1. 23 Dec, 2011 5 commits
  2. 22 Dec, 2011 4 commits
  3. 21 Dec, 2011 1 commit
  4. 20 Dec, 2011 8 commits
  5. 19 Dec, 2011 10 commits
    • Ross Paterson's avatar
      fix #5022: polymorphic definitions inside arrow rec · 4c8e0307
      Ross Paterson authored
      This is quite tricky, with examples like this:
      import Control.Arrow
      pRepeat :: a -> [a]
      pRepeat =
          proc x -> do
              s <- returnA -< f_rec x:s       -- f_rec is monomorphic here
              let f_later y = y               -- f_later is polymorphic here
              _ <- returnA -< (f_later True, f_later 'a')
              let f_rec y = y                 -- f_rec is polymorphic here
            returnA -< f_later s              -- f_later is monomorphic here
      Fixed the typechecking of arrow RecStmt to track changes to the monad
      version.  It was simplest to add a field recS_later_rets corresponding
      to recS_rec_rets.  It's only used for the arrow version, and always
      empty for the monad version.  But I think it would be cleaner to put
      the rec_ids and later_ids in a single list with supplementary info
      saying how they're used.
      Also fixed several glitches in the desugaring of arrow RecStmt.  The fact
      that the monomorphic variables shadow their polymorphic counterparts is a
      major pain.  Also a bit of general cleanup of DsArrows while I was there.
    • Ian Lynagh's avatar
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Tidy up pretty-printing for variables · c492e50b
      Simon Peyton Jones authored
      We already have a class OutputableBndr; this patch adds
      methods pprInfixOcc and pprPrefixOcc, so that we can get
      rid of the hideous hack (the old) Outputable.pprHsVar.
      The hack was exposed by Trac #5657, which is thereby fixed.
    • Ian Lynagh's avatar
    • Ian Lynagh's avatar
      Add a class HasDynFlags(getDynFlags) · 06c6d970
      Ian Lynagh authored
      We no longer have many separate, clashing getDynFlags functions
      I've given each GhcMonad its own HasDynFlags instance, rather than
      using UndecidableInstances to make a GhcMonad m => HasDynFlags m
    • Ian Lynagh's avatar
      Remove an old hack for bad FilePath behaviour · 0c047a83
      Ian Lynagh authored
      We now require GHC >= 7.0, which has the behaviour we want.
    • Ian Lynagh's avatar
      Fix typo · c1a30d7f
      Ian Lynagh authored
    • dmp's avatar
      Hide STG register declarations for LLVM C compilers · f542da48
      dmp authored and Simon Marlow's avatar Simon Marlow committed
      This commit swaps the import order of Rts.h and Stg.h in
      StgCRun.c for non-SPARC architectures. Swapping the import
      order prevents the declaration of the global registers thus
      allowing the GHC runtime to be compiled by LLVM-based C
      LLVM-base C compilers cannot use the global register
      declarations (for R1, R2, etc.) because they use
      GCC-specific extensions. The declarations are not needed in
      StgCRun.c except for the SPARC architecture. The other
      architectures use hand-written assembly that accesses the
      appropriate register directly.
    • Simon Marlow's avatar
  6. 18 Dec, 2011 2 commits
  7. 16 Dec, 2011 2 commits
  8. 15 Dec, 2011 5 commits
    • Ian Lynagh's avatar
      Remove some dead code · 40ef62f6
      Ian Lynagh authored
    • dimitris's avatar
    • Simon Marlow's avatar
      Fix a path, and strip out C++ comments too · 3d7e772f
      Simon Marlow authored
    • Simon Marlow's avatar
      Support for reducing the number of Capabilities with setNumCapabilities · 9bae7915
      Simon Marlow authored
      This patch allows setNumCapabilities to /reduce/ the number of active
      capabilities as well as increase it.  This is particularly tricky to
      do, because a Capability is a large data structure and ties into the
      rest of the system in many ways.  Trying to clean it all up would be
      extremely error prone.
      So instead, the solution is to mark the extra capabilities as
      "disabled".  This has the following consequences:
        - threads on a disabled capability are migrated away by the
          scheduler loop
        - disabled capabilities do not participate in GC
          (see scheduleDoGC())
        - No spark threads are created on this capability
          (see scheduleActivateSpark())
        - We do not attempt to migrate threads *to* a disabled
          capability (see schedulePushWork()).
      So a disabled capability should do no work, and does not participate
      in GC, although it remains alive in other respects.  For example, a
      blocked thread might wake up on a disabled capability, and it will get
      quickly migrated to a live capability.  A disabled capability can
      still initiate GC if necessary.  Indeed, it turns out to be hard to
      migrate bound threads, so we wait until the next GC to do this (see
      comments for details).
    • dimitris's avatar
  9. 14 Dec, 2011 3 commits