newAddrArray# and other things
Okay, one quick question: what do i have to import to get newAddrArray#, readAddrArray#, etc.? And, secondly, a correction to the documentation: under the "Allocation" section (7.2.14.1), It says: newCharArray# :: Int# -> State# s -> (# State# s, MutableByteArray# s elt #) newIntArray#:: Int# -> State# s -> (# State# s, MutableByteArray# s elt #) newAddrArray# :: Int# -> State# s -> (# State# s, MutableByteArray# s elt #) newFloatArray# :: Int# -> State# s -> (# State# s, MutableByteArray# s elt #) newDoubleArray# :: Int# -> State# s -> (# State# s, MutableByteArray# s elt #) but none of those "elt"s should be there, since MutableByteArray# has kind * -> * (it looks like someone just copied and pasted the type signature of newArray#). - Hal -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Ticky-ticky profiling (was: GHC 5.02.2 installation/compilationproblems)
> 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Multiply Recursive Modules
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:[EMAIL PROTECTED]] | Sent: 14 January 2002 16:28 | To: [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ticky-ticky profiling (was: GHC 5.02.2 installation/compilationproblems)
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' These LDV_* functions seem to only be needed/used if compiling for normal profiling, which I'm not and don't want to. Similarly, when I try recompiling the RTS (trying to make the problem disappear), I get warnings of this sort: In file included from Updates.hc:14: Storage.h: In function `updateWithPermIndirection': Storage.h:289: warning: implicit declaration of function `LDV_recordDead_FILL_SLOP_DYNAMIC' So it seems PROFILING is being defined, but I'm not sure where since my $(BUILD)/mk/builk.mk file has these lines: GhcCompilerWays= GhcLibWays=t Can anyone suggest what might be causing the problem? Thanks. -- Nick Nethercote [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 5.02.2 installation/compilation problems
> > > 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 5.02.2 installation/compilation problems
On Fri, 25 Jan 2002, Simon Marlow wrote: > 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. Aha, that would be it, I had omitted glafp-utils from $(ProjectToBuild). Although I thought I had done it that way before... no matter. > > 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? -- Nick Nethercote [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
> 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 5.02.2 installation/compilation problems
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 5.02.2 installation/compilation problems
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: ==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 ... /usr/bin/ld: cannot find -lHSutil_t collect2: ld returned 1 exit status <> 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 [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: popenhs-1.00.0 released
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
