January 2002 - Glasgow-haskell-users

RE: Ticky-ticky profiling (was: GHC 5.02.2 installation/compilationproblems)
by Simon Marlow 25 Jan '02

25 Jan '02

> On Fri, 25 Jan 2002, Nicholas Nethercote wrote: > > > > > Also, when I try to compile for ticky-ticky profiling... > > Further in the ticky-ticky adventure... > > Having compiled the libraries and RTS and other bits for > ticky-ticky, when > I try the -ticky option with ghc I get loads of messages like this at > link-time: > > /homes/njn25/ws/build/ghc/driver/../rts/libHSrts_t.a(GC.t_o): > In function `threadSqueezeStack': > GC.t_o(.text+0x2fe0): undefined reference to > `LDV_recordDead_FILL_SLOP_DYNAMIC' > GC.t_o(.text+0x3010): undefined reference to `LDV_recordCreate' > GC.t_o(.text+0x304d): undefined reference to `LDV_recordCreate' It looks like ticky-ticky has rotted a bit. Some calls to LDV_recordDead_FILL_SLOP_DYNAMIC() and LDV_recordCreate() in Storage.h need to be additionally wrapped in #ifdef TICKY_TICKY. There may be more. If you send me a patch, I'll commit it. Cheers, Simon

1 0

RE: Multiply Recursive Modules
by Simon Peyton-Jones 25 Jan '02

25 Jan '02

We discussed this and yes it seems like a fine idea. Thanks. We should have thought of it ages ago. Not sure how fast we'll implement it, but it's on the list. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 14 January 2002 16:28 | To: glasgow-haskell-users(a)haskell.org | Subject: Multiply Recursive Modules | | | Writing .hi-boot files is a pain, and "the works" (allegedly) | containing a compiler which | does mutually recursive modules properly seem permanently | gummed up. Therefore may I suggest a new .hs-boot suffix | which compiles Haskell to produce just a .hi-boot file? I | already have two .hs-boot files (except I call them .boot.hs | to make ghc happy) and they seem to work reasonably well. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

RE: GHC 5.02.2 installation/compilation problems
by Simon Marlow 25 Jan '02

25 Jan '02

Hi Nick, > I just installed GHC 5.02.2 (actually, the latest version > from CVS), and > had a strange problem. My first attempt worked ok, but I > screwed something > up, so I junked it and started again from scratch. > > This time, it died part-way through the "make boot" step for ghc > itself, because glafp-utils/mkdependC/mkdependC had not been > built. To fix > the problem I just went to that directory and made mkdependC > myself first, > and then recompiled from $(BUILD), which worked. Does anyone have any > idea why mkdependC may not have been built in the first place? Nothing springs to mind, unless you had explicitly set $(ProjectsToBuild) in your build.mk, and left out glafp-utils. It usually isn't necessary to set $(ProjectsToBuild) as it defaults to building all the projects in the current tree. > Also, when I try to compile for ticky-ticky profiling by setting > GhcCompilerWays=t and GhcLibWays=t in $(BUILD)/mk/build.mk, and then > running "make all" in $(BUILD), it compiles for a short time > and then dies > with this error message: Just set GhcLibWays=t, you don't have to set GhcCompilerWays too (this is for building the compiler itself in a different way). Cheers, Simon

2 2

RE: GHC 5.02.2 installation/compilation problems
by Simon Marlow 25 Jan '02

25 Jan '02

> > > Also, when I try to compile for ticky-ticky profiling... > > > > Just set GhcLibWays=t, you don't have to set > GhcCompilerWays too (this > > is for building the compiler itself in a different way). > > Unless I want to ticky-ticky profile the compiler itself, yes? Yup... if you want to do that, you'll need to do a 2-stage bootstrap and build ticky-ticky libraries (GhcLibWays=t) in the first stage, and build the compiler with ticky-ticky in the second stage. I would just do this by adding -ticky-ticky to GhcHcOpts rather than fiddling with GhcCompilerWays, since I'm less certain the latter works properly. Cheers, Simon

1 0

RE: [Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
by Simon Marlow 25 Jan '02

25 Jan '02

> I use GHC 5.00.2 on Solaris 2.6 at the university and am unable to use > hierarchical module names --- with and without the > -fglasgow-exts switch. GHCi > notifies me of parse errors on the module name. What is > interesting is that if > my module with hierarchical name imports a module which > cannot be found GHC > tells me that it cannot find the latter module instead of > first recognizing that > the name of the former module is in its opinion illegal and > complaining about > this. Aren't hierarchical module names supported yet in GHC > 5.00.2? At home with > GHC 5.02 under Linux everything works fine. > By the way, I couldn't find anything about hierarchical > module names in the > documentation. 5.00.2 didn't support hierarchical module names, but 5.02 does have the extension. We're not making a lot of noise about it right now because the full switchover is slated for the 5.04 release, when we'll move all the libraries over to use the hierarchical module system. Cheers, Simon

1 0

GHC 5.02.2 installation/compilation problems
by Nicholas Nethercote 25 Jan '02

25 Jan '02

Hi, I just installed GHC 5.02.2 (actually, the latest version from CVS), and had a strange problem. My first attempt worked ok, but I screwed something up, so I junked it and started again from scratch. This time, it died part-way through the "make boot" step for ghc itself, because glafp-utils/mkdependC/mkdependC had not been built. To fix the problem I just went to that directory and made mkdependC myself first, and then recompiled from $(BUILD), which worked. Does anyone have any idea why mkdependC may not have been built in the first place? Also, when I try to compile for ticky-ticky profiling by setting GhcCompilerWays=t and GhcLibWays=t in $(BUILD)/mk/build.mk, and then running "make all" in $(BUILD), it compiles for a short time and then dies with this error message: <lots of stuff...> ------------------------------------------------------------------------ ==fptools== make way=t all; PWD = /local/scratch-1/njn25/ws/build/ghc/compiler ------------------------------------------------------------------------ /homes/njn25/local/bin/ghc-5.02.2 -o ghc_t-5.03 -ldl -cpp ... <many files> /usr/bin/ld: cannot find -lHSutil_t collect2: ld returned 1 exit status <<ghc: 4187340 bytes, 2 GCs, 126260/126260 avg/max bytes residency (1 samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (0.32 elapsed), 0.03 GC (0.03 elapsed) :ghc>> make[3]: *** [ghc_t-5.03] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/local/scratch-1/njn25/ws/build/ghc' make: *** [all] Error 1 Am I doing something wrong? Has something been broken in 5.02.2? In case it's useful, here's the exact steps I took: - CVS checkout happy, ghc, hslibs - make build tree with sym links to code tree - run autoconf in $(BUILD) and in ghc/$(BUILD) - run ./configure in $(BUILD), with apt. --prefix and --with-ghc values - create $(BUILD)/mk/build.mk: ProjectsToBuild = happy hslibs ghc GhcCompilerWays= GhcLibWays= (for ticky-ticky profiling, I added "t" to the last two lines) - run "make all" in $(BUILD) Thanks for the help. -- Nick Nethercote njn25(a)cam.ac.uk

1 0

ANNOUNCE: popenhs-1.00.0 released
by Jens Petersen 25 Jan '02

25 Jan '02

Version 1.00.0 of popenhs is out. You can get it from: http://www.01.246.ne.jp/~juhp/haskell/popenhs/ popenhs is a small library providing lazy string output from and input to a subprocess. The interface provided by "popen" now differs from the "popen3" offered in 0.00 by taking an input string argument instead of returning an input handle. Thanks to Uwe Schmidt for reporting the problem in the previous release of popen3 hanging on a closed input pipe, that led to this new implmentation, which I believe fixes the problem. Jens

1 0

[Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
by Wolfgang Jeltsch 25 Jan '02

25 Jan '02

Hello, I use GHC 5.00.2 on Solaris 2.6 at the university and am unable to use hierarchical module names --- with and without the -fglasgow-exts switch. GHCi notifies me of parse errors on the module name. What is interesting is that if my module with hierarchical name imports a module which cannot be found GHC tells me that it cannot find the latter module instead of first recognizing that the name of the former module is in its opinion illegal and complaining about this. Aren't hierarchical module names supported yet in GHC 5.00.2? At home with GHC 5.02 under Linux everything works fine. By the way, I couldn't find anything about hierarchical module names in the documentation. Wolfgang

2 1

ignore, please
by S.D.Mechveliani 25 Jan '02

25 Jan '02

this is mail test, ignore, please

1 0

Re: notes on ghc-5.02.2. Reply
by Ashley Yakeley 24 Jan '02

24 Jan '02

At 2002-01-24 06:52, Ketil Z. Malde wrote: >GHC is in Debian, you probably want to use a cutting-edge release >(i.e. sid or at least woody) to be reasonably current. ghc5 in woody and sid is 5.02. If anyone would has a deb for the latest release, that would be very useful... -- Ashley Yakeley, Seattle WA

1 0