Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote: > Glad you got it going. I notice there are a few test failures, many of > which could be fixed easily, e.g. > > --- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009 > +++ ./lib/IO/hClose002.run.stdout.normalisedWed Sep 16 14:08:09 2009 > @@ -1,4 +1,4 @@ > -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) > +Left hClose002.tmp: hClose: invalid argument (Bad file number) > Right () > Right () > Right () > *** unexpected failure for hClose002(normal) > > > that just needs a platform-specific expected output file > (hClose002.stdout-i386-unknown-solaris2). BTW: is there an easy way to do some general output filtering on *all* tests for different platforms? It may not be helpful for the above test, but for some differences (like stderr in case of several types of core dumps on different operating systems, or the typical linker warnings about strcat(3), strcpy(3) etc. on OpenBSD) it may be less maintainance work to filter or modify the output on specific platforms. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
Hi, indeed, I know that and I expect to submit patches later this month. Thanks, Karel Simon Marlow wrote: > Glad you got it going. I notice there are a few test failures, many of > which could be fixed easily, e.g. > > --- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009 > +++ ./lib/IO/hClose002.run.stdout.normalisedWed Sep 16 14:08:09 2009 > @@ -1,4 +1,4 @@ > -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) > +Left hClose002.tmp: hClose: invalid argument (Bad file number) > Right () > Right () > Right () > *** unexpected failure for hClose002(normal) > > > that just needs a platform-specific expected output file > (hClose002.stdout-i386-unknown-solaris2). > > Cheers, > Simon > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to move code from GHC to libraries?
On 17/09/2009 04:43, Norman Ramsey wrote: > > While we're on this topic, I've had several requests to pull HOOPL > > (the new dataflow optimization code) out as a library so that we can > > make it into a Hackage package. I'd like to do this, but the > > situation is complicated because HOOPL depends on UniqFM, which is > > GHC-specific. I thought that there was a similar implementation out > > in the wild (based on Okasaki-Gill rather than Adams), but I can't > > find it on hackage. > > Isn't Data.IntMap ~= UniqFM? Yes, thanks --- I couldn't remember the module name, and search did not help. > > Is there an established procedure for moving a part of GHC into a > > library without breaking everybody's build? ... > > The architecture of our library setup is here: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries > You'd be adding a new zero-boot package... OK, I would like to propose that I put Data.IntMap into a new zero-boot package, and that I replace the existing UniqFM with a compatibility layer over Data.IntMap, with the eventual goal of expunging UniqFM from the GHC sources. Any comments or objections? You can assume that the bootstrapping compiler already has Data.IntMap, no need to put it in a 0-boot package. So in principle using Data.IntMap is a good thing, I wholeheartedly support using the standard libraries instead of in-house duplicates where possible. The only potential problem is performance: we rely heavily on UniqFM in GHC, so we'd have to make sure that any replacement is at least as fast. The only time to measure it is when making the changeover, when you can measure the change in isolation. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On 16/09/2009 15:06, Karel Gardas wrote: Thanks to Christian note I solved the issue. Also thanks to Matthias' advice I've been able to configure ghc to use GNU iconv in /usr/local, but the result was still the same. I later used Christian advice to force ghc not to use /usr/local's iconv and this really configured correctly (like sparky's: checking for library containing iconv... none required) and now finally my buildbot is working even for head. Note the provided /usr/local iconv is probably from package provided by sunfreeware.com and is there from the old SXDE 1/08 installation. Now I'm using OpenSolaris 2009.06 and trying to get rid of such additions which are no longer needed. Thanks for all the help provided! Glad you got it going. I notice there are a few test failures, many of which could be fixed easily, e.g. --- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalisedWed Sep 16 14:08:09 2009 @@ -1,4 +1,4 @@ -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) +Left hClose002.tmp: hClose: invalid argument (Bad file number) Right () Right () Right () *** unexpected failure for hClose002(normal) that just needs a platform-specific expected output file (hClose002.stdout-i386-unknown-solaris2). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
