- Glasgow-haskell-users

ANN: C->Haskell 0.14.1 "Travelling Lightly"
by Manuel M T Chakravarty 15 Jul '05

15 Jul '05

Version 0.14.1 "Travelling Lightly" of C->Haskell introduces three radical changes: * Death to make! We have got brand new Cabal-based build system. * Brand new C lexer/parser based on Alex and Happy kindly contributed by Duncan Coutts. This reduces the memory consumption when compiling bindings to large C libraries dramatically. * No separately installed marshalling library anymore. Support code is provided in source form. Hence, a single C->Haskell installation can generate bindings for any Haskell system and version. The hitch is that you need to use Cabal 1.0.1 to build the system (not version 1.0 included with GHC 6.4, as this misses a crucial feature). Happy Hacking! Manuel PS to GHC HQ: Can we please have the latest Cabal in GHC 6.4.1?

1 0

RE: Problem building GHC
by Simon Marlow 14 Jul '05

14 Jul '05

On 13 July 2005 08:18, Dinko Tenev wrote: > On 7/13/05, John Skaller <skaller(a)users.sourceforge.net> wrote: >>> I guess I'll have to switch to version 2.95.2 as >>> suggested by the guide (I am currently using 3.3.5,) >> >> I think you need more RAM. I had to >> buy a new computer to fix this problem. > > Oh my, that hurts...quite an expensive piece of software, GHC ;) But > this really explains a lot, because two identical builds of mine > happened to die on different files - it never occurred to me GCC could > run low on memory though... > > How about more swap, provided I would let it run overnight? You should be able to use the native code generator to build GHC, which will compile a lot faster and use less memory. The GHC binary it produces may be slightly slower, however (on x86). To do this, create a file mk/build.mk in your build tree, containing the line: SRC_HC_OPTS = -H32m -O -fasm Cheers, Simon

2 2

rendering fonts with OpenGL
by Felix Breuer 14 Jul '05

14 Jul '05

Hello everyone! What is the recommended way to render fonts (i.e. text) using GHC and OpenGL? I know about libraries/GLUT/examples/RedBook/Font.hs, but I do not want to define the font's letter by hand. So, my questions are: * Is there a ready-to-use way load fonts (e.g. using FreeType)? * Is there a library implementing some OpenGL font rendering method (bitmap, texturemap, outline, etc.) that can be used from GHC? * Does anyone have example code for the above? Thanks, Felix Breuer

2 1

Cabal and older versions of GHC
by Dimitry Golubovsky 13 Jul '05

13 Jul '05

Is it possible to use Cabal with older versions (e. g. 6.0 to 6.2.2) of GHC? Some time later, I am going to release HSFFIG as a package. To be usable with GHC 6.2.2, can it be packaged with Cabal, or do I have to use ghc-pkg? If I use ghc-pkg, is there a way to convert such a package into Cabal? I am not going to upgrade to GHC 6.4.x any time soon, so what are my options in using Cabal with 6.2.2? -- Dimitry Golubovsky Anywhere on the Web

4 5

RE: private modules
by Simon Marlow 11 Jul '05

11 Jul '05

On 11 July 2005 10:31, Wolfgang Jeltsch wrote: > I thought, I heard something about a "private modules" feature in > GHC. Was I just dreaming or is there in fact something like this. I > cannot find information about such a thing. If you use Cabal, your package can have "hidden modules" which won't be visible outside your package. Cheers, Simon

1 0

private modules
by Wolfgang Jeltsch 11 Jul '05

11 Jul '05

Hello, I thought, I heard something about a "private modules" feature in GHC. Was I just dreaming or is there in fact something like this. I cannot find information about such a thing. Best wishes, Wolfgang

1 0

RE: option for enabling generalized deriving for newtypes
by Simon Peyton-Jones 11 Jul '05

11 Jul '05

Not at the moment. There could be -- it's just one more thing to implement and document, but it's a relatively easy one. Does anyone else have an opinion? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Wolfgang Jeltsch | Sent: 10 July 2005 18:43 | To: GHC Users ML | Subject: option for enabling generalized deriving for newtypes | | Hello, | | isn't there an option for enabling just generalized deriving for newtypes | without enabling all this other stuff by using -fglasgow-exts? | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

