October 2001 - Glasgow-haskell-users

ghc-5.0.2 for RedHat 7.x
by Chris Dornan 29 Oct '01

29 Oct '01

> I am trying to install ghc-5.02 on an NFS partition for use > with RedHad 7.1. The make in-place scheme with the binary > tar balls (as supplied for RedHat 6.2) work very well for this. > Does anyone know of such a tar ball for RedHat 7.1 or should I > be building from source, or can I adapt the RPM packages to put > things where I want them? To answer my own question, the only thing that seems to be stopping from using the RedHat-6.2 distribution on a RedHat 7.1 machine is libreadline.so, it have been changed from .so.3 to .so.4. However, if I create a symbolic link from one to the other (as suggested by the GHC Mini FAQ for SUSE systems) then it appears to work fine. In summary to get the ghc-5.00.2 binary tar ball to work on a RedHat 7.1 system create a symbolic link from libreadline.so.3, in a directory on $LD_LIBRARY_PATH to /usr/lib/libreadline.so.4 and it all seems to work fine. How easy would it be to use libreadline.a in making up the GHC distribution? (GHC implementers: ghc is a very fine system; thanks.) Chris

1 0

Re: ghc --make feature request
by cwitty＠newtonlabs.com 29 Oct '01

29 Oct '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > > I've seen unexpected compiles using ghc --make. I've got a system > > with modules A, B, and C; A depends on B and B depends on C. I've > > seen the following sequence of events: > > > > I change C > > ghc --make A compiles C, B, and A > > I change A > > ghc --make A skips C and compiles B and A > > > > I don't know of any reason why it would have compiled B in the second > > case. > > > > If this is not a known bug, I can try to reproduce it and submit a > > formal bug report. By the way, a quick try at reproducing this bug -- with what I remember of the sequence of events that caused it -- didn't work; things proceeded as they should have. > From your bug report on SourceForge, it looks like GHC has inferred > the wrong dependency graph for your program. It appears that > Point.lhs doesn't depend on GtkExtra, but nevertheless GHC has > decided to compile GtkExtra before Point, but after the other > dependencies of Point, which would seem to indicate that it thinks > Point depends on GtkExtra. > > If you do a 'ghc --make Point.lhs' (with whatever other options you > need), does it try to compile GtkExtra? No. Carl Witty

1 0

RE: ghc --make feature request
by Simon Marlow 29 Oct '01

