October 2004 - Glasgow-haskell-users

RE: hWaitForInput and timeouts
by Simon Marlow 05 Oct '04

05 Oct '04

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 this? I _could_ forkIO a racer thread myself, of > course, but it feels wrong to do that around a function that > has an explicit timeout argument. :-) I've fixed it so it'll work in the threaded RTS. However, forking a Haskell thread to do the threadDelay might still be quicker. In the unthreaded RTS there isn't an easy fix, I'm afraid. The reason is that we don't currently have a way to block a thread on both I/O *and* a timeout. Cheers, Simon

1 0

RE: threadsafe needed
by Simon Marlow 05 Oct '04

05 Oct '04

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, I've fixed those. We don't have threadsafe by the way; only safe/unusafe. Safe also means threadsafe. > Also, is there plans for a threadunsafe? which seems like it would be > a much more common case than threadsafe and should be much easier to > implement since there is no chance the haskell runtime can be called > from a thread it didn't expect. Not sure what you mean by threadunsafe. Is it different from plain unsafe? We *want* the RTS to be able to be called by threads it doesn't expect. Otherwise how do you implement a thread-safe library API in Haskell? Cheers, Simon

1 0

RE: BeOS port
by Simon Marlow 05 Oct '04

05 Oct '04

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, Simon

1 0

RE: Using packages in ghci
by Simon Marlow 05 Oct '04

05 Oct '04

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, but I don't know exactly how. We could "fix" the problem by checking whether a given module can be found in more than one place, but that would involve searching every package for every module, which might slow things down. When we store the list of visible modules with a package we'll be able to do this much more easily. Cheers, Simon On 02 October 2004 08:42, Adrian Hey wrote: > On Friday 01 Oct 2004 9:36 pm, Simon Marlow wrote: >> Looks fine - GHCi is supposed to look in the directories in >> import_dirs >> for .hi files. What does ghci -v tell you? > > Quite a lot :-), but nothing very surprising. I think I've found what > causes the problem. It does actually seem to work as expected, > provided the current directory is not what it usually is when I'm > working on the library. > > I.E. /home/adrian/HaskellLibs/Data.Tree.AVL > > This is what I get > >> Prelude> :m Data.Tree.AVL >> Prelude Data.Tree.AVL> asTreeL "ABCD" >> >> <interactive>:1: >> tcLookup: `asTreeL' is not in scope >> In the definition of `it': it = asTreeL "ABCD" >> >> Failed to load interface for `Data.Tree.AVL.List': >> Bad interface file: ./Data/Tree/AVL/List.hi >> ./Data/Tree/AVL/List.hi: openBinaryFile: does not exist (No >> such file or directory) >> >> Failed to find interface decl for `asTreeL' >> from module `Data.Tree.AVL.List' > > But if I cd to.. > > I.E. /home/adrian/HaskellLibs/Data.Tree.AVL/pkg > > ..it works fine. I've since discovered it also seems to work fine from > from any other directory too. So it seems to something peculiar about > the one particular directory that upsets it. > > This is with version 6.2.20040915, but 6.2.1 did the same thing IIRC. > > Regards

1 0

RE: symbol __stg_split_marker' is already defined
by Simon Marlow 05 Oct '04

05 Oct '04

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 > -#include HsBase.h -funbox-strict-fields -package-name base -O > -Rghc-timing -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi > GHC/Base.hi /tmp/ghc82602.hc:2593: warning: this decimal constant is > unsigned only in ISO C9 0 > /tmp/ghc82602.s: Assembler messages: > /tmp/ghc82602.s:128: Error: symbol `__stg_split_marker' is already > defined /tmp/ghc82602.s:287: Error: symbol `__stg_split_marker' is > already defined /tmp/ghc82602.s:448: Error: symbol > `__stg_split_marker' is already defined > > And about a hundred more. Ideas? You probably need to add some support for your platform to the split script in ghc/driver/split/ghc-split.lprl and/or the mangler in ghc/driver/mangler/ghc-asm.lprl. For now, you can turn off splitting as Don suggested. > Oh, BTW, I had to put a script named gcc on my path. It says this: > > exec /usr/local/bin/gcc -mpowerpc -maix32 -mminimal-toc "$@" These options should go in machDepCCOpts in ghc/compiler/main/DriverFlags.hs, and then you can do away with the gcc script. Cheers, Simon

