September 2010 - Glasgow-haskell-users

Hashcode for reference
by Mathieu Giorgino 29 Sep '10

29 Sep '10

Hi all, I'm wondering if there is a way to get an hashcode from references (IORef or STRef)? I have looked in the library and a little in the sources of GHC but haven't found anything allowing to do this. I'm generating Haskell code from the Isabelle/HOL proof assistant, which generate "generic" code for other langages too which all have this notion, and I would so need an equivalent in Haskell. Have you any hint on how to achieve this, or even if it is possible? Mathieu

3 2

how to terminate an external program after timeout?
by Christian Maeder 29 Sep '10

29 Sep '10

Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode "metis" filename "" However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Thanks Christian

6 11

DPH, granularity, and GPUs
by Vivian McPhail 29 Sep '10

29 Sep '10

Hello, DPH seems to build parallel vectors at the level of scalar elements (doubles, say). Is this a design decision aimed at targettiing GPUs? If I am filtering an hour's worth of multichannel data (an array of (Vector Double)) then off the top of my head I would think that the optimal efficiency would be achieved on n cpu cores with each core filtering one channel, rather than trying to do anything fancy with processing vectors in parallel. I say this because filters (which could be assembled from arrow structures) feedback across (regions of) a vector. Do GPUs have some sort of shift operation optimisation? In other words, if I have a (constant) matrix A, my filter, and a datastream, x, where x_i(t+1) = x_{i-1}(t), can a GPU perform Ax in O(length(x))? Otherwise, given the cost of moving data to and from the GPU, I would guess that one sequential algorithm per core is faster (Concurrent Haskell) and that there is a granularity barrier. Cheers, Vivian

1 0

Version 7.0.1-rc1 bootstrapping
by David Fox 28 Sep '10

28 Sep '10

