- Glasgow-haskell-users

Allocation break-down by type
by Bruno Martínez Aguerre 19 Sep '10

19 Sep '10

Hi list, To understand better whether ghc is taking advantage of my UNPACK pragmas, I want to profile my program and sort the allocations by type. I couldn't find an option to do this. -p is only by cost-center, and -hy only works for live data, and I want all allocations. Am I missing some option? Any tips to better debug UNPACK, apart from inspecting core? Thanks, Bruno

3 2

Interruptible GHC
by Edward Z. Yang 18 Sep '10

18 Sep '10

So I did a writeup of what I thought might be the next direction to go with the interruptible patch: http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/ The really interesting bit (which I didn't cover) is what information to give to the user functioSo I did a writeup of what I thought might be the next direction to go with the interruptible patch: http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/ The really interesting bit (which I didn't cover) is what information to give to the user function. It needs to be somewhat under the hood: if someone wants to pthread_cancel they need to know what the pthreads ID is; if they want to transmit a Windows event they need some way to get a hold of the event handle associated with the foreign call. Edward

2 7

Directory-backed Handle?
by Dimitry Golubovsky 15 Sep '10

15 Sep '10

Hi, In the GHC I/O system, a Handle may be backed by a "device" (IODevice instance) with IODeviceType = Directory There doesn't seem to be any (at least Google search did not give anything) code that uses this; however, what is supposed to be read from such a Handle: newline-separated list of filenames (like in getDirectoryContents), or some sort of serialized FileStatus structures, or anything else? Thanks. -- Dimitry Golubovsky Anywhere on the Web

3 3

Demand for 64-bit Windows GHC?
by Satnam Singh 15 Sep '10

15 Sep '10

I am trying to get a sense for how much demand there is for a 64-bit version of GHC for Windows. Personally I have two reasons why I would like to have a 64-bit build: * To allow me to write services in Haskell to be deployed on Microsoft's Azure cloud computing system which requires 64-bit binaries (and life is too short for SysWOW64). * To allow me to interoperate with 64-bit native libraries e.g. for dynamic code generation for SSE3 vector instructions as supported by the Accelerator system (I've done this in F# http://blogs.msdn.com/b/satnam_singh/archive/2009/12/15/gpgpu-and-x64-multi… and it would be good to have a Haskell version too for SSE3 vector code - the GPU version works fine with 32-bit DLLs). Is anyone else interested in a 64-bit version of GHC for Windows? Simon Marlow reckons it is about 2 weeks work for him so it should only take a mere mortal about a month or two to do. Anyone interested in making a 64-bit Windows port of GHC? Cheers, Satnam ________________________________ Satnam Singh Microsoft 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom Email: satnams(a)microsoft.com<mailto:satnams@microsoft.com> UK tel: +44 1223 479905 Fax: +44 1223 479 999 UK mobile: +44 7979 648412 USA cell: 206 330 1580 URL: http://research.microsoft.com/~satnams Live Messenger: satnam(a)raintown.org<mailto:satnam@raintown.org>

1 0

ghc_rts_options (defalting RTS flags)
by Thomas DuBuisson 15 Sep '10

15 Sep '10

All, A recent SO question [1] led me to do a quick test on hard-coding RTS options as suggested in the manual rts-hooks section [2]. Unfortunately the timing tests indicate "ghc_rts_opts" isn't being used; tests with flags besides -N (ex: "-H1024m") also show the ghc_rts_opts being ignored. Can someone shed light on what's happening? A grep of ghc source shows no users of ghc_rts_opts, though that isn't definitive. Cheers, Thomas -------- $ cat rts-opts.h char *ghc_rts_opts = "-N"; $ ghc --make -O2 -threaded hashPar.hs rts-opts.h -fforce-recomp [1 of 1] Compiling Main ( hashPar.hs, hashPar.o ) Linking hashPar ... $ time ./hashPar 10MB 10MB 10MB 10MB ["10MB","10MB","10MB"] real 0m2.411s $ time ./hashPar 10MB 10MB 10MB 10MB +RTS -N ["10MB","10MB","10MB"] real 0m1.690s ---------- [1] http://stackoverflow.com/questions/3704430/why-do-you-have-to-use-both-a-co… [2] http://haskell.org/ghc/docs/6.12.2/html/users_guide/runtime-control.html#rt…

2 1

GHCi: scripting and multiline input
by Vivian McPhail 14 Sep '10

14 Sep '10

Hi, I am attempting to mimic matlab/octave using ghci, including a facility for updateable graphs of data. 1) It would be nice to be able to load a script of commands from the prompt \begin{file} script Sine where import "hmatrix" Numeric.Vector import "plot" Graphics.Rendering.Plot let ts = linspace 1000 (0,1 :: Double) let ss = sin (15*2*pi*ts) -- 15 Hz sine wave figure1 <- display $ plot (ts,[line ss blue]) \end{file} The idea is (apart from the import commands) is each line is equivalent to an input line in ghci. Note that the last line binds a variable from an action in the top level IO monad, something not possible in a module. 2) It would be nice to have multiline inputs if the parser can tell that the input is incomplete rather than malformed. One case is an empty 'do' construct: \begin{interaction} Prelude> :load Sine Sine> :show bindings ts :: Data.Vector.Storable Double ss :: Data.Vector.Storable Double figure :: Graphics.Rendering.Plot.Figure.Figure () Sine> withFigureMVar figure1 $ do Figure a > withTitle $ do Text a > setText "15 Hz sine wave" Text a > setFontSize 16 Text a > Figure a > Sine> \end{interaction} (an empty line ends the 'do' construct and returns to next higher level). Is this a feasible addition to GHCi? This way the full power of GHCi is accessible to an interactive mathematics session rather than developing a custom interface on top of the GHC API. Vivian

