- Glasgow-haskell-users

Weekly IRC meeting?
by Simon Marlow 30 Jul '08

30 Jul '08

Hi folks, I've been wondering whether it would be useful to have a weekly IRC meeting to discuss GHC. The idea would be that this is a scheduled time when the developers turn up on #ghc, we'll discuss current topics around GHC, and users can chime in with questions, points for discussion, complaints :-) and so on. I imagine making it completely informal to begin with, and later adding some structure (an agenda etc.) if necessary. Another option is a conference call, but personally I prefer the IRC medium for this kind of meeting. A conference call could work too, though. Thoughts? I'm thinking a time around 1600 UK time (currently UTC+1) would probably work best, does anyone have preferences for days? Cheers, Simon

12 21

ghci and source files
by Johannes Waldmann 30 Jul '08

30 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, how does ghci (actually, the ghc API functions) access the file system? (It needs to check whether source files had been updated.) Is it possible to insert an abstraction layer there? E.g. imagine the sources are not on the file system, but in Eclipse edit buffers. - Any hints appreciated. J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEUEARECAAYFAkiPJUEACgkQDqiTJ5Q4dm99LQCXcaCtKnvEsmoGdJ+UQ93A2x0Z 2ACbBfaSZsvU0xHeh/jQbZZjI5VAEdQ= =eQ4p -----END PGP SIGNATURE-----

3 4

Retainer profiling -- too slow?
by Tim Chevalier 30 Jul '08

30 Jul '08

Hi all, Are there any known problems with retainer profiling in GHC 6.8.2? I have a program that takes 3 minutes to run with "normal" profiling enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and counting. I can tell that progress is being made since the .hp file keeps getting bigger, but that seems like a lot of overhead. I can try to come up with a smaller test case if necessary; just wanted to see if there's any known problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The trouble with academia is that there's a lot of 'If you'll validate my program of Kumquat Studies I won't point out the uselessness of your doctorate in Nail File Studies.'" -- Sarah Barton

2 1

GHC 6.8.3 in Debian?
by Peter Gammie 29 Jul '08

29 Jul '08

Ian - how long until GHC 6.8.3 makes it into Debian's unstable repository? (Just curious how long it takes, and flying the flag of interest.) BTW is there another .deb repository out there for bleeding-edge Haskell artefacts? I believe there used to be, but the URLs in those old (2004) emails seem dead now. cheers peter -- http://peteg.org/

2 1

GHC 6.6 GADT type unification vs GHC 6.8
by Jason Dagit 29 Jul '08

29 Jul '08

Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952… What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason

2 4

Re: ghc 6.8.3 build error with __DISCARD__ linking problem, please help!
by Yu Di 26 Jul '08

26 Jul '08

Thanks! I installed 6.8.2 binary and that successfully compiled 6.8.3 source with gcc 4.1.1. (I am still not sure why a direct 6.8.3. binary installation did not work for me, but now I think everything is good). Thanks very much again! Di, Yu 7.26 ----- Original Message ---- From: Simon Marlow <marlowsd(a)gmail.com> To: Yu Di <diyu60607(a)yahoo.com> Cc: glasgow-haskell-users(a)haskell.org Sent: Friday, July 25, 2008 3:52:01 AM Subject: Re: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! Yu Di wrote: > Hi, I am trying to build ghc 6.8.3 from source release, my currently > installed version is ghc 6.4.2 (x86 linux binary release version), and I > got: > > /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall > -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT > -i../../compat -ignore-package Cabal -Rghc-timing -package unix > -L../../compat -lghccompat Main.o Version.o CRT_noglob.o > Main.o: In function `__stginit_ZCMain': > ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main': > ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main_': > ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' > Main.o:ghc13533.hc:(.text+0x3d): more undefined references to > `__DISCARD__' follow > collect2: ld returned 1 exit status > <<ghc: 13726704 bytes, 3 GCs, 105428/105428 avg/max bytes residency (1 > samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), > 0.01 GC (0.03 elapsed) :ghc>> > > Do you know how I can fix this problem? My ghc and gcc versions are: > > The Glorious Glasgow Haskell Compilation System, version 6.4.2 > gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) > > (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in > the same error message) The error is coming from your installed 6.4.2, and I strongly suspect that it is incompatible with the gcc version you have installed. You could try downgrading gcc, but your best bet is to just install a recent GHC binary distribution. Cheers, Simon

1 0

ghc 6.8.3 build error with __DISCARD__ linking problem, please help!
by Yu Di 25 Jul '08

25 Jul '08

Hi, I am trying to build ghc 6.8.3 from source release, my currently installed version is ghc 6.4.2 (x86 linux binary release version), and I got: /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT -i../../compat -ignore-package Cabal -Rghc-timing -package unix -L../../compat -lghccompat Main.o Version.o CRT_noglob.o Main.o: In function `__stginit_ZCMain': ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main': ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main_': ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' Main.o:ghc13533.hc:(.text+0x3d): more undefined references to `__DISCARD__' follow collect2: ld returned 1 exit status <<ghc: 13726704 bytes, 3 GCs, 105428/105428 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), 0.01 GC (0.03 elapsed) :ghc>> Do you know how I can fix this problem? My ghc and gcc versions are: The Glorious Glasgow Haskell Compilation System, version 6.4.2 gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in the same error message) Thanks!

2 1

Advice sought for 6.9 and Arrow/Category
by Conal Elliott 22 Jul '08

22 Jul '08

I want to use ghc-6.9 for improved support of type families, but I see that the change to the Arrow interface breaks some of my libraries (since (>>>) is no longer a method of Arrow). Will this change really be in ghc-6.9? Does anyone have coping strategies for keeping libraries working in 6.8 *and* 6.9, particularly ones that define instances of Arrow? Thanks, - Conal

5 6

Building libraries with ticky-ticky
by Andrew Hunter 21 Jul '08

21 Jul '08

Hi, I have some code I want to use ticky-ticky profiling on (if it matters, I want some of the data ticky-ticky collects about frequency of updates and related matters.) However, I'm specifically interested in the code running with some modificiations I've made to the RTS, so I need to build GHC with ticky-ticky. That in itself isn't hard--the documentation said to just run "make way=t" in rts/, which seemed to work; but the documentation also said that to get meaningful numbers, I should make sure to build the libraries with ticky-ticky (which makes sense--I'm interested in the same data whether or not the updates happen in a function from List or one I wrote, &c.) The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another. So, any help or advice on how to tell the GHC build system to build a set of libraries with ticky-ticky profiling enabled would be greatly appreciated. (FWIW, I'm not distributing anything, so it'd be more than adequate for stuff to be broken for non ticky use, I just need to build some test executables and be sure they're logging the right data.) Thanks, AHH

2 3

GHC Error: "FATAL:Symbol _XJv_srt already defined."
by Ron Alford 21 Jul '08

21 Jul '08

I posted this to Haskell-Cafe, but it's more GHC specific. Anyone know what this is about? Removing parts makes problem go away, but it's not clear what parts to remove! (that, and I wrote those parts for a reason!). bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 bash-3.2$ uname -a Darwin silverback-wired.home 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 $ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) /var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0: FATAL:Symbol _XxG_srt already defined. -Ron Alford

1 0