- Glasgow-haskell-users

Re[2]: [GHC] #710: library reorganisation
by Bulat Ziganshin 01 Oct '06

01 Oct '06

Hello GHC, Wednesday, September 27, 2006, 9:32:37 PM, you wrote: > I also managed to fork off > * `array` > * `containers` (`Data.{FunctorM, Foldable, Graph, IntMap, IntSet, Map, > Set, Queue, Sequence, Tree, Traversable`) > * `bytestring` > * `printf` > and it also looked plausible that `io` and/or `concurrency` would also be > able to be pulled out, but by that point I had run into enough of the > issues above that I stopped working on it. The rest can be looked at in > more detail when we come to do this for real. i will start answering from this easy part. First, ByteString - it was just integrated and it should be still easy enough to deintegrate this again. but after that, ByteString package should be included in list of extra packages array - look at my ArrayRef lib: http://haskell.org/haskellwiki/Library/ArrayRef http://www.haskell.org/library/ArrayRef.tar.gz except for a few still unfinished features, it's almost completely backward compatible with ghc 6.6 arrays implementation. so, i propose to use it, although some code may require to move between base and arrayref libs. say, unboxed references or GHC.* modules may be better looking in base lib while Ix class (which, i think, is compiler-independent) should be moved out of base. Also, HashTable and may be some other code is Array-dependent (although, on the other side, it may be easily rewritten to use only array primitives described in GHC.ArrBZ) containers, i.e. almost whole Data.* hierarchy - definitely yes other packages may be also based on existing hierarchies - Foreign.*, System.* GHC Handle I/O, i.e. GHC.Hanle, GHC.IO and part of GHC.IOBase - should be moved to separate package at some time. just because this I/O package are rather cumbersome and i hope that it will be replaced by Streams-like package concurrency - definitely. nothing depends on it, and it's separate concept that may be even not implemented in other compilers. but we should first decide where to place primitive operations (i.e. GHC.Conc) - leave them in base package or bundle into the same package as high-level operations? i prefer the first variant. btw, STM package is already playing by these rules Text.* - it would be great to move this into separate package, allowing to make alternative Read/Show implementations but it seems impossible because GHC deriving mechanism use these concrete implementation printf - i think it's too small to make any separate package -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

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