- Glasgow-haskell-users

Re: How easy is it to build a GHC cross compiler targeting Windows?
by Simon Marlow 15 Jun '10

15 Jun '10

[ glasgow-haskell-users CC'd, as requested ] Hi Hamish, Sorry for the delay in replying, things have been busy over the last few days with paper deadlines and suchlike. On 05/06/2010 15:14, Hamish Mackenzie wrote: > We want to try to add Haskell to TakeoffGW (a new Windows > distribution like cygwin, but using MinGW). TakeoffGW is built using > SUSE's mingw32 cross compiling system, so I figured the first step > would be to add GHC to that if possible. > > I figure we will need to two new GHC packages * mingw32-cross-ghc > (GHC cross compiler for building Haskell packages) * mingw32-ghc > (Windows GHC compiler to install on users machines) > > I am a bit concerned that making a cross compiler to build the > Haskell packages might not be practical. So before we spend to much > time on this I thought I should ask how hard it is to build a cross > compiler like this? Is it just a matter of setting the correct > configure flags? We will have the SUSE's mingw32 available > (including binutils and gcc cross compiler), but will this be > enough? First of all, I think TakeoffGW is a great idea, I've been hoping that something like this would emerge. In principle cross-compiling GHC ought to be possible, but actually making it work could be difficult. It's hard to predict without trying. Much of our build system is structured to make cross-compiling work: we have separate build/host/target platforms and generally try to check the correct one, but we almost never actually cross-compile GHC, only when porting GHC to a new platform and there it's a fairly involved manual process. If I had to guess, I'd say you'll probably run into quite a few things that need fixing in the build system to make this work. Probably nothing fatal, but lots of fiddling around. It would be worth doing, and we'll help as much as we can along the way if you want to try. > If we can build the cross compiler will we be able to use it to build > the Windows ghc with it? > > If there are parts that can't be done we may need to resort to using > Wine or a Windows machine. > > I wanted to CC the GHC developers mailing list, but haskell.org is > down. Could you please CC the appropriate list in your reply? Done! Cheers, Simon

1 0

hsc2hs on Mac OS 10.6 unreliable?
by Axel Simon 09 Jun '10

09 Jun '10

Hi all, we're facing serious problems (the seg'faulting kind) with Gtk2Hs on Mac OS 10.6. Chris has tracked this down to incorrect structure offsets that hsc2hs calculates. The offsets that hsc2hs calculates are too large, so it is probably in x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so it must have been compiled with something like -arch i386. My question is the following: What is the right way to compile unixy software on Mac OS 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not producing its C file in the correct way? It seems that a C Gtk+ program works correctly when compiled with no special flags. The only thing we could do is to pass some magic option to hsc2hs when it creates the C program that calculates the offsets. Detecting how Gtk + was compiled would require some sort of autoconf magic which is beyond a simple cabal file. So I probably cannot hope for an easy fix. Any comments or experience appreciated, cheers, Axel

4 5

Re: ANNOUNCE: MonadCatchIO-foreign
by Antoine Latter 09 Jun '10

09 Jun '10

Hi GHC, Is there a reason that Foreign.Marshall.Array.allocaArray calls into allocaBytes instead of allocaBytesAligned? Since alloca needs the alignment, wouldn't allocaArray also need it? I'm not too up on how memory access is supposed to work, it was just something that jump out at me. Thanks, Antoine On Sun, May 30, 2010 at 7:10 PM, Antoine Latter <aslatter(a)gmail.com> wrote: > Hello Haskell, > > I'd like to announce a very small library in two flavors. > > The problem I'm trying to solve is that we have some capabilities for > writing functions which are polymorphic over monad but still use IO > capabilities - liftIO :: (IO a -> m a) from the packages transformers > and mtl. The packages[1,2] MonadCatchIO offer similar polymorphism for > the exception capabilities of the IO monad. > > The package MonadCatchIO-foreign offers similar polymorphism for the > following functions: > > alloca, allocaBytes, allocaArray, allocaArray0 and withForeignPtr. > > It's a small thing, but I don't see why it should be written twice. > > Links on hackage: > > http://hackage.haskell.org/package/MonadCatchIO-mtl-foreign > http://hackage.haskell.org/package/MonadCatchIO-transformers-foreign > > GitHub link: > > http://github.com/aslatter/MonadCatchIO-foreign > > Feedback, praise and adulation welcome. > > Antoine >

