From stefan at cs.uu.nl Thu Mar 1 00:54:56 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Mar 1 00:48:21 2007 Subject: Linker error when building GHC HEAD on Mac OS Message-ID: I'm trying to build GHC HEAD on Mac OS 10.4.8 (PowerPC), but end up with a linker error: ../compiler/stage1/ghc-inplace -o stage2/ghc-6.7.20070228 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing - I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DDEBUGGER - threaded -fforce-recomp stage2/main/Main.o /usr/bin/ld: warning multiple definitions of symbol _UP /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _UP /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_termcap.o) definition of _UP /usr/bin/ld: warning multiple definitions of symbol _BC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _BC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_termcap.o) definition of _BC /usr/bin/ld: warning multiple definitions of symbol _PC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _PC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_tputs.o) definition of _PC /usr/bin/ld: Undefined symbols: _stg_interp_constr1_entry _stg_interp_constr2_entry _stg_interp_constr3_entry _stg_interp_constr4_entry _stg_interp_constr5_entry _stg_interp_constr6_entry _stg_interp_constr7_entry _stg_interp_constr8_entry collect2: ld returned 1 exit status <> make[3]: *** [stage2/ghc-6.7.20070228] Error 1 make[2]: *** [stage2/ghc-6.7.20070228] Error 2 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Anyone any pointers? Cheers, Stefan From dons at cse.unsw.edu.au Thu Mar 1 01:58:37 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu Mar 1 01:52:01 2007 Subject: ghc -fasm declared not too shabby Message-ID: <20070301065837.GB17324@cse.unsw.EDU.AU> Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on amd64: http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! There's some wider variation on the microbenchmarks in the imaginary class: one case 20% faster, another 30% slower, average 2% slower. On real programs though, 3% slower on average. The big benefit of course, no perl, no gcc and faster compilation times. -- Don From duncan.coutts at worc.ox.ac.uk Thu Mar 1 05:02:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 1 04:56:12 2007 Subject: How to debug a segfault. In-Reply-To: <45E5BC97.9090502@davidb.org> References: <45E4D575.8030606@davidb.org> <45E55CE3.9030700@gmail.com> <45E5A95C.4050105@davidb.org> <45E5B3DE.3040601@davidb.org> <45E5BC97.9090502@davidb.org> Message-ID: <1172743377.1018.425.camel@localhost> On Wed, 2007-02-28 at 09:32 -0800, David Brown wrote: > However, what I missed is that the hsc2hs target files are placed > alongside the source, not in the dist directory. I had been building > zlib on x86 using the hs generated on an amd64 machine. The offsets > in the structures were wrong. Ohh, nasty. > How difficult would it be to have Cabal store the target files in the > 'dist' directory with everything else? This also makes revision > control a little more challenging, because I have to hand-pick a few > select .hs files to ignore, since the rest of my code is sitting right > next to them. That would be good. I don't suppose it's too hard, after all we put other generated modules in dist (the paths module). We then just have to add more -i search dirs. I'd be happy to review cabal patches along these lines. [ On the plus side, I'm glad it wasn't a bug in my zlib binding :-) ] Duncan From simonmarhaskell at gmail.com Thu Mar 1 05:45:49 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 1 05:39:14 2007 Subject: ghc -fasm declared not too shabby In-Reply-To: <20070301065837.GB17324@cse.unsw.EDU.AU> References: <20070301065837.GB17324@cse.unsw.EDU.AU> Message-ID: <45E6AEDD.4060506@gmail.com> Donald Bruce Stewart wrote: > Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on > amd64: > > http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html > > Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! > There's some wider variation on the microbenchmarks in the imaginary > class: > > one case 20% faster, another 30% slower, average 2% slower. nsieve is interesting... I'm looking into it now. Also the HEAD seems slower on that program. > On real programs though, 3% slower on average. > The big benefit of course, no perl, no gcc and faster compilation times. I'd thought that -fasm was a slight improvement over -fvia-C on x86_64, so this is a surprise to me. I know it's slower on x86, mainly due to the poor code generationg for floating point on x86. You might consider discounting the programs that run for less than 0.1 seconds from the average, that's what nofib-analyse does. BTW, what happened to imaginary/rfib? I find that a useful floating point microbenchmark. Cheers, Simon From dons at cse.unsw.edu.au Thu Mar 1 05:59:26 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu Mar 1 05:52:55 2007 Subject: ghc -fasm declared not too shabby In-Reply-To: <45E6AEDD.4060506@gmail.com> References: <20070301065837.GB17324@cse.unsw.EDU.AU> <45E6AEDD.4060506@gmail.com> Message-ID: <20070301105926.GA21171@cse.unsw.EDU.AU> simonmarhaskell: > Donald Bruce Stewart wrote: > >Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on > >amd64: > > > > http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html > > > >Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! > >There's some wider variation on the microbenchmarks in the imaginary > >class: > > > > one case 20% faster, another 30% slower, average 2% slower. > > nsieve is interesting... I'm looking into it now. Also the HEAD seems > slower on that program. > > >On real programs though, 3% slower on average. > >The big benefit of course, no perl, no gcc and faster compilation times. > > I'd thought that -fasm was a slight improvement over -fvia-C on x86_64, so > this is a surprise to me. I know it's slower on x86, mainly due to the > poor code generationg for floating point on x86. > Initial x86 numbers now up, note the (known) floating point issues: http://www.cse.unsw.edu.au/~dons/nobench/i686/results.html > You might consider discounting the programs that run for less than 0.1 > seconds from the average, that's what nofib-analyse does. Good idea. Will do. I'll see if I can increase the runtime on a few others. > > BTW, what happened to imaginary/rfib? I find that a useful floating point > microbenchmark. Ah right. It was subsumed with the 'recursive' benchmark, but it might be useful to have back since its smaller. I'll add it. -- Don From simonmarhaskell at gmail.com Thu Mar 1 10:06:22 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 1 09:59:46 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: References: Message-ID: <45E6EBEE.8060204@gmail.com> Ok, what happens here is that in the forked process there is only a single thread, the runtime kills all the other threads (as advertised). Unfortunately this includes the I/O manager thread, so as soon as you do some I/O in the forked process, you block. It might be possible to fix this, but not easily I'm afraid, because the I/O manager doesn't currently have a way to restart after it's been killed. We could implement that, though. I'll create a bug report. On a more general note, forkProcess is known to be hairy - simply the fact that it kills all the other threads in the system in the forked process means that there's a good supply of means to shoot yourself in the foot, even accidentally. John - perhaps there's another way to achieve what you want? Cheers, Simon Jeremy Shaw wrote: > Hello, > > Here is a simplified example that seems to exhibit the same behaviour, > unless I screwed up: > > ---> > > module Main where > > import System.Posix > import System.IO > import System.Exit > > main = > do putStrLn "running..." > (stdinr, stdinw) <- createPipe > (stdoutr, stdoutw) <- createPipe > pid <- forkProcess $ do hw <- fdToHandle stdoutw > hr <- fdToHandle stdinr > closeFd stdinw > hGetContents hr >>= hPutStr hw > hClose hr > hClose hw > exitImmediately ExitSuccess > closeFd stdoutw > closeFd stdinw > hr2 <- fdToHandle stdoutr > hGetContents hr2 >>= putStr > getProcessStatus True False pid >>= print > > <--- > > Compiling with: > > ghc --make -no-recomp test3.hs -o test3 && ./test3 > > works. But compiling with: > > ghc --make -no-recomp -threaded test3.hs -o test3 && ./test3 > > results in a hang. If you comment out the "hGetContents hr >>=" and > change 'hPutStr hw' to 'hPutStr hw "hi"', then it seems to work ok. > > As you suggested, it seems that hGetContents is not ever seeing the > EOF when -threaded is enabled. I think it gets 'Resource temporarily > unavailable' instead. So, it keeps retrying. > > Assuming I have recreated the same bug, we at least have a simpiler > test case now... > > j. > > At Wed, 28 Feb 2007 11:15:04 -0600, > John Goerzen wrote: >> Hi, >> >> I've been hitting my head against a wall for the past couple of days >> trying to figure out why my shell-like pipeline code kept hanging. I >> found fd leakage (file descriptors not being closed), which disrupts EOF >> detection and can lead to deadlocks. I just couldn't find the problem. >> >> I finally tried compiling my test with ghc instead of running it in >> ghci. >> >> And poof, it worked fine the first time. >> >> I tried asking on #haskell, and got the suggestion that ghci uses >> -threaded. I tried compiling my test program with ghc -threaded, and >> again, same deadlock. My program never calls forkIO or forkOS or any >> other threading code. >> >> You can see my test case with: >> >> darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh >> ghc -fglasgow-exts --make -o test2 test2.hs >> >> That'll run fine. If you add -threaded, it will hang. >> >> Ideas? >> >> Thanks, >> >> -- 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 > From jgoerzen at complete.org Thu Mar 1 10:49:50 2007 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 1 10:43:19 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45E6EBEE.8060204@gmail.com> References: <45E6EBEE.8060204@gmail.com> Message-ID: <20070301154950.GB8010@excelhustler.com> On Thu, Mar 01, 2007 at 03:06:22PM +0000, Simon Marlow wrote: > Ok, what happens here is that in the forked process there is only a single > thread, the runtime kills all the other threads (as advertised). > Unfortunately this includes the I/O manager thread, so as soon as you do > some I/O in the forked process, you block. Could it just revert to the nonthreaded IO model, or is that not within the scope of what's easily achievable with the threaded RTS? > On a more general note, forkProcess is known to be hairy - simply the fact > that it kills all the other threads in the system in the forked process > means that there's a good supply of means to shoot yourself in the foot, > even accidentally. John - perhaps there's another way to achieve what you > want? Right. Part of this problem may be one of documentation, and part of it rests with ghci. I have no need for threads in this program. And, in fact, as you said, threads are known to be hazardous when used in conjuntion with fork(). I have no interest in combining the to. The mechanics of signal propogation, file descriptor closing, etc. all get complicated. But it seems like there is not much choice with ghci. It appears to be built with the threaded RTS by default, and uses threads even though I never try to use threads with it. And there seems to be no way to turn it off. Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. Also, why does hGetContents not work, but hPutStr does? If the IO manager is dead, how does some IO still work? -- John From simonmarhaskell at gmail.com Thu Mar 1 11:21:45 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Mar 1 11:15:09 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070301154950.GB8010@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> Message-ID: <45E6FD99.1090802@gmail.com> John Goerzen wrote: > On Thu, Mar 01, 2007 at 03:06:22PM +0000, Simon Marlow wrote: >> Ok, what happens here is that in the forked process there is only a single >> thread, the runtime kills all the other threads (as advertised). >> Unfortunately this includes the I/O manager thread, so as soon as you do >> some I/O in the forked process, you block. > > Could it just revert to the nonthreaded IO model, or is that not within > the scope of what's easily achievable with the threaded RTS? The non-threaded I/O system just isn't compiled into the threaded RTS at all. We used to use it in the threaded RTS before we switched to the I/O manager thread, but as I recall it was a rich source of bugs; the I/O manager thread is much simpler, being in Haskell. >> On a more general note, forkProcess is known to be hairy - simply the fact >> that it kills all the other threads in the system in the forked process >> means that there's a good supply of means to shoot yourself in the foot, >> even accidentally. John - perhaps there's another way to achieve what you >> want? > > Right. Part of this problem may be one of documentation, and part of it > rests with ghci. > > I have no need for threads in this program. And, in fact, as you said, > threads are known to be hazardous when used in conjuntion with fork(). > I have no interest in combining the to. The mechanics of signal > propogation, file descriptor closing, etc. all get complicated. > > But it seems like there is not much choice with ghci. It appears to be > built with the threaded RTS by default, and uses threads even though I > never try to use threads with it. And there seems to be no way to turn > it off. The problem is that the choice between -threaded and non-threaded is made at link-time, so we have to make that choice when we link the GHCi binary. In fact you should think of the non-threaded RTS as deprecated. It isn't Haskell'-compliant, for one thing (assuming that Haskell' will probably require non-blocking foreign calls). I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS is so much more complicated, it might have some adverse performance impliciations, and there are still people who want to run everything in a single OS thread, for whatever reason. But having multiple variants of the RTS is a maintenance and testing headache. > Between that and the lack of support for forkProcess in Hugs, this > renders anything that needs to fork and then do I/O as being usable only > in GHC-compiled code. Which is sub-optimal, but livable anyway. I guess I'm really wondering why you need to fork and do I/O at all. Can you describe the problem at a higher level? > Also, why does hGetContents not work, but hPutStr does? If the IO > manager is dead, how does some IO still work? Ah well, only I/O that needs to block uses the I/O manager thread. I/O that doesn't block just proceeds directly. Cheers, Simon From dkirkman at gmail.com Thu Mar 1 12:01:15 2007 From: dkirkman at gmail.com (David Kirkman) Date: Thu Mar 1 11:54:36 2007 Subject: Linker error when building GHC HEAD on Mac OS In-Reply-To: References: Message-ID: <9bcda0300703010901v872af27n324011192cf51afc@mail.gmail.com> It looks like you're running into the problem of apple's readline not actually being readline at all (it's a link to some other library that is almost, but not quite, readline). See http://cvs.haskell.org/trac/ghc/wiki/Building/MacOSX for instructions on how to install readline and how to tell ghc where it is. I've successfully built HEAD (Feb 25) on ppc OS 10.4.8, so I know it will work. But I also remember it took me a half dozen tries to get it to build the first time (mostly related to this readline business!) -david k. On 2/28/07, Stefan Holdermans wrote: > I'm trying to build GHC HEAD on Mac OS 10.4.8 (PowerPC), but end up > with a linker error: > > ../compiler/stage1/ghc-inplace -o stage2/ghc-6.7.20070228 -H16m -O > -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing - > I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DDEBUGGER - > threaded -fforce-recomp stage2/main/Main.o > /usr/bin/ld: warning multiple definitions of symbol _UP > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib > (terminal.so) definition of _UP > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_termcap.o) definition of _UP > /usr/bin/ld: warning multiple definitions of symbol _BC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib > (terminal.so) definition of _BC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_termcap.o) definition of _BC > /usr/bin/ld: warning multiple definitions of symbol _PC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib > (terminal.so) definition of _PC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_tputs.o) definition of _PC > /usr/bin/ld: Undefined symbols: > _stg_interp_constr1_entry > _stg_interp_constr2_entry > _stg_interp_constr3_entry > _stg_interp_constr4_entry > _stg_interp_constr5_entry > _stg_interp_constr6_entry > _stg_interp_constr7_entry > _stg_interp_constr8_entry > collect2: ld returned 1 exit status > < residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.10 MUT > (4.20 elapsed), 0.05 GC (0.08 elapsed) :ghc>> > make[3]: *** [stage2/ghc-6.7.20070228] Error 1 > make[2]: *** [stage2/ghc-6.7.20070228] Error 2 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > Anyone any pointers? > > Cheers, > > Stefan > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From jgoerzen at complete.org Thu Mar 1 12:38:54 2007 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 1 12:32:19 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45E6FD99.1090802@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> Message-ID: <20070301173854.GA12270@excelhustler.com> On Thu, Mar 01, 2007 at 04:21:45PM +0000, Simon Marlow wrote: > >Between that and the lack of support for forkProcess in Hugs, this > >renders anything that needs to fork and then do I/O as being usable only > >in GHC-compiled code. Which is sub-optimal, but livable anyway. > > I guess I'm really wondering why you need to fork and do I/O at all. Can > you describe the problem at a higher level? I am, for all intents and purposes, writing what amounts to a simple shell. The standard way of implemeting pipes between two external programs in Unix involves setting up pipes and forking, then duping things to stdin/stdout, and execing the final program. In this case, I am setting it up to let people pipe to Haskell functions as well, forking off a process that works with pipes to handle them. I know how all these things work in Unix, in C, in Python, etc. I have no idea how all of this will interact if I were to use forkOS. It is not clear to me what the semantics of forkProcess, executeFile, signal handling, etc. are under a Haskell thread instead of a forked process. This is, as far as I can tell, completely undocumented in System.Posix.* and the subject of differing advice on the WWW. But let me add a voice to keeping the non-threaded RTS around. I have learned the hard way that the threaded RTS is ported only to a very few platforms, a distinct minority of the platforms that Debian supports, for instance. (Just like ghci). Whereas the non-threaded RTS is supported much more broadly (such as Alpha support). My own program hpodder has failed to build in Debian on many platforms because I didn't realize this going in. Not only that, but it is apparent that the threaded RTS is simply inappropriate when a person is trying to do anything remotely low-level on the system. I would hate to have to become a Haskell refugee, going back to Python, because Haskell I/O has become incompatible with fork(). I do not find a language to be useful, in general, unless it lets me fork and exec when I have to. -- John From jeremy.shaw at linspireinc.com Thu Mar 1 14:04:09 2007 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Thu Mar 1 13:57:32 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070301173854.GA12270@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> Message-ID: At Thu, 1 Mar 2007 11:38:54 -0600, John Goerzen wrote: > > On Thu, Mar 01, 2007 at 04:21:45PM +0000, Simon Marlow wrote: > > >Between that and the lack of support for forkProcess in Hugs, this > > >renders anything that needs to fork and then do I/O as being usable only > > >in GHC-compiled code. Which is sub-optimal, but livable anyway. > > > > I guess I'm really wondering why you need to fork and do I/O at all. Can > > you describe the problem at a higher level? > > I am, for all intents and purposes, writing what amounts to a simple > shell. The neat thing about the library is that external commands and haskell code can be freely intermixed, and are uniformly handled. For example, in this pipeline, r <- runS ("ls -l" -|- "grep i" -|- wcL ) wcL is a simple haskell function: wcL :: [String] -> [String] wcL inp = [show $ genericLength inp] The HSH library just creates some pipes to hook the processes together, and then forks of ls, grep, and wcL as seperate processes. The advantage of this scheme is that once the pipeline is started, everything behaves the same way it would if you had run the bash command: $ ls -l | grep i | wcL So, you get very familiar behaviour/performance from a shell scripting point of view. But, you also get to easily stick haskell functions in your pipeline. Poking around with the full HSH code, I *think* I got pipelines that *only* called external commands working fine[1]. This seems logical, since the external commands do not care about the Haskell I/O manager at all. So, perhaps you can have an alternate version of 'instance ShellCommand (String -> IO String)' that gets used for -threaded that uses forkOS instead of forkProcess. All of the external commands would still be forked into seperate processes, but all of the haskell commands would run in the same threaded process. Obviously, you would have to fake the return code, but it looks like that should be feasible. Some open questions are: a) how do you detect that you are running in the threaded RTS b) can you have the linker pick the correct version at link time, so that you do not have to have a compile-time check. Of course, a compile time check might only have to be done once, so the overhead would not be significant. j. [1] In fact, they may work fine out of the box, I haven't tested that. From duncan.coutts at worc.ox.ac.uk Thu Mar 1 17:51:59 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 1 17:45:15 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> Message-ID: <1172789519.1018.464.camel@localhost> On Thu, 2007-03-01 at 11:04 -0800, Jeremy Shaw wrote: > Some open questions are: > > a) how do you detect that you are running in the threaded RTS Currently the nearest approximation is: Control.Concurrent.rtsSupportsBoundThreads :: Bool Duncan From simonmarhaskell at gmail.com Fri Mar 2 05:07:07 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Mar 2 05:00:30 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070301173854.GA12270@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> Message-ID: <45E7F74B.8070707@gmail.com> John Goerzen wrote: > The standard way of implemeting pipes between two external programs in > Unix involves setting up pipes and forking, then duping things to > stdin/stdout, and execing the final program. In this case, I am setting > it up to let people pipe to Haskell functions as well, forking off a > process that works with pipes to handle them. > > I know how all these things work in Unix, in C, in Python, etc. > > I have no idea how all of this will interact if I were to use forkOS. > It is not clear to me what the semantics of forkProcess, executeFile, > signal handling, etc. are under a Haskell thread instead of a forked > process. This is, as far as I can tell, completely undocumented in > System.Posix.* and the subject of differing advice on the WWW. We can certainly add any missing documentation - can you suggest specifically waht you'd like to see mentioned? forkProcess does say what happens when there are multiple threads, and I've added some more notes about I/O with -threaded. executeFile isn't affected by threads. Signal handling unfortunately won't work in the child of forkProcess, with -threaded, right now for the same reason that I/O doesn't work. > But let me add a voice to keeping the non-threaded RTS around. I have > learned the hard way that the threaded RTS is ported only to a very few > platforms, a distinct minority of the platforms that Debian supports, > for instance. (Just like ghci). Whereas the non-threaded RTS is > supported much more broadly (such as Alpha support). My own program > hpodder has failed to build in Debian on many platforms because I didn't > realize this going in. > > Not only that, but it is apparent that the threaded RTS is simply > inappropriate when a person is trying to do anything remotely low-level > on the system. I would hate to have to become a Haskell refugee, going > back to Python, because Haskell I/O has become incompatible with fork(). > > I do not find a language to be useful, in general, unless it lets me > fork and exec when I have to. I share your concerns, and doing low-level system programming of this kind is certainly something we want to support. I'd also consider it a serious problem if we were to lose the ability to write a shell in Haskell. (I should point out that it's not usualy fork+exec that causes problems, rather fork on its own - fork+exec is pretty well supported, we use it in the timeout program in the GHC testsuite for example). Many people really need the facilities that the threaded RTS provides (non-blocking foreign calls, SMP parallelism, writing thread-safe DLLs, etc.). So we have to provide these facilities without losing support for system programming. I accept we may have tipped the balance a little recently in favour of the funky new stuff; apologies for that, and thanks for bringing it up. We won't be throwing away the non-threaded RTS any time soon, certainly not while there are certain programs and platforms that only work with it. Regarding platform support for the threaded RTS: that's certainly a problem, which is mainly due to lack of resources. I'm sure most bugs are probably fairly shallow, since we only use Posix thread support. Regarding your shell: I would suggest trying forkIO for the Haskell "processes" (not forkOS unless for some reason you really need another OS thread). However, I can imagine that it might be hard to implement job control and signal handling in that system. You could also consider using System.Process.runInteractiveProcess, for portability. Cheers, Simon From simonmarhaskell at gmail.com Fri Mar 2 08:32:19 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Mar 2 08:25:48 2007 Subject: Linker error when building GHC HEAD on Mac OS In-Reply-To: References: Message-ID: <45E82763.9040501@gmail.com> Stefan Holdermans wrote: > I'm trying to build GHC HEAD on Mac OS 10.4.8 (PowerPC), but end up with > a linker error: > > ../compiler/stage1/ghc-inplace -o stage2/ghc-6.7.20070228 -H16m -O > -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. > -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DDEBUGGER -threaded > -fforce-recomp stage2/main/Main.o > /usr/bin/ld: warning multiple definitions of symbol _UP > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib(terminal.so) > definition of _UP > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_termcap.o) > definition of _UP > /usr/bin/ld: warning multiple definitions of symbol _BC > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib(terminal.so) > definition of _BC > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_termcap.o) > definition of _BC > /usr/bin/ld: warning multiple definitions of symbol _PC > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib(terminal.so) > definition of _PC > > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_tputs.o) > definition of _PC > /usr/bin/ld: Undefined symbols: > _stg_interp_constr1_entry > _stg_interp_constr2_entry > _stg_interp_constr3_entry > _stg_interp_constr4_entry > _stg_interp_constr5_entry > _stg_interp_constr6_entry > _stg_interp_constr7_entry > _stg_interp_constr8_entry > collect2: ld returned 1 exit status > < samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.10 MUT (4.20 elapsed), > 0.05 GC (0.08 elapsed) :ghc>> > make[3]: *** [stage2/ghc-6.7.20070228] Error 1 > make[2]: *** [stage2/ghc-6.7.20070228] Error 2 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 This was a temporary build bug yesterday that is now fixed, sorry for the inconvenience. Cheers, Simon From gwright at comcast.net Fri Mar 2 10:16:36 2007 From: gwright at comcast.net (Gregory Wright) Date: Fri Mar 2 10:09:55 2007 Subject: Building unregisterised for FreeBSD/amd64 Message-ID: Hi, I'm trying to get ghc-6.6 running on my FreeBSD/amd64 box. It seems as if the build instructions are stale again. When I run $ cd /tmp/ghc-6.6/rts && gmake boot && gmake it falls over in the RTS, as noted in the documentation. But at the next step, when the libraries are built, $ cd ../libraries $ gmake boot && gmake cabal fails to build because it requires HSrts. This aborts the library build leaving me with an incomplete set of libraries. Is there a simple way to tell the build not to make cabal? Best, Greg From igloo at earth.li Fri Mar 2 10:36:46 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 2 10:30:06 2007 Subject: Problems with -caf-all In-Reply-To: <5EBDD6D8-FC75-4717-9AAD-83CEF2549B6C@reillyhayes.com> References: <5EBDD6D8-FC75-4717-9AAD-83CEF2549B6C@reillyhayes.com> Message-ID: <20070302153646.GA11678@matrix.chaos.earth.li> On Thu, Feb 22, 2007 at 09:00:01PM -0800, R Hayes wrote: > > I get the following error message when I try to compile with -caf-all. > > > /tmp/ghc583_0/ghc583_0.s:6482:0: > FATAL:Symbol _Mainmain_CAF_cc_ccs already defined. > > Any ideas as to what I'm doing wrong? Nothing, it's a bug: http://hackage.haskell.org/trac/ghc/ticket/249 It should work in 6.6.1 and 6.8, when they are released, or a recent build of the 6.6 branch or HEAD. Thanks Ian From igloo at earth.li Fri Mar 2 10:41:31 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 2 10:34:50 2007 Subject: Problem compiling GHC In-Reply-To: References: Message-ID: <20070302154131.GB11678@matrix.chaos.earth.li> On Mon, Feb 26, 2007 at 02:48:38PM +0100, Cristian Perfumo wrote: > > So, what I did, to be sure that the error had nothing to do with my > modification, was to download GHC again and try to build the original > version. But I still get the same error (that I paste below this message). So you're trying to build 6.6 from the release tarball? What version are you trying to compile it with? Thanks Ian From cperfumo at gmail.com Fri Mar 2 10:56:07 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Fri Mar 2 10:49:27 2007 Subject: Problem compiling GHC In-Reply-To: <20070302154131.GB11678@matrix.chaos.earth.li> References: <20070302154131.GB11678@matrix.chaos.earth.li> Message-ID: I got my problem solved just by deleting ghc* from /usr/local/bin. Weird, I know. I didn't have that problem again since that time but I left this post "open" because I wanted to know if someone else had had the same problem and the way he/she got rid of it. Cheers. Cristian On 3/2/07, Ian Lynagh wrote: > > On Mon, Feb 26, 2007 at 02:48:38PM +0100, Cristian Perfumo wrote: > > > > So, what I did, to be sure that the error had nothing to do with my > > modification, was to download GHC again and try to build the original > > version. But I still get the same error (that I paste below this > message). > > So you're trying to build 6.6 from the release tarball? > > What version are you trying to compile it with? > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070302/7775e0e5/attachment.htm From maeder at tzi.de Fri Mar 2 11:40:38 2007 From: maeder at tzi.de (Christian Maeder) Date: Fri Mar 2 11:34:12 2007 Subject: Building unregisterised for FreeBSD/amd64 In-Reply-To: References: Message-ID: <45E85386.10501@tzi.de> Gregory Wright schrieb: > cabal fails to build because it requires HSrts. This aborts the library > build > leaving me with an incomplete set of libraries. > > Is there a simple way to tell the build not to make cabal? I think you can simply delete Cabal from: SUBDIRS = ... of libraries/Makefile HTH Christian From marco-oweber at gmx.de Fri Mar 2 12:02:42 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Mar 2 11:57:29 2007 Subject: Registering source files along with .hi and .a files? Message-ID: <20070302170242.GB1621@gmx.de> I see that there is already haddock-interfaces and haddock-html options contained in package descriptions.. Would it make sense to add a hs-source-files option, too? I'm asking because it would be possible to register the source as well together with tag files. The source files could be used by DrIft. They can be used as reference as well (I think many haskell programmers dive into source when looking at some library features ? At least I do) Or is there already an option to register arbitrary files along with a package? Marc Weber From bulat.ziganshin at gmail.com Fri Mar 2 13:54:05 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Mar 2 13:48:31 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45E7F74B.8070707@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> Message-ID: <1679115132.20070302215405@gmail.com> Hello Simon, Friday, March 2, 2007, 1:07:07 PM, you wrote: >> But let me add a voice to keeping the non-threaded RTS around. i want to mention that problem here is not the threaded RTS by itself, but standard i/o library that works via separate i/o manager thread that is built-in part of RTS. my Streams library [1] don't uses this thread at all. for threads created with forkOS it provides excellent overlapping of I/O and computations (thanks, Simon, situation was *greatly* improved in 6.6). of course, it should be not so great for forkIO'd threads that i want to say is that future i/o lib may be written in the RTS-independent way. John Meacham once proposed to develop some common API for i/o managers that will allow to use various "select" variants with any i/o lib that works via this API -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gwright at comcast.net Fri Mar 2 17:39:16 2007 From: gwright at comcast.net (Gregory Wright) Date: Fri Mar 2 17:32:37 2007 Subject: Building unregisterised for FreeBSD/amd64 In-Reply-To: <45E85386.10501@tzi.de> References: <45E85386.10501@tzi.de> Message-ID: <63DA187D-D9A7-4A41-95F4-9EF9CF1CD711@comcast.net> Hi Christian, On Mar 2, 2007, at 11:40 AM, Christian Maeder wrote: > Gregory Wright schrieb: >> cabal fails to build because it requires HSrts. This aborts the >> library >> build >> leaving me with an incomplete set of libraries. >> >> Is there a simple way to tell the build not to make cabal? > > I think you can simply delete Cabal from: > > SUBDIRS = ... > > of libraries/Makefile > > HTH Christian > Deleting Cabal from SUBDIRS=... in libraries/Makefile fixes one probelm, but then the build fails because of a later dependency on Cabal when doing $ cd ../compiler $ gmake boot stage=2 && gmake stage=2 Removing the Cabal dependency from compiler/Makefile and the associated package.conf.* files doesn't help because compiler/main/CodeOutput.lhs depends on Distribution.Package for showPackageId. Is the best course just to give up on 6.6 and go back to 6.4.2, then use 6.4.2 to bring up 6.6? It seems odd that Cabal is so deeply intertwined with the compiler that you can't build the compiler without it. Does anyone know if this is intentional or unavoidable, or did incremental hacking just get us here by accident? Best Wishes, Greg From jgoerzen at complete.org Fri Mar 2 19:07:26 2007 From: jgoerzen at complete.org (John Goerzen) Date: Fri Mar 2 19:06:36 2007 Subject: ghci and ghc -threaded broken with pipes & forking References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> Message-ID: On 2007-03-02, Simon Marlow wrote: > Regarding your shell: I would suggest trying forkIO for the Haskell "processes" > (not forkOS unless for some reason you really need another OS thread). However, > I can imagine that it might be hard to implement job control and signal > handling in that system. You could also consider using > System.Process.runInteractiveProcess, for portability. Thinking about forkIO seems that it could be fairly complex to just drop in. The problem lies around file descriptors. When you fork off a new process, and then close file descriptors in the parent, they stay open in the child, and vice versa. Proper management of file descriptors is a critical part of a shell, and it's vital to close the proper set of FDs at the proper time in the parent and the child, or else bad things like pipes never closing could easily lead to deadlock. Of course, it is possible to work around this, but I fear that it could make the program very complex. -- John From marco-oweber at gmx.de Sat Mar 3 10:43:24 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Mar 3 10:38:20 2007 Subject: Query information about installed modules user or system only? Message-ID: <20070303154324.GA4455@gmx.de> Is there a way to ask ghc-pkg to list all availible packages found in the user lib or system lib or lib given by path? If I have read the documentation corretly it says: no. Is there any reason for this restriction? Can I query ghc-pkg to list pgk-config files (user/ system)? mfg Marc From simonmarhaskell at gmail.com Mon Mar 5 07:07:24 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Mar 5 07:00:38 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> Message-ID: <45EC07FC.8080300@gmail.com> John Goerzen wrote: > On 2007-03-02, Simon Marlow wrote: > >> Regarding your shell: I would suggest trying forkIO for the Haskell "processes" >> (not forkOS unless for some reason you really need another OS thread). However, >> I can imagine that it might be hard to implement job control and signal >> handling in that system. You could also consider using >> System.Process.runInteractiveProcess, for portability. > > Thinking about forkIO seems that it could be fairly complex to just drop > in. The problem lies around file descriptors. When you fork off a new > process, and then close file descriptors in the parent, they stay open > in the child, and vice versa. Proper management of file descriptors is > a critical part of a shell, and it's vital to close the proper set of > FDs at the proper time in the parent and the child, or else bad things > like pipes never closing could easily lead to deadlock. > > Of course, it is possible to work around this, but I fear that it could > make the program very complex. Admittedly I haven't completely thought this through, but my intuition was that you would be able to use forkIO at a higher level. That is, instead of just trying to replace forkProcess with forkIO, you replace forkProcess + pipes + FD handling with forkIO + lazy streams, for Haskell processes. So the way in which data is fed between processes depends on the process: Haskell processes talk to each other using lazy streams, external processes talk to each other over pipes, and at a boundary between the two you need a pipe with another Haskell thread to feed the pipe from a lazy stream, or vice-versa. Cheers, Simon From simonmarhaskell at gmail.com Mon Mar 5 07:09:29 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Mar 5 07:02:40 2007 Subject: Query information about installed modules user or system only? In-Reply-To: <20070303154324.GA4455@gmx.de> References: <20070303154324.GA4455@gmx.de> Message-ID: <45EC0879.2060504@gmail.com> Marc Weber wrote: > Is there a way to ask ghc-pkg to list all availible packages found in > the user lib or system lib or lib given by path? If I have read the > documentation corretly it says: no. > Is there any reason for this restriction? > > Can I query ghc-pkg to list pgk-config files (user/ system)? "ghc-pkg list" tells you each of the config files it is using. You can say "ghc-pkg --global-conf=" to use a different system config file. Does that help? Cheers, Simon From simonmarhaskell at gmail.com Mon Mar 5 07:59:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Mar 5 07:52:30 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <1679115132.20070302215405@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> Message-ID: <45EC1425.6080201@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Friday, March 2, 2007, 1:07:07 PM, you wrote: > >>> But let me add a voice to keeping the non-threaded RTS around. > > i want to mention that problem here is not the threaded RTS by itself, but > standard i/o library that works via separate i/o manager thread that > is built-in part of RTS. The I/O manager thread is hardly built-in to the RTS. It is all in a Haskell library; the only connection with the RTS is that the RTS feeds signals to the I/O manager thread down a pipe, and in fact we could move this signal-handling code out of the RTS and into the base package too. ? my Streams library [1] don't uses this thread > at all. for threads created with forkOS it provides excellent > overlapping of I/O and computations (thanks, Simon, situation was > *greatly* improved in 6.6). of course, it should be not so great for > forkIO'd threads I don't understand why forkOS should be any different from forkIO in this context. Could you explain? There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). Cheers, Simon From jgoerzen at complete.org Mon Mar 5 09:36:29 2007 From: jgoerzen at complete.org (John Goerzen) Date: Mon Mar 5 09:29:40 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45EC1425.6080201@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> Message-ID: <20070305143629.GA25876@excelhustler.com> On Mon, Mar 05, 2007 at 12:59:17PM +0000, Simon Marlow wrote: > There seems to be a common misconception that forkOS is necessary to get > certain kinds of concurrency, and forkIO won't do. I don't know where this > comes from: the documentation does seem to be quite clear to me. The only > reason to use forkOS is for interacting with foreign code that uses > thread-local state; everytyhing else can be done with forkIO (and it is > usually better to use forkIO). >From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? From igloo at earth.li Mon Mar 5 10:20:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Mar 5 10:13:15 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305143629.GA25876@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> Message-ID: <20070305152005.GA28112@matrix.chaos.earth.li> On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote: > On Mon, Mar 05, 2007 at 12:59:17PM +0000, Simon Marlow wrote: > > There seems to be a common misconception that forkOS is necessary to get > > certain kinds of concurrency, and forkIO won't do. I don't know where this > > comes from: the documentation does seem to be quite clear to me. The only > > reason to use forkOS is for interacting with foreign code that uses > > thread-local state; everytyhing else can be done with forkIO (and it is > > usually better to use forkIO). > > >From reading the docs, it sounds like forkIO keeps everything in a > single OS thread/process. Doesn't this mean that a program that uses > forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. Thanks Ian From simonmarhaskell at gmail.com Mon Mar 5 11:12:32 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Mar 5 11:05:43 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305152005.GA28112@matrix.chaos.earth.li> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> <20070305152005.GA28112@matrix.chaos.earth.li> Message-ID: <45EC4170.1040005@gmail.com> Ian Lynagh wrote: > On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote: >> On Mon, Mar 05, 2007 at 12:59:17PM +0000, Simon Marlow wrote: >>> There seems to be a common misconception that forkOS is necessary to get >>> certain kinds of concurrency, and forkIO won't do. I don't know where this >>> comes from: the documentation does seem to be quite clear to me. The only >>> reason to use forkOS is for interacting with foreign code that uses >>> thread-local state; everytyhing else can be done with forkIO (and it is >>> usually better to use forkIO). >> >From reading the docs, it sounds like forkIO keeps everything in a >> single OS thread/process. Doesn't this mean that a program that uses >> forkIO instead of forkOS loses out on SMP machines? > > You can use e.g. +RTS -N2 to use 2 OS threads. I've added a sentence to the forkOS docs to say that you don't need forkOS to get parallelism. Cheers, Simon From jgoerzen at complete.org Mon Mar 5 11:23:53 2007 From: jgoerzen at complete.org (John Goerzen) Date: Mon Mar 5 11:17:02 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305152005.GA28112@matrix.chaos.earth.li> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> <20070305152005.GA28112@matrix.chaos.earth.li> Message-ID: <20070305162353.GA28594@excelhustler.com> On Mon, Mar 05, 2007 at 03:20:05PM +0000, Ian Lynagh wrote: > > >From reading the docs, it sounds like forkIO keeps everything in a > > single OS thread/process. Doesn't this mean that a program that uses > > forkIO instead of forkOS loses out on SMP machines? > > You can use e.g. +RTS -N2 to use 2 OS threads. That's rather ugly though, and doesn't "just work". With other languages, I could just use OS threads, and let the OS schedule, say, 15 threads across 2 CPUs, or 4 CPUs, or however I may have. -- John From haskell at list.mightyreason.com Mon Mar 5 11:39:54 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Mar 5 11:33:04 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305162353.GA28594@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> <20070305152005.GA28112@matrix.chaos.earth.li> <20070305162353.GA28594@excelhustler.com> Message-ID: <45EC47DA.1040806@list.mightyreason.com> John Goerzen wrote: > On Mon, Mar 05, 2007 at 03:20:05PM +0000, Ian Lynagh wrote: >>> >From reading the docs, it sounds like forkIO keeps everything in a >>> single OS thread/process. Doesn't this mean that a program that uses >>> forkIO instead of forkOS loses out on SMP machines? >> You can use e.g. +RTS -N2 to use 2 OS threads. > > That's rather ugly though, and doesn't "just work". With other > languages, I could just use OS threads, and let the OS schedule, say, 15 > threads across 2 CPUs, or 4 CPUs, or however I may have. > > -- John Choice is good, but it does mean the default may need to be tweaked, such as with those options. The main difference in how lightweight or heavyweight the threads are. Lightweight forkIO threads allow for tremendous performance, see the benchmarks here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneos&lang=all http://shootout.alioth.debian.org/gp4/benchmark.php?test=message&lang=all Those benchmarks are without using a "+RTS -N2" style thread pool. -- Chris From igloo at earth.li Mon Mar 5 11:52:36 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Mar 5 11:45:45 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305162353.GA28594@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> <20070305152005.GA28112@matrix.chaos.earth.li> <20070305162353.GA28594@excelhustler.com> Message-ID: <20070305165236.GA29860@matrix.chaos.earth.li> On Mon, Mar 05, 2007 at 10:23:53AM -0600, John Goerzen wrote: > On Mon, Mar 05, 2007 at 03:20:05PM +0000, Ian Lynagh wrote: > > > >From reading the docs, it sounds like forkIO keeps everything in a > > > single OS thread/process. Doesn't this mean that a program that uses > > > forkIO instead of forkOS loses out on SMP machines? > > > > You can use e.g. +RTS -N2 to use 2 OS threads. > > That's rather ugly though, and doesn't "just work". With other > languages, I could just use OS threads, and let the OS schedule, say, 15 > threads across 2 CPUs, or 4 CPUs, or however I may have. You can set a default -Nn as described in http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-hooks if that helps. Thanks Ian From haskell at list.mightyreason.com Mon Mar 5 12:22:55 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Mar 5 12:16:05 2007 Subject: ANN: regex-base version 0.72 Message-ID: <45EC51EF.5010708@list.mightyreason.com> The version 0.71 of regex-base supplied with GHC 6.6 has a bug in Text.Regex.Base.Context: > instance (RegexLike a b) => RegexContext a b (MatchResult b) where that essentially uses 'tail' where it should not, and this may even be using tail on an empty list. This has been patched in the just announced unstable version of regex-base 0.83 and this message announces that the stable repository at http://darcs.haskell.org/packages/regex-base/ now has version 0.72 which is just 0.71 with this bug fixed. For the eventual GHC 6.6.1 release, the supplied version of regex-base should either be conservatively updated to 0.72 or updated to the slightly more convenient regex-unstable/regex-base version (currently 0.83). Cheer, Chris Kuklewicz From haskell2 at davidb.org Mon Mar 5 13:51:46 2007 From: haskell2 at davidb.org (David Brown) Date: Mon Mar 5 13:44:55 2007 Subject: Code breaks with '-O', any ideas. Message-ID: <45EC66C2.9000203@davidb.org> My program 'harchive' breaks if compiled with '-O'. Just wondering if anyone has suggestions on how to figure out what might be causing this. Is is possible to build some files with '-O' and others without? I'm not using unsafePerformIO. Thanks, David From bulat.ziganshin at gmail.com Mon Mar 5 15:10:08 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 5 15:04:52 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <45EC1425.6080201@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> Message-ID: <1736020357.20070305231008@gmail.com> Hello Simon, Monday, March 5, 2007, 3:59:17 PM, you wrote: >> my Streams library [1] don't uses this thread >> at all. for threads created with forkOS it provides excellent >> overlapping of I/O and computations (thanks, Simon, situation was >> *greatly* improved in 6.6). of course, it should be not so great for >> forkIO'd threads > I don't understand why forkOS should be any different from forkIO in this > context. Could you explain? > There seems to be a common misconception that forkOS is necessary to get certain > kinds of concurrency, and forkIO won't do. I don't know where this comes from: > the documentation does seem to be quite clear to me. The only reason to use > forkOS is for interacting with foreign code that uses thread-local state; > everytyhing else can be done with forkIO (and it is usually better to use forkIO). it may be entirely due my ignorance :) my program anyway uses -threaded and forkOS in order to run several C threads si,ultaneously and i don't performed tests in any other conditions so, one thread may read data from file, another thread write data and one more make compression using C routine. in 6.4, these tasks was overlapped only partially while in 6.6 they 100% overlap don't forget that read/write calls are also foreign calls, so while all C calls are marked as "safe", 6.4 doesn't overlap them good enough (also, to make things harder, C compression routine makes calls back to the Haskell routines). if haskell runtime will create new threads for executing other Haskell threads while one thread performs safe C call, then it should be ok. probably, i just mixed up forkOs and -threaded mode :) i remember that i had problems with forkIO. i will try it again and report results -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Mon Mar 5 15:29:50 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Mar 5 15:22:59 2007 Subject: Code breaks with '-O', any ideas. In-Reply-To: <45EC66C2.9000203@davidb.org> References: <45EC66C2.9000203@davidb.org> Message-ID: <20070305202950.GA1542@matrix.chaos.earth.li> On Mon, Mar 05, 2007 at 10:51:46AM -0800, David Brown wrote: > My program 'harchive' breaks > if compiled with '-O'. Just wondering if anyone has suggestions on > how to figure out what might be causing this. What do you mean by "breaks"? > Is is possible to build some files with '-O' and others without? Yes. Thanks Ian From haskell2 at davidb.org Mon Mar 5 15:42:00 2007 From: haskell2 at davidb.org (David Brown) Date: Mon Mar 5 15:35:12 2007 Subject: Code breaks with '-O', any ideas. In-Reply-To: <20070305202950.GA1542@matrix.chaos.earth.li> References: <45EC66C2.9000203@davidb.org> <20070305202950.GA1542@matrix.chaos.earth.li> Message-ID: <45EC8098.3020404@davidb.org> Ian Lynagh wrote: > On Mon, Mar 05, 2007 at 10:51:46AM -0800, David Brown wrote: >> My program 'harchive' breaks >> if compiled with '-O'. Just wondering if anyone has suggestions on >> how to figure out what might be causing this. > > What do you mean by "breaks"? :-). It guess it would be best to describe it as behaving differently. I've seen to case. One has to do with my binding to sqlite3. Sometimes the queries don't return the right results or gibberish is entered into the database. This suggests my binding has problems (like pointers living past a GC). In another instance, a populated map was failing to find an entry in it. I added a debug message to print out the map, and then it worked fine. I'm now rebuilding individual parts with -O to see if I can isolate the problem(s). Thanks, David From haskell2 at davidb.org Mon Mar 5 16:21:42 2007 From: haskell2 at davidb.org (David Brown) Date: Mon Mar 5 16:14:51 2007 Subject: Code breaks with '-O', any ideas. In-Reply-To: <45EC8098.3020404@davidb.org> References: <45EC66C2.9000203@davidb.org> <20070305202950.GA1542@matrix.chaos.earth.li> <45EC8098.3020404@davidb.org> Message-ID: <45EC89E6.10602@davidb.org> David Brown wrote: > Ian Lynagh wrote: >> On Mon, Mar 05, 2007 at 10:51:46AM -0800, David Brown wrote: >>> My program 'harchive' breaks >>> if compiled with '-O'. Just wondering if anyone has suggestions on >>> how to figure out what might be causing this. >> What do you mean by "breaks"? > > I'm now rebuilding individual parts with -O to see if I can isolate > the problem(s). Well, that helped. I found the problem. I had something like: import qualified Data.ByteString as B let hash = B.pack $ replicate (#const SHA_DIGEST_LENGTH) 0 ... B.useAsCStringLen hash $ \ (hdata, _) -> do c_sha1Final hash ctx return hash But this seems to be causing the hash to be garbage, and possibly have c_sha1Final write a 20-byte hash into some garbled piece of memory. Ireplaced this with let hashLen = (#const SHA_DIGEST_LENGTH) hashData <- mallocForeignPtrBytes hashLen withForeignPtr hashData $ \hashP -> do c_sha1Final hashP ctx B.copyCStringLen (hashP, hashLen) and the code works both with and without optimization. Dave From dons at cse.unsw.edu.au Mon Mar 5 19:29:08 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Mon Mar 5 19:22:20 2007 Subject: Code breaks with '-O', any ideas. In-Reply-To: <45EC89E6.10602@davidb.org> References: <45EC66C2.9000203@davidb.org> <20070305202950.GA1542@matrix.chaos.earth.li> <45EC8098.3020404@davidb.org> <45EC89E6.10602@davidb.org> Message-ID: <20070306002908.GB4098@cse.unsw.EDU.AU> haskell2: > David Brown wrote: > > Ian Lynagh wrote: > >> On Mon, Mar 05, 2007 at 10:51:46AM -0800, David Brown wrote: > >>> My program 'harchive' breaks > >>> if compiled with '-O'. Just wondering if anyone has suggestions on > >>> how to figure out what might be causing this. > >> What do you mean by "breaks"? > > > > I'm now rebuilding individual parts with -O to see if I can isolate > > the problem(s). > > Well, that helped. I found the problem. I had something like: > > import qualified Data.ByteString as B > > let hash = B.pack $ replicate (#const SHA_DIGEST_LENGTH) 0 > ... > B.useAsCStringLen hash $ \ (hdata, _) -> do > c_sha1Final hash ctx > return hash > > But this seems to be causing the hash to be garbage, and possibly have > c_sha1Final write a 20-byte hash into some garbled piece of memory. > > Ireplaced this with > > let hashLen = (#const SHA_DIGEST_LENGTH) > hashData <- mallocForeignPtrBytes hashLen > withForeignPtr hashData $ \hashP -> do > c_sha1Final hashP ctx > B.copyCStringLen (hashP, hashLen) > > and the code works both with and without optimization. > > Dave Ah, this is my fault! The old api used 'useAsCSTringLen' unsafely. Its a zero-copying version. The default is now copyCStringLen. See this thread for the issues involved: http://www.haskell.org/pipermail/libraries/2007-January/006783.html and for how it has been resolved: http://www.haskell.org/pipermail/libraries/2007-January/006801.html So yes, using 'copyCStringlen' is the appropriate thing to do, if you don't want to guarantee the C side of things. -- Don From simonmarhaskell at gmail.com Tue Mar 6 05:48:57 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Mar 6 05:42:10 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <20070305162353.GA28594@excelhustler.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <20070305143629.GA25876@excelhustler.com> <20070305152005.GA28112@matrix.chaos.earth.li> <20070305162353.GA28594@excelhustler.com> Message-ID: <45ED4719.3000904@gmail.com> John Goerzen wrote: > On Mon, Mar 05, 2007 at 03:20:05PM +0000, Ian Lynagh wrote: >>> >From reading the docs, it sounds like forkIO keeps everything in a >>> single OS thread/process. Doesn't this mean that a program that uses >>> forkIO instead of forkOS loses out on SMP machines? >> You can use e.g. +RTS -N2 to use 2 OS threads. > > That's rather ugly though, and doesn't "just work". With other > languages, I could just use OS threads, and let the OS schedule, say, 15 > threads across 2 CPUs, or 4 CPUs, or however I may have. One day we might make this automatic, but you're missing the main point: what GHC gives you is lightweight threads that scale transparently on a multiprocessor. You can create thousands of threads without worrying about performance, and therefore you are free to structure your program's concurrency according to the application's needs, not the demands of performance. You don't have to limit the number of threads and do event-driven programming just because threads are too expensive. And your program will scale on a multiprocessor without recompilation. Cheers, Simon From simonmarhaskell at gmail.com Tue Mar 6 05:52:14 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Mar 6 05:45:28 2007 Subject: ghci and ghc -threaded broken with pipes & forking In-Reply-To: <1736020357.20070305231008@gmail.com> References: <45E6EBEE.8060204@gmail.com> <20070301154950.GB8010@excelhustler.com> <45E6FD99.1090802@gmail.com> <20070301173854.GA12270@excelhustler.com> <45E7F74B.8070707@gmail.com> <1679115132.20070302215405@gmail.com> <45EC1425.6080201@gmail.com> <1736020357.20070305231008@gmail.com> Message-ID: <45ED47DE.5080704@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Monday, March 5, 2007, 3:59:17 PM, you wrote: > >>> my Streams library [1] don't uses this thread >>> at all. for threads created with forkOS it provides excellent >>> overlapping of I/O and computations (thanks, Simon, situation was >>> *greatly* improved in 6.6). of course, it should be not so great for >>> forkIO'd threads > >> I don't understand why forkOS should be any different from forkIO in this >> context. Could you explain? > >> There seems to be a common misconception that forkOS is necessary to get certain >> kinds of concurrency, and forkIO won't do. I don't know where this comes from: >> the documentation does seem to be quite clear to me. The only reason to use >> forkOS is for interacting with foreign code that uses thread-local state; >> everytyhing else can be done with forkIO (and it is usually better to use forkIO). > > it may be entirely due my ignorance :) my program anyway uses > -threaded and forkOS in order to run several C threads si,ultaneously > and i don't performed tests in any other conditions > > so, one thread may read data from file, another thread write data and > one more make compression using C routine. in 6.4, these tasks was > overlapped only partially while in 6.6 they 100% overlap > > don't forget that read/write calls are also foreign calls, so while > all C calls are marked as "safe", 6.4 doesn't overlap them good > enough (also, to make things harder, C compression routine makes calls > back to the Haskell routines). if haskell runtime will create new > threads for executing other Haskell threads while one thread performs > safe C call, then it should be ok. probably, i just mixed up forkOs > and -threaded mode :) Ok, there was a complete rewrite of the scheduler between 6.4 and 6.6 so this may account for the differences you see. Beware of forkOS: it'll reduce performance on the Haskell side, because essentially each context switch between a forkOS'd thread and another thread is a complete OS-thread context switch, which is hundreds of times slower than context switching between forkIO'd threads. Cheers, Simon From schneegloeckchen at gmx.li Tue Mar 6 10:18:18 2007 From: schneegloeckchen at gmx.li (mm) Date: Tue Mar 6 09:11:10 2007 Subject: Duplicate instance declarations of a methodless class Message-ID: <20070306151818.GA5733@manthe.gotdns.org> Hello, I was thinking that it could maybe be useful to allow duplicate instance declarations, if the class has no methods. From my naive point of view, i can not see problems, scince there are no conflicting methods to choose from. But the following program fails to be compiled by ghc-6.6: > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > class GT a b > class Succ a b > data Zero > data One > data Two > data Three > instance Succ One Zero > instance Succ Two One > instance Succ Three Two > instance Succ a b => GT a b > instance (Succ a b, GT b c) => GT a c The former two lines lead to: test5.lhs:22:1: Duplicate instance declarations: instance (Succ a b) => GT a b -- Defined at test5.lhs:22:1 instance (Succ a b, GT b c) => GT a c -- Defined at test5.lhs:23:1 From alfonso.acosta at gmail.com Tue Mar 6 14:49:25 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Mar 6 14:42:30 2007 Subject: Duplicate instance declarations of a methodless class In-Reply-To: <20070306151818.GA5733@manthe.gotdns.org> References: <20070306151818.GA5733@manthe.gotdns.org> Message-ID: <6a7c66fc0703061149m54b7a59ev9812b0c1231d3030@mail.gmail.com> Did you try to compile with -fallow-overlapping-instances On 3/6/07, mm wrote: > Hello, > > I was thinking that it could maybe be useful to allow duplicate instance > declarations, if the class has no methods. From my naive point of view, i > can not see problems, scince there are no conflicting methods to choose > from. But the following program fails to be compiled by ghc-6.6: > > > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > > class GT a b > > class Succ a b > > > data Zero > > data One > > data Two > > data Three > > > instance Succ One Zero > > instance Succ Two One > > instance Succ Three Two > > > instance Succ a b => GT a b > > instance (Succ a b, GT b c) => GT a c > > The former two lines lead to: > > test5.lhs:22:1: > Duplicate instance declarations: > instance (Succ a b) => GT a b -- Defined at test5.lhs:22:1 > instance (Succ a b, GT b c) => GT a c -- Defined at test5.lhs:23:1 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From schneegloeckchen at gmx.li Tue Mar 6 15:52:02 2007 From: schneegloeckchen at gmx.li (mm) Date: Tue Mar 6 14:44:53 2007 Subject: Duplicate instance declarations of a methodless class In-Reply-To: <6a7c66fc0703061149m54b7a59ev9812b0c1231d3030@mail.gmail.com> References: <20070306151818.GA5733@manthe.gotdns.org> <6a7c66fc0703061149m54b7a59ev9812b0c1231d3030@mail.gmail.com> Message-ID: <20070306205202.GA6652@manthe.gotdns.org> On Tue, Mar 06, 2007 at 08:49:25PM +0100, Alfonso Acosta wrote: > Did you try to compile with -fallow-overlapping-instances Same effect: ghc -fallow-overlapping-instances --make test5.lhs [1 of 1] Compiling Main ( test5.lhs, test5.o ) test5.lhs:22:1: Duplicate instance declarations: instance [overlap ok] (Succ a b) => GT a b -- Defined at test5.lhs:22:1 instance [overlap ok] (Succ a b, GT b c) => GT a c -- Defined at test5.lhs:23:1 Does it work with another compiler version? > > On 3/6/07, mm wrote: > >Hello, > > > >I was thinking that it could maybe be useful to allow duplicate instance > >declarations, if the class has no methods. From my naive point of view, i > >can not see problems, scince there are no conflicting methods to choose > >from. But the following program fails to be compiled by ghc-6.6: > > > >> {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} > > > >> class GT a b > >> class Succ a b > > > >> data Zero > >> data One > >> data Two > >> data Three > > > >> instance Succ One Zero > >> instance Succ Two One > >> instance Succ Three Two > > > >> instance Succ a b => GT a b > >> instance (Succ a b, GT b c) => GT a c > > > >The former two lines lead to: > > > >test5.lhs:22:1: > > Duplicate instance declarations: > > instance (Succ a b) => GT a b -- Defined at test5.lhs:22:1 > > instance (Succ a b, GT b c) => GT a c -- Defined at test5.lhs:23:1 > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users@haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From haskell2 at davidb.org Tue Mar 6 15:03:05 2007 From: haskell2 at davidb.org (David Brown) Date: Tue Mar 6 14:56:10 2007 Subject: unsafePerformIO safety. Message-ID: <45EDC8F9.1060602@davidb.org> I've noticed quite a few pages referencing constructs such as: var :: MVar ([Foo]) var = unsafePerformIO (newMVar ([])) and the likes. Is there a danger of different uses of 'var' getting new MVars instead of all sharing one. Having a reliable way to create a piece of global state would be very convenient. Dave From quarantedeux42 at yahoo.fr Tue Mar 6 16:29:21 2007 From: quarantedeux42 at yahoo.fr (Fernand Lacas) Date: Tue Mar 6 16:22:26 2007 Subject: HDirect and GHC-6.6 Message-ID: <20070306212921.10441.qmail@web27706.mail.ukl.yahoo.com> Hi all, It's been a long time since I had the time to work with haskell, but I have some news about HDirect. I now succeed in compiling "ihc.exe" with the typelib support (see my previous posts on the subject), but I had to bypass the packages. That is, the second compilation stage is made using the object files from the "comlib" rather than the "com" package. I understand that it is rather ugly but I still hope that it may be useful to anyone needing COM support with ghc. If anyone is interested in the source files, feel free to ask me. Sincerely yours, sL ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070306/c1c2f1ce/attachment.htm From seth at cql.com Tue Mar 6 17:28:13 2007 From: seth at cql.com (Seth Kurtzberg) Date: Tue Mar 6 17:22:54 2007 Subject: unsafePerformIO safety. In-Reply-To: <45EDC8F9.1060602@davidb.org> References: <45EDC8F9.1060602@davidb.org> Message-ID: <20070306172813.c0b10c87.seth@cql.com> On Tue, 06 Mar 2007 12:03:05 -0800 David Brown wrote: > I've noticed quite a few pages referencing constructs such as: > > var :: MVar ([Foo]) > var = unsafePerformIO (newMVar ([])) > > and the likes. Is there a danger of different uses of 'var' getting > new MVars instead of all sharing one. > > Having a reliable way to create a piece of global state would be very > convenient. This operation is unsafe by definition. I use it extensively, without problems. The "unsafe" in the name reminds you that there are situations for which the function is inappropriate, but all of my deployed commercial programs have functionality of this sort. Understand the risk, but don't hesitate to use it. Seth Kurtzberg > > Dave > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From haskell2 at davidb.org Tue Mar 6 18:18:36 2007 From: haskell2 at davidb.org (David Brown) Date: Tue Mar 6 18:11:42 2007 Subject: unsafePerformIO safety. In-Reply-To: <20070306172813.c0b10c87.seth@cql.com> References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> Message-ID: <45EDF6CC.6030804@davidb.org> Seth Kurtzberg wrote: > On Tue, 06 Mar 2007 12:03:05 -0800 > David Brown wrote: > >> I've noticed quite a few pages referencing constructs such as: >> >> var :: MVar ([Foo]) >> var = unsafePerformIO (newMVar ([])) >> >> and the likes. Is there a danger of different uses of 'var' getting >> new MVars instead of all sharing one. >> >> Having a reliable way to create a piece of global state would be very >> convenient. > > This operation is unsafe by definition. I use it extensively, > without problems. The "unsafe" in the name reminds you that there > are situations for which the function is inappropriate, but all of > my deployed commercial programs have functionality of this sort. > Understand the risk, but don't hesitate to use it. Do you do anything to keep 'var' from getting inlined? I can envision a case where the code would be inlined, and then each use would get a separate MVar. Thanks, Dave From isaacdupree at charter.net Tue Mar 6 18:25:57 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Mar 6 18:18:00 2007 Subject: unsafePerformIO safety. In-Reply-To: <45EDC8F9.1060602@davidb.org> References: <45EDC8F9.1060602@davidb.org> Message-ID: <45EDF885.1010204@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Brown wrote: > I've noticed quite a few pages referencing constructs such as: > > var :: MVar ([Foo]) > var = unsafePerformIO (newMVar ([])) > > and the likes. Is there a danger of different uses of 'var' getting > new MVars instead of all sharing one. If I remember correctly, you "should" put {-# NOINLINE var #-} on a line just before that. > > Having a reliable way to create a piece of global state would be very > convenient. This is well known and extensively discussed - unfortunately it is a complicated (or at least controversial) issue Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7fiFHgcxvIWYTTURAoMXAJ9SCryCX+daNLKrMIhWlMh/aJmVXwCghosx 6/lBweYnNslHLal57RAtX0Y= =2oIN -----END PGP SIGNATURE----- From lennart at augustsson.net Tue Mar 6 18:24:37 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Mar 6 18:18:02 2007 Subject: unsafePerformIO safety. In-Reply-To: <45EDF6CC.6030804@davidb.org> References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> Message-ID: Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe. On Mar 6, 2007, at 23:18 , David Brown wrote: > Seth Kurtzberg wrote: >> On Tue, 06 Mar 2007 12:03:05 -0800 >> David Brown wrote: >> >>> I've noticed quite a few pages referencing constructs such as: >>> >>> var :: MVar ([Foo]) >>> var = unsafePerformIO (newMVar ([])) >>> >>> and the likes. Is there a danger of different uses of 'var' getting >>> new MVars instead of all sharing one. >>> >>> Having a reliable way to create a piece of global state would be >>> very >>> convenient. >> >> This operation is unsafe by definition. I use it extensively, >> without problems. The "unsafe" in the name reminds you that there >> are situations for which the function is inappropriate, but all of >> my deployed commercial programs have functionality of this sort. >> Understand the risk, but don't hesitate to use it. > > Do you do anything to keep 'var' from getting inlined? I can envision > a case where the code would be inlined, and then each use would get a > separate MVar. > > Thanks, > Dave > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From haskell at brecknell.org Tue Mar 6 18:33:57 2007 From: haskell at brecknell.org (Matthew Brecknell) Date: Tue Mar 6 18:26:59 2007 Subject: Duplicate instance declarations of a methodless class In-Reply-To: <20070306205202.GA6652@manthe.gotdns.org> References: <20070306151818.GA5733@manthe.gotdns.org> <6a7c66fc0703061149m54b7a59ev9812b0c1231d3030@mail.gmail.com> <20070306205202.GA6652@manthe.gotdns.org> Message-ID: <1173224037.25748.1178095083@webmail.messagingengine.com> Alfonso Acosta: > Did you try to compile with -fallow-overlapping-instances mm : > Same effect: > > ghc -fallow-overlapping-instances --make test5.lhs > [1 of 1] Compiling Main ( test5.lhs, test5.o ) > > test5.lhs:22:1: > Duplicate instance declarations: > instance [overlap ok] (Succ a b) => GT a b > -- Defined at test5.lhs:22:1 > instance [overlap ok] (Succ a b, GT b c) => GT a c > -- Defined at test5.lhs:23:1 Also see Oleg's post in this thread: http://www.haskell.org/pipermail/haskell-cafe/2007-February/022926.html From ndmitchell at gmail.com Tue Mar 6 18:56:19 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Mar 6 18:49:23 2007 Subject: unsafePerformIO safety. In-Reply-To: References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> Message-ID: <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> Hi On 3/6/07, Lennart Augustsson wrote: > Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe. Couldn't GHC bake in knowledge about unsafePerformIO, and never inline it? It is a slightly hacky solution, but since unsafePerformIO is pretty much only used in hacks, I think its almost fitting. Thanks Neil From haskell2 at davidb.org Tue Mar 6 19:03:59 2007 From: haskell2 at davidb.org (David Brown) Date: Tue Mar 6 18:57:07 2007 Subject: unsafePerformIO safety. In-Reply-To: <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> Message-ID: <45EE016F.5040406@davidb.org> Neil Mitchell wrote: > On 3/6/07, Lennart Augustsson wrote: >> Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe. > > Couldn't GHC bake in knowledge about unsafePerformIO, and never inline > it? It is a slightly hacky solution, but since unsafePerformIO is > pretty much only used in hacks, I think its almost fitting. It seems to be used a bit more than just as a hack. Many things that interface with the real world, but try to present lazy interfaces have to use it. Maintaining a shared state that doesn't have to be passed around to everything that uses it isn't really a hack. As an example, I would like to have something that performs logging, and is used by many clients. Without the unsafePerformIO, everything has to somehow find and pass around the state of this logging system, whereas with it, it can just allocate one when first needed. Non-strict semantics are kind of a new thing for me. I'm still trying to get a good grasp of what can be lazy, what should live in the IO Monad, and what should have a carefully crafted "bridge" between the two. Things like hGetContents have somewhat set a trend here. Dave From lennart at augustsson.net Wed Mar 7 03:28:38 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 7 03:22:00 2007 Subject: unsafePerformIO safety. In-Reply-To: <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> Message-ID: I wouldn't like if unsafePerformIO could never be inlined, sometimes you want it inlined for performance. And not all uses are hacky, it's just that when I use it, then burden is on me to convince myself that it is safe. On Mar 6, 2007, at 23:56 , Neil Mitchell wrote: > Hi > > On 3/6/07, Lennart Augustsson wrote: >> Yeah, you really need {-# NOINLINE var #-} to make it reasonable >> safe. > > Couldn't GHC bake in knowledge about unsafePerformIO, and never inline > it? It is a slightly hacky solution, but since unsafePerformIO is > pretty much only used in hacks, I think its almost fitting. > > Thanks > > Neil From simonmarhaskell at gmail.com Wed Mar 7 04:27:26 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Mar 7 04:20:32 2007 Subject: unsafePerformIO safety. In-Reply-To: References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> Message-ID: <45EE857E.20303@gmail.com> Lennart Augustsson wrote: > I wouldn't like if unsafePerformIO could never be inlined, sometimes you > want it inlined for performance. > And not all uses are hacky, it's just that when I use it, then burden is > on me to convince myself that it is safe. unsafePerformIO is currently not inlined - there's a NOINLINE pragma on its definition in GHC.IOBase, and some comments in there to explain why. You're right that sometimes you really want it to be inlined - this is why there's a function called inlinePerformIO in Data.ByteString.Base, for example. You'd better really know what you're doing before using that one, though :-) Cheers, Simon From isaacdupree at charter.net Wed Mar 7 06:17:55 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Mar 7 06:09:59 2007 Subject: unsafePerformIO safety. In-Reply-To: <45EE857E.20303@gmail.com> References: <45EDC8F9.1060602@davidb.org> <20070306172813.c0b10c87.seth@cql.com> <45EDF6CC.6030804@davidb.org> <404396ef0703061556u5901abdsdd6d9fe4e4ee3e98@mail.gmail.com> <45EE857E.20303@gmail.com> Message-ID: <45EE9F63.2020409@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Marlow wrote: > You're right that sometimes you really want it to be inlined - this is > why there's a function called inlinePerformIO in Data.ByteString.Base, > for example. You'd better really know what you're doing before using > that one, though :-) yep, it should be generally available as unsafeInlineUnsafePerformIO (-: It's especially unsafe because... all of the IO might not be executed, due to lazy evaluation + optimization? Some of the IO might be run twice without other parts of it being so? Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7p9jHgcxvIWYTTURAqAKAKCu8dJ4rpyMcMH7ebPv0HfIUyGSgACgy0Jq naeTCZk/2xZraOrSJtyObm8= =oKKG -----END PGP SIGNATURE----- From quarantedeux42 at yahoo.fr Wed Mar 7 13:37:36 2007 From: quarantedeux42 at yahoo.fr (Fernand Lacas) Date: Wed Mar 7 13:30:39 2007 Subject: [HDirect] ihc and COM Message-ID: <20070307183736.19647.qmail@web27709.mail.ukl.yahoo.com> Hi, I'm continuing to experiment with HDirect and the ihc compiler. Trying the "huge" type libraries from Office applications (Word, Excel...), I've met the following issue: some Haskell stubs do not compile out of the box, essentially because of type mismatch between the type signature generated by the ihc compiler and the stub's code. For instance: > Excel.hs:32:25: No instance for (Automation.Variant a0) arising from use of `Automation.outVariant' at Excel.hs:32:25-45 Possible fix: add (Automation.Variant a0) to the type signature(s) for `global_getActiveCell' The faulty declaration is indeed : global_getActiveCell :: Global a1 -> Prelude.IO a0 global_getActiveCell = Automation.propertyGet "ActiveCell" [] Automation.outVariant whereas the correct type is (Automation.Variant a0) => Global a1 -> Prelude.IO a0 There are also some cases where there is a type mismatch between "Int64" and "Automation.Date" type, but the essence of the error is the same : the type signature does not match the method's stub's code. I've looked for an option in the compiler that would help (for instance, I suppose that removing all type signatures from the haskell file would allow to compile it), but I haven't found one. NB : the ihc command line was "../src/ihc.exe --tlb -fautomation -fprefix-interface-name -fmaybe-optional-params -v XL5EN32.OLB (where the OLB file is Excel's type library). Did anyone experienced similar issue ? Thanks in advance, sL PS: the COM library (without Automation) works well. ___________________________________________________________________________ D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses http://fr.answers.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070307/b4f99de7/attachment.htm From p.tanski at gmail.com Thu Mar 8 00:33:52 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Thu Mar 8 00:27:00 2007 Subject: local ByteArrays: performGC do any good? Message-ID: <5C63AE4D-E822-4B6F-B6D3-A3932234857C@gmail.com> Hello Simon and Ian, Perhaps either of you may be able to answer this question easily: I am testing the replacement Integer library in Haskell and I wanted to copy arrays between the two--I can't do all of that in Haskell because the RTS allocation has a maximum alignment of 4 when I need 16 (sometimes--I might also realign things, as a last resort). In any case, the easy way to do it would be to grab the ByteArray# from the Integer (J# Int# ByteArray#), grab the Addr# with the primitive byteArrayContents#, turn that into a pointer and pass it to the foreign function. That would be a sketchy move--even for testing-- because Integer ByteArrays are local (not pinned). Do you think doing a performGC just before grabbing the Addr# would help? There doesn't seem to be another primitive for marshalling a pointer from a ByteArray. Cheers, Peter Tanski From ndmitchell at gmail.com Thu Mar 8 09:58:12 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 8 09:51:11 2007 Subject: Parsing GHC Core Message-ID: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> Hi, I would like to parse GHC Core to an abstract syntax tree, as the old GHC Core library used to allow the user to do. I do not want to depend on the GHC API (too big), but don't mind depending on a small and separately available .cabal'd package. I also don't mind copying a few modules into my program. The types are of no interest to me, if that makes it any easier Does anyone have the code/library to do this sitting around? Thanks Neil From gwright at comcast.net Thu Mar 8 11:25:39 2007 From: gwright at comcast.net (Gregory Wright) Date: Thu Mar 8 11:16:58 2007 Subject: Still trying to build unregisterised for FreeBSD/amd64 Message-ID: <5F87E999-5CE9-4DF0-87B9-850916F55CF0@comcast.net> Hi, I have made some progress in compiling ghc-6.6 unregisterised for freebsd/amd64, but I am stuck again. To get the build on the host (freebsd/i386) to go through, I had to fix up Linker.c so that it would build. (Linker.c seems to define at least one utility function required by the rts, markRootPtrTable.) The instruction on the wiki to, "Don't worry if the build falls over in the RTS, we don't need the RTS yet," seems incorrect for ghc-6.6 at least. If the build fails in the rts, trying to proceed further just leads to more errors. I fixed up Linker.c by replacing the calls to mmap (which will need fixing up anyway on FreeBSD/amd64) with MAP_FAILED and copying the definitions of four relocation types for X86_64 from machine/elf.h on the target into do_Elf_Rela_relocations. (The build on the host complained that R_X86_64_64, R_X86_64_PC32, R_X86_64_32 and R_X86_64_32S were undefined.) With this change, the build on the host was able to complete. Collecting the .hc files works too, but the Makefile is out of date and references a few files that no longer exist. With a little hand editing, this is fixed and I have what I believe is a good set of .hc files. Over on the target, I unpack the fresh ghc-6.6-src.tar.bz2 and drop the .hc files on top of it. On FreeBSD, gmp is usually installed by the ports system in / usr/local/lib, so I preface invocations of configure in distrib/hc-build by CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" so that the installed gmp is picked up in the configuration. I also edit mk/bootstrap.mk to add -L/usr/local/lib to HC_LD_BOOT_OPTS, and also add -lHSregex-compat -lHSregex-posix -lHSregex-base to HC_BOOT_LIBS. The directories to find the regex libraries also get added to HC_BOOT_LD_OPTS (-L$(FPTOOLS_TOP_ABS)/libraries/regex-*). I also have to delete cabal-setup from the SUBDIRS in libraries/Cabal/ Makefile. Otherwise the build fails complaining that there is no rule to make Cabal-setup.o. I also have to change libraries/base/Makefile to not try to build Prim.hs. It seems that when booting from .hc files, PrimopWrappers.hs does not in fact depend on Prim.hs; instead, PrimopWrappers.hs is not really used since we have PrimopWrappers.hc copied over from the host. (Without this change the Makefile tries to invoke the yet unbuilt genprimopcode program to build Prim.hs.) With these changes, distrib/hc-build is ready to roll. It chugs along happily until it tries to build Linker.c (which I have copied over from the host, so it has the changes that I made there) and then ghc-inplace segfaults: ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations - optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc- fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 - static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c - o Linker.o Segmentation fault (core dumped) gmake: *** [Linker.o] Error 139 gmake: Leaving directory `/tmp/ghc-6.6/rts' I noticed that a year and a half ago when Wilhelm Kloke was porting ghc-6.4.1 to freebsd/amd64 he remarked that Linker.c had to be deleted. If I delete it from the target, the build just fails earlier, when genapply is being built, because of missing symbols: ------------------------------------------------------------------------ == gmake all -wr; in /tmp/ghc-6.6/utils/genapply ------------------------------------------------------------------------ gcc -x c GenApply.hc -o GenApply.o -c -O -fomit-frame-pointer -fno- asynchronous-unwind-tables -fno-unit-at-a-time -fno-builtin -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=606 -O -I/tmp/ghc-6.6/ includes -I/tmp/ghc-6.6/libraries/base/include -I/tmp/ghc-6.6/ libraries/unix/include -I/tmp/ghc-6.6/libraries/parsec/include -I/ tmp/ghc-6.6/libraries/readline/include -I. `echo | sed 's/^$/- DSTOLEN_X86_REGS=4/'` gcc -o genapply -fomit-frame-pointer -fno-asynchronous-unwind-tables -fno-unit-at-a-time -fno-builtin -DNO_REGS -DUSE_MINIINTERPRETER - D__GLASGOW_HASKELL__=606 -O -I/tmp/ghc-6.6/includes -I/tmp/ghc-6.6/ libraries/base/include -I/tmp/ghc-6.6/libraries/unix/include -I/tmp/ ghc-6.6/libraries/parsec/include -I/tmp/ghc-6.6/libraries/readline/ include -L/tmp/ghc-6.6/rts -L/tmp/ghc-6.6/libraries/base -L/tmp/ ghc-6.6/libraries/base/cbits -L/tmp/ghc-6.6/libraries/haskell98 -L/ tmp/ghc-6.6/libraries/parsec -L/tmp/ghc-6.6/libraries/regex-base -L/ tmp/ghc-6.6/libraries/regex-compat -L/tmp/ghc-6.6/libraries/regex- posix -L/tmp/ghc-6.6/libraries/Cabal -L/usr/local/lib -L/tmp/ghc-6.6/ libraries/template-haskell -L/tmp/ghc-6.6/libraries/readline -L/tmp/ ghc-6.6/libraries/unix -L/tmp/ghc-6.6/libraries/unix/cbits -u "GHCziBase_Izh_static_info" -u "GHCziBase_Czh_static_info" -u "GHCziFloat_Fzh_static_info" -u "GHCziFloat_Dzh_static_info" -u "GHCziPtr_Ptr_static_info" -u "GHCziWord_Wzh_static_info" -u "GHCziInt_I8zh_static_info" -u "GHCziInt_I16zh_static_info" -u "GHCziInt_I32zh_static_info" -u "GHCziInt_I64zh_static_info" -u "GHCziWord_W8zh_static_info" -u "GHCziWord_W16zh_static_info" -u "GHCziWord_W32zh_static_info" -u "GHCziWord_W64zh_static_info" -u "GHCziStable_StablePtr_static_info" -u "GHCziBase_Izh_con_info" -u "GHCziBase_Czh_con_info" -u "GHCziFloat_Fzh_con_info" -u "GHCziFloat_Dzh_con_info" -u "GHCziPtr_Ptr_con_info" -u "GHCziStable_StablePtr_con_info" -u "GHCziBase_False_closure" -u "GHCziBase_True_closure" -u "GHCziPack_unpackCString_closure" -u "GHCziIOBase_stackOverflow_closure" -u "GHCziIOBase_heapOverflow_closure" -u "GHCziIOBase_NonTermination_closure" -u "GHCziIOBase_BlockedOnDeadMVar_closure" -u "GHCziIOBase_Deadlock_closure" -u "GHCziWeak_runFinalizzerBatch_closure" -u "__stginit_Prelude" GenApply.o -lHSreadline -lHStemplate-haskell -lHSunix - lHSunix_cbits -lHSCabal -lHSregex-compat -lHSregex-posix -lHSregex- base -lHShaskell98 -lHSrts -lHSbase -lHSbase_cbits -lHSparsec -lgmp -lm /tmp/ghc-6.6/rts/libHSrts.a(GC.o)(.text+0x779): In function `GarbageCollect': : undefined reference to `markRootPtrTable' /tmp/ghc-6.6/libraries/base/libHSbase.a(Stable.o)(.text+0x360): In function `sxz_ret': : undefined reference to `hs_free_stable_ptr' /tmp/ghc-6.6/libraries/base/libHSbase.a(Typeable.o)(.text+0x2b85): In function `s4SA_ret': : undefined reference to `hs_free_stable_ptr' /tmp/ghc-6.6/libraries/base/libHSbase.a(Conc.o)(.text+0x3f7b): In function `base_GHCziConc_par_entry': : undefined reference to `newSpark' gmake[1]: *** [genapply] Error 1 gmake: *** [all] Error 1 gmake: Leaving directory `/tmp/ghc-6.6/utils' I am wondering what to try next. Could ghc-inplace on the target be crashing because of differences in say, ptr sizes on the host versus the target? Could I fool the host build into using 64 bit pointers by replacing explicit pointers with "long long" integers? Or should I try building a set of .hc files on a 64 bit linux host and use those to bootstrap the freebsd/amd64 target? Any help would be appreciated. Especially useful would be any comments on which parts of the instructions can be trusted and which may be bitrotted and needing revision. Best Wishes, Greg From kolmodin at dtek.chalmers.se Thu Mar 8 12:16:36 2007 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Thu Mar 8 12:09:36 2007 Subject: Parsing GHC Core In-Reply-To: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> Message-ID: <45F044F4.8050709@dtek.chalmers.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote: > Hi, > > I would like to parse GHC Core to an abstract syntax tree, as the old > GHC Core library used to allow the user to do. I do not want to depend > on the GHC API (too big), but don't mind depending on a small and > separately available .cabal'd package. I also don't mind copying a few > modules into my program. The types are of no interest to me, if that > makes it any easier > > Does anyone have the code/library to do this sitting around? I belive Aarne Ranta wrote a parser for some Core language of GHC 5 a couple of years ago. Um... 2003. It seems to be part of the bnfc[1] tarball as an example. Perhaps you can use that somehow? [1] http://www.cs.chalmers.se/~markus/BNFC/ Cheers, Lennart Kolmodin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF8ET04txYG4KUCuERAmmoAJ4jto4N+d9uEBhE7Z/+fofhTqGePwCgm023 dpCTk9bHmGIXVm5xYuiDQDc= =XEXw -----END PGP SIGNATURE----- From naur at post11.tele.dk Thu Mar 8 14:06:22 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Mar 8 14:00:34 2007 Subject: Parsing GHC Core In-Reply-To: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> Message-ID: <200703082006.24053.naur@post11.tele.dk> Hello, The GHC repository ghc/utils/ext-core contains a parser and an (incomplete?) interpreter, apparently for some earlier version of GHC core. Best regards Thorkil On Thursday 08 March 2007 15:58, Neil Mitchell wrote: > Hi, > > I would like to parse GHC Core to an abstract syntax tree, as the old > GHC Core library used to allow the user to do. I do not want to depend > on the GHC API (too big), but don't mind depending on a small and > separately available .cabal'd package. I also don't mind copying a few > modules into my program. The types are of no interest to me, if that > makes it any easier > > Does anyone have the code/library to do this sitting around? > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From catamorphism at gmail.com Thu Mar 8 19:34:01 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Thu Mar 8 19:26:59 2007 Subject: Parsing GHC Core In-Reply-To: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> Message-ID: <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> On 3/8/07, Neil Mitchell wrote: > Hi, > > I would like to parse GHC Core to an abstract syntax tree, as the old > GHC Core library used to allow the user to do. I do not want to depend > on the GHC API (too big), but don't mind depending on a small and > separately available .cabal'd package. I also don't mind copying a few > modules into my program. The types are of no interest to me, if that > makes it any easier > > Does anyone have the code/library to do this sitting around? Does it matter which version of GHC? As far as I know, there's no External Core parser that will work with the code emitted by -fext-core in 6.6. (Aaron Tomb and I (mostly Aaron) have been working on getting that working again.) I have a parser that works with (IIRC) GHC 6.0 somewhere, though it would take a little bit of finding. If that would be useful for you, let me know. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "In a land of quince jelly, apple butter, apricot jam, blueberry preserves, pear conserves, and lemon marmalade, you always get grape jelly." --William Least Heat-Moon From ndmitchell at gmail.com Thu Mar 8 20:41:25 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 8 20:34:21 2007 Subject: Parsing GHC Core In-Reply-To: <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> Message-ID: <404396ef0703081741lef0e347je5a03da609de736c@mail.gmail.com> Hi > Does it matter which version of GHC? Yes, 6.6 or nothing, I'm afraid. GHC 6.6 is already a dependency for another part of the tool chain, so demanding more than one GHC version is not feasible. > As far as I know, there's no > External Core parser that will work with the code emitted by > -fext-core in 6.6. That's what I thought, but I was hoping to be proven wrong. > on getting that working again.) I have a parser that works with (IIRC) > GHC 6.0 somewhere, though it would take a little bit of finding. If > that would be useful for you, let me know. I have one sitting around somewhere that works with 6.4, I think. Nothing I wrote myself, just something I managed to find online - if you want a copy I'll see if I can dig it out (it was from a while ago). Having a 6.0 parser is not much use to me, but the second you've got a 6.6 parser I'd love to hear from you! Thanks Neil From simonpj at microsoft.com Thu Mar 8 20:48:24 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 8 20:41:27 2007 Subject: Parsing GHC Core In-Reply-To: <404396ef0703081741lef0e347je5a03da609de736c@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> <404396ef0703081741lef0e347je5a03da609de736c@mail.gmail.com> Message-ID: | > on getting that working again.) I have a parser that works with (IIRC) | > GHC 6.0 somewhere, though it would take a little bit of finding. If | > that would be useful for you, let me know. | | I have one sitting around somewhere that works with 6.4, I think. | Nothing I wrote myself, just something I managed to find online - if | you want a copy I'll see if I can dig it out (it was from a while | ago). | | Having a 6.0 parser is not much use to me, but the second you've got a | 6.6 parser I'd love to hear from you! Yes, it'll be great to have External Core working again. Thanks to Kirsten and Peter for picking it up. (Peter, Kirsten, if you get stuck, I'm happy to help.) Simon From catamorphism at gmail.com Thu Mar 8 20:54:04 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Thu Mar 8 20:47:03 2007 Subject: Parsing GHC Core In-Reply-To: References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> <404396ef0703081741lef0e347je5a03da609de736c@mail.gmail.com> Message-ID: <4683d9370703081754g4b4e738chce3a79eac16d0ee8@mail.gmail.com> On 3/8/07, Simon Peyton-Jones wrote: > Yes, it'll be great to have External Core working again. Thanks to Kirsten and Peter for picking it up. > > (Peter, Kirsten, if you get stuck, I'm happy to help.) Correction -- that's Aaron, not Peter :-) At the moment we're not stuck, it's just a matter of finding time to work on it. We won't hesitate to ask if something comes up, though. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Who needs reasons when you've got the root password?"--fjw2@lehigh.edu From atomb at soe.ucsc.edu Fri Mar 9 01:58:28 2007 From: atomb at soe.ucsc.edu (Aaron Tomb) Date: Fri Mar 9 01:49:37 2007 Subject: Parsing GHC Core In-Reply-To: <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> References: <404396ef0703080658w3e86b083qfecb0a369ad5c245@mail.gmail.com> <4683d9370703081634l5175cfe1q165d7c433a5d62a5@mail.gmail.com> Message-ID: Hopefully it will be coming together soon. The last couple of weeks have been pretty hectic for me, but most of it ends tomorrow. I'm hoping to put some time into getting the code into shape this weekend. Aaron On Mar 8, 2007, at 4:34 PM, Kirsten Chevalier wrote: > On 3/8/07, Neil Mitchell wrote: >> Hi, >> >> I would like to parse GHC Core to an abstract syntax tree, as the old >> GHC Core library used to allow the user to do. I do not want to >> depend >> on the GHC API (too big), but don't mind depending on a small and >> separately available .cabal'd package. I also don't mind copying a >> few >> modules into my program. The types are of no interest to me, if that >> makes it any easier >> >> Does anyone have the code/library to do this sitting around? > > Does it matter which version of GHC? As far as I know, there's no > External Core parser that will work with the code emitted by > -fext-core in 6.6. (Aaron Tomb and I (mostly Aaron) have been working > on getting that working again.) I have a parser that works with (IIRC) > GHC 6.0 somewhere, though it would take a little bit of finding. If > that would be useful for you, let me know. > > Cheers, > Kirsten > > -- > Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, > never in doubt > "In a land of quince jelly, apple butter, apricot jam, blueberry > preserves, > pear conserves, and lemon marmalade, you always get grape jelly." > --William Least Heat-Moon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From maeder at tzi.de Fri Mar 9 07:56:59 2007 From: maeder at tzi.de (Christian Maeder) Date: Fri Mar 9 07:49:52 2007 Subject: Distributing a GHC-compiled binary for Macs (x86) In-Reply-To: <45F12699.4090608@tzi.de> References: <45F12699.4090608@tzi.de> Message-ID: <45F1599B.5020000@tzi.de> (move a discussion to glasgow-haskell-users) Macs that don't have GHC installed don't seem to have readline-5 installed, either. Therefore we've created that GNUreadline.framework (see below). However, the binary that one wants to distribute must be linked against that framework. We do this by adding linker options to ghc: -optl-F/home/maeder/Library/Frameworks -optl-framework -optlGNUreadline We have also created a binary distribution (for powerpc, though) that uses our GNUreadline.framework. For this we've changed libraries/readline/config.mk manually: LD=/usr/bin/ld -F/home/maeder/Library/Frameworks -framework GNUreadline SRC_HC_OPTS += -optc-I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers -optl-F/home/maeder/Library/Frameworks -optl-framework -optlGNUreadline SRC_HSC2HS_OPTS += -I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers The binary distribution is here: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/ghc-6.6-powerpc-apple-darwin.tar.bz2 We think, that such a GNUreadline.framework is more flexible and mac-like than installing readline-5 under /opt/local. The framework can reside under /System/Library/Frameworks but also under $HOME/Library/Frameworks. Maybe you could consider making such a distribution (that also doesn't need root permission) as well? The sources and the script to create the GNUreadline framework are included: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip Cheers Christian Christian Maeder schrieb: > Arjun Guha schrieb: >> Hi, >> >> I compiled a binary using GHC 6.6 on my Mac (specifically, using ghc >> --make). This binary seems to depend on the GNU MP framework--I >> imagine GHC uses it to implement its numeric tower. >> >> However, Macs that don't have GHC installed don't seem to have GMP, so >> I'll guess that it was installed along with the GHC binary. Is there >> any way to get around this GMP dependency? I expect the binary to be >> used on Macs that don't have GHC installed. It would be acceptable if >> I instructed Mac-users to download a binary installer for GMP, but I >> haven't been able to find one. >> >> Any hints or suggestions would be appreciated. Thanks. > > We tell our users to install a GMP.framework and a GNUreadline.framework: > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac_e.htm > > Cheers Christian From Edward.Colletta at FMR.COM Fri Mar 9 15:40:08 2007 From: Edward.Colletta at FMR.COM (Colletta, Edward) Date: Fri Mar 9 15:33:13 2007 Subject: chr and ord not in standard prelude Message-ID: <38BD853005C1DE47BAB908F2C23285550C19D6@MSGMMKCLE2WIN.DMN1.FMR.COM> When I try to use functions chr or ord, I get a not in scope error. If I ":browse Prelude" I do not see these functions. Is there another module I should load? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070309/d4c5b5f4/attachment-0001.htm From mhills at cs.uiuc.edu Fri Mar 9 15:46:13 2007 From: mhills at cs.uiuc.edu (Mark Hills) Date: Fri Mar 9 15:40:50 2007 Subject: chr and ord not in standard prelude In-Reply-To: <38BD853005C1DE47BAB908F2C23285550C19D6@MSGMMKCLE2WIN.DMN1.FMR.COM> References: <38BD853005C1DE47BAB908F2C23285550C19D6@MSGMMKCLE2WIN.DMN1.FMR.COM> Message-ID: <45F1C795.4010802@cs.uiuc.edu> It looks like these are in module Char: > ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> Char.chr 65 'A' Prelude> Char.ord 'A' 65 Colletta, Edward wrote: > > When I try to use functions chr or ord, I get a not in scope error. > If I ":browse Prelude" I do not see these functions. Is there another > module I should load? > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From stefanor at cox.net Fri Mar 9 18:17:59 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Mar 9 18:10:55 2007 Subject: chr and ord not in standard prelude In-Reply-To: <38BD853005C1DE47BAB908F2C23285550C19D6@MSGMMKCLE2WIN.DMN1.FMR.COM> References: <38BD853005C1DE47BAB908F2C23285550C19D6@MSGMMKCLE2WIN.DMN1.FMR.COM> Message-ID: <20070309231759.GA2852@localhost.localdomain> On Fri, Mar 09, 2007 at 03:40:08PM -0500, Colletta, Edward wrote: > When I try to use functions chr or ord, I get a not in scope error. > If I ":browse Prelude" I do not see these functions. Is there another > module I should load? Don't use chr and ord - they aren't polymorphic, they restrict your code to work only on Chars. Use fromEnum and toEnum (which are in the Prelude) instead. Stefan From ndmitchell at gmail.com Sat Mar 10 08:49:26 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 10 08:42:20 2007 Subject: Haskell API for memory useage Message-ID: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> Hi, Haskell has getCPUTime to get the amount of CPU Time that has been consumed, but has no equivalent for memory use. I would like to get something similar to -RTS -t, but from a Haskell program. I'm not overly fussed about what memory statistic I get, as long as it is something that corresponds in some way to the amount of memory that has been used - cells, heap size, live heap etc are all fine. So, I'm after something like: getMemoryUse :: IO Integer Is there anything I can use to do this? Thanks Neil From dons at cse.unsw.edu.au Sat Mar 10 09:00:33 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sat Mar 10 08:53:31 2007 Subject: Haskell API for memory useage In-Reply-To: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> References: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> Message-ID: <20070310140033.GA21730@cse.unsw.EDU.AU> ndmitchell: > Hi, > > Haskell has getCPUTime to get the amount of CPU Time that has been > consumed, but has no equivalent for memory use. I would like to get > something similar to -RTS -t, but from a Haskell program. I'm not > overly fussed about what memory statistic I get, as long as it is > something that corresponds in some way to the amount of memory that > has been used - cells, heap size, live heap etc are all fine. > > So, I'm after something like: getMemoryUse :: IO Integer > > Is there anything I can use to do this? > This stuff is surprisingly tricky for some reason. Have a look at the gtop (C?) lib (there's also a perl binding used for the shootout). I'm not sure why shells in general don't provide a 'memory' combinator, considering we have 'time'. -- Don From bjpop at csse.unimelb.edu.au Sat Mar 10 09:41:32 2007 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Sat Mar 10 09:34:55 2007 Subject: Haskell API for memory useage In-Reply-To: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> References: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> Message-ID: <000c01c76322$3f2e5f30$bd8b1d90$@unimelb.edu.au> I once write a little thing called HighWaterMark: http://www.cs.mu.oz.au/~bjpop/code.html It is GHC specific, and it doesn't count memory allocated by foreign stuff (ie C stack etc). I haven't tried it out on a modern GHC, so there is probably some bit rot. Cheers, Bernie. > -----Original Message----- > From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > haskell-users-bounces@haskell.org] On Behalf Of Neil Mitchell > Sent: 10 March 2007 13:49 > To: GHC Users > Subject: Haskell API for memory useage > > Hi, > > Haskell has getCPUTime to get the amount of CPU Time that has been > consumed, but has no equivalent for memory use. I would like to get > something similar to -RTS -t, but from a Haskell program. I'm not > overly fussed about what memory statistic I get, as long as it is > something that corresponds in some way to the amount of memory that > has been used - cells, heap size, live heap etc are all fine. > > So, I'm after something like: getMemoryUse :: IO Integer > > Is there anything I can use to do this? > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ndmitchell at gmail.com Sat Mar 10 09:42:32 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 10 09:35:25 2007 Subject: Haskell API for memory useage In-Reply-To: <20070310140033.GA21730@cse.unsw.EDU.AU> References: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> <20070310140033.GA21730@cse.unsw.EDU.AU> Message-ID: <404396ef0703100642i40d9debbreeee3da850710670@mail.gmail.com> Hi Donald, > This stuff is surprisingly tricky for some reason. Have a look at the > gtop (C?) lib (there's also a perl binding used for the shootout). > > I'm not sure why shells in general don't provide a 'memory' combinator, > considering we have 'time'. I don't want to do this in the shell, but if I did "-RTS -t" already dumps it to a file and I can get the answer from there. The example I want is: do x <- getCPUTime compute y <- getCPUTime z <- getMemoryUse print "Your computation took {y-x}ms and {z}kb" Thanks Neil From ndmitchell at gmail.com Sat Mar 10 10:10:52 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 10 10:03:44 2007 Subject: Haskell API for memory useage In-Reply-To: <000c01c76322$3f2e5f30$bd8b1d90$@unimelb.edu.au> References: <404396ef0703100549y2e25bb76ob245caef6076ffcc@mail.gmail.com> <000c01c76322$3f2e5f30$bd8b1d90$@unimelb.edu.au> Message-ID: <404396ef0703100710t7287e741v496143810c33562b@mail.gmail.com> Hi Bernie, > I once write a little thing called HighWaterMark: > > http://www.cs.mu.oz.au/~bjpop/code.html > > It is GHC specific, and it doesn't count memory allocated by foreign stuff > (ie C stack etc). That's great, a few more things and it would be perfect: * darcs repo * cabal based * working with GHC 6.6 (if it doesn't already) * portable to hugs, just returning Nothing on hugs and Just Integer on GHC is perfect Thanks Neil From arjun at cs.brown.edu Sun Mar 11 14:33:21 2007 From: arjun at cs.brown.edu (Arjun Guha) Date: Sun Mar 11 14:26:12 2007 Subject: Fwd: [Haskell-cafe] Re: Distributing a GHC-compiled binary for Macs (x86) In-Reply-To: References: <45F12699.4090608@tzi.de> <45F1599B.5020000@tzi.de> Message-ID: My apologies for duplicates, if any. I sent it first from the wrong address ---------- Forwarded message ---------- Thanks for the info. The solution I plan to adopt is as follows. I can create a tarball of the /Library/Frameworks/GMP.framework folder on my Intel-Mac that has GHC 6.6 installed. I can ask users of my application to download said tarball and install it in /Library/Frameworks or ~/Library/Frameworks. I tested it on one Mac that didn't have GHC, and it worked. I'll try it on a few others before declaring that it does work. On a slightly related note, it appears that GHC-compiled Windows programs either don't use GMP or have it statically embedded. I ran a Windows binary of the same program on a machine that almost certainly doesn't have GMP installed and it worked. Any confirmation would be appreciated. Thanks for the help. Arjun On 3/9/07, Christian Maeder wrote: > (move a discussion to glasgow-haskell-users) > > Macs that don't have GHC installed don't seem to have readline-5 > installed, either. > > Therefore we've created that GNUreadline.framework (see below). However, > the binary that one wants to distribute must be linked against that > framework. We do this by adding linker options to ghc: > > -optl-F/home/maeder/Library/Frameworks -optl-framework -optlGNUreadline > > We have also created a binary distribution (for powerpc, though) that > uses our GNUreadline.framework. For this we've changed > libraries/readline/config.mk manually: > > LD=/usr/bin/ld -F/home/maeder/Library/Frameworks -framework GNUreadline > SRC_HC_OPTS += > -optc-I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers > -optl-F/home/maeder/Library/Frameworks -optl-framework -optlGNUreadline > SRC_HSC2HS_OPTS += > -I/home/maeder/Library/Frameworks/GNUreadline.framework/Headers > > The binary distribution is here: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/ghc-6.6-powerpc-apple-darwin.tar.bz2 > > We think, that such a GNUreadline.framework is more flexible and > mac-like than installing readline-5 under /opt/local. The framework can > reside under /System/Library/Frameworks but also under > $HOME/Library/Frameworks. > > Maybe you could consider making such a distribution (that also doesn't > need root permission) as well? > > The sources and the script to create the GNUreadline framework are included: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip > > Cheers Christian > > Christian Maeder schrieb: > > Arjun Guha schrieb: > >> Hi, > >> > >> I compiled a binary using GHC 6.6 on my Mac (specifically, using ghc > >> --make). This binary seems to depend on the GNU MP framework--I > >> imagine GHC uses it to implement its numeric tower. > >> > >> However, Macs that don't have GHC installed don't seem to have GMP, so > >> I'll guess that it was installed along with the GHC binary. Is there > >> any way to get around this GMP dependency? I expect the binary to be > >> used on Macs that don't have GHC installed. It would be acceptable if > >> I instructed Mac-users to download a binary installer for GMP, but I > >> haven't been able to find one. > >> > >> Any hints or suggestions would be appreciated. Thanks. > > > > We tell our users to install a GMP.framework and a GNUreadline.framework: > > > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac_e.htm > > > > Cheers Christian > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From trebla at vex.net Mon Mar 12 16:36:07 2007 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon Mar 12 16:36:14 2007 Subject: slight difference in strictness between -O0 and -O Message-ID: <45F5B9B7.3030105@vex.net> main = print (map (const 'x') (take 1 (undefined:undefined))) In ghci, or with ghc -O0, this produces "x". With ghc -O, this produces Prelude.undefined. But hey, please don't sweat too much on it! I bet it is a rather pathological case. From catamorphism at gmail.com Mon Mar 12 17:08:00 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Mar 12 17:08:02 2007 Subject: slight difference in strictness between -O0 and -O In-Reply-To: <45F5B9B7.3030105@vex.net> References: <45F5B9B7.3030105@vex.net> Message-ID: <4683d9370703121408i34cc5a98sddabd9f6a2c77195@mail.gmail.com> On 3/12/07, Albert Y. C. Lai wrote: > main = print (map (const 'x') (take 1 (undefined:undefined))) > > In ghci, or with ghc -O0, this produces "x". > With ghc -O, this produces Prelude.undefined. > What version of ghc? Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "make them believe, if not in magic, in money well spent" -- Annie Gallup From catamorphism at gmail.com Mon Mar 12 17:53:47 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Mon Mar 12 17:53:54 2007 Subject: slight difference in strictness between -O0 and -O In-Reply-To: <4683d9370703121408i34cc5a98sddabd9f6a2c77195@mail.gmail.com> References: <45F5B9B7.3030105@vex.net> <4683d9370703121408i34cc5a98sddabd9f6a2c77195@mail.gmail.com> Message-ID: <4683d9370703121453j435450bev50382f570e770372@mail.gmail.com> On 3/12/07, Kirsten Chevalier wrote: > On 3/12/07, Albert Y. C. Lai wrote: > > main = print (map (const 'x') (take 1 (undefined:undefined))) > > > > In ghci, or with ghc -O0, this produces "x". > > With ghc -O, this produces Prelude.undefined. > > > > What version of ghc? > I was curious, so I checked this against ghc 6.6. Indeed, it exhibits the behavior Albert describes above. Same goes for the HEAD. In ghc 6.4.2, however, the program prints "x" whether compiled with -O or -O0. This does seem like a bug to me. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Live fast, love hard, and wear corrective lenses if you need them." --Webb Wilder From catamorphism at gmail.com Tue Mar 13 05:20:35 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Tue Mar 13 05:20:37 2007 Subject: slight difference in strictness between -O0 and -O In-Reply-To: <4683d9370703121453j435450bev50382f570e770372@mail.gmail.com> References: <45F5B9B7.3030105@vex.net> <4683d9370703121408i34cc5a98sddabd9f6a2c77195@mail.gmail.com> <4683d9370703121453j435450bev50382f570e770372@mail.gmail.com> Message-ID: <4683d9370703130220k6b646245sfd38fe81beee6a74@mail.gmail.com> On 3/12/07, Kirsten Chevalier wrote: > On 3/12/07, Kirsten Chevalier wrote: > > On 3/12/07, Albert Y. C. Lai wrote: > > > main = print (map (const 'x') (take 1 (undefined: