Le 28/11/2010 19:17, oli...@first.in-berlin.de a écrit :
> On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote:
>> Hello,
>>> To the extent that this rule is the same for all languages and that most
>>> languages on the shootout are also garbage collected, I think OCaml's
>>> proble
I see. Yes, that sounds like a great idea. How well does Immix cope with
high allocation rates of short-lived objects? Been a while since I read the
Immix paper...
Cheers,
Jon.
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Be
Hi,
As Jacques said, lablgtk's api is close to gtk's one. I also believe
that was the best solution/approach. Binding that many C functions to
ocaml is already hard enough (not that it could be made easier, the
difficulty lies in the number of functions).
The drawback is of course that writing co
On Nov 28, 2010, at 20:40 , Jon Harrop wrote:
> I don’t understand why this would help here though. Wouldn’t that help when a
> long-lived structure was single large block but, in this case, the long-lived
> structure is a tree composed of many small heap-allocated blocks and,
> therefore, the
I don't understand why this would help here though. Wouldn't that help when
a long-lived structure was single large block but, in this case, the
long-lived structure is a tree composed of many small heap-allocated blocks
and, therefore, they would undergo the same wasteful "allocate in young only
t
On Sun, Nov 28, 2010 at 4:29 PM, Benedikt Meurer <
benedikt.meu...@googlemail.com> wrote:
> Speaking of the OCaml GC in general, wouldn't it make sense to replace the
> current generational collector with a collector framework that requires less
> copying in the common case. For example, dividing
On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote:
> Hello,
> > To the extent that this rule is the same for all languages and that most
> > languages on the shootout are also garbage collected, I think OCaml's
> > problem with this benchmark do point at a weakness of the current
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
> The main problem was that other languages have bigger standard
> libraries, whereas OCaml has a very small one (just what is needed
> to compile the compiler, actually). In many problems, you could
> benefit from using a v
On 27-11-2010, Anastasia Gornostaeva wrote:
> On Sat, Nov 27, 2010 at 10:20:38AM +, Sylvain Le Gall wrote:
>> Hi,
>>
>> On 26-11-2010, Anastasia Gornostaeva wrote:
>> > Hello.
>> >
>> > How can I substitute in setup.ml (not in _oasis file) values for
>> > CCOpt and CCLib fields? I think it i
Speaking of the OCaml GC in general, wouldn't it make sense to replace the
current generational collector with a collector framework that requires less
copying in the common case. For example, dividing the heap into two parts,
"large object space" and "small object space", where LOS is managed b
Le 27/11/10 22:11, Pierre Etchemaïté a écrit :
> Le Mon, 22 Nov 2010 20:33:34 +0200, Török Edwin a
> écrit :
>
>> Not sure what the max should be for the minor heap increase, but based
>> on this benchmark increasing size of minor heap never slows down the
>> program. Even when size of minor heap
On 11/27/2010 11:31 AM, bluestorm wrote:
Reversing the specific
0-ary modification suggested by Alain is probably easier, as I suspect
most users don't use that one much, but Alain probably makes use of it;
As I've been designated as the primary responsible for that uninspired
change (I plead
There was also a project by Chris King to develop a GUI based on lablgtk in
a Functional Reactive Programming style.
http://lambda-the-ultimate.org/node/1918
On Wed, Nov 24, 2010 at 4:57 PM, Hezekiah M. Carty
wrote:
> On Wed, Nov 24, 2010 at 4:47 AM, Martin DeMello
> wrote:
> >
> > I was surp
13 matches
Mail list logo
