ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Jan Scheffczyk
Hi all, I recently switched to ghc 6.0.1 running on a debian linux box. When compiling a program using ghc --make -O or ghc --make -O2 I get lots of errors while linking. The linker concerns about undefined references to Data.FiniteMap, which I frequently use. For example, the linker says:

RE: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Simon Marlow
I recently switched to ghc 6.0.1 running on a debian linux box. When compiling a program using ghc --make -O or ghc --make -O2 I get lots of errors while linking. The linker concerns about undefined references to Data.FiniteMap, which I frequently use. For example, the linker

RE: Lost output in multithreaded program

2003-07-31 Thread Simon Marlow
I haven't investigated in detail, but I believe your problem might be caused by a known bug in the implementation of forkProcess, namely that when forking from a child thread it doesn't kill the main thread. The workaround is to fork (in your case call popen) from the main thread, not a child

Re: Strange Building problem...

2003-07-31 Thread Mark Green
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote: GHCziBase_True_closure is a symbol that should be coming from the base package, the GHC.Base module in particular. You could check that libraries/base/libHSbase.a looks reasonable: it should be on the order of 17Mb. Try 'nm' on it, look for some of

RE: Strange Building problem...

2003-07-31 Thread Simon Marlow
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote: GHCziBase_True_closure is a symbol that should be coming from the base package, the GHC.Base module in particular. You could check that libraries/base/libHSbase.a looks reasonable: it should be on the order of 17Mb. Try 'nm' on it, look

Re: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Ian Lynagh
On Thu, Jul 31, 2003 at 08:55:01AM +0200, Jan Scheffczyk wrote: Hi all, I recently switched to ghc 6.0.1 running on a debian linux box. When compiling a program using ghc --make -O or ghc --make -O2 I get lots of errors while linking. The linker concerns about undefined references

Re: Strange Building problem...

2003-07-31 Thread Mark Green
On Thu, 31 Jul 2003 13:57:02 +0100, you wrote: What is odd is that ghc-inplace is invoked by the make process several times before this big one (which appears to be the start of stage 2?) and works fine... Do the errors really refer to GHCziBase_True_Closure, or is it GHCziBase_True_closure?

Re: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Jan Scheffczyk
Hi Ian, If you are not already using them then you could try the debs from the Haskell Experimental repository. Both stable and unstable debs are available (unfortunately they are awaiting manual intervention before going into the Debian archive as there are a couple of new package names):

Re: ANNOUNCE: GHC version 6.0.1

2003-07-31 Thread Wolfgang Thaller
= The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 = A Mac OS X package id now available at: http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg Cheers,

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Simon Peyton-Jones
Something very odd is going on. GHC does not generate programs than run 3x faster between GHC versions. If, perhaps, you compiled both without -O, no cross-module inlining takes place. That would account for a big slow down when using separate compilation. I see you use -O2 this time. I

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Graham Klyne
At 08:44 31/07/03 +0100, Simon Peyton-Jones wrote: I don't know why the all in one version might go slower though Virtual memory thrashing? (Hal did say something about needing lots of RAM.) #g --- Graham Klyne [EMAIL PROTECTED] PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Koen Claessen
Simon Peyton-Jones wrote: | I don't know why the all in one version might go | slower though. How about some (artificial) cut-offs during optimization phases? Optimizing a hugs module could lead to some kind of combinatorial explosion (which gets cut off by the optimizer) which does not happen

New Haskell and FP merchandise logos for review

2003-07-31 Thread Fritz K Ruehr
John Peterson recently handed over control of the Haskell Merchandise area of haskell.org to me and, in celebration, I've created a bunch of provisional designs for new Haskell, FP and types-related swag. The logos include the original and new haskell.org logos and about 15 others, designed

RE: New Haskell and FP merchandise logos for review

2003-07-31 Thread David Bergman
I seldom post things here, but Fritz, you are a genius! /David ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: ANNOUNCE: GHC version 6.0.1

2003-07-31 Thread Wolfgang Thaller
= The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 = A Mac OS X package id now available at: http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg Cheers,

a breaking monad

2003-07-31 Thread Hal Daume
i've noticed in a lot of my imperative-looking monadic code, i have lots of stuff that looks like: ... = do q - some test if q then return some constant else do major code body here lots of these things embedded makes the code hard to read and introduces way too much

Re: a breaking monad

