September 2006 - Glasgow-haskell-users

FW: [GHC] #916: windows installer should play nice with other Haskell tools
by Simon Peyton-Jones 28 Sep '06

28 Sep '06

Claus, Neil Thanks for raising this. I talked to Sigbjorn about it at ICFP. If you two can form a consensus (giving others an opportunity to speak up) about what should be the desirable behaviour for GHC's installer, he's happy to implement it. (Caveat: unless something turns out to be a lot of work, but that's unlikely.) You mention two specifics: - make file type registration optional - do not overwrite existing default handler for .hs/.lhs, just add new non-default handlers I believe that the former is done already; not sure about the latter (Sigbjorn will correct me if I'm wrong). I don’t know what a non-default handler is. Is there anything else? There was mention of better icons. What did you have in mind by "coordinate with Neil for WinHugs, and possibly with others"? Of course we'd like to coordinate... but about what specifically (apart from the above two)? Thanks Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of GHC Sent: 28 September 2006 14:46 To: glasgow-haskell-bugs(a)haskell.org Subject: [GHC] #916: windows installer should play nice with other Haskell tools #916: windows installer should play nice with other Haskell tools ----------------------------------------+----------------------------------- Reporter: claus.reinke(a)talk21.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.4.2 Severity: normal | Keywords: Os: Windows | Difficulty: Unknown Architecture: Unknown | ----------------------------------------+----------------------------------- traditionally, the windows installers have registered ghci as the default tool to operate on .hs/.lhs files, without regard for existing file type associations. that has been a real pain for those of us who like to use many tools on haskell files. could you please ensure that future installers are more cooperative? - coordinate with Neil for WinHugs, and possibly with others - make file type registration optional - do not overwrite existing default handler for .hs/.lhs, just add new non-default handlers (so people can use their own defaults, eg. editors, and still have easy access to ghci, hugs, ..) this has come up many times. see also: http://www.haskell.org/pipermail/glasgow-haskell-users/2004- March/006402.html http://www.haskell.org/pipermail/hugs-users/2006-February/000656.html http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/14819/ http://www.haskell.org/pipermail/glasgow-haskell-users/2006- September/011107.html http://www.haskell.org/pipermail/glasgow-haskell-users/2006- September/011110.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

4 7

Using close to 3GB heap on Linux, 32 bit
by Alex Iliev 28 Sep '06

28 Sep '06

Hello, I'm trying to run a program on rather large data (mostly an Inductive.Graph), and finding it will not grow beyond 2GB RAM, as reported by top. An allocation attempted by the runtime failed, with: out of memory (requested 1048576 bytes) This is unfortunate, as the machine has 4GB, and on stock Linux (+/- 2.6.9) a process can allocate close to 3GB (which is achievable with malloc as long as the chunks allocated are about 16MB or smaller). Any suggestions for allowing the program to grow bigger? I've tried various RTS settings, like -M2800M, -A10m, -H2000M (it seems to ignore -H with more than 2000M), but as soon as the program tries to grow beyond 2GB, it errors out. I'm using 6.4.1 (Debian testing) Thanks! alex

1 0

release notes
by Bulat Ziganshin 28 Sep '06

28 Sep '06

