Timeline


and

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)

Jun 11, 2009:

11:02 PM WikiStart edited by dibblego
(diff)
4:01 PM Changeset in base [f473a3b]data-proxydbcsencodingghc-7.2ghc-7.4ghc-7.6ghc-7.8imp-param-classmonad-compsupercompilertype-reasoningwindows-iocp by Duncan Coutts <duncan@…>
Remove unused foreign imports of __encodeFloat/Double
4:01 PM Changeset in ghc [16f57103] by Duncan Coutts <duncan@…>
Remove unused foreign imports of __encodeFloat/Double
3:49 PM Changeset in ghc [ea7e893] by Duncan Coutts <duncan@…>
Add __encodeDouble and __encodeFloat Moved here from the rts.
3:49 PM Changeset in integer-gmp [bd4aa5c]ghc-7.2ghc-7.4ghc-7.6ghc-7.8wip/T8647 by Duncan Coutts <duncan@…>
Add __encodeDouble and __encodeFloat Moved here from the rts.
3:00 PM Changeset in process [b3eb59a]encodingghc-7.2ghc-7.4ghc-7.6ghc-7.8 by Simon Marlow <marlowsd@…>
Changes for new IO library
2:42 PM Ticket #3296 (mention also -RTS after stack overflow) created by maeder
a stack overflow is shown as follows: […] Maybe the usage message for …
2:39 PM Ticket #3291 ("Thread blocked indefinitely" kills the program despite being caught) closed by simonmar
invalid: The GC determines which threads are blocked indefinitely: those that are …
2:18 PM Changeset in unix [8438f51]encodingghc-7.2ghc-7.4ghc-7.6ghc-7.8 by Simon Marlow <marlowsd@…>
Update to work with the new GHC IO library internals

Jun 10, 2009:

10:34 PM Ticket #3295 (Null deref by threaded runtime scheduler) created by A1kmm
Using ghc and runtime built from HEAD on Tuesday (although this has been …
9:58 PM Ticket #3294 (Large compilation time/memory consumption) created by pumpkin
When compiling the attached test case in the following way: […] You can …
8:43 PM Ticket #3293 (Implement shiftLInteger and shiftRInteger) created by igloo
Currently shift for Integer (in Data.Bits) is defined in terms of …
7:01 PM Ticket #3292 (Add an 'ignore' function to Control.Monad) created by guest
See http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880
4:48 PM Ticket #3291 ("Thread blocked indefinitely" kills the program despite being caught) created by batterseapower
Perhaps this is just me misunderstanding the semantics of exceptions, but …
1:58 PM Ticket #3290 (Add Functor, Applicative, Monad, and Monoid instances for ParseResult) created by YitzGale
In the haskell-src package, add the following instances to ParseResult: …
8:51 AM Ticket #3285 ("PAP object entered" on executable with profiling) closed by simonmar
duplicate: closing as duplicate after adding a note to #2197 - thanks for the report!
2:24 AM Ticket #3289 (make -j3 (or make -j30) occasionally fails on 6.11) created by gbeshers
I've seen this a handful of times since the new build system was pushed. …

Jun 9, 2009:

9:30 PM Ticket #3288 (GC assertion failure in reactive program) created by Baughn
In the same vein as [http://hackage.haskell.org/trac/ghc/ticket/3279 bug …
2:17 PM Ticket #3287 (Malformed LANGUAGE pragma causes GHC panic) closed by simonmar
duplicate: Thanks for the report! See #3153
1:48 PM Ticket #3287 (Malformed LANGUAGE pragma causes GHC panic) created by caitt
Hi, I tried to compile file starting with {-# LANGUAGE …
1:26 PM Ticket #3286 (junk `naughty x86_64 register' after expression) created by igloo
This is a cut-down version of the hmm and logfloat packages on …

Jun 8, 2009:

12:21 PM Ticket #3285 ("PAP object entered" on executable with profiling) created by darchon
We're developing a tool that translates System Fc (GHC Core) to VHDL, and …
10:36 AM Ticket #3284 (ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: ...) created by mpiechotka
[…] (Crypto 4.1.0)
8:07 AM Building/Troubleshooting edited by simonmar
(diff)
8:05 AM Building/Troubleshooting edited by simonmar
(diff)
5:31 AM Ticket #3283 (Selective disabling of unused bind warnings) created by ajd
I like to compile with -fwarn-unused-binds to keep my code clean, but I …
Note: See TracTimeline for information about the timeline view.