- Glasgow-haskell-users

RE: Strictness of addition functions.
by Simon Peyton-Jones 15 Mar '02

15 Mar '02

| data Pair = Pair !Int# !Int# | | f (Pair x y) = x +# y | | I still discovered to my dismay that the type of the first | argument to f is U(LL). | | What can I do to force the arguments to be strict? Int# is *always* strict. You don't need the !'s. The L is misleading, I suppose. But since Int# means *unboxed* 32-bit integers, there is simply no way you can pass a thunk. Simon

1 0

Strictness of addition functions.
by Sean Seefried 15 Mar '02

15 Mar '02

Lately, I've been attempting to improve the performance of a highly numerically intensive program. Yet try as I might I cannot seem to define (nor find) an addition function that is strict in both its arguments. Using the advice found in the GHC Users Guide I have looked inside the .hi file and discovered that the functions I define are indeed lazy in their arguments. Even when I try something like data Pair = Pair !Int# !Int# f (Pair x y) = x +# y I still discovered to my dismay that the type of the first argument to f is U(LL). What can I do to force the arguments to be strict? ------------------------------------------------ Sean Seefried School of ITEE The University of Queensland Ph: 3365 8301 Mob: 0416 338 636

1 0

RE: HGL ang GHC on Win32
by Simon Marlow 14 Mar '02

14 Mar '02

> That is a shame. I tried both suggestions (specifying > position explicitly > and recompiling with fvia-c -- i had been using O all along) > and neither > worked :(. > > I also tried using 5.03, and got the following warnings: [ message deleted ] It looks like there are some prototypes missing: > C:\DOCUME~1\hdaume\LOCALS~1\Temp\ghc920.hc:59: warning: implicit > declaration of function `prim_rgb' GHC might not generate correct calls to these functions unless there is a visible prototype. In fact, taking this example, the definition of prim_rgb is DWORD prim_rgb(BYTE arg1,BYTE arg2,BYTE arg3) but its FFI declaration says foreign import ccall "prim_rgb" unsafe prim_rgb :: Word32 -> Word32 -> Word32 -> IO (Word32) this looks a bit strange - is there a green-card expert out there to explain what's going on? Why have the BYTEs been turned into Word32s? Cheers, Simon

1 0

RE: HGL ang GHC on Win32
by Simon Marlow 13 Mar '02

13 Mar '02

> I'm hoping that a GHC honcho will say > > "Well of course that happens with 5.02.2 - you should > upgrade to 5.03 right away." > > or some such. I'm afraid not :-) But there *is* a bug in the native code generator in 5.02.2, namly in the FFI support for passing floating point arguments to ccalls, which I fixed yesterday and could potentially cause this kind of problem. Make sure the graphics library has been compiled with -fvia-C or -O to work around it (and if this helps, please let us know). Cheers, Simon

2 1

RE: how to specify gcc location on ghc command line?
by Simon Marlow 13 Mar '02

13 Mar '02

> ghc-5.02.2 seems to need gcc-2.95.3, but here we have > gcc-3.0.* per default. > There IS a gcc-2.95.3 tree around, but how do I tell ghc about it? You can use 'ghc -pgmcgcc-2.95.3' (unfortunately you can't leave a space between -pgmc and gcc-2.95.3 because of a bug in the command-line handling of this option in 5.02.2). If you build GHC yourself, there's a configure-time option to select which gcc to use, namely --with-gcc=<gcc>. Cheers, Simon

1 0

how to specify gcc location on ghc command line?
by Johannes Waldmann 13 Mar '02

13 Mar '02

ghc-5.02.2 seems to need gcc-2.95.3, but here we have gcc-3.0.* per default. There IS a gcc-2.95.3 tree around, but how do I tell ghc about it? -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0

HGL ang GHC on Win32
by Hal Daume III 13 Mar '02

13 Mar '02

When I compile a program using GHC 5.02.2 on Windows 200 using HGL, using the following command line: > ghc --make HelloWorld.hs -o HelloWorld.exe -package concurrent -package win32 -ic:\GraphicsLibrary\lib\win32 it compiles fine, but then when I run the exe, the window starts out initially as wide as my screen and only as tall as the title bar, regardless of what is passed as the dimensions to openWindow. What gives? If I resize the window everything works fine, but in my own application resizing the window causes it to report some error about arithmetic being bigger than 32 bits... Any ideas? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

GHC for MacOS X
by Wolfgang Thaller 12 Mar '02

12 Mar '02

I've decided to publish another preliminary version of my patches for PowerPC. I think that unregistered compilation works now - I haven't tried to bootstrap ghc using the unregistered compiler yet, but I've had good results with some other programs, most notably the cool QBSP sample program from the HOpenGL distribution. Registerized compilation works only partially. Small programs work fine, but as soon as things get a little more complicated there are segfaults and assertion failures. The patches are relative to the ghc version from CVS from 2002.03.04.15.11.33. I didn't want to risk breaking everything again by following the bleeding edge too closely. For now, I recommend including the following lines in mk/build.mk: GhcUnregistered=YES SplitObjs=NO GhcLibWays= ---- Other notes on the patches: * I've removed the old powerpc/rs6000/aix code from ghc-asm.lprl. * I've butchered the nice use of non-standard syntax in rts/ClosureFlags.c, as it is incompatible with Apple's Objective-C compiler. I've solved this by creating a function InitClosureFlags which sets the correct values. * There is some extra initialization code, which resides in Main.c for now. It should be moved somewhere else. Can someone tell me what the proper place is? I didn't want to break any dependencies by moving it to the wrong place (i.e. too late in the initialization process). * I don't think the patches are ready for CVS checkin yet. Simon Marlow wrote: >These things are particularly tedious to debug (or fun and rewarding, >depending on your particular inclinations :-). Tedious. Very tedious. But when I look back afterwards, I think it was fun and rewarding. Probably that's why it is so addictive... MacOS X users: Please report problems & success stories to me - although I can't promise I will be able to solve the problems. Wolfgang

1 0

RE: Concurrent Haskell (GHC) and Win32 Applications ?
by Simon Peyton-Jones 12 Mar '02

12 Mar '02

| May I assume that, if/when a multithreaded RTS stabilises, | the paradigms from parallell Haskell can easily be | implemented on it ("easily" meaning that it'll probably happen)? Parallelism is never "easy". But it'll certainly be easier. s

1 0

RE: Concurrent Haskell (GHC) and Win32 Applications ?
by Simon Peyton-Jones 12 Mar '02

12 Mar '02

| The problem I think is with the lightweight thread implementation - | Win32 calls can (and will) block the OS thread that makes the call, | which blocks the entire system. Given that I'm wanting to write a | network server with a Win32 GUI, this is obviously a Bad Thing. Yes, that's true at the moment, but it's something that we expect to fix shortly. More precisely, Sigbjorn has been working on a fix. It relies on using an OS thread to make a potentially-blocking call, so it's a robust fix. I don't quite know when he'll be done with this -- Sigbjorn do you know? Meanwhile, all you can do is to avoid making blocking I/O calls. Simon

5 4