headers
Simon Marlow | 2 Jul 2001 17:25
Picon
Favicon

FreeBSD package of 5.00.2 available

FreeBSD users:

Sorry for the wait!  I've finally put a 5.00.2 package for FreeBSD
4.3-STABLE on haskell.org.  To install, this should work:

	$ pkg_add http://www.haskell.org/ghc/dist/5.00.2/ghc-5.00.2.tgz

I'm still ironing out a few wrinkles in the port itself (the above
package was build with a little hand-holding), but when it's done I'll
submit it for inclusion in the ports tree.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Ken Shan | 4 Jul 2001 20:28
Picon

Re: GHC Alpha port?

OK-- I'm probably not the most qualified person to try to port GHC to
the Alpha, but my attempt begins...

To get started, I want to generate .hc files using my existing
ghc-5.00.2 installation on my i386-unknown-linux box.  I tried to
follow the steps in

    http://www.cs.uu.nl/~atze/Programming/GHC/cp-b1-b2-all

as follows.  First I create a shadow directory tree and configure:

    mkdir c1 c1-obj
    cd c1
    lndir ../ghc-5.00.2
    ./configure --prefix=$PWD-obj

Second I create c1/mk/build.mk:

    GhcHcOpts    += -H24m -keep-hc-files-too -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER
-fno-asm-mangling -funregisterised -fvia-C
    GhcRtsHcOpts +=                          -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised -fvia-C
    SplitObjs     = NO

Then I ran "make".  It stopped in c1/ghc/rts, at:

    ../../ghc/compiler/ghc-inplace -optc-O -optc-O2 -optc-fomit-frame-pointer -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wbad-function-cast -optc-DCOMPILING_RTS -ldl -I../includes -I.
-Iparallel -O2 -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised
-fvia-C -DCOMPILING_RTS -static -c Adjustor.c -o Adjustor.o
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 5 Jul 2001 11:34
Picon
Favicon

RE: GHC Alpha port?

Hi Ken,

    GhcHcOpts    += -H24m -keep-hc-files-too -optc-DNO_REGS
-optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised -fvia-C
    GhcRtsHcOpts +=                          -optc-DNO_REGS
-optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised -fvia-C
    SplitObjs     = NO

This isn't right: you shouldn't set GhcHcOpts in the first build.  In
the URL you gave, this line was commented out.  That's certainly the
reason for the core dumps.

In GHC 5.00.2, there's an easier way.  For the c1 & c2 builds, you can
just set

	GhcUnregisterised = YES

in build.mk, and you can set $long to empty.

When you get around to bootstrapping on the Alpha, I'll probably need to
help you some more, because bootstrapping from .hc files is quite tricky
on 5.00.

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Jose Emilio Labra Gayo | 6 Jul 2001 18:47
Picon

2 questions regarding ghci and --make

I have just built ghc-5.00.2 and I have 2 questions:

1.- What is the option that I have to change to build the system for
interactive use? At this moment, when I run "ghci", I obtain

	$ ghci
	ghc-5.00.2: not built for interactive use

2.- If I want to have modules in separate directories. How can I tell
"--make" to look for them? 
For example, imagine that I have the following configuration:

	DirectoryA contains file A.hs
	DirectoryB contains file B.hs
	
And I have "Main.hs" which imports "A" and "B". 
Is there a nice way to compile it?

Regards, Jose Labra
Permalink | Reply | 1 comment |
headers
Volker Stolz | 8 Jul 2001 10:31

Re: 2 questions regarding ghci and --make

In local.glasgow-haskell-users, you wrote:
>1.- What is the option that I have to change to build the system for
>interactive use? At this moment, when I run "ghci", I obtain

You have to rebuild ghc-5 with the compiler you just built. Then
you will get a running ghci.

>2.- If I want to have modules in separate directories. How can I tell
>"--make" to look for them? 

Use the same options as you´d use for plain ghc: -i

Saludos,
  Volker
--

-- 
Volker Stolz * vs <at> foldr.org * PGP + S/MIME
Permalink | Reply | 0 comments |
headers
Greg Mildenhall | 9 Jul 2001 22:14
Picon

Concurrent Haskell problem/bug

I posted this on comp.lang.functional and someone suggested I try here.
Apologies if it's not on-charter here - any redirections appreciated.

I'm seeing unexpected behaviour from GHC 5. (unexpected by me, anyway :)

The code which is producing the surprising results is at the bottom, but
I'll breifly explain how it is meant to work here:

ppm' spawns three threads, and hands them all an MVar.
Each thread just puts a True into that MVar and exits.
ppm' takes three values in turn from the MVar and makes sure they are all
True - if it sees a False value, it stops looking. Once it has assessed
whether they have all returned true, it kills all of its child threads
before returning the result of the assessment.

In this case, where each child returns True, the threads will have already
exited, but my understanding is that they are not GCed while ppm' has a
reference to their ThreadIds, so ppm' is still allowed to kill them.

