- Glasgow-haskell-users

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

Re: SGI-Port // Mnagler-Gcc Interface...
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 OK ¿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. >

2 1

RE: Straightforward conversion from Int <-> Word
by Simon Marlow 27 Feb '02

27 Feb '02

> Simon Marlow notes: > > But fromIntegral *does* do the right thing, doesn't it? > > > > > Numeric.showHex (fromIntegral (-1 :: Int32) :: Word32) "" > > "0xffffffff" > > Interesting. The fact that this fooled Julian as well as me suggests > the behavior needs to be better documented. Interestingly, > hugs yields > an error. I'm going to follow up in more detail to haskell, as this > is really about the behavior of "fromInteger", and has nothing to do > with Word32 or Int32 per se at all. There's this paragraph which talks about the behaviour of fromIntegral in GHC: http://www.haskell.org/ghc/docs/latest/set/vs-haskell-defn.html#HASKELL98-U… but it suggests that this only happens for Int. I'll expand it to cover the sized integral types. Cheers, Simon

1 0

RE: problem compiling GUM
by Simon Peyton-Jones 27 Feb '02

27 Feb '02

There is a GPH mailing list in fact. http://www.cee.hw.ac.uk/~dsg/gph/ It's not listed on the "comprehensive" list of mailing lists at haskell.org, which is surely an oversight. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 26 February 2002 19:44 | To: GHC Users Mailing List | Subject: problem compiling GUM | | | Hi all, | | I'm not sure if this is the appropriate place to ask about | this, but there's no GPH mailing list. I recently downloaded | the source for GUM-4.06-291100 and am having difficulty | getting it to compile. The complaint it gives is: | | utils/Argv.lhs: can't locate import `Addr' | <<ghc: 1972928 bytes, 2 GCs, 112168/112168 avg/max bytes | residency (1 samples),\ 5M in use, 0.02 INIT (0.02 elapsed), | 0.04 MUT (0.23 elapsed), 0.07 GC (0.11 el\ | apsed) :ghc>> | gmake[2]: *** [depend] Error 1 | gmake[1]: *** [boot] Error 1 | gmake: *** [boot] Error 1 | | But I don't really know anything about what's going wrong :). | I'm hoping someone can help me out. I've attached full | transcripts of the build process (gzipped so people don't | complain about huge attachments). Please please help me out | here :). I already have ghc5.02.1 installed, so on one of | the builds i specified --with-hc to use this; on the other i | didn't. neither worked. | | Thanks! | | - 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

SGI-Port // Mnagler-Gcc Interface...
by Rafael Martínez Torres 27 Feb '02

27 Feb '02

Hello: 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.... 1) Is it really ghc-2.10 the last version avalaible ? If any newer, where to get it from (Any other discussing group) ? I tried unsuccesfully to run the ghc-2.10 on a Irix6 . The mangler-phase seems to fail and aborts the process. I had been told that for newer ghc-versions I should rearrange the mangler to make GHC run, but I hoped the 2.10 binary version to run succesfull. >From a Unix-programmer external point of view ,(exclude STG or run-time dessigner scope) my empirical experience by running several versions (ghc-3.02,ghc-4.08 ) among different platforms ( sparc-sunos, i386-linux ) suggest me the next: ( I may be wrong or confused. My STG computation model is not very mature (Four months ) Enlightment would be acknowledged ) - Obtaining a succesfull image doesn't depend so much from the run time system implementation varying from ghc-[2345]-XX as from the gcc-mangler interface.(At least for "Hello world" programs, differ subtility from correctness in larger projects, where the run-time system takes more relevance )( Read next) - The mangler is closely bound to the gcc output. As a matter of versioning problem, when gcc goes upwards the mangler may not to operate correctly. Mangler reduces well for gcc-2.7.2.3 and fails for gcc-2.95.1 ( Test source: ghc-3.02 on both i386-linux and sparc-sun. both linked, but a faulty image was generetaed. The O.S sends the runtime a signal and aborted the program). - As a consequence of the previous point, the original idea for using C as a "transparent macro-assembler" among different platforms is now discussed again. In practical terms, not only the C compiler used (I have tried only GNU CC) but the compiler version may interfere the entire ghc-compiling process. This should be of special interest for making binary distributions (rpm, pkg...) The first time I ran the ghc-3.02 (installed from chack's rpm's ) on a i386-linux it failed. Reason: my Linux distribution installed the ghc-2.95.1. Reinstalling downwards the gcc to 2.7.2.3 solved the problem. Hence, 2) Should the binary versions be distributted with the specific gcc version attached ,like other compiler packets do (i.e Ada ) ? This would help to portability among different platforms, though C-compiler transparency would be compromised. Only Gcc should be used and specific version... Unless you want a normal user to hack the mangler piece... 3) Specific question: As a porter, I have two choices in order to make GHC run in a mips-SGI-irix platform... - To hack the mangler: discarded since I have no deep knowledge about how the mangler operates. :-| - To retrieve (from this mailing list) which a configuration was last used to make ghc-2.10 run on a mips-SGI-irix. Instead of rearrenge the mangler to match the environment, I will rearrange the environment to match the mangler. Which gcc version was the ghc-2.10 mangler designed for ? Or The highest gcc version the binary (ghc-2.10-mips-sgi-irix6.tar.gz) ran sucessfull last time : The gcc-2.95 seems to fail... 4)Once I have got it : should I install the GNU assembler for MIPS or use the propietary one ? This is because I have read the gcc modifies its output according to the asssembler to be used in the next step (--with-gnu-as in the configure ). Was this considered during the mangler dessign ? 5) I think once you have the final .o files, choice between GNU or propietary linker shouldn't matter grosso modo. True ? Cheers.

2 1