From simonpj at microsoft.com Mon Feb 2 03:43:32 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 2 03:33:50 2009 Subject: Core questions In-Reply-To: <20090130190347.GC30132@katherina.student.utwente.nl> References: <20090130190347.GC30132@katherina.student.utwente.nl> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328C7FAAC2@EA-EXMSG-C334.europe.corp.microsoft.com> Matthijs | However, there are two issues bothering me still. The first is that the | Core types (in particular CoreExpr) are not instances of Show. They are | instances of Outputable, which allows them to be pretty printed. | However, this pretty printing is good to view the structure of the | expression that the CoreExpr represents, but doesn't show the structure | of the CoreExpr itself. For example, tuple construction is printed | simply as (a, b), while the actual core expression is a nested | application of two types, and a and b to the GHC.Tuple.(,) function | (or datacon?). Also, the exact constructors used are not quite clear, There's absolutely no reason why CoreExpr CoreBind Type should not be an instance of Show. It'd take you 10 mins to make it so, with the aid of 'standalone deriving' (described in the GHC user manual). There *is* a reason why TyCon and Class are not: a TyCon enumerates its DataCons whose type mentions the TyCon In short, the data structures are, by design, cyclic. Printing one of these would take a long time. But I bet you could get a long way with the three above, plus just printing the *name* of a TyCon or Class or Id. Something like: instance Show TyCon where show tc = showSDoc (ppr tc) | My second question concerns typle construction. Since tuple types are | not primitive types, but dependent types defined in various places | (GHC.Tuple and Base IIRC), code working with tuples is not fundamentally | different from code working with other (user defined) dependent types | and thus not trivial to recognize. I've found that there are some | predicate functions that can tell me if a type is a tuple type, but I've | had no such luck for the actual tuple construction. Well a tuple looks like (tdc ty1 ... tyn arg1 .. argn), where tdc is the data constructor for the tuple. So what you need is: isTupleDataConId :: Id -> Bool It's easy to write isTupleDataConId id | Just data_con <- isDataConId_maybe id = isTupleTyCon (dataConTyCon data_con) I hope this is helpful Simon From Christian.Maeder at dfki.de Mon Feb 2 04:48:33 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Feb 2 04:38:46 2009 Subject: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC In-Reply-To: <49a77b7a0901312057g79026785mfc539729e9003715@mail.gmail.com> References: <49a77b7a0901312057g79026785mfc539729e9003715@mail.gmail.com> Message-ID: <4986C171.5060505@dfki.de> David Menendez wrote: > I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 > running OS X 10.5.5. From what I can tell, I'm getting a segmentation > fault from cabal-bin. On PPC leopard you need to update to XCode 3.1 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX http://hackage.haskell.org/trac/ghc/ticket/2887 HTH Christian > > This is possibly related to > and . > > > cd extensible-exceptions && > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf > configure --distpref=dist-bootstrapping > --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc > --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg > --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp > /bin/sh: line 1: 19203 Segmentation fault > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf > configure --distpref=dist-bootstrapping > --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc > --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg > --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp > make[1]: *** [bootstrapping.conf] Error 139 > make: *** [stage1] Error 2 > > > From leather at cs.uu.nl Mon Feb 2 05:56:15 2009 From: leather at cs.uu.nl (Sean Leather) Date: Mon Feb 2 05:47:22 2009 Subject: Core questions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328C7FAAC2@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090130190347.GC30132@katherina.student.utwente.nl> <638ABD0A29C8884A91BC5FB5C349B1C3328C7FAAC2@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <3c6288ab0902020256r229b6d31uc15ca86a271e09d6@mail.gmail.com> Hi Matthijs, This is a shameless plug for EMGM, a library for generic programming that we've been working on at Utrecht. | However, there are two issues bothering me still. The first is that the > | Core types (in particular CoreExpr) are not instances of Show. They are > | instances of Outputable, which allows them to be pretty printed. > | However, this pretty printing is good to view the structure of the > | expression that the CoreExpr represents, but doesn't show the structure > | of the CoreExpr itself. For example, tuple construction is printed > | simply as (a, b), while the actual core expression is a nested > | application of two types, and a and b to the GHC.Tuple.(,) function > | (or datacon?). Also, the exact constructors used are not quite clear, > > There's absolutely no reason why > CoreExpr > CoreBind > Type > should not be an instance of Show. It'd take you 10 mins to make it so, > with the aid of 'standalone deriving' (described in the GHC user manual). > > There *is* a reason why TyCon and Class are not: > a TyCon > enumerates its DataCons > whose type mentions the TyCon > > In short, the data structures are, by design, cyclic. Printing one of > these would take a long time. > > But I bet you could get a long way with the three above, plus just printing > the *name* of a TyCon or Class or Id. Something like: > instance Show TyCon where > show tc = showSDoc (ppr tc) > Suppose you want to print a type with the exception of one constructor, because it is mutually recursive with another or just prints out lots of useless information. There are at least two ways to do it, one with EMGM, and one with standalone deriving. I show both below. > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE OverlappingInstances #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE StandaloneDeriving #-} > > module Example where > > import qualified Generics.EMGM as G > > ----------------------------------------- > > data A = A0 Int | A1 B > data B = B0 Char | B1 A > > $(G.derive ''A) > $(G.derive ''B) > > instance G.Rep G.Show B where > rep = G.Show (\_ _ -> f) > where > f (B0 c) = showString "(B0 " . showChar c . showString ")" > f (B1 _) = showString "(B1 )" > > valAB = A1 (B1 (A0 37)) > showAB = G.show valAB > > ----------------------------------------- > > data C = C0 Int | C1 D > data D = D0 Char | D1 C > > deriving instance Show C > instance Show D where > showsPrec _ = f > where > f (D0 c) = showString "(D0 " . showChar c . showString ")" > f (D1 _) = showString "(D1 )" > > valCD = C1 (D1 (C0 37)) > showCD = show valCD > > ----------------------------------------- The first one uses EMGM's Template Haskell-based derive function to generate the type representation. I then give an overriding instance for the generic Show function (where G.Show is a newtype used for all show/shows/showsPrec generic functions). So, the constructor B1 will not print out the value of its A-type argument. The second uses standalone deriving and a handwritten instance for D that does the same thing as the first solution did for B. What's the difference? Well, between these instances of G.Show and Show, there's not much. However, the EMGM approach gives you access to a lot of other generic functions including Read, Crush, Collect, etc. See the documentation for all of them [1]. One function you may be able to take advantage of is 'collect', perhaps to collect the B values in valAB. *Example> G.show (G.collect valAB :: [B]) "[(B1 )]" Moral of the story: you can do it either way, but EMGM gives you a lot extra. Apologies for the self-promotion, but we're looking for people who might want to use EMGM. ;) If you have feedback, let us know! [2] Regards, Sean [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm [2] http://www.cs.uu.nl/wiki/GenericProgramming/EMGM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090202/863a9741/attachment.htm From gwright at comcast.net Mon Feb 2 09:58:02 2009 From: gwright at comcast.net (Gregory Wright) Date: Mon Feb 2 09:48:14 2009 Subject: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC In-Reply-To: <4986C171.5060505@dfki.de> References: <49a77b7a0901312057g79026785mfc539729e9003715@mail.gmail.com> <4986C171.5060505@dfki.de> Message-ID: <545ABE5B-74A0-4406-9004-A50B5D624B19@comcast.net> Hi David, On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote: > David Menendez wrote: >> I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 >> running OS X 10.5.5. From what I can tell, I'm getting a segmentation >> fault from cabal-bin. > > On PPC leopard you need to update to XCode 3.1 > http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX > http://hackage.haskell.org/trac/ghc/ticket/2887 > > HTH Christian > It would be very helpful to know if this solves the problem for you. I've had reports of similar failures on 10.4, but have not been able to reproduce them on a ppc/10.4 machine or a ppc/10.5 machine. Even with Xcode 3.0, it seems as if not everyone gets tagged by the error. Greg >> >> This is possibly related to >> and . >> >> >> cd extensible-exceptions && >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> cabal-bin >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> bootstrapping.conf >> configure --distpref=dist-bootstrapping >> --with-compiler=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc >> --with-hc-pkg=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg >> --package-db=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> bootstrapping.conf.tmp >> /bin/sh: line 1: 19203 Segmentation fault >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> cabal-bin >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> bootstrapping.conf >> configure --distpref=dist-bootstrapping >> --with-compiler=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc >> --with-hc-pkg=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg >> --package-db=/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ >> bootstrapping.conf.tmp >> make[1]: *** [bootstrapping.conf] Error 139 >> make: *** [stage1] Error 2 >> >> >> From twhitehead at gmail.com Mon Feb 2 11:26:02 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Feb 2 11:16:24 2009 Subject: ST monad and monad tranformers Message-ID: <200902021126.13015.twhitehead@gmail.com> I have a situation in which I believe I need a parameterizable version of the strict ST monad. My computation type is "StateT s' (STT s (ErrorT e m)) a" (i.e., fails or succeeds and has an internal state involving a state thread). The STT type above is a version of ST like the ReaderT, StateT, etc. types. newtype STT s m a = STT ( State# s -> m (STTBox s a) ) data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a (I'm guessing on the UNPACK paragmas here) with runSTT :: (Monad m) => (forall s. STT s m a) -> m a runSTT m = case m of STT m' -> do STTBox _ x <- m' realWorld# return x (writing this as "runSTT (STT m') = ..." doesn't typecheck with ghc 6.8.2) instance Monad m => Monad (STT s m) where return x = STT $ \s -> return $ STTBox s x (STT m) >>= k = STT $ \s -> do STTBox s' x <- m s case k x of STT k' -> k' s' plus all the assorted instances for Functor, MonadPlus, MonadFix, MonadTrans, MonadReader, MonadState, etc. For example, instance MonadWriter w m => MonadWriter w (STT s m) where tell = lift . tell listen (STT m) = STT $ \s -> do (STTBox s' x,w) <- listen $ m s return $ STTBox s' (x,w) pass (STT m) = STT $ \s -> pass $ do STTBox s' (x,f) <- m s return (STTBox s' x,f) I was looking for any comments, wondering if there is a reason for this not existing in the library already, and what I should do in terms of paragmas and such for speed? I see the GHC-ST file has a mix of INLINE and NOINLINE. http://www.haskell.org/ghc/dist/current/docs/libraries/base/src/GHC-ST.html In particular, return, >>=, >>, and runST are marked INLINE, but there is a "regrettably delicate" comment that goes with the runST method. Also, what about the Functor, MonadPlus, MonadFix, MonadTrans, MonadReader, etc. methods? Thanks! -Tyson PS: I would be happy to provide the whole works to be added to the library if it is something that should be there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090202/27f993d1/attachment.bin From josef.svenningsson at gmail.com Mon Feb 2 12:03:15 2009 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Mon Feb 2 11:53:27 2009 Subject: ST monad and monad tranformers In-Reply-To: <200902021126.13015.twhitehead@gmail.com> References: <200902021126.13015.twhitehead@gmail.com> Message-ID: <8dde104f0902020903i3a031f36w8cb6c72e78aa3e6@mail.gmail.com> Hi Tyson, I also needed something like this a while ago so I knocked up a really simple module and put it on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/STMonadTrans If you have any suggestions for improvement they are most welcome. Patches even more so. Josef 2009/2/2 Tyson Whitehead : > I have a situation in which I believe I need a parameterizable version of the > strict ST monad. My computation type is "StateT s' (STT s (ErrorT e m)) a" > (i.e., fails or succeeds and has an internal state involving a state thread). > > The STT type above is a version of ST like the ReaderT, StateT, etc. types. > > newtype STT s m a = STT ( State# s -> m (STTBox s a) ) > data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a > > (I'm guessing on the UNPACK paragmas here) with > > runSTT :: (Monad m) => (forall s. STT s m a) -> m a > runSTT m = case m of STT m' -> do STTBox _ x <- m' realWorld# > return x > > (writing this as "runSTT (STT m') = ..." doesn't typecheck with ghc 6.8.2) > > instance Monad m => Monad (STT s m) where > return x = STT $ \s -> return $ STTBox s x > (STT m) >>= k = STT $ \s -> do STTBox s' x <- m s > case k x of STT k' -> k' s' > > plus all the assorted instances for Functor, MonadPlus, MonadFix, MonadTrans, > MonadReader, MonadState, etc. For example, > > instance MonadWriter w m => MonadWriter w (STT s m) where > tell = lift . tell > listen (STT m) = STT $ \s -> do (STTBox s' x,w) <- listen $ m s > return $ STTBox s' (x,w) > pass (STT m) = STT $ \s -> pass $ do STTBox s' (x,f) <- m s > return (STTBox s' x,f) > > I was looking for any comments, wondering if there is a reason for this not > existing in the library already, and what I should do in terms of paragmas and > such for speed? I see the GHC-ST file has a mix of INLINE and NOINLINE. > > http://www.haskell.org/ghc/dist/current/docs/libraries/base/src/GHC-ST.html > > In particular, return, >>=, >>, and runST are marked INLINE, but there is a > "regrettably delicate" comment that goes with the runST method. Also, what > about the Functor, MonadPlus, MonadFix, MonadTrans, MonadReader, etc. methods? > > Thanks! -Tyson > > PS: I would be happy to provide the whole works to be added to the library if > it is something that should be there. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From rwbarton at math.harvard.edu Mon Feb 2 14:50:10 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Mon Feb 2 14:40:25 2009 Subject: ST monad and monad tranformers In-Reply-To: <8dde104f0902020903i3a031f36w8cb6c72e78aa3e6@mail.gmail.com> References: <200902021126.13015.twhitehead@gmail.com> <8dde104f0902020903i3a031f36w8cb6c72e78aa3e6@mail.gmail.com> Message-ID: <20090202195010.GA2182@rwbarton.mit.edu> On Mon, Feb 02, 2009 at 06:03:15PM +0100, Josef Svenningsson wrote: > Hi Tyson, > > I also needed something like this a while ago so I knocked up a really > simple module and put it on hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/STMonadTrans Warning! The STMonadTrans package uses State# nonlinearly, and as a result, can violate referential transparency: > import Control.Monad > import Control.Monad.Trans > import Control.Monad.ST.Trans > > data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show > > instance Monad Tree where > return = Leaf > Leaf a >>= k = k a > Branch l r >>= k = Branch (l >>= k) (r >>= k) > > foo :: STT s Tree Integer > foo = do > x <- newSTRef 0 > y <- lift (Branch (Leaf 1) (Leaf 2)) > when (odd y) (writeSTRef x y) > readSTRef x > > main = do > print $ runST foo > let Branch _ (Leaf x) = runST foo > print x prints Branch (Leaf 1) (Leaf 1) 0 Evaluating the thunk in the left branch affects the value seen in the right branch. In general a monad transformer version of ST would need to duplicate its state for each branch when used in conjunction with a nondeterminism monad like Tree, which would make it not really different from State, I think. Regards, Reid From twhitehead at gmail.com Mon Feb 2 17:03:28 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Feb 2 16:54:41 2009 Subject: ST monad and monad tranformers In-Reply-To: <200902021126.13015.twhitehead@gmail.com> References: <200902021126.13015.twhitehead@gmail.com> Message-ID: <200902021704.29493.twhitehead@gmail.com> On February 2, 2009 11:26:02 Tyson Whitehead wrote: > The STT type above is a version of ST like the ReaderT, StateT, etc. types. > > newtype STT s m a = STT ( State# s -> m (STTBox s a) ) > data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a > > runSTT :: (Monad m) => (forall s. STT s m a) -> m a > runSTT m = case m of STT m' -> do STTBox _ x <- m' realWorld# > return x > > instance Monad m => Monad (STT s m) where > return x = STT $ \s -> return $ STTBox s x > (STT m) >>= k = STT $ \s -> do STTBox s' x <- m s > case k x of STT k' -> k' s' Of course, I forgot the method to actually use state threaded code stToSTT :: Monad m => ST s a -> STT s m a stToSTT (ST m) = STT $ \s -> case m s of (# s',x #) -> return $ STTBox s' x In re-reading my original email, I also thought I might not have been clear that I did write the instance methods (MonadCont, etc.), I just didn't include them as they would have made the email too lengthy. Cheers! -Tyson PS: Thanks for all the comments so far. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090202/5b340e61/attachment.bin From josef.svenningsson at gmail.com Mon Feb 2 17:41:13 2009 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Mon Feb 2 17:31:22 2009 Subject: ST monad and monad tranformers In-Reply-To: <20090202195010.GA2182@rwbarton.mit.edu> References: <200902021126.13015.twhitehead@gmail.com> <8dde104f0902020903i3a031f36w8cb6c72e78aa3e6@mail.gmail.com> <20090202195010.GA2182@rwbarton.mit.edu> Message-ID: <8dde104f0902021441n27347805gf524356282692b4d@mail.gmail.com> On Mon, Feb 2, 2009 at 8:50 PM, Reid Barton wrote: > On Mon, Feb 02, 2009 at 06:03:15PM +0100, Josef Svenningsson wrote: >> Hi Tyson, >> >> I also needed something like this a while ago so I knocked up a really >> simple module and put it on hackage: >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/STMonadTrans > > Warning! The STMonadTrans package uses State# nonlinearly, and as a > result, can violate referential transparency: > Indeed, thanks for pointing this out. I really should have a warning sign on the package saying that it only works for certain monads. Cheers, /Josef From kyagrd at gmail.com Tue Feb 3 00:44:53 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Tue Feb 3 00:35:09 2009 Subject: Surprised to type in (1+n) as a type index! Message-ID: I was writing a document in lhs form and typed in something like this. > data Exp n where > Atom :: Exp () > List :: [Exp n] -> Exp (1+n) I wasn't expecting this to actually load up on GHCi, but when I load this up with the magical -fglasgow-exts option, it just worked !!! *Main> :t Atom Atom :: Exp () *Main> :t List [Atom, Atom] List [Atom, Atom] :: forall (+ :: * -> * -> *). Exp (+ GHC.Generics.Unit ()) It seems GHC is treating + as just a type variable for binary type constructor of kind * -> * -> *. *Main> :t List [Atom, Atom] List [Atom, Atom] :: forall (+ :: * -> * -> *). Exp (+ GHC.Generics.Unit ()) *Main> :t List [List [Atom, Atom], List []] List [List [Atom, Atom], List []] :: forall (+ :: * -> * -> *) (+1 :: * -> * -> *). Exp (+1 GHC.Generics.Unit (+ GHC.Generics.Unit ())) *Main> :t List [List [List [Atom, Atom], List []]] List [List [List [Atom, Atom], List []]] :: forall (+ :: * -> * -> *) (+1 :: * -> * -> *) (+2 :: * -> * -> *). Exp (+2 GHC.Generics.Unit (+1 GHC.Generics.Unit (+ GHC.Generics.Unit ()))) But, what is this GHC.Generics.Unit thing and where is this documented? Thanks, Ahn, Ki Yung From marlowsd at gmail.com Tue Feb 3 11:42:44 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 3 11:33:02 2009 Subject: Ready for testing: Unicode support for Handle I/O Message-ID: <49887404.4070504@gmail.com> I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: http://www.haskell.org/~simonmar/base-unicode.tar.gz That is a set of patches against a GHC repo tree: unpack the tarball, and say 'sh apply /path/to/ghc/repo' to apply all the patches. Then clean your tree and build it from scratch (or if you're using the new GHC build system, just say 'make' ;-). It should validate, bar one or two minor failures. Oh, it doesn't work on Windows yet. That's the major thing left to do. If anyone else felt like tackling this I'd be delighted: all you have to do is implement a Win32 equivalent of the module GHC.IO.Encoding.Iconv (see below), everything else should work unchanged. Depending on whether any further changes are required, I may amend-record some of these patches, so treat them as temporary patches for testing only. Below is what will be the patch description in the patch for libraries/base. Comments/discussion please! Cheers, Simon Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). Currently hSetEncoding is availble from GHC.IO.Handle, and the encodings are available from GHC.IO.Encoding. We may want to export these from somewhere more permanent; that's something for a library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance is about 30% slower on "hGetContents >>= putStr" than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. IO library restructuring ~~~~~~~~~~~~~~~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc. From jgoerzen at complete.org Tue Feb 3 12:03:58 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 11:54:08 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <49887404.4070504@gmail.com> References: <49887404.4070504@gmail.com> Message-ID: <498878FE.2040502@complete.org> Simon Marlow wrote: > I've been working on adding proper Unicode support to Handle I/O in GHC, > and I finally have something that's ready for testing. I've put a patchset > here: Yay! Comments below. > Comments/discussion please! Do you expect Hugs will be able to pick up all of this? > The only change to the existing behaviour is that by default, text IO > is done in the prevailing encoding of the system. Handles created by > openBinaryFile use the Latin-1 encoding, as do Handles placed in > binary mode using hSetBinaryMode. Sounds very good and reasonable. > We provide a way to change the encoding for an existing Handle: > > hSetEncoding :: Handle -> TextEncoding -> IO () > > and various encodings: > > latin1, > utf8, > utf16, utf16le, utf16be, > utf32, utf32le, utf32be, > localeEncoding, Will there also be something to handle the UTF-16 BOM marker? I'm not sure what the best API for that is, since it may or may not be present, but it should be considered -- and could perhaps help autodetect encoding. > Thanks to suggestions from Duncan Coutts, it's possible to call > hSetEncoding even on buffered read Handles, and the right thing > happens. So we can read from text streams that include multiple > encodings, such as an HTTP response or email message, without having > to turn buffering off (though there is a penalty for switching > encodings on a buffered Handle, as the IO system has to do some > re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? > Performance is about 30% slower on "hGetContents >>= putStr" than > before. I've profiled it, and about 25% of this is in doing the > actual encoding/decoding, the rest is accounted for by the fact that > we're shuffling around 32-bit chars rather than bytes in the Handle > buffer, so there's not much we can do to improve this. Does this mean that if we set the encoding to latin1, tat we should see performance 5% worse than present? 30% slower is a big deal, especially since we're not all that speedy now. > IO library restructuring > ~~~~~~~~~~~~~~~~~~~~~~~~ > > The major change here is that the implementation of the Handle > operations is separated from the underlying IO device, using type > classes. File descriptors are just one IO provider; I have also > implemented memory-mapped files (good for random-access read/write) > and a Handle that pipes output to a Chan (useful for testing code that > writes to a Handle). New kinds of Handle can be implemented outside > the base package, for instance someone could write bytestringToHandle. > A Handle is made using mkFileHandle: Very nice. That means I can eliminate all the HVIO stuff I have in MissingH, which does roughly the same thing. > with making new kinds of Handle. We could split up the layers further > later. Would it now be possible to make the Socket an instance of this typeclass, so we can work with it directly rather than having to convert it to a Handle first? Thanks, -- John From twhitehead at gmail.com Tue Feb 3 12:04:05 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue Feb 3 11:54:23 2009 Subject: ST monad and monad tranformers In-Reply-To: <20090202195010.GA2182@rwbarton.mit.edu> References: <200902021126.13015.twhitehead@gmail.com> <8dde104f0902020903i3a031f36w8cb6c72e78aa3e6@mail.gmail.com> <20090202195010.GA2182@rwbarton.mit.edu> Message-ID: <200902031204.11541.twhitehead@gmail.com> On February 2, 2009 14:50:10 Reid Barton wrote: > On Mon, Feb 02, 2009 at 06:03:15PM +0100, Josef Svenningsson wrote: > > > > I also needed something like this a while ago so I knocked up a really > > simple module and put it on hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/STMonadTrans > > Warning! The STMonadTrans package uses State# nonlinearly, and as a > result, can violate referential transparency: So, if I understand correctly, the underlying issue is that newtype STT s m a = STT (State# s -> m (STTRet s a)) data STTRet s a = STTRet (State# s) a along with STT m >>= k = STT $ \st -> do ret <- m st case ret of STTRet new_st a -> unSTT (k a) new_st (or my equivalent versions) can multithread the "State #s" token depending on how the underlying m monad implements it's bind operator. As in your example data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show Leaf a >>= k = k a Branch l r >>= k = Branch (l >>= k) (r >>= k) things breaks as multithreading the "State# s" token is a strict no-no because it doesn't actually duplicate the underlying real word it represents. StateT doesn't have this problem as it real has a state that would then branch. I guess then, if you wanted to salvage anything out of this, you would need something like a MonadSingleThreaded class that tags single threaded monads and is a class requirement for combining with the STT monad. Is this correct? And, apart from this, is it correct that ghc optimizations can't shuffle code in such a way that things break due to the single threading of the state token through the primitive operations such as newMutVar#? Thanks -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090203/0b25a27c/attachment-0001.bin From duncan.coutts at worc.ox.ac.uk Tue Feb 3 17:56:13 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 17:46:07 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <498878FE.2040502@complete.org> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> Message-ID: <1233701773.26754.590.camel@localhost> On Tue, 2009-02-03 at 11:03 -0600, John Goerzen wrote: > Will there also be something to handle the UTF-16 BOM marker? I'm not > sure what the best API for that is, since it may or may not be present, > but it should be considered -- and could perhaps help autodetect encoding. I think someone else mentioned this already, but utf16 (as opposed to utf16be/le) will use the BOM if its present. I'm not quite sure what happens when you switch encoding, presumably it'll accept and consider a BOM at that point. > > Thanks to suggestions from Duncan Coutts, it's possible to call > > hSetEncoding even on buffered read Handles, and the right thing > > happens. So we can read from text streams that include multiple > > encodings, such as an HTTP response or email message, without having > > to turn buffering off (though there is a penalty for switching > > encodings on a buffered Handle, as the IO system has to do some > > re-decoding to figure out where it should start reading from again). > > Sounds useful, but is this the bit that causes the 30% performance hit? No. You only pay that penalty if you switch encoding. The standard case has no extra cost. > > Performance is about 30% slower on "hGetContents >>= putStr" than > > before. I've profiled it, and about 25% of this is in doing the > > actual encoding/decoding, the rest is accounted for by the fact that > > we're shuffling around 32-bit chars rather than bytes in the Handle > > buffer, so there's not much we can do to improve this. > > Does this mean that if we set the encoding to latin1, tat we should see > performance 5% worse than present? No, I think that's 30% for latin1. The cost is not really the character conversion but the copying from a byte buffer via iconv to a char buffer. > 30% slower is a big deal, especially since we're not all that speedy now. Bear in mind that's talking about the [Char] interface, and nobody using that is expecting great performance. We already have an API for getting big chunks of bytes out of a Handle, with the new Handle we'll also want something equivalent for a packed text representation. Hopefully we can get something nice with the new text package. Duncan From dave at zednenem.com Tue Feb 3 18:34:10 2009 From: dave at zednenem.com (David Menendez) Date: Tue Feb 3 18:24:16 2009 Subject: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC In-Reply-To: <545ABE5B-74A0-4406-9004-A50B5D624B19@comcast.net> References: <49a77b7a0901312057g79026785mfc539729e9003715@mail.gmail.com> <4986C171.5060505@dfki.de> <545ABE5B-74A0-4406-9004-A50B5D624B19@comcast.net> Message-ID: <49a77b7a0902031534r3e593494k217fbcaf08876d0f@mail.gmail.com> On Mon, Feb 2, 2009 at 9:58 AM, Gregory Wright wrote: > On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote: > >> David Menendez wrote: >>> >>> I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 >>> running OS X 10.5.5. From what I can tell, I'm getting a segmentation >>> fault from cabal-bin. >> >> On PPC leopard you need to update to XCode 3.1 >> http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX >> http://hackage.haskell.org/trac/ghc/ticket/2887 >> >> HTH Christian >> > > It would be very helpful to know if this solves the problem for you. I've > had reports > of similar failures on 10.4, but have not been able to reproduce them on a > ppc/10.4 machine > or a ppc/10.5 machine. > > Even with Xcode 3.0, it seems as if not everyone gets tagged by the error. This took care of the problem for me. Thanks. -- Dave Menendez From jgoerzen at complete.org Tue Feb 3 18:39:43 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 18:29:55 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <1233701773.26754.590.camel@localhost> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> Message-ID: <20090203233943.GA10645@complete.org> On Tue, Feb 03, 2009 at 10:56:13PM +0000, Duncan Coutts wrote: > > > Thanks to suggestions from Duncan Coutts, it's possible to call > > > hSetEncoding even on buffered read Handles, and the right thing > > > happens. So we can read from text streams that include multiple > > > encodings, such as an HTTP response or email message, without having > > > to turn buffering off (though there is a penalty for switching > > > encodings on a buffered Handle, as the IO system has to do some > > > re-decoding to figure out where it should start reading from again). > > > > Sounds useful, but is this the bit that causes the 30% performance hit? > > No. You only pay that penalty if you switch encoding. The standard case > has no extra cost. I'm confused. I thought the standard case was conversion to the system's local encoding? How is that different than selecting the same encoding manually? There always has to be *some* conversion from a 32-bit Char to the system's selection, right? What exactly do we have to do to avoid the penalty? > No, I think that's 30% for latin1. The cost is not really the character > conversion but the copying from a byte buffer via iconv to a char > buffer. Don't we already have to copy between a byte buffer and a char buffer, since read() and write() use a byte buffer? > > 30% slower is a big deal, especially since we're not all that speedy now. > > Bear in mind that's talking about the [Char] interface, and nobody using > that is expecting great performance. We already have an API for getting Yes, I know, but it's still the most convenient interface, and making it suck more isn't cool -- though there are certainly big wins here. -- John From duncan.coutts at worc.ox.ac.uk Tue Feb 3 20:32:59 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 20:22:49 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <20090203233943.GA10645@complete.org> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> <20090203233943.GA10645@complete.org> Message-ID: <1233711179.26754.616.camel@localhost> On Tue, 2009-02-03 at 17:39 -0600, John Goerzen wrote: > On Tue, Feb 03, 2009 at 10:56:13PM +0000, Duncan Coutts wrote: > > > > Thanks to suggestions from Duncan Coutts, it's possible to call > > > > hSetEncoding even on buffered read Handles, and the right thing > > > > happens. So we can read from text streams that include multiple > > > > encodings, such as an HTTP response or email message, without having > > > > to turn buffering off (though there is a penalty for switching > > > > encodings on a buffered Handle, as the IO system has to do some > > > > re-decoding to figure out where it should start reading from again). > > > > > > Sounds useful, but is this the bit that causes the 30% performance hit? > > > > No. You only pay that penalty if you switch encoding. The standard case > > has no extra cost. > > I'm confused. I thought the standard case was conversion to the > system's local encoding? How is that different than selecting the > same encoding manually? Sorry, I think we've been talking at cross purposes. > There always has to be *some* conversion from a 32-bit Char to the > system's selection, right? Yes. In text mode there is always some conversion going on. Internally there is a byte buffer and a char buffer (ie UTF32). > What exactly do we have to do to avoid the penalty? The penalty we're talking about here is not the cost of converting bytes to characters, it's in switching which encoding the Handle is using. For example you might read some HTTP headers in ASCII and then switch the Handle encoding to UTF8 to read some XML. Switching the Handle encoding has a penalty. We have to discard the characters that we pre-decoded and re-decode the byte buffer in the new encoding. It's actually slightly more complicated because we do not track exactly how the byte and character buffers relate to each other (it'd be too expensive in the normal cases) so to work out the relationship when switching encoding we have to re-decode all the way from the beginning of the current byte buffer. The point is, in terms of performance we get the ability to switch handle encoding more or less for free. It has a cost in terms of code complexity. The simpler alternative design was that you would not be able to switch encoding on a read handle that used any buffering at the character level without loosing bytes. The performance penalty when switching encoding is the downside to the ordinary code path being fast. > > No, I think that's 30% for latin1. The cost is not really the character > > conversion but the copying from a byte buffer via iconv to a char > > buffer. > > Don't we already have to copy between a byte buffer and a char buffer, > since read() and write() use a byte buffer? In the existing Handle mechanism we read() into a byte buffer and then when doing say getLine or getContents we allocate [Char]'s in a loop reading bytes directly from the byte buffer. There is no separate character buffer. Duncan From jgoerzen at complete.org Tue Feb 3 22:49:10 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 22:39:26 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <1233711179.26754.616.camel@localhost> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> <20090203233943.GA10645@complete.org> <1233711179.26754.616.camel@localhost> Message-ID: <49891036.1060100@complete.org> Duncan Coutts wrote: > Sorry, I think we've been talking at cross purposes. I think so. >> There always has to be *some* conversion from a 32-bit Char to the >> system's selection, right? > > Yes. In text mode there is always some conversion going on. Internally > there is a byte buffer and a char buffer (ie UTF32). > >> What exactly do we have to do to avoid the penalty? > > The penalty we're talking about here is not the cost of converting bytes > to characters, it's in switching which encoding the Handle is using. For > example you might read some HTTP headers in ASCII and then switch the > Handle encoding to UTF8 to read some XML. Simon referenced a 30% penalty. Are you saying that if we read from a Handle using the same encoding that we used when we first opened it, that we won't see any slowdown vs. the system in 6.10? > Switching the Handle encoding has a penalty. We have to discard the > characters that we pre-decoded and re-decode the byte buffer in the new > encoding. It's actually slightly more complicated because we do not Got it. That makes sense, as does the decision to optimize for the more common (not switching the encoding) case. -- John From paolo at hypersonic.it Wed Feb 4 05:33:21 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Wed Feb 4 05:30:07 2009 Subject: Ready for testing: Unicode support for Handle I/O In-Reply-To: <49887404.4070504@gmail.com> References: <49887404.4070504@gmail.com> Message-ID: <49896EF1.3080700@hypersonic.it> Simon Marlow wrote: > The only change to the existing behaviour is that by default, text IO > is done in the prevailing encoding of the system. Handles created by > openBinaryFile use the Latin-1 encoding, as do Handles placed in > binary mode using hSetBinaryMode. wouldn't be semantically correct for a "binary handle" to "return" [Word8]? also switching from text to binary (hSetBinaryMode) doesn't seem "natural" I understand that this has "heavy" consequences... Pao From paolo at hypersonic.it Wed Feb 4 06:53:18 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Wed Feb 4 06:45:08 2009 Subject: Ready for testing: Unicode support for Handle I/O In-Reply-To: References: <49887404.4070504@gmail.com> <49896EF1.3080700@hypersonic.it> Message-ID: <498981AE.4040006@hypersonic.it> Max Vasin wrote: > Wouldn't it be more correct to separate binary IO, which > return [Word8] (or ByteString) and text IO which return > [Char] and deal with text encoding? IIRC that was done in > Bulat Ziganshin's streams library. That's exactly what I meant. Text IO could be then implemented on top of binary IO. Would it be possible to envision a solution that enables composition of IO low level strategies vs binary <-> text conversion strategies? Pao From deniz.a.m.dogan at gmail.com Wed Feb 4 18:11:35 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed Feb 4 18:01:38 2009 Subject: Temporarily overriding Data.Generic Message-ID: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> Sorry for those who receive this who have already gotten it from haskell-cafe. --- Hi I'm currently working on "hacking" Data.Generics for my master thesis. I'm basically trying to find out whether it can be made any faster using e.g. rewrite rules. The problem I'm having is that I need an easy way to import my own modified version of Data.Generics (currently located in the same directory as my testing program) without unregistering or hiding syb-0.1.0.0 as base seems to depend on it. I've read the GHC user manual trying to find nice ways to do this using a bunch of different parameters to ghc, but I can't figure it out. Does anyone here know? Any help appreciated, Deniz From duncan.coutts at worc.ox.ac.uk Wed Feb 4 19:42:42 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 4 19:32:29 2009 Subject: Temporarily overriding Data.Generic In-Reply-To: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> References: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> Message-ID: <1233794562.26754.666.camel@localhost> On Thu, 2009-02-05 at 00:11 +0100, Deniz Dogan wrote: > I'm currently working on "hacking" Data.Generics for my master thesis. > I'm basically trying to find out whether it can be made any faster > using e.g. rewrite rules. The problem I'm having is that I need an > easy way to import my own modified version of Data.Generics (currently > located in the same directory as my testing program) without > unregistering or hiding syb-0.1.0.0 as base seems to depend on it. This should just work. If ./Data/Generics.hs exists in / relative to the current directory then by default that overrides the module of the same name from the syb package. There's clearly some specific problem you're hitting, can you tell us more about it? When you say "currently located in the same directory as my testing program" do you mean you've got Generics.hs in the same dir as your Test.hs module or do you mean you've got ./Test.hs and ./Data/Generics.hs, ie in a subdirectory? The problems you're likely to run into will be with other code that already uses the syb:Data.Generics module as the types are necessarily not substitutable for each other. > I've read the GHC user manual trying to find nice ways to do this > using a bunch of different parameters to ghc, but I can't figure it > out. Does anyone here know? The command line options for controlling the module search path are basically the -package flags and the -i flag. The default if you don't say anything is -i. meaning look first in the current directory. Duncan From jpm at cs.uu.nl Thu Feb 5 02:43:52 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Feb 5 02:33:55 2009 Subject: Temporarily overriding Data.Generic In-Reply-To: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> References: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> Message-ID: <52f14b210902042343j3fd4e25an83ed42fc2d7dc2@mail.gmail.com> Hi Deniz, On Thu, Feb 5, 2009 at 00:11, Deniz Dogan wrote: > Sorry for those who receive this who have already gotten it from > haskell-cafe. > > --- > > Hi > > I'm currently working on "hacking" Data.Generics for my master thesis. > I'm basically trying to find out whether it can be made any faster > using e.g. rewrite rules. Great! Please let us know of the results when you have them :-) > The problem I'm having is that I need an > easy way to import my own modified version of Data.Generics (currently > located in the same directory as my testing program) without > unregistering or hiding syb-0.1.0.0 as base seems to depend on it. > > I've read the GHC user manual trying to find nice ways to do this > using a bunch of different parameters to ghc, but I can't figure it > out. Does anyone here know? I've had my own problems while developing a successor version of the syb package. For starters, cabal fails to install the package: >cabal install Resolving dependencies... cabal: dependencies conflict: base-3.0.3.0 requires syb ==0.1.0.0 however syb-0.1.0.0 was excluded because syb-0.2.0.0 was selected instead syb-0.1.0.0 was excluded because of the top level dependency syb ==0.2.0.0 Note that this package explicitly requires base >= 4.0. Anyway, runghc Setup.hs install does it, though. However, after having it installed I can't use it, getting this when any module imports Data.Generics: Bad interface file: C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi Something is amiss; requested module syb:Data.Generics differs from name found in the interface file syb-0.2.0.0:Data.Generics Failed, modules loaded: none. I talked about this on IRC before and remember this might have had something to do with syb having been unversioned in the release of GHC 6.10.1. But I hope someone can clarify this better... Cheers, Pedro > > > Any help appreciated, > Deniz > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090205/948123aa/attachment.htm From phercek at gmail.com Thu Feb 5 04:05:39 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Feb 5 03:56:01 2009 Subject: my experience with ghci debugger extensions Message-ID: Hi users of ghci debugger, This post is going to be a bit longer. Here are few cookies to motivate you to go on: * you will probably like it more than printf debugging for a lot of cases * it can provide a way of implementing Claus Reinke's idea of breakpoints with a list of identifiers which should be available at breakpoint location and doing it without recompilation; here is the link to Claus' message: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 * it gives some idea to ghc team about importance of ghci debugger related tickets (and whether to implement them just the way they were proposed) A note to ghc developers: Stepping program in ghci debugger sometimes purges top level bindings and sometimes not. Not sure this is a bug or feature (whether there is some logic in it). I do not have a simple example when it purges the bindings. But I did not really look for one. I would probably post later, but some ghci bugs and missing features are badly limiting my progress. There is not much more I can think of to investigate. Maybe somebody will have better ideas how to solve the obstacles I'm hitting. I'm also posting with hope that people will find this interesting and ghc team will fix some of the critical bugs and adds the most critical features, especially if somebody will not have better debugging tips. You can get my extensions here: http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz The extensions are not in a single .ghci file now. The new .ghci file needs to install a library. The reason is that without the library it is not manageable any more. And here are arch linux packaging instructions for my custom ghc (if you are an arch linux user just download and run makepkg :) ): http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz The custom ghc is just the same one as ghc 6.10.1 with two more patches: t2740.patch and loglocal.patch. The first one fixes ticket 2740 and you will get it in 6.10.2. The second one adds :loglocal command to ghci. You can extract the patches from the tar file. If you already read ghci scripting tutorial from Claus Reinke then you will know how to customize ghciext (that is if you would feel like doing so). The tutorial is here: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Here is the list of custom commands in ghciext package: :defs -- list user-defined commands :. -- source commands from :redir ... -- execute redirecting stdout to :grep ... -- filter lines matching from output :* ... -- run times :x ... -- run with stdout suppressed :bp -- put breakpoint at location (adds hit count) :inject -- at location execute if , and stop if :monitor [""] -- show comma separated variables at location if :watch -- break at location when is True :count (_|) [] -- count/query/stop execution at location :find ... -- step with until is found :findex ... -- step with until is found :next [lazy] -- step over; lazy version forces only the top constructor :xout -- redirect ghci stdout to /dev/null :out -- redirect ghci stdout back to console :defs, :., :redir, :grep, are the same as the commands in Claus' tutorial. The only differences I recall now are: * grep pattern can be in quotation marks (easier search for spaces) * grep merges :browse output more nicely * redir can accept :step, :steplocal etc; i.e. also the commands which sometimes remove top level bindings * the commands do not pollute top level bindings so much The rest will describe my custom commands and now they relate to tickets in ghci track. If you want to check the tickets mentioned here then the most easy way is probably selecting them from this list: http://hackage.haskell.org/trac/ghc/search?q=phercek&noquickjump=1&ticket=on The initial big problem was how to limit the amount of information ghci debugger spits at you when breakpoints with custom scripts are used. This is also mentioned in forth point of the "unknown" section of ticket #1377: /We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop. Should we print the info only if there were no commands?/ So I say: yes do it! Just disable any ghci output related to a breakpoint when the breakpoint has a custom code attached. We can disable the output ourselves, but then we disable all the output (including the output of the debugged program). People who are debugging console applications are busted (especially if the applications are interactive). This is not an issue for me since my application is not using console almost at all. I'm solving the problem by prefixing commands like /:main/ and /:continue /with my command /:x/. This makes output by default disabled and ghciExt enables it just before a breakpoint code is run. If the breakpoint continues execution it disables it again. If the debugged function finishes the output is enabled by /:x/ itself. A small problem happens when you forget to use /:x/ e.g. with your /:main/. Then you do not get a prompt when the program finishes. It's time to notice it and use /:out/ to switch it on. This is the only minor disadvantage for a gui application debugging. /:xout /in not that useful (it is mostly used internally by /:x/). It could be a hidden command (i.e. not registered in defs). Now when we have ghci "muted" we can get to real goodies: /:monitor/, /:watch/, and /:count/. If you like printf debugging, then /:monitor/ can help you. It can monitor only free variables in the selected expression (on which a breakpoint is hit) but that was always enough for me during debug sessions I had. Write a script file (lets say it is named *ghciInit* (I'll also call it this way later on in this text)) which is like this example: /:monitor var1,var2 ModuleName 23 :monitor var3 ModuleName 40 :x :main mainArgument/ Then open ghci with your program and run *:. ghciInit* And you will get nice log like this: /(0): var1 = var2 = (1): var3 = (0): var1 = var2 = (1): var3 = ... etc/ Moreover /:monitor/ allows condition in quotation marks to be specified as the first argument. If you do it then the variable values will be printed only when the condition is True. Of course the condition can contain only free variables in the selected expression. Mostly it is not a problem. /:watch/ is a conditional breakpoint which stops when the specified condition is True. /:count/ has 3 forms: /:count _ ModuleName 23/ This never breaks just counts number of times the execution reached position ModuleName 23 /:count 5 ModuleNmae 23/ This breaks when we reach position ModuleName 23 fifth time /:count 0/ This tells how many times breakpoint number 0 was hit (it can report the number of hits for any breakpoint created with /:bp/, /:inject/, /:monitor/, /:watch/, and /:count/). The first form of /:count/ is interesting when you want to stop earlier than something bad happens so that you can see why the bad think happened. Put the first form of /:count/ at the start of the function with the bug and then put a break in the function which is hit when the bad think happens maybe with /:watch/. When you stop at the bug place, check hit count at the start of the function. Add the hit count in your /:count/ breakpoint in your *ghciInt* file restart and you can use /:steplocal/ or /:loglocal/ to find out what went wrong. /:loglocal/ is implemented directly in ghc source code. It does exactly the same as /:steplocal/ but makes sure that the trace history does not contain anything outside of the function we step with /:steplocal/. The problem is that /:steplocal/ works like the code was traced while it is executing. Mostly the result is that your trace history is loaded with crap outside of the scope you are interested in. I'll return to /:loglocal/ later again. /:inject/ is there when you need something special (/:monitor/, /:watch/, and /:count/ are implemented with something very like /:inject/). E.g. when you want to do monitoring of a value but do not want the associated breakpoint number printed. /:find/ and /:findex/ are there primary to search trace history. /:find var1 :back/ will find the variable var1 in your trace history by back stepping it /:find var1 :step/ will single step forward till variable var1 is in the list of free variables /:findex BL/Logic.hs:23 :loglocal/ will fill in your trace history will all the local breakpoints till location BL/Logic.hs:23 is hit. Having the trace history filled in with the right stuff is useful for checking out why you got bad results later. Now lets return to Claus' idea of breakpoints with a list of identifiers which should be available at the breakpoint location. You can make sure the identifiers are available with the first form of /:count/. It never stops but it puts records to the trace history. So the trace history will contain free variables at the locations where you put /:count/. This will be even more useful when automatic search of trace history is built in (see ticket #2737). So a weaker form of Claus' idea can be implemented by carefully selecting what should bet to the trace history. Why a weaker form only? Well, in some cases, the variable instances in trace log may not be the expected ones (they may be from a different lexical scope). Experience with my code indicates this should be rare. /:next/ is an idea how to implement a kind of step over. That is if by step over you mean something else than steplocal. The non-lazy form of /:next/ forces _result and does a /:step/. The lazy form forces only the top level constructor of _result before the step. Hey, I even had a case when it worked just like I expected. But typically it does not work because of bug #1531. _result is not correctly bound to the result of selected expression in most of the practical cases. This bug is also critical for all the forms of conditional breakpoints. It would be cool if we could specify the condition based on _result or some part of it. The implementation of ghciExt conditional breakpoints would need to be extended to support conditions on _result (in particular the breakpoint would need to be disabled during the condition execution) but that is easy to do. Even more worrying thing about bug #1531 is that it has the milestone set to _|_. It is easy to add /:enable/ and /:disable/ to support enabling and disabling breakpoints. I just did not need it yet. Here is how a GhciExt breakpoint looks like: *Main> :show breaks [0] Main a.hs:4:2-8 ":cmd return$GhciExt.getStopCode 0 (True) "putStr \"(0): \"\n:force x" "False"" *Main> Just replace getStopCode with getDisabledStopCode and you have it disabled. Return back to enable. Yeah, and implement getDisabledStopCode which will just continue. I added :/loglocal/ mostly to simulate how /:tracelocal/ in ticket #2737 would help. I was also trying how full tracing is helping. In both cases the answer is: full tracing almost never helps. /:tracelocal/ from ticket #2737 as proposed originally would rarely help. The problem is that trace log gets overwhelmed with crap when we cannot control what can be saved in it and what cannot be saved. My idea is that user should be able to specify what can go in it and also what should not go in it. Here is an alternative solution to the ones I proposed in tickets #2737 and #2946. I think this one would be best. The command to control the tracing should look like: -- should everything be traced? :set trace (True|False) -- scopes which should be traced (or should not be traced when ! is present) :set trace ( (!)? scopeid )* -- add/remove individual scopeids to/from the trace specification :set trace (+|-) (!)? scopeid where scopeid = ( conid . )* ( varid . )* varid Notice how scopeid looks. It can have a sequence of varids at the end. The reason is so that user can leave out a scope of a function which is defined in a where clause. The scope specification is similar to the proposal in ticket #3000. E.g. for this code: fn s = 'a' : add s where add = (++"z") it could look like :set trace Main.fn !Main.fn.add meaning trace whole scope of *fn* but not the stuff in the scope of *add. *Order should not be important, requests for not tracing should have precedence before requests to trace. The scopes which we want typically exclude are the ones which contain loops. The loop content often fills in the trace log forcing the interesting stuff out of it. It is better to investigate functions with loops separately in nested context. Notice that there is a bit difference between this proposal of controlling trace content and the one in ticket #2737. #2737 assumes usage of breakpoint arguments to specify a scope. The breakpoint arguments give an ability to define scopes at finer level but there is no option to define exclude scopes which I find important now. The summary is: Trace log is as useful as much you can control what can get in it. The :trace command looks to me like an error. It is better to control it by allowing/disallowing scopes. I also changed my opinion a bit about ticket #2945. :mergetrace would be better than global trace history. Being able to investigate something separately in a nested context is useful. If I should order the ghci debugger related tickets then the order would be like (more important first): #1531 (_result can get bound to the wrong value in a breakpoint) #2737 and #2946 (add :tracelocal to ghci debugger... and add command :mergetrace...) #3000 (:break command should recognize also nonexported top level symbols...) #2803 (bring full top level of a module in scope when a breakpoint is hit in the ...) #1377 (the task: "We should print breakpoint related info only if breakpoint has no commands set") but people debugging interactive console applications would like to have this one the very top; *IIRC* this may be easy to do, looks like all the printing is done in one function (something like afterCmd???); also #2950 looked like trivial to do (like 15 mins without the compile time???) And the last thing: my first time experiences hacking in the /:loglocal/ into ghc. I cannot tell much, I spend with it only one long Sunday afternoon, but here are my two points: * I needed to extend ghc interface. The type of function GHC.resume changed from: resume :: GhcMonad m => SingleStep -> m RunResult to: resume :: GhcMonad m => (SrcSpan->Bool) -> SingleStep -> m RunResult ... plus the corresponding implementation change. The added argument is a filtering function to limit source spans which can recorded in the trace history. * It would be cool if ghci has its own dir in the souce tree where only the ghci source files are. It would encourage people to hack it more since it would be easier to maintain private patches and merging upstream. It would be also easier to make sure one modifies only ghci source code so that it works with other ghc releases. Hopefully this helps somebody, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090205/123ca701/attachment-0001.htm From rturk at science.uva.nl Thu Feb 5 05:49:54 2009 From: rturk at science.uva.nl (Remi Turk) Date: Thu Feb 5 05:39:57 2009 Subject: :info features Message-ID: <20090205104954.GB5422@frogstar.lan> One of my most used GHCi commands is :info, but quite often the type or class definitions that I'm interested in get drowned in lots of instances. So a week ago I wrote a feature request and a little patch that allowed the following: :info Show -- See class definition and instances :info -Show -- See class definition only SPJ agreed with the idea itself, but suggested an alternative set of commands: :info Show -- See class definition only :instances Show -- See instances of Show This would have the advantage of making it easier to later add additional features: :instances Show (Tree _) -- See instances of form (Show (Tree ...)) However, it would make ":i" ambiguous, which is rather sad. Another potential addition to :info (or another command) would be evaluating types to their normal form, that is, expanding (associated) type synonyms. E.g.: :typeeval Plus (Suc Zero) (Suc Zero) -- (Suc (Suc (Suc (Suc Zero)))) Again, the question is whether this is really useful (or reasonably easy to implement, SPJ?) and if so, what interface is to be preferred? So what's your favourite syntax? One of these options or something else? Or are these features completely unnecessary? Oh, the ticket can be found at http://hackage.haskell.org/trac/ghc/ticket/2986#comment:3 Groeten, Remi From colin at colina.demon.co.uk Thu Feb 5 06:27:05 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Feb 5 06:17:13 2009 Subject: Warning about unrecognised pragma Message-ID: I am getting messages: Board_representation.hs:407:0: Unrecognised pragma Board_representation.hs:442:0: Unrecognised pragma Board_representation.hs:458:0: Unrecognised pragma etc. (GHC 6.10.1) I looked into the documentation to see how to supress these warnings (prefereably for the particular pragma concerned), but I found (from 8.13): any pragma encountered with an unrecognised word is (silently) ignored. -- Colin Adams Preston Lancashire From phercek at gmail.com Thu Feb 5 06:35:43 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Feb 5 06:25:59 2009 Subject: :info features In-Reply-To: <20090205104954.GB5422@frogstar.lan> References: <20090205104954.GB5422@frogstar.lan> Message-ID: Remi Turk wrote: > SPJ agreed with the idea itself, but suggested an alternative set of commands: > > :info Show -- See class definition only > :instances Show -- See instances of Show > Hi Remi, If you do not want to wait till this is implemented you can do it yourself using ghci scripting. Details how to do it are in tutorial from Claus Reinke: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Understanding all the possibilities and limitations of ghci scripting may take a day or maybe even more. But once you are done with it you can implement your :instances command and and something like :infoWithoutInstances withing an hour at most. And it is more interesting that you could do much more extensions like this easily if you need them in the future. Peter. From phercek at gmail.com Thu Feb 5 11:09:18 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Feb 5 10:59:31 2009 Subject: fix for :count command of ghciext package In-Reply-To: References: Message-ID: If somebody managed to download it already there is a newer version. Break point counter inside break expressions was one less than it should be. Sorry for inconvenience. It is still very new. Not sure there would be enough interest to put it on hackage or something like that. Let me know if you want it. http://www.hck.sk/users/peter/pub/ghciext-0.2.tar.gz Peter. From mnislaih at gmail.com Thu Feb 5 11:24:17 2009 From: mnislaih at gmail.com (Pepe Iborra) Date: Thu Feb 5 11:14:18 2009 Subject: my experience with ghci debugger extensions In-Reply-To: References: Message-ID: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Hello Peter, Your efforts are simply outstanding. Thanks a lot for sharing your experiences. I want to add a few comments: - Regarding your :logLocal, you should rename it to :stepLocal, open a ticket, and attach your patch. We should really try to get this into 6.10.2. :stepLocal is broken right now, as you say it traces a lot of garbage. I implemented it and shortly later noticed the problem you mention, but never got around to fixing it. Thanks for shouting. (unless you think it makes sense to keep two versions of this command, :logLocal and :stepLocal) - Your idea of forcing _result to implement step over is very nice. A while ago I tried and failed at implementing :next. The conclusion was it cannot be done without a lexical call stack. Your idea could be useful as a pseudo :next, as long as the user of the debugger is ok with changing the evaluation semantics of the program. However, I don't know if there is a fix for the _result bug at hand's reach. I look forward to playing this. Your custom ghc tar.gz file contains an additional patch, network.patch, but there are no instructions about it. I assume it is ok to ignore it. I applied the two other patches succesfully and hopefully in a few minutes will have a working build. Evidently this is a suboptimal way to distribute your changes. If GHCi lived in its own package as a real GHC api client, it would certainly be much easier to distribute modifications like these.Although it would not have helped in this occasion: the changes you needed required modifying the API. Finallly, please do not forget to add a link to this in the GHCi Debugger wiki page at http://haskell.org/haskellwiki/GHC/GHCi_debugger and/or at the debugging page at http://haskell.org/haskellwiki/Debugging Thanks, pepe 2009/2/5 Peter Hercek : > Hi users of ghci debugger, > > This post is going to be a bit longer. Here are few cookies to motivate you > to go on: > * you will probably like it more than printf debugging for a lot of cases > * it can provide a way of implementing Claus Reinke's idea of breakpoints > with a list of identifiers which should be available at breakpoint location > and doing it without recompilation; here is the link to Claus' message: > http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 > * it gives some idea to ghc team about importance of ghci debugger related > tickets (and whether to implement them just the way they were proposed) > > A note to ghc developers: Stepping program in ghci debugger sometimes purges > top level bindings and sometimes not. Not sure this is a bug or feature > (whether there is some logic in it). I do not have a simple example when it > purges the bindings. But I did not really look for one. > > I would probably post later, but some ghci bugs and missing features are > badly limiting my progress. There is not much more I can think of to > investigate. Maybe somebody will have better ideas how to solve the > obstacles I'm hitting. I'm also posting with hope that people will find this > interesting and ghc team will fix some of the critical bugs and adds the > most critical features, especially if somebody will not have better > debugging tips. > > You can get my extensions here: > http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz > The extensions are not in a single .ghci file now. The new .ghci file needs > to install a library. The reason is that without the library it is not > manageable any more. > > And here are arch linux packaging instructions for my custom ghc (if you are > an arch linux user just download and run makepkg :) ): > http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz > The custom ghc is just the same one as ghc 6.10.1 with two more patches: > t2740.patch and loglocal.patch. The first one fixes ticket 2740 and you will > get it in 6.10.2. The second one adds :loglocal command to ghci. You can > extract the patches from the tar file. > > If you already read ghci scripting tutorial from Claus Reinke then you will > know how to customize ghciext (that is if you would feel like doing so). The > tutorial is here: > http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html > > Here is the list of custom commands in ghciext package: > :defs -- list user-defined commands > :. -- source commands from > :redir ... -- execute redirecting stdout to > :grep ... -- filter lines matching from output > :* ... -- run times > :x ... -- run with stdout suppressed > :bp -- put breakpoint at location (adds hit > count) > :inject -- at location execute if , and stop > if > :monitor [""] -- show comma separated variables at location > if > :watch -- break at location when is True > :count (_|) [] -- count/query/stop execution at location > :find ... -- step with until is found > :findex ... -- step with until is found > :next [lazy] -- step over; lazy version forces only the top > constructor > :xout -- redirect ghci stdout to /dev/null > :out -- redirect ghci stdout back to console > > :defs, :., :redir, :grep, are the same as the commands in Claus' tutorial. > The only differences I recall now are: > * grep pattern can be in quotation marks (easier search for spaces) > * grep merges :browse output more nicely > * redir can accept :step, :steplocal etc; i.e. also the commands which > sometimes remove top level bindings > * the commands do not pollute top level bindings so much > > The rest will describe my custom commands and now they relate to tickets in > ghci track. If you want to check the tickets mentioned here then the most > easy way is probably selecting them from this list: > http://hackage.haskell.org/trac/ghc/search?q=phercek&noquickjump=1&ticket=on > > The initial big problem was how to limit the amount of information ghci > debugger spits at you when breakpoints with custom scripts are used. This is > also mentioned in forth point of the "unknown" section of ticket #1377: > We can disable a breakpoint with ":set stop N :continue", but this still > prints out the breakpoint info when we stop. Should we print the info only > if there were no commands? > So I say: yes do it! Just disable any ghci output related to a breakpoint > when the breakpoint has a custom code attached. We can disable the output > ourselves, but then we disable all the output (including the output of the > debugged program). People who are debugging console applications are busted > (especially if the applications are interactive). This is not an issue for > me since my application is not using console almost at all. I'm solving the > problem by prefixing commands like :main and :continue with my command :x. > This makes output by default disabled and ghciExt enables it just before a > breakpoint code is run. If the breakpoint continues execution it disables it > again. If the debugged function finishes the output is enabled by :x itself. > A small problem happens when you forget to use :x e.g. with your :main. Then > you do not get a prompt when the program finishes. It's time to notice it > and use :out to switch it on. This is the only minor disadvantage for a gui > application debugging. :xout in not that useful (it is mostly used > internally by :x). It could be a hidden command (i.e. not registered in > defs). > > Now when we have ghci "muted" we can get to real goodies: :monitor, :watch, > and :count. > If you like printf debugging, then :monitor can help you. It can monitor > only free variables in the selected expression (on which a breakpoint is > hit) but that was always enough for me during debug sessions I had. Write a > script file (lets say it is named ghciInit (I'll also call it this way later > on in this text)) which is like this example: > :monitor var1,var2 ModuleName 23 > :monitor var3 ModuleName 40 > :x :main mainArgument > > Then open ghci with your program and run :. ghciInit > And you will get nice log like this: > (0): var1 = > var2 = > (1): var3 = > (0): var1 = > var2 = > (1): var3 = > ... etc > > Moreover :monitor allows condition in quotation marks to be specified as the > first argument. If you do it then the variable values will be printed only > when the condition is True. Of course the condition can contain only free > variables in the selected expression. Mostly it is not a problem. > :watch is a conditional breakpoint which stops when the specified condition > is True. > :count has 3 forms: > :count _ ModuleName 23 > This never breaks just counts number of times the execution reached > position ModuleName 23 > :count 5 ModuleNmae 23 > This breaks when we reach position ModuleName 23 fifth time > :count 0 > This tells how many times breakpoint number 0 was hit (it can report the > number of hits for any breakpoint created with :bp, :inject, :monitor, > :watch, and :count). > > The first form of :count is interesting when you want to stop earlier than > something bad happens so that you can see why the bad think happened. Put > the first form of :count at the start of the function with the bug and then > put a break in the function which is hit when the bad think happens maybe > with :watch. When you stop at the bug place, check hit count at the start of > the function. Add the hit count in your :count breakpoint in your ghciInt > file restart and you can use :steplocal or :loglocal to find out what went > wrong. > > :loglocal is implemented directly in ghc source code. It does exactly the > same as :steplocal but makes sure that the trace history does not contain > anything outside of the function we step with :steplocal. The problem is > that :steplocal works like the code was traced while it is executing. Mostly > the result is that your trace history is loaded with crap outside of the > scope you are interested in. I'll return to :loglocal later again. > > :inject is there when you need something special (:monitor, :watch, and > :count are implemented with something very like :inject). E.g. when you want > to do monitoring of a value but do not want the associated breakpoint number > printed. > > :find and :findex are there primary to search trace history. > :find var1 :back > will find the variable var1 in your trace history by back stepping it > :find var1 :step > will single step forward till variable var1 is in the list of free > variables > :findex BL/Logic.hs:23 :loglocal > will fill in your trace history will all the local breakpoints till > location BL/Logic.hs:23 is hit. Having the trace history filled in with the > right stuff is useful for checking out why you got bad results later. > > Now lets return to Claus' idea of breakpoints with a list of identifiers > which should be available at the breakpoint location. You can make sure the > identifiers are available with the first form of :count. It never stops but > it puts records to the trace history. So the trace history will contain free > variables at the locations where you put :count. This will be even more > useful when automatic search of trace history is built in (see ticket > #2737). So a weaker form of Claus' idea can be implemented by carefully > selecting what should bet to the trace history. Why a weaker form only? > Well, in some cases, the variable instances in trace log may not be the > expected ones (they may be from a different lexical scope). Experience with > my code indicates this should be rare. > > :next is an idea how to implement a kind of step over. That is if by step > over you mean something else than steplocal. The non-lazy form of :next > forces _result and does a :step. The lazy form forces only the top level > constructor of _result before the step. Hey, I even had a case when it > worked just like I expected. But typically it does not work because of bug > #1531. _result is not correctly bound to the result of selected expression > in most of the practical cases. This bug is also critical for all the forms > of conditional breakpoints. It would be cool if we could specify the > condition based on _result or some part of it. The implementation of ghciExt > conditional breakpoints would need to be extended to support conditions on > _result (in particular the breakpoint would need to be disabled during the > condition execution) but that is easy to do. Even more worrying thing about > bug #1531 is that it has the milestone set to _|_. > > It is easy to add :enable and :disable to support enabling and disabling > breakpoints. I just did not need it yet. Here is how a GhciExt breakpoint > looks like: > *Main> :show breaks > [0] Main a.hs:4:2-8 ":cmd return$GhciExt.getStopCode 0 (True) "putStr \"(0): > \"\n:force x" "False"" > *Main> > Just replace getStopCode with getDisabledStopCode and you have it disabled. > Return back to enable. Yeah, and implement getDisabledStopCode which will > just continue. > > I added :loglocal mostly to simulate how :tracelocal in ticket #2737 would > help. I was also trying how full tracing is helping. In both cases the > answer is: full tracing almost never helps. :tracelocal from ticket #2737 as > proposed originally would rarely help. The problem is that trace log gets > overwhelmed with crap when we cannot control what can be saved in it and > what cannot be saved. My idea is that user should be able to specify what > can go in it and also what should not go in it. Here is an alternative > solution to the ones I proposed in tickets #2737 and #2946. I think this one > would be best. The command to control the tracing should look like: > -- should everything be traced? > :set trace (True|False) > -- scopes which should be traced (or should not be traced when ! is present) > :set trace ( (!)? scopeid )* > -- add/remove individual scopeids to/from the trace specification > :set trace (+|-) (!)? scopeid > where scopeid = ( conid . )* ( varid . )* varid > Notice how scopeid looks. It can have a sequence of varids at the end. The > reason is so that user can leave out a scope of a function which is defined > in a where clause. The scope specification is similar to the proposal in > ticket #3000. E.g. for this code: > fn s = 'a' : add s > where add = (++"z") > it could look like > :set trace Main.fn !Main.fn.add > meaning trace whole scope of fn but not the stuff in the scope of add. > Order should not be important, requests for not tracing should have > precedence before requests to trace. > The scopes which we want typically exclude are the ones which contain loops. > The loop content often fills in the trace log forcing the interesting stuff > out of it. It is better to investigate functions with loops separately in > nested context. > > Notice that there is a bit difference between this proposal of controlling > trace content and the one in ticket #2737. #2737 assumes usage of breakpoint > arguments to specify a scope. The breakpoint arguments give an ability to > define scopes at finer level but there is no option to define exclude scopes > which I find important now. > > The summary is: Trace log is as useful as much you can control what can get > in it. The :trace command looks to me like an error. It is better to control > it by allowing/disallowing scopes. > > I also changed my opinion a bit about ticket #2945. :mergetrace would be > better than global trace history. Being able to investigate something > separately in a nested context is useful. > > If I should order the ghci debugger related tickets then the order would be > like (more important first): > #1531 (_result can get bound to the wrong value in a breakpoint) > #2737 and #2946 (add :tracelocal to ghci debugger... and add command > :mergetrace...) > #3000 (:break command should recognize also nonexported top level > symbols...) > #2803 (bring full top level of a module in scope when a breakpoint is hit in > the ...) > #1377 (the task: "We should print breakpoint related info only if breakpoint > has no commands set") but people debugging interactive console applications > would like to have this one the very top; IIRC this may be easy to do, looks > like all the printing is done in one function (something like afterCmd???); > also #2950 looked like trivial to do (like 15 mins without the compile > time???) > > And the last thing: my first time experiences hacking in the :loglocal into > ghc. I cannot tell much, I spend with it only one long Sunday afternoon, but > here are my two points: > * I needed to extend ghc interface. The type of function GHC.resume changed > from: > resume :: GhcMonad m => SingleStep -> m RunResult > to: > resume :: GhcMonad m => (SrcSpan->Bool) -> SingleStep -> m RunResult > ... plus the corresponding implementation change. The added argument is > a filtering function to limit source spans which can recorded in the trace > history. > * It would be cool if ghci has its own dir in the souce tree where only the > ghci source files are. It would encourage people to hack it more since it > would be easier to maintain private patches and merging upstream. It would > be also easier to make sure one modifies only ghci source code so that it > works with other ghc releases. > > Hopefully this helps somebody, > Peter. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From phercek at gmail.com Thu Feb 5 12:07:44 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Feb 5 11:58:03 2009 Subject: my experience with ghci debugger extensions In-Reply-To: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> References: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Message-ID: Pepe Iborra wrote: > Hello Peter, > > Your efforts are simply outstanding. Thanks a lot for sharing your > experiences. I want to add a few comments: > > - Regarding your :logLocal, you should rename it to :stepLocal, open a > ticket, and attach your patch. We should really try to get this into > 6.10.2. > :stepLocal is broken right now, as you say it traces a lot of > garbage. I implemented it and shortly later > noticed the problem you mention, but never got around to fixing it. > Thanks for shouting. > (unless you think it makes sense to keep two versions of this > command, :logLocal and :stepLocal) > I do no think it makes sense to keep two versions (both /:steplocal/ and /:loglocal/). I'm aware the name loglocal is bad. I named it that way since it was a way for me to fill in trace log with the right stuff using /:findex/. I kind of did not really intended to release this but I noticed that there was some activity on my ghci debugger related tickets and wanted to get it out till anybody starts to code. Yeah and I'm getting limited by bugs and missing features too. Back to the /:loglocal/ and /:steplocal/. I think there should be only /:steplocal/, but I think the interface for tracing is bad. There should not be /:trace/ command at all. Instead (if the proposal with /:set trace/ is accepted (also mentioned in ticket #2946)) when /:set trace/ is set to True then /:steplocal/ would behave like now; if it is set to False it would behave like /:loglocal/. Of course setting trace to True is just a special case; in my opinion almost useless. The useful cases are when you can set it to scopes either denying them or allowing them. The idea is user should specify filter what is traced. With filter switched off nothing is traced and this case should not have any significant performance impact. When tracing filter is set up into something more complicated it may have some performance impact, but in that case we are not after speed. > - Your idea of forcing _result to implement step over is very nice. > A while ago I tried and failed at implementing :next. The conclusion > was it cannot be done without a lexical call stack. > Your idea could be useful as a pseudo :next, as long as the user of > the debugger is ok with changing the evaluation semantics of the > program. However, I don't know if there is a fix for the _result bug > at hand's reach. > As for as the /:next/ semantics. I actually do not know what it should be in a lazy language. The trick with _result is close sometimes. I could really use it. Especially in my /if/ conditions. They are often simple in my code just some simple arithmetics and record accessors. Stepping over them individually is a pain. It would be also good to step over a function containing a loop when using /:loglocal/ otherwise (so that the loop does not pollute trace log). > I look forward to playing this. > Your custom ghc tar.gz file contains an additional patch, > network.patch, but there are no instructions about it. I assume it is > ok to ignore it. > It is a patch from arch linux upstream. I do not have idea why it is there. It has license whatever arch linux has. You probably can find out more on arch-haskell mailing list. > Finallly, please do not forget to add a link to this in the GHCi > Debugger wiki page at > > http://haskell.org/haskellwiki/GHC/GHCi_debugger > > and/or at the debugging page at > > http://haskell.org/haskellwiki/Debugging > Hmmm, I do not have wiki account and cannot create it. "Create an account or log in" page has a note: "new account creation has been disabled as an anti-spam measure". So I guess it is up to somebody who has a wiki account :-D Peter. From claus.reinke at talk21.com Thu Feb 5 14:07:40 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 5 13:57:45 2009 Subject: :info features References: <20090205104954.GB5422@frogstar.lan> Message-ID: <03654C6819734D3BA4DC135B81CFE93D@cr3lt> >> :info Show -- See class definition only >> :instances Show -- See instances of Show > > If you do not want to wait till this is implemented you can do it > yourself using ghci scripting. Here's a first stab (ghci 6.8.3, using the :redir command from that tutorial), filtering out lines beginning with "instance" until indentation level returns to zero): Prelude> :{ Prelude| :def infoNoInsts \x->return $ unlines Prelude| [":redir out :info "++x Prelude| ,"let noInsts [] = []; Prelude| noInsts (l:ls) = if \"instance\" `Data.List.isPrefixOf` l Prelude| then noInsts $ dropWhile (Data.Char.isSpace . head) ls Prelude| else l:noInsts ls" Prelude| ,"putStr $ unlines $ noInsts $ lines out"] Prelude| :} Prelude> :infoNoInsts Show class Show a where showsPrec :: Int -> a -> ShowS show :: a -> String showList :: [a] -> ShowS -- Defined in GHC.Show Prelude> :infoNoInsts [] Maybe Int data [] a = [] | a : [a] -- Defined in GHC.Base data Maybe a = Nothing | Just a -- Defined in Data.Maybe data Int = GHC.Base.I# GHC.Prim.Int# -- Defined in GHC.Base > Details how to do it are in tutorial from Claus Reinke: > http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html > Understanding all the possibilities and limitations of ghci scripting > may take a day or maybe even more. But once you are done with it you can > implement your :instances command and and something like > :infoWithoutInstances withing an hour at most. And it is more > interesting that you could do much more extensions like this easily if > you need them in the future. Note that "understanding" is unlikely to mean "feel comfortable with" here:-( the quoting and scope management are rather attrocious in 'ghciscript', and as others have pointed out, my tutorial is rather short on explanations (you really need to work through the examples). It does, however, afford you the means to prototype your ghci ideas quickly, and to build yourself a library of useful definitions for working with ghci. Please remember to share any interesting ideas/code at the ghci wiki page http://www.haskell.org/haskellwiki/Ghci (once haskell wiki access is resurrected) Claus From douglas.mcclean at gmail.com Fri Feb 6 00:31:45 2009 From: douglas.mcclean at gmail.com (Douglas McClean) Date: Fri Feb 6 00:21:44 2009 Subject: Display of associated types in GHCi Message-ID: I have a question about the display of names for associated types in GHCi. I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My question has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) Am I correct that the type denoted by "Product (Matrix Two Two Integer) (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly behaves that way in more complicated expressions, which is desirable. If so, could someone explain the reason why GHCi chooses not to simplify such types for display? Could it? Is there a reason why such simplification would be undesirable (when it is possible, I understand that it wouldn't be if type variables were present)? Thanks, Doug McClean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090206/e19b9334/attachment.htm From alistair at abayley.org Fri Feb 6 04:02:40 2009 From: alistair at abayley.org (Alistair Bayley) Date: Fri Feb 6 03:52:40 2009 Subject: Pragma not recognised when wrapped in #ifdef Message-ID: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> I have this little test program: {-# LANGUAGE CPP #-} #ifdef PRAGMA_DERIVE_TYPEABLE {-# LANGUAGE DeriveDataTypeable #-} #else {-# OPTIONS -fglasgow-exts #-} #endif -- This file is Test/Fail.hs. -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail module Test.Fail where import Data.Generics data Fail = Fail deriving Typeable If compile this wih the command ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail then I get this error from ghc-6.10.1: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' I've checked the preprocessor output with -E, and that looks fine. I can compile the preprocessor output with ghc without errors. Alistair From marcot at holoscopio.com Fri Feb 6 05:27:32 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Fri Feb 6 05:17:35 2009 Subject: Error in building profiling Message-ID: <1233916052.18688.184.camel@quindinho.domain.invalid> Hello, I'm trying to package ghc-paths for debian, and I got to this: $ ./setup configure --enable-library-profiling --disable-library-vanilla Configuring ghc-paths-0.1.0.5... $ ./setup build Preprocessing library ghc-paths-0.1.0.5... Building ghc-paths-0.1.0.5... /usr/bin/ar: creating dist/build/libHSghc-paths-0.1.0.5_p.a /usr/bin/ld: dist/build/GHC/Paths.o: No such file: No such file or directory I thought this could be a problem with this package, but I've tried with mtl, and I got the same result: /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file or directory I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. I tried the same with ghc6 6.8.2dfsg1-1 and it worked. Greetings. -- marcot http://marcot.iaaeee.org/ From phunge0 at hotmail.com Fri Feb 6 09:32:03 2009 From: phunge0 at hotmail.com (Brian Bloniarz) Date: Fri Feb 6 09:22:04 2009 Subject: Display of associated types in GHCi In-Reply-To: References: Message-ID: This feature is mentioned as a todo on the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus (under "additional features"). I think it's just something that'd be nice but hasn't made it to the top of the implementers' priorities yet. The next step is probably to submit a feature request and add yourself on the CC: list (to "vote" for this feature). http://hackage.haskell.org/trac/ghc/wiki/ReportABug Thanks, Brian Bloniarz I have a question about the display of names for associated types in GHCi. I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My question has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) Am I correct that the type denoted by "Product (Matrix Two Two Integer) (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly behaves that way in more complicated expressions, which is desirable. If so, could someone explain the reason why GHCi chooses not to simplify such types for display? Could it? Is there a reason why such simplification would be undesirable (when it is possible, I understand that it wouldn't be if type variables were present)? Thanks, Doug McClean _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090206/4e11258e/attachment.htm From rturk at science.uva.nl Fri Feb 6 10:01:38 2009 From: rturk at science.uva.nl (Remi Turk) Date: Fri Feb 6 09:51:38 2009 Subject: :info features In-Reply-To: References: <20090205104954.GB5422@frogstar.lan> Message-ID: <20090206150138.GA5875@frogstar.lan> On Thu, Feb 05, 2009 at 12:35:43PM +0100, Peter Hercek wrote: > Remi Turk wrote: >> SPJ agreed with the idea itself, but suggested an alternative set of commands: >> >> :info Show -- See class definition only >> :instances Show -- See instances of Show > > Hi Remi, > > If you do not want to wait till this is implemented you can do it > yourself using ghci scripting. Thank you Peter, but in this case it won't be of much help: I am already running a patched GHCi: http://hackage.haskell.org/trac/ghc/attachment/ticket/2986/ghci-info-no-instances.patch But I may use it for something else later, so thanks anyway! Cheers, Remi From simonpj at microsoft.com Fri Feb 6 10:07:16 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 6 09:57:22 2009 Subject: my experience with ghci debugger extensions In-Reply-To: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> References: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328CA04DC6@EA-EXMSG-C334.europe.corp.microsoft.com> | Hello Peter, | | Your efforts are simply outstanding. Thanks a lot for sharing your | experiences. Seconded! Very useful stuff. That said, Simon M and I are not really focused on the debugger right now, so I'm hoping that someone (Pepe or others helping him) can follow up your suggestions. Simon From deniz.a.m.dogan at gmail.com Fri Feb 6 10:37:38 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Fri Feb 6 10:27:36 2009 Subject: Temporarily overriding Data.Generic In-Reply-To: <1233794562.26754.666.camel@localhost> References: <7b501d5c0902041511r62794910g1ab590b61bb824c@mail.gmail.com> <1233794562.26754.666.camel@localhost> Message-ID: <7b501d5c0902060737x626d08fkee477bc2cacc8805@mail.gmail.com> Hi Duncan 2009/2/5 Duncan Coutts : > On Thu, 2009-02-05 at 00:11 +0100, Deniz Dogan wrote: >> I'm currently working on "hacking" Data.Generics for my master thesis. >> I'm basically trying to find out whether it can be made any faster >> using e.g. rewrite rules. The problem I'm having is that I need an >> easy way to import my own modified version of Data.Generics (currently >> located in the same directory as my testing program) without >> unregistering or hiding syb-0.1.0.0 as base seems to depend on it. > > This should just work. If ./Data/Generics.hs exists in / relative to the > current directory then by default that overrides the module of the same > name from the syb package. There's clearly some specific problem you're > hitting, can you tell us more about it? You're right of course, it does work. I must have been so convinced it wouldn't work that I completely disregarded that GHC even told me it compiled Data.Generics and all of the other modules. That was silly! Thanks! From simonpj at microsoft.com Fri Feb 6 10:55:35 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 6 10:45:35 2009 Subject: Display of associated types in GHCi In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328CA04E58@EA-EXMSG-C334.europe.corp.microsoft.com> Douglas. Good suggestion. I believe it's already been proposed that typese are normalised (wrt type functions) before being displayed, but I can't find the ticket. Do create a feature request on Trac, with your example. Thanks! Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Douglas McClean Sent: Friday, February 06, 2009 5:32 AM To: glasgow-haskell-users@haskell.org Subject: Display of associated types in GHCi I have a question about the display of names for associated types in GHCi. I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My question has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) Am I correct that the type denoted by "Product (Matrix Two Two Integer) (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly behaves that way in more complicated expressions, which is desirable. If so, could someone explain the reason why GHCi chooses not to simplify such types for display? Could it? Is there a reason why such simplification would be undesirable (when it is possible, I understand that it wouldn't be if type variables were present)? Thanks, Doug McClean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090206/e3aae0d5/attachment.htm From marlowsd at gmail.com Fri Feb 6 11:09:13 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Feb 6 10:59:26 2009 Subject: my experience with ghci debugger extensions In-Reply-To: References: Message-ID: <498C60A9.1030409@gmail.com> Hi Peter, Thanks very much for all the suggestions here. As Simon mentioned, we're not actively working on the debugger, and speaking for myself I don't plan to invest significant effort in it in the near future (too many things to do!). If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Peter Hercek wrote: > /:next/ is an idea how to implement a kind of step over. That is if by > step over you mean something else than steplocal. The non-lazy form of > /:next/ forces _result and does a /:step/. The lazy form forces only the > top level constructor of _result before the step. Hey, I even had a case > when it worked just like I expected. But typically it does not work > because of bug #1531. _result is not correctly bound to the result of > selected expression in most of the practical cases. This bug is also > critical for all the forms of conditional breakpoints. It would be cool > if we could specify the condition based on _result or some part of it. > The implementation of ghciExt conditional breakpoints would need to be > extended to support conditions on _result (in particular the breakpoint > would need to be disabled during the condition execution) but that is > easy to do. Even more worrying thing about bug #1531 is that it has the > milestone set to _|_. So #1531 is tricky to fix, unfortunately. The implementation of _result is a bit of a hack in the first place. The fundamental problem is that a tick expression looks like this case tick of _ -> e where 'e' is not necessarily exactly the same as the expression that was originally inside the tick. We are careful to maintian the property that the tick is evaluated iff the original expression is evaluated, but that's all. _result is bound to e, which may or may not be what you wanted. One way to fix it would be to add extra constraints on what the simplifier can do with tick expressions. I don't like the sound of that because (a) I doni't know exactly what restrictions we'd have to add and (b) this amounts to changing the semantics of Core (i.e. changing which transformations are valid). Maybe there's another way to fix it, but I can't think of one right now. Cheers, Simon From douglas.mcclean at gmail.com Fri Feb 6 12:20:43 2009 From: douglas.mcclean at gmail.com (Douglas McClean) Date: Fri Feb 6 12:11:26 2009 Subject: Display of associated types in GHCi In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328CA04E58@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C3328CA04E58@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Thanks Brian and Simon. In case anyone is interested, this is now ticket 3005. -Doug McClean On Fri, Feb 6, 2009 at 10:55 AM, Simon Peyton-Jones wrote: > Douglas. > > > > Good suggestion. I believe it's already been proposed that typese are > normalised (wrt type functions) before being displayed, but I can't find the > ticket. Do create a feature request on Trac, with your example. Thanks! > > > > Simon > > > > *From:* glasgow-haskell-users-bounces@haskell.org [mailto: > glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Douglas McClean > *Sent:* Friday, February 06, 2009 5:32 AM > *To:* glasgow-haskell-users@haskell.org > *Subject:* Display of associated types in GHCi > > > > I have a question about the display of names for associated types in GHCi. > > I have a module with a matrix type constructor: > > > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) > > which uses type-level naturals to provide dimension checking. > > A type class for multiplication: > > > class Multiply a b where > > type Product a b > > times :: a -> b -> Product a b > > and an instance for matrix multiplication: > > > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b > t) (Matrix b c t) where > > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > > times m1 m2 = ... > > All of this works really well, I get dimension checking (and inference), > and lot of other goodies. > > My question has to do with the following GHCi session: > > *Main> let a = matrix two two [[1,1],[2,6]] > *Main> :t a > a :: Matrix Two Two Integer > *Main> :t a `times` a > a `times` a :: Product > (Matrix Two Two Integer) (Matrix Two Two Integer) > > Am I correct that the type denoted by "Product (Matrix Two Two Integer) > (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly > behaves that way in more complicated expressions, which is desirable. > > If so, could someone explain the reason why GHCi chooses not to simplify > such types for display? Could it? Is there a reason why such simplification > would be undesirable (when it is possible, I understand that it wouldn't be > if type variables were present)? > > Thanks, > Doug McClean > -- J. Douglas McClean (781) 561-5540 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090206/eb5bac95/attachment-0001.htm From allbery at ece.cmu.edu Sat Feb 7 00:39:03 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Feb 7 00:29:02 2009 Subject: :info features In-Reply-To: <20090205104954.GB5422@frogstar.lan> References: <20090205104954.GB5422@frogstar.lan> Message-ID: On 2009 Feb 5, at 5:49, Remi Turk wrote: > SPJ agreed with the idea itself, but suggested an alternative set of > commands: > > :info Show -- See class definition only > :instances Show -- See instances of Show (...) > However, it would make ":i" ambiguous, which is rather sad. :class Show -- unique prefix :cl, already many such collisions :instance Show -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090207/1b6d37d1/PGP.bin From g9ks157k at acme.softbase.org Mon Feb 9 07:53:22 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 9 07:43:17 2009 Subject: length of module name affecting performance?? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33286D93BEC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <638ABD0A29C8884A91BC5FB5C349B1C33286D93BEC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200902091353.22581.g9ks157k@acme.softbase.org> Am Montag, 29. Dezember 2008 12:54 schrieb Simon Peyton-Jones: > What a great bug -- I would never have predicted it, but in retrospect it > makes perfect sense. Record selectors had better get fixed. Can I read somewhere about what caused this bug? What is its trac URL? Best wishes, Wolfgang From rturk at science.uva.nl Mon Feb 9 11:10:48 2009 From: rturk at science.uva.nl (Remi Turk) Date: Mon Feb 9 11:00:44 2009 Subject: :info features In-Reply-To: References: <20090205104954.GB5422@frogstar.lan> Message-ID: <20090209161048.GA5867@frogstar.lan> On Sat, Feb 07, 2009 at 12:39:03AM -0500, Brandon S. Allbery KF8NH wrote: > On 2009 Feb 5, at 5:49, Remi Turk wrote: >> SPJ agreed with the idea itself, but suggested an alternative set of >> commands: >> >> :info Show -- See class definition only >> :instances Show -- See instances of Show > (...) >> However, it would make ":i" ambiguous, which is rather sad. > > :class Show -- unique prefix :cl, already many such collisions > :instance Show That could work, but then how to get information about types as opposed to classes? Its not in the above example, but "Show" actually stands for an arbitrary typeclass _or type_. However, as igloo pointed out on the ticket, abbreviations don't actually have to be unique: "For example, :b means :break even though we also have :back, :browse and :browse!. " [1] That would personally lead me to prefer the :info/:instances combo, with :i as an abbreviation of :info. Groeten, Remi [1] http://hackage.haskell.org/trac/ghc/ticket/2986#comment:4 From dgorin at dc.uba.ar Mon Feb 9 11:52:27 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Mon Feb 9 11:42:25 2009 Subject: length of module name affecting performance?? In-Reply-To: <200902091353.22581.g9ks157k@acme.softbase.org> References: <3A2E7F1F-B236-421A-A36E-516EEAEA9762@dc.uba.ar> <638ABD0A29C8884A91BC5FB5C349B1C33286D93BEC@EA-EXMSG-C334.europe.corp.microsoft.com> <200902091353.22581.g9ks157k@acme.softbase.org> Message-ID: <12F75701-14FD-4D61-92DA-D5ED1EF56F4F@dc.uba.ar> http://hackage.haskell.org/trac/ghc/ticket/2884 On Feb 9, 2009, at 10:53 AM, Wolfgang Jeltsch wrote: > Am Montag, 29. Dezember 2008 12:54 schrieb Simon Peyton-Jones: >> What a great bug -- I would never have predicted it, but in >> retrospect it >> makes perfect sense. Record selectors had better get fixed. > > Can I read somewhere about what caused this bug? What is its trac URL? > > Best wishes, > Wolfgang > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090209/ed5bdb46/attachment.htm From phercek at gmail.com Mon Feb 9 14:16:48 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Feb 9 14:06:44 2009 Subject: my experience with ghci debugger extensions In-Reply-To: <498C60A9.1030409@gmail.com> References: <498C60A9.1030409@gmail.com> Message-ID: <49908120.2040005@gmail.com> Hi Simon, Simon Marlow wrote: > If you felt like working on this yourself, possibly with Pepe, then > we'd be happy to support in any way we can. Thanks. It may happen though it is not probable. I do not know the code so anything non-trivial is a significant effort and my free weekends and evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? > So #1531 is tricky to fix, unfortunately. The implementation of > _result is a bit of a hack in the first place. The fundamental > problem is that a tick expression looks like this > > case tick of > _ -> e > > where 'e' is not necessarily exactly the same as the expression that > was originally inside the tick. We are careful to maintian the > property that the tick is evaluated iff the original expression is > evaluated, but that's all. _result is bound to e, which may or may > not be what you wanted. > > One way to fix it would be to add extra constraints on what the > simplifier can do with tick expressions. I don't like the sound of > that because (a) I doni't know exactly what restrictions we'd have to > add and (b) this amounts to changing the semantics of Core (i.e. > changing which transformations are valid). Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: "If you do not understand why ghci debugger is limited in such a strange way read this." A breakpoint condition on _result: My guess is that in about half of the cases I can just put them on a free variable on some other location just as comfortably. In other cases I'm out of luck :) As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) > Maybe there's another way to fix it, but I can't think of one right now. If by simplifier you did not mean straight translation to core, then I assume you wanted to try to just skip over all the optimizations (simplifications?). Was it hard to do it or was the performance impact so bad that it was not worth the addition of a command line switch? Thanks for reading the post about debugging, now there is at least a chance that it will be better once. Peter. From mnislaih at gmail.com Mon Feb 9 15:12:57 2009 From: mnislaih at gmail.com (pepe) Date: Mon Feb 9 15:02:51 2009 Subject: my experience with ghci debugger extensions In-Reply-To: <49908120.2040005@gmail.com> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> Message-ID: <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> Hi, > > Simon Marlow wrote: >> If you felt like working on this yourself, possibly with Pepe, then >> we'd be happy to support in any way we can. > Thanks. It may happen though it is not probable. I do not know the > code so anything non-trivial is a significant effort and my free > weekends and evenings are sparse :-( > If I would do anything, should it be posted here, sent to Pepe, or > attached to the ticket? > Is it a habit to indicate in the ticket that somebody started coding > it actually (especially if it takes longer to implement)? > Peter, it is best if you attach everything to the ticket. If you want to signal that you started coding on a ticket, just take ownership of it. > As for as /:next/ command: > Like Pepe indicated, I do not have idea how to do it without working > _result and without dynamic stack. Though dynamic stack should not > be that hard since how otherwise could profiler count ticks for > cost centers. > And dynamic stack would be great. It would create new options where > to store lists of free variables of selected expressions :) Having (a kind of messy approximation of) a dynamic stack is possible with a variant of the cost center stacks mechanism used for profiling. But the downside is that code and libraries would need to be compiled for debugging. Nevertheless, I believe that having a true dynamic stack would make debugging so much simpler. > Ok, I did not understand this part a bit till I did not skim over > http://www.haskell.org/~simonmar/papers/ghci-debug.pdf > Maybe that paper should be mentioned on the wiki pages about > debugger. Something like: "If you do not understand why ghci > debugger is limited in such a strange way read this." Debugging for lazy functional languages is a hard problem. The GHCi debugger is no panacea. But you are right in that the current state of things can be improved in several ways. However, the Simons have already enough things in their hands; it is up to us to step forward and help. Unfortunately, my time is also very limited, as I am trying to get a degree here. I am happy to support Peter and anyone else who wants to hack on the debugger, and I will continue maintaining the code around :print. But right now I don't think I can find the time to work on the tickets brought up in this discussion. Cheers, pepe From catamorphism at gmail.com Mon Feb 9 15:16:22 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Feb 9 15:06:10 2009 Subject: How bad is the PowerPC backend? Message-ID: <4683d9370902091216v7762c148kf0ca9d3be70b0516@mail.gmail.com> Hello, For obscure reasons, I'm running some benchmarks both on an x86 machine (2.20 Ghz, 2 GB of RAM, Linux 2.6.22-15) and on a PowerPC Mac (1 Ghz, 512 MB of RAM, Mac OS 10.5). I noticed that even some pretty simple programs run much slower on the Mac than on the PC. For example, the following program (edited down from the "life" nofib benchmark): ------------------------------------------------- limit xs = go [] xs go acc (x:y:xs) | x==y = acc ++ [x] | otherwise = go (acc ++ [x]) (y:xs) go acc [x] = acc ++ [x] go acc [] = error "limit" main = print (length (limit (iterate (\ x -> if x == 10000 then x else (x+1)) 1))) --------------------------------------------------- runs in about 1.5 seconds on the PC, and 14 seconds on the Mac. This is with ghc -O2, version 6.10.1. The numbers are about the same on either machine whether I use -fvia-C or -fasm. The Mac does have a lot less RAM, but I can see that the program isn't swapping. So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I don't like your I-can-use-anything-as-an-adjective attitude." -- Larry Wall From bulat.ziganshin at gmail.com Mon Feb 9 15:27:04 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 9 15:17:08 2009 Subject: How bad is the PowerPC backend? In-Reply-To: <4683d9370902091216v7762c148kf0ca9d3be70b0516@mail.gmail.com> References: <4683d9370902091216v7762c148kf0ca9d3be70b0516@mail.gmail.com> Message-ID: <952900158.20090209232704@gmail.com> Hello Tim, Monday, February 9, 2009, 11:16:22 PM, you wrote: > So is the PPC backend really this bad, or should I be looking for > something weird with the hardware or configuration on the Mac? check GC times too. one possibility is that GC takes much more time due to smaller L2 cache -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From catamorphism at gmail.com Mon Feb 9 16:11:25 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Feb 9 16:01:13 2009 Subject: How bad is the PowerPC backend? In-Reply-To: <952900158.20090209232704@gmail.com> References: <4683d9370902091216v7762c148kf0ca9d3be70b0516@mail.gmail.com> <952900158.20090209232704@gmail.com> Message-ID: <4683d9370902091311oaf80fb7o269afd4584b55072@mail.gmail.com> On 2/9/09, Bulat Ziganshin wrote: > Hello Tim, > > > Monday, February 9, 2009, 11:16:22 PM, you wrote: > > > So is the PPC backend really this bad, or should I be looking for > > something weird with the hardware or configuration on the Mac? > > > check GC times too. one possibility is that GC takes much more time > due to smaller L2 cache > Hmm, doesn't seem to be happening with this example. On the Mac, I get (running with +RTS -s -RTS): 11.86 MUT time (13.95s elapsed) 0.08s GC time (0.15s elapsed) %GC time 0.6% (1.1% elapsed) and on the PC: 1.07s MUT time (1.34s elapsed) 0.01s GC time (0.02s elapsed) %GC time 1.1% (1.6% elapsed) so GC doesn't seem to explain the large difference in running times. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Maybe I don't want to meet someone who shares my interests. I hate my interests." -- Ghost World From catamorphism at gmail.com Mon Feb 9 22:13:42 2009 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Feb 9 22:03:29 2009 Subject: How bad is the PowerPC backend? In-Reply-To: <20090210003540.GA23963@linode.davidb.org> References: <4683d9370902091216v7762c148kf0ca9d3be70b0516@mail.gmail.com> <20090210003540.GA23963@linode.davidb.org> Message-ID: <4683d9370902091913r6c54eef1k3496ca6b604ae3e3@mail.gmail.com> On 2/9/09, David Brown wrote: > > Which CPU is the x86? The modern x86 CPUs (such as Core2) will be > significantly faster than the PowerPC, even at comparable clock rates. > Have you just compared even C code tests? > I think that goes a long way towards explaining it... a simple C loop that I tried runs for 4.5s on the PC and 30s on the Mac. So probably this isn't GHC's fault. Thanks for the suggestion. Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "In fact, a sense of essence is, in essence, the essence of sense, in effect." -- Douglas Hofstadter From mka19 at hw.ac.uk Tue Feb 10 06:49:35 2009 From: mka19 at hw.ac.uk (Aswad, Mustafa K) Date: Tue Feb 10 06:42:17 2009 Subject: Byte in list Message-ID: <9D12E3B7122E214F92BE5E82ABACAC460287AFE5@ex5.mail.win.hw.ac.uk> Hi dear I need to calculate the size of alist consist of n element (("I(a*b)" , "I(b) , I(a)") in 32 bit machine ? -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090210/c8de3b56/attachment.htm From alistair at abayley.org Tue Feb 10 07:02:34 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 10 06:52:21 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> Message-ID: <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> > {-# LANGUAGE CPP #-} > #ifdef PRAGMA_DERIVE_TYPEABLE > {-# LANGUAGE DeriveDataTypeable #-} > #else > {-# OPTIONS -fglasgow-exts #-} > #endif > -- This file is Test/Fail.hs. > -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail > module Test.Fail where > import Data.Generics > data Fail = Fail deriving Typeable > > If compile this wih the command > ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail > then I get this error from ghc-6.10.1: > > [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) > > Test\Fail.hs:11:26: > Can't make a derived instance of `Typeable Fail' > (You need -XDeriveDataTypeable to derive an instance for this class) > In the data type declaration for `Fail' No response. I'd like to know if this is a bug (that's what it looks like to me), or just a mistake I've made. Thanks, Alistair From simonpj at microsoft.com Tue Feb 10 08:20:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 10 08:10:26 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> I'm guessing a bit here, but it looks as if you intend this: * GHC should read Foo.hs, and see {-# LANGUAGE CPP #-} * Then it should run cpp * Then it should look *again* in the result of running cpp, to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-} I'm pretty sure we don't do that; that is, we get the command-line flags once for all from the pre-cpp'd source code. Simon or Ian may be able to confirm. If so, then this amounts to a) a documentation bug: it should be clear what GHC does b) a feature request, to somehow allow cpp to affect in-file flags I'm not sure what the spec would be Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Alistair Bayley | Sent: Tuesday, February 10, 2009 12:03 PM | To: GHC Users Mailing List | Subject: Re: Pragma not recognised when wrapped in #ifdef | | > {-# LANGUAGE CPP #-} | > #ifdef PRAGMA_DERIVE_TYPEABLE | > {-# LANGUAGE DeriveDataTypeable #-} | > #else | > {-# OPTIONS -fglasgow-exts #-} | > #endif | > -- This file is Test/Fail.hs. | > -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail | > module Test.Fail where | > import Data.Generics | > data Fail = Fail deriving Typeable | > | > If compile this wih the command | > ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail | > then I get this error from ghc-6.10.1: | > | > [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) | > | > Test\Fail.hs:11:26: | > Can't make a derived instance of `Typeable Fail' | > (You need -XDeriveDataTypeable to derive an instance for this class) | > In the data type declaration for `Fail' | | | No response. I'd like to know if this is a bug (that's what it looks | like to me), or just a mistake I've made. | | Thanks, | Alistair | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Tue Feb 10 08:31:24 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 10 08:21:16 2009 Subject: :info features In-Reply-To: <20090209161048.GA5867@frogstar.lan> References: <20090205104954.GB5422@frogstar.lan> <20090209161048.GA5867@frogstar.lan> Message-ID: <499181AC.9030403@gmail.com> Remi Turk wrote: > On Sat, Feb 07, 2009 at 12:39:03AM -0500, Brandon S. Allbery KF8NH wrote: >> On 2009 Feb 5, at 5:49, Remi Turk wrote: >>> SPJ agreed with the idea itself, but suggested an alternative set of >>> commands: >>> >>> :info Show -- See class definition only >>> :instances Show -- See instances of Show >> (...) >>> However, it would make ":i" ambiguous, which is rather sad. >> :class Show -- unique prefix :cl, already many such collisions >> :instance Show > > That could work, but then how to get information about types as > opposed to classes? Its not in the above example, but "Show" > actually stands for an arbitrary typeclass _or type_. > > However, as igloo pointed out on the ticket, abbreviations don't > actually have to be unique: > > "For example, :b means :break even though we also have :back, :browse and :browse!. " [1] > > That would personally lead me to prefer the :info/:instances > combo, with :i as an abbreviation of :info. My vote would be: :info class Show :info type Show :info instance Show where :info Show displays information about everything called "Show" I know that classes and types share the same namespace currently, but it might not always be so. Cheers, Simon From marlowsd at gmail.com Tue Feb 10 08:43:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 10 08:33:23 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49918484.1060705@gmail.com> Simon Peyton-Jones wrote: > I'm guessing a bit here, but it looks as if you intend this: > > * GHC should read Foo.hs, and see {-# LANGUAGE CPP #-} > * Then it should run cpp > * Then it should look *again* in the result of running cpp, > to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-} > > I'm pretty sure we don't do that; that is, we get the command-line flags once for all from the pre-cpp'd source code. Simon or Ian may be able to confirm. Spot on. > If so, then this amounts to > a) a documentation bug: it should be clear what GHC does Right, I checked the docs and it doesn't explicitly say this. > b) a feature request, to somehow allow cpp to affect in-file flags > I'm not sure what the spec would be It needs a bit of thought - what should happen to pragmas that are there pre-CPP but not post-CPP, for example? Cheers, Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Alistair Bayley > | Sent: Tuesday, February 10, 2009 12:03 PM > | To: GHC Users Mailing List > | Subject: Re: Pragma not recognised when wrapped in #ifdef > | > | > {-# LANGUAGE CPP #-} > | > #ifdef PRAGMA_DERIVE_TYPEABLE > | > {-# LANGUAGE DeriveDataTypeable #-} > | > #else > | > {-# OPTIONS -fglasgow-exts #-} > | > #endif > | > -- This file is Test/Fail.hs. > | > -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail > | > module Test.Fail where > | > import Data.Generics > | > data Fail = Fail deriving Typeable > | > > | > If compile this wih the command > | > ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail > | > then I get this error from ghc-6.10.1: > | > > | > [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) > | > > | > Test\Fail.hs:11:26: > | > Can't make a derived instance of `Typeable Fail' > | > (You need -XDeriveDataTypeable to derive an instance for this class) > | > In the data type declaration for `Fail' > | > | > | No response. I'd like to know if this is a bug (that's what it looks > | like to me), or just a mistake I've made. > | > | Thanks, > | Alistair > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From alistair at abayley.org Tue Feb 10 08:55:11 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 10 08:44:58 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> 2009/2/10 Simon Peyton-Jones : > I'm guessing a bit here, but it looks as if you intend this: > > * GHC should read Foo.hs, and see {-# LANGUAGE CPP #-} > * Then it should run cpp > * Then it should look *again* in the result of running cpp, > to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-} > > I'm pretty sure we don't do that; that is, we get the command-line flags once for all from the pre-cpp'd source code. Simon or Ian may be able to confirm. > > If so, then this amounts to > a) a documentation bug: it should be clear what GHC does > b) a feature request, to somehow allow cpp to affect in-file flags > I'm not sure what the spec would be I see. So ghc will scan the source initially for pragmas, and add any it finds as command-line flags. Having done that, it then proceeds through the normal processing pipeline. I had assumed (from the manual section 5.4.3) that the pipeline was this: - unlit - cpp - haskell compiler - c compiler (defunct?) - assembler - linker and I also assumed that the pragmas would be parsed by the haskell compiler i.e. post unlit and cpp. It hadn't occured to me that this implementation would make the CPP pragma redundant... and the implications thereof. I'd love (b), but will settle for (a) for now. I was trying to use cpp to switch between the DeriveDataTypeable pragma for 6.10, and glasgow-exts for 6.8 and 6.6. I've decided to push this out to the cabal file instead, so I guess I don't have this problem any more, but it was a bit puzzling. Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems to be the only one that affects/involves preprocessor(s). AFAICT, the others all affect the haskell compiler stage. Alistair From igloo at earth.li Tue Feb 10 11:42:39 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 10 11:32:28 2009 Subject: Plans for GHC 6.10.2 Message-ID: <20090210164239.GA7918@matrix.chaos.earth.li> Hi all, This is just a quick summary of our plans for GHC 6.10.2. While it is possible that we will fix some others, for the 6.10.2 release we mainly intend to look at the high-priority bugs in the 6.10.2 milestone. They are listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&priority=high&priority=highest&milestone=6.10.2&order=priority If there is a bug not in that list that is causing you major problems, then please let us know. We expect to have a release candidate ready around the end of next week. Thanks Ian From igloo at earth.li Tue Feb 10 12:15:45 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 10 12:05:31 2009 Subject: hsc2hs and HsFFI.h Message-ID: <20090210171545.GA8269@matrix.chaos.earth.li> Hi all, Currently, hsc2hs (as shipped with GHC) cannot be used with just hsc2hs Foo.hsc as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897). To make it work you need to run something like hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc (it also works when called by Cabal, as Cabal passes it this flag automatically). However, we would like to have it work without needing to use any special flags, and without having to use it from within a Cabal package. The obvious solution to this problem would seem to be to put HsFFI.h in /usr/lib/hsc2hs/include and have hsc2hs automatically add that to the include path. However, hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't a compiler-independent header file; for example, GHC's implementation defines HsInt to be a 64-bit integer type on amd64, whereas hugs's implementation defines it to be a 32-bit type. We therefore need a different HsFFI.h depending on which compiler we are using. One option would be to have hsc2hs (when installed with GHC) append "-I /usr/lib/ghc-6.10.1/include" to the commandline. If the user gives a "-I /usr/lib/hugs/include" flag then this path will be looked at first, and the hugs HsFFI.h will be used. Another option would be for the user to tell hsc2hs which compiler they're using, e.g. hsc2hs --compiler=/usr/bin/ghc Foo.hsc (this "compiler" is distinct from the C compiler that hsc2hs will use). hsc2hs will then pass the appropriate -I flag, depending on what sort of compiler it is told to use. The hsc2hs that comes with GHC would probably default to using the GHC that it is installed with, but standalone hsc2hs would probably default to searching for /usr/bin/ghc, /usr/bin/hugs, etc. This last approach would also make it possible for hsc2hs to take "-package foo" flags, and add the include paths for the requested packages too. The downside is that it's pushing a lot more knowledge into hsc2hs, which means there is one more thing to keep in sync. Has anyone got any other alternatives to consider? Or opinions on which solution is best? Thanks Ian From simonpj at microsoft.com Tue Feb 10 12:41:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 10 12:31:37 2009 Subject: Plans for GHC 6.10.2 In-Reply-To: <20090210164239.GA7918@matrix.chaos.earth.li> References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399201188@EA-EXMSG-C334.europe.corp.microsoft.com> Friends | While it is possible that we will fix some others, for the 6.10.2 | release we mainly intend to look at the high-priority bugs in the 6.10.2 | milestone. They are listed here: | | http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened | &priority=high&priority=highest&milestone=6.10.2&order=priority | | If there is a bug not in that list that is causing you major problems, | then please let us know. Better still, if you felt able to help us by actually fixing some of the 65+ other bugs recorded against 6.10.2 that would be fantastic! Look here http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.10.2&order=priority Many are minor, many are probably quick to fix. What a great way to spend a happy afternoon, get your name in lights, and help your colleagues! Simon From sof at galois.com Tue Feb 10 14:02:18 2009 From: sof at galois.com (Sigbjorn Finne) Date: Tue Feb 10 13:52:07 2009 Subject: hsc2hs and HsFFI.h In-Reply-To: <20090210171545.GA8269@matrix.chaos.earth.li> References: <20090210171545.GA8269@matrix.chaos.earth.li> Message-ID: <4991CF3A.2010608@galois.com> Hi Ian, it may encompass some of your suggested approaches below, but have you considered either: - add "--print-hsc-options" to the GHC driver, which is akin to "--print-libdir". A ghc-installed hsc2hs shell wrapper or as you suggest have 'hsc2hs' probe the compiler it is using would then build on this. - have the GHC driver handle .hsc input by invoking 'hsc2hs' with the necessary local context. I can see the value of not doing the latter (it already handles too many kinds of input files) and would add to GHC's workload. But thought I'd put it on the table at least.. Q: is the information that --print-libdir returns available programmatically to Haskell code? --sigbjorn Ian Lynagh wrote: > Hi all, > > Currently, hsc2hs (as shipped with GHC) cannot be used with just > hsc2hs Foo.hsc > as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897). > To make it work you need to run something like > hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc > (it also works when called by Cabal, as Cabal passes it this flag > automatically). However, we would like to have it work without needing > to use any special flags, and without having to use it from within a > Cabal package. > > The obvious solution to this problem would seem to be to put HsFFI.h in > /usr/lib/hsc2hs/include > and have hsc2hs automatically add that to the include path. However, > hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't > a compiler-independent header file; for example, GHC's implementation > defines HsInt to be a 64-bit integer type on amd64, whereas hugs's > implementation defines it to be a 32-bit type. We therefore need a > different HsFFI.h depending on which compiler we are using. > > One option would be to have hsc2hs (when installed with GHC) append > "-I /usr/lib/ghc-6.10.1/include" to the commandline. If the user gives a > "-I /usr/lib/hugs/include" flag then this path will be looked at first, > and the hugs HsFFI.h will be used. > > Another option would be for the user to tell hsc2hs which compiler > they're using, e.g. > hsc2hs --compiler=/usr/bin/ghc Foo.hsc > (this "compiler" is distinct from the C compiler that hsc2hs will use). > hsc2hs will then pass the appropriate -I flag, depending on what sort of > compiler it is told to use. The hsc2hs that comes with GHC would > probably default to using the GHC that it is installed with, but > standalone hsc2hs would probably default to searching for /usr/bin/ghc, > /usr/bin/hugs, etc. > > This last approach would also make it possible for hsc2hs to take > "-package foo" flags, and add the include paths for the requested > packages too. > > The downside is that it's pushing a lot more knowledge into hsc2hs, > which means there is one more thing to keep in sync. > > > Has anyone got any other alternatives to consider? Or opinions on which > solution is best? > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From allbery at ece.cmu.edu Tue Feb 10 14:52:28 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Feb 10 14:42:26 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> Message-ID: <468C9044-990F-4877-B7EA-36064DF46429@ece.cmu.edu> On 2009 Feb 10, at 8:55, Alistair Bayley wrote: > Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems > to be the only one that affects/involves preprocessor(s). AFAICT, the > others all affect the haskell compiler stage. Or require the CPP pragma to be the first thing in the file, immediately triggering cpp and a reread. This means > #if 0 > {-# LANGUAGE CPP #-} > #endif is ambiguous, but I think it could be argued that the programmer has asked for _|_ and any behavior is acceptable. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090210/65020e59/PGP.bin From claus.reinke at talk21.com Tue Feb 10 14:19:53 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Feb 10 16:42:08 2009 Subject: Plans for GHC 6.10.2 References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: > This is just a quick summary of our plans for GHC 6.10.2. >.. > If there is a bug not in that list that is causing you major problems, > then please let us know. Hi Ian, I noticed that http://hackage.haskell.org/trac/ghc/ticket/1502 keeps getting pushed back (now 2 years old!). Perhaps the summary is misleading, because the comments make it clear that the issue is one of "normalizing" the mingw layout in GHC's copy. If the layout simply followed the standard mingw layout - just omitting parts, instead of also restructuring the parts that are copied in, that would make it easier for other tools/users. - special cases in cabal/etc could disappear - mingw could be upgraded separately - existing mingw could be used - no surprise bugs due to unusual layout (picking up wrong tools) It isn't causing me personally any problems right now, but this looks like a straightforward simplification - delaying of which causes unnecessary pressure elsewhere. It would also be nice to move to the standard layout before any Haskell Platform releases start relying on the current mess. Anything that makes Windows less of a special case ought to help, no?-) Claus Ps. It is surprising that performance bugs don't get high priority, now that distractions like extralibs are out of the ghc picture? From claus.reinke at talk21.com Tue Feb 10 16:52:13 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Feb 10 16:42:09 2009 Subject: hsc2hs and HsFFI.h References: <20090210171545.GA8269@matrix.chaos.earth.li> <4991CF3A.2010608@galois.com> Message-ID: > Q: is the information that --print-libdir returns available programmatically > to Haskell code? $ ghc --print-libdir C:\ghc\ghc-6.11.20090118 $ ghc -e GHC.Paths.libdir "C:\\ghc\\ghc-6.11.20090118" $ ghc -e ':browse GHC.Paths' docdir :: FilePath ghc :: FilePath ghc_pkg :: FilePath libdir :: FilePath $ ghc-pkg find-module GHC.Paths c:/ghc/ghc-6.11.20090118\package.conf: ghc-paths-0.1.0.5 Claus From igloo at earth.li Tue Feb 10 19:12:55 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 10 19:02:39 2009 Subject: Plans for GHC 6.10.2 In-Reply-To: References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: <20090211001254.GA12036@matrix.chaos.earth.li> On Tue, Feb 10, 2009 at 07:19:53PM -0000, Claus Reinke wrote: > > I noticed that http://hackage.haskell.org/trac/ghc/ticket/1502 > keeps getting pushed back (now 2 years old!). We'll do this for the new build system, as we need to rewrite the code to put gcc etc in the right place anyway. Thanks Ian From chak at cse.unsw.edu.au Tue Feb 10 19:32:15 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 10 19:22:02 2009 Subject: Plans for GHC 6.10.2 In-Reply-To: <20090210164239.GA7918@matrix.chaos.earth.li> References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: <7B0875D4-47E5-43F4-B584-54D8210FEB61@cse.unsw.edu.au> Ian wrote, > This is just a quick summary of our plans for GHC 6.10.2. > > > While it is possible that we will fix some others, for the 6.10.2 > release we mainly intend to look at the high-priority bugs in the > 6.10.2 > milestone. They are listed here: > > http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&priority=high&priority=highest&milestone=6.10.2&order=priority #2658 really needs input from the reporter (see my last comment on the ticket). Manuel From simonpj at microsoft.com Wed Feb 11 03:42:30 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 11 03:32:14 2009 Subject: Plans for GHC 6.10.2 In-Reply-To: References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C333992012EE@EA-EXMSG-C334.europe.corp.microsoft.com> | Ps. It is surprising that performance bugs don't get high | priority, now that distractions like extralibs are out of the | ghc picture? Generally we prioritise bugs that appear to be show-stoppers, and/or are on a tier-1 platform. Having extralibs out of the way is a help, but as you'll see if you follow the link, we typically have a factor of 10 more tickets than we can deal with, at least unless more people join in, an outcome devoutly to be espoused. I believe that many are minor and could well be done by others -- but each requires reproduction, investigation, design, test case etc. I wish we could work faster, but there we are. Of course we want to focus the time we have on the tickets that are most significant to our users. If there is a particular ticket, performance or otherwise, that is particularly important to you, make sure you add a comment to explain that it's important and why; and add yourself to the cc list. http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.10.2&order=priority Simon From simonpj at microsoft.com Wed Feb 11 04:01:17 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 11 03:51:43 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3339920131E@EA-EXMSG-C334.europe.corp.microsoft.com> | Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems | to be the only one that affects/involves preprocessor(s). AFAICT, the | others all affect the haskell compiler stage. Yes, it does seem anomalous. I suppose the motivation is that some modules might need CPP and some not, and it's convenient for the module itself to announce that fact. Simon From colinpauladams at googlemail.com Wed Feb 11 04:06:09 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Wed Feb 11 03:55:54 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3339920131E@EA-EXMSG-C334.europe.corp.microsoft.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3339920131E@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1afdeaec0902110106g1720d1edxb518bbeda4e63150@mail.gmail.com> Is there still a need for CPP now that Template Haskell exists? 2009/2/11 Simon Peyton-Jones : > | Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems > | to be the only one that affects/involves preprocessor(s). AFAICT, the > | others all affect the haskell compiler stage. > > Yes, it does seem anomalous. I suppose the motivation is that some modules might need CPP and some not, and it's convenient for the module itself to announce that fact. > > Simon > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From ndmitchell at gmail.com Wed Feb 11 04:11:15 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 11 04:01:01 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <1afdeaec0902110106g1720d1edxb518bbeda4e63150@mail.gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> <79d7c4980902100555x34931d3bla6daf96d40322025@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3339920131E@EA-EXMSG-C334.europe.corp.microsoft.com> <1afdeaec0902110106g1720d1edxb518bbeda4e63150@mail.gmail.com> Message-ID: <404396ef0902110111v21579539s811de30d9d7ca4fd@mail.gmail.com> Hi > Is there still a need for CPP now that Template Haskell exists? Yes. For a start you might need CPP to switch between Haskell compilers that do and don't support Template Haskell! Both technologies do different things, CPP is great for conditional compilation based on compiler version/features - i.e. using either deriving (Eq) or deriving (Data,Typeable,Eq) where the latter is supported. Also for doing imports which have changed between versions, i.e. import Data.Data or Data.Generics depending on version. Using the CPP textual replacement/macro substitution facilities is more debatable, and in many of these cases Template Haskell is a better choice. Thanks Neil > > 2009/2/11 Simon Peyton-Jones : >> | Perhaps CPP shouldn't be a pragma, just a command-line flag? It seems >> | to be the only one that affects/involves preprocessor(s). AFAICT, the >> | others all affect the haskell compiler stage. >> >> Yes, it does seem anomalous. I suppose the motivation is that some modules might need CPP and some not, and it's convenient for the module itself to announce that fact. >> >> Simon >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From duncan.coutts at worc.ox.ac.uk Wed Feb 11 05:37:05 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 11 05:27:05 2009 Subject: Pragma not recognised when wrapped in #ifdef In-Reply-To: <49918484.1060705@gmail.com> References: <79d7c4980902060102j30c60ft63f9663f21e673c7@mail.gmail.com> <79d7c4980902100402q7a01b06cs4f4fcb3c1ec724fd@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33398DC9BEB@EA-EXMSG-C334.europe.corp.microsoft.com> <49918484.1060705@gmail.com> Message-ID: <1234348625.5238.240.camel@localhost> On Tue, 2009-02-10 at 13:43 +0000, Simon Marlow wrote: > Simon Peyton-Jones wrote: > > I'm guessing a bit here, but it looks as if you intend this: > > > > * GHC should read Foo.hs, and see {-# LANGUAGE CPP #-} > > * Then it should run cpp > > * Then it should look *again* in the result of running cpp, > > to see the now-revealed {-# LANGUAGE DeriveDataTypeable #-} > > > > I'm pretty sure we don't do that; that is, we get the command-line flags once for all from the pre-cpp'd source code. Simon or Ian may be able to confirm. > > Spot on. > > > If so, then this amounts to > > a) a documentation bug: it should be clear what GHC does > > Right, I checked the docs and it doesn't explicitly say this. > > > b) a feature request, to somehow allow cpp to affect in-file flags > > I'm not sure what the spec would be > > It needs a bit of thought - what should happen to pragmas that are there > pre-CPP but not post-CPP, for example? If we ever make Cabal do the cpp'ing instead of Cabal getting ghc to do it then it would operate differently. Cabal would look for the LANGUAGE CPP pragma and use that to decide if the module needs to be cpp'ed. Then ghc would get the result after cpp and so get all pragmas post-cpp. Is there any problem with having ghc do the similar thing now? So ghc reads the file and collects the pragmas. From that set of pragmas it discovers that it needs to run cpp on the file. It should now *discard* all the pragmas and info that it collected. It should run cpp and read the resulting .hs file normally. That means it will accurately pick up pragmas that are affected by cpp, just as if the user had run cpp on the file manually. Duncan From Malcolm.Wallace at cs.york.ac.uk Wed Feb 11 06:45:25 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Feb 11 06:40:22 2009 Subject: hsc2hs and HsFFI.h In-Reply-To: <20090210171545.GA8269@matrix.chaos.earth.li> References: <20090210171545.GA8269@matrix.chaos.earth.li> Message-ID: <20090211114525.701b8e8b.Malcolm.Wallace@cs.york.ac.uk> > Currently, hsc2hs (as shipped with GHC) cannot be used with just > hsc2hs Foo.hsc > as it cannot find HsFFI.h The hsc2hs repo includes a shell script (yes, I know, no good on Windows) called hsc2hs.wrapper that already adds some default arguments. (nhc98 has a modified version of the script, adding a -I$(includedir)) > Another option would be for the user to tell hsc2hs which compiler > they're using, e.g. > hsc2hs --compiler=/usr/bin/ghc Foo.hsc On my system, hsc2hs is already installed as hsc2hs-ghc, in addition to the plain hsc2hs, so if I want the compiler-specific tool, I can use it directly. (nhc98 should do the same thing, i.e. install hsc2hs-nhc98, but I believe for historical reasons, it simply avoids installing hsc2hs at all, to avoid conflicts with the ghc one.) Regards, Malcolm From Malcolm.Wallace at cs.york.ac.uk Wed Feb 11 11:58:14 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Feb 11 11:50:01 2009 Subject: bug in ghc specialiser? Message-ID: <20090211165814.7e67f322.Malcolm.Wallace@cs.york.ac.uk> Here is an apparent bug in ghc's specialisation rules. The rewrite rule generated by a SPECIALISE pragma seems to want to pattern-match on exact dictionaries (as well as types). But the compiler is not necessarily able to fully resolve dictionaries before the rules are supposed to fire. First, the source code we want to specialise: {-# SPECIALISE hedgehog :: Float -> Vector3 Float -> [Cell_8 (Coord3 Float)] -> [Cell_8 (Vector3 Float)] -> [(Coord3 Float, Coord3 Float)] #-} hedgehog :: ( Fractional a, Cell cell vert, Eq vert , Geom coord, Geom vector, Embed vector coord ) => a -> vector a -> [cell (coord a)] -> [cell (vector a)] -> [(coord a, coord a)] And the core + interface generated for this module contains the rule: "SPEC Hedgehog.hedgehog" ALWAYS forall Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 CellTypes.$f1 Geometries.$f5 Geometries.$f3 Geometries.$f1 = Hedgehog.hedgehog1 But in a different module, here is what the usage site looks like just before the specialisation rules are supposed to fire: hedgehog_a4wy = Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 $dFractional_a4xP RectGrid.$f2 CellTypes.$f1 (Dataset.$p2Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) (Dataset.$p1Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) Geometries.$f1 Notice how there are several dictionary selector functions sitting there, so although some of the dictionaries match, not all do, and the rule does not fire. However, later the worker-wrapper transformation is able to resolve those outstanding dictionaries, giving: hedgehog_a4wy = Hedgehog.$whedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 Geometries.$f5 Geometries.$f3 Geometries.$f1 So I'm left calling the worker for the polymorphic version of the function, rather than the specialised monomorphic code I wanted. Given how many dictionaries are involved, and that this is the inner loop of the program, I'm hoping there is a big performance win waiting for me, if only I can get that specialised code to run! Regards, Malcolm From simonpj at microsoft.com Wed Feb 11 12:34:43 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 11 12:24:28 2009 Subject: bug in ghc specialiser? In-Reply-To: <20090211165814.7e67f322.Malcolm.Wallace@cs.york.ac.uk> References: <20090211165814.7e67f322.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C333992018EC@EA-EXMSG-C334.europe.corp.microsoft.com> That should not happen. Can you boil out a test case and make a Trac ticket? When I try the same thing it works: Spec.hs: f :: Num a => a -> a {-# SPECIALISE f :: Int -> Int #-} f x = x+2 ghc -c -ddump-rules -O Spec.hs ==================== Top-level specialisations ==================== "SPEC Foo.f" ALWAYS forall {$dNum :: GHC.Num.Num GHC.Types.Int} Foo.f @ GHC.Types.Int $dNum = f Note the quantification over $dNum. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Malcolm Wallace | Sent: 11 February 2009 16:58 | To: glasgow-haskell-users@haskell.org | Subject: bug in ghc specialiser? | | Here is an apparent bug in ghc's specialisation rules. The rewrite rule | generated by a SPECIALISE pragma seems to want to pattern-match on exact | dictionaries (as well as types). But the compiler is not necessarily | able to fully resolve dictionaries before the rules are supposed to | fire. | | First, the source code we want to specialise: | | {-# SPECIALISE | hedgehog :: Float -> Vector3 Float | -> [Cell_8 (Coord3 Float)] | -> [Cell_8 (Vector3 Float)] | -> [(Coord3 Float, Coord3 Float)] | #-} | hedgehog :: ( Fractional a, Cell cell vert, Eq vert | , Geom coord, Geom vector, Embed vector coord ) => | a -> vector a | -> [cell (coord a)] | -> [cell (vector a)] | -> [(coord a, coord a)] | | And the core + interface generated for this module contains the rule: | | "SPEC Hedgehog.hedgehog" ALWAYS forall | Hedgehog.hedgehog @ GHC.Float.Float | @ RectGrid.Cell_8 | @ CellTypes.MyVertex | @ Geometries.Coord3 | @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 | GHC.Float.$f16 | RectGrid.$f2 | CellTypes.$f1 | Geometries.$f5 | Geometries.$f3 | Geometries.$f1 | = Hedgehog.hedgehog1 | | But in a different module, here is what the usage site looks like just | before the specialisation rules are supposed to fire: | | hedgehog_a4wy = | Hedgehog.hedgehog | @ GHC.Float.Float | @ RectGrid.Cell_8 | @ CellTypes.MyVertex | @ Geometries.Coord3 | @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 | $dFractional_a4xP | RectGrid.$f2 | CellTypes.$f1 | (Dataset.$p2Embed | @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 | @ Geometries.Coord3 | Geometries.$f1) | (Dataset.$p1Embed | @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 | @ Geometries.Coord3 | Geometries.$f1) | Geometries.$f1 | | Notice how there are several dictionary selector functions sitting | there, so although some of the dictionaries match, not all do, and the | rule does not fire. However, later the worker-wrapper transformation | is able to resolve those outstanding dictionaries, giving: | | hedgehog_a4wy = | Hedgehog.$whedgehog | @ GHC.Float.Float | @ RectGrid.Cell_8 | @ CellTypes.MyVertex | @ Geometries.Coord3 | @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 | GHC.Float.$f16 | RectGrid.$f2 | Geometries.$f5 | Geometries.$f3 | Geometries.$f1 | | So I'm left calling the worker for the polymorphic version of the | function, rather than the specialised monomorphic code I wanted. Given | how many dictionaries are involved, and that this is the inner loop of | the program, I'm hoping there is a big performance win waiting for me, | if only I can get that specialised code to run! | | Regards, | Malcolm | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From rturk at science.uva.nl Wed Feb 11 17:25:17 2009 From: rturk at science.uva.nl (Remi Turk) Date: Wed Feb 11 17:15:03 2009 Subject: :info features In-Reply-To: <499181AC.9030403@gmail.com> References: <20090205104954.GB5422@frogstar.lan> <20090209161048.GA5867@frogstar.lan> <499181AC.9030403@gmail.com> Message-ID: <20090211222517.GA8899@frogstar.lan> On Tue, Feb 10, 2009 at 01:31:24PM +0000, Simon Marlow wrote: > Remi Turk wrote: >> On Sat, Feb 07, 2009 at 12:39:03AM -0500, Brandon S. Allbery KF8NH wrote: >>> On 2009 Feb 5, at 5:49, Remi Turk wrote: >>>> SPJ agreed with the idea itself, but suggested an alternative set >>>> of commands: >>>> >>>> :info Show -- See class definition only >>>> :instances Show -- See instances of Show >>> (...) >>>> However, it would make ":i" ambiguous, which is rather sad. >>> :class Show -- unique prefix :cl, already many such collisions >>> :instance Show >> >> That could work, but then how to get information about types as >> opposed to classes? Its not in the above example, but "Show" >> actually stands for an arbitrary typeclass _or type_. >> >> However, as igloo pointed out on the ticket, abbreviations don't >> actually have to be unique: >> >> "For example, :b means :break even though we also have :back, :browse and :browse!. " [1] >> >> That would personally lead me to prefer the :info/:instances >> combo, with :i as an abbreviation of :info. > > My vote would be: > > :info class Show > :info type Show > :info instance Show > > where > > :info Show > > displays information about everything called "Show" > > I know that classes and types share the same namespace currently, but it > might not always be so. Sounds good in principle, and has the advantage of being 100% backward compatible, but ":i class Show" for the common case (ahum, _my_ common case at least ;) still seems rather verbose, so how to abbreviate that? Remi From james.swaine at gmail.com Wed Feb 11 18:16:51 2009 From: james.swaine at gmail.com (James Swaine) Date: Wed Feb 11 18:06:34 2009 Subject: DPH Questions Message-ID: <5195fdde0902111516q150be0e3yc65ace7c6768989f@mail.gmail.com> I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special-purpose standard Prelude when writing vectorised code with DPH. We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations. There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step. Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet? Much thanks, James Swaine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090211/b425ff22/attachment.htm From chak at cse.unsw.edu.au Wed Feb 11 20:16:26 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Feb 11 20:06:10 2009 Subject: DPH Questions In-Reply-To: <5195fdde0902111516q150be0e3yc65ace7c6768989f@mail.gmail.com> References: <5195fdde0902111516q150be0e3yc65ace7c6768989f@mail.gmail.com> Message-ID: James Swaine: > I was wondering if anyone could point me to a more in-depth > explanation of why we are (currently) restricted to using a special- > purpose standard Prelude when writing vectorised code with DPH. The reason is simply that the standard version of the Prelude uses Haskell features that are not yet supported by the vectoriser; in particular, type classes and unboxed values. There is no deep reason for this. It's simply that our priority was to get simple programs completely working with vectorisation from source down to runtime support before widening the path by supporting more language features - ie, we know how to implement these features, but didn't get around to doing it yet. > We're prototyping using several data-parallel languages for a > research project here at Northwestern University, and wanted to get > a better idea how we might go about adding vectorisation support for > addtional types/operations. > > There are certain simple operations which don't appear to be > supported for primitive types yet (e.g. the ^ and ** operators for > an Int type). These are the kinds of things we'd like to look into > as a first step. > > Also - there are several papers which mention foldP as being part of > the (prospective) implementation, but I couldn't find this in any of > the modules. Has this one not been implemented yet? Up to now, the implementation of operations in the special-purpose Prelude and the array library was essentially driven by the examples we coded so far: http://darcs.haskell.org/packages/dph/examples/ So if we didn't actually use a function somewhere, we probably didn't implement it. Again, the motivation was to get simple examples working before making any attempt at completing the set of supported language features or library functions. Generally, we are always keen to hear what (potential) users need most. Where possible, we take these preferences into account in our work plan. If you are able to add some functionality yourself, that would of course be even better and we would be more than happy to receive patches to include into the distribution. Adding functionality to the special-purpose Prelude should usually be fairly straight forward; eg, support for more data types mostly requires to copy and slightly adapt existing code and new functionality can often be achieved by taking code from either GHC's standard Prelude (but remember the restriction on type classes and unboxed values in the current version of the vectoriser) or the Prelude section of the Haskell 98 report. The difficulty of extending the array library depends very much on the functions that you like to add. Some things are easy as they can be implemented by reusing and adapting existing code, but some functionality requires a clear understanding of the internals of the library. In any case, please feel free to ask if you encounter any problems. We are currently working on automatically generating parts of the repetitive boilerplate of the core array library. This will hopefully simplify adding new functionality. Finally, would you mind telling us a bit more about your research project and what you might want to use DPH for? We are always curious about concrete usage scenarios. If you don't want to discuss this on the list, just send me a personal email. Cheers, Manuel From roma at ro-che.info Thu Feb 12 03:22:05 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Feb 12 03:12:07 2009 Subject: DPH Questions In-Reply-To: References: <5195fdde0902111516q150be0e3yc65ace7c6768989f@mail.gmail.com> Message-ID: <20090212082205.GA8656@flit> * Manuel M T Chakravarty [2009-02-12 12:16:26+1100] >> Also - there are several papers which mention foldP as being part of >> the (prospective) implementation, but I couldn't find this in any of >> the modules. Has this one not been implemented yet? > > Up to now, the implementation of operations in the special-purpose > Prelude and the array library was essentially driven by the examples we > coded so far: > > http://darcs.haskell.org/packages/dph/examples/ > > So if we didn't actually use a function somewhere, we probably didn't > implement it. Again, the motivation was to get simple examples working > before making any attempt at completing the set of supported language > features or library functions. It is present here [1] -- so at least it has been implemented. 1. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-PArr.html#v%3AfoldlP -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From marlowsd at gmail.com Thu Feb 12 03:47:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 12 03:37:22 2009 Subject: :info features In-Reply-To: <20090211222517.GA8899@frogstar.lan> References: <20090205104954.GB5422@frogstar.lan> <20090209161048.GA5867@frogstar.lan> <499181AC.9030403@gmail.com> <20090211222517.GA8899@frogstar.lan> Message-ID: <4993E228.20400@gmail.com> Remi Turk wrote: > On Tue, Feb 10, 2009 at 01:31:24PM +0000, Simon Marlow wrote: >> Remi Turk wrote: >>> On Sat, Feb 07, 2009 at 12:39:03AM -0500, Brandon S. Allbery KF8NH wrote: >>>> On 2009 Feb 5, at 5:49, Remi Turk wrote: >>>>> SPJ agreed with the idea itself, but suggested an alternative set >>>>> of commands: >>>>> >>>>> :info Show -- See class definition only >>>>> :instances Show -- See instances of Show >>>> (...) >>>>> However, it would make ":i" ambiguous, which is rather sad. >>>> :class Show -- unique prefix :cl, already many such collisions >>>> :instance Show >>> That could work, but then how to get information about types as >>> opposed to classes? Its not in the above example, but "Show" >>> actually stands for an arbitrary typeclass _or type_. >>> >>> However, as igloo pointed out on the ticket, abbreviations don't >>> actually have to be unique: >>> >>> "For example, :b means :break even though we also have :back, :browse and :browse!. " [1] >>> >>> That would personally lead me to prefer the :info/:instances >>> combo, with :i as an abbreviation of :info. >> My vote would be: >> >> :info class Show >> :info type Show >> :info instance Show >> >> where >> >> :info Show >> >> displays information about everything called "Show" >> >> I know that classes and types share the same namespace currently, but it >> might not always be so. > > Sounds good in principle, and has the advantage of being 100% > backward compatible, but ":i class Show" for the common case > (ahum, _my_ common case at least ;) still seems rather verbose, > so how to abbreviate that? How about a macro? :def ic return . (":info class " ++) Cheers, Simon From Christian.Maeder at dfki.de Thu Feb 12 04:11:24 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 12 04:01:04 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <1234397497.4025.6.camel@localhost> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> Message-ID: <4993E7BC.3030507@dfki.de> Duncan Coutts wrote: > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: >> Does this version work from ghci? >> >> -- Lennart > > Specifically I believe Lennart is asking about Windows. It's worked in > ghci in Linux for ages and it worked in ghci in Windows prior to the > 0.9.13 release. > > In the 0.9.13 release on Windows there was something funky with linking > (possibly due to using a newer mingw) and ghci's linker could not > understand was was going on and could not load the packages. I'm having trouble http://hackage.haskell.org/trac/ghc/ticket/2615 (cairo depends on pthread, which has a linker script) Is there an easy workaround? Maybe that ticket can be considered in "Plans for GHC 6.10.2" Cheers Christian From duncan.coutts at worc.ox.ac.uk Thu Feb 12 07:04:25 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 12 06:54:39 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <4993E7BC.3030507@dfki.de> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> <4993E7BC.3030507@dfki.de> Message-ID: <1234440265.4025.18.camel@localhost> On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote: > Duncan Coutts wrote: > > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: > >> Does this version work from ghci? > >> > >> -- Lennart > > > > Specifically I believe Lennart is asking about Windows. It's worked in > > ghci in Linux for ages and it worked in ghci in Windows prior to the > > 0.9.13 release. > > > > In the 0.9.13 release on Windows there was something funky with linking > > (possibly due to using a newer mingw) and ghci's linker could not > > understand was was going on and could not load the packages. > > I'm having trouble > http://hackage.haskell.org/trac/ghc/ticket/2615 > (cairo depends on pthread, which has a linker script) > Is there an easy workaround? The way it used to work was that the Gtk2Hs ./configure script just filtered out pthread on linux systems. Of course that's just a hack. > Maybe that ticket can be considered in "Plans for GHC 6.10.2" Maybe. Dealing with linker scripts properly is probably rather tricky and we get it for free when we switch to shared libraries. Duncan From chak at cse.unsw.edu.au Thu Feb 12 18:25:42 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Feb 12 18:15:24 2009 Subject: DPH Questions In-Reply-To: <20090212082205.GA8656@flit> References: <5195fdde0902111516q150be0e3yc65ace7c6768989f@mail.gmail.com> <20090212082205.GA8656@flit> Message-ID: <877E20CF-44F8-45DF-B5ED-EC6AAB2B2D73@cse.unsw.edu.au> Roman Cheplyaka: > * Manuel M T Chakravarty [2009-02-12 > 12:16:26+1100] >>> Also - there are several papers which mention foldP as being part of >>> the (prospective) implementation, but I couldn't find this in any of >>> the modules. Has this one not been implemented yet? >> >> Up to now, the implementation of operations in the special-purpose >> Prelude and the array library was essentially driven by the >> examples we >> coded so far: >> >> http://darcs.haskell.org/packages/dph/examples/ >> >> So if we didn't actually use a function somewhere, we probably didn't >> implement it. Again, the motivation was to get simple examples >> working >> before making any attempt at completing the set of supported language >> features or library functions. > > It is present here [1] -- so at least it has been implemented. > > 1. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-PArr.html#v%3AfoldlP That's an old library, not the one used for vectorised code. Manuel From ndmitchell at gmail.com Fri Feb 13 05:29:19 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 13 05:18:58 2009 Subject: DLL support with GHC Message-ID: <404396ef0902130229j28d58ac0u16affeb246782e8f@mail.gmail.com> Hi, What is the current status of shared object support within GHC? Using GHC 6.10.2 (or the branch for it) I can create DLL's under Windows, following these instructions: http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html .Can a similar thing be done under Linux? If so, where is this documented? Many thanks Neil From ndmitchell at gmail.com Fri Feb 13 05:37:18 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 13 05:26:58 2009 Subject: DLL thread safety Message-ID: <404396ef0902130237n24105b2q5ce25e15d9b86a95@mail.gmail.com> Hi, I'm building a DLL using the instructions here: http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html I must call startupHaskell before I make any calls to Haskell functions. However, that page doesn't detail any thread safety rules. In particular: * If I call startupHaskell on Thread 1, can I make Haskell calls from Thread 2. * Can I make Haskell calls from both Thread 1 and Thread 2 simultaneously. Many thanks Neil From rturk at science.uva.nl Sat Feb 14 18:51:08 2009 From: rturk at science.uva.nl (Remi Turk) Date: Sat Feb 14 18:40:42 2009 Subject: :info features In-Reply-To: <4993E228.20400@gmail.com> References: <20090205104954.GB5422@frogstar.lan> <20090209161048.GA5867@frogstar.lan> <499181AC.9030403@gmail.com> <20090211222517.GA8899@frogstar.lan> <4993E228.20400@gmail.com> Message-ID: <20090214235108.GA5823@frogstar.lan> On Thu, Feb 12, 2009 at 08:47:36AM +0000, Simon Marlow wrote: > Remi Turk wrote: >> On Tue, Feb 10, 2009 at 01:31:24PM +0000, Simon Marlow wrote: >>> My vote would be: >>> >>> :info class Show >>> :info type Show >>> :info instance Show >>> >>> where >>> >>> :info Show >>> >>> displays information about everything called "Show" >>> >>> I know that classes and types share the same namespace currently, but >>> it might not always be so. >> >> Sounds good in principle, and has the advantage of being 100% >> backward compatible, but ":i class Show" for the common case >> (ahum, _my_ common case at least ;) still seems rather verbose, >> so how to abbreviate that? > > How about a macro? > > :def ic return . (":info class " ++) Ah of course, I keep forgetting about :def :) Note that when classes and types would stop sharing their namespace, ":info instance Show" would again be ambiguous though.. Groeten, Remi From jared.c.putnam at gmail.com Sun Feb 15 02:32:59 2009 From: jared.c.putnam at gmail.com (Jared) Date: Sun Feb 15 02:22:40 2009 Subject: Linking and constants problems with OpenAL under Windows Message-ID: <61D446EF904944DCA170BA87A53D17FE@skinny> The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work? From duncan.coutts at worc.ox.ac.uk Sun Feb 15 08:07:22 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 15 07:57:25 2009 Subject: [Haskell-cafe] createProcess shutting file handles In-Reply-To: <1234695961.10457.1.camel@localhost> References: <404396ef0902130738h7c20ba29ve319c7a312c9320d@mail.gmail.com> <1234558376.4025.160.camel@localhost> <404396ef0902150124jebeb357qa7498ab27e813f83@mail.gmail.com> <1234695961.10457.1.camel@localhost> Message-ID: <1234703242.10457.18.camel@localhost> On Sun, 2009-02-15 at 11:06 +0000, Duncan Coutts wrote: > On Sun, 2009-02-15 at 09:24 +0000, Neil Mitchell wrote: > > Hi > > > > >> What have I done wrong? Did createProcess close the handle, and is > > >> there a way round this? > > > > > > The docs for runProcess says: > > > > > > Any Handles passed to runProcess are placed immediately in the > > > closed state. > > > > > > but the equivalent seems to be missing from the documentation for > > > createProcess. > > > > However the createProcess command structure has the close_fds flag, > > which seems like it should override that behaviour, and therefore this > > seems like a bug in createProcess. > > close_fds :: Bool > > Close all file descriptors except stdin, stdout and stderr in > the new process > > This refers to inheriting open unix file descriptors (or Win32 HANDLEs) > in the child process. It's not the same as closing the Haskell98 Handles > in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. Duncan From colin at colina.demon.co.uk Sun Feb 15 08:50:32 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Feb 15 08:40:04 2009 Subject: Warning about unrecognised pragma In-Reply-To: (Colin Paul Adams's message of "Thu\, 05 Feb 2009 11\:27\:05 +0000") References: Message-ID: >>>>> "Colin" == Colin Paul Adams writes: Colin> I am getting messages: Board_representation.hs:407:0: Colin> Unrecognised pragma Colin> Board_representation.hs:442:0: Unrecognised pragma Colin> Board_representation.hs:458:0: Unrecognised pragma Colin> etc. Colin> (GHC 6.10.1) Colin> I looked into the documentation to see how to supress these Colin> warnings (prefereably for the particular pragma concerned), Colin> but I found (from 8.13): Colin> "any pragma encountered with an unrecognised word is (silently) ignored." I didn't see any reactions to this. Is it not a bug to emit the error message "Unrecognised pragma"? If it isn't, then is the documentation sentence quoted above a documentation bug? And how do I trun off the message - it is very incovenient, as I get an awful lot of them, and it makes it hard for me to see real error messages. -- Colin Adams Preston Lancashire From ndmitchell at gmail.com Sun Feb 15 12:39:40 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Feb 15 12:29:12 2009 Subject: [Haskell-cafe] createProcess shutting file handles In-Reply-To: <1234703242.10457.18.camel@localhost> References: <404396ef0902130738h7c20ba29ve319c7a312c9320d@mail.gmail.com> <1234558376.4025.160.camel@localhost> <404396ef0902150124jebeb357qa7498ab27e813f83@mail.gmail.com> <1234695961.10457.1.camel@localhost> <1234703242.10457.18.camel@localhost> Message-ID: <404396ef0902150939p72479bb9x5b7c923c8955f72c@mail.gmail.com> Hi >> > However the createProcess command structure has the close_fds flag, >> > which seems like it should override that behaviour, and therefore this >> > seems like a bug in createProcess. >> >> close_fds :: Bool >> >> Close all file descriptors except stdin, stdout and stderr in >> the new process >> >> This refers to inheriting open unix file descriptors (or Win32 HANDLEs) >> in the child process. It's not the same as closing the Haskell98 Handles >> in the parent process that you pass to the child process. > > So lets not talk about if the current behaviour is a bug or not. It's > reasonably clear (if not brilliantly well documented) that it's the > intended behaviour. > > The thing we want to talk about is what reason is there for the current > behaviour, if that's necessary and if it is the sensible default > behaviour. As I said before I don't know why it is the way it is. I'm > cc'ing the ghc users list in the hope that someone there might know. One guiding principle of resource management is that whoever opens/allocates something should release/free it. i.e. if you did the malloc you do the free. For that reason it seems weird that I call openFile but someone else calls hClose on my behalf. Plus, in my particular application, the above behaviour is necessary or I'm going to have to write to a file, open that file, and copy it over to my intended file (which is what I will end up doing, no doubt!) Thanks Neil From marlowsd at gmail.com Mon Feb 16 07:50:57 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 16 07:40:30 2009 Subject: [Haskell-cafe] createProcess shutting file handles In-Reply-To: <404396ef0902150939p72479bb9x5b7c923c8955f72c@mail.gmail.com> References: <404396ef0902130738h7c20ba29ve319c7a312c9320d@mail.gmail.com> <1234558376.4025.160.camel@localhost> <404396ef0902150124jebeb357qa7498ab27e813f83@mail.gmail.com> <1234695961.10457.1.camel@localhost> <1234703242.10457.18.camel@localhost> <404396ef0902150939p72479bb9x5b7c923c8955f72c@mail.gmail.com> Message-ID: <49996131.6010404@gmail.com> Neil Mitchell wrote: > Hi > >>>> However the createProcess command structure has the close_fds flag, >>>> which seems like it should override that behaviour, and therefore this >>>> seems like a bug in createProcess. >>> close_fds :: Bool >>> >>> Close all file descriptors except stdin, stdout and stderr in >>> the new process >>> >>> This refers to inheriting open unix file descriptors (or Win32 HANDLEs) >>> in the child process. It's not the same as closing the Haskell98 Handles >>> in the parent process that you pass to the child process. >> So lets not talk about if the current behaviour is a bug or not. It's >> reasonably clear (if not brilliantly well documented) that it's the >> intended behaviour. >> >> The thing we want to talk about is what reason is there for the current >> behaviour, if that's necessary and if it is the sensible default >> behaviour. As I said before I don't know why it is the way it is. I'm >> cc'ing the ghc users list in the hope that someone there might know. > > One guiding principle of resource management is that whoever > opens/allocates something should release/free it. i.e. if you did the > malloc you do the free. For that reason it seems weird that I call > openFile but someone else calls hClose on my behalf. > > Plus, in my particular application, the above behaviour is necessary > or I'm going to have to write to a file, open that file, and copy it > over to my intended file (which is what I will end up doing, no > doubt!) I don't remember exactly why it's done this way, but it might have something to do with trying to maintain the (possibly ill-conceived) Haskell98 file-locking principle. System.Posix.handleToFd also closes the Handle, FWIW. There's nothing stopping you from re-opening the file and seeking to the end, as a workaround. I could probably be convinced without much difficulty that we should stop closing these Handles; however I do have a vague feeling that I'm forgetting something! Cheers, Simon From marlowsd at gmail.com Mon Feb 16 08:42:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 16 08:32:26 2009 Subject: DLL thread safety In-Reply-To: <404396ef0902130237n24105b2q5ce25e15d9b86a95@mail.gmail.com> References: <404396ef0902130237n24105b2q5ce25e15d9b86a95@mail.gmail.com> Message-ID: <49996D5E.6080403@gmail.com> Neil Mitchell wrote: > Hi, > > I'm building a DLL using the instructions here: > http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html > > I must call startupHaskell before I make any calls to Haskell > functions. However, that page doesn't detail any thread safety rules. > In particular: > > * If I call startupHaskell on Thread 1, can I make Haskell calls from Thread 2. Yes - but of course you must wait for startupHaskell, aka hs_init, to finish first. Also you must compile with -threaded. > * Can I make Haskell calls from both Thread 1 and Thread 2 simultaneously. Yes, with -threaded. Cheers, Simon From marlowsd at gmail.com Mon Feb 16 08:44:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 16 08:34:12 2009 Subject: DLL support with GHC In-Reply-To: <404396ef0902130229j28d58ac0u16affeb246782e8f@mail.gmail.com> References: <404396ef0902130229j28d58ac0u16affeb246782e8f@mail.gmail.com> Message-ID: <49996DBB.2060407@gmail.com> Neil Mitchell wrote: > What is the current status of shared object support within GHC? Using > GHC 6.10.2 (or the branch for it) I can create DLL's under Windows, > following these instructions: > http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html > .Can a similar thing be done under Linux? If so, where is this > documented? No, you can't do that yet. Here's the ticket: http://hackage.haskell.org/trac/ghc/ticket/1876 Cheers, Simon From marlowsd at gmail.com Mon Feb 16 08:49:08 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 16 08:38:50 2009 Subject: Warning about unrecognised pragma In-Reply-To: References: Message-ID: <49996ED4.3090202@gmail.com> Colin Paul Adams wrote: >>>>>> "Colin" == Colin Paul Adams writes: > > Colin> I am getting messages: Board_representation.hs:407:0: > Colin> Unrecognised pragma > > Colin> Board_representation.hs:442:0: Unrecognised pragma > > Colin> Board_representation.hs:458:0: Unrecognised pragma > > Colin> etc. > > Colin> (GHC 6.10.1) > > Colin> I looked into the documentation to see how to supress these > Colin> warnings (prefereably for the particular pragma concerned), > Colin> but I found (from 8.13): > > Colin> "any pragma encountered with an unrecognised word is (silently) ignored." > > I didn't see any reactions to this. > > Is it not a bug to emit the error message "Unrecognised pragma"? > > If it isn't, then is the documentation sentence quoted above a > documentation bug? And how do I trun off the message - it is very > incovenient, as I get an awful lot of them, and it makes it hard for > me to see real error messages. There's a flag to turn off the warnings: -fno-warn-unrecognised-pragmas. Looks like we forgot to document it, though - thanks for highlighting it. http://hackage.haskell.org/trac/ghc/ticket/3031 Cheers, Simon From ndmitchell at gmail.com Mon Feb 16 08:53:21 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 16 08:43:10 2009 Subject: [Haskell-cafe] createProcess shutting file handles In-Reply-To: <49996131.6010404@gmail.com> References: <404396ef0902130738h7c20ba29ve319c7a312c9320d@mail.gmail.com> <1234558376.4025.160.camel@localhost> <404396ef0902150124jebeb357qa7498ab27e813f83@mail.gmail.com> <1234695961.10457.1.camel@localhost> <1234703242.10457.18.camel@localhost> <404396ef0902150939p72479bb9x5b7c923c8955f72c@mail.gmail.com> <49996131.6010404@gmail.com> Message-ID: <404396ef0902160553he64d5a1ne714353a69407931@mail.gmail.com> >>>>> However the createProcess command structure has the close_fds flag, >>>>> which seems like it should override that behaviour, and therefore this >>>>> seems like a bug in createProcess. >>>> >>>> close_fds :: Bool >>>> >>>> Close all file descriptors except stdin, stdout and stderr in >>>> the new process >>>> >>>> This refers to inheriting open unix file descriptors (or Win32 HANDLEs) >>>> in the child process. It's not the same as closing the Haskell98 Handles >>>> in the parent process that you pass to the child process. >>> >>> So lets not talk about if the current behaviour is a bug or not. It's >>> reasonably clear (if not brilliantly well documented) that it's the >>> intended behaviour. >>> >>> The thing we want to talk about is what reason is there for the current >>> behaviour, if that's necessary and if it is the sensible default >>> behaviour. As I said before I don't know why it is the way it is. I'm >>> cc'ing the ghc users list in the hope that someone there might know. >> >> One guiding principle of resource management is that whoever >> opens/allocates something should release/free it. i.e. if you did the >> malloc you do the free. For that reason it seems weird that I call >> openFile but someone else calls hClose on my behalf. >> >> Plus, in my particular application, the above behaviour is necessary >> or I'm going to have to write to a file, open that file, and copy it >> over to my intended file (which is what I will end up doing, no >> doubt!) > > I don't remember exactly why it's done this way, but it might have something > to do with trying to maintain the (possibly ill-conceived) Haskell98 > file-locking principle. System.Posix.handleToFd also closes the Handle, > FWIW. > > There's nothing stopping you from re-opening the file and seeking to the > end, as a workaround. "openFile file AppendMode" is how I ended up doing it, which saves writing a seek in there. It works just fine, merely at the cost of closing/opening handles more than necessary. > I could probably be convinced without much difficulty that we should stop > closing these Handles; however I do have a vague feeling that I'm forgetting > something! Documenting it more clearly would be helpful. As for changing the behaviour - while I think the other way round would be much better, it brings up loads of reverse compatibility headaches, so I'm not sure its worth it. Thanks Neil From colin at colina.demon.co.uk Mon Feb 16 09:00:21 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Feb 16 08:49:49 2009 Subject: Warning about unrecognised pragma In-Reply-To: <49996ED4.3090202@gmail.com> (Simon Marlow's message of "Mon\, 16 Feb 2009 13\:49\:08 +0000") References: <49996ED4.3090202@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> There's a flag to turn off the warnings: Simon> -fno-warn-unrecognised-pragmas. Looks like we forgot to Simon> document it, though - thanks for highlighting it. Simon> http://hackage.haskell.org/trac/ghc/ticket/3031 Great! That does the trick. Thanks. -- Colin Adams Preston Lancashire From phercek at gmail.com Mon Feb 16 12:29:07 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Feb 16 12:18:46 2009 Subject: how dynamic stack approximation works In-Reply-To: <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> Message-ID: pepe wrote: > Having (a kind of messy approximation of) a dynamic stack is possible > with a variant of the cost center stacks mechanism used for profiling. > But the downside is that code and libraries would need to be compiled > for debugging. Is there any info somewhere why the approximation of the dynamic stack needs libraries to be recompiled for debugging? I thought about it but I could not figure out why it would be needed. Here is what I thought is the way it works: * the ticks only inform about the approximate start of the selected expression; this is acceptable provided it makes it much easier to implement * the number of items (continuations) on the return stack from the beginning of /case tick of {_->e}/ to the moment when we can check the count of items in the return stack inside /tick/ is constant and known for a given runtime version of ghc Provided the above is true then we can find out the number of items on the return stack which was valid just before /case tick of {_->e}/ was entered. Lets mark this number as tick_stack_size. Then the only thing we need to build the approximation of the dynamic stack is to get a callback from the runtime just before the number of items in the return stack gets below tick_stack_size for the corresponding /case tick of {_->e}/ expression. That is the moment of "step out" from the selected expression and that is the moment when we can pop an item from our dynamic stack approximation. (Each entering of /tick/ pushes one item to the dynamic stack approximation.) All the requirements to implement the above way seem to be easy to do and they do not look like having too bad speed consequences. Just one indirect memory access and a conditional jump more for each pop of a continuation address from the return stack. And the most important thing is that it does not matter whether a library you use is "strobed" with ticks or not. If a library is not "strobed" it would just look like one item in the approximation of the dynamic stack. If a library is not interpreted (it is not being debugged) we do not want to be bugged with its stack frames anyway ... probably. It looks to me better this way without any experience with it yet. Some of the conditional jumps would happen and would result in more work (maintaining the approximation of the dynamic stack), but all non-tagged value accesses would not as well as all expressions which are not annotated with ticks (like e.g. list creation). Anyway, since the libs would be needed to be compiled for debugging something in the above is wrong. I would like to know what is wrong or some pointer to some web page or paper which describes how the approximation of the dynamic stack works for profiler. I cannot think of other way the profiler dynamic stack approximation would work :-/ Thanks, Peter. From ndmitchell at gmail.com Mon Feb 16 12:42:57 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 16 12:32:32 2009 Subject: Users guide missing Message-ID: <404396ef0902160942y60104a75y705ac76ac155cade@mail.gmail.com> Hi The web page: http://haskell.org/haskellwiki/GHC Links to the latest users guide as a PDF, unfortunately the file is missing: http://www.haskell.org/ghc/docs/latest/users_guide.pdf Thanks Neil From marlowsd at gmail.com Tue Feb 17 03:46:07 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 17 03:35:39 2009 Subject: how dynamic stack approximation works In-Reply-To: References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> Message-ID: <499A794F.3020108@gmail.com> Peter Hercek wrote: > pepe wrote: >> Having (a kind of messy approximation of) a dynamic stack is possible >> with a variant of the cost center stacks mechanism used for profiling. >> But the downside is that code and libraries would need to be compiled >> for debugging. > Is there any info somewhere why the approximation of the dynamic stack > needs libraries to be recompiled for debugging? I thought about it but I > could not figure out why it would be needed. Here is what I thought is > the way it works: I have the feeling that pepe is talking about *lexical* call stacks, rather than *dynamic* call stacks. Cost-centre-stacks try to give you the lexcial call stack (but sadly don't always work properly, and as I've said before we don't fully understand how to do it, or indeed whether it can be done at all...). It probably *would* require recompiling the libraries, though. Perhaps you're already aware of this wiki page, but I'll post the link anyway: http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack The dynamic call stack is already present, in the form of the runtime execution stack. For debugging you might want to track more information than we store on this stack, however. You seem to have a plan for maintaining a dynamic stack for debugging, perhaps you could flesh out the details in a wiki page, mainly to ensure that we're discussing the same thing? Cheers, Simon From marlowsd at gmail.com Tue Feb 17 03:47:39 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 17 03:37:13 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <1234440265.4025.18.camel@localhost> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> <4993E7BC.3030507@dfki.de> <1234440265.4025.18.camel@localhost> Message-ID: <499A79AB.7050501@gmail.com> Duncan Coutts wrote: > On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote: >> Duncan Coutts wrote: >>> On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: >>>> Does this version work from ghci? >>>> >>>> -- Lennart >>> Specifically I believe Lennart is asking about Windows. It's worked in >>> ghci in Linux for ages and it worked in ghci in Windows prior to the >>> 0.9.13 release. >>> >>> In the 0.9.13 release on Windows there was something funky with linking >>> (possibly due to using a newer mingw) and ghci's linker could not >>> understand was was going on and could not load the packages. >> I'm having trouble >> http://hackage.haskell.org/trac/ghc/ticket/2615 >> (cairo depends on pthread, which has a linker script) >> Is there an easy workaround? > > The way it used to work was that the Gtk2Hs ./configure script just > filtered out pthread on linux systems. Of course that's just a hack. > >> Maybe that ticket can be considered in "Plans for GHC 6.10.2" > > Maybe. Dealing with linker scripts properly is probably rather tricky > and we get it for free when we switch to shared libraries. I don't follow this last point - how does switching to shared libraries for Haskell code change things here? Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Feb 17 03:59:34 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 17 03:49:40 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <499A79AB.7050501@gmail.com> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> <4993E7BC.3030507@dfki.de> <1234440265.4025.18.camel@localhost> <499A79AB.7050501@gmail.com> Message-ID: <1234861174.10457.82.camel@localhost> On Tue, 2009-02-17 at 08:47 +0000, Simon Marlow wrote: > Duncan Coutts wrote: > > Maybe. Dealing with linker scripts properly is probably rather tricky > > and we get it for free when we switch to shared libraries. > > I don't follow this last point - how does switching to shared libraries for > Haskell code change things here? It means that ghci will not need to link to system shared libs except when someone uses -lblah on the ghci command line. That's because when we link a Haskell package as a shared lib the system linker interprets any linker scripts and embeds the list of dependencies on other shared libs (other Haskell packages and system libs). Then ghci just dlopens the shared libs for the directly used Haskell packages that that automatically resolves all their deps on other Haskell and system shared libs. Duncan From fmartini at gmail.com Tue Feb 17 12:08:30 2009 From: fmartini at gmail.com (Felix Martini) Date: Tue Feb 17 11:57:55 2009 Subject: Building GHC on Windows Message-ID: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> Hi all, Simon Marlow has recently posted a patch that adds Unicode support to Handle I/O. He mentioned that it didn't work yet on Windows so i was thinking of looking at the source code to see how the new Unicode support works and perhaps try to make it work on Windows. I have built GHC from source in the past on Windows and the process was cumbersome compared to building it on Linux. But i was curious to see if it has gotten easier. After reading the Wiki i decided to get the source with Git as Darcs was slow with remote downloads. Ok, that was a lot quicker than before! Let's see, i need to run sync-all to get the core libraries. I remember that i used to use darcs-all so it must be a new script. Sync-all doesn't have an extension so i probably need to run it with msys. That doesn't work, somehow my msys environment does not find git. So let's try the Git Bash environment which also uses msys (and does not have bash). Now i get a cryptic error: "at ./sync-all line 99, line 19." It seems the script cannot determine the default remote repo. The top line shows that it is a Perl script and i don't know Perl enough to see what is wrong. I have Perl installed on this Windows pc so let's try to run the script directly. That doesn't work either: the Perl script wants to use grep and sed. All this is likely trivial to fix but at the same time these little roadblocks may also explain why few developers on Windows contribute code to GHC and Haskell. Regards, Felix From twhitehead at gmail.com Tue Feb 17 15:50:44 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue Feb 17 15:40:09 2009 Subject: Compiler optimizations questions for ghc 6.10... Message-ID: <200902171550.45001.twhitehead@gmail.com> (compiled with ghc 6.10 with options -O2 -ddump-simpl) I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at the bottom of this email as that is the only place it is ever referenced. It also seems the extra levels of indirection are defeating the strictness analyzer on eta_s1CN in a_s1Gv as all code branches either directly force it or ultimately pass it to digit_s1l3 as in the included branch. Also, why isn't digit_s1l3 optimized to take its first parameter unboxed? It is strict in its first argument, and grepping the core shows that it is only ever used like in lvl_s1mF (i.e., passed things like lvl_s1mG). Thanks! -Tyson PS: Is there any way to get better control over the loop breaker choice? For a slightly simpler digit function, it is not chosen, and great code is produced. I've tried using INLINE on digit, but that seems to result in the monad bind operator not being inlined, which produces even worse code. . . . letrec { lvl_s1mF :: Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int [Str: DmdType {s1l3->C(S)}] lvl_s1mF = digit_s1l3 lvl_s1mG; . . . a_s1Gv :: GHC.Types.Int -> GHC.Types.Int -> Control.Monad.Error.ErrorT [GHC.Types.Char] Control.Monad.Identity.Identity ((GHC.Types.Int, GHC.Types.Int), GHC.Types.Int) [Arity 2 Str: DmdType U(L)L {a1hP->U(TTTL) s1ka->U(L)}] a_s1Gv = a_s1Gv = \ (eta_a1px [ALWAYS Just U(L)] :: GHC.Types.Int) (eta_s1CN [ALWAYS Just L] :: GHC.Types.Int) -> . . .... GHC.Bool.True -> (((lvl_s1mF `cast` (... ~ GHC.Types.Int -> Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity) (GHC.Types.Int, GHC.Types.Int))) (GHC.Types.I# (GHC.Prim.+# x_a1tl 1))) `cast` (... ~ GHC.Types.Int -> Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity ((GHC.Types.Int, GHC.Types.Int), GHC.Types.Int))) eta_s1CN .... . . . . . digit_s1l3 [ALWAYS LoopBreaker Nothing] :: GHC.Types.Int -> Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int [Arity 1 Str: DmdType U(L)] digit_s1l3 = \ (x_aqR [ALWAYS Just U(L)] ::GHC.Types.Int) -> case x_aqR of x_XsO [ALWAYS Just A] { GHC.Types.I# ipv_s1bt [ALWAYS Just L] -> let { . . . } in (\ (eta_X1sC [ALWAYS Just L] :: GHC.Types.Int) (eta_s1FE [ALWAYS Just U(L)] :: GHC.Types.Int) -> . . . ) `cast` (... ~ Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int) . . . } . . . lvl_s1mG :: GHC.Types.Int [Str: DmdType m] lvl_s1mG = GHC.Types.I# 0 From phercek at gmail.com Tue Feb 17 18:23:24 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Feb 17 18:13:00 2009 Subject: my experience with ghci debugger extensions In-Reply-To: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> References: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Message-ID: Pepe Iborra wrote: > - Regarding your :logLocal, you should rename it to :stepLocal, open a > ticket, and attach your patch. We should really try to get this into > 6.10.2. > Ach, I missed I'm supposed to do this first time I read the message. I'll get to it at worst during this weekend. > Finallly, please do not forget to add a link to this in the GHCi > Debugger wiki page at > > http://haskell.org/haskellwiki/GHC/GHCi_debugger > > and/or at the debugging page at > > http://haskell.org/haskellwiki/Debugging > Ok, I found a note in HWN that Ashley Yakeley can create a wiki account. He kindly did it for me so I updated the second page. Also there does not seem to be a demand for ghciext package so I'm not going to advertise it any more but I'll keep the latest version here (if anybody would be interested): http://www.hck.sk/users/peter/pub/ Peter. From batterseapower at hotmail.com Tue Feb 17 19:24:44 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Feb 17 19:14:06 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <200902171550.45001.twhitehead@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> Message-ID: <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> 2009/2/17 Tyson Whitehead : > (compiled with ghc 6.10 with options -O2 -ddump-simpl) > > I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at > the bottom of this email as that is the only place it is ever referenced. The relevant GHC code is SimplUtils.preInlineUnconditionally. It looks like it dosen't get inlined for two reasons: 1) It's not a manifest lambda (it's an application) so inlining inside another lambda would change the number of times the FVs of lvl_s1mF might occur 2) I'm not sure if the use-context is considered interesting by GHC because the application of the function might be hidden by the cast. Not sure about this one. So it looks like the problem stems from digit_s1l3 having arity 1 rather than arity 3. You could try and force it into a higher arity somehow, but I can't say exactly how you might do that without seeing the rest of the Core (and in particular the part under the first lambda in the definition of digit). In general, the -ddump-inlinings flag is useful for working out why something wasn't inlined - but it wouldn't have helped you in this case, because it only dumps information about inlining at call sites, and you actually want an unconditional inlining to occur. > It also seems the extra levels of indirection are defeating the strictness > analyzer on eta_s1CN in a_s1Gv as all code branches either directly force it > or ultimately pass it to digit_s1l3 as in the included branch. > > Also, why isn't digit_s1l3 optimized to take its first parameter unboxed? It > is strict in its first argument, and grepping the core shows that it is only > ever used like in lvl_s1mF (i.e., passed things like lvl_s1mG). Yeah, that's weird. I don't know the answer to this. Have you actually got to the worker-wrapper stage at the point you copied this core? > Thanks! -Tyson > > PS: Is there any way to get better control over the loop breaker choice? For > a slightly simpler digit function, it is not chosen, and great code is > produced. I've tried using INLINE on digit, but that seems to result in the > monad bind operator not being inlined, which produces even worse code. GHC won't inline inside functions marked with INLINE pragmas, for various very good reasons. I don't know how you could change the loop breaker given the current state of technology, but SPJ has a patch for GHC in the works that revamps the treatment of INLINE pragmas and which should (if my understanding of his patch is correct) solve the issue with >>= not being inlined within an inlineable digit. Sorry I can't be more helpful. It's possible I could make some more concrete suggestions if you posted the complete code somewhere. Max From twhitehead at gmail.com Tue Feb 17 23:51:26 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue Feb 17 23:40:58 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> Message-ID: <200902172351.32007.twhitehead@gmail.com> On February 17, 2009 19:24:44 Max Bolingbroke wrote: > 2009/2/17 Tyson Whitehead : > > It also seems the extra levels of indirection are defeating the > > strictness analyzer on eta_s1CN in a_s1Gv as all code branches either > > directly force it or ultimately pass it to digit_s1l3 as in the included > > branch. > > > > Also, why isn't digit_s1l3 optimized to take its first parameter unboxed? > > It is strict in its first argument, and grepping the core shows that it > > is only ever used like in lvl_s1mF (i.e., passed things like lvl_s1mG). > > Yeah, that's weird. I don't know the answer to this. Have you actually > got to the worker-wrapper stage at the point you copied this core? Yes. You are right. Contrary to what the top of the email said, I created that output with -ddump-stranal, and -dshow-passes indicates that the worker- wrapper stage comes next. If I dump it (or just the final core with -ddump- simpl), digit* is entirely replaced with a first-argument-unboxed $wdigit*. The inner lambdas (i.e., the second and third arguments) remain boxed. It seems I should have just used the -ddump-simpl output instead of the - ddump-stranal output. I had just got thinking the the -ddump-simpl output did not include strictness analysis because I didn't see it on a bunch of the code (in retrospect, that was because that code was created by later stages) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090217/35d219ef/attachment.bin From twhitehead at gmail.com Wed Feb 18 00:42:06 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Feb 18 00:31:36 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> Message-ID: <200902180042.12513.twhitehead@gmail.com> On February 17, 2009 19:24:44 Max Bolingbroke wrote: > 2009/2/17 Tyson Whitehead : > > (compiled with ghc 6.10 with options -O2 -ddump-simpl) That should have been -ddump-stranal instead of -ddump-simpl. > > I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core > > at the bottom of this email as that is the only place it is ever > > referenced. > > The relevant GHC code is SimplUtils.preInlineUnconditionally. It looks > like it dosen't get inlined for two reasons: > 1) It's not a manifest lambda (it's an application) so inlining inside > another lambda would change the number of times the FVs of lvl_s1mF > might occur I have to confess my ignorance here as my google fu failed and so I still don't know what a manifest lambda is (other than not a application). : ) > 2) I'm not sure if the use-context is considered interesting by GHC > because the application of the function might be hidden by the cast. > Not sure about this one. I was wondering about that, which is why I didn't remove all the cast noise. > So it looks like the problem stems from digit_s1l3 having arity 1 > rather than arity 3. You could try and force it into a higher arity > somehow, but I can't say exactly how you might do that without seeing > the rest of the Core (and in particular the part under the first > lambda in the definition of digit). The thing is that the inner lambdas come from inlining that StateT monad transformers in a StateT q (StateT Int (ErrorT String Identity)) monad (i.e., the first one is the q state -- which works out to an Int -- and the second is the Int state). I guess I could explicitly pass them around, but that would seem to defeat the purpose of having StateT. The actual routines under this implement part of a FSM for (hopefully) efficiently extracting an Int from a ByteString (or a uvector UArr -- source of the Step data type). The relevant part of the actual code, which is a bit hacked up with ! patterns from my attempts to get better code, is as follows. type ParseInt q a = StateT q (StateT Int (ErrorT String Identity)) a next :: q -> Step q Word8 next i | i==n = Done | otherwise = Yield (bs `BS.unsafeIndex` i) (i+1) wrap :: Monad m => (Word8 -> StateT q m a) -> StateT q m a -> StateT q m a wrap yield (done::StateT q m a) = loop where loop :: StateT q m a loop = do q <- get case next q of Yield x q' -> put q' >> yield x Skip q' -> put q' >> loop Done -> done s2 :: ParseInt q Int s2 = wrap yield done where yield :: Word8 -> StateT q (StateT Int (ErrorT String Identity)) Int yield x | x==48 = digit 0 | x==49 = digit 1 | x==50 = digit 2 | x==51 = digit 3 | x==52 = digit 4 | x==53 = digit 5 | x==54 = digit 6 | x==55 = digit 7 | x==56 = digit 8 | x==57 = digit 9 | otherwise = do !y <- lift get return y where digit :: Int -> ParseInt q Int digit !x = do !y <- lift get ( if y <= (maxBound-9)`quot`10 || y <= (maxBound-x)`div`10 then let !y' = y*10+x in (lift $ put y') >> s2 else throwError "integer overflow" ) done :: ParseInt q Int done = do !y <- lift get return y I just finished adding the Parse q Int type to help with email line wrapping. As I alluded to in my original email, if I don't have the Int overflow check in digit, it is not chosen as the loop breaker, all the StateT stuff is compiled away, and you get a really nice efficient assembler loop (which is important because the final FSM has to actually chew through GBs of data). The part of the code under the first lambda in digit is as follows (I didn't keep the original dump, so the uniques have changed here). It's the second part of the Int overflow bounds check (i.e., y <= (maxBound-x)`div`10), and, indeed, something you don't want to compute unless the easy check fails. digit_s1lk = \ (x_aqR [ALWAYS Just U(L)] :: GHC.Types.Int) -> case x_aqR of x_XsQ [ALWAYS Just A] { GHC.Types.I# ipv_s1bD [ALWAYS Just L] -> let { lvl_s1my [ALWAYS Just D(T)] :: GHC.Types.Int [Str: DmdType] lvl_s1my = case GHC.Prim.-# 9223372036854775807 ipv_s1bD of wild2_a1xi [ALWAYS Just L] { __DEFAULT -> case GHC.Base.divInt# wild2_a1xi 10 of wild21_a1xj [ALWAYS Just L] { __DEFAULT -> GHC.Types.I# wild21_a1xj }; (-9223372036854775808) -> case GHC.Base.divInt# (-9223372036854775808) 10 of wild21_a1xl [ALWAYS Just L] { __DEFAULT -> GHC.Types.I# wild21_a1xl } } } in (\ (eta_X1sU [ALWAYS Just L] :: GHC.Types.Int) (eta_s1G7 [ALWAYS Just U(L)] :: GHC.Types.Int) -> . . . > In general, the -ddump-inlinings flag is useful for working out why > something wasn't inlined - but it wouldn't have helped you in this > case, because it only dumps information about inlining at call sites, > and you actually want an unconditional inlining to occur. I also tried that, and didn't have much luck with it. I didn't understand the output, which there was 48k lines worth of, and the uniques kept changing which made it hard to grep for names from previous -ddump-simpl runs. I'm in the process of reading the "Secrets of the GHC inliner" paper, so, hopefully, that will at least help me with the first of these problems. : ) Thanks very much for looking at this and the details reply! Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090218/6334cd46/attachment-0001.bin From simon at joyful.com Wed Feb 18 01:21:19 2009 From: simon at joyful.com (Simon Michael) Date: Wed Feb 18 01:44:27 2009 Subject: my experience with ghci debugger extensions In-Reply-To: References: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Message-ID: Peter Hercek wrote: > Also there does not seem to be a demand for ghciext package so I'm not Hi Peter.. just to note that I haven't had the need/time yet to try it, but I'm very thankful for the work you and Pepe are doing to make ghci more powerful. It's a very useful tool for learning about Haskell and figuring out perplexing behaviours in real-world programs. From batterseapower at hotmail.com Wed Feb 18 04:29:42 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Feb 18 04:19:04 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <200902180042.12513.twhitehead@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> <200902180042.12513.twhitehead@gmail.com> Message-ID: <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> 2009/2/18 Tyson Whitehead : > On February 17, 2009 19:24:44 Max Bolingbroke wrote: >> 2009/2/17 Tyson Whitehead : >> > (compiled with ghc 6.10 with options -O2 -ddump-simpl) > > That should have been -ddump-stranal instead of -ddump-simpl. Right. Mystery solved. In case you were wondering, the reason the other two lambdas in "digit" are not worker/wrappered is because GHC only performs strictness analysis on lambdas that occur /immediately/ in the binding. So increasing the arity of digit is CRUCIAL to getting your program to compile well, as that will cause: * Strictness analysis on the inner lambdas * Inlining of lvl_s1mF * Fewer updateable thunks to be created by callers (as we won't try to cache the results of a partial application) >> > I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core >> > at the bottom of this email as that is the only place it is ever >> > referenced. >> >> The relevant GHC code is SimplUtils.preInlineUnconditionally. It looks >> like it dosen't get inlined for two reasons: >> 1) It's not a manifest lambda (it's an application) so inlining inside >> another lambda would change the number of times the FVs of lvl_s1mF >> might occur > > I have to confess my ignorance here as my google fu failed and so I still > don't know what a manifest lambda is (other than not a application). : ) Sorry :-). Manifest lambdas are just lambdas that occur manifestly! So e.g.: f = \x -> g x HAS a manifest lambda, whereas: f' = g Does NOT have one. No lambda immediately starts the binding. Lambdas, manifest or otherwise, are important in this context because any value with a leading lambda is certainly very cheap and so can be inlined inside other lambdas - which is what you are trying to achieve with lvl_s1mF. (snip code and explanation) > I just finished adding the Parse q Int type to help with email line wrapping. > As I alluded to in my original email, if I don't have the Int overflow check > in digit, it is not chosen as the loop breaker, all the StateT stuff is > compiled away, and you get a really nice efficient assembler loop (which is > important because the final FSM has to actually chew through GBs of data). > > The part of the code under the first lambda in digit is as follows (I didn't > keep the original dump, so the uniques have changed here). It's the second > part of the Int overflow bounds check (i.e., y <= (maxBound-x)`div`10), and, > indeed, something you don't want to compute unless the easy check fails. Yes - GHC wants to share the work of (maxBound-x)`div`10 between several partial applications of "digit". This is usually a good idea, but in this case it sucks because it's resulted in a massively increased arity. IMHO GHC should fix this by: * Marking divInt# INLINE in the base library. This would result in your code would just containing uses of quotInt# * Making some operations cheap even if they may fail (PrimOp.primpOpIsCheap should change). Though this might mean that we turn non-terminating programs into terminating ones (such operations get pushed inside lambdas) but this is consistent with our treatment of lambdas generally. Actually, your divInt# call wouldn't even usually be floated out to between two lambdas, but at the time FloatOut runs there is something in between the \x lambda and the lambdas from the state monad - the monadic bind operator! So FloatOut feels free to move the computation for "x" up even though that >>= will go away as soon as we run the simplifier. What a disaster! For me, making digit INLINE fixes all this, but that's probably because the context of my code is not the same as yours (I had to invent parts of a program to bind the bs, q and n variables). For your immediate problem, I would suggest this bit of GHC witchdoctory: where digit :: Int -> ParseInt Int Int digit !x = do !y <- lift get ( if y <= (maxBound-9)`quot`10 || y <= ghc_hacks then let !y' = y*10+x in (lift $ put y') >> s2 else throwError "integer overflow" ) where {-# INLINE ghc_hacks #-} ghc_hacks = (maxBound-x)`div`10 With luck, this should make the loop-invariant cheap in GHC's eyes, preventing it from trying to share it. It works for me - but like I say things may differ in your program. >> In general, the -ddump-inlinings flag is useful for working out why >> something wasn't inlined - but it wouldn't have helped you in this >> case, because it only dumps information about inlining at call sites, >> and you actually want an unconditional inlining to occur. > > I also tried that, and didn't have much luck with it. I didn't understand the > output, which there was 48k lines worth of, and the uniques kept changing > which made it hard to grep for names from previous -ddump-simpl runs. Right. I tend to use -ddump-inilnings and -dverbose-core2core (or -ddump-simpl) together, and I have a little script that partitions the output up by the "=====" seperators. Then I can look at the output of a phase (which is split into it's own file) and if I see something that should have been inlined I can go to the output of the previous simplifier run (also in it's own file) and grep for it's name in the -ddump-inlinings output of that phase. This means you don't have to match uniques between two entierly seperate runs, although annoyingly the output format for identifier in -ddump-inlinings is slightly different from that in Core output so grepping is not as easy as it could be. If you are interested in trying my script, it's available via Git at http://github.com/batterseapower/scripts/blob/da1f24ba16c27e3994aa66f9db352ec1102c39d2/ghc-dump-split and is called as "ghc-dump-split ghc-dump-file", where ghc-dump-file results from redirection of GHC stdout+stderr to a file. Hope all that helps, Max From batterseapower at hotmail.com Wed Feb 18 04:38:31 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Feb 18 04:27:53 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> <200902180042.12513.twhitehead@gmail.com> <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> Message-ID: <9d4d38820902180138p3d04f600he29f6ce50af575b1@mail.gmail.com> 2009/2/18 Max Bolingbroke : > Yes - GHC wants to share the work of (maxBound-x)`div`10 between > several partial applications of "digit". This is usually a good idea, > but in this case it sucks because it's resulted in a massively > increased arity. IMHO GHC should fix this by: > * Marking divInt# INLINE in the base library. This would result in > your code would just containing uses of quotInt# > * Making some operations cheap even if they may fail > (PrimOp.primpOpIsCheap should change). Though this might mean that we > turn non-terminating programs into terminating ones (such operations > get pushed inside lambdas) but this is consistent with our treatment > of lambdas generally. Just to let you know - I've filed a bug (#3034 http://hackage.haskell.org/trac/ghc/ticket/3034) about this issue. I've taken the liberty of adding you to the CC list so you can keep track of the problem. Cheers, Max From mnislaih at gmail.com Wed Feb 18 04:51:18 2009 From: mnislaih at gmail.com (pepe) Date: Wed Feb 18 04:40:42 2009 Subject: how dynamic stack approximation works In-Reply-To: <499A794F.3020108@gmail.com> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> Message-ID: On 17/02/2009, at 9:46, Simon Marlow wrote: > Peter Hercek wrote: >> pepe wrote: >>> Having (a kind of messy approximation of) a dynamic stack is >>> possible with a variant of the cost center stacks mechanism used >>> for profiling. But the downside is that code and libraries would >>> need to be compiled for debugging. >> Is there any info somewhere why the approximation of the dynamic >> stack needs libraries to be recompiled for debugging? I thought >> about it but I could not figure out why it would be needed. Here is >> what I thought is the way it works: > > I have the feeling that pepe is talking about *lexical* call stacks, > rather than *dynamic* call stacks. Cost-centre-stacks try to give > you the lexcial call stack (but sadly don't always work properly, > and as I've said before we don't fully understand how to do it, or > indeed whether it can be done at all...). It probably *would* > require recompiling the libraries, though. > Yes, I was meaning lexical call stacks, as Simon suggests. Apologies for the confusion, Peter. pepe From twhitehead at gmail.com Wed Feb 18 12:42:02 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Feb 18 12:31:33 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <200902180042.12513.twhitehead@gmail.com> <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> Message-ID: <200902181242.09526.twhitehead@gmail.com> On February 18, 2009 04:29:42 Max Bolingbroke wrote: > > The part of the code under the first lambda in digit is as follows (I > > didn't keep the original dump, so the uniques have changed here). It's > > the second part of the Int overflow bounds check (i.e., y <= > > (maxBound-x)`div`10), and, indeed, something you don't want to compute > > unless the easy check fails. > > Yes - GHC wants to share the work of (maxBound-x)`div`10 between > several partial applications of "digit". This is usually a good idea, > but in this case it sucks because it's resulted in a massively > increased arity. IMHO GHC should fix this by: > * Marking divInt# INLINE in the base library. This would result in > your code would just containing uses of quotInt# > * Making some operations cheap even if they may fail > (PrimOp.primpOpIsCheap should change). Though this might mean that we > turn non-terminating programs into terminating ones (such operations > get pushed inside lambdas) but this is consistent with our treatment > of lambdas generally. Reading your response got me thinking, "quot and div, I thought I had changed everything to quot because earlier I found that GHC was leaving evaluation of constant expressions like "maxBound-9`div`10" until runtime if I used div." Turns out I had missed that one in the second bounds check, and changing it from "y <= (maxBound-x)`div`10" to "y <= (maxBound-x)`qout`10" resulted in GHC "just doing the right thing". I presume this is because quot must be either marked INLINE and/or primOpIsCheap like you said div should be. I am guess this is because quot maps directly onto the x86 idiv instruction due to both of them truncating towards zero, while div, with its truncation towards negative infinity, does not. Running with -ddump-asm seems to back this up as quotInt# compiles down to an idiv instruction and divInt# to a call through base_GHCziBase_divIntzh_info. Unfortunately for me, I always seem to instinctively go with div and mod ahead of quot and rem. > Actually, your divInt# call wouldn't even usually be floated out to > between two lambdas, but at the time FloatOut runs there is something > in between the \x lambda and the lambdas from the state monad - the > monadic bind operator! So FloatOut feels free to move the computation > for "x" up even though that >>= will go away as soon as we run the > simplifier. What a disaster! I would like to try combining the GHC optimizer with a genetic algorithm so you could set it to pound away on your core loops for an hour or so to find the right sequence of ghc optimization steps to generate the tightest code. Maybe it could then write out an optimization hint file that regular GHC could optionally take in for use alongside the standard rules of thumb to produce great code. All I need is more time and more knowledge. Maybe someday. : ) > For me, making digit INLINE fixes all this, but that's probably > because the context of my code is not the same as yours (I had to > invent parts of a program to bind the bs, q and n variables). Sorry about that. I've put the entire routine at http://www.sharcnet.ca/~tyson/haskell/Example1.hs I should have done this in the first place as it allows me to provide the full code while also stripping it down in the emails to make them more readable. > For your > immediate problem, I would suggest this bit of GHC witchdoctory: > > where digit :: Int -> ParseInt Int Int > digit !x = do !y <- lift get > ( if y <= (maxBound-9)`quot`10 || > y <= ghc_hacks > then let !y' = y*10+x in (lift > $ put y') >> s2 > else throwError "integer overflow" ) > where {-# INLINE ghc_hacks #-} > ghc_hacks = (maxBound-x)`div`10 > > With luck, this should make the loop-invariant cheap in GHC's eyes, > preventing it from trying to share it. It works for me - but like I > say things may differ in your program. I tried that as well, and am pleased to report that it works great. I think I actually understand what is going on here and will hopefully be able to wield it in the future to my advantage. Generally I've had very little luck with the INLINE hammer when the function is at all complex. GHC always seems to finds a way to thwart my pathetic attempts and punish me with even worse code (like then not inlining the monad bind operation in the code resulting from the inlining). : ) > If you are interested in trying my script, it's available via Git at > http://github.com/batterseapower/scripts/blob/da1f24ba16c27e3994aa66f9db352 >ec1102c39d2/ghc-dump-split and is called as "ghc-dump-split ghc-dump-file", > where ghc-dump-file results from redirection of GHC stdout+stderr to a > file. I'll grab a copy of that. : ) > Hope all that helps, It sure did. Thanks very much for all your time! I'm really impressed with GHC and the people hacking on it. I've actually managed to get it to produce some truly tight assembler. It's also great, unlike a lot of projects, having papers that you can read on many details. Thanks again! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090218/8c172691/attachment.bin From twhitehead at gmail.com Wed Feb 18 14:18:00 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Feb 18 14:07:29 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <200902181242.09526.twhitehead@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902180129p3c73358fp4bb186178a758610@mail.gmail.com> <200902181242.09526.twhitehead@gmail.com> Message-ID: <200902181418.06119.twhitehead@gmail.com> On February 18, 2009 12:42:02 Tyson Whitehead wrote: > On February 18, 2009 04:29:42 Max Bolingbroke wrote: > > Yes - GHC wants to share the work of (maxBound-x)`div`10 between > > several partial applications of "digit". This is usually a good idea, > > but in this case it sucks because it's resulted in a massively > > increased arity. IMHO GHC should fix this by: > > * Marking divInt# INLINE in the base library. This would result in > > your code would just containing uses of quotInt# > > * Making some operations cheap even if they may fail > > (PrimOp.primpOpIsCheap should change). Though this might mean that we > > turn non-terminating programs into terminating ones (such operations > > get pushed inside lambdas) but this is consistent with our treatment > > of lambdas generally. > > I am guess this is because quot maps directly onto the x86 idiv instruction > due to both of them truncating towards zero, while div, with its truncation > towards negative infinity, does not. Running with -ddump-asm seems to back > this up as quotInt# compiles down to an idiv instruction and divInt# to a > call through base_GHCziBase_divIntzh_info. Unfortunately for me, I always > seem to instinctively go with div and mod ahead of quot and rem. I see what you mean about div as it is defined through divMod which is in turn defined through quotRem in Prelude. n `div` d = q where (q,_) = divMod n d divMod n d = if signum r == negate (signum d) then (q-1, r+d) else qr where qr@(q,r) = quotRem n d However, GHC almost seems to be doing its own thing as, as I mentioned above, it turns it into a divInt# (which is not in GHC.Prim) in the tidy core, which then turns into a call through base_GHCziBase_divIntzh_info in the assembler. (note that I'm just looking at the source from the haskell.org libraries link) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090218/c17d8af6/attachment-0001.bin From duncan.coutts at worc.ox.ac.uk Wed Feb 18 14:37:39 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 18 14:27:13 2009 Subject: hsc2hs and HsFFI.h In-Reply-To: <20090210171545.GA8269@matrix.chaos.earth.li> References: <20090210171545.GA8269@matrix.chaos.earth.li> Message-ID: <1234985859.10457.173.camel@localhost> On Tue, 2009-02-10 at 17:15 +0000, Ian Lynagh wrote: > Hi all, > > Currently, hsc2hs (as shipped with GHC) cannot be used with just > hsc2hs Foo.hsc > as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897). > To make it work you need to run something like > hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc > (it also works when called by Cabal, as Cabal passes it this flag > automatically). However, we would like to have it work without needing > to use any special flags, and without having to use it from within a > Cabal package. > > The obvious solution to this problem would seem to be to put HsFFI.h in > /usr/lib/hsc2hs/include > and have hsc2hs automatically add that to the include path. However, > hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't > a compiler-independent header file; for example, GHC's implementation > defines HsInt to be a 64-bit integer type on amd64, whereas hugs's > implementation defines it to be a 32-bit type. We therefore need a > different HsFFI.h depending on which compiler we are using. > > One option would be to have hsc2hs (when installed with GHC) append > "-I /usr/lib/ghc-6.10.1/include" to the commandline. If the user gives a > "-I /usr/lib/hugs/include" flag then this path will be looked at first, > and the hugs HsFFI.h will be used. > > Another option would be for the user to tell hsc2hs which compiler > they're using, e.g. > hsc2hs --compiler=/usr/bin/ghc Foo.hsc > (this "compiler" is distinct from the C compiler that hsc2hs will use). > hsc2hs will then pass the appropriate -I flag, depending on what sort of > compiler it is told to use. The hsc2hs that comes with GHC would > probably default to using the GHC that it is installed with, but > standalone hsc2hs would probably default to searching for /usr/bin/ghc, > /usr/bin/hugs, etc. > > This last approach would also make it possible for hsc2hs to take > "-package foo" flags, and add the include paths for the requested > packages too. > > The downside is that it's pushing a lot more knowledge into hsc2hs, > which means there is one more thing to keep in sync. > > > Has anyone got any other alternatives to consider? Or opinions on which > solution is best? I don't see nice solutions here. It's not nice to have each compiler ship their own variant/wrapper of hsc2hs (which one gets to be /usr/bin/hsch2s ?). It's also not nice for hsc2hs to have to know about each different compiler. It's worst to have ghc get taught how to compile .hsc files. My suggestion is to avoid the problem. Why does hsc2hs need to know anything about which Haskell compiler? It's because it #includes HsFFI.h in its default hsc template. Why does it need to include HsFFI.h? Well, actually it probably doesn't need to at all. The HsFFI.h is not needed by code in the hsc template itself and nor is it needed by other code generated by hsc2hs as far as I can tell. Does anyone remember why HsFFI.h was included in the default hsc template? My guess it's there as a convenience for those modules that need things from HsFFI.h. I speculate that the number of .hsc modules that actually need this header file is very low. So my suggestion is that in those few cases where it is needed, it should be specified explicitly in the .hsc file. In such cases it is the responsibility of the build system to use the right -I include dir. Cabal does this ok and others can do it too if needed. To see if this is viable we'd want to check that building a bunch of packages from hackage that use hsc2hs works with a modified template file. This test should be relatively easy to perform, though would take several hours of building. Sound plausible? Duncan From john at repetae.net Wed Feb 18 16:04:14 2009 From: john at repetae.net (John Meacham) Date: Wed Feb 18 15:53:33 2009 Subject: hsc2hs and HsFFI.h In-Reply-To: <1234985859.10457.173.camel@localhost> References: <20090210171545.GA8269@matrix.chaos.earth.li> <1234985859.10457.173.camel@localhost> Message-ID: <20090218210414.GF22261@sliver.repetae.net> I went ahead and implemented --print-hsc-options to jhc, which will spit out something like '-I/usr/share/jhc-0.5/include' suitable for passing to the hsc2hs command line. It seemed like the most straightforward route of the choices mentioned. John -- John Meacham - ?repetae.net?john? From phercek at gmail.com Thu Feb 19 03:40:34 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Feb 19 03:30:03 2009 Subject: my experience with ghci debugger extensions In-Reply-To: References: <44b20d900902050824p4160790fx32aec239f48a0840@mail.gmail.com> Message-ID: Peter Hercek wrote: > Pepe Iborra wrote: >> - Regarding your :logLocal, you should rename it to :stepLocal, open a >> ticket, and attach your patch. We should really try to get this into >> 6.10.2. >> > Ach, I missed I'm supposed to do this first time I read the message. > I'll get to it at worst during this weekend. http://hackage.haskell.org/trac/ghc/ticket/3035 It is there with a patch attached. Maybe you can still validate and add it to 6.10.2. Sorry for not noticing that you wanted me to do it. For me it is not important, I already run a custom ghc anyway because of other things so one more patch does not change much. Peter. From igloo at earth.li Thu Feb 19 08:50:38 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Feb 19 08:39:55 2009 Subject: Plans for GHC 6.10.2 In-Reply-To: <20090210164239.GA7918@matrix.chaos.earth.li> References: <20090210164239.GA7918@matrix.chaos.earth.li> Message-ID: <20090219135038.GA8609@matrix.chaos.earth.li> On Tue, Feb 10, 2009 at 04:42:39PM +0000, Ian Lynagh wrote: > > We expect to have a release candidate ready around the end of next week. We've decided to push this back by a couple of weeks, due to paper deadlines. Thanks Ian From marlowsd at gmail.com Thu Feb 19 10:11:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 19 10:00:42 2009 Subject: Building GHC on Windows In-Reply-To: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> Message-ID: <499D7697.8060604@gmail.com> Felix Martini wrote: > Simon Marlow has recently posted a patch that adds Unicode support to > Handle I/O. He mentioned that it didn't work yet on Windows so i was > thinking of looking at the source code to see how the new Unicode > support works and perhaps try to make it work on Windows. Thanks - I've looked into it a little and it's not too hard. There's some code in the Win32 package (System.Win32.NLS) that should prove helpful, though we'll have to copy anything we need from there since base can't depend on Win32. If you manage to get your build working, keep me updated on your plans. BTW, I think the patches now have conflicts with the HEAD, but hopefully they shouldn't be too hard to fix (I'll try to get around to this soon, but I'm quite busy with other stuff at the moment). > I have built GHC from source in the past on Windows and the process > was cumbersome compared to building it on Linux. But i was curious to > see if it has gotten easier. > > After reading the Wiki i decided to get the source with Git as Darcs > was slow with remote downloads. Ok, that was a lot quicker than > before! Let's see, i need to run sync-all to get the core libraries. I > remember that i used to use darcs-all so it must be a new script. > Sync-all doesn't have an extension so i probably need to run it with > msys. That doesn't work, somehow my msys environment does not find > git. So let's try the Git Bash environment which also uses msys (and > does not have bash). Now i get a cryptic error: "at ./sync-all line > 99, line 19." It seems the script cannot determine the default > remote repo. The top line shows that it is a Perl script and i don't > know Perl enough to see what is wrong. I have Perl installed on this > Windows pc so let's try to run the script directly. That doesn't work > either: the Perl script wants to use grep and sed. > > All this is likely trivial to fix but at the same time these little > roadblocks may also explain why few developers on Windows contribute > code to GHC and Haskell. I haven't tried sync-all on Windows - can anyone help out here? Cheers, Simon From kr.angelov at gmail.com Thu Feb 19 16:34:47 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Thu Feb 19 16:24:04 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <200902180042.12513.twhitehead@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> <200902180042.12513.twhitehead@gmail.com> Message-ID: I was surprised to see this case expression: > case GHC.Prim.-# 9223372036854775807 ipv_s1bD > of wild2_a1xi [ALWAYS Just L] { What is the purpose to compare the value with maxBound before the division? The case expression doesn't disappear even if I use quot instead of div. Krasimir 2009/2/18 Tyson Whitehead : > digit_s1lk = > \ (x_aqR [ALWAYS Just U(L)] :: GHC.Types.Int) -> > case x_aqR > of x_XsQ [ALWAYS Just A] { GHC.Types.I# ipv_s1bD [ALWAYS Just L] -> > let { > lvl_s1my [ALWAYS Just D(T)] :: GHC.Types.Int > [Str: DmdType] > lvl_s1my = > case GHC.Prim.-# 9223372036854775807 ipv_s1bD > of wild2_a1xi [ALWAYS Just L] { > __DEFAULT -> > case GHC.Base.divInt# wild2_a1xi 10 > of wild21_a1xj [ALWAYS Just L] { __DEFAULT -> > GHC.Types.I# wild21_a1xj > }; > (-9223372036854775808) -> > case GHC.Base.divInt# (-9223372036854775808) 10 > of wild21_a1xl [ALWAYS Just L] { __DEFAULT -> > GHC.Types.I# wild21_a1xl > } > } } in > (\ (eta_X1sU [ALWAYS Just L] :: GHC.Types.Int) > (eta_s1G7 [ALWAYS Just U(L)] :: GHC.Types.Int) -> From batterseapower at hotmail.com Thu Feb 19 17:19:08 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Feb 19 17:08:25 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> <200902180042.12513.twhitehead@gmail.com> Message-ID: <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> 2009/2/19 Krasimir Angelov : > I was surprised to see this case expression: > >> case GHC.Prim.-# 9223372036854775807 ipv_s1bD >> of wild2_a1xi [ALWAYS Just L] { > > What is the purpose to compare the value with maxBound before the > division? The case expression doesn't disappear even if I use quot > instead of div. Have a look at this snippet of the base library, file GHC/Real.lhs: a `quot` b | b == 0 = divZeroError | a == minBound && b == (-1) = overflowError | otherwise = a `quotInt` b quotInt is defined in GHC/Base.lhs as: (I# x) `quotInt` (I# y) = I# (x `quotInt#` y) And quotInt# is a primitive, which I guess is implemented via machine division (though I don't work on the codegen stuff at all) - so your offending case must come from those tests in GHC/Real.lhs. In general, if you want to answer questions like this you can usually find the answer by looking at the base code: it's all in Haskell, so very readable! You can get it online at http://darcs.haskell.org/libraries/base/GHC/ Cheers, Max From ganesh at earth.li Thu Feb 19 17:29:37 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Thu Feb 19 17:18:53 2009 Subject: GHC 6.10 changes for recursive calls to class instances Message-ID: Hi, I have a problem in GHC 6.10 with functions in a class instance calling other functions in the same class instance. It seems that the dictionary is freshly constructed for this call, despite being already available. The reason I care is that I want to memoise some expensive computations inside the dictionary for each instance. [Obviously I also have to make sure that the dictionary isn't constructed multiple times by external callers, but I can make other arrangements to ensure that.] To see the problem in action, run main from the attached code. In GHC 6.8 and before, this only executes the trace statement once. In GHC 6.10, the trace statement executes twice, at all optimisation levels. This seems related to http://hackage.haskell.org/trac/ghc/ticket/2902, but I'm a little unclear on whether it's the same problem or not. Cheers, Ganesh -------------- next part -------------- A non-text attachment was scrubbed... Name: RecDict.hs Type: text/x-haskell Size: 675 bytes Desc: Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090219/f2258537/RecDict.bin From kr.angelov at gmail.com Thu Feb 19 18:20:33 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Thu Feb 19 18:09:51 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902171624hf84efe0xcd889d2df1f50cad@mail.gmail.com> <200902180042.12513.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> Message-ID: Oh. I looked at the primops.txt.pp for something suspicious but I didn't checked the actual implementation of quot. I thought that quot calls quotInt# directly. When I use quotInt in the code I can get the real idiv assembly instruction. Still the code generated by GHC is strange it doesn't throw any exception actually. It just evaluates the same expression but with the constant maxBound. On Thu, Feb 19, 2009 at 11:19 PM, Max Bolingbroke wrote: > 2009/2/19 Krasimir Angelov : >> I was surprised to see this case expression: >> >>> case GHC.Prim.-# 9223372036854775807 ipv_s1bD >>> of wild2_a1xi [ALWAYS Just L] { >> >> What is the purpose to compare the value with maxBound before the >> division? The case expression doesn't disappear even if I use quot >> instead of div. > > Have a look at this snippet of the base library, file GHC/Real.lhs: > > a `quot` b > | b == 0 = divZeroError > | a == minBound && b == (-1) = overflowError > | otherwise = a `quotInt` b > > quotInt is defined in GHC/Base.lhs as: > > (I# x) `quotInt` (I# y) = I# (x `quotInt#` y) > > And quotInt# is a primitive, which I guess is implemented via machine > division (though I don't work on the codegen stuff at all) - so your > offending case must come from those tests in GHC/Real.lhs. > > In general, if you want to answer questions like this you can usually > find the answer by looking at the base code: it's all in Haskell, so > very readable! You can get it online at > http://darcs.haskell.org/libraries/base/GHC/ > > Cheers, > Max > From twhitehead at gmail.com Thu Feb 19 22:00:01 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu Feb 19 21:49:29 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> Message-ID: <200902192200.08488.twhitehead@gmail.com> On February 19, 2009 18:20:33 Krasimir Angelov wrote: > Oh. I looked at the primops.txt.pp for something suspicious but I > didn't checked the actual implementation of quot. I thought that quot > calls quotInt# directly. When I use quotInt in the code I can get the > real idiv assembly instruction. Still the code generated by GHC is > strange it doesn't throw any exception actually. It just evaluates the > same expression but with the constant maxBound. > > On Thu, Feb 19, 2009 at 11:19 PM, Max Bolingbroke > > a `quot` b > > > > | b == 0 = divZeroError > > | a == minBound && b == (-1) = overflowError > > | otherwise = a `quotInt` b I checked the quot one like you said. Kind of strange all right. It looks like it is performing the a == minBound check (where a = maxBound-x) despite the b == (-1) check (where b = 10) being optimized away. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090219/2b9cdda3/attachment.bin From kr.angelov at gmail.com Fri Feb 20 03:00:30 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Feb 20 02:49:46 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <200902192200.08488.twhitehead@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> Message-ID: I think that what happens is that this function: a `quot` b | b == 0 = divZeroError | a == minBound && b == (-1) = overflowError | otherwise = a `quotInt` b is expanded to: a `quot` b = if b == 0 then divZeroError else if a == minBound then if b == (-1) then overflowError else a `quotInt` b else a `quotInt` b Then the compiler sees that b is a constant and computes that b == 0 is False and b == (-1) is also False so it could eliminate two If statements. The result is: a `quot` b = if a == minBound then a `quotInt` b else a `quotInt` b and this is exactly what we get. I bet that if the original function was: a `quot` b | b == 0 = divZeroError | b == (-1) && a == minBound = overflowError -- Note the changed order here | otherwise = a `quotInt` b then we would get what we want. I think that it is much more often to have division where the divisor is known so we will get the best code in this case. Regards, Krasimir On Fri, Feb 20, 2009 at 4:00 AM, Tyson Whitehead wrote: > On February 19, 2009 18:20:33 Krasimir Angelov wrote: >> Oh. I looked at the primops.txt.pp for something suspicious but I >> didn't checked the actual implementation of quot. I thought that quot >> calls quotInt# directly. When I use quotInt in the code I can get the >> real idiv assembly instruction. Still the code generated by GHC is >> strange it doesn't throw any exception actually. It just evaluates the >> same expression but with the constant maxBound. >> >> On Thu, Feb 19, 2009 at 11:19 PM, Max Bolingbroke >> > a `quot` b >> > >> > | b == 0 = divZeroError >> > | a == minBound && b == (-1) = overflowError >> > | otherwise = a `quotInt` b > > I checked the quot one like you said. Kind of strange all right. > > It looks like it is performing the a == minBound check (where a = maxBound-x) > despite the b == (-1) check (where b = 10) being optimized away. > > Cheers! -Tyson > From bulat.ziganshin at gmail.com Fri Feb 20 03:22:23 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 20 03:11:48 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> Message-ID: <1151463307.20090220112223@gmail.com> Hello Krasimir, Friday, February 20, 2009, 11:00:30 AM, you wrote: > and this is exactly what we get. I bet that if the original function was: well, you check this yourself! :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kr.angelov at gmail.com Fri Feb 20 03:48:10 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Feb 20 03:37:25 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <1151463307.20090220112223@gmail.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> <1151463307.20090220112223@gmail.com> Message-ID: Well I actually did, almost. I added this function: quotX :: Int -> Int -> Int a `quotX` b | b == 0 = error "divZeroError" | b == (-1) && a == minBound = error "overflowError" | otherwise = a `quotInt` b It does the right thing. However to be sure that this doesn't interfere with some other GHC magic the real quot function have to be changed and tested. I haven't build GHC from source for 2-3 years now and I don't have the time to do it just to test whether this works. Regards, Krasimir On Fri, Feb 20, 2009 at 9:22 AM, Bulat Ziganshin wrote: > Hello Krasimir, > > Friday, February 20, 2009, 11:00:30 AM, you wrote: > >> and this is exactly what we get. I bet that if the original function was: > > well, you check this yourself! :) > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From mechvel at botik.ru Fri Feb 20 04:38:45 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Feb 20 04:31:20 2009 Subject: ./T and ./T >& log Message-ID: <20090220093845.GA14518@scico.botik.ru> People, I observe the output difference in running ./Bug and ./Bug >& log (under Linux) for the program import Dumatel main = do calcInput <- readFile "List0.inp" (putStr $ parseComputeShow calcInput) where parseComputeShow calcInput = concat ["t = ", showsn 3 t "\n", "tR = ", showsn 3 tR "\n"] where calc = addInput_default nilParseOpts (bool rpos) calcInput t = parse_default calc "parsing Term" "(a:nil) + (b:nil)" tR = evaluate emptyUMRMemo AllRules calc t -- I think, it can be reduced to much simpler one. The error break has to occur while computing tR. The difference is in printing or skipping of the result part before tR. The first command outputs --------------------------------- t = ((a : nil) + (b : nil)) Bug: substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X: sort mismatch in substitution --------------------------------- And the second command skips (in ./log) the line of t = ... Who can tell what is the matter? How to have identic outputs in this example? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel@botik.ru From lennart at augustsson.net Fri Feb 20 04:56:36 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Feb 20 04:45:55 2009 Subject: ./T and ./T >& log In-Reply-To: <20090220093845.GA14518@scico.botik.ru> References: <20090220093845.GA14518@scico.botik.ru> Message-ID: I'm just guessing, but it looks like a buffering problem. When a program dies an abnormal death (like the "Bug:" thing probably is) then the stdout buffer is not flushed and you'll miss that bit of the output. You could set stdout in NoBuffering mode and see if that helps. -- Lennart On Fri, Feb 20, 2009 at 9:38 AM, Serge D. Mechveliani wrote: > People, > I observe the output difference in running ./Bug > and ./Bug >& log > (under Linux) for the program > > import Dumatel > main = do calcInput <- readFile "List0.inp" > (putStr $ parseComputeShow calcInput) > where > parseComputeShow calcInput = concat ["t = ", showsn 3 t "\n", > "tR = ", showsn 3 tR "\n"] > where > calc = addInput_default nilParseOpts (bool rpos) calcInput > t = parse_default calc "parsing Term" "(a:nil) + (b:nil)" > tR = evaluate emptyUMRMemo AllRules calc t > > -- I think, it can be reduced to much simpler one. > The error break has to occur while computing tR. > The difference is in printing or skipping of the result part before tR. > The first command outputs > > --------------------------------- > t = ((a : nil) + (b : nil)) > Bug: > substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X: > sort mismatch in substitution > --------------------------------- > > And the second command skips (in ./log) the line of t = ... > Who can tell what is the matter? > How to have identic outputs in this example? > > Thank you in advance for explanation. > > ----------------- > Serge Mechveliani > mechvel@botik.ru > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From allbery at ece.cmu.edu Sat Feb 21 00:53:12 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Feb 21 00:42:39 2009 Subject: ./T and ./T >& log In-Reply-To: <20090220093845.GA14518@scico.botik.ru> References: <20090220093845.GA14518@scico.botik.ru> Message-ID: <59331C48-ED68-4776-B697-84BDEF347126@ece.cmu.edu> On 2009 Feb 20, at 4:38, Serge D. Mechveliani wrote: > The first command outputs > > --------------------------------- > t = ((a : nil) + (b : nil)) > Bug: > substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X: > sort mismatch in substitution > --------------------------------- > > And the second command skips (in ./log) the line of t = ... > Who can tell what is the matter? The ghc runtime doesn't flush stdout when an exception stops the program. This is arguably a bug in the runtime; if you set stdout to line buffering or no buffering you should get pretty much the same output from both. (It's still possible for buffering to cause lines to come out in a different order, so you might prefer unbuffered). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090221/2f512eb0/PGP.bin From bertram.felgenhauer at googlemail.com Sat Feb 21 03:52:00 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 21 03:41:20 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> <1151463307.20090220112223@gmail.com> Message-ID: <499fc0b4.07a5660a.063b.0d32@mx.google.com> Krasimir Angelov wrote: > Well I actually did, almost. I added this function: > > quotX :: Int -> Int -> Int > a `quotX` b > | b == 0 = error "divZeroError" > | b == (-1) && a == minBound = error "overflowError" > | otherwise = a `quotInt` b > > It does the right thing. However to be sure that this doesn't > interfere with some other GHC magic the real quot function have to be > changed and tested. I haven't build GHC from source for 2-3 years now > and I don't have the time to do it just to test whether this works. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers. For a patch, see http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch Nofib results extract: ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed ------------------------------------------------------------------------ fish -0.7% -5.3% 0.05 0.04 primes -0.0% +28.5% +25.6% +25.5% wheel-sieve2 -0.0% -0.3% -17.9% -18.6% ------------------------------------------------------------------------ Min -0.9% -5.3% -17.9% -18.6% Max +0.1% +28.5% +25.6% +25.5% Geometric Mean -0.2% +0.2% -0.0% +0.2% 'primes' is an outlier - the other slowdowns are below 3% What happens in 'primes' is that 'mod' no longer gets inlined; apparently it now looks bigger to the compiler than before. Using -funfolding-use-threshold=10 brings the benchmark back to its original speed, despite the extra comparison before doing the division. In 'wheel-sieve2', the first different optimization choice I see is again a 'mod' that is no longer inlined; this leads to a change in other inlining choices that result in a speedup for reasons that I have not investigated. Bertram From kr.angelov at gmail.com Sat Feb 21 04:23:39 2009 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sat Feb 21 04:12:56 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: <499fc0b4.07a5660a.063b.0d32@mx.google.com> References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> <1151463307.20090220112223@gmail.com> <499fc0b4.07a5660a.063b.0d32@mx.google.com> Message-ID: How mod is affected by the change in quot? Currently mod is defined as: a `mod` b | b == 0 = divZeroError | a == minBound && b == (-1) = overflowError | otherwise = a `modInt` b and modInt is defined via remInt# which is primitive. Did you change the definition of mod as well? I agree that this change in the definition of quot is just a workaround. The best solution would be to do something clever in the compiler itself. For now if someone wants fast division then he/she should use quotInt. On Sat, Feb 21, 2009 at 9:52 AM, Bertram Felgenhauer wrote: > Krasimir Angelov wrote: >> Well I actually did, almost. I added this function: >> >> quotX :: Int -> Int -> Int >> a `quotX` b >> | b == 0 = error "divZeroError" >> | b == (-1) && a == minBound = error "overflowError" >> | otherwise = a `quotInt` b >> >> It does the right thing. However to be sure that this doesn't >> interfere with some other GHC magic the real quot function have to be >> changed and tested. I haven't build GHC from source for 2-3 years now >> and I don't have the time to do it just to test whether this works. > > It works, and it has the desired effect. It's not always a win though; > the nofib prime sieve benchmark suffers. > > For a patch, see > http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch > > Nofib results extract: > > ------------------------------------------------------------------------ > Program Size Allocs Runtime Elapsed > ------------------------------------------------------------------------ > fish -0.7% -5.3% 0.05 0.04 > primes -0.0% +28.5% +25.6% +25.5% > wheel-sieve2 -0.0% -0.3% -17.9% -18.6% > ------------------------------------------------------------------------ > Min -0.9% -5.3% -17.9% -18.6% > Max +0.1% +28.5% +25.6% +25.5% > Geometric Mean -0.2% +0.2% -0.0% +0.2% > > 'primes' is an outlier - the other slowdowns are below 3% > > What happens in 'primes' is that 'mod' no longer gets inlined; > apparently it now looks bigger to the compiler than before. > > Using -funfolding-use-threshold=10 brings the benchmark back to its > original speed, despite the extra comparison before doing the > division. > > In 'wheel-sieve2', the first different optimization choice I see is > again a 'mod' that is no longer inlined; this leads to a change in other > inlining choices that result in a speedup for reasons that I have not > investigated. > > Bertram > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bertram.felgenhauer at googlemail.com Sat Feb 21 04:37:22 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 21 04:26:39 2009 Subject: Compiler optimizations questions for ghc 6.10... In-Reply-To: References: <200902171550.45001.twhitehead@gmail.com> <9d4d38820902191419x3d3c0a9at95b97c77c31797f1@mail.gmail.com> <200902192200.08488.twhitehead@gmail.com> <1151463307.20090220112223@gmail.com> <499fc0b4.07a5660a.063b.0d32@mx.google.com> Message-ID: <499fcb54.0710660a.0e85.27e2@mx.google.com> Krasimir Angelov wrote: > How mod is affected by the change in quot? Currently mod is defined as: > > a `mod` b > | b == 0 = divZeroError > | a == minBound && b == (-1) = overflowError > | otherwise = a `modInt` b > > and modInt is defined via remInt# which is primitive. Did you change > the definition of mod as well? Yes I did. div, mod, quot, rem, divMod, quotRem, for Ints of various sizes. Everything. Bertram From sof at galois.com Sat Feb 21 17:50:54 2009 From: sof at galois.com (Sigbjorn Finne) Date: Sat Feb 21 17:40:02 2009 Subject: Building GHC on Windows In-Reply-To: <499D7697.8060604@gmail.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> <499D7697.8060604@gmail.com> Message-ID: <49A0854E.9010602@galois.com> Simon Marlow wrote: > Felix Martini wrote: > ..... >> >> All this is likely trivial to fix but at the same time these little >> roadblocks may also explain why few developers on Windows contribute >> code to GHC and Haskell. > > I haven't tried sync-all on Windows - can anyone help out here? > It works fine, but be mindful of how 'git' handles crlf translations on Windows. Having run into this a couple of times, it certainly looks the likely cause. Felix may want to try cloning as follows: foo$ git config --global core.autocrlf false foo$ git clone http://darcs.haskell.org/ghc.git hth --sigbjorn From fmartini at gmail.com Sat Feb 21 18:40:46 2009 From: fmartini at gmail.com (Felix Martini) Date: Sat Feb 21 18:29:56 2009 Subject: Building GHC on Windows In-Reply-To: <49A0854E.9010602@galois.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> <499D7697.8060604@gmail.com> <49A0854E.9010602@galois.com> Message-ID: <6c0416190902211540k46acd543if73c3dd154b44c28@mail.gmail.com> Sigbjorn Finne: > It works fine, but be mindful of how 'git' handles crlf translations on > Windows. > Having run into this a couple of times, it certainly looks the likely cause. > Felix > may want to try cloning as follows: > > foo$ git config --global core.autocrlf false > foo$ git clone http://darcs.haskell.org/ghc.git Unfortunately i cannot change the global autocrlf flag because of other projects. I edited the sync-all script to fix the problem, but is good to know that line conversions may be the cause. It would be nice if sync-all (and other scripts) were written in portable Perl. Perl runs well on Windows whereas msys is brittle. Regards, Felix From sof at galois.com Sat Feb 21 18:51:17 2009 From: sof at galois.com (Sigbjorn Finne) Date: Sat Feb 21 18:40:27 2009 Subject: Building GHC on Windows In-Reply-To: <6c0416190902211540k46acd543if73c3dd154b44c28@mail.gmail.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> <499D7697.8060604@gmail.com> <49A0854E.9010602@galois.com> <6c0416190902211540k46acd543if73c3dd154b44c28@mail.gmail.com> Message-ID: <49A09375.5060502@galois.com> Felix Martini wrote: > Sigbjorn Finne: > >> It works fine, but be mindful of how 'git' handles crlf translations on >> Windows. >> Having run into this a couple of times, it certainly looks the likely cause. >> Felix >> may want to try cloning as follows: >> >> foo$ git config --global core.autocrlf false >> foo$ git clone http://darcs.haskell.org/ghc.git >> > > Unfortunately i cannot change the global autocrlf flag because of > other projects. I edited the sync-all script to fix the problem, but > is good to know that line conversions may be the cause. It would be > nice if sync-all (and other scripts) were written in portable Perl. > Perl runs well on Windows whereas msys is brittle. > > ok. Surely you could just temporarily set it as such, followed by config'ing it for that repo only rather than have it be global? I suspect tweaking that one file instead will just be the first of many such tweaks.. --sigbjorn From fmartini at gmail.com Sat Feb 21 18:56:03 2009 From: fmartini at gmail.com (Felix Martini) Date: Sat Feb 21 18:45:11 2009 Subject: Building GHC on Windows In-Reply-To: <49A09375.5060502@galois.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> <499D7697.8060604@gmail.com> <49A0854E.9010602@galois.com> <6c0416190902211540k46acd543if73c3dd154b44c28@mail.gmail.com> <49A09375.5060502@galois.com> Message-ID: <6c0416190902211556k20f1d823y4e0eaf0ba91af3ab@mail.gmail.com> Sigbjorn Finne: > ok. Surely you could just temporarily set it as such, followed by config'ing > it for that repo only > rather than have it be global? I suspect tweaking that one file instead will > just be the first of > many such tweaks.. Yes, that would be the best solution if i want to download the GHC source code again. From colin at colina.demon.co.uk Sun Feb 22 03:02:13 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Feb 22 02:51:25 2009 Subject: [Haskell-beginners] Baffled by Parsec In-Reply-To: (Felipe Lessa's message of "Sun\, 22 Feb 2009 04\:53\:15 -0300") References: <200902212210.36616.daniel.is.fischer@web.de> Message-ID: >>>>> "Felipe" == Felipe Lessa writes: Felipe> On Sun, Feb 22, 2009 at 4:50 AM, Colin Paul Adams Felipe> wrote: >> OK - I see it here, but I was looking in >> Text.ParserCombinators.Parsec.Char, where I can't see it (I can >> see satisfy). I can't see how I am supposed to make that >> apparently disconnected leap (other than by asking here, which >> works :-) ) Felipe> It is there, too! =P Felipe> http://hackage.haskell.org/packages/archive/parsec/3.0.0/doc/html/Text-ParserCombinators-Parsec-Char.html#v%3Adigit Hm. It's not on my local copy of the GHC libraries documentation (ghc 6.10.1), although if I click the source button, I can see it. -- Colin Adams Preston Lancashire From aslatter at gmail.com Sun Feb 22 03:19:00 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 22 03:08:09 2009 Subject: [Haskell-beginners] Baffled by Parsec In-Reply-To: References: <200902212210.36616.daniel.is.fischer@web.de> Message-ID: <694519c50902220019g3c51872dy323dbaeb00fb5767@mail.gmail.com> On Sun, Feb 22, 2009 at 2:14 AM, Felipe Lessa wrote: > > My GHC 6.10.1 was compiled from source and Parsec comes from a > different ebuild (Gentoo), and digit isn't documented as well. It must > be some problem with parsec < 3, because Hackage has the same problem > for old Parsec[1]. > > [1] http://hackage.haskell.org/packages/archive/parsec/2.1.0.1/doc/html/Text-ParserCombinators-Parsec-Char.html > >From the sources: > upper, lower, alphaNum, letter, digit, hexDigit, octDigit :: CharParser st Char I think I've seen Haddock have trouble documenting declarations which share a type signature in other places, as well. Antoine From ndmitchell at gmail.com Sun Feb 22 04:23:09 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Feb 22 04:12:22 2009 Subject: DLL support with GHC In-Reply-To: <49996DBB.2060407@gmail.com> References: <404396ef0902130229j28d58ac0u16affeb246782e8f@mail.gmail.com> <49996DBB.2060407@gmail.com> Message-ID: <404396ef0902220123mef4455eh52fa81e099eb401@mail.gmail.com> >> What is the current status of shared object support within GHC? Using >> GHC 6.10.2 (or the branch for it) I can create DLL's under Windows, >> following these instructions: >> http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html >> .Can a similar thing be done under Linux? If so, where is this >> documented? > > No, you can't do that yet. ?Here's the ticket: > > http://hackage.haskell.org/trac/ghc/ticket/1876 Thanks, I've added myself to the CC. Neil From marlowsd at gmail.com Mon Feb 23 04:26:39 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 23 04:15:51 2009 Subject: Building GHC on Windows In-Reply-To: <49A0854E.9010602@galois.com> References: <6c0416190902170908x1ff225cay817c63f88348871d@mail.gmail.com> <499D7697.8060604@gmail.com> <49A0854E.9010602@galois.com> Message-ID: <49A26BCF.7040703@gmail.com> Sigbjorn Finne wrote: > Simon Marlow wrote: >> Felix Martini wrote: >> ..... >>> >>> All this is likely trivial to fix but at the same time these little >>> roadblocks may also explain why few developers on Windows contribute >>> code to GHC and Haskell. >> >> I haven't tried sync-all on Windows - can anyone help out here? >> > It works fine, but be mindful of how 'git' handles crlf translations on > Windows. > Having run into this a couple of times, it certainly looks the likely > cause. Felix > may want to try cloning as follows: > > foo$ git config --global core.autocrlf false > foo$ git clone http://darcs.haskell.org/ghc.git I added a note about this to the wiki, could someone who actually understands what's going on check what I've written and edit if necessary: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingaGHCsourcetreeusinggit Cheers, Simon From marlowsd at gmail.com Mon Feb 23 06:16:12 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 23 06:05:22 2009 Subject: ./T and ./T >& log In-Reply-To: <59331C48-ED68-4776-B697-84BDEF347126@ece.cmu.edu> References: <20090220093845.GA14518@scico.botik.ru> <59331C48-ED68-4776-B697-84BDEF347126@ece.cmu.edu> Message-ID: <49A2857C.2060601@gmail.com> Brandon S. Allbery KF8NH wrote: > On 2009 Feb 20, at 4:38, Serge D. Mechveliani wrote: >> The first command outputs >> >> --------------------------------- >> t = ((a : nil) + (b : nil)) >> Bug: >> substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X: >> sort mismatch in substitution >> --------------------------------- >> >> And the second command skips (in ./log) the line of t = ... >> Who can tell what is the matter? > > The ghc runtime doesn't flush stdout when an exception stops the > program. This is arguably a bug in the runtime; if you set stdout to > line buffering or no buffering you should get pretty much the same > output from both. (It's still possible for buffering to cause lines to > come out in a different order, so you might prefer unbuffered). stdout should be flushed when the program exits, regardless of whether it exits as a result of a clean exit or an exception. I've just checked the code, and that's certainly what is supposed to happen. If anyone has evidence to the contrary, please submit a bug report! Cheers, Simon From phercek at gmail.com Mon Feb 23 14:18:43 2009 From: phercek at gmail.com (Peter Hercek) Date: Mon Feb 23 14:08:04 2009 Subject: how dynamic stack approximation works In-Reply-To: <499A794F.3020108@gmail.com> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> Message-ID: Simon Marlow wrote: > Perhaps you're already aware of this wiki page, but I'll post the link > anyway: > > http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack I was writing about a way how to maintain the stack as described in point 6 of the page (provided that point is about dynamic stack). The point only says it would be fine to have stack without hints how to do it. > > The dynamic call stack is already present, in the form of the runtime > execution stack. For debugging you might want to track more > information than we store on this stack, however. Does GHC have the same stack for both return addresses and arguments or are they separated? I assumed separated but I'm in doubt now. Do you have enough (debug) information there already to at least match arguments to function calls? My point is that having an exact stack is probably better if it is not too hard to do. On the other side if there is not enough debug information already present, it may be easier to to maintain an approximate debugging stack because most of the information needed for it is already in there. As I already said in other emails, I would rather choose dynamic stack over lexical one if I was forced to choose only one of them. Actually, I almost do not care about lexical stack and still do not understand why people want it. Even for profiling it looks fishy because at least in some cases it behaves like a dynamic stack (time is attributed where expression is forced not where the expression looks to be in the lexical stack). > You seem to have a plan for maintaining a dynamic stack for debugging, > perhaps you could flesh out the details in a wiki page, mainly to > ensure that we're discussing the same thing? Sure, but the plan to maintain an approximate debugging dynamic stack depends on one thing: The number of items (continuations) on the return stack from the beginning of /case tick of {_->e}/ to the moment when we can check the count of items in the return stack inside /tick/ is constant and known for a given runtime version of ghc. Or variable but known for each call individually. This is important to find out the number of return addresses on the return stack just before the execution of /case tick of {_->e}/. This looks achievable to me, but maybe it is not. Do you think the condition can be satisfied without too much work? If yes, I'll go on to write the page. If not it would be waste of time. Thanks, Peter. From Malcolm.Wallace at cs.york.ac.uk Tue Feb 24 05:51:44 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Feb 24 05:41:59 2009 Subject: ./T and ./T >& log In-Reply-To: <49A2857C.2060601@gmail.com> References: <20090220093845.GA14518@scico.botik.ru> <59331C48-ED68-4776-B697-84BDEF347126@ece.cmu.edu> <49A2857C.2060601@gmail.com> Message-ID: <20090224105144.16f0172c.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > stdout should be flushed when the program exits, regardless of whether > it exits as a result of a clean exit or an exception. I've just > checked the code, and that's certainly what is supposed to happen. > If anyone has evidence to the contrary, please submit a bug report! I believe flushing of file handles on program exit is handled by finalizers attached to the handle. Until recently, ghc did not guarantee that any finalizer would ever run. Regards, Malcolm From Malcolm.Wallace at cs.york.ac.uk Tue Feb 24 05:49:32 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Feb 24 05:42:01 2009 Subject: how dynamic stack approximation works In-Reply-To: References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> Message-ID: <20090224104932.088890dc.Malcolm.Wallace@cs.york.ac.uk> Peter Hercek wrote: > > http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack > > I was writing about a way how to maintain the stack as described in > point 6 of the page (provided that point is about dynamic stack). The whole page (including point 6) is about explicitly maintaining a (simulated) lexical call stack, not the dynamic one. > As I already said in other emails, I would rather choose dynamic stack > over lexical one if I was forced to choose only one of them. Actually, > I almost do not care about lexical stack and still do not understand > why people want it. In a lazy language, the dynamic stack rarely tells you anything of interest for debugging. For the value at the top of the stack, you get one of many possible _demand_ chains, rather than the creation chain. The demanding location is pretty-much guaranteed not to be the site of the bug. But you can think of the lexical call stack as what _would_ have been the dynamic call stack, if only the language were completely strict rather than lazy. Most people find the latter notion more intuitive for the purposes of finding program errors. > Sure, but the plan to maintain an approximate debugging dynamic stack > depends on one thing: There is no need to approximate the dynamic stack. It is directly available to the RTS, in full detail. Regards, Malcolm From marlowsd at gmail.com Tue Feb 24 08:31:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 24 08:21:08 2009 Subject: how dynamic stack approximation works In-Reply-To: References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> Message-ID: <49A3F6CC.4060008@gmail.com> Peter Hercek wrote: > Simon Marlow wrote: >> You seem to have a plan for maintaining a dynamic stack for debugging, >> perhaps you could flesh out the details in a wiki page, mainly to >> ensure that we're discussing the same thing? > > Sure, but the plan to maintain an approximate debugging dynamic stack > depends on one thing: > The number of items (continuations) on the return stack from the > beginning of /case tick of {_->e}/ to the moment when we can check > the count of items in the return stack inside /tick/ is constant and > known for a given runtime version of ghc. Or variable but known for each > call individually. This is important to find out the number of return > addresses on the return stack just before the execution of /case tick > of {_->e}/. I don't fully understand what it is you mean. e.g. I don't know what "from the beginning of /case tick of {_->e}/" means. Let me try to explain a couple of things that might (or might not!) help clarify. We don't normally see case tick of { _ -> e } because the byte-code generator turns this into let z = case tick of { _ -> e } in z the debugger paper explains why we do this. Anyway, the byte code for the closure for z does this: - if the breakpoint at is enabled then stop, - otherwise, evaluate e i.e. it doesn't push any stack frames. Does that help frame your question? Cheers, Simon From marlowsd at gmail.com Tue Feb 24 08:36:25 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 24 08:25:33 2009 Subject: ./T and ./T >& log In-Reply-To: <20090224105144.16f0172c.Malcolm.Wallace@cs.york.ac.uk> References: <20090220093845.GA14518@scico.botik.ru> <59331C48-ED68-4776-B697-84BDEF347126@ece.cmu.edu> <49A2857C.2060601@gmail.com> <20090224105144.16f0172c.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <49A3F7D9.6080001@gmail.com> Malcolm Wallace wrote: > Simon Marlow wrote: > >> stdout should be flushed when the program exits, regardless of whether >> it exits as a result of a clean exit or an exception. I've just >> checked the code, and that's certainly what is supposed to happen. >> If anyone has evidence to the contrary, please submit a bug report! > > I believe flushing of file handles on program exit is handled by > finalizers attached to the handle. Until recently, ghc did not > guarantee that any finalizer would ever run. Not exactly. There's a top-level exception handler that flushes stdout and stderr, so they always get flushed on exit (or at least, they are supposed to). Look in base:GHC.TopHandler for the code. Other handlers will only get flushed if their finalizers run, and nothing has changed here: we now guarantee execution of C finalizers, but that doesn't apply to the finalizers for Handles, which are Haskell code. Cheers, Simon From james.swaine at gmail.com Tue Feb 24 12:20:36 2009 From: james.swaine at gmail.com (James Swaine) Date: Tue Feb 24 12:09:38 2009 Subject: Performance Issue Message-ID: <5195fdde0902240920t76e6611fua1f9264751c43cbf@mail.gmail.com> i'm implementing a benchmark which includes a detailed specification for a random number generator. for any of the kernels outlined in the benchmark, i might have to generate a set of random numbers R, which has a length n, using the following formulas: R[k] = ((2^-46)(X[k])) mod 2^46, where X[k] = (a^k)s where the values of a and s are constant and defined below. many of the kernels in the benchmark require a large number of randoms to be generated (in the tens of millions). when i invoke the following getRandAt function that many times to build up a list, evaluation of the list takes forever (somewhere between 5 and 10 minutes). i've tried optimizing this several different ways, with no luck. i though i might post my code here and see if anyone notices anything i'm doing wrong that might be causing such a large bottleneck: --constants a :: Int64 a = 5^13 divisor :: Int64 divisor = 2^46 multiplier :: Float multiplier = 2**(-46) --gets r[k], which is the value at the kth --position in the overall sequence of --pseudorandom numbers getRandAt :: Int64 -> Int64 -> Float getRandAt 0 seed = multiplier * (fromIntegral seed) getRandAt k seed = multiplier * (fromIntegral x_next) where x_prev = (a^k * seed) `mod` divisor x_next = (a * x_prev) `mod` divisor thanks all in advance for your help! -james -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090224/3b80fbc5/attachment-0001.htm From ben.franksen at online.de Tue Feb 24 14:49:54 2009 From: ben.franksen at online.de (Ben Franksen) Date: Tue Feb 24 14:39:07 2009 Subject: Bug in STM with data invariants Message-ID: My ghc(i) crashes when using STM data invariants. This little piece of code demonstrates the problem: module Bug where import Control.Concurrent.STM test = do x <- atomically $ do v <- newTVar 0 always $ return True -- remove this line and all is fine return v atomically (readTVar x) >>= print This is what ghci makes of it: ben@sarun> ghci Bug.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. *Bug> test Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package stm-2.1.1.2 ... linking ... done. zsh: segmentation fault ghci Bug.hs I am using ghc-6.10.1 freshly installed from source with just a 'cabal install stm' thrown after it. BTW, the documentation for Control.Concurrent.STM.TVar lists... nothing. Similar with Control.Monad.STM. Well, at least the source link works, so one isn't completely lost... :-) Cheers Ben From claus.reinke at talk21.com Tue Feb 24 18:57:17 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Feb 24 18:46:24 2009 Subject: optimization and rewrite rules questions Message-ID: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> In the recently burried haskell-cafe thread "speed: ghc vs gcc", Bulat pointed out some of the optimizations that GHC doesn't do, such as loop unrolling. I suggested a way of experimenting with loop unrolling, using template haskell to bypass GHC's blindspot (it usually doesn't unfold recursive definitions http://www.haskell.org/pipermail/glasgow-haskell-users/2007-July/012936.html , but if we unfold a loop combinator at compile time, GHC's normal optimizations can take over from there): http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html While this is fine as far as it goes (it should really be handled within GHC), and does offer some initial speedup, Bulat pointed out that GCC does further optimizations after unrolling, such as reassociating sums to expose potential for constant folding: http://www.haskell.org/pipermail/haskell-cafe/2009-February/056367.html (since the ghc -ddump-simpl output doesn't show this optimization, I assume that gcc handles it, and the "*ghc*" in that message is a typo, but haven't checked - how would I do that, btw?). In this case, GHC optimizations following the loop unrolling leave a sum like (note the repeated variable interspersed with constants) (GHC.Prim.+# (GHC.Prim.+# ww_s1lN 3) (GHC.Prim.+# (GHC.Prim.+# ww_s1lN 2) (GHC.Prim.+# (GHC.Prim.+# ww_s1lN 1) (GHC.Prim.+# (GHC.Prim.+# ww_s1lN 0) ww_s1lR)))))))) which can be simplified (assuming associativity and commutativity of + here..) after sorting the variable references and constants into separate groups. We currently inherit such optimizations when using -fvia-C, even though GHC sometimes produces C code that GCC can't handle optimally. If I understand correctly, -fvia-C is on its way out - is that correct, and what plans are there for recovering the optimizations previously left to GCC? The next thing I was looking at was rewrite rules, the obvious GHC tool for implementing this kind of rule (var+const1)+(var+const2) ==> 2*var + const3 and I ran into more questions: - can RULES left-hand sides test for variables (I don't want to reassociate sums randomly, that wouldn't terminate; instead, I want to float out subterms that are non-variable, and group repeated variables)? - is there any way to control the rewrite strategy, similar to strategy combinators (if rules are applied all over the place, they introduce new structure not covered by rules; if I could limit the strategy to top-down, or bottom-up, I could at least cover some special cases)? - how would one handle this kind of optimization in GHC in full generality? wait for compiler plugins? are there features of rewrite rules that I'm missing? would it make sense to flag rewrite rules system improvements as a GHC GSoC project, given that GHC will have to pull its weight there when moving away from GCC? Claus From simonpj at microsoft.com Wed Feb 25 03:38:00 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 25 03:27:02 2009 Subject: Bug in STM with data invariants In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C333996B9507@EA-EXMSG-C334.europe.corp.microsoft.com> Thank you for a nicely characterised bug report. GHC should never crash! I've created a trac ticket http://hackage.haskell.org/trac/ghc/ticket/3049 Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Ben Franksen | Sent: 24 February 2009 19:50 | To: glasgow-haskell-users@haskell.org | Subject: Bug in STM with data invariants | | My ghc(i) crashes when using STM data invariants. This little piece of code | demonstrates the problem: | | module Bug where | | import Control.Concurrent.STM | | test = do | x <- atomically $ do | v <- newTVar 0 | always $ return True -- remove this line and all is fine | return v | atomically (readTVar x) >>= print | | This is what ghci makes of it: | | ben@sarun> ghci Bug.hs | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help | Loading package ghc-prim ... linking ... done. | Loading package integer ... linking ... done. | Loading package base ... linking ... done. | [1 of 1] Compiling Bug ( Bug.hs, interpreted ) | Ok, modules loaded: Bug. | *Bug> test | Loading package syb ... linking ... done. | Loading package array-0.2.0.0 ... linking ... done. | Loading package stm-2.1.1.2 ... linking ... done. | zsh: segmentation fault ghci Bug.hs | | I am using ghc-6.10.1 freshly installed from source with just a 'cabal | install stm' thrown after it. | | BTW, the documentation for Control.Concurrent.STM.TVar lists... nothing. | Similar with Control.Monad.STM. Well, at least the source link works, so | one isn't completely lost... :-) | | Cheers | Ben | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From phercek at gmail.com Wed Feb 25 13:19:54 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Feb 25 13:09:07 2009 Subject: queued GHCi commands are not context specific; a bug? Message-ID: Hi GHCi users, The example is at the end of this email. I think it is a bug that the second part (:continue) of the command `:cmd return "rv\n:continue"' is executed in a different context than the first part (rv (request for the value of rv variable)). Notice that we did not stop at breakpoint 1 (line 7). Well, the stop happened but it continued immediately because of queued :continue command. But the command was queued in the context of breakpoint 0 and not breakpoint 1. Is it a feature or a bug? If it is a feature it is not good for scripting breakpoints :-/ ... and I do not see an easy way to work around it. Thanks, Peter. PS: I owe responses to some of you on this list, but I must check some docs or do some tests first so I hope I'll answer during weekend at worst. *status:0 peter@metod [716] ~/tmp %* grep -n '^' b.hs 1:fn :: Int -> Int 2:fn x = 3: let rv = add x 1 in 4: rv 5: 6:add :: Int -> Int -> Int 7:add a b = a + b *status:0 peter@metod [717] ~/tmp %* ghci b.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( b.hs, interpreted ) Ok, modules loaded: Main. *Main> :set stop :list *Main> :break 4 Breakpoint 0 activated at b.hs:4:2-3 *Main> :break 7 Breakpoint 1 activated at b.hs:7:0-14 *Main> fn 100 Stopped at b.hs:4:2-3 _result :: Int = _ rv :: Int = _ 3 let rv = add x 1 in 4 *rv* 5 [b.hs:4:2-3] *Main> :cmd return "rv\n:continue" Stopped at b.hs:7:0-14 _result :: Int = _ 6 add :: Int -> Int -> Int 7 *add a b = a + b* 8 101 [b.hs:4:2-3] *Main> :continue 101 *Main> :q Leaving GHCi. *status:0 peter@metod [718] ~/tmp % * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090225/9bc91686/attachment.htm From claus.reinke at talk21.com Wed Feb 25 19:01:11 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Feb 25 18:50:24 2009 Subject: optimization and rewrite rules questions References: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> Message-ID: Okay, I've found a combination of incantations that happens to work, but only for this particular example. So this does not solve the original questions, and I'm still interested in suggestions. But it does give a concrete example of what I'd like to be able to do (or better, what GHC should be doing, and GCC apparently does), in the hope that this helps the discussion along. This message a bit lengthy, as I try to summarize the approach, for those here who didn't follow the haskell-cafe thread earlier (so this should be fairly self-contained) and include timings. 1. Old things first, the TH macro for syntactic replication of calls to 'f', each call getting its own counter 'i', and 'x' as the first parameter: ------------------------------------------------------------------ {-# LANGUAGE TemplateHaskell #-} module Apply where import Language.Haskell.TH.Syntax apply i bound | i $(apply (i+1) bound) f (f i x) |] | otherwise = [| \f x -> x |] ------------------------------------------------------------------ 2. Next, we use this to define an unrolling 'loop' combinator on 'Int', which counts from 'i' to 'max', applying 'body' to the count 'i' and an accumulator 'acc'. Thanks to 'apply' and TH, we can parameterize this code over the number of unrollings 'N' (N=8 here), without having to write out the syntactic unrolling ourselves (this is the only use of TH here, so unlike earlier approaches, we do not implement loop unrolling by any TH-based syntactic analysis, we just syntactically generate a function that will do the unrolling semantically). 'loop' is marked INLINE, and is in a worker/wrapper form, so that the wrapper will be inlined at the call site, bringing the 'body' parameter into scope for the worker, in order to allow GHC to apply further simplifications to the unfolded 'body' applications. ------------------------------------------------------------------ {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE BangPatterns #-} {-# OPTIONS_GHC -DN=8 -ddump-splices #-} module Loop(loop) where import Apply {-# INLINE loop #-} loop :: Int -> Int -> (Int -> Int -> Int) -> Int -> Int loop i max body acc = loopW i acc where loopW :: Int -> Int -> Int loopW !i !acc | i+N<=max = loopW (i+N) ($(apply (0::Int) N) (\j acc->body (i+j) acc) acc) loopW !i !acc | i<=max = loopW (i+1) (body i acc) | otherwise = acc ------------------------------------------------------------------ 3. Finally, the main program, using 'loop' to calculate a simple sum: ------------------------------------------------------------------ {-# LANGUAGE MagicHash #-} module Main where import Loop import GHC.Prim {-# RULES "re-assoc" [~1] forall v x y z. (x+#y)+#(z+#v) = ((x+#y)+#z)+#v "collect1" [1] forall x y. (x+#y)+#x = (2#*#x)+#y "collect2" [1] forall n x y. ((n*#x)+#y)+#x = ((n+#1#)*#x)+#y "collect3" [1] forall n x y z. ((n*#x)+#y)+#z = (n*#x)+#(y+#z) #-} main = print $ loop 1 (10^9) body 0 body :: Int -> Int -> Int body i acc = i+acc ------------------------------------------------------------------ 4. If we ignore the RULES, we note the following: - GHC nicely unrolls the 'loop' and simplifies the both the calls to 'body' and the overhead introduced by our use of 'apply' out of the way, which gives some first improvements in speed, but -fasm is noticeable slower than -fvia-C, so GCC does further optimizations; - a likely candidate are arithmetic laws (associativity/commutativity of '+'), in order to enable constant folding - of the two purposes of loop unrolling, (a) less admin overhead and more straightforward code, (b) enable further optimizations (just like any other unfolding/inlining, but on recursive code), GHC -fasm, even with help from TH, only achieves the first. The interesting bit of core is the one corresponding to the call to 'apply' (for N=8) in the definition of 'loopW' ('ww1_s18W' is the counter variable, 'ww2_s190' is the accumulator): $wloopW_s19d (GHC.Prim.+# ww1_s18W 8) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 7) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 6) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 5) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 4) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 3) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 2) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 1) (GHC.Prim.+# (GHC.Prim.+# ww1_s18W 0) ww2_s190)))))))) Note the various constants, interspersed with copies of the counter variable. If we could sort those into two separate groups, we could evaluate the sum of constants, and simplify the repeated additions of the counter variable. Which is the bit which I don't know how to do in general fashion. But here's the non-general hack, using RULES: I 'reassoc' reassociates the '+' applications from a tree to a simple linear list II 'collectN' perform the grouping into counter variable and constants (by dead reckoning rather than proper analysis:-( 'collect1' and 'collect2' collect the counter variables, 'collect3' collects the constants III phase control (rather unintuitive, imho) is used to keep the 'reassoc' and 'collectN' rules from interfering with each other, rule order is used to limit the applicability of 'collect3' to expressions which do not match 'collect2''s left-hand side (I think?) II is where I'd like to be able to distinguish variables, constants, and complex expressions in the left-hand sides of RULES, and I and III are where I'd like control over the rewrite strategy, as in strategy combinators. The resulting core, for the same position as before ('ww1_s193' is the counter variable, 'ww2_s197' is the accumulator): $wloopW_s19k (GHC.Prim.+# ww1_s193 8) (GHC.Prim.+# (GHC.Prim.*# 8 ww1_s193) (GHC.Prim.+# 28 ww2_s197)) Nice. But I'd like to get there without cheating, with generally applicable RULES. How? Claus ================================================= PS. Some numbers for general entertainment (times are best of 5, GHC is ghc-6.11.20090118, GCC is 3.4.2 (mingw-special)): ------------------------------------------------------------------ $ ghc --make -O2 -fasm Main.hs -ddump-simpl -fno-enable-rewrite-rules >loop.simpl [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m1.080s user 0m0.015s sys 0m0.031s ------------------------------------------------------------------ $ ghc --make -O2 -fasm Main.hs -ddump-simpl >loop.simpl [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m0.569s user 0m0.015s sys 0m0.031s ------------------------------------------------------------------ $ ghc --make -O2 -fvia-C Main.hs -ddump-simpl -fno-enable-rewrite-rules >loop.simpl [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m0.641s user 0m0.031s sys 0m0.015s ------------------------------------------------------------------ Oh, and that '-fvia-C' does seem to pass '-O2' to GCC, but that does not imply '-funroll-loops': The compiler does not perform loop unrolling or function inlining when you specify -O2. If we repeat the experiment with the unrolling branch in 'loopW' commented out, we don't seem to get unrolling from GCC either (is this a case of GHC-generated code not being palatable to GCC, or am I doing something wrong?), but -fasm is still slower than -fvia-C: ------------------------------------------------------------------ $ ghc --make -O2 -fvia-C Main.hs -ddump-simpl >loop.simpl [1 of 3] Compiling Apply ( Apply.hs, Apply.o ) [2 of 3] Compiling Loop ( Loop.hs, Loop.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m3.437s user 0m0.015s sys 0m0.015s ------------------------------------------------------------------ $ ghc --make -O2 -fvia-C -optc -funroll-loops Main.hs -ddump-simpl >loop.simpl [1 of 3] Compiling Apply ( Apply.hs, Apply.o ) [2 of 3] Compiling Loop ( Loop.hs, Loop.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m3.428s user 0m0.015s sys 0m0.015s ------------------------------------------------------------------ $ ghc --make -O2 -fasm Main.hs -ddump-simpl >loop.simpl [1 of 3] Compiling Apply ( Apply.hs, Apply.o ) [2 of 3] Compiling Loop ( Loop.hs, Loop.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ time ./Main.exe -243309312 real 0m4.065s user 0m0.015s sys 0m0.015s ------------------------------------------------------------------ So, unrolling gives the main benefit (4.1 -> 1.1), but arithmetic optimizations are still profitable (1.1 -> 0.6). The latter are somewhat application-specific (if the loop operated on a Map, other RULES would apply), but would seem useful (if they could be made to work) independent of loop unrolling. And -fvia-C still tends to be faster than -fasm. From ndmitchell at gmail.com Thu Feb 26 05:31:58 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 26 05:20:56 2009 Subject: finally part run twice on Ctrl-C Message-ID: <404396ef0902260231h7c162772kea1ba1746094b239@mail.gmail.com> Hi, I've got the following code: import Control.Exception import System.Cmd main = system "sleep 1m" `finally` putStrLn "goodbye" When compiled with GHC 6.10.1.20090225, if I hit Ctrl-C during the sleep, I get the goodbye printed twice. If I leave evaluation to finish normally I get goodbye once. Is this a bug? Thanks Neil From simonpj at microsoft.com Thu Feb 26 07:51:37 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 26 07:40:45 2009 Subject: optimization and rewrite rules questions In-Reply-To: References: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399740E59@EA-EXMSG-C334.europe.corp.microsoft.com> | II is where I'd like to be able to distinguish variables, constants, | and complex expressions in the left-hand sides of RULES, and | I and III are where I'd like control over the rewrite strategy, as | in strategy combinators. I'm deep in icfp submissions, so no time to reply properly. You can distinguish between literals, variables etc, in GHC's BuiltinRules. These are not hard to write: see prelude/PrelRules. But they are built in, not part of the source program. Maybe that's ok, since you are messing with built-in arithmetic. Another avenue is to elaborate the language of rules somehow to let you say what you want. But I don't know a good *spec* for such a feature, let alone an impl. Another possibility is to write a Core-to-Core optimiser aimed at your target area. Max B's plugins would let you dynamically link that to a distributed GHC. But it's not in the HEAD yet... Simon From batterseapower at hotmail.com Thu Feb 26 08:33:25 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Feb 26 08:22:21 2009 Subject: optimization and rewrite rules questions In-Reply-To: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> References: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> Message-ID: <9d4d38820902260533m6dfe83dcp7db610ee37f1d84f@mail.gmail.com> 2009/2/24 Claus Reinke : > In the recently burried haskell-cafe thread "speed: ghc vs gcc", > Bulat pointed out some of the optimizations that GHC doesn't > do, such as loop unrolling. I suggested a way of experimenting with loop > unrolling, using template haskell to bypass GHC's blindspot (it usually > doesn't unfold recursive definitions > http://www.haskell.org/pipermail/glasgow-haskell-users/2007-July/012936.html > , > but if we unfold a loop combinator at compile time, GHC's > normal optimizations can take over from there): > > http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html Just a note - there is a solution that doesn't require Template Haskell which I use in my own code. Here is a sketch: fact = fix4 fact_worker {-# INLINE fact_worker #-} fact_worker recurse n | n <= 0 = 1 | otherwise = n * recurse (n - 1) {-# INLINE fix4 #-} fix4 f = f1 where f1 = f f2 f2 = f f3 f3 = f f4 f4 = f f1 There is probably a way to generalise this to arbitrary levels of unrolling by using instances of a typeclass on type level numerals. Cheers, Max From claus.reinke at talk21.com Thu Feb 26 16:33:41 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 26 16:22:42 2009 Subject: optimization and rewrite rules questions References: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C33399740E59@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <87F7E09DBEC247E6BE106204CD7CEFFE@cr3lt> | II is where I'd like to be able to distinguish variables, constants, | and complex expressions in the left-hand sides of RULES, and | I and III are where I'd like control over the rewrite strategy, as | in strategy combinators. >I'm deep in icfp submissions, so no time to reply properly. Okay, not urgent, just general concerns about GHC performance, can wait a few days. >You can distinguish between literals, variables etc, in GHC's >BuiltinRules. Not really sufficient. If the loop body was about Maps instead of Ints, different rules would apply. And the same limitations apply for all uses of RULES, which were meant to provide for user-extensible library-specific optimization by transformation. >Another avenue is to elaborate the language of rules somehow >to let you say what you want. But I don't know a good *spec* >for such a feature, let alone an impl. >Another possibility is to write a Core-to-Core optimiser aimed >at your target area. Max B's plugins would let you dynamically >link that to a distributed GHC. But it's not in the HEAD yet... My guess would be to start from standard Strafunski/SYB-style traversals over Core as the "semantic API", utilizing compiler plugins. Then look for better syntax, closer to the existing RULES (for a start, something like quasi-quoting, so that left- and right-hand sides of rules can still be written in concrete syntax, even if they are just Haskell function definitions). Then move all RULES to the new framework (to reduce duplication inside GHC, and to provide a single programmer API) and start adding further optimizations to libraries (I wonder: surely others have encountered these limitations when adding RULES for their libraries?). But that is just a guess - as you imply, someone would have to sit down, design, implement, and test. That is why I asked whether it would make a good GSoC topic for GHC HQ (lots of potential, and building on one of last year's topics). Claus From claus.reinke at talk21.com Thu Feb 26 16:40:19 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 26 16:29:22 2009 Subject: optimization and rewrite rules questions References: <8E9D840E78654E929D6E3B28AE3EACFD@cr3lt> <9d4d38820902260533m6dfe83dcp7db610ee37f1d84f@mail.gmail.com> Message-ID: >> but if we unfold a loop combinator at compile time, GHC's >> normal optimizations can take over from there): >> >> http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html > > Just a note - there is a solution that doesn't require Template > Haskell which I use in my own code. Here is a sketch: That is in fact the same solution!-) Just that I stayed close to the example in the original thread, hence a fixpoint-combinator with implicit tail-recursion and built-in counter rather than one with explicit general recursion. > fact = fix4 fact_worker > > {-# INLINE fact_worker #-} > fact_worker recurse n > | n <= 0 = 1 > | otherwise = n * recurse (n - 1) > > {-# INLINE fix4 #-} > fix4 f = f1 > where > f1 = f f2 > f2 = f f3 > f3 = f f4 > f4 = f f1 > > There is probably a way to generalise this to arbitrary levels of > unrolling by using instances of a typeclass on type level numerals. Semantically, one could compute the nested application without meta-level help, but that involves another recursive definition, which GHC won't unfold during compilation. So I used TH, just to generate the equivalent to the 'fixN' definition. Since only the fixpoint/loop combinators need to be unfolded statically, one could indeed do it by hand, for a suitable range of unfolding depths, and provide them as a library. Claus From ben.franksen at online.de Thu Feb 26 18:12:07 2009 From: ben.franksen at online.de (Ben Franksen) Date: Thu Feb 26 18:01:19 2009 Subject: Type (class) recursion + families = exponential compile time? Message-ID: Hi the attached module is a much reduced version of some type-level assurance stuff (inspired by the Lightweight Monadic Regions paper) I am trying to do. I am almost certain that it could be reduced further but it is late and I want to get this off my desk. Note the 4 test functions, test11 .. test14. The following are timings for compiling the module only with all test functions commented out, except respectively, test11, test12, test13, and test14: ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total It seems something is scaling very badly. You really don't want to wait for a version with 20 levels of nesting to compile... If anyone has a good explanation for this, I'd be grateful. BTW, I am not at all certain that this is ghc's fault, it may well be my program, i.e. the constraints are too complex, whatever. I have no idea how hard it is for the compiler to do all the unification. Also, the problem is not of much practical relevance, as no sensible program will use more than a handfull levels of nesting. Cheers Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: Bug2.hs Type: text/x-java Size: 1545 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090227/f32d4c10/Bug2.bin From claus.reinke at talk21.com Thu Feb 26 18:28:48 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 26 18:17:47 2009 Subject: Int vs Word performance? Message-ID: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> Looking at prelude/PrelRules.hs has reminded me of an old conundrum: if I switch from Int to Word, should I expect any performance differences? A while ago, I needed lots of fairly small positive numbers, together with a small number of flags for each, so I thought I'd switch from Int to Word, and map the flags to bits. But the performance dropped so drastically that I went back to Int, slightly complicating the bitmaps. I didn't expect that, and I can't see any builtin rules for Int that would have no Word counterpart. Here is a trivial example with drastic difference between T = Int and T = Word (~2.5x here): main = print $ foldl' (+) 0 [1..100000000::T] What am I missing here? Also, in the real code I ended up seeing things like this in the -ddump-simpl output for the bit-fiddling code: GHC.Prim.word2Int# (GHC.Prim.and# (GHC.Prim.int2Word# wild13_XbE) (GHC.Prim.int2Word# y#_a4EZ)) Is that likely to cost me a lot or are these conversions cheap? Claus From lennart at augustsson.net Thu Feb 26 19:13:59 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 26 19:03:00 2009 Subject: Type (class) recursion + families = exponential compile time? In-Reply-To: References: Message-ID: Just Hindley-Milner type inference is exponential, making the type system more complex isn't going to make things better. 2009/2/26 Ben Franksen : > Hi > > the attached module is a much reduced version of some type-level assurance > stuff (inspired by the Lightweight Monadic Regions paper) I am trying to > do. I am almost certain that it could be reduced further but it is late and > I want to get this off my desk. > > Note the 4 test functions, test11 .. test14. The following are timings for > compiling the module only with all test functions commented out, except > respectively, test11, test12, test13, and test14: > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs ?1,79s user 0,04s system 99% cpu 1,836 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs ?5,87s user 0,14s system 99% cpu 6,028 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs ?23,52s user 0,36s system 99% cpu 23,899 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs ?102,20s user 1,32s system 97% cpu 1:45,89 total > > It seems something is scaling very badly. You really don't want to wait for > a version with 20 levels of nesting to compile... > > If anyone has a good explanation for this, I'd be grateful. > > BTW, I am not at all certain that this is ghc's fault, it may well be my > program, i.e. the constraints are too complex, whatever. I have no idea how > hard it is for the compiler to do all the unification. Also, the problem is > not of much practical relevance, as no sensible program will use more than > a handfull levels of nesting. > > Cheers > Ben > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From dons at galois.com Thu Feb 26 19:28:25 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 26 19:18:03 2009 Subject: Int vs Word performance? In-Reply-To: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> Message-ID: <20090227002825.GH15172@whirlpool.galois.com> claus.reinke: > Looking at prelude/PrelRules.hs has reminded me of an old > conundrum: if I switch from Int to Word, should I expect any > performance differences? > > A while ago, I needed lots of fairly small positive numbers, > together with a small number of flags for each, so I thought > I'd switch from Int to Word, and map the flags to bits. But the > performance dropped so drastically that I went back > to Int, slightly complicating the bitmaps. I didn't expect that, > and I can't see any builtin rules for Int that would have no > Word counterpart. > > Here is a trivial example with drastic difference between > T = Int and T = Word (~2.5x here): > > main = print $ foldl' (+) 0 [1..100000000::T] > > What am I missing here? > > Also, in the real code I ended up seeing things like this in > the -ddump-simpl output for the bit-fiddling code: > > GHC.Prim.word2Int# > (GHC.Prim.and# > (GHC.Prim.int2Word# wild13_XbE) > (GHC.Prim.int2Word# y#_a4EZ)) > > Is that likely to cost me a lot or are these conversions cheap? Those guys are no-ops, and in general you should never see a performance difference. If you do, it is a bug! There are some known cases where rules are missing however: * Conversions to Int from Double for ceil, floor, round are missing rules. http://hackage.haskell.org/trac/ghc/ticket/2271 * gcd only has a specialised implementation for Int, http://hackage.haskell.org/trac/ghc/ticket/2270 Some others I'm aware of are product/sum/maximum/minimum on lists have specialisations for some atomic types (Int, Integer) but not all (needs a ticket for this too). I'm not aware of any remaining "theoretically noop" conversions that aren't in fact implemented noops now. If you find them, please open a ticket. -- Don From Ben.Lippmeier at anu.edu.au Thu Feb 26 19:59:33 2009 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Feb 26 19:48:33 2009 Subject: Type (class) recursion + families = exponential compile time? In-Reply-To: References: Message-ID: <0B66D01F-67DD-4A7F-AAF4-3241CC3CD153@anu.edu.au> Here's the reference http://portal.acm.org/citation.cfm?id=96748 "Deciding ML typability is complete for deterministic exponential time" -- Harry G. Mairson. Ben. On 27/02/2009, at 10:12 AM, Ben Franksen wrote: > Hi > > the attached module is a much reduced version of some type-level > assurance > stuff (inspired by the Lightweight Monadic Regions paper) I am > trying to > do. I am almost certain that it could be reduced further but it is > late and > I want to get this off my desk. > > Note the 4 test functions, test11 .. test14. The following are > timings for > compiling the module only with all test functions commented out, > except > respectively, test11, test12, test13, and test14: > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total > > ben@sarun[1] > time ghc -c Bug2.hs > ghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total > > It seems something is scaling very badly. You really don't want to > wait for > a version with 20 levels of nesting to compile... > > If anyone has a good explanation for this, I'd be grateful. > > BTW, I am not at all certain that this is ghc's fault, it may well > be my > program, i.e. the constraints are too complex, whatever. I have no > idea how > hard it is for the compiler to do all the unification. Also, the > problem is > not of much practical relevance, as no sensible program will use > more than > a handfull levels of nesting. > > Cheers > Ben > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From phunge0 at hotmail.com Thu Feb 26 22:55:49 2009 From: phunge0 at hotmail.com (Brian Bloniarz) Date: Thu Feb 26 22:44:45 2009 Subject: Suggestion for bang patterns documentation Message-ID: I got confused by the GHC documentation recently, I was wondering how it could be improved. From: http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html > A bang only really has an effect if it precedes a variable or wild-card pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Here, f3 and f4 are identical; putting a bang before a pattern that > forces evaluation anyway does nothing. The first sentence is true, but only in settings where the pattern is being evaluated eagerly -- the bang in: > f3 a = let !(x,y) = a in [1,x,y] > f4 a = let (x,y) = a in [1,x,y] has an effect. The first time I read this, I took the first sentence to be a unqualified truth and ended up thinking that !(x,y) was equivalent to (x,y) everywhere. Stuff that comes later actually clarifies this, but I missed it. What about making the distinction clear upfront? Something like: > A bang in an eager pattern match only really has an effect if it precedes a variable > or wild-card pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Because f4 _|_ will force the evaluation of the pattern match anyway, f3 and f4 > are identical; the bang does nothing. It also might be a good idea to immediately follow this with the let/where usage: > A bang can also preceed a let/where binding to make the pattern match strict. For example: > let ![x,y] = e in b > is a strict pattern... (in the existing docs, let comes a bit later): Just a thought. Hopefully someone can come up with a better way of wording what I'm getting at. Thanks, -Brian _________________________________________________________________ Windows Live? Hotmail??more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009 From p.k.f.holzenspies at utwente.nl Fri Feb 27 03:37:18 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Fri Feb 27 03:26:19 2009 Subject: finally part run twice on Ctrl-C In-Reply-To: <20090227000312.9C58E32440B@www.haskell.org> References: <20090227000312.9C58E32440B@www.haskell.org> Message-ID: <200902270937.18492.p.k.f.holzenspies@utwente.nl> > I've got the following code: > > import Control.Exception > import System.Cmd > main = system "sleep 1m" `finally` putStrLn "goodbye" > > When compiled with GHC 6.10.1.20090225, if I hit Ctrl-C during the > sleep, I get the goodbye printed twice. If I leave evaluation to > finish normally I get goodbye once. Is this a bug? Dear Neil, et al. Just to let you know; I tried it on the release version of 6.10.1 and it worked as expected (first run, I waited; second I pressed Ctrl-C): *Test> main goodbye ExitSuccess *Test> main goodbye ExitFailure 2 *Test> If not coming from system differences, the bug should sit in recent code. Regards, Philip From ndmitchell at gmail.com Fri Feb 27 03:39:14 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 27 03:28:08 2009 Subject: finally part run twice on Ctrl-C In-Reply-To: <200902270937.18492.p.k.f.holzenspies@utwente.nl> References: <20090227000312.9C58E32440B@www.haskell.org> <200902270937.18492.p.k.f.holzenspies@utwente.nl> Message-ID: <404396ef0902270039i5adbc37fufd623d704eebc5ce@mail.gmail.com> Hi Philip, > Just to let you know; I tried it on the release version of 6.10.1 and it > worked as expected (first run, I waited; second I pressed Ctrl-C): > > *Test> main > goodbye > ExitSuccess > *Test> main > goodbye > ExitFailure 2 > *Test> It looks like you are running in GHCi, which I think works. It's only when the program is compiled and run from the command line (Cygwin or DOS) that I get the above problem. Thanks Neil; From p.k.f.holzenspies at utwente.nl Fri Feb 27 03:45:15 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?iso-8859-1?q?H=F6lzenspies?=) Date: Fri Feb 27 03:34:09 2009 Subject: finally part run twice on Ctrl-C In-Reply-To: <404396ef0902270039i5adbc37fufd623d704eebc5ce@mail.gmail.com> References: <20090227000312.9C58E32440B@www.haskell.org> <200902270937.18492.p.k.f.holzenspies@utwente.nl> <404396ef0902270039i5adbc37fufd623d704eebc5ce@mail.gmail.com> Message-ID: <200902270945.15389.p.k.f.holzenspies@utwente.nl> On Friday 27 February 2009 09:39:14 Neil Mitchell wrote: > It looks like you are running in GHCi, which I think works. It's only > when the program is compiled and run from the command line (Cygwin or > DOS) that I get the above problem. Dear Neil, You were right. When I do compile it, though, I get the same (correct) behaviour (now I pressed Ctrl-C the first run and let it be for the second): holzensp@ewi1043:~/tmp> ghc Test.hs holzensp@ewi1043:~/tmp> ./a.out goodbye holzensp@ewi1043:~/tmp> ./a.out goodbye holzensp@ewi1043:~/tmp> This is on Linux, though, so it may also be OS-dependent. Regards, Philip From simonpj at microsoft.com Fri Feb 27 05:17:53 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 27 05:06:49 2009 Subject: Suggestion for bang patterns documentation In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C333997414A7@EA-EXMSG-C334.europe.corp.microsoft.com> good idea. done | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Brian Bloniarz | Sent: 27 February 2009 03:56 | To: glasgow-haskell-users@haskell.org | Subject: Suggestion for bang patterns documentation | | | I got confused by the GHC documentation recently, I was wondering how | it could be improved. From: | http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html | | > A bang only really has an effect if it precedes a variable or wild-card pattern: | > f3 !(x,y) = [x,y] | > f4 (x,y) = [x,y] | > Here, f3 and f4 are identical; putting a bang before a pattern that | > forces evaluation anyway does nothing. | | The first sentence is true, but only in settings where the pattern is being | evaluated eagerly -- the bang in: | > f3 a = let !(x,y) = a in [1,x,y] | > f4 a = let (x,y) = a in [1,x,y] | has an effect. | | The first time I read this, I took the first sentence to be a unqualified truth | and ended up thinking that !(x,y) was equivalent to (x,y) everywhere. Stuff | that comes later actually clarifies this, but I missed it. | | What about making the distinction clear upfront? Something like: | > A bang in an eager pattern match only really has an effect if it precedes a | variable | > or wild-card pattern: | > f3 !(x,y) = [x,y] | > f4 (x,y) = [x,y] | > Because f4 _|_ will force the evaluation of the pattern match anyway, f3 and f4 | > are identical; the bang does nothing. | | It also might be a good idea to immediately follow this with the let/where usage: | | > A bang can also preceed a let/where binding to make the pattern match strict. For | example: | > let ![x,y] = e in b | > is a strict pattern... | (in the existing docs, let comes a bit later): | | Just a thought. Hopefully someone can come up with a better way of | wording what I'm getting at. | | Thanks, | -Brian | | _________________________________________________________________ | Windows Live(tm) Hotmail(r)...more than just e-mail. | http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_0 | 22009_______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Fri Feb 27 05:53:22 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 27 05:42:16 2009 Subject: Suggestion for bang patterns documentation In-Reply-To: References: Message-ID: <49A7C622.5010200@dfki.de> Brian Bloniarz wrote: > I got confused by the GHC documentation recently, I was wondering how > it could be improved. From: > http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html Seeing the rule pat ::= !pat you'll probably want to avoid patterns like: "!!pat", "! ! pat", or "~ ! ~ pat". Even the current http://www.haskell.org/onlinelibrary/exps.html#sect3.17.1 apat -> ~ apat allows "~ ~x". (Note the space!) So maybe a separate non-terminal "bpat" should be used with: bpat -> [~|!] apat (and bpat used within pat). You may also want to exclude "v@ ~(...)" in favor of "~v@(...)". >> A bang only really has an effect if it precedes a variable or wild-card pattern: >> f3 !(x,y) = [x,y] >> f4 (x,y) = [x,y] >> Here, f3 and f4 are identical; putting a bang before a pattern that >> forces evaluation anyway does nothing. Maybe the duality (if it is one) should be added that an irrefutable pattern above would make a difference but not within the let below. > The first sentence is true, but only in settings where the pattern is being > evaluated eagerly -- the bang in: >> f3 a = let !(x,y) = a in [1,x,y] >> f4 a = let (x,y) = a in [1,x,y] > has an effect. Cheers Christian From Christian.Maeder at dfki.de Fri Feb 27 06:15:40 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 27 06:04:34 2009 Subject: Suggestion for bang patterns documentation In-Reply-To: References: Message-ID: <49A7CB5C.5010808@dfki.de> Brian Bloniarz wrote: > I got confused by the GHC documentation recently, I was wondering how > it could be improved. From: > http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html The let-binding can be recursive. However, it is much more common for the let-binding to be non-recursive, in which case the following law holds: (let !p = rhs in body) is equivalent to (case rhs of !p -> body) Shouldn't the bang be removed in the final case pattern? Furthermore with existential types the let binding is not supported: data E = forall a . Show a => E a f :: E -> String f x = case x of E a -> show a f works, but g g :: E -> String g x = let !(E a) = x in show a fails (with or without the bang): My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the binding group for !(E a) In a pattern binding: !(E a) = x In the expression: let !(E a) = x in show a In the definition of `g': g x = let !(E a) = x in show a Cheers Christian P.S. It should be mentioned that ~ and ! only make sense for single variant data types (like tuples) From simonpj at microsoft.com Fri Feb 27 06:22:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 27 06:11:43 2009 Subject: Suggestion for bang patterns documentation In-Reply-To: <49A7CB5C.5010808@dfki.de> References: <49A7CB5C.5010808@dfki.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399741587@EA-EXMSG-C334.europe.corp.microsoft.com> | | The let-binding can be recursive. However, it is much more common for | the let-binding to be non-recursive, in which case the following law | holds: (let !p = rhs in body) is equivalent to (case rhs of !p -> body) | | | Shouldn't the bang be removed in the final case pattern? No. If p was a simple variable, then case rhs of x -> body is non-strict in Haskell, but should be strict here. | P.S. It should be mentioned that ~ and ! only make sense for single | variant data types (like tuples) That isn't true. Both are useful for multi-variant types Simon From Malcolm.Wallace at cs.york.ac.uk Fri Feb 27 06:57:22 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 27 06:47:12 2009 Subject: Int vs Word performance? In-Reply-To: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> Message-ID: <20090227115722.7dc7144b.Malcolm.Wallace@cs.york.ac.uk> "Claus Reinke" wrote: > A while ago, I needed lots of fairly small positive numbers, > together with a small number of flags for each, so I thought > I'd switch from Int to Word, and map the flags to bits. Since there are few guarantees about the size of a Word (or Int), surely it would be better to choose a definitely sized basic type, e.g. Word8 or Word16? I vaguely recall that ghc used to generate better code for definitely sized WordN than the generic unguaranteed-size Word. Regards, Malcolm From Christian.Maeder at dfki.de Fri Feb 27 07:46:59 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 27 07:35:52 2009 Subject: Suggestion for bang patterns documentation In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33399741587@EA-EXMSG-C334.europe.corp.microsoft.com> References: <49A7CB5C.5010808@dfki.de> <638ABD0A29C8884A91BC5FB5C349B1C33399741587@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49A7E0C3.4050509@dfki.de> Simon Peyton-Jones wrote: > | > | The let-binding can be recursive. However, it is much more common for > | the let-binding to be non-recursive, in which case the following law > | holds: (let !p = rhs in body) is equivalent to (case rhs of !p -> body) > | > | > | Shouldn't the bang be removed in the final case pattern? > > No. If p was a simple variable, then > case rhs of x -> body > is non-strict in Haskell, but should be strict here. Thanks for pointing this out. But the case with a simple variable (and no distinction) is special anyway (sort of a monomorphic let binding). > | P.S. It should be mentioned that ~ and ! only make sense for single > | variant data types (like tuples) > > That isn't true. Both are useful for multi-variant types Right, a non-empty list should behave like a pair as long as I don't want to know the variant beforehand and thereby forcing evaluation anyway. Cheers Christian From claus.reinke at talk21.com Fri Feb 27 08:13:54 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Feb 27 08:02:51 2009 Subject: Int vs Word performance? References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> Message-ID: <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> >> Here is a trivial example with drastic difference between >> T = Int and T = Word (~2.5x here): >> >> main = print $ foldl' (+) 0 [1..100000000::T] .. >> GHC.Prim.word2Int# >> (GHC.Prim.and# >> (GHC.Prim.int2Word# wild13_XbE) >> (GHC.Prim.int2Word# y#_a4EZ)) >> >> Is that likely to cost me a lot or are these conversions cheap? > > Those guys are no-ops, and in general you should never see a performance > difference. If you do, it is a bug! There are some known cases where > rules are missing however: Thanks, that is one thing less to worry about. Btw, is there a "guide to reading Core" somewhere, with emphasis on performance aspects (what to look for when optimizing time or space usage, what to ignore, how to make it more readable, etc)? Until I stumbled over CORE annotations, I found it near impossible even to find the pieces of interest for non-trivial programs, things like -dsuppress-uniques help a little with diffs, some things look big but are noops, etc. - that kind of helpful pragmatic knowledge (why does it look as if source variable names aren't always preserved; why does it use random uniques instead of de Bruijn-style disambiguation, which wouldn't interfere with diffs and would have static semantic content; why do the outputs look different for core2core vs dump-simpl, ..). > Some others I'm aware of are product/sum/maximum/minimum > on lists have specialisations for some atomic types (Int, Integer) but > not all (needs a ticket for this too). A quick grep shows almost no specialization at all for Word, or for IntXX/WordXX (see below). Still, none of that seems to explain the example repeated at the top of this message. Claus $ find libraries/ -name _darcs -prune -o -name *hs | xargs grep SPECIAL | grep '\ Int #-} libraries/base/Data/List.hs:{-# SPECIALISE sum :: [Integer] -> Integer #-} libraries/base/Data/List.hs:{-# SPECIALISE product :: [Int] -> Int #-} libraries/base/Data/List.hs:{-# SPECIALISE product :: [Integer] -> Integer #-} libraries/base/GHC/Arr.lhs: {-# SPECIALISE instance Ix (Int,Int) #-} libraries/base/GHC/Arr.lhs: {-# SPECIALISE instance Ix (Int,Int,Int) #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE properFraction :: Float -> (Int, Float) #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE round :: Float -> Int #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE properFraction :: Float -> (Integer, Float) #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE round :: Float -> Integer #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE properFraction :: Double -> (Int, Double) #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE round :: Double -> Int #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE properFraction :: Double -> (Integer, Double) #-} libraries/base/GHC/Float.lhs: {-# SPECIALIZE round :: Double -> Integer #-} libraries/base/GHC/Real.lhs:{-# SPECIALISE (%) :: Integer -> Integer -> Rational #-} libraries/base/GHC/Real.lhs:{-# SPECIALISE reduce :: Integer -> Integer -> Rational #-} libraries/base/GHC/Real.lhs:{-# SPECIALISE lcm :: Int -> Int -> Int #-} libraries/bytestring/Data/ByteString/Internal.hs:{-# SPECIALIZE unpackWith :: (Word8 -> Char) -> ByteString -> [Char] #-} libraries/bytestring/Data/ByteString/Internal.hs:{-# SPECIALIZE packWith :: (Char -> Word8) -> [Char] -> ByteString #-} libraries/bytestring/Data/ByteString/Lazy.hs:{-# SPECIALIZE packWith :: (Char -> Word8) -> [Char] -> ByteString #-} libraries/bytestring/Data/ByteString/Lazy.hs:{-# SPECIALIZE unpackWith :: (Word8 -> Char) -> ByteString -> [Char] #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupTree :: Int -> FingerTree (Elem a) -> Place (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupTree :: Int -> FingerTree (Node a) -> Place (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupNode :: Int -> Node (Elem a) -> Place (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupNode :: Int -> Node (Node a) -> Place (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupDigit :: Int -> Digit (Elem a) -> Place (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE lookupDigit :: Int -> Digit (Node a) -> Place (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustTree :: (Int -> Elem a -> Elem a) -> Int -> FingerTree (Elem a) -> FingerTree (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustTree :: (Int -> Node a -> Node a) -> Int -> FingerTree (Node a) -> FingerTree (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustNode :: (Int -> Elem a -> Elem a) -> Int -> Node (Elem a) -> Node (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustNode :: (Int -> Node a -> Node a) -> Int-> Node (Node a) -> Node (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustDigit :: (Int -> Elem a -> Elem a) -> Int -> Digit (Elem a) -> Digit (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE adjustDigit :: (Int -> Node a -> Node a) -> Int -> Digit (Node a) -> Digit (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitTree :: Int -> FingerTree (Elem a) -> Split (FingerTree (Elem a)) (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitTree :: Int -> FingerTree (Node a) -> Split (FingerTree (Node a)) (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitNode :: Int -> Node (Elem a) -> Split (Maybe (Digit (Elem a))) (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitNode :: Int -> Node (Node a) -> Split (Maybe (Digit (Node a))) (Node a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitDigit :: Int -> Digit (Elem a) -> Split (Maybe (Digit (Elem a))) (Elem a) #-} libraries/containers/Data/Sequence.hs:{-# SPECIALIZE splitDigit :: Int -> Digit (Node a) -> Split (Maybe (Digit (Node a))) (Node a) #-} libraries/parallel/Control/Parallel/Strategies.hs:{-# SPECIALISE seqListN :: Int -> Strategy b -> Strategy [b] #-} From claus.reinke at talk21.com Fri Feb 27 08:20:33 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Feb 27 08:09:28 2009 Subject: Int vs Word performance? References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227115722.7dc7144b.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <856594C9331B4D428DAC1BC16D566C22@cr3lt> >> A while ago, I needed lots of fairly small positive numbers, >> together with a small number of flags for each, so I thought >> I'd switch from Int to Word, and map the flags to bits. > > Since there are few guarantees about the size of a Word (or Int), surely > it would be better to choose a definitely sized basic type, e.g. Word8 > or Word16? Good point in principle, and I would indeed prefer a specific size. Unfortunately, I found just the opposite of this > I vaguely recall that ghc used to generate better code for > definitely sized WordN than the generic unguaranteed-size Word. to be true (although I don't recall whether I checked with IntN or WordN, and I don't have a small example for this issue): Even just replacing Int with Int32 on a system where that should be the same was liable to reduce performance.. Given Don's point about SPECIALI[ZS]E, and the lack of specialisations for IntN/WordN, that might explain it? Claus PS. perhaps on newer 64 bit machines, explicitly selecting 32 bits can offer savings? I'd certainly expect selecting 64 bits on a 32 bit machine to lead to slowdowns. From ben.franksen at online.de Fri Feb 27 09:59:09 2009 From: ben.franksen at online.de (Ben Franksen) Date: Fri Feb 27 09:48:12 2009 Subject: ghc crashes on strange foreign import Message-ID: This is the code: {-# OPTIONS -fglasgow-exts #-} import Foreign type X u = Ptr () foreign import ccall bla :: (forall u. X u) -> IO () I know of course that I must not use fancy types in foreign imports. I forgot for a moment and instead of an error message got: ben@sarun> ghci Bug3 GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Bug3.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): unboxArg: Bug3.hs:4:0-51 forall u{tv aht} [tv]. main:Main.X{tc rhp} u{tv aht} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Cheers Ben From marlowsd at gmail.com Fri Feb 27 11:34:37 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Feb 27 11:23:45 2009 Subject: Int vs Word performance? In-Reply-To: <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> Message-ID: <49A8161D.3010301@gmail.com> Claus Reinke wrote: >>> Here is a trivial example with drastic difference between >>> T = Int and T = Word (~2.5x here): >>> >>> main = print $ foldl' (+) 0 [1..100000000::T] > .. > A quick grep shows almost no specialization at all for Word, or for > IntXX/WordXX (see below). Still, none of that seems to explain the > example repeated at the top of this message. The Enum instance for Int uses specialised implementations of enumFromTo and friends, whereas the Word version uses the generic integralEnumFromTo. Cheers, Simon From simonpj at microsoft.com Fri Feb 27 11:36:39 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 27 11:25:35 2009 Subject: Int vs Word performance? In-Reply-To: <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399741900@EA-EXMSG-C334.europe.corp.microsoft.com> | Until I stumbled over CORE annotations, I found it near impossible even | to find the pieces of interest for non-trivial programs, things like | -dsuppress-uniques help a little with diffs, some things look big but | are noops, etc. - that kind of helpful pragmatic knowledge (why does | it look as if source variable names aren't always preserved; why does | it use random uniques instead of de Bruijn-style disambiguation, which | wouldn't interfere with diffs and would have static semantic content; | why do the outputs look different for core2core vs dump-simpl, ..). Many of these things might be fixable if someone thought about the specification carefully. The current core pretty-printer was initially designed only for GHC internals hackers, rather than Joe User. A first step might be for a posse of Joe Users to specify what they want, as precisely as possible. Then this same posse might even write a Core pretty-printer to achieve it. I am happy to advise. Then we could substitute new for old. | A quick grep shows almost no specialization at all for Word, or for | IntXX/WordXX (see below). Still, none of that seems to explain the | example repeated at the top of this message. We'd be delighted to apply suitable library patches. Simon From simonpj at microsoft.com Fri Feb 27 11:38:42 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 27 11:27:36 2009 Subject: Int vs Word performance? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33399741900@EA-EXMSG-C334.europe.corp.microsoft.com> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C33399741900@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399741905@EA-EXMSG-C334.europe.corp.microsoft.com> | | A quick grep shows almost no specialization at all for Word, or for | | IntXX/WordXX (see below). Still, none of that seems to explain the | | example repeated at the top of this message. | | We'd be delighted to apply suitable library patches. PS: in the case that no one gets around to creating such a patch, creating a ticket that documents the problem and points to the needed specialisations would be a start From marlowsd at gmail.com Fri Feb 27 11:39:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Feb 27 11:28:18 2009 Subject: Int vs Word performance? In-Reply-To: <856594C9331B4D428DAC1BC16D566C22@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227115722.7dc7144b.Malcolm.Wallace@cs.york.ac.uk> <856594C9331B4D428DAC1BC16D566C22@cr3lt> Message-ID: <49A81739.5080702@gmail.com> Claus Reinke wrote: > PS. perhaps on newer 64 bit machines, explicitly selecting > 32 bits can offer savings? I'd certainly expect selecting > 64 bits on a 32 bit machine to lead to slowdowns. Unlikely, I'd have thought. We implement all the explicitly sized integral types by zero-extending or sign-extending to the size of an Int/Word. That's why there are no primitive types or operations for Word8#, Word16#, etc. Cheers, Simon From dons at galois.com Fri Feb 27 13:07:10 2009 From: dons at galois.com (Don Stewart) Date: Fri Feb 27 12:56:49 2009 Subject: Int vs Word performance? In-Reply-To: <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> Message-ID: <20090227180709.GF18853@whirlpool.galois.com> claus.reinke: >>> Here is a trivial example with drastic difference between >>> T = Int and T = Word (~2.5x here): >>> >>> main = print $ foldl' (+) 0 [1..100000000::T] > .. >>> GHC.Prim.word2Int# >>> (GHC.Prim.and# >>> (GHC.Prim.int2Word# wild13_XbE) >>> (GHC.Prim.int2Word# y#_a4EZ)) >>> >>> Is that likely to cost me a lot or are these conversions cheap? >> >> Those guys are no-ops, and in general you should never see a performance >> difference. If you do, it is a bug! There are some known cases where >> rules are missing however: > > Thanks, that is one thing less to worry about. Btw, is there a "guide to > reading Core" somewhere, with emphasis on performance aspects (what > to look for when optimizing time or space usage, what to ignore, how to > make it more readable, etc)? > > Until I stumbled over CORE annotations, I found it near impossible even > to find the pieces of interest for non-trivial programs, things like > -dsuppress-uniques help a little with diffs, some things look big but > are noops, etc. - that kind of helpful pragmatic knowledge (why does > it look as if source variable names aren't always preserved; why does > it use random uniques instead of de Bruijn-style disambiguation, which > wouldn't interfere with diffs and would have static semantic content; > why do the outputs look different for core2core vs dump-simpl, ..). I use the ghc-core tool: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core From dons at galois.com Fri Feb 27 14:16:57 2009 From: dons at galois.com (Don Stewart) Date: Fri Feb 27 14:06:35 2009 Subject: Int vs Word performance? In-Reply-To: <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> Message-ID: <20090227191657.GH18853@whirlpool.galois.com> claus.reinke: >>> Here is a trivial example with drastic difference between >>> T = Int and T = Word (~2.5x here): >>> >>> main = print $ foldl' (+) 0 [1..100000000::T] > .. >>> GHC.Prim.word2Int# >>> (GHC.Prim.and# >>> (GHC.Prim.int2Word# wild13_XbE) >>> (GHC.Prim.int2Word# y#_a4EZ)) >>> >>> Is that likely to cost me a lot or are these conversions cheap? >> >> Those guys are no-ops, and in general you should never see a performance >> difference. If you do, it is a bug! There are some known cases where >> rules are missing however: > > Thanks, that is one thing less to worry about. Btw, is there a "guide to > reading Core" somewhere, with emphasis on performance aspects (what > to look for when optimizing time or space usage, what to ignore, how to > make it more readable, etc)? > > Until I stumbled over CORE annotations, I found it near impossible even > to find the pieces of interest for non-trivial programs, things like > -dsuppress-uniques help a little with diffs, some things look big but > are noops, etc. - that kind of helpful pragmatic knowledge (why does > it look as if source variable names aren't always preserved; why does > it use random uniques instead of de Bruijn-style disambiguation, which > wouldn't interfere with diffs and would have static semantic content; > why do the outputs look different for core2core vs dump-simpl, ..). > >> Some others I'm aware of are product/sum/maximum/minimum >> on lists have specialisations for some atomic types (Int, Integer) but >> not all (needs a ticket for this too). > > A quick grep shows almost no specialization at all for Word, or for > IntXX/WordXX (see below). Still, none of that seems to explain the > example repeated at the top of this message. We do need to decide on if we want to add specializations for all atomic types in general, and if so, then let'd do that intentionally. Does anyone see a reason not to do it in the libraries, via rules? From dons at galois.com Fri Feb 27 19:40:55 2009 From: dons at galois.com (Don Stewart) Date: Fri Feb 27 19:30:33 2009 Subject: Int vs Word performance? In-Reply-To: <49A8161D.3010301@gmail.com> References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt> <20090227002825.GH15172@whirlpool.galois.com> <4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt> <49A8161D.3010301@gmail.com> Message-ID: <20090228004055.GC18853@whirlpool.galois.com> marlowsd: > Claus Reinke wrote: >>>> Here is a trivial example with drastic difference between >>>> T = Int and T = Word (~2.5x here): >>>> >>>> main = print $ foldl' (+) 0 [1..100000000::T] >> .. > >> A quick grep shows almost no specialization at all for Word, or for >> IntXX/WordXX (see below). Still, none of that seems to explain the >> example repeated at the top of this message. > > The Enum instance for Int uses specialised implementations of enumFromTo > and friends, whereas the Word version uses the generic > integralEnumFromTo. Another good reason to use uvector, import Data.Array.Vector import Data.Word main = print $ foldlU (+) (0::T) (enumFromToU 1 (100000000::T)) type T = Word $wfold :: Word# -> Word# -> Word# $wfold = \ (ww_s1cg :: Word#) (ww1_s1ck :: Word#) -> case gtWord# ww1_s1ck __word 100000000 of wild_a19p { False -> $wfold (plusWord# ww_s1cg ww1_s1ck) (plusWord# ww1_s1ck __word 1); True -> ww_s1cg Yields: Main_zdwfold_info: .Lc1e1: cmpq $100000000,%rdi ja .Lc1e4 leaq 1(%rdi),%rax addq %rdi,%rsi movq %rax,%rdi jmp Main_zdwfold_info While at type T = Int We get: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_s144 :: Int#) (ww1_s148 :: Int#) -> case ># ww1_s148 100000000 of wild_a11q { False -> $wfold (+# ww_s144 ww1_s148) (+# ww1_s148 1); True -> ww_s144 And *identical assembly* Main_zdwfold_info: .Lc15E: cmpq $100000000,%rdi jg .Lc15H leaq 1(%rdi),%rax addq %rdi,%rsi movq %rax,%rdi jmp Main_zdwfold_info -- Don From dons at galois.com Sat Feb 28 12:49:32 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 28 12:39:05 2009 Subject: Loop unrolling + fusion ? Message-ID: <20090228174932.GA23519@whirlpool.galois.com> Hey guys, We have nice fusion frameworks now. E.g. stream fusion on uvector, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector Takes something like this: import Data.Array.Vector import Data.Bits main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) and turns it into a loop like this: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> case ww1_sX1 of wild_B1 { __DEFAULT -> $wfold (*# ww_sWX 40) (+# wild_B1 1); 100000000 -> ww_sWX } Now, that's fine in my book. Going via -fasm, we get: Main_zdwfold_info: .LcYt: movq %rdi,%rax cmpq $100000000,%rax jne .LcYx movq %rsi,%rbx jmp *(%rbp) .LcYx: incq %rax imulq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info Ok: $ time ./product 0 ./product 0.31s user 0.00s system 96% cpu 0.316 total Going via C, however, we get: Main_zdwfold_info: cmpq $100000000, %rdi je .L6 .L2: leaq (%rsi,%rsi,4), %rax leaq 1(%rdi), %rdi leaq 0(,%rax,8), %rsi jmp Main_zdwfold_info Nice! $ time ./product 0 ./product 0.19s user 0.00s system 97% cpu 0.197 total So now, since we've gone to such effort to produce a tiny loop like, this, can't we unroll it just a little? Sadly, my attempts to get GCC to trigger its loop unroller on this guy haven't succeeded. -funroll-loops and -funroll-all-loops doesn't touch it, Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC it is worth unrolling this guy, so we get the win of both aggressive high level fusion, and aggressive low level loop optimisations? -- Don From claus.reinke at talk21.com Sat Feb 28 14:42:57 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Feb 28 14:31:49 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: > import Data.Array.Vector > import Data.Bits > main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) > (5::Int) > > and turns it into a loop like this: > > $wfold :: Int# -> Int# -> Int# > $wfold = > \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> > case ww1_sX1 of wild_B1 { > __DEFAULT -> > $wfold (*# ww_sWX 40) (+# wild_B1 1); > 100000000 -> ww_sWX > } .. > So now, since we've gone to such effort to produce a tiny loop like, this, > can't we unroll it just a little? > Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC > it is worth unrolling this guy, so we get the win of both aggressive high level > fusion, and aggressive low level loop optimisations? I'm not sure this is what you're after (been too long since I read assembler;-), but it sounds as if you wanted to unroll the source of that fold, which seems to be a local definition in foldS? Since unrolling is not always a good idea, it would also be nice to have a way to control/initiate it from outside of the uvector package (perhaps a RULE to redirect the call from foldS to a foldSN, but foldS is hidden, and gets inlined away; but something like that). If that works, you'd then run into the issue of wanting to rearrange the *# and *# by variable and constant. Claus From batterseapower at hotmail.com Sat Feb 28 15:14:01 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Feb 28 15:02:52 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <20090228174932.GA23519@whirlpool.galois.com> References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: <9d4d38820902281214g28bdb93s3d4a3a4aa05e9aef@mail.gmail.com> 2009/2/28 Don Stewart : > So now, since we've gone to such effort to produce a tiny loop like, this, > can't we unroll it just a little? Sadly, my attempts to get GCC to trigger > its loop unroller on this guy haven't succeeded. -funroll-loops and > -funroll-all-loops doesn't ?touch it, > > Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC > it is worth unrolling this guy, so we get the win of both aggressive high level > fusion, and aggressive low level loop optimisations? For a couple of weeks, I have had a working solution for the concatMap problem using a sort of loop unrolling. I have tweaked the approach slightly to also unroll the worker loop to get the results you desire. You can check out the (very rough) code with: git clone http://www.cl.cam.ac.uk/~mb566/git/concatmap/.git/ $EDITOR concatmap/CallUnrollConcatMap.hs Apologies if the code is somewhat cryptic, but you should be able to get the general idea. A sneak preview is in order. The following Core: """ Rec { $wf1_s1bU [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int# -> GHC.Prim.Int# [Arity 1 Str: DmdType L] $wf1_s1bU = \ (ww_s1bO :: GHC.Prim.Int#) -> case GHC.Prim.<=# ww_s1bO 100000000 of wild_B1 [ALWAYS Dead Just A] { GHC.Bool.False -> 0; GHC.Bool.True -> let { x_XMS [ALWAYS Just L] :: GHC.Prim.Int# [Str: DmdType] x_XMS = GHC.Prim.+# ww_s1bO 1 } in case GHC.Prim.<=# x_XMS 100000000 of wild_Xx [ALWAYS Dead Just A] { GHC.Bool.False -> GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# ww_s1bO 2) 2; GHC.Bool.True -> let { x_XMX [ALWAYS Just L] :: GHC.Prim.Int# [Str: DmdType] x_XMX = GHC.Prim.+# x_XMS 1 } in case GHC.Prim.<=# x_XMX 100000000 of wild_XE [ALWAYS Dead Just A] { GHC.Bool.False -> GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# ww_s1bO 2) 2) (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XMS 2) 2); GHC.Bool.True -> let { x_XOf [ALWAYS Just L] :: GHC.Prim.Int# [Str: DmdType] x_XOf = GHC.Prim.+# x_XMX 1 } in case GHC.Prim.<=# x_XOf 100000000 of wild_XM [ALWAYS Dead Just A] { GHC.Bool.False -> GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# ww_s1bO 2) 2) (GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XMS 2) 2) (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XMX 2) 2)); GHC.Bool.True -> case $wf1_s1bU (GHC.Prim.+# x_XOf 1) of ww_s1bS { __DEFAULT -> GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# ww_s1bO 2) 2) (GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XMS 2) 2) (GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XMX 2) 2) (GHC.Prim.+# (GHC.Prim.*# (GHC.Prim.uncheckedIShiftL# x_XOf 2) 2) ww_s1bS))) } } } } } end Rec } """ Is generated by this program: """ result = sumS . mapS (*2) . mapS (`shiftL` 2) $ enumFromToS 0 100000000 """ Of course, my approach is far from perfect: * Unrolling ALWAYS happens, and to a fixed depth * RULEs aren't very good at exploiting properties of arithmetic, as Claus has pointed out * concatMap fuses with my library but has lingering issues with allocation if join points don't get inlined and has some strictness problems too (to see this in action, try compliing the program "sumS $ mapS (+10) $ concatMapS (\x -> enumFromToS x 20) $ enumFromToS 1 10" from the same file). It also is only permitted up to a fixed depth as defined by the level of unrolling specified in the "spec" combinator. But it does get your unrolling with TODAYs GHC, transparently to the user of the uvector library. I am currently looking at other, smarter, ways that GHC can optimize loops as part of my research - so with luck this sort of manual unrolling hackery will become less relevant in the future. All the best, Max