summaryrefslogtreecommitdiff
path: root/libraries/base/GHC/ConsoleHandler.hs
Commit message (Collapse)AuthorAgeFilesLines
* winio: Multiple refactorings and support changes.Tamar Christina2020-07-151-162/+0
|
* Using unsafe foreign import for rtsSupportsBoundThreads (part of #9696)Marcin Mrotek2016-03-051-4/+4
| | | | | | | | | | | | | | | | | | A safe import is unnecessary considering rtsSupportsBoundThreads simply returns a constant. This commit doesn't fix the main issue of ticket #9696 that "readRawBufferPtr and writeRawBufferPtr allocate memory". Reviewers: bgamari, austin, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1964 GHC Trac Issues: #9696
* Allow CallStacks to be frozenEric Seidel2015-12-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces "freezing," an operation which prevents further locations from being appended to a CallStack. Library authors may want to prevent CallStacks from exposing implementation details, as a matter of hygiene. For example, in ``` head [] = error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` including the call-site of `error` in `head` is not strictly necessary as the error message already specifies clearly where the error came from. So we add a function `freezeCallStack` that wraps an existing CallStack, preventing further call-sites from being pushed onto it. In other words, ``` pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack ``` Now we can define `head` to not produce a CallStack at all ``` head [] = let ?callStack = freezeCallStack emptyCallStack in error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` --- 1. We add the `freezeCallStack` and `emptyCallStack` and update the definition of `CallStack` to support this functionality. 2. We add `errorWithoutStackTrace`, a variant of `error` that does not produce a stack trace, using this feature. I think this is a sensible wrapper function to provide in case users want it. 3. We replace uses of `error` in base with `errorWithoutStackTrace`. The rationale is that base does not export any functions that use CallStacks (except for `error` and `undefined`) so there's no way for the stack traces (from Implicit CallStacks) to include user-defined functions. They'll only contain the call to `error` itself. As base already has a good habit of providing useful error messages that name the triggering function, the stack trace really just adds noise to the error. (I don't have a strong opinion on whether we should include this third commit, but the change was very mechanical so I thought I'd include it anyway in case there's interest) 4. Updates tests in `array` and `stm` submodules Test Plan: ./validate, new test is T11049 Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1628 GHC Trac Issues: #11049
* Rip out __HADDOCK__ referencesBen Gamari2015-11-141-1/+1
| | | | | | | | | | | | | | | As it turns out no one actually sets this macro anyways and haddock now clearly has no trouble parsing this code. Test Plan: Validate Reviewers: hvr, goldfire, austin Reviewed By: austin Subscribers: duncan, thomie, hvr Differential Revision: https://phabricator.haskell.org/D1463
* Be consistent with placement of Safe Haskell mode at top of fileDavid Terei2014-11-211-1/+1
|
* Refactor module imports in baseHerbert Valerio Riedel2014-10-191-0/+4
| | | | | | | | | | 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.
* Drop redundant `{-# LANGUAGE #-}` pragmasHerbert Valerio Riedel2013-09-281-1/+1
| | | | | | | | | | | | | This removes language pragmas from Haskell modules which are implicitly active with `default-language: Haskell2010`. Specifically, the following language extension pragmas are removed by this commit: - PatternGuards - ForeignFunctionInterface - EmptyDataDecls - NoBangPatterns Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove unnecessary import (Windows only)Simon Peyton Jones2011-07-291-5/+7
| | | | ...and add a comment
* SafeHaskell: Added SafeHaskell to baseDavid Terei2011-06-181-0/+1
|
* add missing extensions for WindowsSimon Marlow2011-01-311-1/+1
|
* Use explicit language extensions & remove extension fields from base.cabalsimonpj@microsoft.com2011-01-281-1/+2
| | | | | | | | | | Add explicit {-# LANGUAGE xxx #-} pragmas to each module, that say what extensions that module uses. This makes it clearer where different extensions are used in the (large, variagated) base package. Now base.cabal doesn't need any extensions field Thanks to Bas van Dijk for doing all the work.
* Remove unused import on WindowsIan Lynagh2010-11-201-1/+0
|
* Remove an unnecessary fromIntegralIan Lynagh2010-11-201-1/+1
|
* Remove redundant importIan Lynagh2010-10-311-1/+0
|
* Windows build fix, following RTS tidyupSimon Marlow2009-08-031-1/+1
|
* Add back imports needed on WindowsIan Lynagh2009-07-071-0/+7
|
* Remove unused importsIan Lynagh2009-07-071-3/+0
|
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Highlights: * 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 independently. 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): latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). 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 anyway. [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 accepted. 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 Handles. 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!). 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 warnings. 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: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.UTF8 GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.
* Windows-only fixes for moving concurrent out of baseIan Lynagh2008-08-241-1/+10
|
* Fix Windows-only warningsIan Lynagh2008-08-231-1/+2
|
* FIX BUILD (on Windows)Simon Marlow2008-07-091-1/+1
|
* untabifyDon Stewart2008-03-051-22/+22
|
* protect console handler against concurrent access (#1922)Simon Marlow2007-12-041-19/+29
|
* documentation for installHandlerSimon Marlow2006-12-051-0/+19
| | | | merge to 6.6
* deriving (Eq, Ord, Enum, Show, Read, Typeab) for ConsoleEventSimon Marlow2006-12-011-0/+2
|
* generate Haddock docs on all platformsSimon Marlow2006-08-211-2/+4
|
* [project @ 2005-05-06 00:30:56 by sof]sof2005-05-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [mingw only] Work around bug in win32 Console API which showed up in the GHCi UI: if the user typed in characters prior to the appearance of the prompt, the first of these characters always came out as a 'g'. The GHCi UI does for good reasons one-character reads from 'stdin', which causes the underlying APIs to become confused. A simple repro case is the following piece of C code: /*----------------------*/ #include <stdio.h> #include <windows.h> int main() { char ch1,ch2; HANDLE hStdIn = GetStdHandle(STD_INPUT_HANDLE); DWORD dw; /* Type in some characters before the prompt appears and be amused.. */ sleep(1000); printf("? "); ReadConsoleA(hStdIn,&ch1,1,&dw,NULL); ReadConsoleA(hStdIn,&ch2,1,&dw,NULL); /* or, if you want to use libc: read(0,&ch1,1); read(0,&ch2,1); */ printf("%c%c\n", ch1,ch2); return 0; } /*----------------------*/ This happens across win32 OSes, and I can't see anything untoward as far as API usage goes (the GHC IO implementation uses read(), but that reduces to ReadConsoleA() calls.) People inside the Behemoth might want to have a closer look at this.. Not much we can do about this except work around the problem by flushing the input buffer prior to reading from stdin. Not ideal, as type-ahead is a useful feature. Flushing is handled by GHC.ConsoleHandler.flushConsole Merge to STABLE.
* [project @ 2005-04-22 17:00:49 by sof]sof2005-04-221-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | [mingw only] Better handling of I/O request abortions upon throwing an exception to a Haskell thread. As was, a thread blocked on an I/O request was simply unblocked, but its corresponding worker thread wasn't notified that the request had been abandoned. This manifested itself in GHCi upon Ctrl-C being hit at the prompt -- the worker thread blocked waiting for input on stdin prior to Ctrl-C would stick around even though its corresponding Haskell thread had been thrown an Interrupted exception. The upshot was that the worker would consume the next character typed in after Ctrl-C, but then just dropping it. Dealing with this turned out to be even more interesting due to Win32 aborting any console reads when Ctrl-C/Break events are delivered. The story could be improved upon (at the cost of portability) by making the Scheduler able to abort worker thread system calls; as is, requests are cooperatively abandoned. Maybe later. Also included are other minor tidyups to Ctrl-C handling under mingw. Merge to STABLE.
* [project @ 2005-02-03 10:38:44 by simonmar]simonmar2005-02-031-1/+1
| | | | unhide a few modules
* [project @ 2005-02-03 10:32:11 by ross]ross2005-02-031-0/+1
| | | | hide GHC internals from Haddock
* [project @ 2005-01-28 13:36:25 by simonmar]simonmar2005-01-281-2/+2
| | | | | | | Catch up with updates to platform #defines. Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we have to retain compatibility with previous GHC versions).
* [project @ 2005-01-11 16:04:08 by simonmar]simonmar2005-01-111-1/+1
| | | | Use OPTIONS_GHC instead of OPTIONS
* [project @ 2004-11-26 16:00:06 by simonmar]simonmar2004-11-261-0/+3
| | | | more make -j fixing
* [project @ 2004-11-17 19:07:38 by sof]sof2004-11-171-0/+88
Expose Win32 console event handling to the user. Added RTS support for registering and delivering console events quite a while ago (rts/win32/ConsoleHandler.c), but got bored with it before completing the job. Here's the concluding commit; it does the following: - new module, base/GHC/ConsoleHandler.hs which supports registering of console event handlers (the null module on plats other than mingw). - special handling of aborted async read()s on 'standard input' in rts/win32/IOManager.c (together with GHC.Conc.asyncRead). See comments in that IOManager.c as to why this is needed. [ Any other code that performs blocking I/O on 'standard input' will need to be tweaked too to be console event handler/signal friendly.] - for now, disable the delivery of 'close' events (see rts/win32/ConsoleHandler.c:generic_handler() for reasons why) Feel free to hoik GHC/ConsoleHandler.hs around the lib hierarchy to wherever is considered more fitting. Unifying functionality between System.Posix.Signals and GHC.ConsoleHandler is one (obvious) thing to do. -- Demonstrating GHC.ConsoleHandler use; win32 only module Main(main) where import GHC.ConsoleHandler import System.IO (hFlush, stdout) import GHC.Conc (threadDelay) main :: IO () main = do installHandler (Catch (\ _ -> putStrLn "Caught console event; ignoring" >> hFlush stdout)) loop where loop = do threadDelay 100000 ls <- getLine putStrLn ls loop --
View Lorry Controller Status