- Glasgow-haskell-users

RE: sparc/linux, again
by Simon Marlow 30 Apr '02

30 Apr '02

> Dear all, I can't get the hc-boot process to work for > sparc64-linux-debian. > I compiled from the ghc-4.08.2 hc-files, but when I run the > executable, I get > > Starting program: /home/joe/ghc-4.08.2/ghc/compiler/hsc > (no debugging symbols found)...(no debugging symbols found)... > (no debugging symbols found)... > Program received signal SIGBUS, Bus error. > 0x7ccdd8 in forceIO_info () > (gdb) where > #0 0x7ccdd8 in forceIO_info () > #1 0x7ccec0 in stg_init_ret () > #2 0x7c45b4 in schedule () > #3 0x7c4bd8 in waitThread () > #4 0x7c30a4 in rts_evalIO () > #5 0x7c2ab4 in main () > #6 0x700df450 in __libc_start_main () from /lib/libc.so.6 Which .hc files did you use? To port to a new architecture you really need to start from an unregisterised build. As I recall, 4.08.2 also has some 64-bit incompatibilities, which might cause problems porting to sparc64. I don't want to put you off, but this *really* isn't for the faint-hearted ;-) You might want to talk to Ken Shan <ken(a)digitas.harvard.edu> who did the Alpha port recently, and there are some useful messages in the mailing list archives (use Google's "search site" facility to search haskell.org for "GHC Alpha port"). Cheers, Simon

1 0

RE: powerpc-linux port
by Simon Marlow 30 Apr '02

30 Apr '02

> On Mon, Apr 29, 2002 at 05:50:49PM +0100, Simon Marlow wrote: > > > No, actually I'd like to have GHC, because many libraries > I want to > > > use depend on it. But good that you point this out, maybe > it would be > > > possible to have NHC compile GHC... Although the FAQ says it > > > would most probably not work. > > > > It most *definitely* would not work ;-) > > > > To bootstrap the unregisterised version, I suggest starting > from version > > 4.08.2. The reason is that bootstrapping more recent > versions from .hc > > files is significantly more difficult (but hopefully should > get easier > > again soon...). > > OK, be it 4.08.2 then. I see there are HC files for x86 and > Sparc, how do > I get (produce) them for PowerPC? You need to start from unregisterised .hc files, which you have to build on a supported platform (eg. Linux/x86). Here's a message that has some details on how to do the bootstrap: http://www.haskell.org/pipermail/glasgow-haskell-users/2000-October/0014 45.html (which coincidentally is a reply to another guy who asked about PPC/Linux...) Cheers, Simon

1 0

resetting in ghci
by Serge D. Mechveliani 30 Apr '02

30 Apr '02

