Simon Marlow wrote:
[ replaying on glasgow-haskell-users@haskell.org ]
Paul A. Steckler wrote:
[Apologies for the cross-post from Haskell Cafe, but I got no responses
there.]
I need a Linux ghc 6.2.1 built with glibc-2.4. The existing 6.2.1 RPM,
built with glibc-2.3, works mostly OK, but with
On Wed, Apr 19, 2006 at 01:23:56PM +0200, Ketil Malde wrote:
> >> perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be
> >> called and the maximum heap size set to just under that
>
> Of course, it is commonly set to 'unlimited' anyway. Perhaps I should
> limit it; OTOH, the val
Christian Maeder wrote:
The files in the binary distribution are:
ghc -> ghc-6.4.2
ghc-6.4.2
due to a missing dvips "make binary-dist" does not finish properly and
does not create a ghc-6.4.2.sh (and other .sh) file(s).
Should it not be possible to build a binary distribution without
docum
Hello Simon,
Wednesday, April 19, 2006, 7:28:23 PM, you wrote:
> GHC might well be able to make use of such stuff too. In general,
> one would like to be able to treat a file much like a database, as
> you suggest, with binary serialisation of data structures into it.
what you mean by "database
Simon Marlow wrote:
--- ghc/rts/package.conf.inplaceThu Apr 13 15:49:49 2006
+++ ghc/rts/package.conf.inplace~ Wed Apr 12 19:44:55 2006
@@ -429,7 +429,6 @@
extra-libraries: "m"
, "gmp"
- , "rt"
Hello Simon,
Wednesday, April 19, 2006, 4:45:19 PM, you wrote:
> Believe me I've looked in detail at your streams library.
> Performance-wise it is great but the design needs to be reworked IMO.
> The main problem is that it doesn't have enough type structure. There
> are many combinations of s
GHC might well be able to make use of such stuff too. In general, one would
like to be able to treat a file much like a database, as you suggest, with
binary serialisation of data structures into it.
GHC's serialisation also includes a simple communing-up mechanism for "leaves",
especially str
Bulat Ziganshin wrote:
Streams library includes AltBinary functionality and also emulation of
two versions of NewBinary library - byte-aligned and bit-aligned one.
as long as you search for nhc-style serialization library (i.e., with
`get` and `put_` functions) my lib should be the best beast ar
Hello Simon,
Wednesday, April 19, 2006, 12:15:55 PM, you wrote:
> It's been on my todo list for a while to benchmark the various Binary
my lib anyway will be fastest :)))
> libraries, since there's a consensus that we need some kind of Binary
> functionality in Haskell'.
Streams library inclu
Simon Marlow <[EMAIL PROTECTED]> writes:
> John Meacham wrote:
>> perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be
>> called and the maximum heap size set to just under that
Of course, it is commonly set to 'unlimited' anyway. Perhaps I should
limit it; OTOH, the value mus
Simon Marlow wrote:
On 19 April 2006 11:53, Christian Maeder wrote:
Simon Marlow wrote:
Highlights in this release:
- Cabal has been upgraded to version 1.1.4.
ghc-pkg lists
Cabal-1.0
in the binary distribution
http://www.haskell.org/ghc/dist/6.4.2/ghc-6.4.2-i386-unknown-linux.t
On 19 April 2006 11:53, Christian Maeder wrote:
> Simon Marlow wrote:
>> Highlights in this release:
>>
>> - Cabal has been upgraded to version 1.1.4.
>
> ghc-pkg lists
>
> Cabal-1.0
>
> in the binary distribution
>
http://www.haskell.org/ghc/dist/6.4.2/ghc-6.4.2-i386-unknown-linux.tar.
Simon Marlow wrote:
Highlights in this release:
- Cabal has been upgraded to version 1.1.4.
ghc-pkg lists
Cabal-1.0
in the binary distribution
http://www.haskell.org/ghc/dist/6.4.2/ghc-6.4.2-i386-unknown-linux.tar.bz2
___
Glasgow-haskell-us
On Wed, Apr 19, 2006 at 01:56:25PM +0400, Bulat Ziganshin wrote:
> generational GC (at least one used in GHC) is better suited for
> "functional" (immutable) data. this conception by itself based on that
> new allocated data can contain references to old ones but not vice
> versa. minor GC algorith
Hello Ravi,
Wednesday, April 19, 2006, 12:05:28 AM, you wrote:
> 1. What "goes wrong" with mutable data and generational garbage
> collection to make this sort of workaround necessary?
generational GC (at least one used in GHC) is better suited for
"functional" (immutable) data. this conception
Simon Marlow wrote:
Christian Maeder wrote:
A further problem occured when installing my binary distribution. The
installed file "bin/ghc" (and bin/ghci) did not have the mini-driver,
but only the settings up to DEFAULT_TMPDIR.
Did you have BIN_DIST=1 in your build.mk from the beginning?
Ye
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC.
This release contains a significan
John Meacham wrote:
perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be
called and the maximum heap size set to just under that, since it is the
point that the OS will forcefully kill the program anyway.
Good idea, I've created a task ticket for it.
Cheers,
Simon
___
Jan-Willem Maessen wrote:
On Apr 18, 2006, at 4:05 PM, Ravi Nanavati wrote:
2. If there is a known fix for this issue, what would it involve
(and, if there are any guesses, how much work might it be)?
I had thought this was on the list of things fixed in 6.4. Simon?
Fixed in 6.6, yes.
Bulat Ziganshin wrote:
Hello Simon,
Tuesday, April 18, 2006, 3:02:20 PM, you wrote:
if that is due to the time of reading .hi files, my alternative Binary
library should help in some future
I'd be suprised if you could improve on GHC's binary library. Using
BinMem (reading/writing direct
Christian Maeder wrote:
Simon Marlow wrote:
I'm rolling and uploading the 6.4.2 bits now, and this patch didn't
make it in, sorry. We can put together a patchset for building on
Solaris and make it available separately. Can you send me a working
patch? Did the DriverState patch I posted ea
21 matches
Mail list logo