1 0

GADT regression
by alcremi＠free.fr 05 Oct '04

05 Oct '04

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) instance Show (UnOp a b) where show OpNegate = "OpNegate" show OpRecip = "OpRecip" show OpNot = "OpNot" show OpConst = "OpConst" show (OpUnFunc _) = "OpUnFunc <function>" data (Show a) => Obs a = KonstObs a | forall b. (Show b) => LiftObs (UnOp b a) (Obs b) instance (Show a) => Show (Obs a) where show (KonstObs x) = "KonstObs " ++ show x I get the following message : bug.hs:23:10: Ambiguous type variable `a' in the top-level constraint: `Show a' arising from use of `LiftObs' at bug.hs:23:10-21 It compiles OK with 'hugs -98' Alain

1 0

RE: Is there a non-blocking version of hGetArray?
by Simon Marlow 05 Oct '04

05 Oct '04

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 / sendTo working on raw buffers? > > I've attached a proposed implementation. It moves most of code to > recvBufFrom and sendBufTo, and changes recvFrom / sendTo to use the > *Buf* functions. Committed, thanks! > It would be nice if these functions could be used to implement > efficient recvFromArray / sendToArray (without copying), but I don't > know if it's possible to get the pointer from MutableByteArray. Is > there a danger that GC invalidates the pointer? It is possible to get a Ptr from a MutableByteArray, but only if the array was allocated pinned, and only if you make sure it lives across any foreign calls (using touch#). This is how Foreign.alloca works, for example. Cheers, Simon

1 0

reading text files
by Carsten Schultz 04 Oct '04

04 Oct '04

Hi! I want to read a text file from a socket and process it as a String (using Parsec). Is hGetContent ok, or are there mor efficient alternatives available, even if I want a String anyway? Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page.

3 2

AIX 5.1L Build of GHC 6.2.1
by John Goerzen 04 Oct '04

04 Oct '04

Hello, Whew! This was the toughest bootstrap I've done in a long time. Thanks 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!) Find it at: gopher://quux.org/1/devel/AIX/ghc or http://quux.org/devel/AIX/ghc for the gopher-impaired I have posted the "binary distribution" generated by the make system as well as a tarball containing my fully built source tree. There's also a info file describing how I finally made it work. Thanks very much to everyone on these two lists that provided hints along the way. I appreciate it! For the curious, this was bootstrapped from Debian on x86. It is built for PowerPC using gcc 3.3.2. Please feel free to post either or both of these on the GHC download page. (Is there someone specific I should contact about that?) These are unregisterized builds. Porting the registerized system and interpreter are beyond my expertise, and things I don't need, but maybe this will provide a start for someone else to do that. (Please note: the binary dist has uploaded to the site but my build tree is still uploading as I type this, so please give it about an hour before you try to download that, or you'll get a partial file.) -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

2 3

RE: Bools are not unboxed
by Simon Peyton-Jones 04 Oct '04

04 Oct '04

| > for :: Int -> IO () -> IO () | > for 0 _ = return () | > for n x = x >> for (n - 1) x Good example (allocates lots of silly thunks). I'd come across this before, and fixed the HEAD, but the 6.2 branch is still doing badly. We'll try to fix that. | Playing with the code generated by ghc is a great way to waste time | for me. Wait until you have found the RULES-pragma :-) In general, GHC's optimiser should behave predictably; small changes in the source program should not have big effects. Of course, sometimes they do, and for good reason. But not always; I'm keen to identify cases where the optimiser does a poor/unpredictable job, and fix them. So please let me know when that happens. The more you can boil down a program, and identify the culprit, as Carsten did so accurately in this case, the more likely I am to fix it. At the other end of the spectrum "this 1000 line program goes slower than I expect" is less helpful :-) Incidentally, GHC does use pre-allocated True and False booleans. Simon

1 0