Timeline


and

Jun 17, 2009:

3:38 PM Changeset in directory [0175c04]encodingghc-7.2ghc-7.4ghc-7.6ghc-7.8patch-5014 by Simon Marlow <marlowsd@…>
Decouple from System.Posix.Internals on Unix This will let me clean up System.Posix.Internals, and move in the direction of having System.Directory depend only on either System.Posix or System.Win32.
2:49 PM Building/Using edited by simonmar
GhcLIbWays must contain "v" (diff)
2:06 PM Changeset in ghc [6cb7174]at-defaultsatomicsbetter-ho-cardinalitycardinalitycoerciblecoloured-corecpr-sum-typescrosscross-compiler-alienlessdata-kind-syntaxdecision-procedureencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8ghc-axiomsghc-constraint-solverghc-deferghc-lwc2ghc-new-coghc-new-flavorghc-parmake-gsocghc-spjimp-param-classknown-key-serializationlate-dmdlate-lam-liftlocal-gcmonad-compnew-demand-to-mergenewcgno-pred-tyoverlapping-tyfamsprofilingreal-src-loc-spansdocsilent-sc-argssimdsrclocsupercompilertc-arrowstc-untouchablesth-newth-new-7.6ticky-for-all-letstype-holes-branchtype-natstype-nats-simpleunboxed-tuple-argumentsunboxed-tuple-arguments2wip/Cabal-1.20wip/T4404wip/T5084wip/T7704wip/T8545-ghc-7.8wip/T8592wip/T8776wip/T8995-level-generalisationwip/cbv-conv-thunkwip/common-contextwip/cpr-vs-jpwip/exprAritywip/nested-cprwip/pattern-synonymswip/recurs-compatwip/simdwip/th-new by Simon Marlow <marlowsd@…>
fix 'make 1'
1:07 PM Ticket #3132 (cgCase of PrimAlts needs care in new codegen) reopened by simonmar
Ah, we need to leave this ticket open, as a reminder to investigate the …
1:05 PM Ticket #3132 (cgCase of PrimAlts needs care in new codegen) closed by simonmar
fixed: Fixed: […]
12:17 PM Changeset in ghc [ee937549] by Ian Lynagh <igloo@…>
gmp build tweaks
12:17 PM Changeset in integer-gmp [8c97633]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
gmp build tweaks
9:04 AM Ticket #3288 (GC assertion failure in reactive program) closed by simonmar
duplicate: This bug turns out to be the same as #3288
8:56 AM Commentary/Compiler/UnusedImports edited by simonpj
(diff)
8:48 AM Commentary/Compiler/UnusedImports created by simonpj
7:57 AM Ticket #3306 (Improve syntax for GADT + records) created by simonpj
This …

Jun 16, 2009:

6:30 PM Changeset in ghc [585f14e2] by Ian Lynagh <igloo@…>
Make configure fail if deriving the constants fails
6:30 PM Changeset in integer-gmp [62393f1]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Make configure fail if deriving the constants fails
5:37 PM Changeset in ghc [4a35e26] by Ian Lynagh <igloo@…>
Improve the configure script
5:37 PM Changeset in integer-gmp [b3a04fa]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Improve the configure script
2:06 PM Changeset in unix [b507e58]encodingghc-7.2ghc-7.4ghc-7.6ghc-7.8 by Ross Paterson <ross@…>
rename cache variables to keep recent autoconfs happy
12:36 PM Ticket #2678 (hLookAhead + hSetBuffering = unsupported operation (Illegal seek)) closed by simonmar
fixed: Works in HEAD. Added a test: […]
12:36 PM Ticket #3128 (hClose leaves file descriptor open if it fails) closed by simonmar
fixed: Fixed: […] and a test: […]
12:13 PM Building/Using edited by simonmar
(diff)
11:07 AM Changeset in base [049f089]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Simon Marlow <marlowsd@…>
Fix #3128: file descriptor leak when hClose fails
11:07 AM Changeset in ghc [bbbf03e] by Simon Marlow <marlowsd@…>
Fix #3128: file descriptor leak when hClose fails
10:42 AM TypeFunctionsStatus edited by simonpj
(diff)
10:10 AM Ticket #3270 (Stop using PackedString in template-haskell; drop packedstring as a ...) closed by simonmar
fixed: Done. In template-haskell: […] And ghc: […]
9:32 AM TypeFunctionsStatus edited by simonpj
(diff)
9:31 AM TypeFunctionsStatus edited by simonpj
(diff)
8:58 AM Building/Using edited by simonmar
(diff)
8:55 AM Building/Using edited by simonmar
(diff)
1:40 AM Ticket #3305 (panic message "impossible happened" loadobj: failed loading SOE packages ...) created by don vinnedge
ghc v. 6.10 error trying to run main1 in SOE.Animation.lhs package. No …

Jun 15, 2009:

9:48 PM Changeset in base [e060da5]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Ian Lynagh <igloo@…>
Fix warnings in configure script
9:48 PM Changeset in ghc [5abf6bce] by Ian Lynagh <igloo@…>
Fix warnings in configure script
8:32 PM Changeset in base [3c8810e]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Ian Lynagh <igloo@…>
Remove AC_C_CONST It was breaking the build on Windows. The problem was that we included stdio.h which gave a prototype for some functions (e.g. remove), then the AC_C_CONST meant that we did /* Define to empty if `const' does not conform to ANSI C. */ #define const /**/ and then we included io.h which gave prototypes that, due to const being removed, conflicted with the earlier prototypes.
8:32 PM Changeset in ghc [28d13213] by Ian Lynagh <igloo@…>
Remove AC_C_CONST It was breaking the build on Windows. The problem was that we included stdio.h which gave a prototype for some functions (e.g. remove), then the AC_C_CONST meant that we did /* Define to empty if `const' does not conform to ANSI C. */ #define const /**/ and then we included io.h which gave prototypes that, due to const being removed, conflicted with the earlier prototypes.
8:25 PM Changeset in ghc [81217a9] by Ian Lynagh <igloo@…>
Don't put "extra-libraries: gmp" in the cabal file; it comes from the buildinfo file
8:25 PM Changeset in integer-gmp [e4f4af1]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Don't put "extra-libraries: gmp" in the cabal file; it comes from the buildinfo file
8:24 PM Changeset in base [eac35b5]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Ian Lynagh <igloo@…>
Remove old Integer prototypes
8:24 PM Changeset in ghc [bba3952] by Ian Lynagh <igloo@…>
Remove old Integer prototypes
8:23 PM Changeset in ghc [ce8b9e1] by Ian Lynagh <igloo@…>
Fixes for building on machines that don't have gmp
8:23 PM Changeset in integer-gmp [d4611d6]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Fixes for building on machines that don't have gmp
8:17 PM Changeset in ghc [819ff42e] by Ian Lynagh <igloo@…>
Move the int64 conversion functions here, from ghc-prim
8:17 PM Changeset in integer-gmp [3e9b9da]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Move the int64 conversion functions here, from ghc-prim
8:17 PM Changeset in ghc [d8cc29c] by Ian Lynagh <igloo@…>
Remove the Integer functions; they're now in integer-gmp instead
8:17 PM Changeset in ghc-prim [a597405]ghc-7.2ghc-7.4ghc-7.6ghc-7.8no-pred-ty by Ian Lynagh <igloo@…>
Remove the Integer functions; they're now in integer-gmp instead
8:16 PM Changeset in base [a6e063f]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Ian Lynagh <igloo@…>
Fix warnings in C programs generated by configure; fixes failures with -Werror
8:16 PM Changeset in ghc [d273fbcc] by Ian Lynagh <igloo@…>
Fix warnings in C programs generated by configure; fixes failures with -Werror
3:52 PM Changeset in base [5bea16b]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Malcolm.Wallace@…>
Allow System.Posix.Internals to compile with nhc98 again. Also affects GHC.IO.Device, which is not very GHC-specific at all.
3:52 PM Changeset in ghc [7f97d9d] by Malcolm.Wallace@…>
Allow System.Posix.Internals to compile with nhc98 again. Also affects GHC.IO.Device, which is not very GHC-specific at all.
2:18 PM Ticket #2811 (Unicode support for text I/O) closed by simonmar
fixed: Done. […]
1:17 AM Ticket #3304 (define gcd 0 0 = 0) created by stevec
Please make any comments on the libraries list by Tuesday 15th September …

Jun 14, 2009:

9:53 PM Ticket #3303 (Allow multi-line deprecation messages.) created by duncan
Sometimes one line just isn't enough. There's two related issues, pretty …
6:53 PM Changeset in base [ccc931d]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Simon Marlow <marlowsd@…>
Save and restore the codec state when re-decoding We previously had an ugly hack to check for a BOM when re-decoding some binary data in flushCharBuffer. The hack was there essentially because codecs like UTF-16 have a state, and we had not restored it. This patch gives codecs an explicit state, and implemented saving/restoring of the state as necessary. Hence, the hack in flushCharBuffer is replaced by a more general mechanism that works for any codec with state. Unfortunately, iconv doesn't give us a way to save and restore the state, so this is currently only implemented for the built-in codecs.
6:53 PM Changeset in ghc [1e74d272] by Simon Marlow <marlowsd@…>
Save and restore the codec state when re-decoding We previously had an ugly hack to check for a BOM when re-decoding some binary data in flushCharBuffer. The hack was there essentially because codecs like UTF-16 have a state, and we had not restored it. This patch gives codecs an explicit state, and implemented saving/restoring of the state as necessary. Hence, the hack in flushCharBuffer is replaced by a more general mechanism that works for any codec with state. Unfortunately, iconv doesn't give us a way to save and restore the state, so this is currently only implemented for the built-in codecs.
6:32 PM Changeset in ghc [060251c2] by Ian Lynagh <igloo@…>
Move gmp to here, from the GHC repo
6:32 PM Changeset in integer-gmp [355dc3f]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Ian Lynagh <igloo@…>
Move gmp to here, from the GHC repo
6:19 PM Building/Platforms/Windows edited by augustss
(diff)
5:22 AM Ticket #3302 (Where-clause environments for GHCi) created by cjs
Often in ghci I'd like to interactively debug and play with functions in …
5:02 AM Ticket #3301 (Update Haskeline) created by cjs
GHC 6.10.3 switched from readline/editline to …
12:44 AM Ticket #3300 (System.IO and System.Directory functions not Unicode-aware under Windows) created by shu
Under Windows, System.Directory.getDirectoryContents seems to apply …

