- Glasgow-haskell-users

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

passing an option to gcc without a -
by Hal Daume III 25 Jul '02

25 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 thoughts? - 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

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

25 Jul '02

> Regardless, it would be nice if functions were first > deprecated and then > removed. I'm really wishing at this point that I hadn't > upgraded to ghc > 5.04; most of my programs no longer compile due to the library > restructuring and for every function I use that's not pure Haskell 98 > (which is a fair amount, unfortunately), I've had to grep around the > imports directory to find out where it moved to. Hmm, I tried quite hard not to break too much stuff in 5.04. That's why all the old hslibs are still there, and they still supply virtually the same APIs that they did in 5.02. Specifically, what broke for you? > I don't mean to point a > finger at anyone for this, but I was expecting either a smoother > transition or for the version number of GHC to change > significantly. A > minor version change should not break programs (imo). 5.02->5.04 is a major version change :-) We only promise not to break APIs in patchlevel releases (eg. 5.04->5.04.1 won't break anything). > Sorry for the tirade, but I'm pressured to get some code out > soon and this isn't helping things. Not at all, we appreciate the feedback. I'm surprised that you're having so much trouble though. Cheers, Simon

2 2

RE: Using UArray and Array
by Simon Marlow 25 Jul '02

25 Jul '02

> Short answer: just say > > import Array(Array) > import Data.Array.Unboxed I'd prefer it if Data.Array was the fully overloaded version, but sadly IArray requires multi-param type classes and we don't want to knobble the libraries too much for non-MPTC compilers. The current situation is a bit unsavoury, though; perhaps Data.Array.IArray should re-export the Array type. Cheers, Simon

1 0