- Glasgow-haskell-users

regex.h included with GHC 6.4.2
by Rich Fought 24 Jul '06

24 Jul '06

Am I crazy or is there an error in regex.h included with GHC? On line 110 there appears to be an extraneous or unterminated 'extern "C" {' Regards, Rich

2 1

Re: Text.Regex.Posix regcomp
by Rich Fought 20 Jul '06

20 Jul '06

Thanks, upgrading to 6.4.2 seems to have done the trick. I've obviously put it off too long! Rich

1 0

<<loop>> problems
by Chad Scherrer 20 Jul '06

20 Jul '06

Hi, I have some code that just says <<loop>> when it's run. I found a FAQ that says something about finalizers, but I'm not using those (at least not consciously). Here is my main: import qualified Data.ByteString.Lazy.Char8 as L main = do ls <- liftM L.lines $ L.readFile "output.txt" mapM_ (print . score . readUArray . L.words) ls ... and the types of some other pieces (I'm not sure how much you care to see) score :: (IArray a Double) => a Int Double -> Double readUArray :: [Data.ByteString.Lazy.ByteString] -> UArray Int Double Is this a bug, or am I doing something wrong? Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 2

Possible memory leak?
by Chris Kuklewicz 19 Jul '06

19 Jul '06

I was working on pulling library calling code from JRegex into Text.Regex.Lazy and I am wondering if this code for compiling regex.h regular expressions is a potential memory leak: > regcomp pattern flags = do > regex_fptr <- mallocForeignPtrBytes (#const sizeof(regex_t)) > r <- withCString pattern $ \cstr -> > withForeignPtr regex_fptr $ \p -> > c_regcomp p cstr (fromIntegral flags) > if (r == 0) > then do addForeignPtrFinalizer ptr_regfree regex_fptr > return (Regex regex_fptr) > else error "Text.Regex.Posix.regcomp: error in pattern" -- ToDo The (r/=0) path calls error, but never attaches the finalizer. And the man page for regex says: > The regfree() function frees any dynamically-allocated storage associated > with the compiled RE pointed to by preg. The remaining regex_t is no > longer a valid compiled RE and the effect of supplying it to regexec() or > regerror() is undefined. So it looks like the c_regcomp might allocate memory associated with regex_fptr even in the event of an error, so this case needs the same finalizer. I have not re-compiled GHC, but I have attached a small untested patch to change the code to always trigger the finalizer when there is an error: > regcomp pattern flags = do > regex_fptr <- mallocForeignPtrBytes (#const sizeof(regex_t)) > addForeignPtrFinalizer ptr_regfree regex_fptr > r <- withCString pattern $ \cstr -> > withForeignPtr regex_fptr $ \p -> > c_regcomp p cstr (fromIntegral flags) > if (r == 0) > then return (Regex regex_fptr) > else do finalizeForeignPtr regex_fptr > error "Text.Regex.Posix.regcomp: error in pattern" -- ToDo Cheers, Chris --- Text/Regex/Posix-orig.hsc 2006-07-18 11:06:55.000000000 +0100 +++ Text/Regex/Posix.hsc 2006-07-18 11:18:57.000000000 +0100 @@ -79,13 +79,14 @@ -> IO Regex -- ^ Returns: the compiled regular expression regcomp pattern flags = do regex_fptr <- mallocForeignPtrBytes (#const sizeof(regex_t)) + addForeignPtrFinalizer ptr_regfree regex_fptr r <- withCString pattern $ \cstr -> withForeignPtr regex_fptr $ \p -> c_regcomp p cstr (fromIntegral flags) if (r == 0) - then do addForeignPtrFinalizer ptr_regfree regex_fptr - return (Regex regex_fptr) - else error "Text.Regex.Posix.regcomp: error in pattern" -- ToDo + then return (Regex regex_fptr) + else do finalizeForeignPtr regex_fptr + error "Text.Regex.Posix.regcomp: error in pattern" -- ToDo -- ----------------------------------------------------------------------------- -- regexec

2 1

Recompiling the darcs tree after a pull
by Joel Reymont 19 Jul '06

19 Jul '06

I get a lot of errors like this: utils/Panic.lhs:27:0: Failed to load interface for `Config': Bad interface file: stage1/main/Config.hi mismatched interface file versions: expected 6050, found 390518464 Do you guys always clean after a pull or is there an easy way to get a list of *.hi (and *.o) files to delete? Thanks, Joel -- http://wagerlabs.com/

3 4

Package "mounting" proposal
by Sven Moritz Hallberg 16 Jul '06

16 Jul '06

Hi lists, (I hope my cross-posting is okay, but somehow this post seems to apply to all of you, so here goes...) I've recently noticed that folks at GHC HQ are working on a way to resolve the problem of importing two modules with the same name from different packages. There is a proposal[1] on the GHC wiki calling for a syntax extension for 'import' statements in Haskell modules so that the package (and version) to import from can be specified explicitly. There is a second ("extended") proposal[2], which calls for the ability to import (subtrees of) the module hierarchy exposed by a package and attach it to the global module namespace at an arbitrary point, analogous to mounting a filesystem in Unix. This proposal was appearently inspired by a post to the libraries mailing list by Frederik Eaton[3]. I agree with Frederik that it would be very nice to remove the burden of writing out long package or hierarchy prefixes in modules, and just work in some previously defined context. I'd like to propose yet another alternative to the existing two proposals that follows [2] in trying to satisfy [3] but differes from it in the following ways: - It doesn't require an extension of the existing Haskell syntax. - It can be implemented by extending Cabal alone (AFAICT). In particular, I propose to drop the assumption that Haskell modules are closed entities but rather always consider them to be seen in the context of a particular _package_. The package is now made responsible for assembling an appropriate (hierarchical) module namespace to which imports in the packaged modules are taken to refer. To this end, the current 'depends:' entry in a package description would be replaced by a more general "mounting" construct, i.e. "mount package foo at Foo.Bar in the module hierarchy". Optionally, as in [2], only a subtree of "foo" could be selected, or only a specific version of "foo". While I'm at it, I had to evaluate how this proposal would interact with the "ECT" module versioning scheme, I've proposed earlier[4]. I'd like to rework that scheme to this proposal. In ECT, a library author guarantees to his users that their imports will never break by providing different (numbered) variants of the library modules whenever their interface changes. By keeping the old variants as re-exports of updated versions, the author can record compatibilities. This carries the burden for users to annotate each import with a version number. If we lift the principles of ECT to the package level in accord with this proposal, that burden largely evaporates. Keeping the promise of "eternal backwards-compatibility", however, requires an (obvious) extension to the way Cabal deals with version numbers... First of all, package "mounts" must be able to say "this version, or any compatible one". Obviously, that's actually always what one wants, so it can be taken to be the only meaning of specifying "mount foo-1.3 at Foo.Bar". Then the question is just when to consider another version of foo compatible to 1.3. Obviously, only later versions should be considered, but when does compatibility end? Only the author of foo knows! She must specify it somehow. Two possibilities come to mind: 1. Add a field to the package description of foo (v1.4, say) that says "I'm backwards-compatible with 1.3." When building, this relation would have to be inspected to see whether any currently installed version of foo satisfies the dependency specified by the mount. 2. Declare a convention for version numbers to carry compatibility information, like the OpenGL standard, for example: If the new version is backwards-compatible, only the minor version number changes. If it isn't, the major version number must be incremented. I'd personally favour 2, as it would be easier to maintain for the author of foo (no compatiblity-field in the package description to update all the time) and also to implement in the build system (just a simple version comparison instead of a relation traversal to check a dependency). As a (more conservative?) variant of alternative 2, the third (instead of second) version component could be declared as "stays compatible", i.e. if only the third (or later) version component changes, the new version is assumed backwards-compatible, otherwise it's assumed incompatible. This would allow frequent incompatible updates without quickly getting large major version numbers... As for wasting space by keeping old versions around: Of course, if the new one is backwards-compatible, any old version can be removed. Otherwise, if it's "half-way" compatible, the author of foo can release a new backwards-compatible revision of the old version that reimplements (part of) the functionality in terms of the new operations, so the old version can be replaced by this leaner revision. Comments? Best regards, Sven [1]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackages [2]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackageNamespaces [3]: http://www.haskell.org/pipermail/libraries/2005-June/004009.html [4]: http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

2 1

Poor compile times
by Neil Mitchell 15 Jul '06

15 Jul '06

Hi, Using GHC 6.4.2 on Windows and 6.4.1 on Linux, I get really poor compile time performance for large do blocks - for example: main = do return () return () .... return () The following are the compile times in seconds for a given number of return () lines, GHC 6.4.1 on Linux, with a very beefy processor (my department server) and loads of RAM. 100 1.444 200 4.054 300 7.977 400 13.967 500 21.265 600 30.71 700 43.997 For comparison on my desktop machine I get out of heap space with 268Mb of heap, in a few minutes for 700. Compared to Hugs and Yhc, which both deal with all of these files instantly. By splitting the 700 line do block into 7 separate do blocks, each 100 lines, I get a compile time of 8.530. The particular reason I was running into this issue was with an auto generated file of tests, about 360 lines of reasonably lines in a do block, which exhausted the memory in GHCi. I have modified my test generator to split the files into 50 line blocks. Thanks Neil

1 0

Compile problem on Windows
by Robert Dockins 14 Jul '06

14 Jul '06

I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/ 4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible. I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake. Thanks Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 3

Where is HsTimeConfig.h?
by Alistair Bayley 14 Jul '06

14 Jul '06

I'm trying to build Ashley's time package with GHC6.4 on Windows XP, and there are a few things it uses which seem to be in GHC6.6 only. Some of them I can find in the GHC sources, but I am unable to locate HsTimeConfig.h. When GHC is installed I'd expect to find it under C:\ghc\ghc-6.4.1\include, but I can't tell where this maps to in the ghc source tree. Thanks, Alistair

5 8

STM check operation
by Rodney D Price 14 Jul '06

14 Jul '06

I've been reading the STM papers on Simon PJ's website, but I find that the GHC I'm using (6.5) changes a few things from the paper's descriptions. For instance, "atomic" becomes "atomically" and "catch" becomes "catchSTM". I can't, however, find "throw", and the type signature of "check" has changed. The GHC documentation isn't much help. Is there a discussion, perhaps in a mailing list archive somewhere, that will shed some light on these changes? Thanks, -Rod

3 4