RE: Can't run hello-world program in ghc-4.01

1998-12-03 Thread Simon Marlow
> Hi. I have just downloaded and installed (in-place) > ghc-4.01. I tried testing it by compiling the sample program > > main = putStr "Hello, world!\n" > > with > > ghc -o hello Main.hs > > This compiles without complaint (only an observation that > "ghc: module version changed to 1; reas

RE: Can't run hello-world program in ghc-4.01

1998-12-04 Thread Manuel M. T. Chakravarty
Simon Marlow <[EMAIL PROTECTED]> wrote, > > Hi. I have just downloaded and installed (in-place) > > ghc-4.01. I tried testing it by compiling the sample program > > > > main = putStr "Hello, world!\n" > > > > with > > > > ghc -o hello Main.hs > > > > This compiles without complaint (only

RE: Can't run hello-world program in ghc-4.01

1998-12-04 Thread Herbert Graeber
It looks like some platforms have problems with memory mangement. I observed a similar problem with the Win32 binary, too. On Windows NT everything is OK. Using Windows 95/98 (on my home machine) I have got the message: getMBlocks: MapViewOfFileEx failed with: 487 TEST.EXE: fatal error: G

RE: Can't run hello-world program in ghc-4.01

1998-12-07 Thread Sigbjorn Finne (Intl Vendor)
Hi, Herbert Graeber [mailto:[EMAIL PROTECTED]] writes: > > It looks like some platforms have problems with memory > mangement. I observed a similar problem with the Win32 > binary, too. On Windows NT everything is OK. > Using Windows 95/98 (on my home machine) I have got the > message: > >

RE: Can't run hello-world program in ghc-4.01

1998-12-04 Thread Simon Marlow
> Is N very high? If not, why not just allocate N - 1 bytes > too much and then advance the pointer to the memory block to > the next N-byte boundary? N is a megabyte by default. I don't like doing too many mmaps, especially mmaping more memory than we need, because some operating systems tend

Another ghc-4.01 Problem (Was: Re: Can't run hello-world program in ghc-4.01)

1998-12-08 Thread Herbert Graeber
Sigbjorn Finne (Intl Vendor) <[EMAIL PROTECTED]> writes >[...] >The base address is still 0x5000 though - if this >turns out to interact badly with other allocators, we'll elaborate on >the code that picks the base address to allocate from. I am not 100% sure you should use a fixed base ad