2017-07-31 13:26 GMT+02:00 Dirk Eddelbuettel :
> The _type_ is in Rcpp proper, so maybe RcppXPtrHelpers, or RcppXPtrWrappers,
> or just RcppXPtrUtils?
Here we go, comments and PRs welcome: https://github.com/Enchufa2/RcppXPtrUtils
Apart from adding tests, I was thinking about defining a wrapper f
On 31 July 2017 at 10:57, Iñaki Úcar wrote:
| Ok then, I'll sketch out a new package. May I use the name "RcppXPtr"?
Sure, could do.
The _type_ is in Rcpp proper, so maybe RcppXPtrHelpers, or RcppXPtrWrappers,
or just RcppXPtrUtils?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...
2017-07-31 1:29 GMT+02:00 Dirk Eddelbuettel :
>
> This might be most suitable for an add-on package, at least until all bugs
> are ironed out. The use case and scope is more limited than for
> cppFunction().
Agree. In fact, I can prepend the getter's declaration and append the
definition, so tha
On 30 July 2017 at 19:49, Iñaki Úcar wrote:
| 2017-07-30 14:15 GMT+02:00 Dirk Eddelbuettel :
| >
| > On 30 July 2017 at 02:38, Iñaki Úcar wrote:
| > | One last question: would you consider adding a cppXPtr() function to
| > | Rcpp? It would work as cppFunction(), but it would return a XPtr
| > | i
http://www.keittlab.org/
On Sat, Jul 29, 2017 at 8:00 AM, Iñaki Úcar wrote:
> 2017-07-29 13:58 GMT+02:00 JJ Allaire :
> > The best you can do is to get the pointer to the function (not sure if
> that
> > does what you are hoping for):
> >
> > func <- Rcpp::cppFunction("int foo() { return 1; }")
2017-07-30 14:15 GMT+02:00 Dirk Eddelbuettel :
>
> On 30 July 2017 at 02:38, Iñaki Úcar wrote:
> | One last question: would you consider adding a cppXPtr() function to
> | Rcpp? It would work as cppFunction(), but it would return a XPtr
> | instead of the function. I have a working example if you a
On 30 July 2017 at 02:38, Iñaki Úcar wrote:
| One last question: would you consider adding a cppXPtr() function to
| Rcpp? It would work as cppFunction(), but it would return a XPtr
| instead of the function. I have a working example if you are
| interested.
"Possibly" -- API and functionality ex
One last question: would you consider adding a cppXPtr() function to
Rcpp? It would work as cppFunction(), but it would return a XPtr
instead of the function. I have a working example if you are
interested.
Iñaki
___
Rcpp-devel mailing list
Rcpp-devel@li
2017-07-29 16:15 GMT+02:00 Dirk Eddelbuettel :
>
> On 29 July 2017 at 15:48, Iñaki Úcar wrote:
> | Yes, I am, and I think that my use case is slightly different. My
> | understanding is, correct me if I'm wrong, that RcppDE implements some
> | C++ functions and the user is able to choose which one
On 29 July 2017 at 15:48, Iñaki Úcar wrote:
| Yes, I am, and I think that my use case is slightly different. My
| understanding is, correct me if I'm wrong, that RcppDE implements some
| C++ functions and the user is able to choose which one the backend
| should use via its name. In my case, the u
2017-07-29 15:02 GMT+02:00 Sokol Serguei :
> Jj Allaire has written at Sat, 29 Jul 2017 07:58:13 -0400
>
> The best you can do is to get the pointer to the function (not sure if that
> does what you are hoping for):
>
> func <- Rcpp::cppFunction("int foo() { return 1; }")
>
>> body(func)
> .Primit
On 29 July 2017 at 15:00, Iñaki Úcar wrote:
| With our simulator, simmer, we are able to generate arrivals, entities
| that execute a given set of activities. One of these activities could
| be, let's say, a delay. A user can provide this delay as a fixed
| parameter to the C++ core, but also as a
Jj Allaire has written at Sat, 29 Jul 2017 07:58:13 -0400
The best you can do is to get the pointer to the function (not sure if
that does what you are hoping for):
func <- Rcpp::cppFunction("int foo() { return 1; }")
> body(func)
.Primitive(".Call")()
And to narrow even more:
> Rcpp::cppFun
2017-07-29 13:58 GMT+02:00 JJ Allaire :
> The best you can do is to get the pointer to the function (not sure if that
> does what you are hoping for):
>
> func <- Rcpp::cppFunction("int foo() { return 1; }")
>
>> body(func)
> .Primitive(".Call")()
I don't think so. Let me explain the motivation be
The best you can do is to get the pointer to the function (not sure if that
does what you are hoping for):
func <- Rcpp::cppFunction("int foo() { return 1; }")
> body(func)
.Primitive(".Call")()
On Fri, Jul 28, 2017 at 8:00 PM, Iñaki Úcar wrote:
> 2017-07-29 0:29 GMT+02:00 Dirk Eddelbuettel :
2017-07-29 0:29 GMT+02:00 Dirk Eddelbuettel :
>
> On 28 July 2017 at 19:14, Iñaki Úcar wrote:
> | Hi all,
> |
> | I found this interesting thread by Davor Cubranic in which Romain came
> | up with a solution for calling a C routine from the 'stats' package:
> |
> http://lists.r-forge.r-project.org
On 28 July 2017 at 19:14, Iñaki Úcar wrote:
| Hi all,
|
| I found this interesting thread by Davor Cubranic in which Romain came
| up with a solution for calling a C routine from the 'stats' package:
| http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2010-June/000753.html
|
| In a nutshel
Hi all,
I found this interesting thread by Davor Cubranic in which Romain came
up with a solution for calling a C routine from the 'stats' package:
http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2010-June/000753.html
In a nutshell, I would like to do the same, but with a user-provided
fu
Luckily, the functionality was all contained in two files. I just copied
those from R source into my package, removed the NativeSymbolInfo trick
from my code, and everything worked fine. The licenses are both GPL, so
it's OK in that respect.
Davor
On 12-10-07 01:59 PM, Dirk Eddelbuettel wrot
On 7 October 2012 at 13:40, Davor Cubranic wrote:
| Just a heads up that the hack to convert NativeSymbolInfo of an object
| in one package to a function pointer that is called from another (in my
| case, calling "loess_raw" in stats from rgam), is not allowed any more
| in development versions
Just a heads up that the hack to convert NativeSymbolInfo of an object
in one package to a function pointer that is called from another (in my
case, calling "loess_raw" in stats from rgam), is not allowed any more
in development versions of R and will cause a crash.
Davor
On 10-06-10 03:28 P
On 2010-06-08, at 10:46 PM, Romain Francois wrote:
>>> Reading the information on writing R extensions, it sounds like there
>>> may not be a way to get to the address of an object in another
>>> package's DLL. (In this case, in stats.so.) However, there is a
>>> NativeSymbolInfo for stats:::R_loe
On 2010-06-09, at 12:03 PM, Dirk Eddelbuettel wrote:
> ... at a fundamental level, I am not yet sure that 'poking through' an api
> that R Core has sealed is the right idea.
>
> My hunch is that I would just take the code to loess_raw and stick it into a
> small utility package so that one coul
Hi all,
That's a great question by Davor. Like many other people, I am also a fan of
loess (for the concrete example). But ...
On 9 June 2010 at 07:46, Romain Francois wrote:
| Le 09/06/10 07:14, Romain Francois a écrit :
| > Le 09/06/10 03:04, Davor Cubranic a écrit :
| >> There are some C rout
Le 09/06/10 07:14, Romain Francois a écrit :
Le 09/06/10 03:04, Davor Cubranic a écrit :
Hi there,
I have a question about the murky world of R internals, DLLs, and
their interaction with Rcpp.
There are some C routines in the 'stats' package that I would like to
call directly from my Rcpp-b
Le 09/06/10 03:04, Davor Cubranic a écrit :
Hi there,
I have a question about the murky world of R internals, DLLs, and their
interaction with Rcpp.
There are some C routines in the 'stats' package that I would like to call
directly from my Rcpp-based package, e.g., loess_raw. However, 'stat
Hi there,
I have a question about the murky world of R internals, DLLs, and their
interaction with Rcpp.
There are some C routines in the 'stats' package that I would like to call
directly from my Rcpp-based package, e.g., loess_raw. However, 'stats' only
exposes them to R callers, not C or C+
27 matches
Mail list logo
