Re: UTF-8 decoding error
Fortress (sun's possibly-not-vaporware hpc language) supports arbitrary
unicode chars in code, and has an escape syntax for commonly used things.
Similarly, proof-general/isabelle supports tex-style escapes for symbols
greek. It seems to me that a pre-processor that turns human-friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a slightly
intelligent IDE (or emacs mode?) would go most of the way to letting us use
up-side-down ys and curly as with all the visual beauty and editor niceness
that we have now with ascii.
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings) that can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Year 2038 problem in GHC 6.4.2 runtime
Hello Cyril, Tuesday, September 26, 2006, 1:30:23 AM, you wrote: I am afraid I would need the new Time library a little earlier than 2038, because I am working on financial software where it is not uncommon to have contracts over 30 years long. of course i'm joking. i even don't known is this library solves this problem or not Is the new Time library available for download? http://semantic.org/TimeLib/ moreover, it will be bundled with ghc 6.6 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more extra-libs for ghc 6.6
Bulat Ziganshin wrote: how about adding to the list of extra libs the following very useful ones: regex-* FilePath MissingH Edison Let me echo what Ian said: the idea with extralibs was not to bundle useful stuff with GHC, but rather to *separate* from GHC as many of the bundled libraries as we can. In the future we will probably drop extralibs altogether - it's only purpose is to reduce the surprise level for people used to all the bundled libs in GHC 6.4.2. Cheers, Simon ___ 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)
Duncan Coutts wrote: On Sun, 2006-09-24 at 01:28 +0400, Bulat Ziganshin wrote: Hello Duncan, Sunday, September 24, 2006, 12:22:38 AM, you wrote: 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. with 512k blocks it also allocates two times more data than requested. Oh, sorry I missed that point. Something fishy is going on then. Duncan's explanation works for allocating 4k, but there's another explanation for larger blocks. GHC allocates memory from the OS in units of a megablock (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage), currently 1Mb. So if you allocate a 1Mb array, the storage manager has to allocate 1Mb + overhead, which will cause it to allocate a 2Mb megablock. The surplus will be returned to the system in the form of free blocks, but if all you do is allocate lots of 1Mb arrays, you'll waste about half the sapce because there's never enough contiguous free space to contain another 1Mb array. Similar problem for 512k arrays: the storage manager allocates a 1Mb block, and returns slightly less than half of it as free blocks, so each 512k allocation takes a whole new 1Mb block. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Christian Maeder wrote: Simon Marlow schrieb: 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/ I've downloaded the source bundle ghc-6.5.20060918-src.tar.bz After ./configure and make, I realized that I have no root permissions for installation. So called ./configure --prefix=/local/home/maeder/ghc-6.5 followed by make and make install only to find out that /usr/local/lib/ghc-6.5.20060918/ghc-6.5.20060918 cannot be found by my /local/home/maeder/ghc-6.5/bin/ghc (in line 5). What do I have to clean after configure with a new prefix? (I hope not everything. And I hope it works at all with a different prefix) I think this is just because you tried to re-configure with a new prefix after the first failed installation, and the (slightly hacky) binary distribution Makefile didn't know to re-generate the scripts. If you unpacked the distribution and tried from scratch with a new prefix, it should work. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Simon Marlow schrieb: Christian Maeder wrote: I've downloaded the source bundle ghc-6.5.20060918-src.tar.bz After ./configure and make, I realized that I have no root permissions for installation. So called ./configure --prefix=/local/home/maeder/ghc-6.5 followed by make and make install only to find out that /usr/local/lib/ghc-6.5.20060918/ghc-6.5.20060918 cannot be found by my /local/home/maeder/ghc-6.5/bin/ghc (in line 5). What do I have to clean after configure with a new prefix? (I hope not everything. And I hope it works at all with a different prefix) I think this is just because you tried to re-configure with a new prefix after the first failed installation, and the (slightly hacky) binary distribution Makefile didn't know to re-generate the scripts. If you unpacked the distribution and tried from scratch with a new prefix, it should work. You're right, I re-configured with a new prefix. (I never tried to install with the wrong prefix but only called make in the sources.) Rather than recompiling the whole sources I grabbed a new binary distribution from the dist site. So I solved my problem but it discouraged me to compile the ghc sources (again). Aren't there just a few spots to be removed to allow changing the prefix? Christian ___ 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)
I added notes about this to http://haskell.org/haskellwiki/Performance/GHC S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Simon Marlow | Sent: 27 September 2006 13:44 | To: Duncan Coutts | Cc: glasgow-haskell-users@haskell.org | Subject: Re: bug in mallocForeignPtrBytes (both 6.4 and 6.6) | | Duncan Coutts wrote: | On Sun, 2006-09-24 at 01:28 +0400, Bulat Ziganshin wrote: | | Hello Duncan, | | Sunday, September 24, 2006, 12:22:38 AM, you wrote: | | | 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. | | with 512k blocks it also allocates two times more data than requested. | | Oh, sorry I missed that point. Something fishy is going on then. | | Duncan's explanation works for allocating 4k, but there's another explanation | for larger blocks. GHC allocates memory from the OS in units of a megablock | (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage), currently | 1Mb. So if you allocate a 1Mb array, the storage manager has to allocate 1Mb + | overhead, which will cause it to allocate a 2Mb megablock. The surplus will be | returned to the system in the form of free blocks, but if all you do is allocate | lots of 1Mb arrays, you'll waste about half the sapce because there's never | enough contiguous free space to contain another 1Mb array. Similar problem for | 512k arrays: the storage manager allocates a 1Mb block, and returns slightly | less than half of it as free blocks, so each 512k allocation takes a whole new | 1Mb block. | | Cheers, | Simon | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiler-independent core libraries infrastructure
On Fri, Sep 15, 2006 at 05:20:36PM +0100, Ian Lynagh wrote: As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. See my comment in http://hackage.haskell.org/trac/ghc/ticket/710 for the results of my longer look at this. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
more fixups for GHC docs: ddump flags
The flags under section 4.17.26. Compiler debugging options seem to be out of date. They seem to be wrong for both 6.42 and 6.6 For example --ddump-cmm is not listed, but works. But --ddump-absC is listed, and gives the error unknown flag. I can't get -ddump-stix to work either. Gone, or renamed, or only works in combination with other flags? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Sep 27, 2006, at 6:05 AM, Matthew Pocock wrote:
Fortress (sun's possibly-not-vaporware hpc language) supports
arbitrary
unicode chars in code, and has an escape syntax for commonly used
things.
I have spent the past week writing Fortress code (which runs in
parallel, even). But I'm perhaps a special case. :-)
Similarly, proof-general/isabelle supports tex-style escapes for
symbols
greek. It seems to me that a pre-processor that turns human-
friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a
slightly
intelligent IDE (or emacs mode?) would go most of the way to
letting us use
up-side-down ys and curly as with all the visual beauty and editor
niceness
that we have now with ascii.
In Fortress we spent a *lot* of effort making the TWiki syntax as
painless as possible for stuff which we planned to use often (for
example, - and = turn into Unicode arrows, and the language syntax
is defined in terms of them). One source of both encouragement and
frustration is the fact that every unicode code point has an
associated description. We support using these descriptions---and
various shortenings of them, since they are too verbose for day-to-
day use. The frustration is that the names or their shortenings are
not necessarily unique. For characters which only occur in strings
this is less critical, but a little effort will go a long way.
One heuristic we've used is: if I do a diff on the ASCII
representation provided by my version control system, will I be able
to read the result?
We of course have a little program which processes an official
unicode character table (downloaded from the web) plus some
information about our special cases and uses it to generate the
appropriate conversion functions. This is important because Unicode
is constantly changing (mostly getting bigger).
-Jan-Willem Maessen
Fortress developer, Haskell hacker
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1
characters
in literals?
I wish to keep source files (containing umlauts in strings) that
can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
smime.p7s
Description: S/MIME cryptographic signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Deferred instance declarations (serialization of existential boxes)
Simon Peyton-Jones wrote: Concerning your application | I am having a box like | data Box = forall a. Cxt a = Box a | and want to write a Read instances for it. I don’t see how it helps to defer the Read instance. I would defer the instance declaration till the point where I know all types that will ever go into the box (for instance in my Main module). The Show instance of Box would write the representation of a together with it's type (this means Cxt should contain at least Show and Typeable). The Read instance will then contain something like String aType- lexP result - case aType of [Int] - (readPrec :: ReadPrec [Int]) = (return . Box) SomeOtherType - (readPrec :: ReadPrec SomeOtherType) = (return . Box) -- more of such cases _ - error (aType ++ cannot be read inside of Box) Not very elegant of course, but it seems to be the only way to Read existentials. But I think the case is stronger for top-level constraints, and I will bear it in mind. If you would like to open a Trac feature request, please do so. Ok, I will. Cheers, Misha ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
