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 hca...@atmos.umd.edu
wrote:
On Wed, Nov 24, 2010 at 4:47 AM, Martin DeMello
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
Le 27/11/10 22:11, Pierre Etchemaïté a écrit :
Le Mon, 22 Nov 2010 20:33:34 +0200, Török Edwin edwinto...@gmail.com 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
On 27-11-2010, Anastasia Gornostaeva erm...@ermine.pp.ru wrote:
On Sat, Nov 27, 2010 at 10:20:38AM +, Sylvain Le Gall wrote:
Hi,
On 26-11-2010, Anastasia Gornostaeva erm...@ermine.pp.ru wrote:
Hello.
How can I substitute in setup.ml (not in _oasis file) values for
CCOpt and CCLib
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 very
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
GC
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 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
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, they
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
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
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
problem with this
12 matches
Mail list logo
