July 2002 - Glasgow-haskell-users

new RTS interface problem with ghc-5.04
by Keean 17 Jul '02

17 Jul '02

I have just moved to ghc-5.04 to try the threaded runtime, however some code I have to do dynaminc module loading using the rts linker will not compile, failing with: RtsAPIDeprec.o undefined reference to Addr_Azh_con_info (in rts_mkAddr) this symbol appears to be defined in libHSlang.a, and I have a -syslib lang in the compile command... what's wrong here? secondly, if this interface is deprecated, (I presume this is something to do with the FFI?) where am I using rts_mkAddr and rts_getAddr, would that be in addrToHValue, and if so what is the non-deprecated way of doing this? Keean Schupke Department of Electrical & Electronic Engineering, Imperial College.

2 1

RE: Unregisterised build
by Christoph Reichenbach 16 Jul '02

16 Jul '02

Hi, [...] > BTW the cross-port script is a little old, so you might find other > problems. As far as I know, unregisterised compilation *does* work > though. I had to do a number of manual compiles, out-of-order makes etc. to get stuff working; I'm not completely convinced that what I'm trying to do is right ATM... [...] > Your best bet for the .hsc files is to generate the .hs on your > Alpha/Linux box by taking the intermediate _hsc.c files over and > compiling/running them on the target machine to get the .hs files. Then > take the .hs back to the bootstrapping machine and carry on. These are > the libraries in stage 1, BTW. Did that. [...] > The cross-port script also tries to do too much. You won't be able to > actually run the b2 compiler on your bootstrap box, because it will be > built against the Alpha/Linux-specific libraries, so just stop after > you've got a set of .hc files for ghc/compiler in stage 2. Take the > library .hc files from stage 1, and the compiler .hc files from stage 2, > to your Alpha/Linux box. That's where I am now. Running the distrib/hc-build script dies pretty early on in the ghc subdir: ... copying ./mpn/generic/sb_divrem_mn.c to mpn/sb_divrem_mn.c copying ./mpn/generic/jacbase.c to mpn/jacbase.c copying ./mpn/alpha/gmp-mparam.h to gmp-mparam.h ../utils/ghc-pkg/ghc-pkg-inplace --update-package <rts.conf.inplace /bin/sh: ../utils/ghc-pkg/ghc-pkg-inplace: No such file or directory make[1]: *** [boot] Error 127 I tried building that manually, but it seems to be relying on the presence of a large amount of libraries (I have all its object files, but they're worthless without the libs). 'make' in ghc/compiler dies with: gcc -x c absCSyn/AbsCSyn.hc -o absCSyn/AbsCSyn.raw_s -S -O -mieee -static -w -D__GLASGOW_HASKELL__=505 -O -I/home/jameson/work/port/haskell/build/ghc/includes -I/home/jameson/work/port/haskell/build/libraries/base/include -I/home/jameson/work/port/haskell/build/hslibs/lang/cbits -I/home/jameson/work/port/haskell/build/hslibs/posix/cbits -I/home/jameson/work/port/haskell/build/hslibs/util/cbits -I/home/jameson/work/port/haskell/build/hslibs/text/cbits -I/home/jameson/work/port/haskell/build/hslibs/hssource/cbits -Iparser -I. -I../includes -O -D__GLASGOW_HASKELL__=505 -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` absCSyn/AbsCSyn.hc:2: HsStd.h: No such file or directory absCSyn/AbsCSyn.hc:46: macro `SET_HDR_' used with only 3 args absCSyn/AbsCSyn.hc:174: macro `SET_HDR_' used with only 3 args [...] followed by more of the same. The only fitting SET_HDR_ seems to be in common-rts/includes/StgMacros.h. I'm not sure which of the two approaches I should pursue now and where to look for solutions to these problems (HsStd.h in particular managed to evade all attempts to find(1) it); any ideas or suggestions? > At some point we'll try to make all this easier, but I'm afraid that's > the way it is at the moment :-( NP, it's quite interesting (in a masochistic kind of way ;) Thanks for your help so far, llap, Christoph

1 0

RE: make -j2 fails on SMP with ghc-5.04
by Simon Marlow 16 Jul '02

16 Jul '02

> I have a dual Athlon box, make -j2 fails, but make works. > Is that normal? I did some tweaking to the build system to help -jN builds, but I haven't tested a complete build this way. Whereabouts does it fall over for you? Cheers, Simon

2 1

RE: profiling objects (segmentation fault)
by Simon Peyton-Jones 16 Jul '02

16 Jul '02

It's still on our to-do list, and we've just thought of a nice way to do it too. So it's just moved up into "let's do it" status. Thanks for the reminder Simon | -----Original Message----- | From: MR K P SCHUPKE [mailto:k.schupke@ic.ac.uk] | Sent: 15 July 2002 17:20 | To: glasgow-haskell-users | Subject: profiling objects (segmentation fault) | | | I know this has been discussed before, but I can't remember the | conclusion and nothing seems to have | been done, so I am going to bring it up again. | | Is there any way the compiler can mark object files with whether they | are profiling or not, so that you cannot | link a profiled object with a non-profiled one. It seems | quite bad that | the program appears to compile and then | fails with a segmentation fault. Perhapse all profiling symbols could | have "prof" appended - so they will not link | against non-profiling symbols of the same name? | | Keean Schupke. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

RE: replacing the Prelude (again)
by Simon Peyton-Jones 16 Jul '02

16 Jul '02

| Ambiguities in the class Num are most common, so Haskell | provides another | way to resolve them---with a default declaration: | default (t1 , ... , tn) | where n>=0, and each ti must be a monotype for which Num ti holds. | ^^^^^^^^^^ | In situations where an ambiguous type is discovered, an | ambiguous type | variable is defaultable if at least one of its classes is | a numeric class | (that is, Num or a subclass of Num) and if all of its | classes are defined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | in the Prelude or a standard library | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Each defaultable variable is replaced by the first type in | the default list | that is an instance of all the ambiguous variable's | classes. It is a | static error if no such type is found." | | Do these become "whatever Num is in scope" when I use | -fno-implicit-prelude, and "whatever classes from standard | libraries" are in scope? If they don't then I think I'm in a pickle. I confess that I had forgotten about this. It's not easy to see what a good alternative design would be... I suppose it could be "whatever Num is in scope or a subclass thereof", but what would correspond to "defined in the Prelude or a standard lib"? An alternative would be to drop the rule altogether with -fno-implicit-prelude and let all ambiguous types be defaulted with the specified list of types. The motivation for the rules as stated is to avoid excessive defaulting, which silently affects the meaning of your program. As you say, the absence of an obvious design point means I'm unlikely to fiddle just now. If a consensus emerges (and it's not to hard to do) I'd be willing to fiddle, though. Simon

