1. 16 Nov, 2007 4 commits
  2. 19 Nov, 2007 2 commits
  3. 16 Nov, 2007 5 commits
    • Simon Marlow's avatar
      Attempt at fixing #1873, #1360 · 037aa382
      Simon Marlow authored
      I think I figured out a reasonable way to manage the GHCi context,
      comments welcome.
      Rule 1: external package modules in the context are persistent.  That
      is, when you say 'import Data.Maybe' it survives over :load, :add,
      :reload and :cd.
      Rule 2: :load and :add remove all home-package modules from the
      context and add the rightmost target, as a *-module if possible.  This
      is as before, and makes sense for :load because we're starting a new
      program; the old home-package modules don't make sense any more.  For
      :add, it usually does what you want, because the new target will
      become the context.
      Rule 3: any modules from the context that fail to load during a
      :reload are remembered, and re-added to the context at the next
      successful :reload.
      Claus' suggestion about adding the "remembered" modules to the prompt
      prefixed with a ! is implemented but commented out.  I couldn't
      decide whether it was useful or confusing.
      One difference that people might notice is that after a :reload where
      there were errors, GHCi would previously dump you in the most recent
      module that it loaded.  Now it dumps you in whatever subset of the
      current context still makes sense, and in the common case that will
      probably be {Prelude}.
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
    • Simon Marlow's avatar
      use "ghc-pkg latest --global" instead of "ghc-pkg list --simple-output" · a9e89211
      Simon Marlow authored
      The former now does the right thing: it uses the global database only,
      and picks the most recent package with the given name.
    • Simon Marlow's avatar
  4. 15 Nov, 2007 2 commits
    • Simon Marlow's avatar
      FIX #1828: installing to a patch with spaces in · 5af10d51
      Simon Marlow authored
      We have to pass the path to gcc when calling windres, which itself
      might have spaces in.  Furthermore, we have to pass the path to gcc's
      tools to gcc.  This means getting the quoting right, and after much
      experimentation and reading of the windres sources I found something
      that works: passing --use-temp-files to windres makes it use its own
      implementation of quoting instead of popen(), and this does what we
      want.  Sigh.
    • Simon Marlow's avatar
      Avoid the use of unversioned package dependencies · f4629357
      Simon Marlow authored
      Fortunately "ghc-pkg list $pkg --simple-output" is a good way to add
      the version number.
  5. 14 Nov, 2007 5 commits
  6. 15 Nov, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make SpecConstr work again · a496c6a2
      simonpj@microsoft.com authored
      In a typo I'd written env instead of env', and as a result RULES are
      practically guaranteed not to work in a recursive group.  This pretty
      much kills SpecConstr in its tracks!
      Well done Kenny Lu for spotting this.  The fix is easy.
      Merge into 6.8 please.
  7. 14 Nov, 2007 6 commits
  8. 13 Nov, 2007 2 commits
  9. 13 Oct, 2007 1 commit
  10. 06 Oct, 2007 1 commit
  11. 04 Oct, 2007 1 commit
  12. 28 Sep, 2007 1 commit
  13. 13 Nov, 2007 1 commit
  14. 12 Nov, 2007 6 commits
  15. 11 Nov, 2007 1 commit
  16. 08 Nov, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #1654: propagate name changes into CoreRules · 4c38417c
      simonpj@microsoft.com authored
      This patch is on the HEAD.  It fixes a nasty and long-standing bug
      whereby we weren't substituting the ru_fn field of a CoreRule in 
      CoreSubst.substSpec, which ultimately led to a puzzling "nameModule"
      error trying to put the rules in the interface file.