1 0

unicode characters in operator name
by Greg 11 Sep '10

11 Sep '10

Hi-- I'm creating a family of methods for a class, and to prevent name clashes I've annotated the function names with º. The files are saved UTF-8, so the character is accepted. Method names of the form fº are handled fine. GHC consumes them quite happily. Where I'm having trouble is in operator names. I'd like to create the operator (*º) but I get a type error: Invalid type signature for this line: (*º) :: (Real b, Floating b) => b -> a -> a I've tried other (ascii) symbol combinations and they're accepted, so I think the general form of my type declaration is fine. If I read the Haskell Report correctly, operators are named by (symbol {symbol | : }), where symbol is either an ascii symbol (including *) or a unicode symbol (defined as any Unicode symbol or punctuation). I'm pretty sure º is a unicode symbol or punctuation. I know I could get around this by using a different name, but this naming convention is more intuitive for what I'm trying to do. Am I misinterpreting the report, or am I doing something else wrong? Thanks-- Greg

3 4

HEAD: Deterioration in ByteString I/O
by Daniel Fischer 09 Sep '10

09 Sep '10

Trying out HEAD (specifically, ghc-6.13.20100831-src.tar.bz2 built with 6.12.3) investigating an issue with the text package, I found that I/O of ByteStrings has become significantly slower (on my machine at least: $ uname -a Linux linux-mkk1 2.6.27.48-0.2-pae #1 SMP 2010-07-29 20:06:52 +0200 i686 i686 i386 GNU/Linux Pentium 4, 3.06GHz). Timings for reading and outputting a 74.3MB file: cat: $ time cat bigfile > /dev/null 0.00user 0.04system 0:00.06elapsed 83%CPU ghc-6.12.3: $ time ./nbench lazyBSNull bigfile a b > /dev/null 0.01user 0.09system 0:00.10elapsed 100%CPU ghc-6.13.20100831: $ time ./hdbench lazyBSNull bigfile a b > /dev/null 0.07user 0.10system 0:00.18elapsed 96%CPU In addition to the slowdown, the allocation behaviour has become quite bad: ghc-6.12.3: 89,330,672 bytes allocated in the heap 15,092 bytes copied during GC 35,980 bytes maximum residency (1 sample(s)) 29,556 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) ghc-6.13.20100831: 475,305,720 bytes allocated in the heap 89,272 bytes copied during GC 68,860 bytes maximum residency (1 sample(s)) 29,444 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation)

5 10

alignment and the evil gc assertion failure
by Evan Laforge 09 Sep '10

09 Sep '10

So a long time ago (I think when 6.10 first came out, the problem didn't happen with the previous version, and I think 6.10 changed how the FFI used alignment) I filed a ghc ticket about a gc assertion failure. Unfortunately it was so hard to reproduce and reduce to a manageable example that I wound up thinking I had fixed it and closing it as user error. However, I'm pretty sure I tracked down what the problem was since I changed something and I haven't had that crash since. To recap, the crash is an assertion failure in the gc, I've seen two positions: seq: internal error: ASSERTION FAILED: file rts/dist/build/sm/Evac_thr.c, line 298 seq: internal error: ASSERTION FAILED: file rts/dist/build/sm/Evac_thr.c, line 369 The problem was in the marshalling of a certain struct. The struct has 3 Color fields and two char fields. The Colors are simply triples of chars. I'd been using an alignment macro I've seen around: #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); },y__) Since my struct is made out of chars, this macro returns an alignment of 1. However, an alignment of 1 seems to be what leads to the GC crash. After setting the alignment to 4 I've never had the crash again. So... what's going on here? Is the macro wrong? Alignment 1 seems correct for something built of chars... or does a 'struct { char, char, char }' embedded in another struct turn it into alignment 4 somehow? Alignment seems like a particularly problematic part of the FFI, which is in all other respects very easy to use. It's low level, poorly understood (well, by me at least), not super well documented, and one little mistake can either be harmless, or lead to a *very* hard to track down bug. If the alignment macro is correct, can it be built into hsc2hs? Copy and pasting some magic I saw on the net into every hsc file doesn't give me a good feeling. If it's incorrect, what would a correct one be? One odd thing about that macro is that if you mis-spell a field name, gcc gets a bus error (OS X 10.5.8, gcc 4.0.1, does anyone else see this?) Or is the alignment correct and it really is a ghc bug? If so, how can I help track it down? The best I can think of is to make a small program with that same data structure, pass it around some, and then generate and collect a lot of garbage, but this bug has been really hard to pin down in the past, change one little thing and it disappears only to pop up again in 6 months.

2 1

Type Families and defaults
by Mitar 09 Sep '10

09 Sep '10

Hi! I see here: http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus That defaults in type families are not yet implemented. But how far is this? And how far is overall implementation of this? There seems to be a lot of open bugs around that? Are type families meant to be used or is that still an experimental feature? For example, I have problems type checking the attached code (Test.hs). Is there a way to define a default function as I envisioned it? Or is this just broken code? ;-) It seems it is the later as also version with dependencies does not work (Test2.hs). Best regards Mitar

3 6