April 2002 - Glasgow-haskell-users

RE: GHCi and -O [was: Re: ANNOUNCE: GHC 5.02.3 released]
by Simon Marlow 10 Apr '02

10 Apr '02

> This made me think about using *.o-files in GHCi generated w/ 'ghc > -O2'. My GHCi (currently 5.00.2) states: > > --- snip --- > warning: -O conflicts with --interactive; -O turned off. > --- snap --- > > if I pass -O2 to ghci. > > Additionally, I recall some core-dumps or having ghci sometimes report > missing symbols if using some modules compiled w/ optimization. > > So, is GHCi supposed to work w/ optimized modules after all? Sure, GHCi is supposed to be able to load optimised object code just as well as non-optimised object code. If it doesn't, this is a bug. Cheers, Simon

2 1

RE: Fundep/Existential Types in 5.03
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-09 20:02, I wrote: >Does anyone even know of a workaround? Given this, find an implementation >of 'f' that retrieves the contents of its 'D' argument: > > class C a b | a -> b > > data D a = forall b. (C a b) => MkD b > > f :: (C a b) => D a -> b > -- f (MkD b) = b won't compile > >It's very annoying if it can't be done. Oh, I suppose I can always do this: data D a b = MkD b ...so perhaps in all fairness it's not quite so annoying. -- Ashley Yakeley, Seattle WA

1 0