Jun 13, 2009:

5:27 PM Ticket #3299 (Error building HEAD on OS X: missing gmp.h) created by judah
I got a fresh tree from darcs of ghc+libraries, ran ./configure and …
2:46 PM Changeset in ghc [116fd1f] by Duncan Coutts <duncan@…>
Add a configure script and rely on local definitions of derived constants
2:46 PM Changeset in integer-gmp [5481265]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Duncan Coutts <duncan@…>
Add a configure script and rely on local definitions of derived constants
1:40 PM Changeset in ghc [8294eb64] by Duncan Coutts <duncan@…>
Tweak the small integer case of gcdInteger for better optimisation The gcdInt function in the base package now calls gcdInteger with two small integers. With this weak, the optimiser generates a base gcdInt that directly calls the gcdInt# primop from this package. This means there should be no additional overhead compared to when the base gcdInt called the gcdInt# primop directly.
1:40 PM Changeset in integer-gmp [8917ca1]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Duncan Coutts <duncan@…>
Tweak the small integer case of gcdInteger for better optimisation The gcdInt function in the base package now calls gcdInteger with two small integers. With this weak, the optimiser generates a base gcdInt that directly calls the gcdInt# primop from this package. This means there should be no additional overhead compared to when the base gcdInt called the gcdInt# primop directly.
1:37 PM Changeset in ghc [68e2d961] by Duncan Coutts <duncan@…>
Implement the gmp primops in the integer-gmp package using cmm
1:37 PM Changeset in integer-gmp [5c16b0a]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Duncan Coutts <duncan@…>
Implement the gmp primops in the integer-gmp package using cmm

Jun 12, 2009:

11:13 PM Changeset in base [7b0e8c5]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Ian Lynagh <igloo@…>
Add iconv as an extra library on platform that need to link with it For example, we need -liconv on OS X.
11:13 PM Changeset in ghc [7834fd6e] by Ian Lynagh <igloo@…>
Add iconv as an extra library on platform that need to link with it For example, we need -liconv on OS X.
9:07 PM Ticket #3298 (Add swap to Data.Tuple) created by r6
I think swap is a widely accepted name for the function. There is only …
2:29 PM Changeset in base [dcf1dbd]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Duncan Coutts <duncan@…>
Redefine gcdInt to use gcdInteger rather than gcdInt# primop The gcdInt# primop uses gmp internally, even though the interface is just Int#. Since we want to get gmp out of the rts we cannot keep gcdInt#, however it's also a bit odd for the integer package to export something that doesn't actually use Integer in its interface. Using gcdInteger is still not terribly satisfactory aesthetically. However in the short-term it works and it is no slower since gcdInteger calls gcdInt# for the special case of two small Integers.
2:29 PM Changeset in ghc [86b3b700] by Duncan Coutts <duncan@…>
Redefine gcdInt to use gcdInteger rather than gcdInt# primop The gcdInt# primop uses gmp internally, even though the interface is just Int#. Since we want to get gmp out of the rts we cannot keep gcdInt#, however it's also a bit odd for the integer package to export something that doesn't actually use Integer in its interface. Using gcdInteger is still not terribly satisfactory aesthetically. However in the short-term it works and it is no slower since gcdInteger calls gcdInt# for the special case of two small Integers.
1:56 PM Changeset in base [d2063b5]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Simon Marlow <marlowsd@…>
Rewrite of the IO library, including Unicode support 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.
1:56 PM Changeset in ghc [7b067f2d] by Simon Marlow <marlowsd@…>
Rewrite of the IO library, including Unicode support 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.
1:43 PM Ticket #3297 (Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in ...) created by hesselink
On the following code sample the compiler panics with: […] I found …
10:17 AM Changeset in ghc [10b4734] by Simon Marlow <marlowsd@…>
abstractify ModName, PkgName and OccName; drop dependency on packedstring
8:28 AM Building/GettingTheSources edited by simonmar
Remove mentions of darcs-all --extra, which now doesn't exist (diff)
Note: See TracTimeline for information about the timeline view.