Hi everyone.
I am trying to create an ocaml binding to a C library as a test to see if I
can get the ocaml FFI to work. This is just experimental so I can gain
experience to later write bindings to real C libraries for ocaml.
I am using ocaml 3.11.0 with the MingW toolchain on windows (vista).
roua...@softwarerealisations.com a écrit :
Hi everyone.
Hi.
I am using ocaml 3.11.0 with the MingW toolchain on windows (vista).
Cannot help you much there.
Now I create the mylib_stub.c file which contains the marshalling code
between the libmylib.dll library and ocaml. This file contai
On 2009-12-31, at 00:30, Guillaume Yziquel wrote:
#include
#include
#include "../mylib/mylib.h"
CAMLprim value
my_print_stub(value v) {
CAMLparam1(v); /* is missing here, for garbage
collection purposes. */
char* str = (char*)String_val( v );
/* You
Damien Doligez a écrit :
On 2009-12-31, at 00:30, Guillaume Yziquel wrote:
#include
#include
#include "../mylib/mylib.h"
CAMLprim value
my_print_stub(value v) {
CAMLparam1(v); /* is missing here, for garbage
collection purposes. */
char* str = (char*)Stri
Guillaume Yziquel wrote:
However, I had a look at
https://yquem.inria.fr/caml/svn/ocaml/version/3.09/byterun/sys.c
and more specifically at the function
CAMLprim value caml_sys_exit(value retcode)
{
#ifndef NATIVE_CODE
caml_debugger(PROGRAM_EXIT);
#endif
exit(Int_val(retcode));
ret
Basile STARYNKEVITCH a écrit :
Why do these functions not follow the usual CAMLparam/CAMLreturn macro
stuff?
Because they are written by the Ocaml guys (Damien knows really well the
Ocaml garbage collector; he wrote it). And also, because these
particular functions do not do any allocation
Guillaume Yziquel:
> Basile STARYNKEVITCH a écrit :
> >>
> >> Why do these functions not follow the usual CAMLparam/CAMLreturn
> >> macro stuff?
> >
> > Because they are written by the Ocaml guys (Damien knows really well
> > the Ocaml garbage collector; he wrote it). And also, because these
> > pa
David Allsopp a écrit :
Guillaume Yziquel:
So, no allocation of OCaml values (or in place modification, either, I
guess) implies no need for CAMLparam/CAMLreturn stuff?
Chapter 18 of the manual in Section 18.5 describes pretty much everything you need to know about writing safe stubs that wor
On Sat, Jan 09, 2010 at 12:33:08PM +0100, Guillaume Yziquel wrote:
> David Allsopp a écrit :
> >Guillaume Yziquel:
> >
> >>So, no allocation of OCaml values (or in place modification, either, I
> >>guess) implies no need for CAMLparam/CAMLreturn stuff?
> >
> >Chapter 18 of the manual in Section 18.
Section 2) of this paper also has a very gentle and readable
introduction to the gc :
http://portal.acm.org/citation.cfm?id=141130
Another thing you need to know, if you have long running pieces of C
code that don't interact with ocaml's runtime system, is the two
functions :
caml_enter_blocking
> http://portal.acm.org/citation.cfm?id=141130
http://portal.acm.org/citation.cfm?id=1411308
Sorry,
Daniel
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beg
On Jan 9, 2010, at 2:02 PM, Daniel Bünzli wrote:
> http://portal.acm.org/citation.cfm?id=1411308
How can I access this paper without an ACM subscription?
Thanks, Joel
---
http://wagerlabs.com
___
Caml-list mailing list. Subscription manage
Richard Jones a écrit :
Why is this a problem? Because you might in your C code have some
value on the stack. 'value' is (or can be) a pointer. The OCaml
garbage collector can move pointed-to-objects around, firstly from the
minor heap to the major heap, secondly when compacting the major hea
Daniel Bünzli a écrit :
Section 2) of this paper also has a very gentle and readable
introduction to the gc :
http://portal.acm.org/citation.cfm?id=141130
Thanks for the link.
Another thing you need to know, if you have long running pieces of C
code that don't interact with ocaml's runtime s
> So if I want to call R code that multithreads with OCaml, I should write
> something like
>
>> enter_blocking_section();
>> PROTECT(e = R_tryEval(Sexp_val(sexp_list), R_GlobalEnv, &error));
>> UNPROTECT(1);
>> leave_blocking_section();
>
> Am I correct?
Yes, but the functions have now a caml
On Sat, 09 Jan 2010 20:36:07 +0100
Guillaume Yziquel wrote:
> So if I want to call R code that multithreads with OCaml, I should write
> something like
>
> > enter_blocking_section();
> > PROTECT(e = R_tryEval(Sexp_val(sexp_list), R_GlobalEnv, &error));
> > UNPROTECT(1);
> > leave_block
> For instance, here is the piece of code that executes R code ad catches
> errors. I've tried to follow guidelines available on the net, and
> inspired myself from pcre.
>
> > CAMLprim value r_eval_sxp (value sexp_list) {
> > CAMLparam0();
> > CAMLlocal2(ml_error_call, ml_error_message);
>
Gerd Stolpmann a écrit :
Would it be legitimate to include CAMLlocal2 inside the error-handling
braces?
No. You would start a new context for local roots, and there is no way
to end it (CAMLreturn ends the context).
There are the macros Begin_roots and End_roots that should be used in
this c
Daniel Bünzli a écrit :
So if I want to call R code that multithreads with OCaml, I should write
something like
enter_blocking_section();
PROTECT(e = R_tryEval(Sexp_val(sexp_list), R_GlobalEnv, &error));
UNPROTECT(1);
leave_blocking_section();
Am I correct?
Yes, but the functions have no
ygrek a écrit :
On Sat, 09 Jan 2010 20:36:07 +0100
Guillaume Yziquel wrote:
So if I want to call R code that multithreads with OCaml, I should write
something like
enter_blocking_section();
PROTECT(e = R_tryEval(Sexp_val(sexp_list), R_GlobalEnv, &error));
UNPROTECT(1);
leave_blockin
On 2010-01-09, at 20:29, Guillaume Yziquel wrote:
The remembere set, in this context, explains why I would need
Store_field when dealing with pure OCaml world. When wrapping
pointers to the C heap in abstract blocks, I do not see the point of
Store_field, and it seems to me that Field= ass
21 matches
Mail list logo
