- Glasgow-haskell-users

RE: AMD64
by Simon Marlow 01 Jun '04

01 Jun '04

On 31 May 2004 20:53, scott west wrote: > Well, I just poked and proded the build a bit more, and got it to > complete and install, with the same result as you. Seg faults > immediately and that's it. Hmm, any else had any experience with this? The amd64 port isn't really there yet. It works unregisterised, but the registerised support need some more work (as you discovered). You also need a non-broken version of gcc (3.3.3 or 3.4.0). Don Stewart was working on this recently; I'm not sure how far he got. Cheers, Simon

2 1

AMD64
by scott west 31 May '04

31 May '04

Hello, I was just trying to cross compile ghc for my new amd64 box and was just wondering to what stage others have gotten with it? Personally I get a working ghc-inplace, and then I've tried to methods, neither of which work. First, I get a fresh source tree (all compilations were with 6.2.1) and do a configure passing --with-ghc=/path/to/ghc-inline, this works pretty well for a while, and eventually it cops out when it tries to find Data.Array and can't. Tried some other things with this method and they only got me marginally furhter (but I'm fairly sure it wasn't the proper way to go about it). Next, I tried, after using the supplied hc-boot script (which did complete), to do a make install... this also fails with: ghc-6.2.1: error: directory portion of "stage2/absCSyn/AbsCSyn.o" does not exist (used with "-o" option.) So stage2 isn't there, I verified that, but i'm not really familiar enough to know when/where it is created. Can anyone shed any light on this? Thanks!

2 2

RE: Compiling data
by Simon Peyton-Jones 27 May '04

27 May '04

GHC is indeed utterly terrible when compiling source files that contain a lot of literal data. This seldom bites (which is why we keep postponing doing anything about it) but when it bites, it bites badly, as you found. There's some non-linear algorithm going on. If any helpful person out there with a build-GHC setup would like to build a profiled version of the compiler, and poke around a bit to localise where all the time is going, that'd make it much more likely that I'd do something about it. It might even be trivial to fix, who knows. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ketil Malde | Sent: 27 May 2004 10:41 | To: glasgow-haskell-users(a)haskell.org | Subject: Compiling data | | | Hi, | | I've recently tried to compile some data into my program, and suddenly | I realize why people tend to complain about the speed of GHC. | | For a benchmark, I'd like to include a bit of data in the form of a | list of integer matrices (i.e. [[[Int]]]). While I have about 10000 of | them, sized about twenty square, even 100 of them takes extremely | long to compile. Is there a trick to make this faster? | | (For short lists (1-8 matrices), time seems to scale linarly, but the | 100-matrix took much longer than expected from a simple extrapolation) | | Also, it takes a long time before any error is produced, it'd be nice | if syntactical problems were reported as quickly as possible (perhaps | they are?) | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

messages from `make'
by Serge D. Mechveliani 24 May '04

24 May '04

Dear GHC team, When `make' preforms for the GHC build from source, it works so long and concludes only with a technical message about leaving some directory, and no explanations for the naive user of what finally has happenend. And the user doubts of whether this is a success. Maybe, it worths to finish `make' with some common-sense message? Like "everything looks compiled, you may try this and this". With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: ghci and ld scripts
by Simon Peyton-Jones 24 May '04

24 May '04

We've no idea what to do here. In your case it'd be possible to just ignore the script, but presumably not so in general. If anyone who understands the problem properly would like to advise, we'd be happy to hear from them. Parsing ld scripts seems beyond what our linker is ever going to do! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Duncan Coutts | Sent: 16 May 2004 16:48 | To: GHC-users list | Subject: ghci and ld scripts | | So here's the problem: | | We have a Haskell binding to a C library (one of the gtk extension libs) | which uses the pthread library. So we put "pthread" in the | extra_libraries section of our ghc package conf file. | | This works fine when building standalone programs, however when we try | and use this package in ghci we get this error: | | ... | Loading package gtk2 ... linking ... done. | Loading package sourceview ... ghc-6.2.1: can't load .so/.DLL for: | pthread (/usr/lib/libpthread.so: invalid ELF header) | | Inspecting /usr/lib/libpthread.so we find that indeed it is not a .so | file but a gnu ld script: | | /* GNU ld script | Use the shared library, but some functions are only in | the static library, so try that secondarily. */ | OUTPUT_FORMAT(elf32-i386) | GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) | | So we should get ghci to dynamically load /lib/libpthread.so.0, however | there is no way to specify this in the package.conf file. | | It turns out that we don't need ghci to load this .so because it is a | dep of another .so that we do load, however if I leave it out then | building standalone progs would fail to link. | | Has anyone come across this before? How do you deal with it? | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: F#
by Simon Marlow 21 May '04