2003-07-31 Thread Derek Elkins
On Thu, 31 Jul 2003 13:18:40 -0700 Hal Daume [EMAIL PROTECTED] wrote: so, my questions are: does this exist in some other form I'm not aware of? is there something fundamentally broken about this (sorry for the pun)? any other comments, suggestions? This looks like a bizarre rendition of

Raw I/O library proposal, second (more pragmatic) draft

2003-07-31 Thread Ben Rudiak-Gould
[Crossposted to Haskell and Libraries. Replies to Libraries.] -- More comments, please. Bad names? Important missing functionality? -- Still unimplementable? module System.RawIOSecondDraft (...) where data File -- now essentially a file handle data InputChannel -- renamed

RE: a breaking monad

2003-07-31 Thread Hal Daume
This looks like a bizarre rendition of the Error/Exception monad. Yes, of course. *Hal slaps himself* Thanks. Also, your motivating example is ambiguous. I think you mainly care about the case where the test is testing for some exceptional condition. I personally wouldn't want to use

Text I/O library proposal, first draft

2003-07-31 Thread Ben Rudiak-Gould
[Crossposted to Haskell and Libraries. Replies to Libraries.] {- Good things about this text library design: * Efficient implementation should be straightforward * Character coder interface is public, so users can supply their own encodings, or write coder transformers (there are some

RE: Text I/O library proposal, first draft

2003-07-31 Thread Hal Daume
Hi Ben, Bad things: * There's no way to implement fgetpos/fsetpos type functionality, because coders don't expose their internal state. (In fact, there would need to be a way to explicitly copy the state, since it may well include IORefs, Ptrs, etc.) Is this a serious

Re: Text I/O library proposal, first draft

2003-07-31 Thread John Meacham
presumably if you are doing random access on the file, it is in a known nonarbitrary text encoding (like utf8). in which case you can read/access the file with the binary routines and just use the appropriate text conversions to get data out. John On Thu, Jul 31, 2003 at 03:55:44PM

*safe* coerce, for regular and existential types

2003-07-31 Thread oleg
This message describes functions safeCast and sAFECoerce implemented in Haskell98 with common, pure extensions. The functions can be used to 'escape' from or to existential quantification and to make existentially-quantified datatypes far easier to deal with. Unlike Dynamic, the present approach

Re: Text I/O library proposal, first draft

2003-07-31 Thread Glynn Clements
Ben Rudiak-Gould wrote: module System.TextIOFirstDraft (...) where -- A BlockRecoder takes source and destination buffers and does some sort -- of translation between them. It returns the number of values (not -- bytes!) consumed and the number of values produced. It does not have to --

Re: *safe* coerce, for regular and existential types

2003-07-31 Thread Derek Elkins
Throughout this message you imply, if not outright state, that Dynamics requires unsafeCoerce/unsafePerformIO. This is simply not the case. GHC implements Dynamics with unsafeCoerce, or did last time I checked, but it can easily be implemented using only existentials. (I presume that this

Re: Exporting GHC functions.

2003-07-31 Thread Thomas L. Bevan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I've worked it out. Didn't read the docs properly as usual. Tom On Thu, 31 Jul 2003 04:20 pm, Thomas L. Bevan wrote: Here is a copy of all the files I am using to try to export a Haskell function. This compiles but produces a executable

Re: CSV parser, quotes?

2003-07-31 Thread Keith Wansbrough
In attempting to improve the CSV parser based on comments, I have the following code that's attached. I'm having a heck of a time getting the double quotes = an escaped quote thing to work. There is some commented out code which was my last attempt. As it stands the code works, minus the

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(moved to haskell cafe -- hopefully the other threads will follow) I don't know why the all in one version might go slower though Virtual memory thrashing? (Hal did say something about needing lots of RAM.) only to compile. i haven't measured, but the resulting executable shouldn't

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(haskell-cafe now) Interesting. I've stripped them and they are exactly the same size. diff says they differ though. pre-stripping, the normal nhc (non ai1) is marginally larger (6.8m versus 7.0m). I'll try to measure memory usage if someone tells me how :) - Hal -- Hal Daume III

RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(cafe) This seems like a reasonable hypothesis. Is there a way to get GHC to keep trying, despite the enormity of the input file? Specifically, I expect it to do a better job of (a) inlining and (b) specialization. Is there a way to hint to it to try a bit harder? :) - Hal -- Hal Daume