Hello Simon, i write to you, Simon (not to Igloo), because these changes require a knowledge of new GHC language features that you have implemented second paragraph of release notes (http://www.haskell.org/ghc/dist/current/docs/users_guide/release-6-6.html) is still erroneous. it mention two _different_ things - addition of impredicative polymorphism and changes in scoped type variables. Your mail mentioned here is about variables while section 7.4.9 is about polymorphism. There is also section 7.4.10 what say about variables and in my POV is much more readable than your letter. so i propose to write smth like the: - GHC now handles impredicative polymorphism, see Section 7.4.9, ⌠Impredicative polymorphism■ for the documentation - There are changes to the way scoped type variables work, see Section 7.4.10 for details. Shortly saying, the following is no more works: f (x::a) = sizeOf (undefined::a) g :: a = genericLength [] `asTypeOf` (undefined::a) while Section 7.4.10 should mention "Simon's letter" as containing more technical details. i also propose to add here explanations of how old code can be converted to new syntax. it may be obvious for you but not for us, common haskellers :D f (x::a) = sizeOf (undefined::a) should be now written as f :: a -> Int f (x::a) = sizeOf (undefined::a) to reach compatibility with old GHC versions and Hugs. well, i'm not language lawyer and not sure what is the best way, but at least using 'forall' to bring 'a' into scope is not H98-compatible It's very important to mention that this change means _dropping_ capabilities, not adding new ones, because it is completely unobvious from current docs. i don't realized it until i've compiled my program and spend several hours trying to understand 7.4.10, your letter and then 7.4.10 again :) i hope that proposed changes will greatly simplify this "learning curve" :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Year 2038 problem in GHC 6.4.2 runtime
by Cyril Schmidt 27 Sep '06

27 Sep '06

As far as I can see, the current (6.4.2) GHC runtime suffers the year 2038 problem; that is, the System.Time module does not support dates from 2038 onwards (the code below reproduces the problem). Is this bug scheduled to be fixed in the near future (my search in Trac yielded nothing) ? Regards, Cyril ___ The following code reproduces the problem with the Windows distribution of GHC 6.4.2: module Main where import System.Time main = putStrLn $ show $ toClockTime $ CalendarTime 2038 January 31 12 0 0 0 Sunday 0 "GMT" 0 False

3 5

bug in mallocForeignPtrBytes (both 6.4 and 6.6)
by Bulat Ziganshin 27 Sep '06

27 Sep '06

Hello glasgow-haskell-users, the attached program show up the bug in mallocForeignPtrBytes (and newPinnedByteArray#) implementation - it allocates two times more memory as requested. The bug seen both on 6.6rc and june 6.4 windows builds, namely: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-… http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.2.20060609-i386-unknown… after program prints "40 mb allocated" look at Task Manager indication - it shows that two times more memory actually in use. it seems that problem is only with allocating memory buffers whose sizes are powers of 2 or very close - bug shows for bufsize = 4kb, 1mb or 4095, but not not for 4000 or 10^6 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 5

ANNOUNCE: GHC 6.6 Release Candidate
by Simon Marlow 27 Sep '06

27 Sep '06

Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20060831 are release candidates for 6.6 Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src-extralibs… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! Which brings me on to the release itself: we had planned to release before ICFP, but that only leaves just over a week, which isn't really enough time to test the RC thoroughly, so it's looking like the 6.6 release will happen after ICFP now. In the meantime we have the RC to play with, so enjoy... Cheers, Simon

7 11

more extra-libs for ghc 6.6
by Bulat Ziganshin 27 Sep '06

27 Sep '06

Hello glasgow-haskell-users, how about adding to the list of extra libs the following very useful ones: regex-* FilePath MissingH Edison ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4

TArray
by Bulat Ziganshin 25 Sep '06

25 Sep '06

Hello glasgow-haskell-users, can someone try to compile this one-line module: import Control.Concurrent.STM.TArray with a recent 6.5 builds, preferably mingw32 ones? it doesn't work for me, although TVar and other modules import without any problems; and i see TArray.hi module along with TVar.hi and so on. the message is: Failed to load interface for `Control.Concurrent.STM.TArray': locations searched: Control/Concurrent/STM/TArray.hi Control/Concurrent/STM/TArray.hi-boot compiler is, again, http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-… -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

internal error: asyncRead#, ghci and fps (windows) (trac 806)
by Rene de Visser 25 Sep '06

25 Sep '06

Is there anyway to turn off that ghci runs in threaded mode on windows? fps 0.8 (and software that uses fps) triggers trac error #806. This means that I cannot run such things interactively :-( Rene.

2 1

threadDelay not ending
by Rich Fought 25 Sep '06

25 Sep '06

I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. Any ideas? What would have changed between 6.4 and 6.4.2 that would cause this behavior? Thanks, Rich

5 6