- Glasgow-haskell-users

RE: Parallel
by Simon Marlow 14 Jun '04

14 Jun '04

On 03 June 2004 15:56, Goran Topic wrote: > I am a newcomer to functional programming, and I would like to learn > it very much. However, I'm also starting to deal with parallel > programming, and I thought I'd combine my two interests. > > So I grabbed the Debian ghc6 package (v6.2), and (after a lot of > searching) found out that I lack the "mp" way. Then I tried grabbing > the sources, and compiling them with WAYS=mp, but when the compiler is > compiling the "mp" way, it does so with the -parallel switch, which > requires the "mp" include files - the very ones I am trying to > compile! > > Now, several people tried telling me that GpH is a separate project, > but 1) it's very out of date > 2) ghc source has a ton of PVM references > 3) the ghc user manual mentions parallel code > ...so I kind of figured that GpH got integrated into ghc. The problem > is that I just can't get it to run! The parallel version of GHC is maintained by a separate group, the GPH project, and they do their own releases. There is old, non-working parallel code in the version of GHC we distribute (as you discovered). For the GPH project, go here: http://www.macs.hw.ac.uk/~dsg/gph/ Cheers, Simon

2 1

RE: Handrolled linker?
by Simon Marlow 14 Jun '04

14 Jun '04

On 02 June 2004 18:41, David Brown wrote: > On Wed, Jun 02, 2004 at 06:19:00PM +0100, Duncan Coutts wrote: >> On Wed, 2004-06-02 at 17:44, David Brown wrote: >>> Any estimates on the difficulty of changing Linker.c to be able to >>> use standard dynamic link calls (dlopen, ...) rather than having to >>> be customized for every target platform. >> >> I asked Simon M about this recently: >> >> http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06189.h tml > > Actually, this isn't the question that I have. This is about ghci's > dynamic loading of C objects (or other similar language). There is a > handrolled linker in the ghci code. I'm interested in replacing this > handrolled linker with dlopen... so that it is easier to port. This might work... if the dynamic linker supports doing "ordinary" static-style linking. I've been meaning to try this on Linux. Note that we can't produce proper shared libraries (with position-independent code etc.), but we can produce libraries with relocation info that the dynamic linker can understand. The linker will scribble all over the library at load time, but that's not a problem (our existing linker does that anyway). Cheers, Simon

2 1

Re: IO question (hGetLine)
by Gerd M 14 Jun '04

14 Jun '04

Duncan Coutts wrote: >The GHC run time system is designed to block without using CPU when all >threads are blocked doing IO. >Could you give more details? It would be useful to see the code or >preferably a small test case that demonstrates your problem. What >version of ghc are you using? Which OS are you running that on? I'm using ghc-6.2.1 to compile in 32bit mode while i'm running the program in 64bit (Linux Kernel 2.6.5, amd64) with the 32bit emulation libraries. I don't think that is the problem spot because all other 32bit application are working fine. mainLoop dev = do inp <- hGetLine dev (runIndexCmd . parseInput) inp return () This is called from main with: devHandle <- openFile device ReadMode ................... catchJust asyncExceptions (forever (mainLoop devHandle)) (cleanup devHandle) forever = a >> forever a The module that manages the device puts a process to sleep with interruptible_sleep_on( queue ) if there's no data available and wakes it up as soon as input arrives. As i said before this works when i use "cat". _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

RE: Finalizers and FFI
by Simon Marlow 14 Jun '04

14 Jun '04

To clarify some of the points in this discussion: Alastair is right in that the finalizer thread isn't necessarily run to completion if the main thread exits. GHC does run any outstanding finalizers at the end of the program, but it doesn't necessarily complete any existing finalizer threads that have already started. This is clearly inconsistent, and we were planning to make it consistent by not guaranteeing to run finalizers at program exit at all. There are good reasons (at least, good justifications) for this[1]. If your finalizer results in <<loop>>, it is probably because you tried to write to stdout in the finalizer, and the finalizer ran after stdout had already been finalized. Try calling something lower-level if you want to do some output from a finalizer. We don't implement any kind of finalizer ordering or dependencies between finalizers. There are good reasons for this[1] :-) Cheers, Simon [1] http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html, especially Appendix A.

1 0

RE: GMP
by Simon Marlow 14 Jun '04

14 Jun '04

On 10 June 2004 01:15, John Meacham wrote: > I was curious what the best way would be to access the various useful > GMP functions which are not exported for Integers. I was thinking of > making my own (strict) Integer type, but it would be much easier if I > can just use the FFI to import the required functions and get at the > mpz_t inside Integers somehow. > > I am not positive, but it looks like ghc seems to have primitives > which call the gmp functions internally rather than using the FFI.. > At least I didn't see an obvious example poking around in the library. That's right. Interestingly, I think many of the Integer primitives could be done using the FFI now; this probably wasn't the case when they were originally implemented. Efficiency might be slightly worse, because of the need to allocate temporary MP structs using alloca, compared to using C stack allocation. On other other hand, you'd save a call/return because the primitive would be implemented inline. Also, GHC needs to be able to implement constant folding on Integer primops, which isn't possible when they are defined using the FFI. However, I suspect that constant folding Integer ops is very rarely used at the moment, because the ops aren't inlined due to being too large, so the actual primops are never visible to the compiler. You could implement your own Integer ops using the FFI to call the GMP functions. Take a look at the GMP primops in ghc/rts/PrimOps.hc for hints. Cheers, Simon

