July 2002 - Glasgow-haskell-users

Problems dealing with GHC incompatibilities
by George Russell 26 Jul '02

26 Jul '02

I used to have a lot of trouble with UniForM / HTk every time there was a new GHC release, because we use a LOT of GHC extensions. Sometimes a GHC release wouldn't work at all and I had to submit a shopping list of bugs to the GHC Team, in the hope that they would issue a version X+0.01 which we could use. However I'm glad to say I had virtually no trouble with the upgrade to GHC5.04. I think this is partly because I tried out ghc5.03 several times before ghc5.04 was released, partly from the snapshot releases, and partly from the CVS version. I made sure the UniForM code worked with ghc5.03. Where I had real trouble I was able to complain loudly to the GHC team, and get them to fix the problem, in time for ghc5.04. For example, I think I had two problems with ghc-pkg, which Simon M was kind enough to fix. So my suggestion is that (1) The GHC team continue to issue snapshot releases as often as possible (I don't know why they don't make the automatic builds generate them every night). (2) If you are responsible for a lot of Glasgow Haskell code, you make sure it works not only with the latest official GHC release, but also try to keep it in step with the snapshot releases. We use the -cpp option and combinations like #if (__GLASGOW_HASKELL__ >= 503) -- new stuff #else -- old stuff #endif By the way, Simon M, how long can we rely on the hslibs library structure? Because some time I shall have to schedule time to move over to the new structure, and I'm not looking forward to it.

1 0

RE: re-evaluating CAFs in ghc
by Simon Marlow 26 Jul '02

26 Jul '02

> Is there any way to trick ghc into causing CAFs to > be re-evaluated upon each reference to them? (specifically > without adding arguments to it so that it is no longer a CAF). > > I know this sounds like a dodgy hack ... Apart from hacking the compiler to remove the update frame from CAFs (which isn't difficult), no. In GHCi you can cause CAFs to be thrown away after each evaluation by saying ':set +r'. Cheers, Simon

1 0

re-evaluating CAFs in ghc
by Bernard James POPE 26 Jul '02

26 Jul '02

Hi all, Is there any way to trick ghc into causing CAFs to be re-evaluated upon each reference to them? (specifically without adding arguments to it so that it is no longer a CAF). I know this sounds like a dodgy hack ... Cheers, Bernie.

1 0

RE: bug with profiling things with "strange" filename
by Simon Marlow 26 Jul '02

26 Jul '02

> if you compile a program -p -auto-all with ghc and the name > you give the > exectuable contains iether a "." or a "-" (and possibly other > things) it > will core dump when executed (at least on sparc solaris), or > so it seems, > under 5.04. > > has anyone else had this problem? I've uncovered a profling bug that affects Sparc. 5.04.1 will have the fix. Cheers, Simon

1 0

RE: Foreign.destructArray
by Simon Marlow 26 Jul '02

26 Jul '02

> I'm not for a number of reasons: > > - The libraries that come with GHC are huge and very few of them are > completely stable. Even the H98 libraries change as H98 is refined. > > - The statement that 'deprecated' means 'will not change > until the next > major release' isn't very satisfactory because: > > 1) People might disagree about what a major version is. The second > sentence in this quote from SimonM suggests that the ':-)' is > a typo and SimonM really doesn't regard 5.02->5.04 as a minor > version change. Ok, we define a major release to be anything that isn't a patchlevel release. They have been happenning at roughly 6-12 month intervals recently. The "major version number" (i.e the "5") doesn't correspond to a major release; we use it to indicate when the compiler gets a major overhaul or significant components are rewritten (so that you have a good idea when things might be unstable). eg. in 5.00 we introduced GHCi, in 4.00 we completely re-wrote the RTS, etc. It was debatable whether 5.04 should have been 6.00 since we introduced hierarchical libraries, but in the end we decided it didn't really constitute a significant rewrite, just a re-organisation of existing bits. 6.00 is on the horizon though: it will probably include Template Haskell, possibly Optimistic Evaluation, and a redesign of parts of the RTS and evaluation model that Simon & I are working on. > 2) The timing of GHC releases is unlikely to be a useful measure to > people relying on GHC in their project. Much more > useful would be > 'will not change before the POPL deadline' or 'will not change > before our IPO'. That is, entities should be deprecated for > a time period not a release cycle. If you don't want things to change, don't upgrade! We're keeping releases stable for quite a long time these days: the 5.02 cycle lasted nearly 10 months, during which time we didn't break *anything* between releases. I wish we had the resources to maintain releases from two branches simultaneously, but sadly we don't. > To fix this situation (which I believe is common), we probably need > something like: > > 1) Every entity in the API (type, function, module, etc.) should be > assigned a 'stable period' such as 'stable until Jan 1st 2003'. Do you know about the stability assignment for each module in the hierarchical libraries? Each module is classified as either 'stable', 'provisional', or 'experimental'. These terms are defined more precisely in http://www.haskell.org/~simonmar/libraries/libraries.html I think that's about the right level of rigour, given our current resources. The scheme you're proposing is, IMHO, unrealistic at the moment (although it may be the right thing in the future when things have settled down some more). > 3) GHC's flag to warn about deprecated functions would take an > optional expiry date as an argument. GHC would warn about use of > entities which will expire before then. Probably on by default. This is a good idea. Volunteers? > 5) Each release would include a list of any entities removed ahead of > schedule. > > [It's open to debate whether this would do anything other than > increase the motivation to keep the list small.] I agree we ought to do a better job here. I'm sure there's a way to automate this at least partially: compare the library interfaces against the previous release's and document (or fix) any changes. Cheers, Simon

1 0

RE: what does "ExtractConcepts: fatal error: heapCensus" mean?
by Simon Marlow 26 Jul '02

26 Jul '02

> I get this when I "+RTS -h" one of my programs... > > what does it mean? It means you should report a bug :-) Simon

1 0

RE: passing an option to gcc without a -
by Simon Marlow 26 Jul '02

26 Jul '02

> I'm linking with a .a file built from C; when I do this on a > C program I > do something like: > > gcc myfile.c -o myout theafile.a > > so i tried > > ghc MyFile.hs -o myout -optctheafile.a > > but this doesn't appear to pass the paramter. when i run with -v3 and > inspect the call to gcc it doesn't include this option. if i > copy that > call to gcc and add it maually at the command line, everything's cool You want the option passed when *linking*, so I think you want -optl rather than -optc. Cheers, Simon

1 0

bug with profiling things with "strange" filename
by Hal Daume III 26 Jul '02

26 Jul '02

if you compile a program -p -auto-all with ghc and the name you give the exectuable contains iether a "." or a "-" (and possibly other things) it will core dump when executed (at least on sparc solaris), or so it seems, under 5.04. has anyone else had this problem? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 2

instances of Typable
by Hal Daume III 25 Jul '02

25 Jul '02

if I have newtype Foo = Foo Int and i want to make it an instance of typeable, how do I create a TypeRep object? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

what does "ExtractConcepts: fatal error: heapCensus" mean?
by Hal Daume III 25 Jul '02

25 Jul '02

I get this when I "+RTS -h" one of my programs... what does it mean? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0