November 2009 - Glasgow-haskell-users

Changes to the ticket system
by Simon Marlow 17 Nov '09

17 Nov '09

I've made a few changes to the ticket system today, in preparation for a push on cleaning up the ticket database (announcement to be made shortly). The changes are: 1. There's a new field "Type of Failure", with values None/Unknown Build failure Install failure GHC doesn't work at all Compile-time crash Runtime crash GHCi crash Incorrect result at runtime Compile-time performance bug Runtime performance bug Hopefully the values are self-explanatory. Setting this correctly will help us to focus on important tickets, and may help us automatically prioritize tickets in the future. 2. The "Severity" field has gone away. This field was intended to be used as a way for ticket submitters to communicate to us the importance of the bug to them, but in practice it wasn't clear how to use it, it hasn't been used consistently, and as a result we generally ignore it. The new "Type of Failure" is a much less ambiguous way to communicate some of the same information. 3. The "Difficulty" field has more sensible values representing a range of times, rather than just "1 hour" or "1 week": Unknown Easy (less than 1 hour) Moderate (less than a day) Difficult (2-5 days) Project (more than a week) Rocket Science Cheers, Simon

3 4

Ubuntu ghc6 package (german translation)
by Heiko Studt 16 Nov '09

16 Nov '09

To: glasgow-haskell-users Cc: ubuntu-devel-discuss Hi, the German translation of the ghc6 package description is some kind of wrong in the current Ubuntu 9.10: the technical term "lazy" is translated as "träge" which means (slow, lazy) with an accent on slow. I don't know whether there is a default translation in the haskell universum (like "faul"). In my opinion the best would be to stay at the technical term "lazy". Possibly this mistake was done in other translations as well. Mit freundlichen Grüßen (With kindly regards) Heiko Studt

2 1

3 questions regarding profiling in ghc
by Daniil Elovkov 13 Nov '09

13 Nov '09

Hello Sorry for the uninformative subject, but I've got no less than 3 questions about profiling in ghc. Here we go 1) Can I profile my program if I don't have all the libraries it depends on compiled with profiling? ghc says it can't find profiling variants of this and that module in other packages, when I try ghc -prof. I managed to build all the dependencies with profiling, but that being a necessity doesn't look good to me. Maybe there's a way to avoid that? Moreover, as far as I could tell functions from those packages didn't appear in the call graph after +RTS -p profiling. 2) Can I exclude a function from profiling? That probably means not assigning a cost centre to it. Typical case, I think. Database connect function is rather heavyweight (regarding time) compared to the rest of the code, and it takes up to 98% of time. So the rest of the picture is less informative than it could be. 3) Isn't it possible to have -p profiling data of the interrupted (ctrl-c) program? Thanks a lot! -- Daniil Elovkov

4 4

Re: [Haskell-cafe] Fwd: (Solved) cabal install with external gcc tool chain not the ghc-bundled one
by Duncan Coutts 12 Nov '09

12 Nov '09

