June 2002 - Glasgow-haskell-users

RE: GHCI Can't Find Module But GHC Can
by Simon Marlow 27 Jun '02

27 Jun '02

> But ghci already contains a Haskell parser - so it should be much > less work. No excuses, but part of the reason we didn't do this is because of the structure of GHCi. There's a strong separation between the bit we call the "compiler" which translates a single module into executable code, and the "compilation manager" which handles multiple module compilation and linking. The parser lives in the compiler, and the dependency-tree generation lives in the compilation manager. Cheers, Simon

1 0

RE: mergesort
by Simon Marlow 27 Jun '02

27 Jun '02

> (hopefully this is fairly bug-free) At least for my data (lots of > values, limited range), it appears to speed things up tremendously. I > haven't measured more general cases in any detail, though. And one > obvious drawback may be that it's not stable, which I think can be > alleviated by a few well placed 'reverse's. I imagine you could write a pretty good bin/bucket sort using accumArray, which should be linear time in GHC. Have you tried that? Cheers, Simon

1 0

RE: mergesort
by Simon Marlow 27 Jun '02

27 Jun '02

> | 5.02 uses quicksort, but 5.04 will use mergesort > | instead which has much more predictable performance > | behaviour. > > What implementation of mergesort are you using? (Could you > send me code?) It's Ian Lynagh's implementation, from a thread on this list recently: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.h tml There was some concern about the lack of laziness and stack overflows, but the general concensus was that merge sort was a better choice. Feel free to argue otherwise :) In the new libraries, I don't have any objection to providing both Data.List.mergesort and Data.List.quicksort, and even Data.List.insertionsort for almost-sorted lists. Cheers, Simon

2 1

RE: GHCI Can't Find Module But GHC Can
by Simon Marlow 27 Jun '02

27 Jun '02

> > > I think the problem is that GHCi doesn't respect #ifdef > > > conditional compilation. > > > > I wasn't aware of any bugs in that area, can anyone provide > some sample > > code? (and I'm surprised, because GHCi just runs cpp in > the same way as > > GHC). > > Ah, I think it is probably just a failure to use the -cpp option on > the ghci commandline. The error message isn't terribly helpful in > this regard, since it complains about being unable to find a module > that wasn't wanted anyway. It might be more useful to complain that > a cpp # directive was found? Aha! GHCi (and ghc --make) has a pre-pass that looks through the file for import declarations so it can build the dependency tree, and it does this without using a proper Haskell parser. I'll bet it's ignoring the CPP directives. Probably it should flag an error, I'll look into it. Cheers, Simon

3 4

RE: ghc on debian/powermac
by Simon Marlow 27 Jun '02

27 Jun '02

> I am trying to compile ghc on my powermac (debian 3.0) > apt-get source ghc5 succeed, > but to do the actual compilation, it need a working ghc > (and there is no binary package in the list) > > How can I get a (even old) working ghc ? I'm afraid we don't have a port for your system at the moment. Furthermore the road to porting GHC is long and tortuous :-( We do have a port for Macs running Darwin, however I'm guessing that's quite different to Debian (Darwin has Apple's special version of GCC for one thing). Check out the GHC porting instructions for more details: http://www.haskell.org/ghc/docs/latest/building/sec-porting-ghc.html Cheers, Simon

2 1

RE: GHCI Can't Find Module But GHC Can
by Simon Marlow 27 Jun '02

27 Jun '02

> > Aha! GHCi (and ghc --make) has a pre-pass that looks through the > > file for import declarations so it can build the dependency tree, > > and it does this without using a proper Haskell parser. I'll bet > > it's ignoring the CPP directives. Probably it should flag an error, > > I'll look into it. > > Using an improper parser sounds a little delicate. Yes, it is - I've never really been happy with the way we do that. Sigh, another thing for the TODO list.... Cheers, Simon

1 0

RE: Weird profiling behaviour
by Simon Marlow 27 Jun '02

27 Jun '02

> > 5.02 uses quicksort, > > That's funny, since I see quadratic scaling, I must be hitting worst > case both times? 'sort' and 'sortBy' *are* implemented in the same > way, right? It's possible, I suppose. Yes, sort is defined in terms of sortBy. Simon

1 0

RE: GHCI Can't Find Module But GHC Can
by Simon Marlow 26 Jun '02

26 Jun '02

> I think the problem is that GHCi doesn't respect #ifdef > conditional compilation. > The HaXml package has modules with stuff like > > #if defined(__HBC__) > import IOMisc > #endif > > which seems to confuse the interpreter (but not the compiler). I've > also seen reports that recent versions of GHC don't grok lines like > > #if __GLASGOW_HASKELL__ <= 210 I wasn't aware of any bugs in that area, can anyone provide some sample code? (and I'm surprised, because GHCi just runs cpp in the same way as GHC). Cheers, Simon

2 1

Weird profiling behaviour
by ketil＠ii.uib.no 26 Jun '02

26 Jun '02

Hi, I have what I think is a really strange problem. I have a fair sized problem, which involves sorting a data set, first on labels (which are Strings) and then on scores (which are Ints). The strange thing is that string sorting is *vastly* faster than int scoring! Now, I've tried modifying the sorting routinges, moving them into the same module, and so on, to no avail. Is there any likely explanation? The pipeline is basically sortBy int_cmp . compound_equal . sortBy string_cmp I hesitate to post the code, since it's part of a rather large program, and in the hope that somebody will pop up and say that oh, yes, it's a well know feature of 'sortBy'. Or that it's an artifact of profiling. Or something like that. Any, and I mean any, suggestions really, really welcome. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

3 4

RE: GHCI Can't Find Module But GHC Can
by Simon Marlow 26 Jun '02

26 Jun '02

> ghci test1.hs -i../lib -I../lib SVG-part1.o SVG-part2.o > ../lib/*.o -package > lang > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.02.3, > for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package std ... linking ... done. > Loading package lang ... linking ... done. > Loading object (static) SVG-part1.o ... done. > Loading object (static) SVG-part2.o ... done. > Loading object (static) ../lib/Haskell2Xml.o ... done. > Loading object (static) ../lib/ParseSTLib.o ... done. > Loading object (static) ../lib/Pretty.o ... done. > Loading object (static) ../lib/Xml2Haskell.o ... done. > Loading object (static) ../lib/XmlCombinators.o ... done. > Loading object (static) ../lib/XmlHtmlGen.o ... done. > Loading object (static) ../lib/XmlHtmlParse.o ... done. > Loading object (static) ../lib/XmlLex.o ... done. > Loading object (static) ../lib/XmlLib.o ... done. > Loading object (static) ../lib/XmlPP.o ... done. > Loading object (static) ../lib/XmlParse.o ... done. > Loading object (static) ../lib/XmlTypes.o ... done. > final link ... done. > can't find module `IOMisc' > Prelude> Where is the module IOMisc located? Does it have source or binary files or both? GHC looks for .hi files and .o files, whereas GHCi also looks for .hs files. If you need to use a pre-compiled Haskell file without source, then it needs to be in a package. Cheers, Simon

2 1