option for enabling generalized deriving for newtypes
by Wolfgang Jeltsch 10 Jul '05

10 Jul '05

Hello, isn't there an option for enabling just generalized deriving for newtypes without enabling all this other stuff by using -fglasgow-exts? Best wishes, Wolfgang

1 0

RE: Performance on amd64
by Simon Marlow 06 Jul '05

06 Jul '05

On 05 July 2005 16:25, John Skaller wrote: > On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote: >> On 05 July 2005 10:38, John Skaller wrote: >> >>> Can someone comment on the Debian package for Ubuntu Hoary >>> providing ghc-6.2.2 with binary for amd64? >> >> You're probably running an unregisterised build, which is going to be >> generating code at least a factor of 2 slower than a registerised >> build. You can get an up to date snapshot of 6.4.1 for Linux/x86_64 >> here: >> >> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1.20050704-x86_64-un >> known-linux.tar.bz2 > > > Thanks, downloading it now.. will try. What exactly is > a 'registered' build? An "unregisterised" build generates plain C which is compiled with a C compiler. The term "registerised" refers to a set of optimisations which require post-processing the assembly generated by the C compiler using a Perl script (affectionately known as the Evil Mangler). In particular, registerised code does real tail-calls and uses real machine registers to store the Hsakell stack and heap pointers. An "unregisterised" build is usually the first step when porting GHC to a new architecture, before support for the "registerised" optimisations is added. GHC's native code generators also generate "registerised" code. >> This build is registerised, but doesn't have the native code >> generator. > > Which would generate the best code? -fvia-C has traditionally produced slightly better code than -fasm, at least on x86. On other platforms it might be the other way around. >> I hope you're not going to conclude *anything* based on the >> performance of ackermann and tak! :-) > > Ackermann is a good test of optimisation of a recursive > function, which primarily require the smallest possible > stack frame. Of course it is only one function, more need > to be tested. > > In fact, this one test has been very good helping me get > the Felix optimiser to work well -- the raw code generated > without optimisation creates a heap closure for every function, > including ones synthesised for conditionals and matches, etc. > If I remember rightly, it took 2 hours to calculate Ack(3,6), > and I needed a friend to use a big PPC to get the result > in two hours for Ack(3,7). > > So ... you could say the Felix optimiser has improved a bit... :) Sure, it's good to look at these small benchmarks to improve aspects of our compilers, but we should never claim that results on microbenchmarks are in any way an indicator of performance on programs that people actually write. > If you would like to suggest other tests I'd be quite interested. > At the moment I'm using code from the Alioth Shootout, > simply because I can -- saves writing things in languages > I don't know (which includes Haskell unfortunately). The shootout has lots of good benchmarks, for sure. Don't restrict yourself to the small programs, though. It's still hard to get a big picture from the results - there are too many variables. I believe many of the Haskell programs in the suite can go several times faster with the right tweaks, and using the right libraries (such as a decent PackedString library). Cheers, Simon

3 2

It's bug time!
by Simon Marlow 06 Jul '05

06 Jul '05

Folks, Here at GHC HQ we've decided the bug list is getting a bit on the long side. Furthermore, we plan to put out 6.4.1 in about a month, so it seems like a good time to have a bug-squashing session. The sourceforge bug list is here: http://sourceforge.net/tracker/?group_id=8032&atid=108032 Anything that isn't explicitly assigned to someone is up for grabs, and we'd welcome further information on *any* bug, assigned or not. If you have a sourceforge login and want to be added to the dev list for GHC, let us know. Even if you don't have a sourceforge login and would like to tackle a bug, just post here. Don't pay too much attention to the priorities at the moment, although anything less than 5 we have deemed to be non-critical and not necessary for 6.4.1. Of course, feel free to yell if you disagree. After the bug squashing, we plan to have a performance-fest. We have plenty of performance issues outstanding (in fact, if you know of a specific perf problem, please submit it as a bug). Cheers, and happy hunting... Simon(s)

1 0