21 May '04

On 21 May 2004 01:07, John Sharley wrote: > I note this remark on the Microsoft Research site > (http://research.microsoft.com/projects/ilx/fsharp.aspx) > <quote> > Purely functional languages like Haskell are excellent within certain > niches, but unfortunately some simple programming exercises can > quickly turn into problems that require a PhD. to solve. > </quote> > > Are the Microsoft Research people working on GHC or anyone else on > this list also of this opinion? If so, why? > > What if anything does the quoted remark mean for the prospects of > seeing a production Haskell compiler from Microsoft? A response from the author of that page (Don Syme, also here at MSRC): On 21 May 2004 15:00, Don Syme wrote: > I've removed the offending line, since I didn't mean to be > inflammatory. I believe it to be true - writing a GUI library > wrapper for Win32 is fairly simple in C#, pretty hard in F#, and > really quite researchy in Haskell - but others obviously don't agree. > > Replaced with > > Purely functional languages like Haskell are excellent > within certain niches, but non-trivial problems exist with language > interoperability between lazy and strict languages. > > I believe that is uncontroversial. Forward this to the Haskell list > if you like. Change should propagate to research.microsoft.com > sometime soon. > > Cheers > > Don

2 1

RE: Overlapping, undecidable, incoherent -- or worse?
by Simon Peyton-Jones 21 May '04

21 May '04

| > I agree, I have made it not terminate myself with | > undecidable-instances, | > I also think prolog style backtacking would be a good idea... | | For what it's worth, I'll AOL this ("me too"). I know that for the | area of Haskell I'm exploring (integrating it with OO languages), | putting backtracking into the type system would instantly enable us | solve some significant problems. I'll bear this in mind. I think the main implementation difficulty concerns functional dependencies: when backtracking out one will have to undo any unifications triggered by functional dependencies. Nothing difficult in principle, but the constraint solver is one of the more delicate parts of GHC because GHC's constraint language has become so complex. Simon

2 1

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 21 May '04

21 May '04

>I pointed out that the type system _may already_ not terminate I agree, I have made it not terminate myself with undecidable-instances, I also think prolog style backtacking would be a good idea... I think I said that you either want full backtracking or you want to leave it how it is (with dependancies ignored) - I have yet to be convinced that any partial solution would have the elegance of full backtracking, yet would complicate the implementation and syntax. Keean.

3 2

Statically linked binary?
by Jochen L. Leidner 21 May '04

21 May '04

Hi, sorry for an urgent newbie question: how can I create a statically compiled version of a Haskell program on Linux with GHC that does not rely on external shared libs (also for any of its libraries it uses)? I would like to build a binary that works on a 3-processor machine with an older Linux SMP kernel as well as RH9/FC2. Thanks in advance, Jochen -- Jochen L Leidner <leidner(a)acm.org> ICCS <Jochen.Leidner(a)ed.ac.uk> University of Edinburgh <http://www.iccs.informatics.ed.ac.uk/~s0239229/>

2 1

RE: F#
by Simon Marlow 21 May '04

21 May '04

On 21 May 2004 01:07, John Sharley wrote: > I note this remark on the Microsoft Research site > (http://research.microsoft.com/projects/ilx/fsharp.aspx) > <quote> > Purely functional languages like Haskell are excellent within certain > niches, but unfortunately some simple programming exercises can > quickly turn into problems that require a PhD. to solve. > </quote> > > Are the Microsoft Research people working on GHC or anyone else on > this list also of this opinion? If so, why? > > What if anything does the quoted remark mean for the prospects of > seeing a production Haskell compiler from Microsoft? It's possible that the remark is referring to the use of monads to do IO in Haskell, but I wouldn't read too much into it. Cheers, Simon

1 0