On 01/09/2010 02:04 AM, Guillaume Yziquel wrote:
Guillaume Yziquel a écrit :
Simon Urbanek a écrit :
If you have suggestions for extending the API, feel free to post them
with exact explanations how in general that extensions could be
useful (general is the key word here - I think so far it wa
Guillaume Yziquel a écrit :
Simon Urbanek a écrit :
If you have suggestions for extending the API, feel free to post them
with exact explanations how in general that extensions could be useful
(general is the key word here - I think so far it was rather to hack
around your way of implementin
Simon Urbanek a écrit :
If you have suggestions for extending the API, feel free to post them
with exact explanations how in general that extensions could be useful
(general is the key word here - I think so far it was rather to hack
around your way of implementing it). [And FWIW tryEval *is*
Simon Urbanek a écrit :
No, because you cannot use CHARSXP as a TAG. TAGs are always symbols.
Therefore, logically, you must register it first in (or obtain from) the symbol
table using install.
OK. That's R side.
OCaml side, I need to have as little side-effects as possible. Symbol
assign
On Dec 1, 2009, at 8:32 PM, Guillaume Yziquel wrote:
> Simon Urbanek a écrit :
>> You just pass it as value of the call. I suspect the reason it doesn't work
>> is in your code, not in the facility (note that the link above is useless
>> since the construction is mystery - if you were construct
Simon Urbanek a écrit :
You just pass it as value of the call. I suspect the reason it doesn't
work is in your code, not in the facility (note that the link above is
useless since the construction is mystery - if you were constructing it
right, it would work ;)).
Small example:
SEXP myEval
Guillaume Yziquel a écrit :
Guillaume Yziquel a écrit :
One last thing, concerning the use of promises. If I do install,
findVar, without forcing the resulting promise, and then construct the
call, I get a failure:
Replacing findfun by findvar works in this specific case. See below.
Could
Guillaume Yziquel a écrit :
One last thing, concerning the use of promises. If I do install,
findVar, without forcing the resulting promise, and then construct the
call, I get a failure:
# R.eval_langsxp (R.langsxp_of_list [(R.symbol "str"); (R.symbol
"lm")] 2);;
Erreur dans function (objec
Simon Urbanek a écrit :
On Nov 30, 2009, at 16:07 , Guillaume Yziquel wrote:
Simon Urbanek a écrit :
And it goes then to my other question: How can you pass to eval a
LANGSXP where the CAR is an *anonymous* function, no SYMSXP involved?
You just pass it as value of the call. I suspect the r
On Nov 30, 2009, at 16:07 , Guillaume Yziquel wrote:
Simon Urbanek a écrit :
And it goes then to my other question: How can you pass to eval a
LANGSXP where the CAR is an *anonymous* function, no SYMSXP
involved?
You just pass it as value of the call. I suspect the reason it
doesn't wor
Simon Urbanek a écrit :
And it goes then to my other question: How can you pass to eval a
LANGSXP where the CAR is an *anonymous* function, no SYMSXP involved?
You just pass it as value of the call. I suspect the reason it doesn't
work is in your code, not in the facility (note that the link
On Nov 30, 2009, at 13:14 , Guillaume Yziquel wrote:
Simon Urbanek a écrit :
Because I've been unable to find what exactly applyClosure or eval
requires, when it comes to the structure of the argument LANGSXP.
For example.
LANGSXP is simply a pairlist representing the expression, e.g. to
Simon Urbanek a écrit :
Because I've been unable to find what exactly applyClosure or eval
requires, when it comes to the structure of the argument LANGSXP. For
example.
LANGSXP is simply a pairlist representing the expression, e.g. to look
at "a+2" expression:
> .Internal(inspect(quot
On Nov 30, 2009, at 12:08 , Guillaume Yziquel wrote:
Simon Urbanek a écrit :
You're talking about two entirely different things -- bypassing the
API is a very bad idea, but it has nothing to do with your last
paragraph.
It's very good to hear that it's two different things. This has been
Simon Urbanek a écrit :
You're talking about two entirely different things -- bypassing the API
is a very bad idea, but it has nothing to do with your last paragraph.
It's very good to hear that it's two different things. This has been
quite unclear to me.
The API gives you access all use
Guillaume,
On Nov 29, 2009, at 13:57 , Guillaume Yziquel wrote:
Simon Urbanek a écrit :
On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote:
FWIW what I think you should be really looking at is
R_PreserveObject/R_ReleaseObject.
OK. Thanks.
I would suggest looking at the many other R embe
Simon Urbanek a écrit :
On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote:
FWIW what I think you should be really looking at is
R_PreserveObject/R_ReleaseObject.
OK. Thanks.
I would suggest looking at the many other R embeddings in other languages that
already exist since I don't think
On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote:
> Whit Armstrong a écrit :
>> I've had success w/ using a reference counting paradigm in which the outside
>> memory manager calls UNPROTECT_PTR(R_object_); in its destructor.
>> So, in my case (using c++ ) if objects are allocated on the heap
Whit Armstrong a écrit :
I've had success w/ using a reference counting paradigm in which the outside
memory manager calls UNPROTECT_PTR(R_object_); in its destructor.
So, in my case (using c++ ) if objects are allocated on the heap, which
allocate R objects as their backend storage, I don't hav
I've had success w/ using a reference counting paradigm in which the outside
memory manager calls UNPROTECT_PTR(R_object_); in its destructor.
So, in my case (using c++ ) if objects are allocated on the heap, which
allocate R objects as their backend storage, I don't have to worry about out
of ord
Hello.
In the writing of my OCaml-R binding, I'm sort of confused when it comes
to the use of the PROTECT and UNPROTECT macros.
Basically, I have C stub functions that are in charge of calling R for
everything. Here's a simple example:
CAMLprim value r_findvar (value symbol) {
/* The fin
21 matches
Mail list logo