Hello,
On 22-11-2010, Thanassis Tsiodras wrote:
> I apologize beforehand if this is not the forum to ask.
>
> I am on the fence about whether to learn OCaml or not, and while
> reading an article called "Why OCaml"
> (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw
> that OCam
Thanassis Tsiodras gmail.com> writes:
-snip-
> Is it just hype, then? Or am I missing something?
Note the "Why Ocaml?" date - December 2002.
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-li
David Rajchenbach-Teller univ-orleans.fr> writes:
> I can confirm that old code-snippets were removed (and that both faster
solutions and environment
> variable tweaks were rejected).
Even back in 2001, Doug Bagley had noted all the things that were
wrong with the tasks on his "The Great Compu
Gerd Stolpmann gerd-stolpmann.de> writes:
-snip-
> I think the shootout is not a good data source. There are definitely
> some very poor Ocaml results there, so I'd guess the shootout got
> recently more attention by enthusiasts of other languages, and the
> current Ocaml programs there are not v
bluestorm gmail.com> writes:
-snip-
> With appropriate GC parameters, the very same OCaml program is exactly as fast
as C.
>
>
> http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees
>
> « Note: these programs are being measured with the default initial heap size -
the measure
Dario Teixeira yahoo.com> writes:
-snip-
> There's lies, damn lies, and shootout statistics.
-snip-
After all, facts are facts,
and although we may quote one to another with a chuckle
the words of the Wise Statesman, 'Lies--damned lies--and statistics,'
still there are some easy figures the simp
Christophe TROESTLER umh.ac.be> writes:
>
> On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
> >
> > > C version : 12.11 secs
> > > OCaml version : 47.22 secs
> > > OCaml version with GC parameters tuned ("interesting alternative"
> > section) : 12.67 secs
> >
> > And of course you know b
Is that book the source for the quotation 'Lies--damned lies--and statistics'?
Fabrice Le Fessant inria.fr> writes:
> Maybe you should read "Tainted Truth: The Manipulation of Fact In
> America" by Cynthia Crossen ?
___
Caml-list mailing list. Subscr
Jon Harrop googlemail.com> writes:
>
> Note that the regex-dna solution for Haskell tweaks its GC parameters via
> the -H command-line parameter:
Note that there is no restriction on "tuning the GC" for regex-dna.
Note that there is no restriction on "tuning the GC" for any task except
binary
Jon Harrop googlemail.com> writes:
> Ketil Malde crafted
> a much better solution but noted:
>
> "This is considered cheating, since it is the easy and natural way to do
> it." -
> http://www.haskell.org/haskellwiki/Shootout/Knucleotide
Not even cheating - just an answer to a different quest
The source of this pharse is unknown, however Mark Twain is credited with
making it well known:
"There are three kinds of lies: lies, damned lies and statistics."
Isaac Gouy writes:
> Is that book the source for the quotation 'Lies--damned lies--and statistics'?
>
>
> Fabrice Le Fessant
Mark Diekhans kermodei.com> writes:
>
>
> The source of this pharse is unknown, however Mark Twain is credited with
> making it well known:
>
>"There are three kinds of lies: lies, damned lies and statistics."
http://www.york.ac.uk/depts/maths/histstat/lies.htm
_
Török Edwin gmail.com> writes:
-snip-
> Sounds good. Then Ocaml could still win if it performs well on the
> other benchmarks.
The main benchmarks game summary is median and quartiles so one measurement
doesn't have much influence.
There are several tasks which have worse performing OCaml pro
Gerd Stolpmann gerd-stolpmann.de> writes:
-snip-
> I do not say that it is complete nonsense to do this comparison, but
> only that it is more specific than a reader would assume.
A reader's wrong assumptions are their own responsibility:
http://shootou.alioth.debian.org/flawed-benchmarks.php
Gerd Stolpmann gerd-stolpmann.de> writes:
> > > (It would be actually interesting to compare various versions of this test
> > > with different memory management methods.)
> >
> > So do that comparison and publish the results.
>
> Please don't tell me what I am supposed to do. I'm not a troll l
Christophe TROESTLER umh.ac.be> writes:
-snip-
> The question is why is C allowed to use
> an external library for managing its memory
I asked why you think C should not be allowed to use memory pools - you haven't
tried to answer that question.
If you think that C should not be allowed to use
Hi,
Regarding alternative solutions to the shootout problems:
The thread ring problem can be easily implemented using Lwt
yielding (pun intended ;)) performance
comparable to the haskell solution
have fun,
Romain.
___
Caml-list mailing list
Richard Jones annexia.org> writes:
> > Note that there is no restriction on "tuning the GC" for regex-dna.
> >
> > Note that there is no restriction on "tuning the GC" for any task except
> > binary-trees.
>
> Don't you think this is a pretty ludicrous restriction?
>
> Tuning the GC / adjustin
first.in-berlin.de> writes:
> > Even back in 2001, Doug Bagley had noted all the things that were
> > wrong with the tasks on his "The Great Computer Language Shootout".
>
> And what was wrong in his eyes?
Find out for yourself:
http://web.archive.org/web/20010617014807/www.bagley.org/~doug/
Eray Ozkural gmail.com> writes:
> Hello, I think that this benchmark is lacking ...
http://shootout.alioth.debian.org/help.php#why
Please make the kind of comparison you think should be done and publish it.
___
Caml-list mailing list. Subscription
Jeff Meister gmail.com> writes:
> We know what your rules are for
> binary-trees; repeating them does not help.
When Christophe TROESTLER wrongly states - "OCaml is not authorized to make use
of its very own library!" - he shows that those rules are not known.
> Richard's objection, which yo
Andrew gmail.com> writes:
> +1. Seriously, Isaac, try to calm down, everything is fine. You might want
> to read what others write, I have the feeling that many people were making
> valid points, whereas you have mostly been turning down any objection by
> pointing people to the same webpage and
David Rajchenbach-Teller univ-orleans.fr> writes:
> Maybe the solution is to get one of our numbers among the maintainers of the
shootout. This would guarantee, if not objectivity, then at least informed
choices wrt OCaml.
Presumably you'd need all of the maintainers to be OCaml certified to gu
Christophe Troestler umh.ac.be> writes:
> Isolating a sentence gives a misleading idea of what I said.
gmane demands "Prune quoted stuff."
> Must I
> really repeat that I was asking WHY is C allowed to use an external
> library to enhance its memory management¹ but OCaml cannot use its own
Thanassis Tsiodras gmail.com> writes:
-snip-
> However, when I actually went to the Language Shootout page suggested
> in the article, I found out that OCaml is not 2nd, it is 13th, behind
> languages like Haskell and C#...
>
(http://shootout.alioth.debian.org/u32/which-programming-languages-are-f
David Allsopp metastack.com> writes:
-snip-
> Reducing an entire programming language's strengths (or
> weaknesses!) to a single number is just not really realistic - the truth is
more complex than one
> single-precision floating point number (or even an array of them) can
describe. (NB. The shoo
Ed Keith yahoo.com> writes:
> > > I am not asking WHAT the rules are but a JUSTIFICATION
> > for them (which you
> > > have been incapable of providing so far).
> >
> > I feel no need to provide a JUSTIFICATION to you for
> > anything.
> >
>
> Am I to interpret this to mean that the rules are
David Allsopp metastack.com> writes:
> > > (NB. The shootout
> > > doesn't claim that the final ranking displayed is anything other than
> > > a score of how well the languages did
> > > at the various benchmarks given - but a graph like that is easy to
> > > interpret erroneously in that way)
>
> Richard's objection, which you dismissed out of hand, was that your
> no-GC-tuning rule is silly in the light of actual uses of garbage
> collected programming languages on modern processors. It makes your
> results unrealistic, and an unrealistic benchmark is misleading, or at
> best merely use
Stefan Monnier iro.umontreal.ca> writes:
-snip-
> Of course, the shootout could be improved.
Of course, anyone interested can do their own more extensive comparisons for a
couple of language implementations, for example -
http://blog.marketcetera.com/2007/03/08/java-and-the-computer-language
Fabrice Le Fessant inria.fr> writes:
-snip-
> Anyway, I decided to stop trying to improve the solutions, and work on
> improving the compiler and its libraries instead. It might benefit to
> ocaml ranking in the shootout, but more importantely, it will benefit to
> everybody in the community a
>>> I think OCaml's problem with this benchmark do point at a weakness
>>> of the current GC code.
> What makes you think that ?
I don't really understand the question: it was just stating the obvious.
OCaml's GC (including its default settings) is generally very good, but
like all GCs it has its
Maybe you should read "Tainted Truth: The Manipulation of Fact In
America" by Cynthia Crossen ?
--Fabrice
Isaac Gouy wrote, On 11/23/2010 03:20 AM:
> Dario Teixeira yahoo.com> writes:
> -snip-
>> There's lies, damn lies, and shootout statistics.
> -snip-
>
> After all, facts are facts,
> and a
On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
> C version : 12.11 secs
> OCaml version : 47.22 secs
> OCaml version with GC parameters tuned ("interesting alternative"
section) : 12.67 secs
And of course you know because that GC tuned OCaml program is shown
on the
benchmarks game
.inria.fr] On Behalf Of Christophe TROESTLER
> Sent: 23 November 2010 10:38
> To: igo...@yahoo.com
> Cc: caml-l...@inria.fr
> Subject: Re: [Caml-list] Re: Is OCaml fast?
>
> On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
> >
> > > C version : 12.11 secs
> >
l-list-
> boun...@yquem.inria.fr] On Behalf Of Christophe TROESTLER
> Sent: 23 November 2010 10:38
> To: igo...@yahoo.com
> Cc: caml-l...@inria.fr
> Subject: Re: [Caml-list] Re: Is OCaml fast?
>
> On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
> >
> > > C version : 12.11
On Tue, 23 Nov 2010 18:03:10 + (UTC)
Isaac Gouy wrote:
> Jon Harrop googlemail.com> writes:
>
> >
> > Note that the regex-dna solution for Haskell tweaks its GC
> > parameters via the -H command-line parameter:
>
>
> Note that there is no restriction on "tuning the GC" for regex-dna.
>
Am Dienstag, den 23.11.2010, 17:53 + schrieb Isaac Gouy:
> Christophe TROESTLER umh.ac.be> writes:
>
> >
> > On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
> > >
> > > > C version : 12.11 secs
> > > > OCaml version : 47.22 secs
> > > > OCaml version with GC parameters tuned ("interest
Am Dienstag, den 23.11.2010, 20:28 + schrieb Isaac Gouy:
> > (It would be actually interesting to compare various versions of this test
> > with different memory management methods.)
>
> So do that comparison and publish the results.
Please don't tell me what I am supposed to do. I'm not a t
On Tue, 23 Nov 2010 17:53:14 +, Isaac Gouy wrote:
>
> Christophe TROESTLER writes:
>
> > Since you are here, please explain why C can use memory pools and vec
> > tor instructions but tuning the GC of OCaml ― although it is part of
> > the standard library ― is considered an “alternative”.
Yes, an answer to a better question.
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Isaac Gouy
> Sent: 23 November 2010 18:07
> To: caml-l...@inria.fr
> Subject: [Caml-list] Re: Is OCaml fas
On Tue, Nov 23, 2010 at 06:03:10PM +, Isaac Gouy wrote:
> Jon Harrop googlemail.com> writes:
>
> >
> > Note that the regex-dna solution for Haskell tweaks its GC parameters via
> > the -H command-line parameter:
>
>
> Note that there is no restriction on "tuning the GC" for regex-dna.
>
>
On Tue, Nov 23, 2010 at 02:01:33AM +, Isaac Gouy wrote:
> David Rajchenbach-Teller univ-orleans.fr> writes:
>
>
> > I can confirm that old code-snippets were removed (and that both faster
> solutions and environment
> > variable tweaks were rejected).
>
>
> Even back in 2001, Doug Bagley h
Hello,
I think that this benchmark is lacking in the algorithms department. Where
is a dynamic programming problem? A graph algorithm? Anything with
non-trivial time/space complexity? Anything a little more complex than
matrix product?
Also, it's not uncommon to disallow low-level optimizations s
Everyone in this thread is capable of reading your site and has
probably already done so. We know what your rules are for
binary-trees; repeating them does not help. Richard's objection, which
you dismissed out of hand, was that your no-GC-tuning rule is silly in
the light of actual uses of garbage
> ::Jeff Meister
>Everyone in this thread is capable of reading your site and has
>probably already done so. We know what your rules are for
>binary-trees; repeating them does not help. Richard's objection, which
>you dismissed out of hand, was that your no-GC-tuning rule is silly in
>the light of
Submitted this a few years ago (just with streams, not Lwt), and the solution
was rejected.
On Nov 24, 2010, at 12:21 AM, evil sloot wrote:
> Hi,
>
> Regarding alternative solutions to the shootout problems:
> The thread ring problem can be easily implemented using Lwt
> yielding (pun intended
Maybe the solution is to get one of our numbers among the maintainers of the
shootout. This would guarantee, if not objectivity, then at least informed
choices wrt OCaml.
On Nov 24, 2010, at 2:36 AM, Eray Ozkural wrote:
> Hello,
>
> I think that this benchmark is lacking in the algorithms depa
On Wed, 24 Nov 2010 06:50:15 +, Isaac Gouy wrote:
>
> Jeff Meister gmail.com> writes:
>
> > We know what your rules are for binary-trees; repeating them does
> > not help.
>
> When Christophe TROESTLER wrongly states - "OCaml is not authorized
> to make use of its very own library!" - he sh
On Wed, Nov 24, 2010 at 12:24 PM, Christophe Troestler <
christophe.troestler+oc...@umh.ac.be
> wrote:
> On Wed, 24 Nov 2010 06:50:15 +, Isaac Gouy wrote:
> >
> > Jeff Meister gmail.com> writes:
> >
> > > We know what your rules are for binary-trees; repeating them does
> > > not help.
> >
>
Hello,
Here is a test of gctweak.ml on the "now famous" binary-tree shootout bench ...
As you can see it is a 30% speed up which is not too bad, just adding
a file on the compilation command line !
I reattached the file, because I correct a few comments in it ... and a syntax
error
that is only
--- On Wed, 11/24/10, Isaac Gouy wrote:
>
>
> > I am not asking WHAT the rules are but a JUSTIFICATION
> for them (which you
> > have been incapable of providing so far).
>
> I feel no need to provide a JUSTIFICATION to you for
> anything.
>
Am I to interpret this to mean that the rules are p
Hey, guys.
Time to stop this, please.
Thanks,
David
On Nov 24, 2010, at 8:13 PM, Isaac Gouy wrote:
> Ed Keith yahoo.com> writes:
>
I am not asking WHAT the rules are but a JUSTIFICATION
>>> for them (which you
have been incapable of providing so far).
>>>
>>> I feel no need to prov
Isaac Gouy wrote:
> David Allsopp metastack.com> writes:
>
> -snip-
> > Reducing an entire programming language's strengths (or
> > weaknesses!) to a single number is just not really realistic - the
> > truth is more complex than one single-precision floating point
> > number (or even an array o
halting problem discovered practically ;)
Zitat von "David Rajchenbach-Teller" :
Hey, guys.
Time to stop this, please.
Thanks,
David
On Nov 24, 2010, at 8:13 PM, Isaac Gouy wrote:
Ed Keith yahoo.com> writes:
I am not asking WHAT the rules are but a JUSTIFICATION
for them (which you
Gerd Stolpmann writes:
> Am Dienstag, den 23.11.2010, 17:53 + schrieb Isaac Gouy:
>> Christophe TROESTLER umh.ac.be> writes:
>>
>> >
>> > On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
>> > >
>> > > > C version : 12.11 secs
>> > > > OCaml version : 47.22 secs
>> > > > OCaml version
Stefan wrote:
> I think OCaml's
> problem with this benchmark do point at a weakness of the current
> GC code.
A difference but not necessarily a weakness. OCaml makes performance
transparent and gives you the ability to improve it with a high glass
ceiling. I prefer that to hiding the controls an
On 11/25/2010 11:12 PM, Jon Harrop wrote:
Stefan wrote:
I think OCaml's problem with this benchmark do point at a weakness of the
current
GC code.
What makes you think that ?
I have contributed to some of the solutions that you can find there (and
some other ones were rejected because cachi
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 code.
This is untrue ... the bintree example, is just bad in OCaml becau
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 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
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
li
> Sent: 29 November 2010 07:33
> To: oli...@first.in-berlin.de
> Cc: Caml List
> Subject: Re: [Caml-list] Re: Is OCaml fast?
>
> 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:
> >>
ml-list-boun...@yquem.inria.fr [mailto:caml-list-
> > boun...@yquem.inria.fr] On Behalf Of Christophe Raffalli
> > Sent: 29 November 2010 07:33
> > To: oli...@first.in-berlin.de
> > Cc: Caml List
> > Subject: Re: [Caml-list] Re: Is OCaml fast?
> >
> > Le 28
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
> 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
Le 29/11/10 12:44, oli...@first.in-berlin.de a écrit :
> yes.
>
> On Mon, Nov 29, 2010 at 11:25:52AM -, Jon Harrop wrote:
>> I assume he means one thread has one behaviour and another has the other
>> behaviour, in which case there certainly is a problem!
Then, I do not know what you can do .
Zitat von "Gerd Stolpmann" :
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
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 (ju
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
> Zitat von "Gerd Stolpmann" :
>
> > Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
> > oli...@first.in-berlin.de:
> >> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
> >> [...]
> >> > The main problem was that ot
Zitat von "Gerd Stolpmann" :
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Zitat von "Gerd Stolpmann" :
> Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
> oli...@first.in-berlin.de:
>> On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
>> [...]
>> > The main
On 11/29/2010 04:33 PM, Oliver Bandel wrote:
Zitat von "Gerd Stolpmann" :
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Zitat von "Gerd Stolpmann" :
You use shared mem(?), but you link only to *.ml files,
and I see no *.c there.
How can this be done?
At least not via th
On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
> On 11/29/2010 04:33 PM, Oliver Bandel wrote:
> >Zitat von "Gerd Stolpmann" :
> >
> >>Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
> >>>Zitat von "Gerd Stolpmann" :
> >>>
>
> >>>You use shared mem(?), but you link on
On Tue, Nov 30, 2010 at 2:55 PM, wrote:
>
>
> (A thread-specific GC for thread-specific variables would help here,
> making global locks only necessary when accessing global used variables.
> But I don't know if such a way would be possible without changing the
> GC-stuff
> itself.)
>
>
Seconde
On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
There is one problem with this... when you have forked, then
you obviously have separated processes and also in each process
your own ocaml-program with it's own GC running...
...neatly sidestepping the problem that the GC needs to lock o
Am Dienstag, den 30.11.2010, 13:55 +0100 schrieb
oli...@first.in-berlin.de:
> On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
> > On 11/29/2010 04:33 PM, Oliver Bandel wrote:
> > >Zitat von "Gerd Stolpmann" :
> > >
> > >>Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Am Dienstag, den 30.11.2010, 15:04 +0100 schrieb Stephan Houben:
> On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
> > There is one problem with this... when you have forked, then
> > you obviously have separated processes and also in each process
> > your own ocaml-program with it's own G
On Tue, Nov 30, 2010 at 03:04:32PM +0100, Stephan Houben wrote:
> On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
> >There is one problem with this... when you have forked, then
> >you obviously have separated processes and also in each process
> >your own ocaml-program with it's own GC ru
On Tue, Nov 30, 2010 at 4:29 PM, wrote:
>
> And here I see a thread-specific GC as a solution.
>
> It seems to me that this way was not thought about before,
> and people thought about changing the GC to be able to handle multiple
> threads.
> Instead I mean: each thread that is not the global thr
On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
I don't think this is the reason. Many people can ignore Windows,
actually.
The problem is more that your whole program needs then to be
restructured - multi-processing implies a process model (which is the
master, which are the workers). With multi-
Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
> On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
> > I don't think this is the reason. Many people can ignore Windows,
> > actually.
> >
> > The problem is more that your whole program needs then to be
> > restructured - multi-processi
On Tue, Nov 30, 2010 at 05:07:31PM +0100, Gerd Stolpmann wrote:
> Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
> > On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
> > > I don't think this is the reason. Many people can ignore Windows,
> > > actually.
> > >
> > > The problem is mor
What would be responsible for collecting the shared heap?
Cheers,
Jon.
Eray wrote:
> Seconded, why is this not possible? That is to say, why cannot each thread
maintain a separate GC,
> if so desired?
___
Caml-list mailing list. Subscription managemen
Le 30/11/10 22:13, Jon Harrop a écrit :
> What would be responsible for collecting the shared heap?
Reference counting: if there are no pointer within the shared heap (I
mean pointer
to and from the shared heap), this should be quite easy via a finaliser ...
For more than that, reference counting
82 matches
Mail list logo
