- Glasgow-haskell-users

ghc-6.4.1-july-12 test is all right
by Serge D. Mechveliani 21 Jul '05

21 Jul '05

I wrote today on testing of ghc-6.4.1-July-12-2005 > 3. Memory test with loading to ghci the whole DoCon test > (DoCon compiled with -O, tests compiled with -Onot) > and performing it: > 6.4.1-July-12 needs the minimum of 18 Mb, > 6.4, 6.4.1-June-14 need 10 Mb. > > -- ? This was some mistake of mine, probably. Now, I repeated the docon `make', and this test needs again 10 Mb, as in 6.4. Compiling the test part with -0 increases the needed memory to 14 Mb. I wonder, how could it appear the minimum of 18 Mb in previous session. So, all my tests for ghc-6.4.1-July-12 show almost the same (+- 3%) results as for ghc-6.4 and 5.02. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

testing 6.4.1-July-12
by Serge D. Mechveliani 21 Jul '05

21 Jul '05

This is on Simon Marlow's recent requests for the ghc-6.4.1-pre testing and benchmarking. I have installed ghc-6.4.1-July-12-2005 on Linux Debian by making it with ghc-6.4.1-June-14. 1. A simple test with list sorting and such, shows almost the same result as in ghc-6.4 and as in 5.02, for the performance, and minimal needed memory too. 2. The tests of ghc-6.4.1-July-12 on dumatel-1.03-pre (compex symbolic computations in prover) and docon-2.09-pre (complex computer algebra) look all right. I tested separately the performance, and minimal needed memory, for the tasks of 3-variable polynomial GCD and bi-variable factoring. It shows almost the same as in 6.4 and 5.02. 3. Memory test with loading to ghci the whole DoCon test (DoCon compiled with -O, tests compiled with -Onot) and performing it: 6.4.1-July-12 needs the minimum of 18 Mb, 6.4, 6.4.1-June-14 need 10 Mb. -- ? I am not very sure about 6.4 and 6.4.1-June-14, this may be a bug in old DoCon documenation. If the GHC developers need to repeat and make sure about this, let them ask me, and I would send them docon-2.09-pre, with description of what precisely to apply. Personally, I would not like now to re-install 6.4. On the other hand, this 1.8 factor difference looks suspicious, it worths to make sure. 4. A problem with the package clash in self-make. Now, Simon says, it will be fixed. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: GADTs and pedagogy was Re: GADTs and fundeps
by Simon Peyton-Jones 21 Jul '05

21 Jul '05

| > You mean, if the data type being defined doesn't actually use the | > generality of GADTs, allow GADT syntax, and deriving() too? | | Yes, that would be very nice for the HaskellDemo and new users. | I'd definitely switch all of my non-GADT datatypes to use that. I finally got around to doing this; turned out to be trivial. Record syntax aside, you can now declare any Haskell-98 data type using the GADT-style where-clause syntax, including 'deriving'. Simon

1 0

RE: GHC 6.4.1 for Solaris
by Simon Marlow 21 Jul '05

21 Jul '05

On 20 July 2005 16:31, herington, dean wrote: > I'm trying to deploy GHC 6.4.1 on a Solaris 5.9 machine. I installed > the binary release (in-place) from > <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2> > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2 > <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2.tar.bz2> > .tar.bz2, but it needs libreadline.so.5, libncurses.so.5, and > libgmp.so.3, which my machine lacks. How should I obtain these > shared libraries? On Solaris, the only way is to download, build and install each one. Cheers, Simon

1 0

Functional Dependencies
by Dirk Reckmann 21 Jul '05

21 Jul '05

Hello everybody! I wanted to have some fun with functional dependencies (see http://www.cs.chalmers.se/~hallgren/Papers/wm01.html) and tried some examples from this paper as well as some own experiments. The idea is to use the type checker for computations by "abuse" of type classes with functional dependencies. The example in the attached file is taken from the above paper. Due to the functional dependencies, I expected the type of seven to be uniquely determined to be (Succ (Succ (Succ ...))), i. e. seven, but ghc (version 6.4) gives me following error message: Add.hs:14:0: Couldn't match the rigid variable `a' against `Succ s' `a' is bound by the type signature for `seven' Expected type: Succ s Inferred type: a When using functional dependencies to combine Add (Succ n) m (Succ s), arising from the instance declaration at Add.hs:11:0 Add (Succ (Succ (Succ Zero))) (Succ (Succ (Succ (Succ Zero)))) a, arising from the type signature for `seven' at Add.hs:13:0-77 When generalising the type(s) for `seven' However, using the definition of Add to define Fibonacci numbers does work, and a similar function declaration can be used to compute numbers by the type checker. The same definition of Add works in Hugs... So, is this a bug in ghc, or am I doing something wrong? Thanks in advance, Dirk Reckmann

1 0

GHC 6.4.1 for Solaris
by herington, dean 20 Jul '05

20 Jul '05

I'm trying to deploy GHC 6.4.1 on a Solaris 5.9 machine. I installed the binary release (in-place) from <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2> <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2.ta r.bz2> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2.tar .bz2, but it needs libreadline.so.5, libncurses.so.5, and libgmp.so.3, which my machine lacks. How should I obtain these shared libraries?

1 0

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 20 Jul '05

20 Jul '05

On 19 July 2005 17:17, Peter A Jonsson wrote: > Perl 5.6.0 seems to be released 2000-Mar-22, demanding that people who > build ghc have a perl that is no older than 5 years might be a > reasonable first step? Ok, done. >>> Needed a patch to build NCG. I tried to preserve as much of the >>> previous structure in order to avoid introducing bugs, but I wasn't >>> entirely successfull. I've attached the patch and would appreciate >>> if someone could glance over it looking for obvious errors. >> >> There are never any "obvious" errors in the NCG :-) I did glance >> over it, and it mostly looks like a straightforward change over to >> Cmm. Since your patch only touches code inside #ifdef >> sparc_TARGET_ARCH, which is currently broken anyway, I'm inclined to >> just merge it as-is. > > That sounds good to me, a smaller diff would hopefully make my life > easier. > > About the lack of sparc-support - is the problem that no active > developers have access to sparc-machines any longer or is there simply > no interest in sparc? If it is the former, contact me off list and > I'll try to help out. I can get access to a machine, but I don't have a lot of time to maintain the Sparc port (and it's always harder to fix things remotely). We've been advertising for a Sparc guru for a while, but no takers so far. > The stack-check sequence you are referring to, is that in Cmm > represented by "if ((Sp + -12) < SpLim) goto <label>"? If that is the > case, I can't find any errors in the asm produced. > > Any hints that would ease the burden of reading big chunks of > assembler would be much appreciated! Compiling programs with -debug is a good first step - that links in the debugging version of the RTS, with lots of ASSERTs and support for the debugging output flags (-Dxxx, -Ds and -DS are my favourites). Cheers, Simon

1 0

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 19 Jul '05

19 Jul '05

On 18 July 2005 12:01, Peter A Jonsson wrote: > Ok, I gave it a spin, that was "interesting". Things I wrote down > while looking at it that might be of interest to others: > > I tried to build with gcc 3.4.1 and it didn't work very well. Found a > mail from November 2004 (<Message-Id: 419B599C.2020204(a)tzi.de>) which > had the same problem. In a reply you said that it was the JMP_-macro > in TailCall.h and changing the cast would make the warning go away. It > did, however I think I messed up with something else since it made > other problems appear. I reverted my changes and switched gcc > instead. > > I had perl 5.005_03 first in my path, that made the splitter not > work. Changing to a newer version made it work. Maybe a test could be > added to configure to avoid too old versions of perl? I'll be happy to - but I don't know exactly what version of Perl we require. Any clues? What went wrong with the splitter? > All those "Bad eta expand" looks slightly scary when building for the > first time. Found a mail from Simon Peyton Jones which made me less > worried. Maybe it could be documented that those are expected in the > building guide? Ok, we'll look into sqashing those. > The GHC commentary was written for pre-CMM NCG. I tried patching that > while going through the code but I just ended up butchering the > document to basically contain no information whatsoever. I'm not sure > it's helpful at all in its current shape though, unfortunately. True - I'd love to update this, but quite gigantic. A shame that Julian put so much effort into writing this doc, and it's now mostly out of date (and I don't think I even referred to it once when converting the NCG to Cmm :-(). > Needed a patch to build NCG. I tried to preserve as much of the > previous structure in order to avoid introducing bugs, but I wasn't > entirely successfull. I've attached the patch and would appreciate if > someone could glance over it looking for obvious errors. There are never any "obvious" errors in the NCG :-) I did glance over it, and it mostly looks like a straightforward change over to Cmm. Since your patch only touches code inside #ifdef sparc_TARGET_ARCH, which is currently broken anyway, I'm inclined to just merge it as-is. > With this patch a bunch of array tests with WAY=normal fails, all in > the same way: > > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. Best guess is the code generated for a stack-check sequence is incorrect. Match up the assembly file (use -keep-s-file) with the Cmm (-ddump-opt-cmm) and see if you can spot the incorrect code. I can provide some gdb tips - let me know if you need more help. Also, the codeGen tests are probably a better place to start (tests/ghc-regress/codeGen/should_run). Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 19 Jul '05

19 Jul '05

On 18 July 2005 17:29, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> That's the general rule, anyway. It would be an interesting >> exercise to specify the GHC command-line semantics, or better still, >> redesign it :) > > I for one would find it quite helpful to see a warning line for each > overriden option, if without so much of an explanation -- a "red > light" to let me know something might be wrong. I think there's a difference of philosophy here: overriding options is considered normal usage on the GHC command line. We expect to be able to do things like "make EXTRA_HC_OPTS=-Onot" to turn off optimisation, for example - we don't want this usage to generate a warning for every compilation. Every flag you specify on the command line is in effect overriding the default. We often override global defaults by putting pragmas in source files. e.g. you wouldn't want a warning for putting {-# OPTIONS -fno-warn-overlapping-patterns #-} in a source file, despite the fact that this overrides -Wall on the command line. I think there's a case for warnings in some cases (e.g. -keep-hc-files vs. -fasm might warrant a warning), but not in general. Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 18 July 2005 16:03, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> Two reasons: one, -O implies -fvia-C and two, -keep-hc-files also >> implies -fvia-C (because otherwise you don't get any .hc files). >> You'll need to modify the definition of GhcLibHcOpts in build.mk to >> put -fasm after -O, and also to remove -keep-hc-files. > > I'll try this tonight, thanks. > > BTW, am I the only one to find it alarming that GHC would allow > conflicting options to override one another without any warning? :) The GHC command-line isn't declarative, it's imperative. Options are processed left-to-right. That's the general rule, anyway. It would be an interesting exercise to specify the GHC command-line semantics, or better still, redesign it :) Cheers, Simon

2 1