Re: smp and make
On Wed, Jun 16, 1999 at 15:57:00 -0400, Kirstin S. Reese wrote: when building ghc on an smp machine, gmake arguments of -j ?? are overridden by -rj 1, in an unneccesary fashion. However, I cannot find where this is defined for MFLAGS. Any one know about this? Hi! Actually, this is normal behaviour of make (see: make.info: "Communicating Options to a Sub-`make'"). If you call the toplevel make with option "-jval", all sub-make's get "-rj 1", only. You could try just "-j", this is passed along to all sub-makes without change, but the number of parallel jobs isn't limited... useless, unless you do have a *really* big machine with lots of processors and mem :-) BTW: (1) you could also try to use "-j -lmax-load", which limits the number of jobs according to the load value specified, but this isn't a real solution, try and you'll see why... (2) I modified ghc/Makefile to add "-j2" explicitly to MFLAGS, but then, after some time, the ghc's turned into zombies... (same with (1))... strange... I didn't figure out why this happened, can somebody test this? Cheers, Michael -- XXXVII: Ninety percent of the time things will turn out worse than you expect. The other 10 percent of the time you had no right to expect so much.
Re: PATCH: unlit.c
Kevin Atkinson wrote: I discovered that my problem was that unlit was crashing because stdout does not like to be closed. Anyway this patch fixes the problem. I will let you know how things go now that I solved that problem. Next time I will actually take a look at the core file. It would of saved my and Kirstin S. Reese a lot of trouble. It turns out that unlit.c was the only think I needed to modify in order to get the CVS version (June 27) to compile with the ghc 4.02 linux binaries. The fflush in RtsStartup had nothing to do with it. Not being able to close stdout is defiantly a bug as the glibc info pages has an example in which it does that very thing. However considering that the libc distributed with Redhat 6.0 has this problem I strongly recommend you apply my patch as it does not do any real harm. Special thanks to Kirstin S. Reese for helping me with this problem. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
RE: PATCH: unlit.c
It turns out that unlit.c was the only think I needed to modify in order to get the CVS version (June 27) to compile with the ghc 4.02 linux binaries. The fflush in RtsStartup had nothing to do with it. Not being able to close stdout is defiantly a bug as the glibc info pages has an example in which it does that very thing. However considering that the libc distributed with Redhat 6.0 has this problem I strongly recommend you apply my patch as it does not do any real harm. Special thanks to Kirstin S. Reese for helping me with this problem. Thanks Kevin - I've applied your patch. Should be in tomorrow's CVS. Cheers, Simon
Re: PATCH: unlit.c
Simon Marlow wrote: Thanks Kevin - I've applied your patch. Should be in tomorrow's CVS. Your welcome. BTW: the ghc perl script could defiantly be dive better error messages. Like saying which program actually crashed instead of just returning nothing but a bad return value. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
RE: Parser or Renamer error
While trying to compile fudgets with my newest ghc build (CVS, checked out on Mon Jun 21, about 18:00 GMT), the following error occurred: Font.hs:182: Data constructor not in scope: `LA' Font.hs:182: Variable not in scope: `.!' Font.hs:182: Data constructor not in scope: `LA' Font.hs:182: Variable not in scope: `.!' Line 182 is: Arr (b1,b2) a ! i = (a LA.! dix (ii-fromEnum b1)) LA.! ii where ii = fromEnum i and in the beginning of that file, there's a qualified import: import qualified Array as LA I.e. either the parser or the renamer doesn't recognize qualified operators. It's actually a qualified "specialop" - a case that the new lexer didn't handle properly. Anyway I've fixed it now, tomorrow's CVS sources will have the fix. Thanks for the report. Cheers, Simon
Parser or Renamer error
Hello! While trying to compile fudgets with my newest ghc build (CVS, checked out on Mon Jun 21, about 18:00 GMT), the following error occurred: Font.hs:182: Data constructor not in scope: `LA' Font.hs:182: Variable not in scope: `.!' Font.hs:182: Data constructor not in scope: `LA' Font.hs:182: Variable not in scope: `.!' Line 182 is: Arr (b1,b2) a ! i = (a LA.! dix (ii-fromEnum b1)) LA.! ii where ii = fromEnum i and in the beginning of that file, there's a qualified import: import qualified Array as LA I.e. either the parser or the renamer doesn't recognize qualified operators. Regards, Hannah. PS: Just tested some more: This works: import qualified Prelude as P main = P.print (1 P.+ 2) This does NOT work: module Y where import qualified Array as A acc a x = a A.! x It DOES work with ghc 3.02 and with an older post-4.02-CVS checkout.
CVS Version of GHC has problems finding Instances
It seams that the CVS version of ghc (June 27) has problems finding instances. See the attached file Main.hs in a message I just sent to the Haskell mailing list with a subject of "Second attempt for an STL like library for Haskell". If I don't import Eval it complains of not being able to find an instance of Monad for Eval.Eval. If this is not a known problem I have some additional examples I can provide. Just let me known. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
