- Glasgow-haskell-users

RE: wait(2)
by Simon Marlow 26 Jul '01

26 Jul '01

> Is there a way in Glasgow Haskell to get a thread to wait on > a child process > in the same way as the Posix function wait(), and get the > termination status > of the child? If so, how? There's a couple of ways. The obvious way is to get the thread to place its result in an MVar when it exits: there's a guarantee that a thread always either exits or raises an exception, so you can wrap the top-level computation in something that places the result/exception in an MVar. Alternatively, you can foreign import rts_evalIO() and do it that way. It ought to work, but I haven't tried it. This way lets you get at the Interrupted or Deadlocked return states too, which you can't do solely within Haskell. Hmm, now I think about it, the compiler won't let you foreign import rts_evalIO() with the type you want, namely a -> Ptr b -> IO CInt, and quite rightly so. You'll need a version of rts_evalIO() that takes StablePtrs instead. Cheers, Simon

1 0

Rationals
by Amanda Clare 26 Jul '01

26 Jul '01

Does anyone know how I use Rationals in ghc? In nhc I can just write let a = b % c But ghc-5.00.2 gives the error message "Variable not in scope: `%'" I've looked through the documentation and can't find any reference to a Rational library, or any other library that might have it. The package "std" has a Ratio.hi in the lib/imports directory (std isn't described in the documentation) but including this doesn't help - same error. The Haskell98 report says: "In particular, the type Rational is a ratio of two Integer values, as defined in the Rational library." Any ideas? Amanda -- Amanda Clare http://users.aber.ac.uk/ajc99/ Tel: +44 (0)1970 621922 Fax: +44 (0)1970 622455 Dept. of Computer Science, University of Wales, Aberystwyth, SY23 3DB

1 1

Re: Trying to make Hood work with GHC
by Mike Gunter 25 Jul '01

25 Jul '01

Below are the diffs I used to get from the 4.08 version to one that compiles and seems to work with 5.00. mike diff -c -a -r1.1 Observe.lhs *** Observe.lhs 10 Jan 2001 16:21:12 -0000 1.1 --- Observe.lhs 25 Jul 2001 16:44:09 -0000 *************** *** 107,113 **** \begin{code} import Exception ( catchAll ! , Exception(..) , throw , catchAllIO ) --- 107,113 ---- \begin{code} import Exception ( catchAll ! , Exception(..), IOException , throw , catchAllIO ) *************** *** 269,275 **** generate an IOError with a bottom in it, your just asking for trouble. \begin{code} ! instance Observable IOError where { observer = observeBase } \end{code} Functions. --- 269,275 ---- generate an IOError with a bottom in it, your just asking for trouble. \begin{code} ! instance Observable IOException where { observer = observeBase } \end{code} Functions. Alain Cremieux <alcremi(a)pobox.com> writes: > Hi, > I'm currently trying to have Hood work with GHC, but I have some > problems > - I have succeeded in using the hugs version of Hood > - I have dowloaded the GHC version (slightly different) but the > compilation of the 'Observe' modules fails (the module is supposed to > work with GHC 4.08 and I have GHC 5.00.2) : ...

2 1

Trying to make Hood work with GHC
by Alain Cremieux 25 Jul '01

25 Jul '01

Hi, I'm currently trying to have Hood work with GHC, but I have some problems - I have succeeded in using the hugs version of Hood - I have dowloaded the GHC version (slightly different) but the compilation of the 'Observe' modules fails (the module is supposed to work with GHC 4.08 and I have GHC 5.00.2) : Duplicate instance declarations: Observe.lhs:272: Observable IOError Observe.lhs:291: Observable Exception with the following command-line : ghc -fglasgow-exts -package lang -package concurrent Observe.lhs corresponding to the source : instance Observable IOError where { observer = observeBase } instance Observable Exception where observer (IOException a) = send "IOException" (return IOException << a) observer (ErrorCall a) = send "ErrorCall" (return ErrorCall << a) observer other = send "<Exception>" (return other) I don't understant why there are duplicate instance declarations. Furthermore, removing them leads to : Observe.lhs:182: No instance for `Observable Exception' arising from use of `<<' at Observe.lhs:182 In the second argument of `send', namely `((return throw) << exc)' In the first argument of `return', namely `(send "throw" ((return throw) << exc) context)' Changing names (of Observable...) does not help, so its is not a name conflict with prelude or libraries The source is avalaible at : http://haskell.cs.yale.edu/hood/downloads/ghc/Observe.lhs (I don't include it here so the M.L. won't be cluttered) If somebody can help, I am completely at a loss Alain

1 0

createAdjustor for Alpha (and Sparc)
by Ken Shan 25 Jul '01

25 Jul '01

Hello again, It seems that I have a registerised GHC mostly working on the Alpha. The main missing piece is createAdjustor. My understanding of (the _ccall rather than _stdcall part of) createAdjustor is as follows: Given "hptr" and "wptr" of types void *hptr; {return type} (*wptr)(void *, void *, {more arguments}); createAdjustor creates "adjustor" of the type {return type} (*adjustor)({more arguments}); such that calling (*adjustor)({argument values}) is equivalent to calling (*wptr)(hptr, {undefined/ignored pointer}, {argument values}). This goal seems difficult to achieve on the Alpha, since its complicated calling convention puts arguments in registers, and we don't know how many arguments there are, let alone how to adjust the stack if needed. But wait! There's a Sparc port of createAdjustor already, and the Sparc passes arguments in registers too! How was that done? I pored over the #ifdef sparc_TARGET_ARCH code in Adjustor.c, and couldn't understand. It puts hptr in %o0 and wptr in %o1, where I assume %o0 is where the first argument is expected in _ccall, but what about shifting over {more arguments}? In any case, given that many architectures pass arguments in registers nowadays, what seems like a more universally workable approach to me is to pass hptr not as a regular function call argument but inside a special register that the called stub function (i.e., *wptr) knows about. This register must be caller-save and must not be involved in the usual prologue sequence generated by gcc. I'd guess that the following would work: i386 %eax alpha $0 = $v0 sparc %g7 This new scheme would involve changing DsForeign.lhs to output different _ccall stub code. Would it work? Any demystification would be greatly appreciated. (By the way, why can't we use $0 and $1 on the Alpha? Only $2 and up are assigned in MachRegs.h.) -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig « ne gâche pas ta vie pour leur idée de patrie » le bouton me dit

2 1

RE: Booting from HC files is completely broken
by Simon Marlow 24 Jul '01

24 Jul '01

> I tried to compile ghc-5.00.2 on a RedHat-7.1 system by booting from > HC files. (Actually, I have a ghc-5.00 installed, but apparently some > programs compiled with it segfault, and this makes compilation of > ghc-5.00.2 impossible. Note that I have a working happy-1.10, > however.) > > Now it seems that the distrib/hc-build script is broken. Yes it is, sorry about that. There are several open bug reports on SourceForge relating to the broken hc bootstrapping situation. I'm working on fixing it, so hopefully the next release will have reliable hc bootstrapping again. Your particular problem can be solved by (a) getting the .hs files that are generated from the .hsc files in the libraries, and (b) making in ghc/lib/std and hslibs before ghc/utils. Having the .hs files means you don't need hsc2hs in order to build the libraries and works around the chicken/egg problem. Cheers, Simon

1 0

Booting from HC files is completely broken
by David Madore 24 Jul '01

24 Jul '01

Hi all. I tried to compile ghc-5.00.2 on a RedHat-7.1 system by booting from HC files. (Actually, I have a ghc-5.00 installed, but apparently some programs compiled with it segfault, and this makes compilation of ghc-5.00.2 impossible. Note that I have a working happy-1.10, however.) Now it seems that the distrib/hc-build script is broken. First of all, this is a minor point, but it calls ./configure twice, and the second time it omits passing $configopts to it, so that anything like --prefix will fail. But this is not the problem I have. To avoid the above gotcha, I manually drove the various commands. Up to the second invocation of "configure", everything works fine. I end up with a working ghc-inplace (well, it seems to work). But no interface (.hi) files. How on earth are these supposed to be generated? The hc-build script calls ./configure a second time; now that does not find a working ghc (of course: it doesn't know about the just built ghc-inplace), so GHC="" in the Makefiles, and the attempt to make all in ghc/utils fails miserably (in a ridiculous way, in fact: since GHC="", the next argument on the command line, viz. "-ldl", becomes the command, and GNU make looks for a program called "ldl", doesn't find it, and ignores the error because of the prepended "-"; similarly, some "-o" commands look for a program named "o" and ignore the error). I tried passing GHC to point to the ghc-inplace program built, but that doesn't work either (missing interface files, so ghc/utils can't be built; and ghc/libs can't be built because of the missing ghc/utils). It seems that we still have a chicken-and-egg problem which the .hc files have done nothing to solve. Any suggestion (other than starting from a binary build, which is what I suppose I'll try now)? (Note: I'm not subscribed to the list. Please Cc me all replies.) -- David A. Madore (david.madore(a)ens.fr, http://www.eleves.ens.fr:8080/home/madore/ )

1 0

RE: Profiles in GHC
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

There's a whole section in the user manual about profiling (http://haskell.org/ghc) You can find a paper or two about the underlying ideas on my publications page under "Profiling". http://research.microsoft.com/~simonpj/Papers/papers.html#profiling The GHC 4.08 distribution for Win32 should have profiling, and I *think* the GHC5 thrill-seekers release does too, but Reuben can confirm. Incidentally, there's a special list for GHC users, glasgow-haskell-users(a)haskell.org <mailto:ghc-users@haskell.org> , to avoid troubling the main Haskell list Simon -----Original Message----- From: Andre W B Furtado [mailto:awfurtado@uol.com.br] Sent: 21 July 2001 01:07 To: haskell(a)haskell.org Subject: Profiles in GHC Can anyone give me a brief explanation (or show me where in the web I can find some info) about using the profiling library in GHC? Is it avaible for Windows 98/NT? Thanks in advance, Andre W B Furtado

1 0

linking with c++ libraries
by Corneliu Popeea 21 Jul '01

21 Jul '01

I'm trying to use from Haskell a C++ library (Omega Calculator). I'm using the following command: ghc -c -fglasgow-exts -package lang main.hs ghc main.o mylib.o -lomega -lstdc++ -fglasgow-exts -package lang Do I need to add more options? The compilation went fine (after I added -lstdc++ which is invoked by default by "g++", but not by "ghc"), but the executable generates a core. Omega library used from a C++ file, with the same call, and same parameters runs ok. Best regards, Corneliu

2 1

New InstallShield: GHCi 5.01 "Borag Thungg"
by Reuben Thomas 19 Jul '01

19 Jul '01

I've updated the test Windows InstallShield of GHCi 5.01 available from http://www.haskell.org/ghc/dist/5.00.2/ghc-5-01.exe (There's no link to it on the web site) In case you missed the previous announcement, this is a test release, but seems fairly stable (I use it all the time). It has the following features: * GHCi: now you can use GHC interpretively under Windows. You can just run the InstallShield, and double-click on GHCi to get going. * Complete install: everything you need to use GHC is included; Cygwin is no longer required; also, unlike recent 4.08.2 releases, it doesn't interfere with any Cygwin installation you may already have Changes from the previous test release, "Zarjaz": * Now installs in Program Files by default (supports paths containing spaces). * Installs the profiling libraries and imports (the previous test release included them, but for mysterious reasons they weren't actually installed). Also note that as one user found, the supplied gcc doesn't like identifiers containing top-bit-set characters, so if you want to use them you must use the native code generator.

1 0