Dear GHC, Does ghci have a command of clearing out of all the currently defined values (like x set by `let x = 1') ? What about un-loading modules? Does the user need to exit and re-run ghci in order to reset the created environment? Such situation is not a tragedy, but still ... ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

sparc/linux, again
by Johannes Waldmann 30 Apr '02

30 Apr '02

Dear all, I can't get the hc-boot process to work for sparc64-linux-debian. I compiled from the ghc-4.08.2 hc-files, but when I run the executable, I get Starting program: /home/joe/ghc-4.08.2/ghc/compiler/hsc (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGBUS, Bus error. 0x7ccdd8 in forceIO_info () (gdb) where #0 0x7ccdd8 in forceIO_info () #1 0x7ccec0 in stg_init_ret () #2 0x7c45b4 in schedule () #3 0x7c4bd8 in waitThread () #4 0x7c30a4 in rts_evalIO () #5 0x7c2ab4 in main () #6 0x700df450 in __libc_start_main () from /lib/libc.so.6 Any hints? -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0

specifying main on command line
by Hal Daume III 29 Apr '02

29 Apr '02

This was in response to a post I made and I would really really like to see something like this in ghc (I don't particularly care if f is IO a or IO (), though). > Ack! This kind of change would be good, but it doesn't go quite far > enough. In my opinion, you should be able to specify --main=M.f, where > M is any module and f is anything of type IO a for some a.

1 0

RE: powerpc-linux port
by Simon Marlow 29 Apr '02

29 Apr '02

> No, actually I'd like to have GHC, because many libraries I want to > use depend on it. But good that you point this out, maybe it would be > possible to have NHC compile GHC... Although the FAQ says it > would most probably not work. It most *definitely* would not work ;-) To bootstrap the unregisterised version, I suggest starting from version 4.08.2. The reason is that bootstrapping more recent versions from .hc files is significantly more difficult (but hopefully should get easier again soon...). Cheers, Simon

2 1

powerpc-linux port
by Sven M. Hallberg 29 Apr '02

29 Apr '02

Hi, what happened to the PPC Linux port? I would do it myself, but I have no clue about - compilers, - the PowerPC architecture, or - how to bootstrap GHC. However, I'm a curious person, so anyone feeling like sharing some knowledge will be greatly appreciated. I see there is already working support for Darwin. What will have to be adjusted to get from powerpc-apple-darwin to powerpc-unknown-linux? I've tried to manage a bootstrap compile but failed already at generating the hc files (on i386-unknown-linux). How To?? Can anyone produce a definitive guide? Best regards, Sven Moritz

4 4

ghc binaries for sparc-debian-linux?
by Johannes Waldmann 27 Apr '02

27 Apr '02

Dear all, we need ghc on an ultra sparc running debian linux. Before we embark on building from hc-files (the correct way to go?), perhaps are there binary packages of ghc somewhere around? Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0

RE: module namespaces with "Prelude"
by Simon Marlow 25 Apr '02

25 Apr '02

> On Thursday, April 25, 2002, at 03:00 , Alastair Reid wrote: > > >> Now, since there's nothing that prevents the directory hierarchies > >> starting at these roots from overlapping, we have a potential for > >> ambiguity when we want to map module names to filenames. > > > > This suggests that we might want to modify the search algorithm to > > find all matches and report and error if two or more candidate files > > are found. If this is a big performance hit, we could make > it a :set > > option. > > But wouldn't that just prohibit the use of module names that > also appear in the standard libraries? At least we need to stop > searching the directory of the importing module to make > something useful of this idea. I agree with Alastair - I think it should be an error if there are two modules with the same name on the search path. If it weren't for (a) the performance hit and (b) the difficulty in portably determining whether two pathnames refer to the same file, I'd have made GHCi do this already. Yes, it would prohibit the use of module names that also appear in the standard libraries. But after all we're moving to hierarchical libraries so there's no need to do that any more! Cheers, Simon

2 1

RE: module namespaces with "Prelude"
by Hal Daume III 25 Apr '02

25 Apr '02

It happens in Hugs, too, but somewhat differently. Here's a test case. Go to /foo and do mkdir Bar. In Bar, create IO.hs and make its contents: module Bar.IO where then also in Bar create Foo.hs module Bar.Foo where import IO Then when in directory Bar load ghci (using 5.02.1) and load Bar.Foo and you'll get: IO.hs: file name does not match module name `IO' Quit ghci, load hugs and load Bar.Foo and you'll get: ERROR "Foo.hs" - Module "IO" not previously loaded (worse things can happen in hugs -- if say Bar.IO imported Bar.Foo and plain Bar.Foo imported plain old IO hugs will complain about cyclic modules) if you are in /foo instead of /foo/Bar when you load ghci and set paths correctly it will work. I don't know that this is exactly a bug in the software as much as it's just somewhat underspecified what to do in these situations (I could be wrong though). IMO if you say in an import "import XXX" and it looks in XXX.(l)hs and the module names is "YYY.XXX" it should keep looking instead of just dying. I don't really know what repurcussions this will have, though. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Mon, 22 Apr 2002, Simon Peyton-Jones wrote: > Hal, > > If your question is GHC-specific, send it to ghc-users not the haskell > list. > > And it would save time if you could be more specific. Say what > compiler > you are using, enclose a test case, etc. Otherwise we're all guessing. > > Simon > > | -----Original Message----- > | From: Hal Daume III [mailto:hdaume@ISI.EDU] > | Sent: 23 April 2002 03:21 > | To: Alastair Reid > | Cc: Haskell Mailing List > | Subject: Re: module namespaces with "Prelude" > | > | > | Ah, so the problem was that even though I had the superdir of > | NLP in my path, I was actually loading the modules in ghci > | from the NLP directory. Still, I find this behavior odd, > | since even if I were in the NLP directory I could not import > | "NLP.Foo" simply as "Foo", I don't see why I should be > | allowed to (try to) import "NLP.Prelude" simply as "Prelude", > | thus messing stuff up... > | > | -- > | Hal Daume III > | > | "Computer science is no more about computers | hdaume(a)isi.edu > | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume > | > | On 23 Apr 2002, Alastair Reid wrote: > | > | > > | > >>>>> "#Hal" == Hal Daume <hdaume(a)ISI.EDU> writes: > | > > | > > I'm developing my package "NLP" for supporting common NLP > | functions > | > > and have a set of functions/datatypes that are common to > | almost all > | > > of my modules and I wanted to separate them off into an > | > > "NLP.Prelude" file, but this seems not to work. One of > | my modules > | > > imports Prelude (the Haskell one) directly so I can hide a few > | > > definitions, but then it looks at NLP/Prelude.lhs and > | complains that > | > > the name of that module "NLP.Prelude" doesn't match "Prelude". > | > > SHould I simply name my module "NLP.NLPPrelude" or > | something (which > | > > is ugly, imo) or what? > | > > | > The only change that hierarchial module namespaces make is that the > | > dots become a legal part of the name and that compilers have a > | > sensible way of mapping them onto filenames such as > | replacing dots by > | > slashes. So, under the new scheme, these names are different and > | > unrelated > | > > | > Prelude NLP.Prelude User.Hal.Daume.NLP.Prelude > | > > | > in the same way that these names were different and > | unrelated in the > | > old scheme. > | > > | > Prelude NLP_Prelude User_Hal_Daume_NLP_Prelude > | > > | > If you are seeing something other than that, the problem is > | with your > | > compiler or the way you are using command line arguments to your > | > compiler (e.g., Hugs' import chasing mechanism has some interesting > | > interactions with hierarchial namespaces) and you should > | say which one > | > you're using and how you're using it. > | > > | > -- > | > Alastair Reid > | > > | > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell > | >

4 8