Re: [Caml-list] using modules to wrap c++ classes
Joel Reymont joe...@gmail.com writes:
On Fri, May 4, 2012 at 9:43 AM, Goswin von Brederlow goswin-...@web.de
wrote:
As discussed on irc you need to create your callbacks[] array as ocaml
block and register that itself as root. That also has the benefit that
you only have to register a single root instead of 50.
Assuming that I have a class named MyCallbacks with a public member
callbacks of type value, is this correct?
No. The callbacks[] can be public, protect, private or static. You
could also register the individual callbacks but then you need to
register and deregister all 50 of them seperate. Having just one makes
things easier.
So the need above might be to strong. It is just simpler that way. And
I think the GC had some performance issues with too many roots.
Also, can I use Is_block to check if there's a closure value stored in
the callbacks block before I dispatch to the closure?
Sure.
Thanks, Joel
---
// finalizer, stored in custom_operations
void Callbacks_delete(value v)
{
CAMLparam1(v);
MyCallbacks* o = Callbacks_val(v);
caml_remove_global_root(o-callbacks);
delete o;
}
CAMLprim value
Callbacks_new()
{
CAMLparam0();
CAMLlocal2(v, cbks);
v = caml_alloc_custom(ops, sizeof(MyCallbacks*), 0, 1);
MyCallbacks* o = new MyCallbacks();
Callbacks_val(v) = o;
cbks = caml_alloc(NUM_CBKS, 0);
o-callbacks = cbks;
caml_register_global_root(o-callbacks);
CAMLreturn(v);
}
extern C CAMLprim value
Callbacks_set(value self, value cbk)
{
CAMLparam2(self, cbk);
MyCallbacks* o = Callbacks_val(self);
Store_field(o-callbacks, Tag_val(cbk), Field(0, cbk));
CAMLreturn(Val_unit);
}
Don't you have to use caml_modify() here instead of Store_field()? I
think Store_field is only alowed in freshly allocated blocks.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] A shallow option type
Hi, I wish there was an option type that would work without extra indirection (or more importantly without extra allocation of an ocaml value when setting it to something). Why? I'm interfacing with C in a multithreaded way. The data is allocated on the C side so it won't be moved around by the GC. The ocaml side will modify data and the C side will utilize it. Now if ocaml changes a multable 'a option then it will allocate a block for Some x and the GC will move that block around during compaction. Which means the 'a option can't be safely used without holding the runtime system lock. Which then means the threads can't run in parallel. What I want is a type 'a shallow = NULL | 'a (constraint 'a != 'b shallow) I have some ideas on how to implement this in a module as abstract type providing get/set/clear functions, which basically means I map None to a C NULL pointer and Some x to plain x. I know x can never be the NULL pointer, except when someone creates a 'a shallow shallow and sets Some None. That would turn into simply None. Is it possible to somehow declare the constraint that 'a in 'a shallow must not be itself a 'b shallow? MfG Goswin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] A shallow option type
Is it possible to somehow declare the constraint that 'a in 'a shallow
must not be itself a 'b shallow?
If I understand correctly, this is not possible directly, and while
you could do that with a sufficiently clever layer of phantom types,
I'm not sure it is worth the additional complexity. In particular, you
would not be able to statically move from ('a shallow) to ('a) by the
imperative action of updating a reference (one would need a type
system with strong update, where state change may incur type change,
to do that).
I think that, given your constraints, the simplest solution is
probably to just use 'a, while informally specifying that it is not
always safe to use, and providing from the C side a null value of type
'a, so that you can dynamically test on the OCaml side that your
variable indeed is initialized.
(I suppose you need to expose yet-unitialized values to the OCaml
side, otherwise you wouldn't need to reason about nullability at all.)
On Sat, May 5, 2012 at 3:33 PM, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I wish there was an option type that would work without extra
indirection (or more importantly without extra allocation of an ocaml
value when setting it to something).
Why? I'm interfacing with C in a multithreaded way. The data is
allocated on the C side so it won't be moved around by the GC. The ocaml
side will modify data and the C side will utilize it. Now if ocaml
changes a multable 'a option then it will allocate a block for Some x
and the GC will move that block around during compaction. Which means
the 'a option can't be safely used without holding the runtime system
lock. Which then means the threads can't run in parallel.
What I want is a
type 'a shallow = NULL | 'a (constraint 'a != 'b shallow)
I have some ideas on how to implement this in a module as abstract type
providing get/set/clear functions, which basically means I map None to a
C NULL pointer and Some x to plain x. I know x can never be the NULL
pointer, except when someone creates a 'a shallow shallow and sets Some
None. That would turn into simply None.
Is it possible to somehow declare the constraint that 'a in 'a shallow must
not be itself a 'b shallow?
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] using modules to wrap c++ classes
On Sat, May 5, 2012 at 1:39 PM, Goswin von Brederlow goswin-...@web.de wrote:
Don't you have to use caml_modify() here instead of Store_field()? I
think Store_field is only alowed in freshly allocated blocks.
Store_field uses caml_modify behind the scenes.
/* convenience macro */
#define Store_field(block, offset, val) do{ \
mlsize_t caml__temp_offset = (offset); \
value caml__temp_val = (val); \
caml_modify (Field ((block), caml__temp_offset), caml__temp_val); \
}while(0)
--
Working on AlgoKit, a new algorithmic trading platform using Rithmic R|API
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] A shallow option type
On May 5, 2012, at 15.33 h, Goswin von Brederlow wrote: What I want is a type 'a shallow = NULL | 'a (constraint 'a != 'b shallow) This is a form of negation, which cannot be expressed in conventional type systems. Just consider what it should mean in the presence of type abstraction: if you have M : sig type t ... end would `M.t shallow` be a legal type? You couldn't decide that properly without requiring that _every_ abstract type in every signature is annotated with a constraint saying that it is not shallow. I have some ideas on how to implement this in a module as abstract type providing get/set/clear functions, which basically means I map None to a C NULL pointer and Some x to plain x. I know x can never be the NULL pointer, except when someone creates a 'a shallow shallow and sets Some None. That would turn into simply None. And how do you know that nobody else implements a _different_ type, say shallow2, that does the same thing? And a third party then constructs a value of type `int shallow2 shallow`? It seems to me that what you want effectively is a special case of non- disjoint union. Unfortunately, those are known to come with all kinds of problems, such as not being compositional. /Andreas -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] How do I declare a value of 'a t instead of '_a t in a module?
Hi, I'm writing a module that reimplements the option type without redirection. For that I'm mapping None to a value with all bits set to 0, the NULL pointer in C. For that I have a little helper function: external make_null : unit - 'a t = caml_shallow_null But now I want to also have a polymorphic value for NULL: module Make : sig type 'a t val make_list : unit - 'a list val make_null : unit - 'a t end = struct type 'a t let make_list () = [] external make_null : unit - 'a t = caml_shallow_null end module Shallow : sig type 'a t val list : 'a list val null : 'a t end = struct type 'a t = 'a Make.t let list = Make.make_list () let null = Make.make_null () end File shallow.ml, line 15, characters 6-102: Error: Signature mismatch: Modules do not match: sig type 'a t = 'a Make.t val list : 'a list val null : '_a Make.t end is not included in sig type 'a t val list : 'a list val null : 'a t end Values do not match: val null : '_a Make.t is not included in val null : 'a t What makes the Make.make_list differ from Make.make_null? Is there a way that I can specify that null is still polymorphic or does that only work for constructors like None and compiler magic like []? -- And here something odd: module Make : sig type 'a t = 'a list val make_list : unit - 'a list val make_null : unit - 'a t end = struct type 'a t = 'a list let make_list () = [] external make_null : unit - 'a t = caml_shallow_null end module Shallow : sig type 'a t val list : 'a list val null : 'a t end = struct type 'a t = 'a Make.t let list = Make.make_list () let null = Make.make_null () end compiles fine. But module Make : sig type 'a t = private 'a list val make_list : unit - 'a list val make_null : unit - 'a t end = struct type 'a t = 'a list let make_list () = [] external make_null : unit - 'a t = caml_shallow_null end module Shallow : sig type 'a t val list : 'a list val null : 'a t end = struct type 'a t = 'a Make.t let list = Make.make_list () let null = Make.make_null () end fails again. Just making the Make.t private makes it fail. MfG Goswin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] How do I declare a value of 'a t instead of '_a t in a module?
You need to specify in the signature that ('a t) is contravariant:
type +'a t
This is done to please the relaxed value restriction: in the
let-binding let foo = make_null (), the right-hand-side is not a
value, so it is not generalized (this is the value restriction). The
relaxation introduced is that types that only occur in covariant
position are generalized. In general OCaml infers the variance so you
don't need to think about it, but if you have an opaque type interface
you need to specify the variance properties in the interface.
On Sat, May 5, 2012 at 5:37 PM, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I'm writing a module that reimplements the option type without
redirection. For that I'm mapping None to a value with all bits set to
0, the NULL pointer in C. For that I have a little helper function:
external make_null : unit - 'a t = caml_shallow_null
But now I want to also have a polymorphic value for NULL:
module Make : sig
type 'a t
val make_list : unit - 'a list
val make_null : unit - 'a t
end = struct
type 'a t
let make_list () = []
external make_null : unit - 'a t = caml_shallow_null
end
module Shallow : sig
type 'a t
val list : 'a list
val null : 'a t
end = struct
type 'a t = 'a Make.t
let list = Make.make_list ()
let null = Make.make_null ()
end
File shallow.ml, line 15, characters 6-102:
Error: Signature mismatch:
Modules do not match:
sig
type 'a t = 'a Make.t
val list : 'a list
val null : '_a Make.t
end
is not included in
sig type 'a t val list : 'a list val null : 'a t end
Values do not match:
val null : '_a Make.t
is not included in
val null : 'a t
What makes the Make.make_list differ from Make.make_null?
Is there a way that I can specify that null is still polymorphic or does
that only work for constructors like None and compiler magic like []?
--
And here something odd:
module Make : sig
type 'a t = 'a list
val make_list : unit - 'a list
val make_null : unit - 'a t
end = struct
type 'a t = 'a list
let make_list () = []
external make_null : unit - 'a t = caml_shallow_null
end
module Shallow : sig
type 'a t
val list : 'a list
val null : 'a t
end = struct
type 'a t = 'a Make.t
let list = Make.make_list ()
let null = Make.make_null ()
end
compiles fine. But
module Make : sig
type 'a t = private 'a list
val make_list : unit - 'a list
val make_null : unit - 'a t
end = struct
type 'a t = 'a list
let make_list () = []
external make_null : unit - 'a t = caml_shallow_null
end
module Shallow : sig
type 'a t
val list : 'a list
val null : 'a t
end = struct
type 'a t = 'a Make.t
let list = Make.make_list ()
let null = Make.make_null ()
end
fails again. Just making the Make.t private makes it fail.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] A shallow option type
Andreas Rossberg rossb...@mpi-sws.org writes:
On May 5, 2012, at 15.33 h, Goswin von Brederlow wrote:
What I want is a
type 'a shallow = NULL | 'a (constraint 'a != 'b shallow)
This is a form of negation, which cannot be expressed in conventional
type systems. Just consider what it should mean in the presence of
type abstraction: if you have
M : sig
type t
...
end
would `M.t shallow` be a legal type? You couldn't decide that properly
without requiring that _every_ abstract type in every signature is
annotated with a constraint saying that it is not shallow.
True, so abstract types would have to be forbidden too becauseit can't
be decided wether they are save or not. Since 'a shallow is an abstract
type that would also forbid 'a shallow shallow.
So constraint 'a != abstract would be the right thing.
I have some ideas on how to implement this in a module as abstract
type
providing get/set/clear functions, which basically means I map None
to a
C NULL pointer and Some x to plain x. I know x can never be the NULL
pointer, except when someone creates a 'a shallow shallow and sets
Some
None. That would turn into simply None.
And how do you know that nobody else implements a _different_ type,
say shallow2, that does the same thing? And a third party then
constructs a value of type `int shallow2 shallow`?
I don't and I can't. But such a type would be abstract so wouldn't be
allowed by the above (reject abstract types).
It seems to me that what you want effectively is a special case of non-
disjoint union. Unfortunately, those are known to come with all kinds
of problems, such as not being compositional.
/Andreas
What I want is to have an array of
type t ={ ... } (* Unit.t *)
and a matrix of
type tile = { ... mutable unit : Unit.t option; }
that I can safely access from a C thread in parallel with ocaml without
having to look the runtime system or individual tiles (the array and
matrix would both be created outside the ocaml heap).
The problem I have is that
tile.unit - Some unit
will allocate an option block on the heap and accessing that from C
while the GC runs causes a race condition.
What I don't want to do is use
type tile = { ... mutable unit : Unit.t; }
tile.unit - Obj.magic 0
since then trying things out in the toplevel causes segfaults when the
pretty printer prints the tile.unit and it would be easy to forget to
compare the tile.unit to Obj.magic 0 on every use. I know my shallow
type is basically nothing else but it adds a level of savety to it.
Idealy I would even love to write
match tile.unit with
| NULL - ()
| unit - do_something unit
I guess some camlp4 magic could be used to transform such a match into
match Shallow.as_option tile.unit with
| None - ()
| Some unit - do_something unit
or similar constructs.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] A shallow option type
Thanks for the clearer use-case example.
I think Andreas's comment is at a general level of language design:
no, we don't want to add something close to what you're asking for in
a language. His argumentation is spot on. What we could have is a type
system with strong update, but that's dreaming about another language,
not OCaml.
In your case, have you considered having a private option type, that
would be allocated by a call to a C primitive (building a genuine
OCaml option, but outside the heap) instead of (Some foo) on the OCaml
side? That would be completely safe, and you could still safely match
it on the OCaml side.
That said, it's only pushing the problem one step further: now you
still need to allocate your Unit.t value outside the OCaml heap,
otherwise you still have this problem. Is it the case in your
application?
On Sat, May 5, 2012 at 6:22 PM, Goswin von Brederlow goswin-...@web.de wrote:
Andreas Rossberg rossb...@mpi-sws.org writes:
On May 5, 2012, at 15.33 h, Goswin von Brederlow wrote:
What I want is a
type 'a shallow = NULL | 'a (constraint 'a != 'b shallow)
This is a form of negation, which cannot be expressed in conventional
type systems. Just consider what it should mean in the presence of
type abstraction: if you have
M : sig
type t
...
end
would `M.t shallow` be a legal type? You couldn't decide that properly
without requiring that _every_ abstract type in every signature is
annotated with a constraint saying that it is not shallow.
True, so abstract types would have to be forbidden too becauseit can't
be decided wether they are save or not. Since 'a shallow is an abstract
type that would also forbid 'a shallow shallow.
So constraint 'a != abstract would be the right thing.
I have some ideas on how to implement this in a module as abstract
type
providing get/set/clear functions, which basically means I map None
to a
C NULL pointer and Some x to plain x. I know x can never be the NULL
pointer, except when someone creates a 'a shallow shallow and sets
Some
None. That would turn into simply None.
And how do you know that nobody else implements a _different_ type,
say shallow2, that does the same thing? And a third party then
constructs a value of type `int shallow2 shallow`?
I don't and I can't. But such a type would be abstract so wouldn't be
allowed by the above (reject abstract types).
It seems to me that what you want effectively is a special case of non-
disjoint union. Unfortunately, those are known to come with all kinds
of problems, such as not being compositional.
/Andreas
What I want is to have an array of
type t ={ ... } (* Unit.t *)
and a matrix of
type tile = { ... mutable unit : Unit.t option; }
that I can safely access from a C thread in parallel with ocaml without
having to look the runtime system or individual tiles (the array and
matrix would both be created outside the ocaml heap).
The problem I have is that
tile.unit - Some unit
will allocate an option block on the heap and accessing that from C
while the GC runs causes a race condition.
What I don't want to do is use
type tile = { ... mutable unit : Unit.t; }
tile.unit - Obj.magic 0
since then trying things out in the toplevel causes segfaults when the
pretty printer prints the tile.unit and it would be easy to forget to
compare the tile.unit to Obj.magic 0 on every use. I know my shallow
type is basically nothing else but it adds a level of savety to it.
Idealy I would even love to write
match tile.unit with
| NULL - ()
| unit - do_something unit
I guess some camlp4 magic could be used to transform such a match into
match Shallow.as_option tile.unit with
| None - ()
| Some unit - do_something unit
or similar constructs.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] CiE 2012: Turing Centenary Conference, Cambridge - Final Call for Presentations
** FINAL CALL FOR INFORMAL PRESENTATIONS - DEADLINE MAY 11th, 2012: TURING CENTENARY CONFERENCE http://www.cie2012.eu Computability in Europe 2012: How the World Computes University of Cambridge Cambridge, 18-23 June 2012 CiE 2012 is one of three major international Turing Centenary Celebrations. CiE 2012 offers researchers an opportunity to actively participate in this remarkable year of activities. SUBMISSION OF ABSTRACTS OF INFORMAL PRESENTATIONS are invited with a deadline of MAY 11th 2012. For submission details, see: http://www.mathcomp.leeds.ac.uk/turing2012/WScie12/give-page.php?12 Authors will be notified of acceptance, usually within two weeks of submission. All accepted papers become eligible for consideration for post-conference journals: COMPUTABILITY will consider journal versions of papers presented at CiE conferences as a general rule; and there will be special issues of Logical Methods in Computer Science (LMCS), Annals of Pure and Applied Logic (APAL) and the Journal of Computational Biology. CiE 2012 CONFERENCE TOPICS include, but not exclusively - * Admissible sets * Algorithms * Analog computation * Artificial intelligence * Automata theory * Bioinformatics * Classical computability and degree structures * Cognitive science and modelling * Complexity classes * Computability theoretic aspects of programs * Computable analysis and real computation * Computable structures and models * Computational and proof complexity * Computational biology * Computational creativity * Computational learning and complexity * Computational linguistics * Concurrency and distributed computation * Constructive mathematics * Cryptographic complexity * Decidability of theories * Derandomization * DNA computing * Domain theory and computability * Dynamical systems and computational models * Effective descriptive set theory * Emerging and Non-standard Models of Computation * Finite model theory * Formal aspects of program analysis * Formal methods * Foundations of computer science * Games * Generalized recursion theory * History of computation * Hybrid systems * Higher type computability * Hypercomputational models * Infinite time Turing machines * Kolmogorov complexity * Lambda and combinatory calculi * L-systems and membrane computation * Machine learning * Mathematical models of emergence * Molecular computation * Morphogenesis and developmental biology * Multi-agent systems * Natural Computation * Neural nets and connectionist models * Philosophy of science and computation * Physics and computability * Probabilistic systems * Process algebras and concurrent systems * Programming language semantics * Proof mining and applications * Proof theory and computability * Proof complexity * Quantum computing and complexity * Randomness * Reducibilities and relative computation * Relativistic computation * Reverse mathematics * Semantics and logic of computation * Swarm intelligence and self-organisation * Type systems and type theory * Uncertain Reasoning * Weak systems of arithmetic and applications We particularly welcome submissions in emergent areas, such as bioinformatics and natural computation, where they have a basic connection with computability. CiE 2012 will have a special relationship to the scientific legacy of Alan Turing, reflected in the broad theme: How the World Computes, with all its different layers of meaning. Contributions which are directly related to the visionary and seminal work of Turing will be particularly welcome. PROGRAMME COMMITTEE: * Samson Abramsky (Oxford) * Pieter Adriaans (Amsterdam) * Franz Baader (Dresden) * Arnold Beckmann (Swansea) * Mark Bishop (London) * Paola Bonizzoni (Milan) * Luca Cardelli (Cambridge)* Douglas Cenzer (Gainesville) * S Barry Cooper (Leeds, Co-chair) * Ann Copestake (Cambridge) * Anuj Dawar (Cambridge, Co-chair) * Solomon Feferman (Stanford) * Bernold Fiedler (Berlin) * Luciano Floridi (Hertfordshire) * Martin Hyland (Cambridge)* Marcus Hutter (Canberra) * Viv Kendon (Leeds) * Stephan Kreutzer (Oxford) * Ming Li (Waterloo) * Benedikt Loewe (Amsterdam) * Angus MacIntyre (London) * Philip Maini (Oxford) * Larry Moss (Bloomington) * Amitabha Mukerjee (Kanpur) * Damian Niwinski (Warsaw) * Dag Normann (Oslo) * Prakash Panangaden (Montreal)* Jeff Paris (Manchester) * Brigitte Pientka (Montreal) * Helmut Schwichtenberg (Munich) * Wilfried Sieg (Carnegie Mellon) * Mariya Soskova (Sofia) * Bettina Speckmann (Eindhoven)* Christof Teuscher (Portland) * Peter van Emde Boas (Amsterdam) * Jan van Leeuwen (Utrecht) * Rineke Verbrugge (Groningen) The PROGRAMME COMMITTEE cordially invites all researchers