29 Oct '01

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > GHC actually has rather sophisticated recompilation checking which > > goes beyond just checking whether the interface changed - it keeps > > version information for each entity exported by a module and only > > recompiles if any of the entities actually used by the module have > > changed (this is described in the user's guide under the section on > > recompilation checking). > > I've seen unexpected compiles using ghc --make. I've got a system > with modules A, B, and C; A depends on B and B depends on C. I've > seen the following sequence of events: > > I change C > ghc --make A compiles C, B, and A > I change A > ghc --make A skips C and compiles B and A > > I don't know of any reason why it would have compiled B in the second > case. > > If this is not a known bug, I can try to reproduce it and submit a > formal bug report. >From your bug report on SourceForge, it looks like GHC has inferred the wrong dependency graph for your program. It appears that Point.lhs doesn't depend on GtkExtra, but nevertheless GHC has decided to compile GtkExtra before Point, but after the other dependencies of Point, which would seem to indicate that it thinks Point depends on GtkExtra. If you do a 'ghc --make Point.lhs' (with whatever other options you need), does it try to compile GtkExtra? I tried a small example with similar module structure to your setup, but couldn't reproduce the bug. Cheers, Simon

1 0

RE: ghc compiled program crashes
by Simon Marlow 29 Oct '01

29 Oct '01

> from time to time ghc compiled programs simply crash on > my windows2000 without any meaningfull error message. I guess > this has something to do with storage management (I vaguely > remember having read something about errors durcing gc on this > list, but did not find the corresponding posts in the archive). We need more info, in particular an example of a program that crashes. Does it crash in the same way every time? Does it depend on what GC options you use? Cheers, Simon

1 0

test
by Eray Ozkural 29 Oct '01

29 Oct '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 test! - -- Eray Ozkural (exa) <erayo(a)cs.bilkent.edu.tr> Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE73XOzfAeuFodNU5wRAt2mAJ9fmzCmrO5hLN9x2UJtVDLiH/6+9gCeNMks I2r1Ts1IPwh37u01s5p64tg= =iHjs -----END PGP SIGNATURE-----

1 0

RE: Existential Typing (was Multi-parameter OOP)
by Simon Peyton-Jones 29 Oct '01

29 Oct '01

| If GHC had true existential typing, as opposed to just | existential datatypes, | you could reasonably code what I think you want like this: | | class A a where | basicA :: Bool | nextA :: a -> (EX a'. A a' => a') | basicA = True | nextA = id Curiously enough, this thread intersects with the "higher-ranked types" thread on the Haskell list. If I do implement the Odersky/Laufer higher-ranked types inference mechanism, then I'll also allow existentials in arbitrary positions. The elimination of "stupid" existential wrapper constructors is discussed in a bit more detail in the paper Mark and I wrote recently: First class modules for Haskell http://research.microsoft.com/~simonpj/papers/first-class-modules/index. htm Simon

2 1

ghc-5.0.2 for RedHat 7.x
by Chris Dornan 29 Oct '01

29 Oct '01

Hi, I am trying to install ghc-5.02 on an NFS partition for use with RedHad 7.1. The make in-place scheme with the binary tar balls (as supplied for RedHat 6.2) work very well for this. Does anyone know of such a tar ball for RedHat 7.1 or should I be building from source, or can I adapt the RPM packages to put things where I want them? Cheers, Chris

1 0

RE: [nhc-bugs] confhc does not recognize ghc 5.*
by Simon Marlow 29 Oct '01

29 Oct '01

> Here is the essential part of the patch: > > - GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed > 's/^libdir=.$.*$./\1/'` > + GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed > 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` > > However, this does not work on my (Slackware Linux) machine. In the > driver script for ghc-5.02, I see the following two lines: > > libdir='/usr/malcolm/local/lib/ghc-5.02' > TOPDIROPT="-B$libdir"; > > which means that the original confhc gives the correct path > (/usr/malcolm/local/lib/ghc-5.02), but the patched confhc gives an > incorrect path symbol ($libdir). > > Can someone at ghc central confirm whether this part of the ghc-5.02 > driver script differs, depending on package and platform? And if so, > what is the best way to detect which variation applies? It differs depending on whether you installed GHC from a binary distribution, via make install, or from an RPM. I've just added the --print-libdir option to GHC, and I'll try to sneak it into 5.02.1. Cheers, Simon

1 0

RE: GHC Installation Location
by Simon Marlow 29 Oct '01

29 Oct '01

> On Thu, Oct 25, 2001 at 03:18:33 -0700, Ashley Yakeley wrote: > > At 2001-10-25 03:01, Simon Marlow wrote: > > > > >I've wondered at various times in the past whether there > ought to be a > > >link from /usr/local/includes/ghc to > /usr/local/lib/ghc-5.02/includes. > > > > Won't help, my GHC is installed at /usr/lib/ghc-5.02/, > exactly where the > > Debian package put it. And now that location is hard-coded > in my Makefile. > > What about (finally!) adding the `--print-include-path' and > `--print-library-path' switches to ghc? That would be a clean > solution, IMO. > > IIRC, this has been asked for several times in the past, but was never > implemented. In 5.00.X you could say 'ghc-pkg --show-package=std --field=library_dirs' but now in 5.02 this just says "$libdir" because we made the package.conf file independent of the install location to solve some problems with installation on Windows. The value of $libdir (aka $topdir) is passed to GHC using the -B<dir> option, which on Unix is hardwired into the shell wrapper script 'ghc'. So we should have an option like '--print-libdir' to get at the value of $libdir, and then you can find out the locations of the actual libraries and include files by interrogating ghc-pkg. ok? Cheers, Simon

1 0

RE: ghc --make feature request
by Simon Marlow 29 Oct '01

29 Oct '01

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > GHC actually has rather sophisticated recompilation checking which > > goes beyond just checking whether the interface changed - it keeps > > version information for each entity exported by a module and only > > recompiles if any of the entities actually used by the module have > > changed (this is described in the user's guide under the section on > > recompilation checking). > > I've seen unexpected compiles using ghc --make. I've got a system > with modules A, B, and C; A depends on B and B depends on C. I've > seen the following sequence of events: > > I change C > ghc --make A compiles C, B, and A > I change A > ghc --make A skips C and compiles B and A > > I don't know of any reason why it would have compiled B in the second > case. > > If this is not a known bug, I can try to reproduce it and submit a > formal bug report. It's not a known bug, although we have encountered problems of this kind in the past. Thanks for the report, we'll look into it. Cheers, Simon

1 0