- Glasgow-haskell-users

RE: GHC Alpha port?
by Simon Marlow 10 Jul '01

10 Jul '01

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! Great, you're in uncharted territory now :-) (no-one has bootstrapped from unregisterised .hc files with 5.00 yet...) > The first obstacle I encountered is that PackedString.raw_s seems to > be mangled incorrectly. Ok, for unregisterised building we need to disable the mangler. You should be able to just compile the .hc files directly using gcc, but you'll need to make sure that -DNO_REGS and -DUSE_MINIINTERPRETER are added to gcc's command line. The relevant makefile code is in fptools/mk/bootstrap.mk - I'm sure you'll be able to modify it to do the right thing. When you've got it working we'll think about how to set up the bootstrapping system so mangling is optional. (if you're wondering why this is harder than it used to be with 4.08, it's because we used to have the "driver" written in Perl, and the driver knew all about compiling .hc files. Now the driver is in Haskell and part of the compiler itself, we have to manage without it during bootstrapping, hence the new bootstrap.mk makefile) Cheers, Simon

2 1

RE: Concurrent Haskell problem/bug
by Simon Marlow 10 Jul '01

10 Jul '01

> 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

1 0

RE: GHC Alpha port?
by Simon Marlow 10 Jul '01

10 Jul '01

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

2 1

Concurrent Haskell problem/bug
by Greg Mildenhall 09 Jul '01

09 Jul '01

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) (2,True) (3,True) (4,True) (5,True) (6,True) (7,True) (8,True) (9,True) (10,True) PPM: no threads to run: infinite loop or deadlock? --------------------------- So there _does_ seem to be a strange interaction between seperate occurrences of ppm'. Can anyone see how that is happening? (of course the other possibility is that I've done something really silly in my code and not noticed, but I'm happy to take suggestions on that front, too. :) If noone here can see what is causing it, is anyone here brave enough to say "this is probably a GHC bug" and recommend how best I report it? Thanks for any insight you can offer me. -Greg Mildenhall

1 1

2 questions regarding ghci and --make
by Jose Emilio Labra Gayo 08 Jul '01

08 Jul '01

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

2 1

RE: GHC Alpha port?
by Simon Marlow 04 Jul '01

04 Jul '01

> A few users at our site have asked about running GHC on Alpha > machines. In addition to following the instructions at > http://www.haskell.org/ghc/docs/4.08.2/building/sec-port-info.html > I'm also personally curious about what work would involved in making > GHC work again on Alphas. Could someone give an overview? Sure: the first thing to do is to get GHC running "unregisterised" on your platform. This means building an unregisterised set of .hc files with GHC on a supported platform, shipping these to the Alpha and bootstrapping using them. A couple of people did this recently for MacOS/X (using GHC 4.08.X), so you should be able to get more detailed instructions from the mailing list archives. There will also be some porting effort involved in getting 64-bit support going again. There are sure to be some accidental 32-bit dependencies in the RTS, but they won't be fatal - the RTS was designed to be word-size independent, it just hasn't been used on a 64-bit platform up to now. Once you have an unregisterised build working (& bootstrapped), you can start trying to get the mangler going for full registerised support. The mangler has Alpha support, but it is old and bound to be rotten to some extent. One other thing: you'll probably be better off starting from 4.08.2, because 5.00 has some problems with hc-bootstrapping at the moment. We'll be happy to help out if you get into difficulties.... good luck! Cheers, Simon

2 1

FreeBSD package of 5.00.2 available
by Simon Marlow 02 Jul '01

02 Jul '01

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

1 0

E-mail Marketing Products
by Bee Gee Marketing 02 Jul '01

02 Jul '01

1 0

Re: problems with haxml
by Marcin 'Qrczak' Kowalczyk 30 Jun '01

30 Jun '01

Fri, 29 Jun 2001 09:15:13 -0000, Siemens Entwicklungsteam <haskellsparte(a)hotmail.com> pisze: > XmlParse.o(.text+0x20):fake: undefined reference to `__init_IOExts' This suggests lack of -package lang option during linking. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: problems with haxml
by Simon Marlow 29 Jun '01

29 Jun '01

> we are developing haskell programs with XML interfaces (using > haxml). So > far, we tested all our source files in HUGS98, which always > worked fine. > Now we have to compile them with ghc(version 4.08.2 with > Cygwin in Windows > NT) which causes several errors. Linking Xml2Haskell.o, XmlParse.o, > XmlTypes.o etc. to it reduced the number of errors a lot. The > only one that > is left now is the following one: > > XmlParse.o(.text+0x20):fake: undefined reference to `__init_IOExts' It looks like you've compiled up HaXml yourself, right? You don't actually need to do that - HaXml comes with GHC in package text. But anyway, the IOExts module comes from package 'lang', which must have been used in order to compile HaXml. All you need to do is to add '-package lang' to the GHC command line when linking, and GHC will link in the correct libraries. Cheers, Simon

1 0