April 2011 - Glasgow-haskell-users

Changing language options in ghci at runtime
by Simon Hengel 09 Apr '11

09 Apr '11

Hello, does anyone know whether you can somehow change the currently active language flags during a ghci session (say change what `:show languages' outputs)? If no, is this possible by using the GHC API? Cheers, Simon

2 2

Strange performance effects with unsafePerformIO
by Björn Peemöller 08 Apr '11

08 Apr '11

Hello, we have a strange performance behaviour when we use unsafePerformIO, at least with GHC 6.12.3 and 7.0.1. Please consider the example program following at the end of this post. Running the original code the execution time is about 26 seconds, while uncommenting one (or both) of the comments shrinks it to about 0.01 seconds on our machine. Is there an explanation for this effect? Regards, Bjoern -- --------------- module Main where import System.IO.Unsafe traverse [] = return () -- traverse (_:xs) = traverse xs traverse (_:xs) = traverse xs >> return () makeList 0 = [] -- makeList n = () : (makeList (n - 1)) makeList n = () : (unsafePerformIO . return) (makeList (n - 1)) main = traverse $ makeList (10^5)

4 5

dynamic loading with ghc api?
by Rob Nikander 07 Apr '11

07 Apr '11

Hi all, I'd like to load a value from a .o file. I've got... import ObjLink main = do initObjLinker loadObj "Thing.o" resolveObjs Just ptr <- lookupSymbol "Thing_value_closure" Is that the correct symbol to load for the name "value" in module "Thing"? And if so, how to I get the haskell value out of the Ptr that I get from lookupSymbol? I found some code to do it and it works value :: Int, but it seg faults if value :: Integer, or something more complex like a function. {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} ... let !(Ptr addr) = ptr in case addrToHValue# addr of (# hval #) -> hval Is there some documentation for this that I'm missing? I'm looking at haddock with just type signatures, like this: http://www.haskell.org/ghc/docs/7.0.3/html/libraries/ghc-7.0.3/ObjLink.html (I'm a haskell beginner.) thank you, Rob

2 3

Re: Validate failures on the new codegen
by Edward Z. Yang 07 Apr '11

07 Apr '11

Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011: > OK! Thanks for the information. So this -fnew-codegen is this famous > codegen which is using hoopl for data-dependency tracking or something > like that if I understand correctly Yep. > And which is producing just C-- in order to be compatible with the current > infrastructure, i.e. NCG? Not quite. We have two C-- representations, in cmm/CmmNode.hs and cmm/OldCmm.hs respectively. Our backends consume OldCmm, and Hoopl consumes CmmNode, and then converts it to OldCmm using CmmCvt.hs. > If I also read correctly somewhere on GHC Trac Wiki, then this -fnew-codegen > should sometime in the future even replace NCG. May I ask you when such > replace is planed? That's the idea, but depends on how long it takes for us to get the new code generator generating as good (or better--that's the idea behind Hoopl) as the old code generator at a reasonable pace. The new codegen is already several years into the making. > I'm asking since I'm still poking with the idea of writing NCG for some GHC > not yet supported platform and since this will be my free time hobby project > it'll certainly take some time hence I do have doubts if to use current NCG > as a basis for it or wait and/or use your new planned infrastructure. It's certainly a question. Since we can convert from one to another, whichever one you pick, we should be able to support (some fiddling may be required if you use the new C-- representation, since none of our other backends use it right now--but this is certainly the way forward.) Edward

1 0

T3738 allocation figures for 32-bit
by Daniel Fischer 07 Apr '11

07 Apr '11

Hit send too soon: > Apparently the allocation figures drastically vary by arch and OS, it > would probably be necessary to test on several such and be more > generous with the limits. The same holds for other tests, of course. I had unexpected failures due to allocation figures also for space_leak001, T4801 and T3064. space_leak001 failing with bytes allocated 9328745840 is more than maximum allowed 9100000000 (allocation figures slightly vary among the different ways) which is close enough to not worry about, considering the minimum allowed is 9050000000. T4801 with peak_megabytes_allocated 41 is less than minimum allowed 70 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 358364424 is more than maximum allowed 80000000 max_bytes_used 17406288 is more than maximum allowed 4000000 and T3064 with peak_megabytes_allocated 9 is less than minimum allowed 14 If this is because you have improved GHC, please update the test so that GHC doesn't regress again bytes allocated 69984336 is less than minimum allowed 150000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again max_bytes_used 3368652 is less than minimum allowed 6000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again The figures in HEAD's testsuite are again close to what I get, while the 7.0.3 figures are way off. Cheers, Daniel

2 1

Some tips for using git rebase and keeping your history clean
by Johan Tibell 06 Apr '11

06 Apr '11

Hi all, Since we've now switched to git I though I share Linus' notes on rebasing for those of you who haven't seen them: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html The mail talks about when to use rebase and when not to. Johan

1 0

-DDEBUG and testsuite
by Edward Z. Yang 06 Apr '11

06 Apr '11

Hello all, If I run 'make fast' in the testsuite, with a stage2 compiler that has been built with -DDEBUG, should I be getting extra failures? Edward

3 4

Re: [Gtk2hs-users] cairo error: ghc.exe: unable to load package `cairo-0.12.0'
by Axel Simon 05 Apr '11

05 Apr '11

Hi Daniel, On 04.04.2011, at 16:01, Daniel wrote: > Hi list, > > I've built gtk2hs successfully for ghc-7.0.2, but if I try to load > the example > Drawing.hs from the cairo packages demo folder I get: > > > *Main> :load Drawing.hs > [1 of 1] Compiling Main ( Drawing.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > Loading package transformers-0.2.2.0 ... linking ... done. > Loading package mtl-2.0.1.0 ... linking ... done. > Loading package array-0.3.0.2 ... linking ... done. > Loading package containers-0.4.0.0 ... linking ... done. > Loading package process-1.0.1.5 ... linking ... done. > Loading package time-1.2.0.3 ... linking ... done. > Loading package random-1.0.0.3 ... linking ... done. > Loading package haskell98-1.1.0.1 ... linking ... done. > Loading package cairo-0.12.0 ... linking ... <interactive>: > C:/users/daniel/appd > ata/roaming/cabal\cairo-0.12.0\ghc-7.0.2\HScairo-0.12.0.o: unknown > symbol `_cair > o_image_surface_get_data' > ghc.exe: unable to load package `cairo-0.12.0' > > Have tried many things so far: > > * Starting with re-inited package database > * Doing a $ nm /h/Gtk+/bin/libcairo-2.dll | grep -i > cairo_image_surface_get_data > yielding 68de04d8 T _cairo_image_surface_get_data > * Temporarily renaming libcairo-2.dll (the only one found on my > setup, even > not-in-PATH ones are non-existent) yielding as expected "dll not > found" error > * as you can see there is no "literal" space in the gtk+ > installation path > (h:\Gtk+), only in the users haskell package installation path, but > that's > fairly standard with Windows I guess > * Compilable with ghc --make ... though, but that's sadly not > sufficient as > Chart package isn't installable due to this issue If ghc --make works but interactively the object cannot be found, then it might be a ghc problem rather than ours, especially since the symbol exists in the DLL. Can somebody from the ghc group shed some light on the issue? Cheers, Axel

2 1

Re: [Haskell] Polymorphic types in RHS of type instances
by José Pedro Magalhães 04 Apr '11

04 Apr '11

Hi, [Moving to glasgow-haskell-users(a)haskell.org] I would also like to know the answer to this question. While I can imagine it has something to do with type checking/inference, it is not immediately clear to me where the problem lies. Thanks, Pedro On Sat, Feb 5, 2011 at 12:25, Steven Keuchel <steven.keuchel(a)gmail.com>wrote: > Hi list, > > I was wondering why GHC doesn't allow usage of polymorphic types in > the right-hand side of type instance declarations for type families. > The GHC user guide states: "The right-hand side of a type instance > must be a monotype (i.e., it may not include foralls) [...]", but it > doesn't state the reason. > > I stumbled upon this limitation when I was trying to generically > calculate Johann's and Ghani's interpreter (transformers) for nested > data types from their "Initial Algebra Semantics is Enough!" paper. > > Cheers, > Steven > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 2

T3738 allocation figures for 32-bit
by Daniel Fischer 02 Apr '11

02 Apr '11

In 7.0.3's testsuite, allT in perf/should_run says: test('T3738', [stats_num_field('peak_megabytes_allocated', 1, 1), # expected value: 1 (amd64/Linux) # expected value: 12800 (x86/OS X): if_wordsize(32, stats_num_field('bytes allocated', 12700, 14000)), if_wordsize(64, stats_num_field('bytes allocated', 60000, 80000)), # expected value: 72608 (amd64/Linux) only_ways(['normal']) ], compile_and_run, ['-O']) which looks quite amazing. On my linux box I consequently get bytes allocated 60608 is more than maximum allowed 14000 *** unexpected failure for T3738(normal) which looks quite horrible. But considering that 6.12.3 allocated nearly 500,000 bytes for that, it's pretty fine. In HEAD's testsuite, the figures have been adjusted to if_wordsize(32, stats_num_field('bytes allocated', 40000, 50000)), and HEAD does that, allocating 46008 bytes. A trivial 'main = return ()' produces ./nuff +RTS -s 47,496 bytes allocated in the heap 1,376 bytes copied during GC 34,036 bytes maximum residency (1 sample(s)) 19,212 bytes maximum slop here Apparently the allocation figures drastically vary by arch and OS, it would probably be necessary to test on several such and be more generous with the limits. Cheers, Daniel

1 0