GHCi spaces-on-folder-names bug revisited.
Hello. I have recently built a GHC/GHCi from the "ghc-5-04-branch" to check whether the bug concerning white spaces in folder names have been resolved. It has (thanks!) but while testing it I found another strangeness: it does not work for literate Haskell-scripts. $ ghci test\ dir/Test.lhs [...] Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. usage: unlit [-q] [-n] [-c] file1 file2 phase `Literate pre-processor' failed (exitcode = 1) Prelude> Whereas for the non-literate version seemingly works correctly. When running unlit manually via $ /usr/local/lib/ghc-5.04.3/unlit test\ dir/Test.lhs - it prints out the correct unliterated code. Any ideas as to what goes wrong? Thanks (again), Calle. PS When will 5.04.4 be released?
In local.glasgow-haskell-users, you wrote:
I have recently built a GHC/GHCi from the "ghc-5-04-branch" to check whether the bug concerning white spaces in folder names have been resolved. It has (thanks!) but while testing it I found another strangeness: it does not work for literate Haskell-scripts.
$ ghci test\ dir/Test.lhs [...] Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. usage: unlit [-q] [-n] [-c] file1 file2 phase `Literate pre-processor' failed (exitcode = 1)
Fixed in CVS, thanks!
PS When will 5.04.4 be released?
You mean 6.00? :) -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine
Volker Stolz
PS When will 5.04.4 be released?
You mean 6.00? :)
OK; when will the *next* release be around? And, in particular, will it fix the large file business? If it's going to take a while, I'll implement multiple files to work around the 2G limit, but if it's about to be released, I'd rather just wait for the upgraded RPMs. -kzm (a lazy programmer using a lazy language :-) -- If I haven't seen further, it is by standing in the footprints of giants
Volker Stolz
You mean 6.00? :)
On Mon, May 26, 2003 at 03:36:28PM +0200, Ketil Z. Malde wrote:
OK; when will the *next* release be around? And, in particular, will it fix the large file business? If it's going to take a while, I'll implement multiple files to work around the 2G limit, but if it's about to be released, I'd rather just wait for the upgraded RPMs.
It should probably be tied to an audit to ensure file offsets aren't ever truncated to 32 bits (wrapping can lead to non-termination of programs that would otherwise not loop when the offset fits into the type of offset variables). But that could very well be trivial. -- wli
participants (4)
-
Calle Lejdfors -
ketil＠ii.uib.no -
Volker Stolz -
William Lee Irwin III