3 3

Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
by Ian Lynagh 31 May '10

31 May '10

On Mon, May 31, 2010 at 12:38:56PM +0100, Barney Stratford wrote: > > Any ideas? Have you tried running the testsuite, to see if you can find a small failing program? I'd try the ffi tests first, e.g.: cd testsuite/tests/ghc-regress/ffi make CLEANUP=1 SKIPWAY=ghci Thanks Ian

1 0

Memory use blowup with -O1 (versus -O0) in GHC 6.12.1/6.12.2
by Robert Greayer 25 May '10

25 May '10

Hi, I've encountered an interesting issue with GHC 6.12.1 and 2 in which a small program compiles quickly without using loads of memory with optimization turned off, but with optimization (-O1) turned on, GHC's memory usage becomes very high (and compilation takes much much longer). $ time ghc -c -O0 Tst.hs real 0m0.107s user 0m0.073s sys 0m0.035s $ time ghc -c -O1 Tst.hs real 0m38.605s user 0m36.669s sys 0m1.923s Memory used by GHC looks like it tops out at 3G (in the -O1 case). Constraining the heap size to 1G causes compilation to fail: $ ghc +RTS -M1g -RTS -c -O1 Tst.hs Heap exhausted; Current maximum heap size is 1073741824 bytes (1024 MB); use `+RTS -M<size>' to increase it. (whereas, without optimization, a heap of 16m is sufficient) The module being compiled is (probably deceptively) simple: module Tst where import Merge data Rec1 = Rec1 !Int mkRec1 v = mk $ merge v () where mk (Tagged i :* ()) = Rec1 i but the devil is in the details of 'merge' (attached) which merges heterogeneous lists of values, using a lot of type level programming with type families. Does this sound like an known, open issue? I was unable to find anything in GHC Trac that looked similar. Thanks, Rob

3 2

RE: [Haskell-cafe] Re: Data instance for a GADT
by Simon Peyton-Jones 25 May '10

25 May '10

There have been a couple of emails about Template Haskell support for · GADTs · View patterns · Reifying instances There’s a ticket for this already http://hackage.haskell.org/trac/ghc/ticket/3497 It’s mainly a library design question, in this case the design of the Template Haskell data types in Language.Haskell.TH.Syntax. It needs some motivated person to propose a design, get a consensus, and write some boilerplate code. Just use the standard libraries process An issue is the extent to which it’s ok to change the Template Haskell data types (and thereby break people’s code), but that’s something the interested parties can work out together. If you evolve a consensus design I’m more than happy to make it part of GHC. I just don’t want to drive the consensus building! Simon From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ozgur Akgun Sent: 14 April 2010 10:53 To: Haskell cafe Subject: [Haskell-cafe] Re: Data instance for a GADT Seeing this old thread[1], I hope something happened towards enabling this. Does anybody know the current status about using TH on GADTs? [1] http://www.haskell.org/pipermail/template-haskell/2006-August/000567.html On 14 April 2010 10:32, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: answering to myself: I guess this is related: http://hackage.haskell.org/trac/ghc/ticket/3497 On 14 April 2010 10:13, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: Cafe, How can I provide a Data instance for a GADT? I am trying to TH on it, and Uniplate requires Data. I tried StandaloneDeriving, but it seems not to work.

1 0

6.12.3-candidate
by Serge D. Mechveliani 24 May '10

24 May '10

Dear GHC developers, I have tested ghc-6.12.3-candidate of 6.12.2.20100521 on Debian Linux, i386-family on making it by ghc-6.12.2, on making it by itself on the DoCon test, on the Dumatel test -- with skipping profiling. It looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: Dynamic libraries and GHCi
by John Lato 20 May '10

20 May '10

> From: Simon Marlow <marlowsd(a)gmail.com> >> > >> But currently there is one problem with "GhcShared=YES": with this >> option, the stage-2 compiler gets linked dynamically but the >> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, >> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around >> this by manually symlinking all the dynamic libraries to ./inplace/lib >> and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should >> be a solution better than this. > > On Linux we link the binary using -rpath (I know OS X doesn't have > -rpath). This is another issue we need to resolve before we can switch > to a dynamically-linked GHCi. > > Basically there's a fair bit to do to make a dynamic GHCi a reality, and > before we can do anything there are some tricky decisions to make. > When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1. John

3 5

Re: [Haskell-cafe] cabal: problem building ffi shared library and significance of __stginit
by Duncan Coutts 19 May '10

19 May '10

On Tue, 2010-05-18 at 17:31 -0400, Anthony LODI wrote: > Hello, > > I'm trying to build some haskell code as a .so/.dll so that it can > ultimately be used by msvc. I have it working when I compile by hand > (listed below) but I can't get the exact same thing built/linked with > cabal. On linux everything builds fine, but when I try to link the > resulting .so file, I get an error about a missing > '__stginit_CInterface' reference. Indeed I couldn't find that name in > any of the cabal-generated .dyn_o files. I checked the output of > 'cabal build -v' and it seems to be executing about the same thing > that I'm executing manually so I'm not sure what could be going wrong. > On windows cabal won't even configure since '--enable-shared' seems > to imply '-dynamic' (right?), and that's not currently supported. > > Also, when I remove the line 'hs_add_root(__stginit_CInterface);', and > the corresponding forward declaration, the program runs fine! Does > ghc no longer need this call or are my toy programs just being lucky > sofar? For reference for other people, Anthony and I worked this out today. full example: http://pastebin.com/aLdyFMPg The difference between doing it manually and building a library via Cabal is the package name. When building directly with ghc, the default package name is "" aka the main package. When building a ghc/Haskell package, the package name gets set (ghc -package-name test-0.0). This package name gets encoded into the symbol names. So we get: __stginit_testzm0zi0_CInterface vs __stginit_CInterface (testzm0zi0 is the Z-encoding of test-0.0) What is bad here is that the __stginit stuff is even necessary. Anthony is going to file a ghc ticket and/or complain on the ghc users list, citing this example. Duncan

1 0

Dynamic libraries and GHCi
by Simon Marlow 18 May '10

18 May '10

We had planned to switch to using a dynamically-linked GHCi for 6.14.1 (see http://hackage.haskell.org/trac/ghc/ticket/3658) which on the whole seems like the right direction to be heading in, since we reduce the dependence on our own RTS linker. The dynamically-linked GHCi works, and passes all the tests. It also starts up faster than the statically linked one, at least on Linux, possibly due to a combination of the system linker being faster than ours and it doing on-demand linking. That's the good news. But I've realised this transition won't be as easy as I thought. Currently if you build a package dynamically (Cabal's --enable-dynamic), then you get a completely separate build of the package, with its own interface files and so on - it's a "way", in the same sense as profiling. This seemed obviously the sensible thing to do, since we really are compiling the code multiple times, and the results might be different. However, it gives us a problem with GHCi. If GHCi is dynamically linked, then it can only load object code that is compiled with -dynamic, because then the object code will be compiled against the right .hi files. I see only three possibilities: - we make -dynamic the default. - we somehow make the two ways compatible. This would probably entail compiling both versions at the same time, so we get the same Core, but running the code generator twice. I think there might be some technical problems with doing this, as we sometimes turn static data into dynamic data when compiling with -dynamic. If we could work around this, though, the general idea would still require a lot of changes in build systems, Cabal, GHC and so on. - packages should have predictable & stable ABIs. I've been wanting to do this for a long time, but we're not ready yet, and even so I hadn't planned to impose stable ABIs on every package - e.g. doing this for the base package would probably limit cross-module optimisation too much. It's perhaps worth investigating the consequences of the first option, making -dynamic the default. Cabal would have to --enable-dynamic by default - perhaps it would get an --enable-static that could even be *off* by default. We would have to measure the performance implications carefully. I know that right now the GC takes quite a severe performance hit (about 30% or so) when compiled with -fPIC on x86, due to losing the %ebx register. I think that's unacceptable, but I haven't managed to fix it yet. I don't have a clear idea for how to proceed, so I thought I'd describe the issues here and see if we can come up with a plan. Cheers, Simon

4 5