October 2004 - Glasgow-haskell-users

ghc from CVS HEAD doesn't work with "-O -threaded"
by Peter Simons 19 Oct '04

19 Oct '04

The following reproducibly fails: $ darcs get http://cryp.to/hsdns [*] $ cd hsdns/ $ hsc2hs ADNS.hsc $ ghc -threaded -Wall -O --make test.hs -o test -ladns | Chasing modules from: test.hs | Compiling ADNS ( ./ADNS.hs, ./ADNS.o ) | /tmp/ghc2613.hc:9:23: ADNS_stub.h: No such file or directory | /tmp/ghc2613.hc: In function `s8Xa_ret': | /tmp/ghc2613.hc:6340: error: `ADNS_d7eN' undeclared (...) If you build the program without optimization, $ ghc -threaded --make test -ladns it works just fine. This seems to happen only when the threaded RTS in involved, -O without -threaded works. Peter

1 0

RE: deriving...
by MR K P SCHUPKE 17 Oct '04

17 Oct '04

>look at the user manual. Okay, I see the Generic type class stuff does not support multi parameter type classes. I guess I am stuck - any suggestions as to how best do this? I wish to be able to derive type level labels for datatypes, like the following: data Fred a = Fred a deriving TTypeable generates the instance: instance TTypeable a al => TTypeable (Fred a) (NCons (N3 (N4 (N5 Nil))) (TCons al Nil)) where (N3 (N4 (N5 Nil))) is the result of a hash function on the name "Fred". I have looked at TcDeriv but I don't know enough of the compiler internals to see how this would be added to the current implementation... Can you give me some pointers on how to do this? Keean.

5 5

Re: deriving...
by MR K P SCHUPKE 16 Oct '04

16 Oct '04

>Check out Ulf Norell's IOHCC submission, his DeriveData.hs module does this, Do you have a link? Keean.

2 1

RE: x86_64: total success
by Simon Marlow 15 Oct '04

15 Oct '04

On 14 October 2004 10:13, John Meacham wrote: >> It's too late for 6.2.2, unless it's a 1-line fix. I don't think it >> is, because it won't be self-hosting without some more work in the >> build system. > > > ;diff package.conf.backup package.conf > # /usr/lib/ghc-6.2.1 2:06AM john@momenergy 1 12c12 > < extra_ghc_opts = [], > --- >> extra_ghc_opts = ["-optc-m32", "-opta-m32", "-optl-m32"], > > well, it did turn out to be a one-line fix :) but perhaps this isn't > the > proper way to do it, it does seem to have solved the problem for me > though. That's not really a "fix". It's a patch for the i386 distribution to make it work on on x86_64 platform, but it doesn't let you build GHC on that platform, for example. For that, some (probably small) changes to the build system would be required. I imagine you would do something like: ./configure --build=x86_64-unknown-linux --host=i386-unknown-linux and the build system picks up the difference between $BuildArch and $HostArch and adds the -m32 flags. Something like that. >> The interesting bit will be doing the native code generator, but you >> should start from the new NCG in 6.4 if you're interested in working >> on that. Adding SSE support would be great. > > Yes, I am looking at that code now. > > Would it even be possible to have the same ghc binary have multiple > target architectures? it seems that some stuff ends up hardcoded in > various places after the ./configure of ghc. Certainly compiling multiple native code generators into the compiler is possible in principle, but would require some work. That's certainly not the end of the story though: GHC expects certain constants to be "constant", including the size of a word on the target architectre. Abstracting this would be rather difficult. However, building a cross-compiler is probably more feasible. Some work involved definitely, but feasible. Cheers, Simon

2 1

RE: req for code
by Simon Marlow 15 Oct '04

15 Oct '04

On 14 October 2004 13:06, Benedict Kavanagh wrote: > Writing some system code. Want to do it in Haskell. As a head start > boost does anybody have any code that > > uses forkprocess to fork, creates a pipe between parent/child and dups > child's end to be standard out for the child and then have the > parent do something based on something the child says. > > I'll just go ahead and write it but I was wondering how integrated > IO() stuff is with low level file calls. An example would help. > > Anyone got any code that I could look at? Is there any code in any > library or other code that does this kind of stuff? The new System.Process library does the setting up of pipes and forking business for you, all behind a portable API. It'll be in GHC 6.4, but there's a version here which might work for you with GHC 6.2.2: http://www.haskell.org/~simonmar/process/process.tar.gz Cheers, Simon

