| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the front panel compile again, submitted by Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>. From his email:
Attached is a patch to port the GHC RTS font panel to Gtk+ 2.x rather
than the obsolete Gtk+ 1.2.
There were basically two changes needed. Change the configure check to
look for the pkg-config utility rather than the old gtk-config. At it's
just checking for Gtk+ 2.0 or later. It may be that the new code
actually needs a slightly later version than that. I'm not quite sure.
The other change was to convert the ghc-fontpanel.glade file to the
glade-2 format using the libglade-convert script and then to re-generate
the C code for constructing the GUI, that is the Vis*.c Vis*.h files in
ghc/rts.
The front panel has been bit-rotting for quite some time so it has not
kept up with changes in the rts structures. So I had to comment out
references to 3 bits that no longer exist. I've left FIXMEs in the code
at the appropriate places so that someone wiser than me can make the
appropriate changes.
So the thing does now build though I have no doubt that it will not run,
or at least will not do the right thing because it has not yet been
updated to the current state of the rts. However hopefully now that it
is at least buildable with a modern Gtk+ version someone else might be
able to fix it up.
This also relates to trac ticket #599:
http://cvs.haskell.org/trac/ghc/ticket/599
|
| |
|
|
|
|
| |
Remove the ForeignObj# type, and all its PrimOps. The new efficient
representation of ForeignPtr doesn't use ForeignObj# underneath, and
there seems no need to keep it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Block allocator performance fix: instead of keeping the free list
ordered, keep it doubly-linked, and introduce a new flag BF_FREE so we
can tell when a block is free. We can still coalesce blocks on the
free list because block descriptors are kept consecutively in memory,
so we can tell based on the BF_FREE flag whether to coalesce with the
next higher/lower blocks when freeing a block.
This (almost) make freeChain O(n) rather than O(n^2), and has been
reported to help a lot when dealing with very large heaps.
|
| |
|
|
|
| |
Removed the annoying "Id" CVS keywords, they're a real PITA when it
comes to merging...
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Cleanup: all (well, most) messages from the RTS now go through the
functions in RtsUtils: barf(), debugBelch() and errorBelch(). The
latter two were previously called belch() and prog_belch()
respectively. See the comments for the right usage of these message
functions.
One reason for doing this is so that we can avoid spurious uses of
stdout/stderr by Haskell apps on platforms where we shouldn't be using
them (eg. non-console apps on Windows).
|
| |
|
|
| |
Merge backend-hacking-branch onto HEAD. Yay!
|
| |
|
|
|
| |
- AP_UPD got renamed to AP in rev. 1.18 of ClosureTypes.h
- #if 0-out section which is a sure segfault in the colouring loop
|
| |
|
|
| |
Add missing MUT_CONS case (reported by Andy Cheadle)
|
| |
|
|
|
| |
* Use new `gen_no' member in `bdescr'
* Track renaming of member `to_space' in `step' structure
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the story about POSIX headers in C compilation.
Until now, all C code in the RTS and library cbits has by default been
compiled with settings for POSIXness enabled, that is:
#define _POSIX_SOURCE 1
#define _POSIX_C_SOURCE 199309L
#define _ISOC9X_SOURCE
If you wanted to negate this, you'd have to define NON_POSIX_SOURCE
before including headers.
This scheme has some bad effects:
* It means that ccall-unfoldings exported via interfaces from a
module compiled with -DNON_POSIX_SOURCE may not compile when
imported into a module which does not -DNON_POSIX_SOURCE.
* It overlaps with the feature tests we do with autoconf.
* It seems to have caused borkage in the Solaris builds for some
considerable period of time.
The New Way is:
* The default changes to not-being-in-Posix mode.
* If you want to force a C file into Posix mode, #include as
the **first** include the new file ghc/includes/PosixSource.h.
Most of the RTS C sources have this include now.
* NON_POSIX_SOURCE is almost totally expunged. Unfortunately
we have to retain some vestiges of it in ghc/compiler so that
modules compiled via C on Solaris using older compilers don't
break.
|
| |
|
|
| |
Sync this with the rest of the RTS and make it compile again.
|
| |
|
|
| |
DEAD_WEAK ==> stg_DEAD_WEAK
|
| |
|
|
| |
Add the GLADE config for the front panel, tweak a few things.
|
|
|
Add a basic "front panel" for GHC-compiled programs.
How to use it:
- re-autoconf & configure to detect GTK+
- add "GhcRtsWithFrontPanel = YES" to mk/build.mk
- rebuild the RTS
- compile up a program, add `gtk-config --libs` to the
link command line
- run with program with +RTS -f,
- sit back & watch the show :-) Programs with lots of
heap-resident data are the most interesting. For extra
kicks, turn up the number of generations & steps like so:
+RTS -f -G5 -T3.
- Bootstrap your compiler, and see in glorious technicolor
just how much of a lumbering beast GHC really is.
This is a work in progress. There's lots more stuff we could display
on the panel: suggestions/comments are of course welcome. The window
layout was designed with GLADE, I'll commit the config file shortly.
I haven't quite figured out how we're going to integrate this with the
release yet (ie. whether we'll distribute two separate RTS's or what).
|