The ppm' function is "done" 11 times (but some slightly modified versions
caused me to need up to a hundred invocations in order to see the problem,
so if you don't see the problem on your GHC, try > 11) and each invocation
is wrapped up in an unsafePerformIO. (I don't think the unsafePerformIO
should be a problem, because there oughtn't be any interaction between the
seperate ppm' instances.)

Some of these 11 seem to return the expected result, but one of them
doesn't. The output is this:
---------------------------
(1,True)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Mildenhall | 9 Jul 2001 22:17
Picon

Re: Concurrent Haskell problem/bug

OK, it appears that I am a complete fool. My first post on this list and I
forget to include the code I'm writing about.

-Greg

-----------------------------------------------------------------
import Concurrent
import IOExts

awk' x = (unsafePerformIO ppm',x)

ppm'  = do m <- newEmptyMVar
           hs <- sequence [forkIO (f m) | f <- replicate 3 (flip putMVar
True)]
           result <- assess 3 m
           sequence (map killThread hs)
           return result
             where assess 0 m = return True
                   assess n m = do h <- takeMVar m
                                   if h then (assess (n-1) m)
                                        else (return False)

main = sequence [putStrLn ( show (x,unsafePerformIO ppm')) | x <- [1..11]]

-----------------------------------------------------------------

On Tue, 10 Jul 2001, Greg Mildenhall wrote:

> I posted this on comp.lang.functional and someone suggested I try here.
> Apologies if it's not on-charter here - any redirections appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Shan | 10 Jul 2001 02:47
Picon

Re: GHC Alpha port?

On 2001-07-05T10:34:27+0100, Simon Marlow wrote:
> This isn't right: you shouldn't set GhcHcOpts in the first build.  In
> the URL you gave, this line was commented out.  That's certainly the
> reason for the core dumps.

Ah!  Careless me.  Thank you.

> In GHC 5.00.2, there's an easier way.  For the c1 & c2 builds, you can
> just set
> 	GhcUnregisterised = YES
> in build.mk, and you can set $long to empty.

This seems to have worked.  By the way, the "old way" (as specified in
the MacOS port readme) does not work with ghc 5 -- I got a seg fault
when running ghc-inplace during the second stage.

> When you get around to bootstrapping on the Alpha, I'll probably need to
> help you some more, because bootstrapping from .hc files is quite tricky
> on 5.00.

I'm there!

The first obstacle I encountered is that PackedString.raw_s seems to
be mangled incorrectly.

    PWD = /a/lair62/vol/vol0/home/ccshan/u/ghc-port/alpha/hslibs/lang
    ------------------------------------------------------------------------
    gcc -x c PackedString.hc -o PackedString.raw_s -S -O   -D__GLASGOW_HASKELL__=500  -O
-I/a/lair62/vol/vol0/home/ccshan/u/ghc-port/alpha/ghc/includes
-I/a/lair62/vol/vol0/home/ccshan/u/ghc-port/alpha/ghc/lib/std/cbits
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 10 Jul 2001 11:31
Picon
Favicon

RE: Concurrent Haskell problem/bug

> I posted this on comp.lang.functional and someone suggested I 
> try here.
> Apologies if it's not on-charter here - any redirections appreciated.
> 
> I'm seeing unexpected behaviour from GHC 5. (unexpected by 
> me, anyway :)

Hi Greg,

As it happens I saw your post on comp.lang.functional and we fixed the
bug last week :-)  (I replied to the newsgroup, but our news is a bit
flaky here so you may not have seen it).

Yes, you found a genuine bug in take/putMVar that appeared when the
semantics of putMVar changed to allow it to block when the MVar is full.
To work around the problem, don't rely on this behaviour of putMVar and
either use one of the other Concurrent Haskell datatypes (eg. Chan) or
use a second MVar to act as a "lock" on the first one.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 10 Jul 2001 11:24
Picon
Favicon

RE: GHC Alpha port?

Hi Ken,

> On 2001-07-05T10:34:27+0100, Simon Marlow wrote:
> > This isn't right: you shouldn't set GhcHcOpts in the first 
> build.  In
> > the URL you gave, this line was commented out.  That's certainly the
> > reason for the core dumps.
> 
> Ah!  Careless me.  Thank you.
> 
> > In GHC 5.00.2, there's an easier way.  For the c1 & c2 
> builds, you can
> > just set
> > 	GhcUnregisterised = YES
> > in build.mk, and you can set $long to empty.
> 
> This seems to have worked.  By the way, the "old way" (as specified in
> the MacOS port readme) does not work with ghc 5 -- I got a seg fault
> when running ghc-inplace during the second stage.

Hmm, I should really add a section to the building guide on porting and
unregisterised compilation.

> > When you get around to bootstrapping on the Alpha, I'll 
> probably need to
> > help you some more, because bootstrapping from .hc files is 
> quite tricky
> > on 5.00.
> 
> I'm there!
(Continue reading)

Permalink | Reply | 1 comment |

Gmane