1 0

threadsafe needed
by John Meacham 15 Oct '04

15 Oct '04

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 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. John -- John Meacham - ⑆repetae.net⑆john⑈

3 2

req for code
by Benedict Kavanagh 14 Oct '04

14 Oct '04

Writing some system code. Want to do it in Haskell. As a head start boost does anybody have any code that uses forkprocess to fork, creates a pipe between parent/child and dups child's end to be standard out for the child and then have the parent do something based on something the child says. I'll just go ahead and write it but I was wondering how integrated IO() stuff is with low level file calls. An example would help. Anyone got any code that I could look at? Is there any code in any library or other code that does this kind of stuff? google turned up zilch. Thanks Ben

1 0

RE: -ddump-minimal-imports and -hidir / -odir
by Simon Marlow 14 Oct '04

14 Oct '04

On 12 October 2004 18:06, Peter Simons wrote: > is it possible that GHC doesn't process the -hidir and -odir > command-line options correctly when -ddump-minimal-imports > is given as well? I have had this problem right now and > removing the -(hi|o)dir flags fixed it, so I figured I'd > better say something. ;-) A quick test doesn't show up anything obviously wrong. Can you give more details? Cheers, Simon

2 1

RE: Performance-loss of accessing data through class?
by Simon Marlow 14 Oct '04

14 Oct '04

On 10 October 2004 02:01, Peter Simons wrote: > in a module I am writing, I am using a 'StateT st IO' monad > with a state like this: > > data MyState st = ST !Int !st > > My own monad is yet-another wrapper for ... another state > monad. And that's getting inconvenient. > > So I wondered whether it would be good to define a class > that unified all those StateTs into _one_ state, like: > >> class KnowsMyStuff a where >> foo :: a -> Int >> bar :: a -> Float >> etc :: a -> [String] > > Then I could write my functions so that they'd work on any > MonadIO which has some way of getting those instances > defined. > > If I did that, how much performance would I lose? Accessing > those values would probably require one more level of > indirection, that can't be as fast as having a specific data > type, right? > > Or is there some optimizer magic at work here? If your code is using a method from a known instance of a class, and the method has a small enough definition, then chances are good that it'll get inlined and the extra layer of abstraction will dissappear. I'm guessing this is the case with your example. If performance is important, then you should probably check the simplifier output with -ddump-simpl to make sure that the code is what you expect. We always enjoy investigating benchmarks, so if you have some code you think isn't going fast enough, then post it here and we'll help you find out where the performance problems are. Cheers, Simon

2 1

RE: x86_64: total success
by Simon Marlow 14 Oct '04

14 Oct '04

On 14 October 2004 07:06, John Meacham wrote: > Aha! a partial fix! now everything works as expected. > > > I just needed to create a link from > libgmp.so.3 -> libgmp.so > and now it all works! The right way to get this link (at least on old RedHat systems) is to install the gmp-devel RPM. > So the complete instructions for getting ghc working on a fedora 2 > x86_64 system are > > ; yum install gmp.i386 readline.i386 > ; ln -s /usr/lib/libgmp.so.3 /usr/lib/libgmp.so > ; ln -s /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmp.so > ; rpm -U ghc-*.i386*.rpm -- downloaded from ghc web site > > and just always pass > > -optc-m32 -opta-m32 -optl-m32 > > to ghc and everything just works. > > If we can get ghc to pass those options automatically by 6.2.2 that > would be cool and a very easy fix. It's too late for 6.2.2, unless it's a 1-line fix. I don't think it is, because it won't be self-hosting without some more work in the build system. However, someone could create a 6.2.2 distribution for x86_64 with the small local patch which adds -m32 to gcc's command line. > Now I can get started on a native port. Hopefully, the much reduced > register pressure on x86_64 and ability to take advantage of sse for > floating point will speed things up for the RTS. There's already some work on this in the tree - I've picked a register mapping (see ghc/includes/MachRegs.h) and done much of the work to get registerised going on x86_64. I got stalled before because of a bug in gcc, but that's now fixed (in gcc 3.4), so you should be ok. The interesting bit will be doing the native code generator, but you should start from the new NCG in 6.4 if you're interested in working on that. Adding SSE support would be great. Cheers, Simon

2 1