From simonmarhaskell at gmail.com Tue May 1 04:34:28 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 1 04:31:53 2007 Subject: ghc configure In-Reply-To: References: Message-ID: <4636FB94.4040201@gmail.com> C.M.Brown wrote: > I've noticed that when you run ./configure on a ghc build lot's of > repetition occurs. A lot of the time the same checks are being performed for > each configure file in the ghc hierarchy. Could it be possible if some of > these checks could be done once at a high level and then subsequent > configures could refer to these checks to speed up > configuration time? It's just configuring ghc on a mac G4 is a very time > consuming process in it's own right! Mainly this is due to modularity: many of the library packages can be built entirely separately from GHC, so their configure scripts are designed to be standalone. I know that configure takes a long time on Windows, but I'm surprised if it's a bottleneck for other platforms. How long does the build take? Have you taken steps to speed up the build as described in the Building Guide? Cheers, Simon From cmb21 at kent.ac.uk Tue May 1 06:44:52 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue May 1 06:42:18 2007 Subject: ghc configure In-Reply-To: <4636FB94.4040201@gmail.com> References: <4636FB94.4040201@gmail.com> Message-ID: Hi Simon, > Mainly this is due to modularity: many of the library packages can be built > entirely separately from GHC, so their configure scripts are designed to be > standalone. > Yes, I guess it would be a fair bit of work to have it check that you are building the whole of GHC as opposed to separate modules. I just thought that it could check to see if it was a global build -- and share configure checks where appropriate; or, in separate module builds the configure runs as normally. > I know that configure takes a long time on Windows, but I'm surprised if it's a > bottleneck for other platforms. How long does the build take? Have you taken > steps to speed up the build as described in the Building Guide? Configuring and building on my Mac can take several hours. Mind you, it's a slow machine (G4 1.33 with 1 gig of RAM). I can safely say it's very fast on my linux machine - the configure whips through, and even a full build only takes a little more than an hour or so. Thanks for pointing out tips to speed up the build. I must confess my ignorance of not checking that! Kind regards, Chris. From claus.reinke at talk21.com Tue May 1 07:02:35 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue May 1 07:00:00 2007 Subject: ghc configure References: <4636FB94.4040201@gmail.com> Message-ID: <007401c78be0$3ab6c460$e2318351@cr3lt> >> Mainly this is due to modularity: many of the library packages can be built >> entirely separately from GHC, so their configure scripts are designed to be >> standalone. library packages are haskell packages, and much of the configuration data should be common (plus a few package-specific checks). would it be possible to have a "configuration package" with nothing but the common checks? then every package, and ghc itself, could depend on that package being there, and every package configure could modularly use the information from that package. such a package might also encode the information in haskell, for use in cabal? perhaps creating such common info should be a cabal feature, factoring common checks from the package configure files to cabal, which would need access to some shared configuration file to store and retrieve the info? that way, once you've got cabal built on a platform, there'd be no need to repeat the common suspects of tests in individual configure files? just thinking out loud,-) claus From simonpj at microsoft.com Tue May 1 11:07:30 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 1 11:04:53 2007 Subject: recent Windows installer for ghc head? In-Reply-To: References: Message-ID: Following the "snapshot distribution" link on GHC's download page yields this http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 That seems to be a tar bundle for Windows; it's not an msi but if you unpack it you should be able to run it just fine. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 27 April 2007 20:03 To: glasgow-haskell-users@haskell.org Subject: recent Windows installer for ghc head? I'd like to try out the new & improved combination of type classes and GADTs, which I understand is only in head. Is there a recent working windows installer for head? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070501/a8f49481/attachment.htm From josef.svenningsson at gmail.com Tue May 1 11:58:12 2007 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Tue May 1 11:55:39 2007 Subject: More speed please! In-Reply-To: References: <1174006562.5005.63.camel@localhost> <1174116191.5038.13.camel@localhost> Message-ID: <8dde104f0705010858x661de3c2of7c206bc2c4905b2@mail.gmail.com> I'm replying to a rather old thread here, about unboxing in functions. Duncan had a continuation monad which passed around some data type that would be nice to unbox. You discussed strictness annotations in function types as a potential solution. I have a different tack on the problem which seems potentially useful. I've experimented with doing local defunctionalization on the module. This is a long mail as I will try to explain in some detail what it is that I have done. Please be patient. Normal defunctionalization is about replacing the primitive function type "a -> b" with an algebraic data type which I'll call "Fun a b". Not all functions will be eliminated as we will see but the program will be first order after the transformation. The core of the transformation is that every lambda in the program gives rise to a new constructor in the Fun data type and whenever we apply a function we instead call a newly created "apply function" with the following type "Fun a b -> a -> b". This is basically what JHC does. Defunctionalization is normally a whole program transformation (which is why JHC is a whole program compiler). But sometimes it can be done on a per module basis. This is where *local* defunctionalization comes in. The key to local defunctionalization is that we often can divide the data type Fun into several disjoint data types. We can do this whenever there are several different function spaces that never get mixed up. And sometimes we're even so lucky that a function space is totally contained in one module. Then we can do local defunctionalization of that particular function space only and completely within that module without changing it's interface. This case often comes up when using the continuation monad and Duncan's code is not an exception. So, I've manually done local defunctionalization on Duncan's code. It gives rise to two types which I've called Fun1 and Fun2. They look like follows (including the Put monad): \begin{code} newtype Put a = Put { runPut :: Fun2 a } data Fun1 a where Bind :: (a -> Put b) -> Fun1 b -> Fun1 a Then :: Put b -> Fun1 b -> Fun1 a Run :: Fun1 () FlushOld :: !(Fun1 ()) -> !Int -> !(ForeignPtr Word8) -> !Int -> !Int -> Fun1 () data Fun2 a where Return :: a -> Fun2 a Bind2 :: Put a -> (a -> Put b) -> Fun2 b Then2 :: Put a -> Put b -> Fun2 b Flush :: Fun2 () Write :: !Int -> (Ptr Word8 -> IO ()) -> Fun2 () \end{code} Intuitively every constructor corresponds to a closure. I've chosen the name for the constructor based on which function the closure appears in. The respective apply functions for these data types acts as interpreters and executes the corresponding code for each constructor/closure. Their type look as follow: \begin{code} apply1 :: Fun1 a -> a -> Buffer -> [B.ByteString] apply2 :: Fun2 a -> Fun1 a -> Buffer -> [B.ByteString] \end{code} Now, the cool thing is that once GHC starts optimizing away on these apply functions they will be unboxed and no Buffer will ever be created or passed around. Here is the core type for apply1: \begin{core} $wapply1_r21p :: forall a_aQu. PutMonad.Fun1 a_aQu -> a_aQu -> GHC.Prim.Addr# -> GHC.ForeignPtr.ForeignPtrContents -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [Data.ByteString.Base.ByteString] \end{core} This is exactly what Duncan wanted, right? I declare victory :-) However, things are not all roses. There are some functions that will not be unboxed as we hope for with this approach, for instance the function flushOld (see Duncan's code). To achieve the best possible optimization I think one would have to perform strictness analysis and the worker-wrapper transformation twice, once before doing local defunctionalization and then again on the apply functions generated by the defunctionalization process. This should give the code that Duncan wants I believe. I think it should be relatively straightforward to implement local defunctionalization in GHC but it should not be turned on by default as the number of modules where it is beneficial is rather few. The complete defunctionalized version of Duncan's module is attached. I'm sure there are a lot of things that are somewhat unclear in this message. Feel free to ask and I'll do my best to clarify. Cheers, Josef -------------- next part -------------- A non-text attachment was scrubbed... Name: PutMonadDefunc2.hs Type: text/x-haskell Size: 4659 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070501/cae356cf/PutMonadDefunc2-0001.bin From v.dijk.bas at gmail.com Tue May 1 15:36:40 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue May 1 15:34:00 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: <20070429143159.GA6112@matrix.chaos.earth.li> References: <20070429143159.GA6112@matrix.chaos.earth.li> Message-ID: On 4/29/07, Ian Lynagh wrote: > > Hi Bas, > > On Sun, Apr 29, 2007 at 11:54:35AM +0000, Bas van Dijk wrote: > > > > I'm trying to build GHC from darcs. Unfortunately compilation fails > > with the following error: > > > > ... > > cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) > > in GHC/Num.lhs at line 27 col 1 > > make[1]: *** [doc.library.base] Error 1 > > make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' > > make: *** [stage1] Error 2 > > ... > > > > The following is the part where the error occurs in > > libraries/base/GHC/Num.lhs : > > ... > > #include "MachDeps.h" > > #if SIZEOF_HSWORD == 4 > > This is a cpphs bug - IIRC it wasn't recursively expanding > SIZEOF_HSWORD. Either install cpphs from darcs (I don't think there is a > release with the fix yet) or uninstall it so that cpp is used instead. > > > Thanks > Ian After uninstalling cpphs the error no longer occurs, thanks! However the build now crashes when running Haddock on Cabal: ... ifBuildable/ifBuildable Cabal setup/Setup haddock Preprocessing library Cabal-1.1.7... Running Haddock for Cabal-1.1.7... Warning: cannot use package base-2.1: ghc-pkg failed dist/build/tmp/Distribution/PreProcess.hs:"Distribution/PreProcess.hs": 115:1: parse error in doc string: [TokSpecial '/',TokString "build",TokSpecial '"'] make[1]: *** [doc.library.Cabal] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 The respected code from libraries/Cabal/Distribution/PreProcess.hs (line 115 and onwards a bit): data PreProcessor = PreProcessor { -- Is the output of the pre-processor platform independent? eg happy output -- is portable haskell but c2hs's output is platform dependent. -- This matters since only platform independent generated code can be -- inlcuded into a source tarball. platformIndependent :: Bool, -- TODO: deal with pre-processors that have implementaion dependent output -- eg alex and happy have --ghc flags. However we can't really inlcude -- ghc-specific code into supposedly portable source tarballs. runPreProcessor :: (FilePath, FilePath) -- Location of the source file relative to a base dir -> (FilePath, FilePath) -- Output file name, relative to an output base dir -> Int -- verbosity -> IO () -- Should exit if the preprocessor fails } Do I maybe need a newer Haddock for this? Currently I have version 0.8. Installing darcs version right now... Thanks, Bas van Dijk From isaacdupree at charter.net Tue May 1 19:48:00 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue May 1 19:44:04 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461EA8A2.2000601@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <461CBA88.4000901@charter.net> <461E04FE.7010507@charter.net> <461E20B7.1080707@gmail.com> <461EA8A2.2000601@charter.net> Message-ID: <4637D1B0.80308@charter.net> Okay, first steps: 1. A Trac ticket (#1318, http://hackage.haskell.org/trac/ghc/ticket/1318) (is "feature request" a good category, versus "task"?) 2. A test-case to make sure I don't break anything with existing '-' syntax. I'm guessing it should go in testsuite/tests/ghc-regress/parser/should_run/, although maybe since it checks Haskell-98 compatibility it should go in the testsuite/tests/h98 directory? (tested ghc and hugs, which both pass) Isaac (test-case attached in case anyone wants to look at or review it; I'll send a darcs patch adding the testcase once I know where to put it) -------------- next part -------------- A non-text attachment was scrubbed... Name: negateH98tests.hs Type: text/x-haskell Size: 1512 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070501/fd344a25/negateH98tests.bin From simonmarhaskell at gmail.com Wed May 2 05:41:43 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 2 05:39:03 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: References: <20070429143159.GA6112@matrix.chaos.earth.li> Message-ID: <46385CD7.2040807@gmail.com> Bas van Dijk wrote: > However the build now crashes when running Haddock on Cabal: > ... > ifBuildable/ifBuildable Cabal setup/Setup haddock > Preprocessing library Cabal-1.1.7... > Running Haddock for Cabal-1.1.7... > Warning: cannot use package base-2.1: > ghc-pkg failed > dist/build/tmp/Distribution/PreProcess.hs:"Distribution/PreProcess.hs": > 115:1: parse error in doc string: [TokSpecial '/',TokString > "build",TokSpecial '"'] > make[1]: *** [doc.library.Cabal] Error 1 > make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' > make: *** [stage1] Error 2 Thanks, I think I've fixed this one now. Cheers, Simon From v.dijk.bas at gmail.com Wed May 2 08:00:52 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed May 2 07:58:09 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: <46385CD7.2040807@gmail.com> References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> Message-ID: On 5/2/07, Simon Marlow wrote: > Thanks, I think I've fixed this one now. You did indeed, thanks! Now I get another error when compiling main/GHC.hs: ../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64 -opta-march=athlon64 -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include "cutils.h"' -package-name ghc-6.7.20070502 -fgenerics -c main/GHC.hs -o stage2/main/GHC.o -ohi stage2/main/GHC.hi main/GHC.hs:2223:50: Couldn't match expected type `InteractiveContext' against inferred type `[Name]' In the sixth argument of `ResumeHandle', namely `names' In the expression: ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names In the definition of `res': res = ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names main/GHC.hs:2230:54: Couldn't match expected type `InteractiveContext' against inferred type `[Name]' In the `hsc_IC' field of a record In the second argument of `writeIORef', namely `hsc_env {hsc_IC = final_ic}' In the expression: writeIORef ref (hsc_env {hsc_IC = final_ic}) main/GHC.hs:2270:26: Constructor `ResumeHandle' should have 7 arguments, but has been given 6 In the pattern: ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names In the definition of `resume': resume (Session ref) (res@(ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names)) = do hsc_env <- readIORef ... writeIORef ... (...) .... <> make[2]: *** [stage2/main/GHC.o] Error 1 make[2]: Leaving directory `/home/bas/development/haskell/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/bas/development/haskell/ghc' make: *** [bootstrap2] Error 2 regards, Bas van Dijk From simonmarhaskell at gmail.com Wed May 2 10:30:25 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 2 10:27:46 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> Message-ID: <4638A081.9090201@gmail.com> Bas van Dijk wrote: > On 5/2/07, Simon Marlow wrote: >> Thanks, I think I've fixed this one now. > > You did indeed, thanks! > > Now I get another error when compiling main/GHC.hs: > > ../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64 > -opta-march=athlon64 -istage2/utils -istage2/basicTypes > -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename > -istage2/typecheck -istage2/deSugar -istage2/coreSyn > -istage2/specialise -istage2/simplCore -istage2/stranal > -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main > -istage2/profiling -istage2/parser -istage2/cprAnalysis > -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen > -istage2/ghci -Istage2 -DGHCI -package template-haskell > -DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE > -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package > unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot > -fasm -H16M '-#include "cutils.h"' -package-name ghc-6.7.20070502 > -fgenerics -c main/GHC.hs -o stage2/main/GHC.o -ohi > stage2/main/GHC.hi > > main/GHC.hs:2223:50: > Couldn't match expected type `InteractiveContext' > against inferred type `[Name]' > In the sixth argument of `ResumeHandle', namely `names' > In the expression: > ResumeHandle > breakMVar statusMVar final_names final_ic resume_ic names > In the definition of `res': > res = ResumeHandle > breakMVar statusMVar final_names final_ic resume_ic names I believe this one is now fixed, sorry about that. Cheers, Simon From ndmitchell at gmail.com Wed May 2 11:00:05 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 2 10:57:23 2007 Subject: GHC -O2 and unsafePerformIO Message-ID: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> Hi I have a program (below) which when compiled with -O2 gives the result: H:\work\supero\charcount>type log.txt | diff.exe i am here 109 done The process tried to write to a nonexistent pipe. And when compiled with -O0 gives: H:\work\supero\charcount>type log.txt | diff i am here 109 i am here 111 done The process tried to write to a nonexistent pipe. It tries to read two characters, so I really do want two characters to appear. I have tried NOINLINE, but with no effect. Any suggestions? Thanks Neil --------------- -- The program import System.IO.Unsafe import System.IO import Data.Word import Debug.Trace main = p_System_IO_hGetChar 1 `seq` p_System_IO_hGetChar 2 `seq` putStrLn "done" {-# NOINLINE wrapIO #-} wrapIO x = unsafePerformIO (x >>= return) foreign import ccall "stdio.h getchar" getchar :: IO Word8 {-# NOINLINE p_System_IO_hGetChar #-} p_System_IO_hGetChar h = trace "i am here" $ wrapIO (getchar >>= \c -> print c >> return (if c == (-1) then 0 else chr_ c)) chr_ = fromEnum From bulat.ziganshin at gmail.com Wed May 2 11:09:03 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 2 11:10:04 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> Message-ID: <1327857984.20070502190903@gmail.com> Hello Neil, Wednesday, May 2, 2007, 7:00:05 PM, you wrote: > {-# NOINLINE wrapIO #-} > wrapIO x = unsafePerformIO (x >>= return) -fno-cse ? it's usual company for unsafePerformIO+NOINLINE :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Wed May 2 11:17:49 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 2 11:15:08 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <1327857984.20070502190903@gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> <1327857984.20070502190903@gmail.com> Message-ID: <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> Hi Bulat, > Wednesday, May 2, 2007, 7:00:05 PM, you wrote: > > {-# NOINLINE wrapIO #-} > > wrapIO x = unsafePerformIO (x >>= return) > > -fno-cse ? it's usual company for unsafePerformIO+NOINLINE :) No luck, alas. A slightly tweaked version, which is slightly simpler and still gives the same behaviour is below. Thanks Neil ---------------------- main = p_System_IO_hGetChar undefined `seq` p_System_IO_hGetChar 12 `seq` putStrLn "done" foreign import ccall "stdio.h getchar" getchar :: IO Word8 {-# NOINLINE p_System_IO_hGetChar #-} p_System_IO_hGetChar h = trace "i am here" $ unsafePerformIO (getchar >>= \c -> print c >> return (if c == (-1) then 0 else chr_ c)) chr_ = fromEnum From ndmitchell at gmail.com Wed May 2 11:33:39 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 2 11:30:56 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> <1327857984.20070502190903@gmail.com> <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> Message-ID: <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> Hi Thanks to dcoutts, I have now come up with an answer. I don't understand why it works now, but not before. I do remember than browsing either Core or STG is not a fun thing to do... p_System_IO_hGetChar h = trace "i am here" $ unsafePerformIO $ getCharIO h {-# NOINLINE getCharIO #-} getCharIO h = do c <- getchar print c return $ if c == (-1) then 0 else chr_ c Thanks Neil On 5/2/07, Neil Mitchell wrote: > Hi Bulat, > > > Wednesday, May 2, 2007, 7:00:05 PM, you wrote: > > > {-# NOINLINE wrapIO #-} > > > wrapIO x = unsafePerformIO (x >>= return) > > > > -fno-cse ? it's usual company for unsafePerformIO+NOINLINE :) > > No luck, alas. A slightly tweaked version, which is slightly simpler > and still gives the same behaviour is below. > > Thanks > > Neil > > > ---------------------- > > > > main = p_System_IO_hGetChar undefined `seq` p_System_IO_hGetChar 12 > `seq` putStrLn "done" > > foreign import ccall "stdio.h getchar" getchar :: IO Word8 > > {-# NOINLINE p_System_IO_hGetChar #-} > p_System_IO_hGetChar h = trace "i am here" $ > unsafePerformIO (getchar >>= \c -> print c >> return (if c == > (-1) then 0 else chr_ c)) > > chr_ = fromEnum > From v.dijk.bas at gmail.com Wed May 2 11:36:32 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed May 2 11:33:49 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: <4638A081.9090201@gmail.com> References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> <4638A081.9090201@gmail.com> Message-ID: On 5/2/07, Simon Marlow wrote: > I believe this one is now fixed, sorry about that. No problem. I'm now able to successfully make GHC. Thanks about that! However 'make install' fails: $ make install ... ifBuildable/ifBuildable base setup/Setup install copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. ... copy dist/build/HSbase-2.1.o to /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o Registering base-2.1... Reading package info from ".installed-pkg-config" ... done. ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist or isn't a directory (use --force to override) make[1]: *** [install.library.base] Error 1 make: *** [install] Error 1 The directory: /home/bas/lib/base-2.1/ghc-6.7.20070502/include indeed does not exists. What can be the problem? regards, Bas van Dijk From duncan.coutts at worc.ox.ac.uk Wed May 2 12:06:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 2 12:16:11 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> <1327857984.20070502190903@gmail.com> <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> Message-ID: <1178121972.9770.64.camel@localhost> On Wed, 2007-05-02 at 16:33 +0100, Neil Mitchell wrote: > Hi > > Thanks to dcoutts, I have now come up with an answer. I don't > understand why it works now, but not before. main = p_System_IO_hGetChar 1 `seq` p_System_IO_hGetChar 2 `seq` putStrLn "done" This is fine (though note that p_System_IO_hGetChar 1 is a constant) the real problem is here: {-# NOINLINE p_System_IO_hGetChar #-} p_System_IO_hGetChar h = trace "i am here" $ unsafePerformIO $ getchar >>= \c -> print c >> return (if c == (-1) then 0 else chr_ c) You've tried to trick ghc into always calling this by passing a dummy 'h' parameter. Then 'h' is never used in the body. Note however that the whole body of this function is a constant and so ghc can (and at -O2 does) float it out as a CAF. This means you get the side effects of p_System_IO_hGetChar at most once. The solution of course is to use a full data dependency like IO or ST uses. > I do remember than browsing either Core or STG is not a fun thing to > do... So yeah, we see the above CAFs and let floating by looking at the core. We could do with a prettier pretty printer for core, I agree. Duncan From conal at conal.net Wed May 2 14:10:06 2007 From: conal at conal.net (Conal Elliott) Date: Wed May 2 14:07:24 2007 Subject: recent Windows installer for ghc head? In-Reply-To: References: Message-ID: Thanks for the pointer. I get failures (below) when I try to "make install". Does anyone have a suggestion? - Conal bash-3.2$ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin Which we'll further canonicalise into: i386-unknown-cygwin32 checking for perl... /cygdrive/c/Perl/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for sed... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking version of gcc... 3.4.4 checking how to run the C preprocessor... gcc -E configure: creating ./config.status config.status: creating Makefile **************************************************** Configuration done, ready to either 'make install' or 'make in-place'. (see README and INSTALL files for more info.) **************************************************** bash-3.2$ make in-place make config-pkgs bindir=`pwd`/bin/i386-unknown-cygwin32 libdir=`pwd`/lib/i386-unknown-cygwin32 datadir=`pwd`/share make[1]: Entering directory `/cygdrive/c/ghc/ghc-6.7.20070404' Configuring ghc, version 6.7.20070404.20070404, on i386-unknown-cygwin32 ... Creating a configured version of ghcprof .. /bin/sh: line 5: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 6: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 7: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 8: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 9: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 10: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 11: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 12: bin/i386-unknown-cygwin32/ghcprof: No such file or directory chmod: cannot access `bin/i386-unknown-cygwin32/ghcprof': No such file or directory Done. Creating a configured version of ghc-asm .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-asm': No such file or directory Done. Creating a configured version of ghc-split .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-split: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-split': No such file or directory Done. Creating a configured version of package.conf .. Can't open lib/i386-unknown-cygwin32/package.conf: No such file or directory. make[1]: Leaving directory `/cygdrive/c/ghc/ghc-6.7.20070404' Finished configuring..to use, add /cygdrive/c/ghc/ghc-6.7.20070404/bin/i386-unknown-cygwin32 to your PATH. bash-3.2$ On 5/1/07, Simon Peyton-Jones wrote: > > Following the "snapshot distribution" link on GHC's download page yields > this > > > http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 > > > > That seems to be a tar bundle for Windows; it's not an msi but if you > unpack it you should be able to run it just fine. > > > > Simon > > > > *From:* glasgow-haskell-users-bounces@haskell.org [mailto: > glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 27 April 2007 20:03 > *To:* glasgow-haskell-users@haskell.org > *Subject:* recent Windows installer for ghc head? > > > > I'd like to try out the new & improved combination of type classes and > GADTs, which I understand is only in head. Is there a recent working > windows installer for head? > > Thanks, - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070502/ca92323d/attachment-0001.htm From claus.reinke at talk21.com Wed May 2 15:34:48 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 2 15:32:11 2007 Subject: recent Windows installer for ghc head? References: Message-ID: <004c01c78cf0$f34d2f30$81148351@cr3lt> > Thanks for the pointer. I get failures (below) when I try to "make > install". Does anyone have a suggestion? - Conal if you are talking about the good old-fashioned snapshots, there shouldn't be any configuration or install, just untar where you need it? claus > bash-3.2$ ./configure > checking build system type... i686-pc-cygwin > checking host system type... i686-pc-cygwin > checking target system type... i686-pc-cygwin > Which we'll further canonicalise into: i386-unknown-cygwin32 > checking for perl... /cygdrive/c/Perl/bin/perl > checking if your perl works in shell scripts... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether ln -s works... yes > checking for sed... /usr/bin/sed > checking for gcc... gcc > checking for C compiler default output file name... a.exe > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... .exe > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking version of gcc... 3.4.4 > checking how to run the C preprocessor... gcc -E > configure: creating ./config.status > config.status: creating Makefile > **************************************************** > Configuration done, ready to either 'make install' > or 'make in-place'. > (see README and INSTALL files for more info.) > **************************************************** > > bash-3.2$ make in-place > make config-pkgs bindir=`pwd`/bin/i386-unknown-cygwin32 > libdir=`pwd`/lib/i386-unknown-cygwin32 datadir=`pwd`/share > make[1]: Entering directory `/cygdrive/c/ghc/ghc-6.7.20070404' > Configuring ghc, version 6.7.20070404.20070404, on i386-unknown-cygwin32 ... > Creating a configured version of ghcprof .. > /bin/sh: line 5: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 6: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 7: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 8: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 9: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 10: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 11: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > /bin/sh: line 12: bin/i386-unknown-cygwin32/ghcprof: No such file or > directory > chmod: cannot access `bin/i386-unknown-cygwin32/ghcprof': No such file or > directory > Done. > Creating a configured version of ghc-asm .. > /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-asm: No such file or > directory > chmod: cannot access `lib/i386-unknown-cygwin32/ghc-asm': No such file or > directory > Done. > Creating a configured version of ghc-split .. > /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-split: No such file or > directory > chmod: cannot access `lib/i386-unknown-cygwin32/ghc-split': No such file or > directory > Done. > Creating a configured version of package.conf .. > Can't open lib/i386-unknown-cygwin32/package.conf: No such file or > directory. > make[1]: Leaving directory `/cygdrive/c/ghc/ghc-6.7.20070404' > Finished configuring..to use, add > /cygdrive/c/ghc/ghc-6.7.20070404/bin/i386-unknown-cygwin32 > to your PATH. > bash-3.2$ > > > On 5/1/07, Simon Peyton-Jones wrote: >> >> Following the "snapshot distribution" link on GHC's download page yields >> this >> >> >> http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 >> >> >> >> That seems to be a tar bundle for Windows; it's not an msi but if you >> unpack it you should be able to run it just fine. >> >> >> >> Simon >> >> >> >> *From:* glasgow-haskell-users-bounces@haskell.org [mailto: >> glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Conal Elliott >> *Sent:* 27 April 2007 20:03 >> *To:* glasgow-haskell-users@haskell.org >> *Subject:* recent Windows installer for ghc head? >> >> >> >> I'd like to try out the new & improved combination of type classes and >> GADTs, which I understand is only in head. Is there a recent working >> windows installer for head? >> >> Thanks, - Conal >> > -------------------------------------------------------------------------------- > _______________________________________________ > 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 Wed May 2 15:51:32 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed May 2 15:48:55 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> <4638A081.9090201@gmail.com> Message-ID: <20070502195132.GB4542@zombie.inf.tu-dresden.de> [Note: Sorry if this is a duplicate. I originally sent the patches inline in the mail, but the resulting mail grew rather big and is "awaiting moderators approval" now. (moderators: no need to approve it)] Bas van Dijk wrote: > On 5/2/07, Simon Marlow wrote: > >I believe this one is now fixed, sorry about that. > > No problem. I'm now able to successfully make GHC. Thanks about that! > > However 'make install' fails: > > > $ make install > ... > ifBuildable/ifBuildable base setup/Setup install > copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. > ... > copy dist/build/HSbase-2.1.o to > /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o > > Registering base-2.1... > Reading package info from ".installed-pkg-config" ... done. > ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist [...] I'm sorry, that's my fault. I have two patches that should fix this: One for libraries/Cabal, http://int-e.home.tlink.de/haskell/Cabal-fix-installIncludeFiles.patch and another for libraries/base: http://int-e.home.tlink.de/haskell/base-install-includes.patch The semantics for the includes: and install-includes: fields in cabal files has changed; the patch against base adds an install-includes field to the base.cabal file that uses the new semantics. I was going to send this patch in now anyway. I'm afraid I missed the interaction of the install directory and the package registration, and obviously I didn't test this properly. So I revert the behaviour back to always creating the include directory. Bertram From simonmarhaskell at gmail.com Thu May 3 03:57:25 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 3 03:54:52 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> <1327857984.20070502190903@gmail.com> <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> Message-ID: <463995E5.2000204@gmail.com> Neil Mitchell wrote: > Hi > > Thanks to dcoutts, I have now come up with an answer. I don't > understand why it works now, but not before. I do remember than > browsing either Core or STG is not a fun thing to do... > > p_System_IO_hGetChar h = trace "i am here" $ > unsafePerformIO $ getCharIO h > > > {-# NOINLINE getCharIO #-} > getCharIO h = do > c <- getchar > print c > return $ if c == (-1) then 0 else chr_ c This is clearly a misuse of unsafePerformIO (as I'm sure you're aware). Just out of interest - what's the context? Cheers, Simon From ndmitchell at gmail.com Thu May 3 04:59:51 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 3 04:57:05 2007 Subject: GHC -O2 and unsafePerformIO In-Reply-To: <463995E5.2000204@gmail.com> References: <404396ef0705020800x54b7f17coa1eca4875dff28a4@mail.gmail.com> <1327857984.20070502190903@gmail.com> <404396ef0705020817w5a12740erce6bcecadd640870@mail.gmail.com> <404396ef0705020833r317848eeka1aaa41d1723cec9@mail.gmail.com> <463995E5.2000204@gmail.com> Message-ID: <404396ef0705030159q6fba728di26e89b1c4262e8e@mail.gmail.com> Hi Simon, > This is clearly a misuse of unsafePerformIO (as I'm sure you're aware). Just > out of interest - what's the context? I am writing an optimiser for Yhc, doing whole-program optimisation, with the intention of keeping it fast and high performance. Since writing out Yhc bytecode would kill any performance benefits, I am writing back to Haskell to be compiled with GHC. So the basic sequence of steps is: compile Haskell to Yhc Core transform Yhc Core convert Yhc Core to Haskell compile Haskell to GHC The problem I'm currently overcoming is that Yhc inserts its own IO monad, which isn't the same as the GHC one. By the time I get to GHC Haskell, all of the Yhc monad is invisible to GHC, so I have to unsafePerformIO the getchar/putchar functions. With this as the primitive getchar, it seems to work for my particular example, but is clearly a bit fragile. All the examples I'm doing for now are wc -c, wc -l, so shouldn't stress the IO much more than getchar/putchar. Thanks Neil From v.dijk.bas at gmail.com Thu May 3 06:31:34 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu May 3 06:28:48 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: <20070502195132.GB4542@zombie.inf.tu-dresden.de> References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> <4638A081.9090201@gmail.com> <20070502195132.GB4542@zombie.inf.tu-dresden.de> Message-ID: On 5/2/07, Bertram Felgenhauer wrote: > ... > I have two patches that should fix this: > ... Thanks, I applied base-install-includes.patch. (Cabal-fix-installIncludeFiles.patch was already applied according to darcs.) However, in order to apply the patches I did a new checkout of GHC without the --partial. This seemed to have pulled a few new patches that break my build again. I fixed the first error (I darcs send the patch): ./compiler/coreSyn/CoreUtils.lhs 262 -mkAltExpr DEFAULT = panic "mkAltExpr" +mkAltExpr DEFAULT _ _ = panic "mkAltExpr" This leaves the second error when building base: Building base-2.1... GHC/Exts.hs:29:1: Not in scope: type constructor or class `IsString' If I import Data.String in GHC/Exts.hs I get the following error: Building base-2.1... ghc-6.7.20070502: panic! (the 'impossible' happened) (GHC version 6.7.20070502 for i386-unknown-linux): mkWWcpr: not a product base:Data.Typeable.TypeRep{tc r3eN} What can be the problem? regards, Bas van Dijk From simonpj at microsoft.com Thu May 3 08:34:12 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 3 08:31:29 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> <4638A081.9090201@gmail.com> <20070502195132.GB4542@zombie.inf.tu-dresden.de> Message-ID: the base library is in a bit of a sad state. I think I have fixed it. Try pulling (both compiler and libraries) and try again S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Bas van Dijk | Sent: 03 May 2007 11:32 | To: Bertram Felgenhauer | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Error compiling GHC/Num.lhs | | On 5/2/07, Bertram Felgenhauer wrote: | > ... | > I have two patches that should fix this: | > ... | | Thanks, I applied base-install-includes.patch. | (Cabal-fix-installIncludeFiles.patch was already applied according to | darcs.) | | However, in order to apply the patches I did a new checkout of GHC | without the --partial. This seemed to have pulled a few new patches | that break my build again. | | I fixed the first error (I darcs send the patch): | | ./compiler/coreSyn/CoreUtils.lhs 262 | -mkAltExpr DEFAULT = panic "mkAltExpr" | +mkAltExpr DEFAULT _ _ = panic "mkAltExpr" | | | This leaves the second error when building base: | | Building base-2.1... | | GHC/Exts.hs:29:1: | Not in scope: type constructor or class `IsString' | | If I import Data.String in GHC/Exts.hs I get the following error: | | Building base-2.1... | ghc-6.7.20070502: panic! (the 'impossible' happened) | (GHC version 6.7.20070502 for i386-unknown-linux): | mkWWcpr: not a product base:Data.Typeable.TypeRep{tc r3eN} | | What can be the problem? | | regards, | | Bas van Dijk | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From cmb21 at kent.ac.uk Thu May 3 08:50:01 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Thu May 3 08:47:23 2007 Subject: Pretty printing type annotations Message-ID: Hi, I was wondering if there was an easy way to pretty print the result of the type checker from GHC. I basically want the format that GHCi spits out, rather than a type annotation with qualified types. I know I can knock up a parser that removes the qualifiers, but I was wondering if there was a simple function that I could call that would just printy print it for me (and saving me the work). The type checker gives me something of the form: (GHC.Num.Num t1, GHC.Num.Num t) => t1 -> t -> t1 But GHCi gives me the same without any qualifying. Hope someone can help. Chris. From v.dijk.bas at gmail.com Thu May 3 09:09:05 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu May 3 09:06:20 2007 Subject: Error compiling GHC/Num.lhs In-Reply-To: References: <20070429143159.GA6112@matrix.chaos.earth.li> <46385CD7.2040807@gmail.com> <4638A081.9090201@gmail.com> <20070502195132.GB4542@zombie.inf.tu-dresden.de> Message-ID: On 5/3/07, Simon Peyton-Jones wrote: > I think I have fixed it... You did, thanks very much! GHC now builds and install without any errors, jippy! Thanks, Bas van Dijk From ahey at iee.org Thu May 3 11:24:26 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 3 11:21:46 2007 Subject: Why do we have stack overflows? Message-ID: <4639FEAA.2030902@iee.org> Hello Folks, Just wondering about this. Please understand I'm not asking why programs use a lot of stack sometimes, but specifically why is using a lot of stack (vs. using a lot of heap) generally regarded as "bad". Or at least it seems that way given that ghc run time makes distinction between the two and sets separate limits for them (default max stack size being relatively small whereas default max heap size in unlimited). So programs can fail with a stack overflow despite having bucket loads of heap available? Frankly I don't care if my program fails because it's used a lot of stack or a lot of heap. I would rather set some common memory budget and have them fail if that budget was exceeded. This policy seems to have unfortunate consequences. Sometimes you end up re-writing stuff in a manner that just trades stack use for heap use (I.E. doesn't do anything to reduce overall memory consumption). Given the cost of reclaiming heap is rather high (compared to stack), this seems like bad idea (the version that used a lot of stack would be better IMO if only it didn't risk stack overflow). Example.. -- Strict version of take stackGobbler :: Int -> [x] -> [x] stackGobbler 0 _ = [] stackGobbler _ [] = [] stackGobbler n (x:xs) = let xs' = stackGobbler (n-1) xs in xs' `seq` (x:xs') -- Another strict version of take heapGobbler :: Int -> [x] -> [x] heapGobbler = heapGobbler' [] where heapGobbler' rxs 0 _ = reverse rxs heapGobbler' rxs _ [] = reverse rxs heapGobbler' rxs n (x:xs) = heapGobbler' (x:rxs) (n-1) xs But I guess everyone here is already aware of this, hence the question (current ghc memory system design seems a bit odd, but maybe there's a good reason why the rts can't work the way I would like). Thanks -- Adrian Hey From duncan.coutts at worc.ox.ac.uk Thu May 3 11:39:28 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 3 11:49:25 2007 Subject: Why do we have stack overflows? In-Reply-To: <4639FEAA.2030902@iee.org> References: <4639FEAA.2030902@iee.org> Message-ID: <1178206768.9770.113.camel@localhost> On Thu, 2007-05-03 at 16:24 +0100, Adrian Hey wrote: > Hello Folks, > > Just wondering about this. Please understand I'm not asking why > programs use a lot of stack sometimes, but specifically why is > using a lot of stack (vs. using a lot of heap) generally regarded > as "bad". Or at least it seems that way given that ghc run time > makes distinction between the two and sets separate > limits for them (default max stack size being relatively small > whereas default max heap size in unlimited). So programs can > fail with a stack overflow despite having bucket loads of heap > available? Perhaps it's there to help people who write simple non-terminating recursion. They'll get an error message fairly soon rather than using all memory on the machine and invoking the wrath of the OOM killer. Duncan From ahey at iee.org Thu May 3 12:40:24 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 3 12:37:42 2007 Subject: Why do we have stack overflows? In-Reply-To: <1178206768.9770.113.camel@localhost> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> Message-ID: <463A1078.7090608@iee.org> Duncan Coutts wrote: > On Thu, 2007-05-03 at 16:24 +0100, Adrian Hey wrote: >> Hello Folks, >> >> Just wondering about this. Please understand I'm not asking why >> programs use a lot of stack sometimes, but specifically why is >> using a lot of stack (vs. using a lot of heap) generally regarded >> as "bad". Or at least it seems that way given that ghc run time >> makes distinction between the two and sets separate >> limits for them (default max stack size being relatively small >> whereas default max heap size in unlimited). So programs can >> fail with a stack overflow despite having bucket loads of heap >> available? > > Perhaps it's there to help people who write simple non-terminating > recursion. They'll get an error message fairly soon rather than using > all memory on the machine and invoking the wrath of the OOM killer. Hmm, I still don't see why a "stack leak" should be treated differently from "heap leak". They'll both kill your program in the end. Regards -- Adrian Hey From john at repetae.net Thu May 3 19:59:58 2007 From: john at repetae.net (John Meacham) Date: Thu May 3 19:57:12 2007 Subject: Why do we have stack overflows? In-Reply-To: <463A1078.7090608@iee.org> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> Message-ID: <20070503235958.GA18281@momenergy.repetae.net> On Thu, May 03, 2007 at 05:40:24PM +0100, Adrian Hey wrote: > Duncan Coutts wrote: > >On Thu, 2007-05-03 at 16:24 +0100, Adrian Hey wrote: > >>Hello Folks, > >> > >>Just wondering about this. Please understand I'm not asking why > >>programs use a lot of stack sometimes, but specifically why is > >>using a lot of stack (vs. using a lot of heap) generally regarded > >>as "bad". Or at least it seems that way given that ghc run time > >>makes distinction between the two and sets separate > >>limits for them (default max stack size being relatively small > >>whereas default max heap size in unlimited). So programs can > >>fail with a stack overflow despite having bucket loads of heap > >>available? > > > >Perhaps it's there to help people who write simple non-terminating > >recursion. They'll get an error message fairly soon rather than using > >all memory on the machine and invoking the wrath of the OOM killer. > > Hmm, I still don't see why a "stack leak" should be treated differently > from "heap leak". They'll both kill your program in the end. I believe it is because a stack cannot be garbage collected, and must be traversed as roots for every garbage collection. I don't think there are any issues with a huge stack per se, but it does not play nice with garbage collection so may hurt your performance and memory usage in unforeseen ways. John -- John Meacham - ?repetae.net?john? From brandon at heave.ugcs.caltech.edu Thu May 3 20:36:45 2007 From: brandon at heave.ugcs.caltech.edu (Brandon Michael Moore) Date: Thu May 3 20:33:58 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070503235958.GA18281@momenergy.repetae.net> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> Message-ID: <20070504003645.GA13287@heave.ugcs.caltech.edu> On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: > I believe it is because a stack cannot be garbage collected, and must be > traversed as roots for every garbage collection. I don't think there are > any issues with a huge stack per se, but it does not play nice with > garbage collection so may hurt your performance and memory usage in > unforeseen ways. Isn't it just the top of the stack that has to be treadted as a root? (maybe you need to walk the stack to find exception handlers and so on.) Maybe it shouldn't be so much worse than a heap. The Chicken Scheme system allocates everything on the C stack, and runs some sort of compacting collector when it is about to fill. Brandon From stefanor at cox.net Thu May 3 21:21:19 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu May 3 21:18:34 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070504003645.GA13287@heave.ugcs.caltech.edu> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <20070504003645.GA13287@heave.ugcs.caltech.edu> Message-ID: <20070504012119.GA3568@localhost.localdomain> On Thu, May 03, 2007 at 05:36:45PM -0700, Brandon Michael Moore wrote: > On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: > > I believe it is because a stack cannot be garbage collected, and must be > > traversed as roots for every garbage collection. I don't think there are > > any issues with a huge stack per se, but it does not play nice with > > garbage collection so may hurt your performance and memory usage in > > unforeseen ways. > > Isn't it just the top of the stack that has to be treadted as a root? > (maybe you need to walk the stack to find exception handlers and so on.) > Maybe it shouldn't be so much worse than a heap. The Chicken Scheme > system allocates everything on the C stack, and runs some sort of > compacting collector when it is about to fill. GHC uses a simple exponential-backoff algorithm for handling stacks. When the stack pointer passes the stack limit, the thread yields to the scheduler, where the stack size is doubled, and the old stack is moved. Perhaps instead we could modify the algorithm such that up to 16K stack size the behaivor is the same, but use linked lists for larger? 1. Allocate a new chunk, of size 16KB. 2. Copy the topmost 1KB of stack to the new block. This decreases storage efficiency slightly (but not much in time - memcpy is several times faster than anything the current ghc code generator can generate), but it avoids a nasty corner case (stack size fluctuating across 0 mod 16K) by acting as a form of hysteresis. 3. Create a special frame at the bottom of the new stack chunk that returns into a stack underflow handler, thus avoiding the need for yet another conditional. Yes, 16KB unrolled linked lists are virtually as fast as flat byte arrays; see Data.ByteString.Lazy if you want proof. The only hard part appears to be step 3, as it requires finding an appropriate place to insert the trampoline frame; it seems plausible that stack frames are sufficiently self describing to make this a simple exercise of loops, but it could be much much harder. With this change GHC stacks could fill the whole heap with little more performance degradation than ordinary objects already give. Stefan From maeder at tzi.de Fri May 4 08:48:13 2007 From: maeder at tzi.de (Christian Maeder) Date: Fri May 4 08:45:32 2007 Subject: testsuite for GHC version 6.6.1? In-Reply-To: <20070426112223.GA26119@matrix.chaos.earth.li> References: <20070426112223.GA26119@matrix.chaos.earth.li> Message-ID: <463B2B8D.4010801@tzi.de> How or where can I pick up the testsuite for this new version? I want to test my own builds. Cheers Christian From ahey at iee.org Fri May 4 09:11:28 2007 From: ahey at iee.org (Adrian Hey) Date: Fri May 4 09:11:13 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070503235958.GA18281@momenergy.repetae.net> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> Message-ID: <463B3100.2010602@iee.org> John Meacham wrote: > I believe it is because a stack cannot be garbage collected, and must be > traversed as roots for every garbage collection. I don't think there are > any issues with a huge stack per se, but it does not play nice with > garbage collection so may hurt your performance and memory usage in > unforeseen ways. I'm still not convinced :-( I also don't believe it's in anybodys interest to have programs failing for no good reason. A good reason to fail is if overall memory demands are getting stupid. Failing because the stack has grown beyond some arbitrary (and typically small) size seems bad to me. I know that this is to a certain extent this is controllable using RTS options, but this is no use to me as a library writer tying to chose between stackGobbler and heapGobbler. The stuff should "just work" and not be dependent on the right RTS incantations being used when the final program is run. Regards -- Adrian Hey From kili at outback.escape.de Fri May 4 09:21:16 2007 From: kili at outback.escape.de (Matthias Kilian) Date: Fri May 4 09:22:17 2007 Subject: testsuite for GHC version 6.6.1? In-Reply-To: <463B2B8D.4010801@tzi.de> References: <20070426112223.GA26119@matrix.chaos.earth.li> <463B2B8D.4010801@tzi.de> Message-ID: <20070504132116.GB6405@petunia.outback.escape.de> On Fri, May 04, 2007 at 02:48:13PM +0200, Christian Maeder wrote: > How or where can I pick up the testsuite for this new version? I want to > test my own builds. http://www.haskell.org/ghc/dist/6.6.1/ghc-testsuite-6.6.1.tar.gz From Malcolm.Wallace at cs.york.ac.uk Fri May 4 09:37:43 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri May 4 09:35:24 2007 Subject: Why do we have stack overflows? In-Reply-To: <463B3100.2010602@iee.org> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <463B3100.2010602@iee.org> Message-ID: <20070504143743.45605491.Malcolm.Wallace@cs.york.ac.uk> Adrian Hey wrote: > Failing because the stack has > grown beyond some arbitrary (and typically small) size seems > bad to me. Just FYI, nhc98 has a single memory area in which the stack and heap grow towards each other. Memory exhaustion only happens when the stack and heap meet in the middle and GC fails to reclaim any space. However, it can only do this because it is single-threaded. As soon as you need a separate stack for each thread in a multi-threaded system, this nice one-dimensional model breaks down. Regards, Malcolm From ahey at iee.org Fri May 4 10:28:58 2007 From: ahey at iee.org (Adrian Hey) Date: Fri May 4 10:29:30 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070504143743.45605491.Malcolm.Wallace@cs.york.ac.uk> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <463B3100.2010602@iee.org> <20070504143743.45605491.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <463B432A.6040705@iee.org> Malcolm Wallace wrote: > Just FYI, nhc98 has a single memory area in which the stack and heap > grow towards each other. Memory exhaustion only happens when the stack > and heap meet in the middle and GC fails to reclaim any space. > > However, it can only do this because it is single-threaded. As soon as > you need a separate stack for each thread in a multi-threaded system, > this nice one-dimensional model breaks down. Yes. A while ago I did the same thing with a toy FPL I was tinkering with. But like nhc98, it was single threaded. But I don't believe this is a serious extra complication. ghc does seem to have the capability to grow stacks effectively without bound (and presumably shrink them too), but it doesn't do this by default for reasons I don't understand. My preference would be to have an upper limit on total (stack+heap) memory used. Also, as Stefan has suggested, I think stack should grow linearly, not exponentially. But I don't really know enough about the innards of ghc rts to know what might or might not be possible/easy/difficult. Regards -- Adrian Hey From mads_lindstroem at yahoo.dk Fri May 4 12:04:38 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Fri May 4 12:04:39 2007 Subject: GHC as a library - getting output from GHCI Message-ID: <1178294679.2509.0.camel@localhost.localdomain> Hi I am trying to use GHC as a library (see http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the output from an interactive session and put in a GUI. This http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a nice starting point. However, the result of: GHC.runStmt session stmt does not include the output of evaluating the statement (stmt above) - just the names of bound names. That is if stmt eqauls "3 + 5" then GHC.runStmt do not return a string equaling "8", but just the "it"-name (which is bound to 8). The output is printed to standard output :( And I do not see and easy way to get hold of it. The only way I see, is having the GUI in one process and "GHC as a library" in another process. Do anybody know of an easy way to get hold of the output from "GHC as a library" - the output currently printed to standard output? Greetings, Mads Lindstr?m From mnislaih at gmail.com Fri May 4 12:36:52 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Fri May 4 12:34:09 2007 Subject: GHC as a library - getting output from GHCI In-Reply-To: <1178294679.2509.0.camel@localhost.localdomain> References: <1178294679.2509.0.camel@localhost.localdomain> Message-ID: I believe that the trick is to wrap your stmt in a IO handler that captures stdout and returns it together with the value of your stmt. That is, something with a type: wrapStmt :: IO a -> IO (a,String) It should be easy to implement wrapStmt using System.Posix.Process. Then you just define runStmt' session stmt = runStmt session ("wrapStmt $ " ++ stmt) Good Luck! On 04/05/2007, at 18:04, Mads Lindstr?m wrote: > Hi > > I am trying to use GHC as a library (see > http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get > all the > output from an interactive session and put in a GUI. This > http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a > nice starting point. > > However, the result of: > > GHC.runStmt session stmt > > does not include the output of evaluating the statement (stmt above) - > just the names of bound names. That is if stmt eqauls "3 + 5" then > GHC.runStmt do not return a string equaling "8", but just the "it"- > name > (which is bound to 8). > > The output is printed to standard output :( And I do not see and easy > way to get hold of it. The only way I see, is having the GUI in one > process and "GHC as a library" in another process. > > Do anybody know of an easy way to get hold of the output from "GHC > as a > library" - the output currently printed to standard output? > > > Greetings, > > Mads Lindstr?m > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mads_lindstroem at yahoo.dk Fri May 4 13:19:16 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Fri May 4 13:19:17 2007 Subject: GHC as a library - getting output from GHCI In-Reply-To: References: <1178294679.2509.0.camel@localhost.localdomain> Message-ID: <1178299156.2509.12.camel@localhost.localdomain> Hi Pepe I would have liked something cross-platform. Also, if stmt contains an error, wrapStmt will not be evaluated, and the resulting error is written to standard output or maybe to standard error. Whichever way, I am back to the same problem. Greetings, Mads Lindstr?m > I believe that the trick is to wrap your stmt in a IO handler that > captures stdout and returns it together with the value of your stmt. > That is, something with a type: > > wrapStmt :: IO a -> IO (a,String) > > It should be easy to implement wrapStmt using System.Posix.Process. > Then you just define > > runStmt' session stmt = runStmt session ("wrapStmt $ " ++ stmt) > > Good Luck! > > On 04/05/2007, at 18:04, Mads Lindstr?m wrote: > > > Hi > > > > I am trying to use GHC as a library (see > > http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get > > all the > > output from an interactive session and put in a GUI. This > > http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a > > nice starting point. > > > > However, the result of: > > > > GHC.runStmt session stmt > > > > does not include the output of evaluating the statement (stmt above) - > > just the names of bound names. That is if stmt eqauls "3 + 5" then > > GHC.runStmt do not return a string equaling "8", but just the "it"- > > name > > (which is bound to 8). > > > > The output is printed to standard output :( And I do not see and easy > > way to get hold of it. The only way I see, is having the GUI in one > > process and "GHC as a library" in another process. > > > > Do anybody know of an easy way to get hold of the output from "GHC > > as a > > library" - the output currently printed to standard output? > > > > > > Greetings, > > > > Mads Lindstr?m > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From mnislaih at gmail.com Fri May 4 14:12:55 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Fri May 4 14:10:11 2007 Subject: GHC as a library - getting output from GHCI In-Reply-To: <1178299156.2509.12.camel@localhost.localdomain> References: <1178294679.2509.0.camel@localhost.localdomain> <1178299156.2509.12.camel@localhost.localdomain> Message-ID: Mads On 04/05/2007, at 19:19, Mads Lindstr?m wrote: > Hi Pepe > > I would have liked something cross-platform. > Take a look at the unix-compat[1] package by Bjorn Bringert, although it looks like it won't help you. Maybe it can be extended. > Also, if stmt contains an error, wrapStmt will not be evaluated, > and the > resulting error is written to standard output or maybe to standard > error. Whichever way, I am back to the same problem. What else should be the behaviour in the case stmt contains an error? You can capture errors and stop them being written out very easily. Take a look at this snippet (not mine, it's beschmi's code) from Shim [2]: \begin{code} load' :: FilePath -> Maybe String -> SHM (SuccessFlag, [CompileNote],Session) load' sourcefile source = do source' <- addTime source ses <- getSessionFor sourcefile dflags0 <- io $ GHC.getSessionDynFlags ses ref <- io $ MVar.newMVar [] let dflags1 = dflags0{ log_action = logMsg ref } io $ GHC.setSessionDynFlags ses dflags1 io $ GHC.setTargets ses [Target (TargetFile sourcefile Nothing) source'] loadResult <- io $ GHC.load ses LoadAllTargets cnotes <- io $ reverse `liftM` MVar.readMVar ref case loadResult of Succeeded -> do -- GHC takes care of setting the right context modq <- io $ findModuleInFile ses sourcefile io $ GHC.setContext ses [modq] [] return (Succeeded,cnotes,ses) Failed -> do -- We take care of getting at least the Prelude io(GHC.setContext ses [] =<< atomM (getPrelude ses)) return (Failed,cnotes,ses) where atomM = liftM (:[]) logMsg ref severity' srcSpan' style' msg' = do dir <- getCurrentDirectory logS ('\n':show ((mkLocMessage srcSpan' msg') style')) MVar.modifyMVar_ ref (\l -> return $ (CompileNote severity' srcSpan' style' msg' dir):l) \end{code} Here, DynFlags.logAction is being filled with a handler that writes to a MVar instead of the default handler that writes to stdout. pepe [1] - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix- compat-0.1 [2] - http://shim.haskellco.de/shim/Shim/Hsinfo.hs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070504/0a059377/attachment.htm From ahey at iee.org Fri May 4 14:28:41 2007 From: ahey at iee.org (Adrian Hey) Date: Fri May 4 14:25:56 2007 Subject: Cost of Overloading vs. HOFs Message-ID: <463B7B59.4050005@iee.org> Hello, The GHC users guide says overloading "is death to performance if left to linger in an inner loop" and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable a performance boost (compared with dictionary passing presumably). I'm not sure why that should be, but has anyone else noticed this? If so, maybe this advice should be added to the user guide, especially if your function repeatedly uses just one method from a class? (or maybe not if it's nonsense :-) I guess having done this there would be little to gain by using the SPECIALIZE pragma though (unless ghc also specialises HOFs). Regards -- Adrian Hey From conal at conal.net Fri May 4 15:23:25 2007 From: conal at conal.net (Conal Elliott) Date: Fri May 4 15:20:36 2007 Subject: recent Windows installer for ghc head? In-Reply-To: <004c01c78cf0$f34d2f30$81148351@cr3lt> References: <004c01c78cf0$f34d2f30$81148351@cr3lt> Message-ID: I untar'd the 20070404 head and added its bin/i386-unknown-cygwin32 to my PATH. When I run ghci, I get : Can't find package.conf as > c:\ghc\GHC-67~2.200\bin\I386\driver\package.conf.inplace > Suggestions? Thanks, - Conal On 5/2/07, Claus Reinke wrote: > > > Thanks for the pointer. I get failures (below) when I try to "make > > install". Does anyone have a suggestion? - Conal > > if you are talking about the good old-fashioned snapshots, there shouldn't > be any configuration or install, just untar where you need it? > > claus > > > bash-3.2$ ./configure > > checking build system type... i686-pc-cygwin > > checking host system type... i686-pc-cygwin > > checking target system type... i686-pc-cygwin > > Which we'll further canonicalise into: i386-unknown-cygwin32 > > checking for perl... /cygdrive/c/Perl/bin/perl > > checking if your perl works in shell scripts... yes > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether ln -s works... yes > > checking for sed... /usr/bin/sed > > checking for gcc... gcc > > checking for C compiler default output file name... a.exe > > checking whether the C compiler works... yes > > checking whether we are cross compiling... no > > checking for suffix of executables... .exe > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether gcc accepts -g... yes > > checking for gcc option to accept ANSI C... none needed > > checking version of gcc... 3.4.4 > > checking how to run the C preprocessor... gcc -E > > configure: creating ./config.status > > config.status: creating Makefile > > **************************************************** > > Configuration done, ready to either 'make install' > > or 'make in-place'. > > (see README and INSTALL files for more info.) > > **************************************************** > > > > bash-3.2$ make in-place > > make config-pkgs bindir=`pwd`/bin/i386-unknown-cygwin32 > > libdir=`pwd`/lib/i386-unknown-cygwin32 datadir=`pwd`/share > > make[1]: Entering directory `/cygdrive/c/ghc/ghc-6.7.20070404' > > Configuring ghc, version 6.7.20070404.20070404, on i386-unknown-cygwin32 > ... > > Creating a configured version of ghcprof .. > > /bin/sh: line 5: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 6: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 7: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 8: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 9: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 10: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 11: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > /bin/sh: line 12: bin/i386-unknown-cygwin32/ghcprof: No such file or > > directory > > chmod: cannot access `bin/i386-unknown-cygwin32/ghcprof': No such file > or > > directory > > Done. > > Creating a configured version of ghc-asm .. > > /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-asm: No such file or > > directory > > chmod: cannot access `lib/i386-unknown-cygwin32/ghc-asm': No such file > or > > directory > > Done. > > Creating a configured version of ghc-split .. > > /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-split: No such file or > > directory > > chmod: cannot access `lib/i386-unknown-cygwin32/ghc-split': No such file > or > > directory > > Done. > > Creating a configured version of package.conf .. > > Can't open lib/i386-unknown-cygwin32/package.conf: No such file or > > directory. > > make[1]: Leaving directory `/cygdrive/c/ghc/ghc-6.7.20070404' > > Finished configuring..to use, add > > /cygdrive/c/ghc/ghc-6.7.20070404/bin/i386-unknown-cygwin32 > > to your PATH. > > bash-3.2$ > > > > > > On 5/1/07, Simon Peyton-Jones wrote: > >> > >> Following the "snapshot distribution" link on GHC's download page > yields > >> this > >> > >> > >> > http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 > >> > >> > >> > >> That seems to be a tar bundle for Windows; it's not an msi but if you > >> unpack it you should be able to run it just fine. > >> > >> > >> > >> Simon > >> > >> > >> > >> *From:* glasgow-haskell-users-bounces@haskell.org [mailto: > >> glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Conal Elliott > >> *Sent:* 27 April 2007 20:03 > >> *To:* glasgow-haskell-users@haskell.org > >> *Subject:* recent Windows installer for ghc head? > >> > >> > >> > >> I'd like to try out the new & improved combination of type classes and > >> GADTs, which I understand is only in head. Is there a recent working > >> windows installer for head? > >> > >> Thanks, - Conal > >> > > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > 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/20070504/bb6e2fe4/attachment-0001.htm From ndmitchell at gmail.com Fri May 4 16:02:03 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 4 15:59:14 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <463B7B59.4050005@iee.org> References: <463B7B59.4050005@iee.org> Message-ID: <404396ef0705041302y47ac6cc7w4e06e5e1e9bd9188@mail.gmail.com> Hi Adrian > The GHC users guide says overloading "is death to performance if > left to linger in an inner loop" and one thing I noticed while > playing about with the AVL lib was that using a HOF and passing > the (overloaded) compare function as an explicit argument at the > start seemed to give noticable a performance boost (compared with > dictionary passing presumably). > > I'm not sure why that should be, but has anyone else noticed this? A HOF is one box, the Ord dictionary is an 8-box tuple containing HOF boxes. When you invoke compare out of Ord, you are taking something out of the tuple, whereas when you use the HOF its directly there. This is also the reason you get a performance decrease moving from a 1-element class to a 2-element class. Thanks Neil From duncan.coutts at worc.ox.ac.uk Fri May 4 16:19:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 4 16:29:16 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <463B7B59.4050005@iee.org> References: <463B7B59.4050005@iee.org> Message-ID: <1178309965.9770.207.camel@localhost> On Fri, 2007-05-04 at 19:28 +0100, Adrian Hey wrote: > Hello, > > The GHC users guide says overloading "is death to performance if > left to linger in an inner loop" and one thing I noticed while > playing about with the AVL lib was that using a HOF and passing > the (overloaded) compare function as an explicit argument at the > start seemed to give noticable a performance boost (compared with > dictionary passing presumably). > > I'm not sure why that should be, but has anyone else noticed this? One might hope that in this case we could hoist the extraction of the dictionary members outside the inner loop. Duncan From ahey at iee.org Fri May 4 16:53:43 2007 From: ahey at iee.org (Adrian Hey) Date: Fri May 4 16:52:49 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <404396ef0705041302y47ac6cc7w4e06e5e1e9bd9188@mail.gmail.com> References: <463B7B59.4050005@iee.org> <404396ef0705041302y47ac6cc7w4e06e5e1e9bd9188@mail.gmail.com> Message-ID: <463B9D57.3020707@iee.org> Neil Mitchell wrote: > Hi Adrian > >> The GHC users guide says overloading "is death to performance if >> left to linger in an inner loop" and one thing I noticed while >> playing about with the AVL lib was that using a HOF and passing >> the (overloaded) compare function as an explicit argument at the >> start seemed to give noticable a performance boost (compared with >> dictionary passing presumably). >> >> I'm not sure why that should be, but has anyone else noticed this? > > A HOF is one box, the Ord dictionary is an 8-box tuple containing HOF > boxes. When you invoke compare out of Ord, you are taking something > out of the tuple, whereas when you use the HOF its directly there. Well I can understand why overloading might be slow compared to a direct call (presumably this is what you get from specialisation). But I wouldn't have thought this additional indirection cost of method lookup was very significant compared with the HOF approach (at least not after everything was in cache). IOW I would have expected HOFs to just about as deathly to performance as (unspecialised) overloading, but it seems this isn't the case. > This is also the reason you get a performance decrease moving from a > 1-element class to a 2-element class. Why is that? Does ghc pass just the single method rather than a one entry dictionary in such cases? Regards -- Adrian Hey From ahey at iee.org Fri May 4 16:56:49 2007 From: ahey at iee.org (Adrian Hey) Date: Fri May 4 16:54:04 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <1178309965.9770.207.camel@localhost> References: <463B7B59.4050005@iee.org> <1178309965.9770.207.camel@localhost> Message-ID: <463B9E11.1020501@iee.org> Duncan Coutts wrote: > One might hope that in this case we could hoist the extraction of the > dictionary members outside the inner loop. This possibility had crossed my mind too. If HOFs really are faster (for whatever reason) then it should be possible for a compiler to do this automatically. Regards -- Adrian Hey From kahl at cas.mcmaster.ca Fri May 4 17:13:52 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Fri May 4 17:11:06 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <463B9E11.1020501@iee.org> (message from Adrian Hey on Fri, 04 May 2007 21:56:49 +0100) References: <463B7B59.4050005@iee.org> <1178309965.9770.207.camel@localhost> <463B9E11.1020501@iee.org> Message-ID: <20070504211352.22413.qmail@schroeder.cas.mcmaster.ca> Adrian Hey wrote: > > Duncan Coutts wrote: > > One might hope that in this case we could hoist the extraction of the > > dictionary members outside the inner loop. > > This possibility had crossed my mind too. If HOFs really are faster > (for whatever reason) then it should be possible for a compiler to > do this automatically. Once everything is in terms of dictionaries, this should even be part of ``full laziness''. Wolfram From conal at conal.net Fri May 4 18:07:41 2007 From: conal at conal.net (Conal Elliott) Date: Fri May 4 18:04:53 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <463B7B59.4050005@iee.org> References: <463B7B59.4050005@iee.org> Message-ID: Does anyone know what became of Dictionary-free Overloading by Partial Evaluation ? Is it impractical for some reason? On 5/4/07, Adrian Hey wrote: > > Hello, > > The GHC users guide says overloading "is death to performance if > left to linger in an inner loop" and one thing I noticed while > playing about with the AVL lib was that using a HOF and passing > the (overloaded) compare function as an explicit argument at the > start seemed to give noticable a performance boost (compared with > dictionary passing presumably). > > I'm not sure why that should be, but has anyone else noticed this? > > If so, maybe this advice should be added to the user guide, especially > if your function repeatedly uses just one method from a class? > > (or maybe not if it's nonsense :-) > > I guess having done this there would be little to gain by using the > SPECIALIZE pragma though (unless ghc also specialises HOFs). > > Regards > -- > Adrian Hey > _______________________________________________ > 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/20070504/9fdc71c6/attachment.htm From stefanor at cox.net Fri May 4 18:36:23 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri May 4 18:33:33 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <404396ef0705041302y47ac6cc7w4e06e5e1e9bd9188@mail.gmail.com> References: <463B7B59.4050005@iee.org> <404396ef0705041302y47ac6cc7w4e06e5e1e9bd9188@mail.gmail.com> Message-ID: <20070504223623.GA2929@localhost.localdomain> On Fri, May 04, 2007 at 09:02:03PM +0100, Neil Mitchell wrote: > Hi Adrian > > >The GHC users guide says overloading "is death to performance if > >left to linger in an inner loop" and one thing I noticed while > >playing about with the AVL lib was that using a HOF and passing > >the (overloaded) compare function as an explicit argument at the > >start seemed to give noticable a performance boost (compared with > >dictionary passing presumably). > > > >I'm not sure why that should be, but has anyone else noticed this? > > A HOF is one box, the Ord dictionary is an 8-box tuple containing HOF > boxes. When you invoke compare out of Ord, you are taking something > out of the tuple, whereas when you use the HOF its directly there. > > This is also the reason you get a performance decrease moving from a > 1-element class to a 2-element class. What ever happened to OccurAnal? Stefan From john at repetae.net Fri May 4 18:51:08 2007 From: john at repetae.net (John Meacham) Date: Fri May 4 18:48:18 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: References: <463B7B59.4050005@iee.org> Message-ID: <20070504225108.GB13654@momenergy.repetae.net> On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote: > Does anyone know what became of Dictionary-free Overloading by Partial > Evaluation ? Is it > impractical for some reason? jhc also uses a dictionary free approach, doing a case directly on the type parameter. The nice thing about this is that _all_ methods can be determined by a single case evaluation, because finding out the right instance for any method will determine the right instance for all other methods too for a given type. The standard case-of-known-value optimization takes care of later scrutinizations (method lookups) on the same type. John -- John Meacham - ?repetae.net?john? From conal at conal.net Fri May 4 20:06:10 2007 From: conal at conal.net (Conal Elliott) Date: Fri May 4 20:03:21 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <20070504225108.GB13654@momenergy.repetae.net> References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> Message-ID: Cool. You know which types to consider because jhc is a whole-program compiler? Given the whole program, why not monomorphize, and inline away all of the dictionaries? - Conal On 5/4/07, John Meacham wrote: > > On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote: > > Does anyone know what became of Dictionary-free Overloading by Partial > > Evaluation ? Is it > > impractical for some reason? > > jhc also uses a dictionary free approach, doing a case directly on the > type parameter. > > The nice thing about this is that _all_ methods can be determined by a > single case evaluation, because finding out the right instance for any > method will determine the right instance for all other methods too for a > given type. The standard case-of-known-value optimization takes care of > later scrutinizations (method lookups) on the same type. > > John > > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > 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/20070504/f9abb7a4/attachment-0001.htm From stefanor at cox.net Fri May 4 20:13:02 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri May 4 20:10:19 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> Message-ID: <20070505001302.GA3462@localhost.localdomain> On Fri, May 04, 2007 at 05:06:10PM -0700, Conal Elliott wrote: > Cool. You know which types to consider because jhc is a whole-program > compiler? > > Given the whole program, why not monomorphize, and inline away all of the > dictionaries? Because compilation might take forever - it is possible to write a program that uses a statically unbounded number of types. See Data.Sequence for a non-contrived example of this. (In fairness the issue won't appear because Data.Sequence doesn't use overloading, but in general this is a problem.) Stefan From john at repetae.net Fri May 4 20:21:33 2007 From: john at repetae.net (John Meacham) Date: Fri May 4 20:18:42 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> Message-ID: <20070505002133.GC13654@momenergy.repetae.net> On Fri, May 04, 2007 at 05:06:10PM -0700, Conal Elliott wrote: > Cool. You know which types to consider because jhc is a whole-program > compiler? Yes. though, i have since redone the back end so there is no technical reason for it to be whole program any more, you can just benefit from more optimizations that way. The old backend required global knowledge to compile at all. > Given the whole program, why not monomorphize, and inline away all of the > dictionaries? Well that is the thing, there are no dictionaries at all, the only extra arguments passed in are the types so, f :: forall a . (Foo a, Baz a, Bar a Int, Bred a) => a -> a still is only passed the single hidden argument of 'a' since a case on it will determine what method to use. (+) a x y = case a of Int -> plusInt x y Float -> plusFloat x y and so forth. a here is a type, of kind '*'. since the method lookup is done explicitly via the case statement, it can be optimized via standard transformations in nice ways. John > > - Conal > > On 5/4/07, John Meacham wrote: > > > >On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote: > >> Does anyone know what became of Dictionary-free Overloading by Partial > >> Evaluation ? Is it > >> impractical for some reason? > > > >jhc also uses a dictionary free approach, doing a case directly on the > >type parameter. > > > >The nice thing about this is that _all_ methods can be determined by a > >single case evaluation, because finding out the right instance for any > >method will determine the right instance for all other methods too for a > >given type. The standard case-of-known-value optimization takes care of > >later scrutinizations (method lookups) on the same type. > > > > John > > > > > >-- > >John Meacham - ?repetae.net?john? > >_______________________________________________ > >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 -- John Meacham - ?repetae.net?john? From haskell at brecknell.org Fri May 4 20:29:54 2007 From: haskell at brecknell.org (Matthew Brecknell) Date: Fri May 4 20:27:02 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <20070505001302.GA3462@localhost.localdomain> References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> <20070505001302.GA3462@localhost.localdomain> Message-ID: <1178324994.7549.1188196921@webmail.messagingengine.com> Stefan O'Rear: > Data.Sequence doesn't use overloading Data.Sequence uses overloading for subtree size annotations. The structural recursion seems to make it quite awkward to express size annotations without overloading. From stefanor at cox.net Fri May 4 20:37:12 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri May 4 20:34:22 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <1178324994.7549.1188196921@webmail.messagingengine.com> References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> <20070505001302.GA3462@localhost.localdomain> <1178324994.7549.1188196921@webmail.messagingengine.com> Message-ID: <20070505003712.GA3558@localhost.localdomain> On Sat, May 05, 2007 at 10:29:54AM +1000, Matthew Brecknell wrote: > Stefan O'Rear: > > Data.Sequence doesn't use overloading > > Data.Sequence uses overloading for subtree size annotations. The > structural recursion seems to make it quite awkward to express size > annotations without overloading. Ah yes, I'd forgotten about that use. I was thinking of the fact that Data.Sequence is monomorphic in the measurement type. Thanks for the correction. Stefan From skaller at users.sourceforge.net Fri May 4 20:59:37 2007 From: skaller at users.sourceforge.net (skaller) Date: Fri May 4 20:56:51 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: References: <463B7B59.4050005@iee.org> <20070504225108.GB13654@momenergy.repetae.net> Message-ID: <1178326777.16098.9.camel@rosella.wigram> On Fri, 2007-05-04 at 17:06 -0700, Conal Elliott wrote: > Cool. You know which types to consider because jhc is a whole-program > compiler? > > Given the whole program, why not monomorphize, and inline away all of > the dictionaries? That's what Felix does: typeclasses, no dictionaries: whole program analyser: resolves typeclasses, inlines whilst resolving typeclasses, monomorphises resolving typeclasses, and inlines again resolving typeclassses. Indirect dispatch can't be eliminated if the method is wrapped in a polymorphic closure. Monomorphisation alone can't eliminate second order polymorphism. [But Felix doesn't support that anyhow] -- John Skaller Felix, successor to C++: http://felix.sf.net From mads_lindstroem at yahoo.dk Sun May 6 05:33:28 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sun May 6 05:33:31 2007 Subject: GHC as a library - getting output from GHCI In-Reply-To: References: <1178294679.2509.0.camel@localhost.localdomain> <1178299156.2509.12.camel@localhost.localdomain> Message-ID: <1178444008.4271.11.camel@localhost.localdomain> Hi Pepe Pepe Iborra wrote: > Mads > > On 04/05/2007, at 19:19, Mads Lindstr?m wrote: > > > Hi Pepe > > > > > > I would have liked something cross-platform. > > > > > > > Take a look at the unix-compat[1] package by Bjorn Bringert, although > it looks like it won't help you. Maybe it can be extended. > > > Also, if stmt contains an error, wrapStmt will not be evaluated, and > > the > > > > resulting error is written to standard output or maybe to standard > > > > error. Whichever way, I am back to the same problem. > > > > > > > What else should be the behaviour in the case stmt contains an error? It could behave like most other IO actions which produce values - return them to the caller. For instance readFile :: FilePath -> IO String . runStmt could have the following type: runStmt :: Session -> String -> IO (RunResult, String) where the returned String would contain either the error or the result from evaluating the statement. > You can capture errors and stop them being written out very easily. > Take a look at this snippet (not mine, it's beschmi's code) from > Shim[2]: > Yes, that works for me. Greetings, Mads > > \begin{code} > load' :: FilePath -> Maybe String -> SHM > (SuccessFlag,[CompileNote],Session) > load' sourcefile source = do > source' <- addTime source > ses <- getSessionFor sourcefile > dflags0 <- io $ GHC.getSessionDynFlags ses > ref <- io $ MVar.newMVar [] > let dflags1 = dflags0{ log_action = logMsg ref } > io $ GHC.setSessionDynFlags ses dflags1 > io $ GHC.setTargets ses [Target (TargetFile sourcefile Nothing) > source'] > loadResult <- io $ GHC.load ses LoadAllTargets > cnotes <- io $ reverse `liftM` MVar.readMVar ref > case loadResult of > Succeeded -> do -- GHC takes care of setting the right context > modq <- io $ findModuleInFile ses sourcefile > io $ GHC.setContext ses [modq] [] > return (Succeeded,cnotes,ses) > Failed -> do -- We take care of getting at least the > Prelude > io(GHC.setContext ses [] =<< atomM (getPrelude ses)) > return (Failed,cnotes,ses) > where atomM = liftM (:[]) > logMsg ref severity' srcSpan' style' msg' = do > dir <- getCurrentDirectory > logS ('\n':show ((mkLocMessage srcSpan' msg') style')) > MVar.modifyMVar_ ref > (\l -> return $ (CompileNote severity' srcSpan' > style' msg' dir):l) > \end{code} > > > Here, DynFlags.logAction is being filled with a handler that writes to > a MVar instead of the default handler that writes to stdout. > > > pepe > > > [1] - http://hackage.haskell.org/cgi-bin/hackage > -scripts/package/unix-compat-0.1 > [2] - http://shim.haskellco.de/shim/Shim/Hsinfo.hs From ahey at iee.org Sun May 6 17:09:10 2007 From: ahey at iee.org (Adrian Hey) Date: Sun May 6 17:06:22 2007 Subject: 6.6.1 for windows Message-ID: <463E43F6.6020601@iee.org> Hello, Can we expect a 6.6.1 binary and/or installer for windows sometime? Thanks -- Adrian Hey From simonpj at microsoft.com Mon May 7 04:18:47 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon May 7 04:15:52 2007 Subject: 6.6.1 for windows In-Reply-To: <463E43F6.6020601@iee.org> References: <463E43F6.6020601@iee.org> Message-ID: | Can we expect a 6.6.1 binary and/or installer for windows sometime? Sigbjorn Finne, the guy who builds our Windows installer, is totally snowed at work at the moment. Stay tuned! Simon From simonpj at microsoft.com Mon May 7 04:28:58 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon May 7 04:26:06 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <463B7B59.4050005@iee.org> References: <463B7B59.4050005@iee.org> Message-ID: | The GHC users guide says overloading "is death to performance if | left to linger in an inner loop" and one thing I noticed while | playing about with the AVL lib was that using a HOF and passing | the (overloaded) compare function as an explicit argument at the | start seemed to give noticable a performance boost (compared with | dictionary passing presumably). GHC does try to optimise the task of selecting a method out of a dictionary. However optimisation is a delicate art, especially when you are looking at inner loops. It may well be that GHC screws up because of some apparently minor change. The thing to do is to look at the Core (-ddump-simpl) for your inner loop and see what the difference is. (Even then, it's not always straightforward to design optimisations that hit your case without harming someone else. But it's usually fun.) Simon From simonpj at microsoft.com Mon May 7 04:38:58 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon May 7 04:36:02 2007 Subject: GHC as a library - getting output from GHCI In-Reply-To: <1178294679.2509.0.camel@localhost.localdomain> References: <1178294679.2509.0.camel@localhost.localdomain> Message-ID: | I am trying to use GHC as a library (see | http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the | output from an interactive session and put in a GUI. This | http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a | nice starting point. If you want to collect *all* the output, that presumably includes the output of printing to 'stdout'? That is, if I type putStr "Hello" I see the result. If you manage to redirect stdout in this way, I think you will also see the value of your 'stmt', because what GHC does is to compile a little (print it) stmt and run it. It's a while since I looked at the Interactive loop, but I think that's right. Simon From brianh at metamilk.com Mon May 7 06:07:14 2007 From: brianh at metamilk.com (Brian Hulley) Date: Mon May 7 06:26:28 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070504003645.GA13287@heave.ugcs.caltech.edu> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <20070504003645.GA13287@heave.ugcs.caltech.edu> Message-ID: <463EFA52.7000909@metamilk.com> Brandon Michael Moore wrote: > On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: > >> I believe it is because a stack cannot be garbage collected, and must be >> traversed as roots for every garbage collection. I don't think there are >> any issues with a huge stack per se, but it does not play nice with >> garbage collection so may hurt your performance and memory usage in >> unforeseen ways. >> > > Isn't it just the top of the stack that has to be treadted as a root? > No, because the functions below the top are still active and would usually be referencing other heap locations not visible to the top function. On another note, why use stacks in the first place? Couldn't all activation records just be heap allocated? Regards, Brian. From simonmarhaskell at gmail.com Mon May 7 11:17:57 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon May 7 11:15:03 2007 Subject: Cost of Overloading vs. HOFs In-Reply-To: <1178309965.9770.207.camel@localhost> References: <463B7B59.4050005@iee.org> <1178309965.9770.207.camel@localhost> Message-ID: <463F4325.2080808@gmail.com> Duncan Coutts wrote: > On Fri, 2007-05-04 at 19:28 +0100, Adrian Hey wrote: >> Hello, >> >> The GHC users guide says overloading "is death to performance if >> left to linger in an inner loop" and one thing I noticed while >> playing about with the AVL lib was that using a HOF and passing >> the (overloaded) compare function as an explicit argument at the >> start seemed to give noticable a performance boost (compared with >> dictionary passing presumably). >> >> I'm not sure why that should be, but has anyone else noticed this? > > One might hope that in this case we could hoist the extraction of the > dictionary members outside the inner loop. In theory at least, case liberation (on with -O2) does this sort of thing. (BTW Simon: it looks like -fliberate-case-threshold was replaced by -fspec-threshold, but the change wasn't propagated to the docs). Cheers, Simon From ndmitchell at gmail.com Mon May 7 11:34:10 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 7 11:31:13 2007 Subject: GHC 6.6.1 Windows installer, test version Message-ID: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> Hi, I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as an official installer, could people please test it? http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe The new features of this installer (relative to the 6.6 one) are: * Prettier .hs icons * Automatically adds GHC and Cabal binaries to the %PATH% * 10Mb smaller (better compression) Thanks to Duncan for answering installer related questions. Neil From brianh at metamilk.com Mon May 7 13:18:19 2007 From: brianh at metamilk.com (Brian Hulley) Date: Mon May 7 13:14:56 2007 Subject: GHC 6.6.1 Windows installer, test version In-Reply-To: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> References: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> Message-ID: <463F5F5B.8000607@metamilk.com> Neil Mitchell wrote: > Hi, > > I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as > an official installer, could people please test it? > > http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe Thanks Neil, This works perfectly! Best regards, Brian. From ahey at iee.org Mon May 7 13:24:40 2007 From: ahey at iee.org (Adrian Hey) Date: Mon May 7 13:21:50 2007 Subject: GHC 6.6.1 Windows installer, test version In-Reply-To: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> References: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> Message-ID: <463F60D8.6050008@iee.org> Neil Mitchell wrote: > Hi, > > I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as > an official installer, could people please test it? > > http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe > Thanks for that. It seems to install and compile the collections package OK so I guess it's working. Regards -- Adrian Hey From shelarcy at gmail.com Mon May 7 22:45:52 2007 From: shelarcy at gmail.com (shelarcy) Date: Mon May 7 22:43:13 2007 Subject: GHC 6.6.1 Windows installer, test version In-Reply-To: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> References: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> Message-ID: Hi Neil, On Tue, 08 May 2007 00:34:10 +0900, Neil Mitchell wrote: > I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as > an official installer, could people please test it? > > http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. This is well-known problem, if build GHC your self. Because MInGW doesn't have these headers and library files in its directory. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-October/011253.html http://www.haskell.org/pipermail/haskell/2006-December/018919.html So you must copy these files from old GHC's directory first, and then building new GHC. > The new features of this installer (relative to the 6.6 one) are: > > * Prettier .hs icons > * Automatically adds GHC and Cabal binaries to the %PATH% > * 10Mb smaller (better compression) > > Thanks to Duncan for answering installer related questions. And can you add Installation Mode to your installer? There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. http://hackage.haskell.org/trac/ghc/ticket/1024 http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/thread.html#12408 On the other hand, if anyone want to install sommaller GHC, he doesn't want to install unnecessary things. And we can point out that for other things. For example, we want to include extra libraries or not, we want to include OpenAL and ALUT or not (these package can buid only when building GHC now. because OpenAL and ALUT libraries are built by ccall convention, but these package use stdcall convention on Windows now. And -fvia-C convert stdcall to ccall). http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/011112.html http://www.haskell.org/pipermail/hopengl/2007-March/000715.html http://hackage.haskell.org/trac/ghc/ticket/1140 http://hackage.haskell.org/trac/ghc/ticket/1243 So I think we will become happy, if adding Installation Mode and maintain that on GHC's darcs repository. Best Regards, -- shelarcy http://page.freett.com/shelarcy/ From john at repetae.net Mon May 7 23:26:40 2007 From: john at repetae.net (John Meacham) Date: Mon May 7 23:23:41 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <461C96C1.40408@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> Message-ID: <20070508032640.GE13654@momenergy.repetae.net> On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: > I definitely think that -1# should be parsed as a single lexeme. > Presumably it was easier at the time to do it the way it is, I don't > remember exactly. > > I'd support a warning for use of prefix negation, or alternatively you > could implement the Haskell' proposal to remove prefix negation completely > - treat the unary minus as part of a numeric literal in the lexer only. > This would have to be optional for now, so that we can continue to support > Haskell 98 of course. yes please! odd that I look forward to such a minor change in the big scheme of things, but the current treatment of negation has annoyed me more than any other misfeature I think. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue May 8 00:34:31 2007 From: john at repetae.net (John Meacham) Date: Tue May 8 00:31:35 2007 Subject: {-# INLINE me_harder #-} In-Reply-To: <46260A11.4010103@charter.net> References: <1176880918.25192.47.camel@localhost> <46260A11.4010103@charter.net> Message-ID: <20070508043431.GF13654@momenergy.repetae.net> On Wed, Apr 18, 2007 at 08:07:45AM -0400, Isaac Dupree wrote: > Jhc has a pragma named "SUPERINLINE" that just means "try even harder to > inline this", I think, e.g. it has > {-# SUPERINLINE id, const, (.), ($), ($!), flip #-} > > It just reminded me of the name -- I'm not sure whether it actually > makes sense to use that same name for this purpose. Actually, SUPERINLINE basically means 'treat this as if it were a term-rewriting macro', so, it really always does inline no matter what, fairly early in the compilation process. Even if the call is unsaturated and it will end up being let-floated out anyway. I originally added it so some early flow-insensitive optimizations wouldn't end up doing silly things like unifying all uses of 'id' program-wide. The compiler is smarter now, so it is less needed, but it still exists. John -- John Meacham - ?repetae.net?john? From simonmarhaskell at gmail.com Tue May 8 03:43:29 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 8 03:40:31 2007 Subject: Why do we have stack overflows? In-Reply-To: <20070504012119.GA3568@localhost.localdomain> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <20070504003645.GA13287@heave.ugcs.caltech.edu> <20070504012119.GA3568@localhost.localdomain> Message-ID: <46402A21.5080204@gmail.com> Stefan O'Rear wrote: > On Thu, May 03, 2007 at 05:36:45PM -0700, Brandon Michael Moore wrote: >> On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: >>> I believe it is because a stack cannot be garbage collected, and must be >>> traversed as roots for every garbage collection. I don't think there are >>> any issues with a huge stack per se, but it does not play nice with >>> garbage collection so may hurt your performance and memory usage in >>> unforeseen ways. >> Isn't it just the top of the stack that has to be treadted as a root? >> (maybe you need to walk the stack to find exception handlers and so on.) >> Maybe it shouldn't be so much worse than a heap. The Chicken Scheme >> system allocates everything on the C stack, and runs some sort of >> compacting collector when it is about to fill. > > GHC uses a simple exponential-backoff algorithm for handling stacks. > When the stack pointer passes the stack limit, the thread yields to > the scheduler, where the stack size is doubled, and the old stack is > moved. Perhaps instead we could modify the algorithm such that up to > 16K stack size the behaivor is the same, but use linked lists for > larger? > > 1. Allocate a new chunk, of size 16KB. > > 2. Copy the topmost 1KB of stack to the new block. This decreases > storage efficiency slightly (but not much in time - memcpy is > several times faster than anything the current ghc code generator > can generate), but it avoids a nasty corner case (stack size > fluctuating across 0 mod 16K) by acting as a form of hysteresis. > > 3. Create a special frame at the bottom of the new stack chunk that > returns into a stack underflow handler, thus avoiding the need for > yet another conditional. GHC in the distant past (pre-4.0) had linked stack chunks, but we discarded the idea when the RTS was rewritten, mainly for simplicity. It was before my time, so I don't know all the war stories, but I think it turned out to be hairy enough to avoid it in the redesign. At least it would require separate TSO and STACK objects, the underflow frame, code to avoid performance degradation at the boundary (e.g. as you say, copy the top 1k of stack to the new chunk), stack walking gets more complicated (several places in the RTS do this). My impression is that the performance of stack growth isn't usually a limiting factor, so I'm not sure it's worth adding this complexity. Benchmarks can be convincing, though... Cheers, Simon From simonmarhaskell at gmail.com Tue May 8 03:48:47 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 8 03:45:48 2007 Subject: Why do we have stack overflows? In-Reply-To: <463B3100.2010602@iee.org> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <463B3100.2010602@iee.org> Message-ID: <46402B5F.8030307@gmail.com> Adrian Hey wrote: > John Meacham wrote: >> I believe it is because a stack cannot be garbage collected, and must be >> traversed as roots for every garbage collection. I don't think there are >> any issues with a huge stack per se, but it does not play nice with >> garbage collection so may hurt your performance and memory usage in >> unforeseen ways. > > I'm still not convinced :-( > > I also don't believe it's in anybodys interest to have programs > failing for no good reason. A good reason to fail is if overall > memory demands are getting stupid. Failing because the stack has > grown beyond some arbitrary (and typically small) size seems > bad to me. > > I know that this is to a certain extent this is controllable > using RTS options, but this is no use to me as a library > writer tying to chose between stackGobbler and heapGobbler. > > The stuff should "just work" and not be dependent on the right > RTS incantations being used when the final program is run. I'm more than happy to change the defaults, if there's some agreement on what the defaults should be. The current choice is somewhat historical - we used to have a bound on both heap size and stack size, but the heap size bound was removed because we felt that on balance it made life easier for more people, at the expense of a bit more pain when you write a leaky program. Also, it used to be the case that the OOM killer could be a bit unpredictable, killing vital system processes instead of the leaky Haskell program. I'm not sure if this is still true for current OS incarnations. Cheers, Simon From ndmitchell at gmail.com Tue May 8 06:04:33 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 8 06:01:31 2007 Subject: GHC 6.6.1 Windows installer, test version In-Reply-To: References: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> Message-ID: <404396ef0705080304g75ed2484p35fbe4218997d067@mail.gmail.com> Hi > You forgot to include GLUT and readline packages. > I think you can't build these packages, so you don't include it. I have built an installer for the binary package produced by the GHC Team, including whatever they included, and excluding whatever they excluded. If the GHC Team change their build so these are built, I will happily include whatever they tell me. > And can you add Installation Mode to your installer? There is already a silent install mode, /SILENT or /VERYSILENT do something - but I have no idea what. Is that what you meant by Installation Mode? > There is no C++ files in your installer. > But if anyone want to build C++ source code by GHC, he disappoint > about that. As before, what goes in the package is someone elses choice. This installer is intended as something quick to get a working installer out the door. I'd like to think about beefing it up, offering extra options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) > So I think we will become happy, if adding Installation Mode and > maintain that on GHC's darcs repository. I'm still not entirely sure what you mean by this? Thanks Neil From ahey at iee.org Tue May 8 06:54:56 2007 From: ahey at iee.org (Adrian Hey) Date: Tue May 8 06:52:03 2007 Subject: Why do we have stack overflows? In-Reply-To: <46402B5F.8030307@gmail.com> References: <4639FEAA.2030902@iee.org> <1178206768.9770.113.camel@localhost> <463A1078.7090608@iee.org> <20070503235958.GA18281@momenergy.repetae.net> <463B3100.2010602@iee.org> <46402B5F.8030307@gmail.com> Message-ID: <46405700.70604@iee.org> Simon Marlow wrote: > I'm more than happy to change the defaults, if there's some agreement on > what the defaults should be. The current choice is somewhat historical > - we used to have a bound on both heap size and stack size, but the heap > size bound was removed because we felt that on balance it made life > easier for more people, at the expense of a bit more pain when you write > a leaky program. Well in the light of what Stefan says about exponentially increasing stack size I'm not sure increasing (or removing) the default is the answer. Going from 16M to 32M to 64M stacks is bit drastic. It seems to me going up in sane sized linear increments would be better. But since we also want to avoid frequent copying of an already oversized stack I guess some linked list representation is what's needed. In fact I'd think what Stefan suggests or something very similar would be the way to go. But I have no idea how much work that would be. But to give programs best possible chance of running successfully then I think an (optional) overall limit on total memory use would be preferable (better than trying to guess how much stack space will be needed in advance). Regards -- Adrian Hey From shelarcy at gmail.com Tue May 8 08:36:30 2007 From: shelarcy at gmail.com (shelarcy) Date: Tue May 8 08:33:51 2007 Subject: GHC 6.6.1 Windows installer, test version In-Reply-To: <404396ef0705080304g75ed2484p35fbe4218997d067@mail.gmail.com> References: <404396ef0705070834s481ce141taef9def396238e8@mail.gmail.com> <404396ef0705080304g75ed2484p35fbe4218997d067@mail.gmail.com> Message-ID: On Tue, 08 May 2007 19:04:33 +0900, Neil Mitchell wrote: >> You forgot to include GLUT and readline packages. >> I think you can't build these packages, so you don't include it. > > I have built an installer for the binary package produced by the GHC > Team, including whatever they included, and excluding whatever they > excluded. If the GHC Team change their build so these are built, I > will happily include whatever they tell me. It's wrong about buildable packages and C++ files. First, "make binary-dist" includes these packages in binary distribution if you can build theirs. GHC 6.4 and GHC 6.6.1 or above installers include theirs. And if you can build OpenAL and ALUT, you can include these packages to your installer. Second, I can include C++ files (except header files) in binary by "make binary-dist" command with MinGW-4.1.1. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012410.html http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012413.html So I want to know "What version of MinGW do you use?" and "Is your MinGW has C++ files?" If you don't find C++ files in your MinGW directory, I think you probably choice not to install C++/g++ things. So if you find your MinGW doesn't include C++ files, you must install these files first. And then you try to use "make binary-dist" command and make installer again. >> There is no C++ files in your installer. >> But if anyone want to build C++ source code by GHC, he disappoint >> about that. > > As before, what goes in the package is someone elses choice. This > installer is intended as something quick to get a working installer > out the door. I'd like to think about beefing it up, offering extra > options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) So above tasks will be complete just checking and correcting your build enviornment. An lack is C++ header files, but you can fix this problem by changing to comment out or remove dist/prep-bin-dist-mingw's below line. rm -rf include/mingw/c++/ || echo "c++/ not there" I think these tasks are easy, and they don't become bottleneck to release installer. >> And can you add Installation Mode to your installer? > > There is already a silent install mode, /SILENT or /VERYSILENT do > something - but I have no idea what. Is that what you meant by > Installation Mode? GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. I want to say that. But that is difficult task, so I wait that for the next version. Best Regards, -- shelarcy http://page.freett.com/shelarcy/ From maeder at tzi.de Tue May 8 09:19:05 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue May 8 09:16:10 2007 Subject: problems using ghc-6.6.1 Message-ID: <464078C9.2080100@tzi.de> Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The cre