RE: Fundep/Existential Types in 5.03
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-08 04:14, Simon Peyton-Jones wrote: >I don't know how to make existentials "know" about functional >dependencies. Existentials are not the only things that don't "know" about functional dependencies. This for instance does not compile: class C a b | a -> b g :: (C a b,C a b') => b -> b' g x = x I submit that it should, even if it's bad style to write the type of 'g' like that. This may seem a pointless case, given that one can easily rewrite the type to tell GHC what it can't figure out for itself (that b and b' are the same), but I suspect that it's the same principle as the existential datatype case below, where there doesn't appear to be a workaround. > In the type system that GHC implements, your >example fails, and I don't see any meaningful way to make it >succeed. But maybe someone else does. Does anyone even know of a workaround? Given this, find an implementation of 'f' that retrieves the contents of its 'D' argument: class C a b | a -> b data D a = forall b. (C a b) => MkD b f :: (C a b) => D a -> b -- f (MkD b) = b won't compile It's very annoying if it can't be done. -- Ashley Yakeley, Seattle WA

1 0

ANNOUNCE: GHC 5.02.3 released
by Simon Marlow 09 Apr '02

09 Apr '02

The (Interactive) Glasgow Haskell Compiler -- version 5.02.3 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.02.3. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris and Win32 are also available (or will appear shortly). Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.02.3 ====================== Some important bugfixes: - now works with gcc 3.x - works with newer glibc releases on Linux - loading parsers generated by Happy with the -ag flags into GHCi now works - fix for excessive recompilation when using --make - tryTakeMVar now works - fix some problems with the dynamic linker when loading C libraries into GHCi (using Gtk+HS from GHCi should now work). and various other minor fixes. NOTE: object files created by this vesrion of GHC may be incompatible with object files created by older versions of GHC, so be sure to recompile any pre-compiled libraries you may have lying around. How to get it =============== The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =============================== Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ===================== To compile programs with GHC, you need a machine with 64+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists =============== We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

6 5

RE: ghc 5.02.2 FFI question
by Simon Marlow 09 Apr '02

09 Apr '02

Hi Bernie, Thanks for a very well researched bug report. I've looked into it, and there is indeed a space leak (well, two in fact). The reason I didn't notice before was because I was looking at the heap stats rather than using top; one of the leaks was with memory from malloc(), and the other was memory obtained from our own arena allocator. > My motivation is debugging. I was trying to implement a > similar interface > to the HugsInternals one. Ah yes, I'd forgotten you were working on this. > If I compile the program so that it does not call C > (by modifying the definition of main so that it uses callLeak') > then this is what top gives over 30 second samples: > > SIZE RSS TIME > -------------- > 1692 1692 0:00 > 1704 1704 0:30 > 1720 1720 1:00 > 1736 1736 1:30 > 1752 1752 2:00 > 1764 1764 2:30 > > The process is still growing, but very slowly. I wouldn't expect > it to grow at all, but I don't know the memory management of > ghc well enough to be sure. Ok, the first space leak was in the stable pointer table, as you noticed. It wasn't a bug as such, but we were waiting for a GC before freeing entries in the stable pointer table (due to interactions with StableNames), and in the case of your example it was a *long* time between generation 1 GCs, which meant the stable pointer table grows in the meantime. This one is easily fixed. The other leak was in our hash table implementation - I changed it to use our arena allocator recently (for speed), and in the process removed some of the recycling of hash table cells that was happening, so if entries are repeatedly added and removed from the table then it would grow without bound until the whole table is freed. Creating/freeing a stable pointer does exactly this, with the result that the stable pointer hash table was leaking. I've changed it back to the old malloc/free version (that'll teach me to fiddle with working code ;-). The reason the pure Haskell version was leaking less is perhaps because major garbage collections were happening more often, but I didn't look into this. Once again, thanks for a great report. Cheers, Simon

1 0

RE: ghc 5.02.2 FFI question
by Simon Marlow 09 Apr '02

09 Apr '02

Hi Bernie, > I've been playing with the FFI in GHC 5.02.2 > > I'm not sure if I'm using it correctly because I get a space leak > in my program. I just tried your example and it seems to run in constant space here with 5.02.2. The code looks fine - this isn't something we really envisaged people doing with the RTS API, but there's no real problem with it except that of course you don't get the benefits of type checking. I'm sure you have very good reasons for building Haskell expressions in C :-) Can you give us any more clues? What were the symptoms when you ran it? Cheers, Simon

2 1

RE: GHC 5.02.3, SuSE rpms
by Simon Marlow 09 Apr '02

09 Apr '02

> I've uploaded SuSE 7.3 rpms for the patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.02.3. Thanks; slurped & added to the download page. Cheers, Simon

1 0

Re: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Ashley Yakeley 08 Apr '02

08 Apr '02

At 2002-04-08 11:33, John Meacham wrote: >this usage of unsafePerformIO is such a staple of real-world Haskell >programming, it seems there should be some language (or experemental >compiler *wink wink ghc nudge*) support for it. Sounds like a bad habit that shouldn't be encouraged to me. Still, if there is a way to support this safely, perhaps it should be allowed. I'd like to see a compiler flag that made all "unsafe" calls compiler errors. I'd put it into package javavm so that anyone using JVM-Bridge would have it turned on. -- Ashley Yakeley, Functional Purist Rank 2 Knight, Order of the Polymorphic Typed Lambda Calculus Seattle WA

1 0

RE: ghc-5.02.2-i386-unknown-linux.tar.bz2
by Byron Hale 08 Apr '02

08 Apr '02

At 11:40 AM 4/8/2002 +0100, you wrote: > > I downloaded and installed ghc-5.02.2-i386-unknown-linux.tar.bz2 on my > > RedHat Linux 6.2 box (because RPM won't install the relevant RPMs). > > However, when I run "ghci," I get the message ... "GHC ... > > 5.02.1" ... > > > > What do you think is happening here? > >What do you get from 'ghc --version'? It came from the haskell.org download page. Version 5.02.1 was previously installed, as Serge Mechveliani inquired. I installed it as the super-user at the root of the file system. Perhaps I should now consider Version 5.02.3, but the problem may recur. I got this version of RHL from RH over the Web and finally realize that I need to register with RH for support. That is the ultimate solution, but there may be a delay in executing it. It is at least worth understanding. Thanks, Byron Hale byron.hale(a)einfo.com >Simon >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users(a)haskell.org >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Simon Marlow 08 Apr '02

08 Apr '02

> A while back I asked how to make the Ref's from Koen Clasessen's PhD > thesis Ord-able for the purpose of making them keys for efficient > finite maps. > > Koen quickly responded with a clever implementation which attaches the > values to the keys. While I don't rule out eventually making use of > it, this solution has the drawback of requiring lookups in the finite > map to be inside the ST or IO monad. > > Josef Svenningsson asked if I had tried adding > {-# NOINLINE refWInt #-} > I had (quite hopefully.) It doesn't work. After fiddling a bit to > get a sense of what works and what doesn't, I tried: > {-# INLINE refWInt #-} > . This does the trick! I've included the working code (which differs > from that of my original message only by the addition of the INLINE > directive) below. > > My question to the GHC implementors is: what's going on here? Can you > give us (at least Josef and I are confused) any help in predicting how > unsafePerformIO will behave? I'm afraid the answer is just "unsafePerformIO is called *unsafe*PerformIO for a reason"! You're using it in an inherently unsafe way here - the result of the program depends on whether the compiler duplicates the expression or not, something which it is normally free to do without affecting the meaning of the program. However, it is possible to have global top-level references using unsafePerformIO if you're very careful about it. In GHC we do something like this: {-# NOINLINE global_var #-} global_var :: IORef Int global_var = unsafePerformIO (newIORef 42) the NOINLINE pragma is used to ensure that there is precisely *one* copy of the right hand side of global_var in the resulting program (NOTE: you also need to compile the program with -fno-cse to ensure that the compiler doesn't also common up the RHS of global_var with other similar top-level definitions). Cheers, Simon

2 1