All,
We've got an unfortunate situation with the bytestring repo. It got
accidentally forked after the ghc-6.8 release and is now about 7
releases behind and contains many known bugs and performance problems.
It would be pretty bad if ghc-6.10.1 shipped with this ancient
bytestring version.
The problem seems to be that the fork of bytestring that ghc is using
now cannot easily by synced with the current bytestring. This is because
a small handful of patches were added and we now cannot easily merge
while maintaining continuity for users. Of course we could just drop the
fork but that'd involve all people who use the ghc-6.10 branch darcs
repos deleting their libraries/bytestring repo and getting the new one.
One possibility is to apply one huge patch to the
ghc-6.10/packages/bytestring repo to bring it in sync with the current
bytestring. That'd still mean using the forked repo but users would not
be affected. However it would make it difficult to merge further fixes.
It's not a long term solution.
One alternative Ian has suggested occasionally is for bytestring to be
not a boot lib, then ghc would not need that repository at all. This
would work with a couple minor changes. The win32 package would have to
stop using bytestring (patch attached) and one function in the ghci code
would have to stop using bytestring. This would not preclude making
bytestring a boot lib again later if we thought we were going to make
more use of it.
One way or another we must make sure we do not ship an old bytestring
with ghc for another 12 months.
Duncan
Sat Oct 4 13:18:30 PDT 2008 Duncan Coutts <[EMAIL PROTECTED]>
* Drop Win32 dependency on the bytestring package
The function to mmap a file as a ByteString was never reviewed
and introduces a dependency in the wrong direction. The Win32
package is supposed to be lower in the package heirarchy and
the mmap feature should be implemented in bytestring on top of
functions in the unix and Win32 packages.
New patches:
[Drop Win32 dependency on the bytestring package
Duncan Coutts <[EMAIL PROTECTED]>**20081004201830
The function to mmap a file as a ByteString was never reviewed
and introduces a dependency in the wrong direction. The Win32
package is supposed to be lower in the package heirarchy and
the mmap feature should be implemented in bytestring on top of
functions in the unix and Win32 packages.
] {
hunk ./System/Win32/FileMapping.hsc 24
-import Data.ByteString ( ByteString )
-import Data.ByteString.Internal ( fromForeignPtr )
hunk ./System/Win32/FileMapping.hsc 50
--- | As mapFile, but returns ByteString
-mapFileBs :: FilePath -> IO ByteString
-mapFileBs p = do
- (fp,i) <- mapFile p
- return $ fromForeignPtr fp 0 i
-
hunk ./Win32.cabal 14
-build-depends: base, bytestring
+build-depends: base
}
Context:
[Pad version number to 2.2.0.0
Ian Lynagh <[EMAIL PROTECTED]>**20080920160255]
[Bump version number to 2.2
Ian Lynagh <[EMAIL PROTECTED]>**20080920115239]
[TAG 6.10 branch has been forked
Ian Lynagh <[EMAIL PROTECTED]>**20080919123439]
[failWith: generate proper IOExceptions
Simon Marlow <[EMAIL PROTECTED]>**20080826092409
I cheated a little by mapping first to an errno, using the existing
Foreign.C.Error.errnoToIOError, and finally adding the real error
message from Win32. To do this properly we should provide a
Win32-specific version of errnoToIOError.
]
[#define UNICODE in more places
Simon Marlow <[EMAIL PROTECTED]>**20080826090654
fixes garbled error messages from System.Win32 functions
]
[Move -DUNICODE from cc-options into HsWin32.h, where it can do less damange
Simon Marlow <[EMAIL PROTECTED]>**20080820140027
The problem is that cc-options get added to the command line for any C
compilation in a package that depends (directly or indirectly) on
Win32, and -DUNICODE was having unexpected effects.
]
[Build fixes
Ian Lynagh <[EMAIL PROTECTED]>**20080803180428]
[TAG 2008-05-28
Ian Lynagh <[EMAIL PROTECTED]>**20080528004258]
Patch bundle hash:
0f64361dedcda6c0c6f422834b8bff1a9ef9fd12
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