1 0

RE: Glasgow Haskell on different versions of Linux
by Simon Marlow 14 Jun '04

14 Jun '04

On 09 June 2004 20:09, Christian Maeder wrote: > I wrote: >>> since version 6.2 we have 2 binary distributions for (generic) >>> linux: for glibc 2.2 and glibc 2.3 >> >> Maybe this is no longer necessary. I've produced an installation >> (under glibc 2.2) that runs under glibc 2.2 and glibc 2.3. > > I've now also successfully installed ghc-6.2.1 from source under glibc > 2.3 that works under glibc 2.2, too. > >> As also Volker Stolz suggested I've changed, after calling >> ./configure, a line in "mk/config.h" from >> >> #define HAVE_CTYPE_H 1 >> >> to >> >> /* #undef HAVE_CTYPE_H */ >> >> >> I'll try the same trick under glibc 2.3 later. > > Yes, that basically did it. Thus the glibc 2.3 version (without > ctype.h) should be sufficient as binary distribution in the future. We want to support glibc 2.2. However, given that it is no longer the predominant flavour of glibc around, we don't want to put a lot of effort into supporting it, or to compromise our support for glibc 2.3. Trying to avoid ctype.h seems pretty fragile. I don't understand why undefining HAVE_CTYPE_H makes things work, and whether it will break anything else. "Avoid ctype.h" is yet another global invariant, and I've learned to avoid those where possible. This strikes me as simply not the right way to go. We can't be sure that there aren't other binary incompatibilies between glibc 2.2 and 2.3. The right way is just to have separate installations for the two systems. Cheers, Simon

1 0

DLLs and shared libraries
by Andrei de A. Formiga 14 Jun '04

14 Jun '04

Greetings, I need to generate DLLs (in Windows) and shared libraries (in unix environments) that expose some Haskell functions (directly or through a C stub). My first option is having ghc generate the libs directly with the foreign export functions. But, searching through the documentation, FAQ, web and some part of the list archives, I didn't find any mention about how to do this. The manual mentions the capability to create DLLs in windows but as not working and unsupported. If this is possible to do in all or most platforms supported by ghc, I would be glad to know how. If it's not, the plan is link object files generated by ghc into a DLL/shared library, maybe using C stubs to call the Haskell functions. I'm going to experiment with this soon, but if there's already some ready-made guide about how to link ghc-generated objects, possibily together with C object files, using ld, that would be great. I suspect I have to refer to all the auto packages during the link. If that's all there's to it, is there a list of all the libs that need to be linked in ? Thanks in advance for any help and sorry if this question is somehow inadequate to the list (I just joined, but have been looking for help for ages). --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

IO question (hGetLine)
by Gerd M 14 Jun '04

14 Jun '04

I've written a Haskell program that reads continuously from a character device that provides data line by line and blocks the reader when there's no data available yet. At the moment performance isn't a real issue so I thought I would give hGetLine a try. Unfortunately the program is consuming a lot of cpu power when the input is blocked which is definitely an issue of hGetLine because this wasn't the case when I tested it with # cat /dev/chardev which waits silently until data is available. Any suggestions? Thanks in advance! Gerd _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Space usage
by Ian Lynagh 12 Jun '04

12 Jun '04

Hi all, My intuition tells me that the code in http://urchin.earth.li/~ian/Mem.hs should have the same space usage regardless of whether USESMEM is defined. However, when compiling with ghc -Wall -O2 -cpp --make Mem -o mem and running ./mem True 100000 > /dev/null it runs in constant space but compiling with ghc -Wall -O2 -cpp -DUSESMEM --make Mem -o mem and running in the same way it increases up to >100M. Is this an instance of GHC not being as smart as it could? Or is it a case in which I need to give it additional strictness annotations in order to get it to run in constant space (and if so, what annotations would be best?)? Thanks Ian

1 0

Re: AMD64
by scott west 12 Jun '04

12 Jun '04

> The amd64 port isn't really there yet. It works unregisterised, but the > registerised support need some more work (as you discovered). You also > need a non-broken version of gcc (3.3.3 or 3.4.0). > > I'd settle for unregisterised... it seems every time I run through the whole port process I see to do some new wrong thing each time, hehe. I'm really just in search of a working ghc implementation for my amd64, registered or not (the main difference is the use of architecture specific registers and thus performance right?). Does anyone have any unregistered amd64 builds that they've cooked up? Regards, Scott

6 10