1. 27 Jan, 2005 1 commit
  2. 26 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-26 16:03:40 by simonmar] · 55aa70cd
      simonmar authored
      Common up the ghc_ge_XXX variables into config.mk, and add the
      ability to build ghc/lib and ghc/utils using the stage1 compiler, by
      saying 'make UseStage1=YES'.  This is going to be useful for
      bootstrapping.
      55aa70cd
  3. 20 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-20 14:22:19 by simonmar] · c830ae13
      simonmar authored
      Fill in the haddock-interfaces and haddock-html fields in the
      package.conf files.
      
      To do this I had to make some changes:
      
        - haddock-interfaces requires the value of $(datadir).  We can't
          just plug this in, because $(datadir) might change at install-time
          (eg. a Windows installer can be placed anywhere, as can a Unix
          binary .tar.gz distribution).  The current trick is for the
          compiler to splice in the value of $libdir in package.conf at
          runtime.  So we could extend this mechanism and tell the compiler
          the value of $datadir via a command-line option, but that seems
          ugly.
      
          On Windows, $datadir==$libdir, so we don't need any changes:
          package.conf still uses $libdir, and a Windows installation is
          independent of its absolute location.  Even 'make install' on
          Windows should have this property.
      
          On Unix:
      	- for 'make install' and in-place execution, we just use
                absolute paths in package.conf
      
      	- for a binary dist, we generate a package.conf that refers
      	  to $libdir and $datadir, and splice in the values at
      	  install-time (distrib/Makefile-bin.in).
      
        - Also, I renamed $libdir to $topdir to more closely reflect its
          actual meaning.  This is somewhat malicious in that it will flush
          out all those clients using $libdir when they really shouldn't
          be :-)
      c830ae13
  4. 04 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-04 13:41:53 by simonmar] · f3cdd93b
      simonmar authored
      ghc/mk/config.mk was never being included in ordinary Makefiles.  It
      was only included in the top-level fptools/Makefile for the purposes
      of obtaining binary distribution settings.
      
      This fixes that problem, and now as a side-effect $(GhcHasReadline)
      will start working again.
      f3cdd93b
  5. 04 Dec, 2004 1 commit
  6. 20 Nov, 2004 1 commit
  7. 11 Nov, 2004 1 commit
  8. 30 Sep, 2004 1 commit
  9. 20 Sep, 2004 1 commit
  10. 19 Sep, 2004 1 commit
  11. 11 Sep, 2003 1 commit
  12. 29 Jul, 2003 1 commit
    • panne's avatar
      [project @ 2003-07-29 19:08:40 by panne] · f7064672
      panne authored
      Revert to previous commit, i.e. ProjectVersion is now a plain "6.1"
      again, not "6.1.20030727". It looked like an accidental commit and
      broke my build scripts.
      f7064672
  13. 28 Jul, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-07-28 16:05:30 by simonmar] · 387a411e
      simonmar authored
      Disable update-in-place.  In its current form, it has a serious bug:
      if the thunk being updated happens to have turned into a BLACKHOLE_BQ,
      then the mutable list will be corrupted by the update.
      
      Disabling update-in-place has some performance implications: many
      programs are not affected, but one program in nofib (nucleic2) goes
      about 20% slower.  However, I can get it to go 300% faster by adding a
      few strictness annotations and compiling with -funbox-strict-fields.
      387a411e
  14. 24 Jul, 2003 1 commit
  15. 23 May, 2003 1 commit
  16. 20 May, 2003 1 commit
  17. 19 May, 2003 1 commit
  18. 28 Mar, 2003 1 commit
  19. 24 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-24 14:46:53 by simonmar] · b3f53081
      simonmar authored
      Fix some bugs in compacting GC.
      
      Bug 1: When threading the fields of an AP or PAP, we were grabbing the
      info table of the function without unthreading it first.
      
      Bug 2: eval_thunk_selector() might accidentally find itself in
      to-space when going through indirections in a compacted generation.
      We must check for this case and bale out if necessary.
      
      Bug 3: This is somewhat more nasty.  When we have an AP or PAP that
      points to a BCO, the layout info for the AP/PAP is in the BCO's
      instruction array, which is two objects deep from the AP/PAP itself.
      The trouble is, during compacting GC, we can only safely look one
      object deep from the current object, because pointers from objects any
      deeper might have been already updated to point to their final
      destinations.
      
      The solution is to put the arity and bitmap info for a BCO into the
      BCO object itself.  This means BCOs become variable-length, which is a
      slight annoyance, but it also means that looking up the arity/bitmap
      is quicker.  There is a slight reduction in complexity in the byte
      code generator due to not having to stuff the bitmap at the front of
      the instruction stream.
      b3f53081
  20. 05 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-05 10:22:22 by simonmar] · 9a1114e3
      simonmar authored
      Duh.  hsc2hs should be in $(GhcBinDistShScripts), not
      $(GhcBinDistBins), otherwise it doesn't get the right directories
      tacked on the front at installation time.  Strange that nobody
      complained that hsc2hs wasn't working from a binary dist *shrug*.
      9a1114e3
  21. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  22. 30 Sep, 2002 1 commit
  23. 09 Aug, 2002 1 commit
  24. 08 Jul, 2002 1 commit
  25. 05 Jul, 2002 1 commit
  26. 02 Jul, 2002 1 commit
  27. 01 Apr, 2002 1 commit
  28. 27 Feb, 2002 1 commit
  29. 12 Feb, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-02-12 15:17:13 by simonmar] · 2cc5b907
      simonmar authored
      Switch over to the new hierarchical libraries
      ---------------------------------------------
      
      This commit reorganises our libraries to use the new hierarchical
      module namespace extension.
      
      The basic story is this:
      
         - fptools/libraries contains the new hierarchical libraries.
           Everything in here is "clean", i.e. most deprecated stuff has
           been removed.
      
      	- fptools/libraries/base is the new base package
      	  (replacing "std") and contains roughly what was previously
      	  in std, lang, and concurrent, minus deprecated stuff.
      	  Things that are *not allowed* in libraries/base include:
      		Addr, ForeignObj, ByteArray, MutableByteArray,
      		_casm_, _ccall_, ``'', PrimIO
      
      	  For ByteArrays and MutableByteArrays we use UArray and
      	  STUArray/IOUArray respectively now.
      
      	  Modules previously called PrelFoo are now under
      	  fptools/libraries/GHC.  eg. PrelBase is now GHC.Base.
      
      	- fptools/libraries/haskell98 provides the Haskell 98 std.
      	  libraries (Char, IO, Numeric etc.) as a package.  This
      	  package is enabled by default.
      
      	- fptools/libraries/network is a rearranged version of
      	  the existing net package (the old package net is still
      	  available; see below).
      
      	- Other packages will migrate to fptools/libraries in
      	  due course.
      
           NB. you need to checkout fptools/libraries as well as
           fptools/hslibs now.  The nightly build scripts will need to be
           tweaked.
      
         - fptools/hslibs still contains (almost) the same stuff as before.
           Where libraries have moved into the new hierarchy, the hslibs
           version contains a "stub" that just re-exports the new version.
           The idea is that code will gradually migrate from fptools/hslibs
           into fptools/libraries as it gets cleaned up, and in a version or
           two we can remove the old packages altogether.
      
         - I've taken the opportunity to make some changes to the build
           system, ripping out the old hslibs Makefile stuff from
           mk/target.mk; the new package building Makefile code is in
           mk/package.mk (auto-included from mk/target.mk).
      
           The main improvement is that packages now register themselves at
           make boot time using ghc-pkg, and the monolithic package.conf
           in ghc/driver is gone.
      
           I've updated the standard packages but haven't tested win32,
           graphics, xlib, object-io, or OpenGL yet.  The Makefiles in
           these packages may need some further tweaks, and they'll need
           pkg.conf.in files added.
      
         - Unfortunately all this rearrangement meant I had to bump the
           interface-file version and create a bunch of .hi-boot-6 files :-(
      2cc5b907
  30. 29 Jan, 2002 1 commit
  31. 10 Jan, 2002 1 commit
  32. 10 Sep, 2001 3 commits
  33. 30 Aug, 2001 1 commit
  34. 31 Jul, 2001 1 commit
  35. 16 Jul, 2001 1 commit
  36. 05 Jul, 2001 1 commit
  37. 28 Jun, 2001 2 commits