- Glasgow-haskell-users

Windows: calling a process from Haskell
by George Russell 01 Mar '02

01 Mar '02

How do I start up a new process in Windows without stopping the world (as I presume System.system will do)?

1 0

RE: Weird symbol prevents GHCi from loading my package.
by Simon Marlow 01 Mar '02

01 Mar '02

> I built quite a big library and turned it into a package. It > works fine if > use ghc -package gtk2 Blah.hs to compile things. But when I > convert all > the libraries to object files as described in the documentation, GHCi > refuses to load the whole machinery: > > ~/source/mogul/fpDemo:$ ghci -package gtk2 Arabic.hs > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 5.02.2, > for Haskell > 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package std ... linking ... done. > Loading package lang ... linking ... done. > Loading package gtk2 ... > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol > gcc2_compiled. > whilst processing object file > /home/as49/local/lib/gtk2hs/gtk2hs.o I think this is due to a bug in GHCi's linker, which has been fixed post 5.02.2. I tripped over it recently while trying to use Gtk+HS in GHCi on my RedHat 7.2 box. There are two bugs tickled by gcc 2.96: our linker wasn't dealing with sections with names other than the standard ones (.text, .data, .rodata) properly, and there was also some infelicities in the local-symbol handling (Julian S. can tell you more). The workaround I used is to compile up any .c files in your package *without* -O, and without -g if you were also using that. Cheers, Simon

2 1

RE: mangler
by Simon Marlow 28 Feb '02

28 Feb '02

