1. 28 May, 2015 1 commit
    • Austin Seipp's avatar
      base: fix #10298 & #7695 · e28462de
      Austin Seipp authored
      This applies a patch from Reid Barton and Sylvain Henry, which fix a
      disasterous infinite loop when iconv fails to load locale files, as
      specified in #10298.
      The fix is a bit of a hack but should be fine - for the actual reasoning
      behind it, see `Note [Disaster and iconv]` for more info.
      In addition to this fix, we also patch up the IO Encoding utilities to
      recognize several variations of the 'ASCII' encoding (including its
      aliases) directly so that GHC can do conversions without iconv. This
      allows a static binary to sit in an initramfs.
      Authored-by: rwbarton's avatarReid Barton <rwbarton@gmail.com>
      Authored-by: default avatarSylvain Henry <hsyl20@gmail.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      Test Plan: Eyeballed it.
      Reviewers: rwbarton, hvr
      Subscribers: bgamari, thomie
      Differential Revision: https://phabricator.haskell.org/D898
      GHC Trac Issues: #10298, #7695
  2. 07 Nov, 2014 1 commit
  3. 25 Oct, 2014 1 commit
  4. 19 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Refactor module imports in base · b5930f8b
      Herbert Valerio Riedel authored
      This commit removes a couple of
        {-# OPTIONS_GHC -fno-warn-unused-imports #-}
      by cleaning up the imports, as well as ensuring that all modules in the
      GHC.* hierarchy avoid importing the `Prelude` module to clean-up the
      import graph a bit.
  5. 04 Dec, 2013 1 commit
  6. 14 Nov, 2013 1 commit
    • Duncan Coutts's avatar
      Handle ExitFailure (-sig) by killing process with signal · 643f07c6
      Duncan Coutts authored
      On Unix we now use negative exit codes in ExitFailure to indicate that a
      process exited due to a signal. This patch implements the case for when
      a ExitFailure exception propagates out of the top of main (and is
      handled by the topHandler).
      For a negative ExitFailure code, we try to kill the process using that
      signal (the details of that are handled by shutdownHaskellAndSignal from
      the RTS). For an exit code outside the valid ranges, we use 0xff.
  7. 28 Sep, 2013 1 commit
  8. 22 Sep, 2013 1 commit
  9. 14 Feb, 2013 1 commit
  10. 12 Apr, 2012 1 commit
  11. 07 Nov, 2011 1 commit
  12. 18 Jun, 2011 1 commit
  13. 28 Jan, 2011 1 commit
  14. 01 Aug, 2009 1 commit
  15. 11 Jul, 2009 1 commit
  16. 10 Jul, 2009 1 commit
  17. 12 Jun, 2009 1 commit
    • Simon Marlow's avatar
      Rewrite of the IO library, including Unicode support · 7b067f2d
      Simon Marlow authored
      * Unicode support for Handle I/O:
        ** Automatic encoding and decoding using a per-Handle encoding.
        ** The encoding defaults to the locale encoding (only on Unix 
           so far, perhaps Windows later).
        ** Built-in UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE) codecs.
        ** iconv-based codec for other encodings on Unix
      * Modularity: the low-level IO interface is exposed as a type class
        (GHC.IO.IODevice) so you can build your own low-level IO providers and
        make Handles from them.
      * Newline translation: instead of being Windows-specific wired-in
        magic, the translation from \r\n -> \n and back again is available
        on all platforms and is configurable for reading/writing
      Unicode-aware Handles
      This is a significant restructuring of the Handle implementation with
      the primary goal of supporting Unicode character encodings.
      The only change to the existing behaviour is that by default, text IO
      is done in the prevailing locale encoding of the system (except on
      Windows [1]).  
      Handles created by openBinaryFile use the Latin-1 encoding, as do
      Handles placed in binary mode using hSetBinaryMode.
      We provide a way to change the encoding for an existing Handle:
         GHC.IO.Handle.hSetEncoding :: Handle -> TextEncoding -> IO ()
      and various encodings (from GHC.IO.Encoding):
         utf16, utf16le, utf16be,
         utf32, utf32le, utf32be,
      and a way to lookup other encodings:
         GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding
      (it's system-dependent whether the requested encoding will be
      We may want to export these from somewhere more permanent; that's a
      topic for a future library proposal.
      Thanks to suggestions from Duncan Coutts, it's possible to call
      hSetEncoding even on buffered read Handles, and the right thing
      happens.  So we can read from text streams that include multiple
      encodings, such as an HTTP response or email message, without having
      to turn buffering off (though there is a penalty for switching
      encodings on a buffered Handle, as the IO system has to do some
      re-decoding to figure out where it should start reading from again).
      If there is a decoding error, it is reported when an attempt is made
      to read the offending character from the Handle, as you would expect.
      Performance varies.  For "hGetContents >>= putStr" I found the new
      library was faster on my x86_64 machine, but slower on an x86.  On the
      whole I'd expect things to be a bit slower due to the extra
      decoding/encoding, but probabaly not noticeably.  If performance is
      critical for your app, then you should be using bytestring and text
      [1] Note: locale encoding is not currently implemented on Windows due
      to the built-in Win32 APIs for encoding/decoding not being sufficient
      for our purposes.  Ask me for details.  Offers of help gratefully
      Newline Translation
      In the old IO library, text-mode Handles on Windows had automatic
      translation from \r\n -> \n on input, and the opposite on output.  It
      was implemented using the underlying CRT functions, which meant that
      there were certain odd restrictions, such as read/write text handles
      needing to be unbuffered, and seeking not working at all on text
      In the rewrite, newline translation is now implemented in the upper
      layers, as it needs to be since we have to perform Unicode decoding
      before newline translation.  This means that it is now available on
      all platforms, which can be quite handy for writing portable code.
      For now, I have left the behaviour as it was, namely \r\n -> \n on
      Windows, and no translation on Unix.  However, another reasonable
      default (similar to what Python does) would be to do \r\n -> \n on
      input, and convert to the platform-native representation (either \r\n
      or \n) on output.  This is called universalNewlineMode (below).
      The API is as follows.  (available from GHC.IO.Handle for now, again
      this is something we will probably want to try to get into System.IO
      at some point):
      -- | The representation of a newline in the external file or stream.
      data Newline = LF    -- ^ "\n"
                   | CRLF  -- ^ "\r\n"
                   deriving Eq
      -- | Specifies the translation, if any, of newline characters between
      -- internal Strings and the external file or stream.  Haskell Strings
      -- are assumed to represent newlines with the '\n' character; the
      -- newline mode specifies how to translate '\n' on output, and what to
      -- translate into '\n' on input.
      data NewlineMode 
        = NewlineMode { inputNL :: Newline,
                          -- ^ the representation of newlines on input
                        outputNL :: Newline
                          -- ^ the representation of newlines on output
                   deriving Eq
      -- | The native newline representation for the current platform
      nativeNewline :: Newline
      -- | Map "\r\n" into "\n" on input, and "\n" to the native newline
      -- represetnation on output.  This mode can be used on any platform, and
      -- works with text files using any newline convention.  The downside is
      -- that @readFile a >>= writeFile b@ might yield a different file.
      universalNewlineMode :: NewlineMode
      universalNewlineMode  = NewlineMode { inputNL  = CRLF, 
                                            outputNL = nativeNewline }
      -- | Use the native newline representation on both input and output
      nativeNewlineMode    :: NewlineMode
      nativeNewlineMode     = NewlineMode { inputNL  = nativeNewline, 
                                            outputNL = nativeNewline }
      -- | Do no newline translation at all.
      noNewlineTranslation :: NewlineMode
      noNewlineTranslation  = NewlineMode { inputNL  = LF, outputNL = LF }
      -- | Change the newline translation mode on the Handle.
      hSetNewlineMode :: Handle -> NewlineMode -> IO ()
      IO Devices
      The major change here is that the implementation of the Handle
      operations is separated from the underlying IO device, using type
      classes.  File descriptors are just one IO provider; I have also
      implemented memory-mapped files (good for random-access read/write)
      and a Handle that pipes output to a Chan (useful for testing code that
      writes to a Handle).  New kinds of Handle can be implemented outside
      the base package, for instance someone could write bytestringToHandle.
      A Handle is made using mkFileHandle:
      -- | makes a new 'Handle'
      mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev)
                    => dev -- ^ the underlying IO device, which must support
                           -- 'IODevice', 'BufferedIO' and 'Typeable'
                    -> FilePath
                           -- ^ a string describing the 'Handle', e.g. the file
                           -- path for a file.  Used in error messages.
                    -> IOMode
                           -- ^ The mode in which the 'Handle' is to be used
                    -> Maybe TextEncoding
                           -- ^ text encoding to use, if any
                    -> NewlineMode
                           -- ^ newline translation mode
                    -> IO Handle
      This also means that someone can write a completely new IO
      implementation on Windows based on native Win32 HANDLEs, and
      distribute it as a separate package (I really hope somebody does
      This restructuring isn't as radical as previous designs.  I haven't
      made any attempt to make a separate binary I/O layer, for example
      (although hGetBuf/hPutBuf do bypass the text encoding and newline
      translation).  The main goal here was to get Unicode support in, and
      to allow others to experiment with making new kinds of Handle.  We
      could split up the layers further later.
      API changes and Module structure
      NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still
      present, but are just re-exporting things from other modules now).
      For 6.12 we'll want to bump base to version 5 and add a base4-compat.
      For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated
      I split modules into smaller parts in many places.  For example, we
      now have GHC.IORef, GHC.MVar and GHC.IOArray containing the
      implementations of IORef, MVar and IOArray respectively.  This was
      necessary for untangling dependencies, but it also makes things easier
      to follow.
      The new module structurue for the IO-relatied parts of the base
      package is:
         Implementation of the IO monad; unsafe*; throw/catch
         The IOMode type
         Buffers and operations on them
         The IODevice and RawIO classes.
         The BufferedIO class.
         The FD type, with instances of IODevice, RawIO and BufferedIO.
         IO-related Exceptions
         The TextEncoding type; built-in TextEncodings; mkTextEncoding
         Implementation internals for GHC.IO.Encoding
         The main API for GHC's Handle implementation, provides all the Handle
         operations + mkFileHandle + hSetEncoding.
         Implementation of Handles and operations.
         Parts of the Handle API implemented by file-descriptors: openFile,
         stdin, stdout, stderr, fdToHandle etc.
  18. 19 Feb, 2009 1 commit
    • Simon Marlow's avatar
      Rewrite of signal-handling (base patch; see also ghc and unix patches) · 1d266a94
      Simon Marlow authored
      The API is the same (for now).  The new implementation has the
      capability to define signal handlers that have access to the siginfo
      of the signal (#592), but this functionality is not exposed in this
      #2451 is the ticket for the new API.
      The main purpose of bringing this in now is to fix race conditions in
      the old signal handling code (#2858).  Later we can enable the new
      API in the HEAD.
      Implementation differences:
       - More of the signal-handling is moved into Haskell.  We store the
         table of signal handlers in an MVar, rather than having a table of
         StablePtrs in the RTS.
       - In the threaded RTS, the siginfo of the signal is passed down the
         pipe to the IO manager thread, which manages the business of
         starting up new signal handler threads.  In the non-threaded RTS,
         the siginfo of caught signals is stored in the RTS, and the
         scheduler starts new signal handler threads.
  19. 14 Jan, 2009 1 commit
  20. 23 Aug, 2008 1 commit
  21. 20 Aug, 2008 1 commit
  22. 03 Aug, 2008 1 commit
  23. 01 Aug, 2008 4 commits
  24. 31 Jul, 2008 1 commit
  25. 30 Jul, 2008 2 commits
  26. 21 Jun, 2008 1 commit
  27. 09 Jul, 2008 2 commits
    • Simon Marlow's avatar
      FIX BUILD (on Windows) · ab5a660c
      Simon Marlow authored
    • Simon Marlow's avatar
      FIX part of #2301 · d17038a8
      Simon Marlow authored
      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.
  28. 08 Mar, 2008 1 commit
  29. 20 Jan, 2008 2 commits
  30. 03 Apr, 2007 1 commit
  31. 11 Aug, 2006 1 commit
  32. 21 Mar, 2006 1 commit
  33. 20 Mar, 2006 1 commit
    • Simon Marlow's avatar
      add runIOFastExit :: IO a -> IO a · d1372be0
      Simon Marlow authored
      Similar to runIO, but calls stg_exit() directly to exit, rather than
      shutdownHaskellAndExit().  Needed for running GHCi in the test suite.
  34. 03 Feb, 2005 1 commit