Porting to NetBSD Alpha (alpha-unknown-netbsd)
I am working on porting ghc-6.2.2 to NetBSD Alpha according to the porting instructions (10.2. Porting GHC to a new architecture) in the Building Guide. The target system is NetBSD 1.6.2 (STABLE) alpha, and the host system is a Red Hat 9.0 i386 system with the ghc-6.2.2 base and profiling RPMs installed. All example diff files, hc tarball, etc. (see ...) are at http://sorensen.freeshell.org/ghc/ for now. Target System I added alpha-unknown-netbsd to T/configure.ac (see configure.ac.diff) and ran autoreconf. The instructions 'make config.h' didn't work with NetBSD's make; gmake was required. I then copied the config.h (see config.h) to the host system. Host System While running make in H/libraries, I ran into the "cc1: Invalid option `ieee'" discussed on the mailing list: http://www.haskell.org//pipermail/glasgow-haskell-users/2003-September/005650.html I used Ian's suggested mk/boilerplate.mk fix: http://www.haskell.org//pipermail/glasgow-haskell-users/2003-September/005652.html This fixed most of the errors, but 'ar' still ran a few times, causing an error. Running 'make AR=/bin/true LD=/bin/true' fixed these (I was unable to track down where these problematic make lines were). I then build the hc file tarball (see ghc-6.2.2-alpha-unknown-netbsd-hc.tar.gz). This tarball contains 501 files, including 450 .hc files. Target System 2 I unpacked the tarball on the target system, and ran the hc-build script. The first problem I ran into was the readline headers not being found. Setting 'ReadlineIncludePath=/usr/pkg/include' in the mk/config.mk.in (see config.mk.in.diff) fixed this error. The second problem I ran into was with the ieee_set_fp_control() function in ghc/rts/Signals.c. This function isn't available in NetBSD alpha (or FreeBSD alpha I believe, not sure about OSF), only Linux alpha. I simply commented out the reference to the function (see Signals.c.diff), but the file should be modified to check the OS. The hc-build script then sucessfully went through the first "building compiler" stage. After that, in the "building libraries" stage, when it reruns configure, it stalls when detecting the ghc version. The ghc-inplace compiler freezes when run. That is where I am at now. Does anyone have any clue why the inplace compiler freezes, even when run with --version, and must be killed? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scoped type variables
Please! I've lost count of the number of times when I've written code as f :: a -> b f (x :: a) = ... wishing that I didn't have to locally bind the 'a'. I'm not sure I understand the objection raised by Jon; the 'implicit declaration' of type variables in type signatures has never bothered me, and in fact seems quite similar to how names for values don't have to be declared beforehand but are brought into scope by the binding (which I also have no problem with). Abe On Fri, 17 Dec 2004 19:37:00 +, Keean Schupke <[EMAIL PROTECTED]> wrote: > what about having -fno-lexically-scoped-types for old code? > > Keean. > > Simon Peyton-Jones wrote: > > >OK, OK, I yield! > > > >This message is about lexically scoped type variables. I've gradually > >become convinced that if you write > > > > f :: [a] -> [a] > > f x = > > > >then the type variable 'a' should be in scope in . At present in > >GHC you have to write > > f (x :: [a]) = > >to bring 'a' into scope. > > > >I've fought against this because it seems funny for a 'forall' in a type > >signature to bring a type variable into scope in perhaps-distant > >function body, but it's just so convenient and "natural". Furthermore, > >as Martin Sulzmann points out, you might have type variables that are > >mentioned only in the context of the type: > > g :: Foo a b => [a] -> [a] > > g = ... > >GHC provides no way to bring 'b' into scope at the moment, and that > >seems bad design. > > > > > >If I do this, which I'm inclined to, it could break some programs, > >because (with -fglasgow-exts) all type signatures will bring scoped type > >variables into scope in their function body. Here's an example that > >will break > > > > f :: [a] -> [a] > > f x = my_id x > > where > > my_id :: a -> a > > my_id y = y > > > >The type signature for my_id will become monomorphic, since 'a' is now > >in scope, so the application (my_id x) will fail saying > > can't unify 'a' with '[a]'. > >In some ways that makes sense. If you used 'b' instead in the defn of > >my_id, it'd be fine, because my_id would get the type (forall b. b->b). > >Fixing such breakages is easy. > > > > > >So there it is. Any one have strong opinions? (This is in addition to > >the existing mechanism for bringing scoped type variables into scope via > >pattern type signatures, of course.) > > > >Simon > >___ > >Glasgow-haskell-users mailing list > >[EMAIL PROTECTED] > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scoped type variables
what about having -fno-lexically-scoped-types for old code? Keean. Simon Peyton-Jones wrote: OK, OK, I yield! This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] -> [a] f x = then the type variable 'a' should be in scope in . At present in GHC you have to write f (x :: [a]) = to bring 'a' into scope. I've fought against this because it seems funny for a 'forall' in a type signature to bring a type variable into scope in perhaps-distant function body, but it's just so convenient and "natural". Furthermore, as Martin Sulzmann points out, you might have type variables that are mentioned only in the context of the type: g :: Foo a b => [a] -> [a] g = ... GHC provides no way to bring 'b' into scope at the moment, and that seems bad design. If I do this, which I'm inclined to, it could break some programs, because (with -fglasgow-exts) all type signatures will bring scoped type variables into scope in their function body. Here's an example that will break f :: [a] -> [a] f x = my_id x where my_id :: a -> a my_id y = y The type signature for my_id will become monomorphic, since 'a' is now in scope, so the application (my_id x) will fail saying can't unify 'a' with '[a]'. In some ways that makes sense. If you used 'b' instead in the defn of my_id, it'd be fine, because my_id would get the type (forall b. b->b). Fixing such breakages is easy. So there it is. Any one have strong opinions? (This is in addition to the existing mechanism for bringing scoped type variables into scope via pattern type signatures, of course.) Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scoped type variables
On 2004-12-17 at 17:51GMT "Simon Peyton-Jones" wrote: > This message is about lexically scoped type variables. I've been trying to work out what I think about this since you sent out the first message in this thread. I'm not sure that I've come to a useful conclusion, so I'll summarise my thoughts and see if that makes anything pop out of someone else's head. First, I've never liked the fact that type variables in signatures aren't declared anywhere -- this was part of the motivation that drove me to use a non-Hindley-Milner type system in Ponder. There, you could put a quantifier on an expression, so instead of > f :: [a] -> [a] > f x = you could write (mangled to make it look more like Haskell) stuff like f = forall a.\(x::[a]) -> ::[a] and the scope of a was completely clear. Of course, this doesn't work with the way variables are declared in Haskell. Would it help to stick the quantifier at the beginning of the type declaration? > forall a b . g :: Foo a b => [a] -> [a] > g = ... That reads OK, and one can imagine that whenever you see a "g = ..." bit, you implicitly get the type variables that come at the front of the type declaration in scope as well. Doing this would mean that you keep the old behaviour for cases where there is no quantifier at the beginning of the type declaration, so things wouldn't break. > So there it is. Any one have strong opinions? (This is > in addition to the existing mechanism for bringing scoped > type variables into scope via pattern type signatures, of > course.) If I have a strong opinion about anything it's that the only thing that should bring type variables into scope is a(n implied) quantifier. Free variables are nasty. I don't hold out much hope of convincing anyone of this last, though. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Scoped type variables
OK, OK, I yield! This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] -> [a] f x = then the type variable 'a' should be in scope in . At present in GHC you have to write f (x :: [a]) = to bring 'a' into scope. I've fought against this because it seems funny for a 'forall' in a type signature to bring a type variable into scope in perhaps-distant function body, but it's just so convenient and "natural". Furthermore, as Martin Sulzmann points out, you might have type variables that are mentioned only in the context of the type: g :: Foo a b => [a] -> [a] g = ... GHC provides no way to bring 'b' into scope at the moment, and that seems bad design. If I do this, which I'm inclined to, it could break some programs, because (with -fglasgow-exts) all type signatures will bring scoped type variables into scope in their function body. Here's an example that will break f :: [a] -> [a] f x = my_id x where my_id :: a -> a my_id y = y The type signature for my_id will become monomorphic, since 'a' is now in scope, so the application (my_id x) will fail saying can't unify 'a' with '[a]'. In some ways that makes sense. If you used 'b' instead in the defn of my_id, it'd be fine, because my_id would get the type (forall b. b->b). Fixing such breakages is easy. So there it is. Any one have strong opinions? (This is in addition to the existing mechanism for bringing scoped type variables into scope via pattern type signatures, of course.) Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: internal error: weird activation record found on stack: 9
On 16 December 2004 16:12, Peter Simons wrote: > I'm getting this error in my software every now and then: > > postmaster: internal error: scavenge_stack: weird activation record > found on stack: 9 Please report this as a bug to > [EMAIL PROTECTED], or > http://www.sourceforge.net/projects/ghc/ > > The process runs just fine for several days, and then it > crashes with this message out of the sudden. There is no > apparent cause. I'm using a fairly recent CVS ghc to compile > the program on Linux/x86. > > Any idea what I can do to help tracking this bug down? Please compile the program with -debug, then open it with gdb. Set a breakpoint on barf() and run the program: gdb> break barf gdb> run and wait for it to hit the breakpoint. Then do gdb> signal SIGABRT to get a core dump. Send the source, binary, and core dump to us. With any luck, we'll be able to track it down without running the program. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
