Re: Bools are not unboxed

2004-10-05 Thread John Meacham
On Tue, Oct 05, 2004 at 01:48:30PM +0100, Simon Marlow wrote: > It would probably be better to return 0#/1# instead of a Bool from the > comparison primops, because this would expose slightly more detail to > the simplifier and might result in slightly better code in some cases > (but no dramatic i

RE: AIX 5.1L Build of GHC 6.2.1

2004-10-05 Thread Simon Marlow
On 04 October 2004 17:19, John Goerzen wrote: > On 2004-10-02, John Goerzen <[EMAIL PROTECTED]> wrote: >> to help from people here, I have built a working GHC 6.2.1 for >> AIX5.1L. (The last GHC I could find for AIX was GHC 2.09!) > > As a follow-up question: what does it take to get this listed

RE: hWaitForInput and timeouts

2004-10-05 Thread Simon Marlow
On 03 October 2004 19:34, Peter Simons wrote: > I have another I/O problem. I need to time out when a Handle > blocks forever. I am using hWaitForInput anyway, so that > shouldn't be a problem, but the documentation says that > using this feature will block all IO threads? Is it much > work to fix

RE: Bools are not unboxed

2004-10-05 Thread Simon Marlow
On 03 October 2004 14:07, Tomasz Zielonka wrote: > Then I noticed the cause: > GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other > primitive comparison operators. > > Would it be difficult to add Bool unboxing to GHC? > Maybe it would suffice to use preallocated False and

RE: threadsafe needed

2004-10-05 Thread Simon Marlow
On 05 October 2004 10:16, John Meacham wrote: > Quite a few foreign calls in the library are missing threadsafe in > their declarations. if this could be fixed by 6.2.2 that would be > great. in particular > system, rawSystem, and DNS lookups are important to be able to do > concurrently. Thanks,

RE: BeOS port

2004-10-05 Thread Simon Marlow
On 03 October 2004 02:14, Donald Bruce Stewart wrote: > Waldemar.Kornewald: >> Hi, >> is it possible to use a simpler build system for GHC? :) > > It isn't so bad. It seems to be quite portable :) We *are* using a simpler build system for GHC. You should have seen the last one :-) Cheers,

RE: Using packages in ghci

2004-10-05 Thread Simon Marlow
I think what's happening here is that you essentially have overlapping .hi files: the interface for Data.Tree.AVL.List is found along the search path, and also in a package (because the search path "." and the import_dirs for the package point to the same place). This is apparently confusing GHC,

RE: symbol __stg_split_marker' is already defined

2004-10-05 Thread Simon Marlow
On 02 October 2004 01:22, John Goerzen wrote: > rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir > GHC/Base_split; else /o pt/freeware/bin/find GHC/Base_split -name > '*.o' -print | xargs rm -f __rm_food; fi; > ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude > -#inclu

GADT regression

2004-10-05 Thread alcremi
Hi, I am unable to compile the following program with ghc-6.3.20041004, due to a regression introduced by GADT (I suppose) : module Definition where data UnOp a b = OpNegate | OpRecip | OpNot | OpConst | OpUnFunc (a -> b) inst

RE: Is there a non-blocking version of hGetArray?

2004-10-05 Thread Simon Marlow
On 02 October 2004 13:04, Tomasz Zielonka wrote: > On Fri, Oct 01, 2004 at 09:34:36PM +0100, Simon Marlow wrote: >> >> Not currently, but I could probably implement the equivalent >> (hGetArrayNonBlocking). > > It is perhaps not closely related, but could we also have > Network.Socket recvFrom /

Re: threadsafe needed

2004-10-05 Thread Peter Simons
John Meacham writes: > in particular system, rawSystem, and DNS lookups are > important to be able to do concurrently. For DNS, there is a solution available here: http://cryp.to/hsdns/ Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTE

threadsafe needed

2004-10-05 Thread John Meacham
Quite a few foreign calls in the library are missing threadsafe in their declarations. if this could be fixed by 6.2.2 that would be great. in particular system, rawSystem, and DNS lookups are important to be able to do concurrently. Also, is there plans for a threadunsafe? which seems like it wo