1. 10 Jul, 2008 9 commits
  2. 09 Jul, 2008 9 commits
    • Simon Marlow's avatar
      366614a9
    • Simon Marlow's avatar
      fb8c1b80
    • Ian Lynagh's avatar
      ObjectIO is no longer an extralib · 80d2e6f7
      Ian Lynagh authored
      80d2e6f7
    • Ian Lynagh's avatar
      Remove all references to -mno-cygwin · ccc9a4a5
      Ian Lynagh authored
      We shouldn't need it, as we don't call cygwin's gcc, and it was causing
      problems with the nightly builders passing it to GHC.
      ccc9a4a5
    • Simon Marlow's avatar
      #1205: ':load foo.hs' in GHCi always compiles to bytecode · 3897d02a
      Simon Marlow authored
      So now
      
        :load foo.hs       loads bytecode for foo.hs, even if foo.o exists
        :load foo          is just shorthand for :load foo.hs
        :load M            loads a module M, as object code if possible
                           (no change here)
      
        :set -fobject-code
        :load foo.hs       loads foo.hs as object code; an existing foo.o
                           can be used.
        
      This turned out to be very straightforward: when building the
      ModSummary for a file (summariseFile) we just ignore the object file
      unless -fobject-code is on.
      3897d02a
    • Simon Marlow's avatar
      add -fwarn-dodgy-foreign-imports (see #1357) · 3b6382e4
      Simon Marlow authored
      From the entry in the User's guide:
      
      -fwarn-dodgy-foreign-imports causes a warning to be emitted for
      foreign imports of the following form:
      
      foreign import "f" f :: FunPtr t
      
      on the grounds that it probably should be
      
      foreign import "&f" f :: FunPtr t
      
      The first form declares that `f` is a (pure) C function that takes no
      arguments and returns a pointer to a C function with type `t`, whereas
      the second form declares that `f` itself is a C function with type
      `t`.  The first declaration is usually a mistake, and one that is hard
      to debug because it results in a crash, hence this warning.
      3b6382e4
    • Simon Marlow's avatar
      Treat the Unicode "Letter, Other" class as lowercase letters (#1103) · 0c266d7a
      Simon Marlow authored
      This is an arbitrary choice, but it's strictly more useful than the
      current situation, where these characters cannot be used in
      identifiers at all.
      
      In Haskell' we may revisit this decision (it's on my list of things to
      discuss), but for now this is an improvement for those using caseless
      languages.
      0c266d7a
    • Simon Marlow's avatar
      FIX part of #2301, and #1619 · addff19a
      Simon Marlow authored
      2301: Control-C now causes the new exception (AsyncException
      UserInterrupt) to be raised in the main thread.  The signal handler
      is set up by GHC.TopHandler.runMainIO, and can be overriden in the
      usual way by installing a new signal handler.  The advantage is that
      now all programs will get a chance to clean up on ^C.
      
      When UserInterrupt is caught by the topmost handler, we now exit the
      program via kill(getpid(),SIGINT), which tells the parent process that
      we exited as a result of ^C, so the parent can take appropriate action
      (it might want to exit too, for example).
      
      One subtlety is that we have to use a weak reference to the ThreadId
      for the main thread, so that the signal handler doesn't prevent the
      main thread from being subject to deadlock detection.
      
      1619: we now ignore SIGPIPE by default.  Although POSIX says that a
      SIGPIPE should terminate the process by default, I wonder if this
      decision was made because many C applications failed to check the exit
      code from write().  In Haskell a failed write due to a closed pipe
      will generate an exception anyway, so the main difference is that we
      now get a useful error message instead of silent program termination.
      See #1619 for more discussion.
      addff19a
    • Simon Marlow's avatar
      Fix some random register clobbering in takeMVar/putMVar · 5f923aab
      Simon Marlow authored
      This showed up as a crash in conc032 for me.
      5f923aab
  3. 08 Jul, 2008 7 commits
  4. 07 Jul, 2008 6 commits
  5. 05 Jul, 2008 9 commits