summaryrefslogtreecommitdiff
path: root/libraries/base/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Convert some more declarations to use the CAPIIan Lynagh2012-02-212-11/+6
|
* Redo the sigset capi changesIan Lynagh2012-02-211-22/+0
| | | | | Now that we have the CTYPE pragma we can do this in such a way that it doesn't break the build on OS X.
* Roll back the sigset capi changesIan Lynagh2011-12-041-0/+22
| | | | They broken the build on OSX. See #2979.
* Use capi to define the fcntl FFI importsIan Lynagh2011-11-291-14/+0
|
* Use capi some more (part of #5480)Ian Lynagh2011-11-291-16/+0
|
* Convert come FFI bindings to use the capi calling conventionIan Lynagh2011-11-281-26/+0
|
* Make a wrapper for getrusage; part of #5480Ian Lynagh2011-11-251-0/+8
|
* Remove some unused functions from include/HsBase.hIan Lynagh2011-11-251-24/+0
|
* Add a C wrapper for gettimeofdayIan Lynagh2011-11-251-0/+4
| | | | | | | Based on part of a patch from Arnaud Degroote in #5480. On NetBSD just calling the function directly warns: warning: reference to compatibility gettimeofday(); include <sys/time.h> to generate correct reference
* Add unsafeShift to Data.BitsJohan Tibell2011-11-081-0/+2
| | | | | This allows shifting by a non-statically known amount without introducing a branch (to check for "overflow").
* Add Data.Bits.popCountJohan Tibell2011-08-251-1/+2
|
* Remove some antiquated C constructsIan Lynagh2011-08-011-6/+6
| | | | | | | | Fixes validate on amd64/Linux with: SRC_CC_OPTS += -Wmissing-parameter-type SRC_CC_OPTS += -Wold-style-declaration SRC_CC_OPTS += -Wold-style-definition
* Typeable overhaul (see #5275)Simon Marlow2011-07-111-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instances of Typeable used to call mkTyCon: mkTyCon :: String -> TyCon which internally kept a table mapping Strings to Ints, so that each TyCon could be given a unique Int for fast comparison. This meant the String has to be unique across all types in the program. However, derived instances of typeable used the qualified original name (e.g. "GHC.Types.Int") which is not necessarily unique, is non-portable, and exposes implementation details. The String passed to mkTyCon is returned by tyConString :: TyCon -> String which let the user get at this non-portable representation (also the Show instance returns this String). Now we store three Strings in TyCon. The internal representation is this: data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } (internal representations are now provided by Data.Typeable.Internal) The fields of TyCon are not exposed via the public API. Together the three fields tyConPackage, tyConModule and tyConName uniquely identify a TyCon, and the Fingerprint is a hash of the concatenation of these three Strings (so no more internal cache to map strings to unique Ids). tyConString now returns the value of tyConName only, so is therefore portable (but the String returned does not uniquely identify the TyCon). I've measured the performance impact of this change, and performance seems to be uniformly better. This should improve things for SYB in particular. Also, the size of the code generated for deriving Typeable is less than half as much as before. == API changes == === mkTyCon is DEPRECATED == mkTyCon is used by some hand-written instances of Typeable. It still works as before, but is deprecated in favour of... === Add mkTyCon3 === mkTyCon3 :: String -> String -> String -> TyCon mkTyCon3 takes the package, module, and name of the TyCon respectively. Most users can just derive Typeable, there's no need to use mkTyCon3. In due course we can rename mkTyCon3 back to mkTyCon. === typeRepKey changed === Previously we had typeRepKey :: TypeRep -> IO Int but since we don't assign unique Ints to TypeReps any more, this is difficult to implement. Instead we provide an abstract key type which is an instance of Eq and Ord, and internally is implemented by the fingerprint: data TypeRepKey -- abstract, instance of Eq, Ord typeRepKey :: TypeRep -> IO TypeRepKey typeRepKey is still in the IO monad, because the Ord instance is implementation-defined.
* For GHC, implement the Typeable.hs macros using standalone derivingIan Lynagh2011-04-241-39/+13
| | | | | | As well as being more pleasant, this fixes #1841: Data.Typeable: Instances of basic types don't provide qualified strings to mkTyCon
* Use _NSGetEnviron on OS X: fixes #2458Max Bolingbroke2011-04-061-0/+7
|
* More accurate isatty test for MinGW.Edward Z. Yang2010-09-071-0/+1
|
* Integrated new I/O managerSimon Marlow2010-08-102-0/+126
| | | | (patch originally by Johan Tibell <johan.tibell@gmail.com>, minor merging by me)
* Add some more C wrappers; patch from Krister WalfridssonIan Lynagh2009-08-071-0/+9
| | | | Fixes 21 testsuite errors on NetBSD 5.99.
* Updates to follow the RTS tidyupSimon Marlow2009-08-012-50/+35
| | | | C functions like isDoubleNaN moved here (primFloat.c)
* Move directory-related stuff to the unix packageSimon Marlow2009-06-252-47/+0
| | | | now that it isn't used on Windows any more.
* Tidy up use of read/write/recv/send; avoid unnecessary wrappersSimon Marlow2009-06-221-27/+0
|
* Windows: Unicode openFile and stat functionsSimon Marlow2009-06-181-24/+37
|
* Add a comment to remind us that memcpy_src_off is used by dphSimon Marlow2009-06-181-0/+1
|
* Remove old Integer prototypesIan Lynagh2009-06-151-3/+0
|
* Allow System.Posix.Internals to compile with nhc98 again.Malcolm.Wallace@cs.york.ac.uk2009-06-151-0/+1
| | | | Also affects GHC.IO.Device, which is not very GHC-specific at all.
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix warningsIan Lynagh2009-05-231-3/+3
|
* add _O_NOINHERIT when opening files on Windows (see #2650)Simon Marlow2009-05-201-2/+4
|
* Add wrappers around fcntlIan Lynagh2009-05-201-0/+14
| | | | | We need to do this as it has a (, ...) type, which we aren't allowed to directly call with the FFI.
* Set the IO manager pipe descriptors to FD_CLOEXECSimon Marlow2009-02-191-0/+20
| | | | | This pipe is an internal implementation detail, we don't really want it to be exposed.
* Rewrite of signal-handling (base patch; see also ghc and unix patches)Simon Marlow2009-02-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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 patch. #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.
* Make System.Posix.Internals buildable by nhc98.Malcolm.Wallace@cs.york.ac.uk2009-02-063-0/+50
|
* Don't define __hscore_s_issock on WindowsIan Lynagh2008-09-041-0/+2
|
* Don't make S_ISSOCK use conditionalIan Lynagh2008-09-041-2/+0
| | | | | We were conditionally defining the C wrapper, but unconditionally using it. So if it didn't exist then things would have broken anyway.
* make Typeable instances for larger tuples available to non-GHCRoss Paterson2008-09-031-0/+80
|
* Fix some more warningsIan Lynagh2008-08-201-1/+0
|
* remove __hscore_renameFile, it is no longer uesdSimon Marlow2008-08-181-1/+0
| | | | System.Directory implements renameFile using unix/Win32 now.
* Make the macros in Typeable.h add type signaturesIan Lynagh2008-06-191-0/+4
|
* delete __hscore_{mkstemp,getrlimit,setrlimit} (moved to unix)Ross Paterson2008-06-151-16/+0
|
* Fix the build on WindowsIan Lynagh2008-05-201-0/+2
|
* Add wrappers for [gs]etrlimitIan Lynagh2008-05-201-0/+10
| | | | | This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled.
* Add a wrapper for mkstempIan Lynagh2008-05-201-0/+4
| | | | | This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled.
* Avoid calling varargs functions using the FFISimon Marlow2008-05-091-0/+3
| | | | | | Calling varargs functions is explicitly deprecated according to the FFI specification. It used to work, just about, but it broke with the recent changes to the via-C backend to not use header files.
* fix types for __hscore_st_dev() and __hscore_st_ino()Simon Marlow2008-03-191-2/+2
|
* untabifyDon Stewart2008-03-051-6/+6
|
* add comment about lack of _chsize_s()Simon Marlow2008-01-231-0/+3
|
* Windows: large file support for hFileSize and hSeek (#1771)Simon Marlow2008-01-231-8/+28
|
* Move file locking into the RTS, fixing #629, #1109Simon Marlow2007-11-202-15/+2
| | | | | | | | | | | | | | | File locking (of the Haskell 98 variety) was previously done using a static table with linear search, which had two problems: the array had a fixed size and was sometimes too small (#1109), and performance of lockFile/unlockFile was suboptimal due to the linear search. Also the algorithm failed to count readers as required by Haskell 98 (#629). Now it's done using a hash table (provided by the RTS). Furthermore I avoided the extra fstat() for every open file by passing the dev_t and ino_t into lockFile. This and the improvements to the locking algorithm result in a healthy 20% or so performance increase for opening/closing files (see openFile008 test).
* Remove redundant include/MakefileIan Lynagh2007-08-281-14/+0
|
* fpstring.h has moved to bytestringRoss Paterson2007-08-191-6/+0
|
View Lorry Controller Status