21/09/15 18:41, David Matthews wrote:
On 21/09/2015 16:08, Phil Clayton wrote:
What I am actually observing is that finalizers are not run on exit for
finalizable values that are in scope in the top-level environment. On
exit, the REPL has finished, so shouldn't such values be garbage
On 21/09/2015 16:08, Phil Clayton wrote:
What I am actually observing is that finalizers are not run on exit for
finalizable values that are in scope in the top-level environment. On
exit, the REPL has finished, so shouldn't such values be garbage
collected and therefore finalized?
I noticed
On 17/09/2015 19:31, Matthew Fluet wrote:
On Thu, Sep 17, 2015 at 6:48 AM, Phil Clayton wrote:
16/09/15 12:40, David Matthews wrote:
On 15/09/2015 22:18, Phil Clayton wrote:
I looked at the MLton documentation and couldn't understand what "touch"
was trying to
On 18/09/2015 13:50, Phil Clayton wrote:
The only other changes I'm thinking about are:
1. Introducing a "touch" primitive for long-term security in case a
future update to the optimiser means that the current "touch" becomes a
no-op.
I think that would be a very good idea.
I've done that
16/09/15 12:40, David Matthews wrote:
On 15/09/2015 22:18, Phil Clayton wrote:
I think weak references could do the job. Better still, I may be able
to adapt (shamelessly copy) MLtonFinalizable:
https://github.com/MLton/mlton/blob/master/basis-library/mlton/finalizable.sig
Thanks for the example - it was a useful to see how to use the Thread
structure. And to see how easy it was. That's a nice library.
Attached is a first stab at implementing the FINALIZABLE signature shown
below, which is identical to MLTON_FINALIZABLE. The code is based on
the MLton
On 17/09/2015 11:50, Phil Clayton wrote:
Thanks for the example - it was a useful to see how to use the Thread
structure. And to see how easy it was. That's a nice library.
Attached is a first stab at implementing the FINALIZABLE signature shown
below, which is identical to MLTON_FINALIZABLE.
On 15/09/2015 23:06, Phil Clayton wrote:
In MLton, creating a finalizable value from the pointer and size is
simple. Roughly as follows:
fun fromNewPtr p n =
let
val array = Finalizable.new p
in
Finalizable.addFinalizer (t, fn p => free_ (p, n));
array
On 15/09/2015 22:18, Phil Clayton wrote:
I think weak references could do the job. Better still, I may be able
to adapt (shamelessly copy) MLtonFinalizable:
https://github.com/MLton/mlton/blob/master/basis-library/mlton/finalizable.sig
David,
I think weak references could do the job. Better still, I may be able
to adapt (shamelessly copy) MLtonFinalizable:
https://github.com/MLton/mlton/blob/master/basis-library/mlton/finalizable.sig
https://github.com/MLton/mlton/blob/master/basis-library/mlton/finalizable.sml
This would
Hi Phil,
Can't you wrap the array and size in a struct. For example in
https://github.com/polyml/polyml/tree/cb1b36caa242fc6ea9f74b015158466efac68d66/mlsource/extra/CInterface/Examples
we have :
-
//ForeignTest.c
typedef struct _tree {
struct _tree *left, *right;
On 14/09/2015 22:36, Phil Clayton wrote:
I am trying to create an SML binding to a C function that returns an
array that the caller must free. Usually, there is a free function that
takes just the array (as a pointer) which can be attached as a finalizer
with CInterface.setFinal. I have
I am trying to create an SML binding to a C function that returns an
array that the caller must free. Usually, there is a free function that
takes just the array (as a pointer) which can be attached as a finalizer
with CInterface.setFinal. I have encountered a case [1] where the
caller must
13 matches
Mail list logo