Re: Year 2038 problem in GHC 6.4.2 runtime
Hello Cyril, Friday, September 22, 2006, 6:16:44 PM, you wrote: 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). there is new Time library, which is supposed to replace old System.Time. we hope that it will happen before 2038 :D -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bug in mallocForeignPtrBytes (both 6.4 and 6.6)
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-mingw32.tar.gz http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.2.20060609-i386-unknown-mingw32.tar.gz 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:[EMAIL PROTECTED] mallocForeignPtrBytes.hs Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug in mallocForeignPtrBytes (both 6.4 and 6.6)
On Sat, 2006-09-23 at 13:58 +0400, Bulat Ziganshin wrote: 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-mingw32.tar.gz http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.2.20060609-i386-unknown-mingw32.tar.gz 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 The reason for this is that for larger objects ghc has an allocation granularity of 4k. That is it always uses a multiple of 4k bytes. However a byte array has some overhead: it needs one word for the heap cell header and another for the length. So if you allocate a 4k byte array then it uses 8k. So the trick is to allocate 4k - overhead. This is what the Data.ByteString library does. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User preferences lost between Hugs upgrades on Windows
[some possibly shared hugs/ghci concerns] The settings on Windows are stored under a registry key for each specific release. This means that if you install WinHugs, carefully set up everything, then upgrade, you loose all your settings. part of the reason was also to enable multiple independent versions of Hugs to be installed, I think? So: a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings? b) shouldn't there be an installation option checking for compatible old settings and offering to copy them? c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)? while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that we take over the handling of Haskell files, no matter what the user wanted? - it's a pain to have Hugs and GHCi compete with each other on this - I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web) any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-) cheers, claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User preferences lost between Hugs upgrades on Windows
Hi, a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings? That can be added, but no one will use it - too much effort, not obvious thats what needs to be done. b) shouldn't there be an installation option checking for compatible old settings and offering to copy them? Reasonable, although I still think just having one set of settings is a better way forward. c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)? A cabal issue, since Hugs has no knowledge of Cabal, but a reasonable idea. while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that we take over the handling of Haskell files, no matter what the user wanted? Nope :) I emailed off to people about this offering to cooperate nicely with GHC and Hugs, but no one ever got back to me, so both WinHugs and GHC steal the preferences. GHC also replaces the .hs document icon with one that is more ugly. I tried to submit a patch, and have emailed over the icons, but the GHC installer stuff isn't publically available, so I have no way to fix it. - I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web) Have you used a recent copy of WinHugs? The default action is to open the file in WinHugs, but there is also an edit action which opens the file in whichever editor you have configured WinHugs to use. It does this by firing off WinHugs, checking your settings for the best haskell editor, and starting it. If you haven't configured any editor specially, it will find the editor that seems best - i.e. if you have TextPad and Notepad, it will pick TextPad, otherwise it will pick Notepad if thats all it can find. All very seamless. I'd love to make Edit be the default, i.e. rename it to Open, and then add Open with WinHugs. However, this is a change in how WinHugs operates. Initially I tried to adhere quite closely to how WinHugs worked before I hacked on it, now I think the time has come to have Open be Edit and add Open in WinHugs. any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-) This time around, no - you just missed the boat on WinHugs and you're probably too late for GHC 6.6. Next time around, perhaps. I'm willing to do the WinHugs side, but it does need someone to do the GHC side. This is especially important because (as far as I was able to make out last time I started asking questions), the GHC installer is generated with a proprietory Haskell script which is not publically available. This means the community cannot play with the GHC installer and fix these issues. I am willing to adapt the Hugs on Windows installer to GHC, if thats something the GHC team would rather? You could also then have nightly builds that included an installer. For reference, Yhc is moving to the Hugs installer, and the Yhc nightly builds will come with an installer. For the moment Yhc won't register any file extensions, but if some suitable agreement can be found, I'll make sure Yhc follows that. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