> How much (quantitatively) is gained by using GCC for compilation? It > sure sounds like it causes a lot of trouble. How much better > is it than an optimizing assembler? In most cases very little, in terms of performance, is gained by using gcc as an intermediate. If you use an optimising assembler though, you still need a native code generator (which we have, but GHC's native code generator is missing some things: eg. profiling support and architectures other than sparc & x86). Cheers, Simon

1 0

Haskell in Space
by Christoph Lueth 28 Feb '02

28 Feb '02

Dear Haskell people, as the last exercise of a second-year undergraduate Haskell course I had the students write an asteroids-type game (older readers may remember this arcade classic from the last century) using the Hugs Graphics Library. I put some solutions up on a wee web-page, because I thought it might amuse some of you who teach or learn Haskell, and because frankly one of the students' solutions simply deserved some wider attention: http://www.informatik.uni-bremen.de/~cxl/haskell-in-space Enjoy, --Christoph.

2 1

RE: cannot switch to qualified module names in ghci
by Simon Marlow 28 Feb '02

28 Feb '02

> It seems that if you are in a module X which imports Foo.Bar, > you cannot > use :m to get to the Bar module. > > X> :m Bar > can't find module `Bar' > X> :m Foo.Bar > strange looking module name: `Foo.Bar' > > It appears the remedy to this would be to modify the definition of > isAlphaNumEx in ghci/InteractiveUI.hs to: > > isAlphaNumEx c = isAlphaNum c || c == '_' || c == '.' > > it seems that the code in setContext and newContext know how to handle > qualified module name switches; it's just being blocked > before they can > try. Thanks, fixed. Simon

1 0

Cross compilers
by Sean Seefried 28 Feb '02

28 Feb '02

Look what came up when I tried to make a cross compiler. GHC configuration does not support differing host/target (i.e., cross-compiling) Now what do I do? Can I make a cross compiler? Sean Seefried

1 0

cannot switch to qualified module names in ghci
by Hal Daume III 28 Feb '02

28 Feb '02

It seems that if you are in a module X which imports Foo.Bar, you cannot use :m to get to the Bar module. X> :m Bar can't find module `Bar' X> :m Foo.Bar strange looking module name: `Foo.Bar' It appears the remedy to this would be to modify the definition of isAlphaNumEx in ghci/InteractiveUI.hs to: isAlphaNumEx c = isAlphaNum c || c == '_' || c == '.' it seems that the code in setContext and newContext know how to handle qualified module name switches; it's just being blocked before they can try. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

mangler
by David Feuer 27 Feb '02

27 Feb '02

How much (quantitatively) is gained by using GCC for compilation? It sure sounds like it causes a lot of trouble. How much better is it than an optimizing assembler? David Feuer

1 0

Re: SGI-Port // Mnagler-Gcc Interface...( Typing mistake on table)
by Rafael Martínez Torres 27 Feb '02

27 Feb '02

> > The other way to do the port is to bootstrap from HC files; i.e., > forget that any ghc build exists on your architecture, and start from > scratch. The method is discussed briefly at > > http://www.haskell.org/ghc/docs/latest/building/sec-booting-from-c.html > > but basically involves using pre-built, non-gcc-specific C files that > don't need mangling to build the first stage GHC compiler. Well, I may be wrong, but I think booting .hc files doesn't avoid mangling step ... .hs ->| hsc |-> .hc -> |cc| -> .s -> |mangling| -> .s' -> |assembler| -> .o -> | linker | -> a.out am I right ? I tried booting from .hc files in linux, sun, and now irix... Look at the table: platform sparc-sunos sparc-sunos i386-linux i386-linuxmips-sgi-irix mips-sgi-irix gcc-version 2.7.2.3 2.95.1 2.7.2.3 2.95.1 2.95.1 2.7.2.3 ghc-3.02-booting-hcOK NOK OK NOK NOK ¿OK? We should distinguish conceptually the next "model": - compiler properly said (hsc) : .hs -> .hc ( writen in Haskell (.hs) !! , so I need to mangle !) - the run-time suport (-l<something>.a , It's almost written in C, something in Haskell .) - the mangler (ghc-asm.prl) .s -> .s' (mangles prelude functions, destroying C -stack model ) - the linker ( -lruntimea, .o -> a.out) - the driver (ghc.prl) . The master overall guide process... The key point I must concentrate is the gcc-mangler interface...That would explain the previous table. Booting .hc doesn't avoid mangling...as I understand the process.( I may be wrong ) The older mangler (ghc-3.02) seems to be dessigned closely to the gcc 2.7.2.3 output... ( The ghc-4.08 runs on gcc-2.95.1 ) That's why I'm trying to find which one was used to build and run ghc-2.10-mips-sgi-irix6.tar.gz . Any other e-mail or reference to consult MIPS-port would be acknowledged... Sorry if my previous mail was large and a bit dark... > From > there, you have a Haskell compiler that can be used to compile the > real GHC natively, and you can work on the mangler etc as necessary. > No doubt one of the GHC Team will give more details. > > In general, the GHC Team is very happy to help with this kind of > thing, because they want GHC to be available on as many platforms as > possible. >

1 0

RE: SGI-Port // Mnagler-Gcc Interface...
by Simon Marlow 27 Feb '02

27 Feb '02

Hi there, > I'm trying to run GHC in a mips-SGI-irix platform, more > accurately Irix > 6. > > The last binary version avalaible > (ftp://ftp.dcs.glasgow.ac.uk/pub/haskell/glasgow/) is for ghc-2.10 > (ghc-2.10-mips-sgi-irix6.tar.gz) . > > > In order to reach the actual ghc-5-XX step by step, I will start by > porting ghc-3.02, ghc-4.08.... This is one way, but as you noticed you need to be careful about gcc versions. There are 4 porting steps involved: 2.10 (should just work given the right gcc version), 3.02, 4.08, and finally 5.02. Each step will require a particular gcc and perhaps changes to the mangler. This is a long and tortuous route to getting GHC working. There is a better way, as suggested by Keith, namely to bootstrap from .hc files. The best version to start from is 4.08(.2) (later versions have problems with .hc bootstrapping). One can bootstrap the compiler using "unregisterised" .hc files, which avoids the mangler. The process has been discussed on one of the lists before, but I just did a search and couldn't find it - maybe you'll have better luck. Anyhow there are three stages: first you generate the unregisterised .hc files using a two-stage bootstrap on a machine with a working 4.08 GHC (eg. a Linux box). Then you compile these on the target machine to generate a working unregisterised compiler. Finally you can use this compiler to experiment with getting registerised builds working - i.e. modifying the mangler. Cheers, Simon

1 0