RE: MacOS X GHC Status
> Some programs work, including green-card and some HOpenGL programs. > > GHC, compiled with my registerized version, crashes. > At some point, there is pointer on the Stg Stack that points > into data space. > However, it doesn't point to a closure. In points to a place just > after the last data symbol in of one GHC module, and before the next > (there's quite some stuff between those two modules, and I have no > idea what the linker puts there). > The word at that position is definitely not a valid info pointer, it > points about 300 megabytes above the heap (into unmapped space). > MacOS X doesn't yet support watchpoints, so I still have no idea > "who" put this strange pointer onto the stack. Under what conditions > are pointers into data space > put on the stack? Any ideas how I could go about debugging this? How > can I possibly ever find out what code is putting this nonsense value > on the stack? These things are particularly tedious to debug (or fun and rewarding, depending on your particular inclinations :-). The first thing to do is compile the RTS with debugging support: there are two lines to copy from config.mk into your build.mk, namely the settings for GhcRtsHcOpts and GhcRtsCcOpts. When you have this, you can turn on heap sanity checking with -D128, which occasionally finds bugs closer to the point at which they occur. In particular if there's a bug in GC it'll probably show up right after the GC in which it occurs, rather than later on during execution. The only pointers into data space that should be on the stack are pointers to static closures. The other things on the stack are pointers to text space (info tables), and pointers into heap space (dynamic closures). > For now, I'll try to find some smaller programs that crash, too. Yes, that's a good idea. I usually make sure the whole nofib suite goes through before attempting to bootstrap a compiler. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MacOS X GHC Status
Some programs work, including green-card and some HOpenGL programs. GHC, compiled with my registerized version, crashes. At some point, there is pointer on the Stg Stack that points into data space. However, it doesn't point to a closure. In points to a place just after the last data symbol in of one GHC module, and before the next (there's quite some stuff between those two modules, and I have no idea what the linker puts there). The word at that position is definitely not a valid info pointer, it points about 300 megabytes above the heap (into unmapped space). MacOS X doesn't yet support watchpoints, so I still have no idea "who" put this strange pointer onto the stack. Under what conditions are pointers into data space put on the stack? Any ideas how I could go about debugging this? How can I possibly ever find out what code is putting this nonsense value on the stack? For now, I'll try to find some smaller programs that crash, too. Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC status
> I read a nice paper recently "The cathedral and the bazaar" by Eric Raymond, > reflecting on his experience Linux, and in particular of developing > "fetchmail". You can find it at > http://locke.ccil.org/~esr/writings/cathedral.html > > It's really worth reading. One particular thing he suggests is making very > frequent releases, even if they are buggy (like daily when in intense > development mode). I've been brought up to think that releasing buggy > software is likely to discourage one's users, but perhaps not if the > non-buggy versions (ha!) are prominently so flagged, so that "users" can > stick to them, while "developers" can pull in the latest one. Comments? > (Read the Raymond paper first.) Very nice paper, I greatly enjoyed reading it. I think that the Linux kind of frequent releases may actually be worth a try. For the libraries it is most certainly worth it. For the compiler proper, it probably depends heavily on how many people actually install the sources or even build from them. My impression from the mailing lists is that a substantial number of users do this. Probably a version numbering scheme like that of Linux is necessary to distinguish stable from experimental versions (Linux uses X.Y.Z where Y is even for stable and odd for experimental versions). Linux ftp sites usually keep the even and odd kernel versions in two separate subdirectories to avoid confusion. Manuel
GHC status
Dear GHC users and co-implementors We are about to return from sabbatical in Oregon back to Glasgow, so now seems a good time to let you know the current state of GHC affairs, and something about our future plans. Simon and Sigbjorn Who's doing what Things have been a bit slow this year, because I have been between grants, so there have been no research assistants working on GHC. Sigbjorn has heroically done wonders, but he's really working on his thesis, so I only let him out to play with GHC one day a week these days. Because I've been on sabbatical I have personally had more time to spend on GHC, but I usually cause untold chaos when let loose to play, so you may not have noticed a great improvement. GHC *is* much more beautiful inside, I promise. It's some 10k lines shorter than GHC 0.29 in spite of growing to accommodate Haskell 1.4.