1 0

profiling objects (segmentation fault)
by MR K P SCHUPKE 15 Jul '02

15 Jul '02

I know this has been discussed before, but I can't remember the conclusion and nothing seems to have been done, so I am going to bring it up again. Is there any way the compiler can mark object files with whether they are profiling or not, so that you cannot link a profiled object with a non-profiled one. It seems quite bad that the program appears to compile and then fails with a segmentation fault. Perhapse all profiling symbols could have "prof" appended - so they will not link against non-profiling symbols of the same name? Keean Schupke.

1 0

RE: package name mismatch
by George Russell 15 Jul '02

15 Jul '02

Simon Marlow quoted Max Kirillov [snip] > > Building htk, I've got an error: > >=20 > > TestGetPut.hs:6: > > Module `GetPut' is located in package `Main' > > but its interface file claims it is part of package > > `uni-events-test' > >=20 > > It happened (as far as I got) when ghc saw in current path > > the *.hi file built for installation. There are some ways to > > work around it, but, there was a lot of such places, so can > > I just skip the 'package name' check and go as it is? > > This was converted to a warning in, I think, ghc 5.02.3. Please > upgrade, preferably to 5.04. [snip] It must have been only a warning in 5.02.3, or I could never have compiled it there. (Before 5.02.3 we didn't use the package system like this at all.) Actually I would like this message to go away altogether in this case, if possible. The actual situation is that GetPut.hs is in fact part of the package "uni-events-test", and the compiler is told to load uni-events-test on the command line. However GetPut.hs is *also* in the current directory during this compilation, so GHC loads it from there instead. I'm not sure what logic would be best here, but my suggestion would be that where a .hi file is found in an import declaration and has an unexpected package name, GHC keeps on searching. If it finds a .hi file with a matching package name, it accepts it, otherwise accept the .hi file with the wrong package name and issue a warning. If that's too complicated, just ignore .hi files with the wrong package name. But then people might complain . . . [ - for Max's eyes only - As a matter of fact, this file is not needed for uni-htk anyway (it's just part of a test case) so Max could just work around it. If you just do "gmake package" rather than "gmake" or "gmake all" I don't think it will occur, though that will also mean the test programs don't get made. If you want the HTk examples go into htk/examples and do "gmake main" and/or "gmake test" there. - ]

1 0

RE: Weird profiling behaviour
by Simon Marlow 15 Jul '02

15 Jul '02

> >> The default definition of sortBy uses insertion sort > > > I have vague recollection of the wisdom of this choice being > > questioned > > And now I think I'm about question it as well... 5.02 uses quicksort, but 5.04 will use mergesort instead which has much more predictable performance behaviour. Cheers, Simon

6 6

Re: replacing the Prelude (again)
by Bernard James POPE 15 Jul '02

15 Jul '02

Hi again, Malcolm writes: > We came across the same problem in the Hat tracer (which is also a > source-to-source transformation, and can also be used for debugging). > > The problem is that the transformation introduces new classes, so > Prelude.Ord -> HatPrelude.Ord > Prelude.Eq -> HatPrelude.Eq > Prelude.Num -> HatPrelude.Num > > The defaulting mechanism *only* applies to types constrained by > the original builtin Prelude.Num, not to the transformed class > HatPrelude.Num. I did wonder how Hat tackled this. Out of curiosity what is the solution that Hat uses? And what is the situation in nhc98? > I think you are saying that if we > import HatPrelude as Prelude > together with -fno-implicit-prelude in GHC, then defaulting should work > over the HatPrelude classes rather than the Prelude ones? That's what I had hoped for. > Unfortunately, in Hat at least, we continue to use the original > Prelude in *addition* to the replacement HatPrelude. This adds an extra element of difficulty to the problem. I am trying my hardest to avoid needing the to import the original Prelude in a transformed module - this requires quite a bit of desugaring in the transformation. Still, I would like to be able to use do notation and have it refer to Prelude.Monad, not MyPrelude.Monad. I can live without it of course. For what reasons do you require the original prelude? Cheers, Bernie.

3 2

RE: package name mismatch
by Simon Marlow 15 Jul '02

15 Jul '02

> Building htk, I've got an error: > > TestGetPut.hs:6: > Module `GetPut' is located in package `Main' > but its interface file claims it is part of package > `uni-events-test' > > It happened (as far as I got) when ghc saw in current path > the *.hi file built for installation. There are some ways to > work around it, but, there was a lot of such places, so can > I just skip the 'package name' check and go as it is? This was converted to a warning in, I think, ghc 5.02.3. Please upgrade, preferably to 5.04. Cheers, Simon

1 0