In order to bootstrap with the compiler we are using, I had to rename the function at line 13 of compiler/utils/Exception.hs from mask_ to mask. Sorry I didn't reply to the announcement, I just found out I wasn't subscribed to this list. (I also had to change <613 to <614, but this won't affect many people.)

4 4

Re: Does GhcDebugged work?
by Ian Lynagh 28 Sep '10

28 Sep '10

On Tue, Sep 28, 2010 at 12:22:52PM -0400, Edward Z. Yang wrote: > Excerpts from Ian Lynagh's message of Fri Sep 24 17:23:16 -0400 2010: > > Note that if you're running validate you need to set settings in > > mk/validate.mk instead. > > Ah, that's good to know. If you've run a validate on the checkout before, > does mk/validate.mk stick? (that is, if you remake, does it continue to use > those settings?) Yes, unless you make clean. (it works by putting Validating=YES in mk/are-validating.mk) Thanks Ian

2 1

Does GhcDebugged work?
by Edward Z. Yang 24 Sep '10

24 Sep '10

I wasted an afternoon compiling GHC with GhcDebugged = YES in my mk/build.mk, only to have ghc-stage2 tell me it wasn't compiled with -debug. Looking at mk/config.mk.in, it seems that GhcDebugged is unconditionally set to NO. What am I doing wrong? Edward

2 1

Re: GHCi 6.12.3 stdout redirection works for :type, but not for :info
by Claus Reinke 23 Sep '10

23 Sep '10

> good diagnosis. want to make a ticket? done: http://hackage.haskell.org/trac/ghc/ticket/4332 On second thought: is there any reason to use haskelline for *output*, as opposed to *input* history logging/editing? If not, avoiding that might be the easiest fix. Claus > | -----Original Message----- > | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- > | users-bounces(a)haskell.org] On Behalf Of Claus Reinke > | Sent: 22 September 2010 16:05 > | To: GHC users > | Subject: Re: GHCi 6.12.3 stdout redirection works for :type, but not for > | :info > | > | > | > The problem is that my code for redirecting the output > | > of GHCi commands still works for things like :type, but > | > no longer for things like :info (this is my smallest example > | > demonstrating the effect). > | > | The difference seems to be between commands that use > | old-style GHCi output (works with redirection) versus > | commands that output via Haskelline (redirection fails). > | > | ':type' calls typeOfExpr, which still uses 'printForUser', > | which ultimately goes down to > | 'compiler/utils/Pretty.lhs:printDoc', where it just calls > | 'hPutChr/Str stdout'. > | > | ':info' calls 'info', which uses 'outputStrLn', which > | ultimately goes down to > | 'Haskelline/Backend/Win32.hsc:putOut', where it > | calls either 'WriteConsole' (if to terminal), or > | 'Data.ByteString.putStr' (no terminal). > | > | The distinction between terminal and no terminal > | is currently done only once per GHCi session, so > | redirecting stdout to a file for just one command > | will call 'WriteConsole' on a non-terminal handle > | (redirecting the whole session works, though it is > | useless for writing advanced GHCi commands). > | > | I consider this a serious GHCi regression (never > | mind the inconsistencies between GHCi commands), > | as it breaks all the nice .ghci goodies from my old > | tutorial (*) that people keep writing to me about. > | > | If this analysis is correct, possible fixes would be: > | > | - use 'printForUser/outputStrLn' consistently > | (why is the latter needed for some commands, > | but not for others?), and ensure that terminal > | status is checked for each GHCi command, > | instead of once per session (the main problem > | is the version of 'putOut' that goes into the > | 'RunTerm structure's 'putStrOut' field - it is > | set by 'myRunTerm' in 'runInputTWithPrefs') > | > | - expose a GHCi command that allows users > | to trigger Haskelline's terminal status check, > | and rewrite the redirection code accordingly > | > | Sadly, I won't be able to implement either myself > | at the moment - is there a chance of getting this > | fixed for the 7.0.1 release (the first variant would > | be the proper fix, the second variant a quick hack > | to restore functionality)? > | > | Claus > | > | (*) http://haskell.org/haskellwiki/Ghci#Using_.ghci.2C_a_mini-tutorial > | > | > With the attached GHCi script defining a > | > > | > :redir <var> <command> > | > > | > command that should redirect the ouput of <command> > | > into variable <var>, we get the output appended below > | > (note the Exception for WriteConsole "handle is invalid", > | > which is written into the temporary file when :info is > | > called while stdout is redirected to that temporary file; > | > in other words, the error message appears where the > | > output of the command fails to appear). > | > > | > Is that an expected change with a known workaround, > | > so that I just need to update my code, or is that > | > unexpected behaviour that can only be fixed in GHCi? > | > > | > Claus > | > > | > PS. This is on Windows 7, if that matters. > | > > | > ------------- example session output > | > $ ghcii.sh -ignore-dot-ghci > | > GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help > | > .. > | > Prelude> :cmd readFile "redir.script" > | > Prelude> :redir x :t map > | > .. > | > Prelude> x > | > "-- logging GHCi stdout\nmap :: (a -> b) -> [a] -> [b]\n" > | > Prelude> :redir y :i map > | > Prelude> y > | > "-- logging GHCi stdout\n*** Exception: WriteConsole: invalid argument > | > (Das > | > Handle ist ung\252ltig.)\n" > | > > | > | > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users(a)haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

2 1

Cost Centre MAIN
by Stefan Wehr 23 Sep '10

23 Sep '10

Hi all, I'm profiling a Haskell program and now getting that the program spents 56% of its individual time in the cost centre MAIN (note the capital letters). I searched the documentation for this cost centre, with no success. In all profiling results so far, the individual time spent in MAIN was always 0%. Any hints? -- Stefan

2 2

GHC 6.13 + Data.Vector experiences
by Christian Höner zu Siederdissen 22 Sep '10

22 Sep '10

Hi, I am about to upload a number of packages to hackage. They are all needed by RNAFoldProgs. The main program therein, RNAFold, replicates RNAfold of the ViennaRNA package. The difference is that the algorithm already uses a newer set of parameters; the C functionality will follow soon from our lab. But that is not why this message: RNAFold requires a total of 15 lookup tables (multidimensional arrays), from 1-d arrays up to a maximum of 6 dimensions. We write into 5 different 2-dimensional tables. 15 different (and rather complex) functions are involved in filling the tables. Everything is built upon the Data.Vector package to facilitate fusion to happen (though it boils down to map+enumFromN most of the time). Some measurements on an input sequence show the following: ViennaRNA / C: 1.75s 6.13.20100826 / llvm / O2: 40s 6.13 / llvm O3 / Odph: 17.5s 6.12.3 / c O3 / Odph: 535s (really, nine minutes [1]) Unfortunately, between last and this week, the time went from ~13s to 18s but instead of fiddling around, I thought to release the packages for anyone interested. Please take it only as my personal testbed for Data.Vector and head -- though should you want to use the lib for actual rna secondary structure prediction, that should work, too. Anyways, there are probably a number of bugs in there, so be warned. The target is, of course, to have a runtime of 1.74s on my machine :-) Thanks to don stewart (uvector), roman leshchinskiy (vector) and simon peyton jones (default method inlining [1]) [1] "6.12.3" shows just how much the working default method inliner brings. With 6.12, everything goes through dictionaries which is not cool if you need to do many millions of min/+ operations (We work on a ring and instanciate very late in the game). Viele Gruesse, Christian PS: Why are my executables with HEAD like 60mbyte in size?!

1 0

GHCi 6.12.3 stdout redirection works for :type, but not for :info
by Claus Reinke 22 Sep '10

22 Sep '10

Dear GHCi / IO experts, I'm encountering some odd GHCi behaviour with some old ghci.conf code of mine (used to work in older GHCis). The problem is that my code for redirecting the output of GHCi commands still works for things like :type, but no longer for things like :info (this is my smallest example demonstrating the effect). With the attached GHCi script defining a :redir <var> <command> command that should redirect the ouput of <command> into variable <var>, we get the output appended below (note the Exception for WriteConsole "handle is invalid", which is written into the temporary file when :info is called while stdout is redirected to that temporary file; in other words, the error message appears where the output of the command fails to appear). Is that an expected change with a known workaround, so that I just need to update my code, or is that unexpected behaviour that can only be fixed in GHCi? Claus PS. This is on Windows 7, if that matters. ------------- example session output $ ghcii.sh -ignore-dot-ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help .. Prelude> :cmd readFile "redir.script" Prelude> :redir x :t map .. Prelude> x "-- logging GHCi stdout\nmap :: (a -> b) -> [a] -> [b]\n" Prelude> :redir y :i map Prelude> y "-- logging GHCi stdout\n*** Exception: WriteConsole: invalid argument (Das Handle ist ung\252ltig.)\n"

1 1