- Glasgow-haskell-users

Tracing idea
by Edward Z. Yang 12 May '11

12 May '11

I was thinking it might be useful if we had a per-thread circular buffer in memory for which we pushed a pointer to the info table we had just entered. In the event of a crash, you could dump the contents of the buffer to see what code had been recently executed. To reduce overhead, one might only need to record this information when we do a tail call, and not when the path can be reconstructed from the stack. (Obviously, you'd need to compile in debug mode, and you'd probably want to also add an RTS flag). What do people think? Cheers, Edward

3 4

ghc7, -rtsopts, and g++
by Evan Laforge 06 May '11

06 May '11

So as everyone probably knows, ghc7 requires -rtsopts to enable +RTS parsing. Apparently this makes it include various header files in rts/ when linking, because after upgrading to ghc7 I suddenly got syntax errors from headers there. Some investigation revealed that the problems were use of 'new' as a variable name in rts/storage/Block.h, and implicit conversion from a bool to an enum rtsBool in rts/ClosureMacros.h. These things are fine in C, but not in C++, and I'm linking with -pgmc g++ -pgml g++ so they were a problem. I was able to fix them by simply renaming 'new' and replacing the implicit conversion with explicit. But it makes me think setting g++ for the "C" compiler was incorrect. I'm linking with c++ code via a wrapper that uses 'extern "C" { ... }' to ensure the haskell FFI knows how to call it, and if I don't set pgmc then the link dies horribly and very verbosely when none of the c++ symbols are visible. So I arrived at that flag by guessing after my program wouldn't link without it, not because I saw documentation saying this is how to do it. Is there a better way to link to c++?

2 2

upgrading to 7.0.3 causes assembly errors
by Evan Laforge 05 May '11

05 May '11

So I just upgraded to 7, and on compiling I got: /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0: suffix or operands invalid for `push' /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0: suffix or operands invalid for `push' ... etc. Some digging revealed that it was actually in the compilation of a *_stub.c file, and the underlying problem is thus: This is OS X 10.6. For various reasons, my app is compiled 32 bit, and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc. Previously, of course, this wasn't necessary since ghc always produced 32 bit code. But now there seems to be an issue with flag order. When ghc wants to compile the stub, it runs: g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of my flags Then it wants to assemble it: /Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o ./Ui/RulerC_stub.o -m64 -fno-stack-protector So it looks like when compiling, the user flags go last, overriding the new default -m64. But when assembling, they go first, and are overidden. This seems like an easy fix, I imagine it's just constructing the cmdline inconsistently. Is there a way for me to influence how it constructs the cmdline for gcc for stubs? I mean, without recompiling ghc. I'm supposed to be able to get ghc to compile 32 bit, right? It also seems odd to me that it's compiled and assembled separately, but I suppose there must have been some reason for that. I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...

2 3

Are FFI calls interruptible?
by Bas van Dijk 04 May '11

04 May '11

Hello, Quick question: are safe/unsafe FFI calls interruptible? Thanks, Bas

3 6

Elimination of absurd patterns
by C Rodrigues 03 May '11

03 May '11

I was experimenting with using GADTs for subtyping when I found something interesting. Hopefully someone can satisfy my curiosity. Here are two equivalent GADTs. My understanding was that GHC would translate "Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates better code for 'fooName' than for 'barName'. In 'fooName', there is no pattern match against 'FooExtra'. In 'barName', there is a pattern match against 'BarExtra'. What makes these data types different? data Tagdata TagExtra -------- data Foo a where Foo :: String -> Foo a FooExtra :: IORef String -> Foo TagExtra -- The cmm code for fooName does not match against 'FooExtra'fooName :: Foo Tag -> StringfooName (Foo s) = s -------- data Bar a where Bar :: String -> Bar a BarExtra :: a ~ TagExtra => IORef String -> Bar a -- The cmm code for barName will try to pattern-match against 'BarExtra'barName :: Bar Tag -> StringbarName (Bar s) = s

2 2

Broken ghc-7.0.3/vector combination?
by Daniel Fischer 03 May '11

03 May '11

Investigating the appearance of NaN in criterion's output, I found that NaNs were frequently introduced into the resample vectors when the resamples were sorted. Further investigation of the sorting code in vector-algorithms revealed no bugs there, and if the runtime was forced to keep a keen eye on the indices, by replacing unsafeRead/Write/Swap with their bounds-checked counterparts or by 'trace'ing enough of their uses, the NaNs did not appear. I could not reproduce the behaviour with ghc-7.0.1 (using exactly the same versions of the involved libraries), ghc-7.0.2 (different criterion release, the other libraries identical) or unoptimised compilation with 7.0.3 (no NaNs encountered in some 100+ testruns with varying input). So, is it possible that some change in ghc-7.0.3 vs. the previous versions caused a bad interaction between ghc-optimisations and vector fusion resulting in bad vector reads/writes?

9 14

Elimination of absurd patterns (reformatted)
by C Rodrigues 03 May '11

03 May '11

I'm re-sending this e-mail, hopefully with proper line breaks this time. I was experimenting with using GADTs for subtyping when I found something interesting. Hopefully someone can satisfy my curiosity. Here are two equivalent GADTs. My understanding was that GHC would translate "Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates better code for 'fooName' than for 'barName'. In 'fooName', there is no pattern match against 'FooExtra'. In 'barName', there is a pattern match against 'BarExtra'. What makes these data types different? data Tag data TagExtra -------- data Foo a where Foo :: String -> Foo a FooExtra :: IORef String -> Foo TagExtra -- The cmm code for fooName does not match against 'FooExtra' fooName :: Foo Tag -> String fooName (Foo s) = s -------- data Bar a where Bar :: String -> Bar a BarExtra :: a ~ TagExtra => IORef String -> Bar a -- The cmm code for barName will try to pattern-match against 'BarExtra' barName :: Bar Tag -> String barName (Bar s) = s

2 1

(no subject)
by hsing-chou chen 02 May '11

02 May '11

http://www.buonviaggioitaly.com/modules/mod_osdonate/myhome.html

1 0

Incrementally consuming the eventlog
by Johan Tibell 02 May '11

02 May '11

Hi, We were discussing how to consume the eventlog incrementally on #ghc today. Would it be feasible to offer an API (e.g. GHC.EventLog) that allows programs to register for events that occur in the program? Programs would register listeners like so: registerEventListener (\ event -> doSomethingWith event) The current write-to-file system could be implemented in terms of this API. We could even allow event logging to be turned on/off from within the application, allowing developers to attach to a running application, enable event logging, diagnose the app, and then turn of event logging again. The RTS would invoke listeners every time a new event is written. This design has many benefits: - We don't need to introduce the serialization, deserialization, and I/O overhead of first writing the eventlog to file and then parsing it again. - Programs could monitor themselves and provide debug output (e.g. via some UI component). - Users could write code that redirects the output elsewhere e.g. to a socket for remote monitoring. Would invoking a callback on each event add too big of an overhead? How about invoking the callback once every time the event buffer is full? Johan

5 9

Package management
by Brandon Moore 01 May '11

01 May '11

Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them. Deleting perfectly good versions seems to be the root of all package management problems. There are already hashes to keep incompatible builds of a package separate. Would anything break if existing packages were left alone when a new version was installed? (perhaps preferring the most recent if a package flag specifies version but not hash). For example, It seems the butterfly effect http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ could be avoided if the package database was allowed to simultaneously contain a "twittertags-1.0.0-hashA" and "twittertags-1.0.0-hashB" built against different dependencies. The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea? Brandon

3 3