On Thu, 2009-11-12 at 10:46 +0100, Daniel Kahlenberg wrote: > to answer this question myself how the use of another gcc is specified > with effect, I used the following options with the 'cabal install' call: > > --ghc-options="-pgmc e:/programme/ghc/mingw-gcc4/bin/gcc.exe -pgml > e:/programme/ghc/mingw-gcc4/bin/gcc.exe" > > See > http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html… > (searched in the wrong direction, too many trees...). Slightly tuned, > this should be the way to go in all similar cases. > > One thing I haven't considered yet is if the '--with-ld' and > '--with-gcc' options (if curious too, see logs in my previous mail - > Subject "[Haskell-cafe] caba install with external gcc toolchain not the > ghc-bundled one") only effect what gets written into the > setup-config/package.conf file or what other effects these have. Feel free to file a ticket about this. What makes me somewhat nervous is that the gcc you want to use for say .c files is not necessarily the same as the one ghc wants to use to compile .hc files or link stuff. This is particularly the case on Windows where ghc includes its own copy of gcc. Similarly on Solaris 10, ghc cannot use the /usr/bin/gcc because it's a hacked-up gcc that uses the Sun CC backend (which doesn't grok some of the crazy GNU C stuff that ghc uses). So it'd certainly be possible to have cabal's --with-gcc/ld override the ones that ghc uses by default, but the question is should it do so? I think it's worth asking the ghc hackers about this. Duncan

1 0

GHCI :reload module without erasing previous data
by Michael Serdar 11 Nov '09

11 Nov '09

I have a module that loads several dozen megabytes of static data into memory. This module is working properly. I have another module that I'm developing to analyze that data. As I make iterations on the analysis module, I would like it if the data loaded by the data module could stay in memory. In GHCI, every time I reload a module, it clears whatever data I have set with the "let" command. Is there a way to persist that data across calls to :reload, or is there an altogether different workflow I should be using for this?

2 1

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

Compiling to ANSI C
by han 09 Nov '09

09 Nov '09

I am (in fact we are) working to make Haskell code to run on an ARM Linux machine called GP2X Wiz, the open-source based handheld game console. I wish to finally make a Haskell cross-compiler for ARM Linux, and for now I am trying to make main = putStrLn "Hello, World!" to run on the machine. At first I did $ ghc hello.hs -o hello -fvia-C -keep-hc-files and tried to use the generated hc file, but figured that the code is (or at least some code in the included headers is) x86-dependent. I heard that the GHC can compile to ANSI C, and I want to use it as an intermediate code to ARM Linux before we can actually port the GHC to it. Is there any specific option I have to give in order to generate an ANSI C code from a Haskell source code?

7 6

Re: Compiling to ANSI C
by scooter.phd＠gmail.com 07 Nov '09

07 Nov '09

Believe it when it shows up in GHC pristine. ------Original Message------ From: Thomas DuBuisson To: scooter.phd(a)gmail.com Cc: han Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 11:28 On Sat, Nov 7, 2009 at 11:16 AM, <scooter.phd(a)gmail.com> wrote: > Do we have a native LLVM bitcode writer or is it still FFI? I was referring to a paper [1] I just ran into on reddit. I only skimmed it, but it seems they (or just he?) integrated LLVM as a new backend for GHC. Thomas [1] http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf Sent from my Verizon Wireless BlackBerry

1 0

Re: Compiling to ANSI C
by scooter.phd＠gmail.com 07 Nov '09

07 Nov '09

Do we have a native LLVM bitcode writer or is it still FFI? ------Original Message------ From: Thomas DuBuisson Sender: glasgow-haskell-users-bounces(a)haskell.org To: han Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Compiling to ANSI C Sent: Nov 7, 2009 09:56 If I were you, I'd look at using the recent LLVM backend work as a means to translate Haskell -> ARM. Thomas On Sat, Nov 7, 2009 at 9:08 AM, han <e(a)xtendo.org> wrote: > I am (in fact we are) working to make Haskell code to run on an ARM > Linux machine called GP2X Wiz, the open-source based handheld game > console. > > I wish to finally make a Haskell cross-compiler for ARM Linux, and for > now I am trying to make > > main = putStrLn "Hello, World!" > > to run on the machine. At first I did > > $ ghc hello.hs -o hello -fvia-C -keep-hc-files > > and tried to use the generated hc file, but figured that the code is > (or at least some code in the included headers is) x86-dependent. > > I heard that the GHC can compile to ANSI C, and I want to use it as an > intermediate code to ARM Linux before we can actually port the GHC to > it. > > Is there any specific option I have to give in order to generate an > ANSI C code from a Haskell source code? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sent from my Verizon Wireless BlackBerry

2 1

ANNOUNCE: GHC 6.12.1 Release Candidate 1
by Ian Lynagh 07 Nov '09

07 Nov '09

Hi all, We are pleased to (finally!) announce the first release candidate for GHC 6.12.1: http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

17 36