[Rd] rdyncall fears removal from CRAN
Dear R Core and CRAN Team, I received a warning that the rdyncall package [1] will be archived and removed from the main CRAN distribution at 7th of September if I can not get rid of .Internal calls. > From: rip...@stats.ox.ac.uk (Prof Brian Ripley) > Subject: Use of .Internal in CRAN package rdyncall > Date: August 14, 2012 11:09:06 AM GMT+02:00 > To: dad...@uni-goettingen.de > > R CMD check has been warning about the use of .Internal in packages > for several months now, in R-release since 2.15.0. We have decided > that it will not be allowed at all in the next release of R (not least > because the work on long vectors means we need to move > argument-checking code between internal code and the R wrapper). > > So can we please have a package update without .Internal calls by > September 7 (or the package will be archived). You should also check > the R-devel CRAN check pages at > http://cran.r-project.org/web/checks/check_results_.html (replace > by the name of your package) for any other issues that need to > be addressed. The use of .Internal in rdyncall was due to a missing interface for namespace object management. Since the main task of this package is to offer an alternative FFI *AND* a catalog of ready-to-use bindings to popular C libraries (across platforms) and interface for attach/remove of namespace objects was required. The current implementation uses a small snippet of code "makeNamespace" from src/library/base/R/namespace.R and we have to make a call to .Internal(registerNamespace). A request was made on the mailing list in the past: https://stat.ethz.ch/pipermail/r-devel/2011-December/062839.html Since the deadline is very soon, I emphasize and repeat my request for an R programming interface to namespace objects and I please you for advices to go about this issue. Are there any other plans for opening the interface to namespace management? The namespace creation function 'makeNamespace' is currently defined in a local scope to another function making it not accessible from the outside. 'registerNamespace' is a functionality only available via '.Internal'. So what is 'good pratice' for opening access to this - another wrapper in 'base' that calls '.Internal' ? It would be very sad if rdyncall is dropped from CRAN since more and more package authors are using it for different applications. For those that need more detail, there is an article on R Journal (http://journal.r-project.org/archive/2012-1/RJournal_2012-1_Adler.pdf) Any help, comment and advice is very appreciated. Thank you - Daniel Begin forwarded message: > > > The CRAN team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rdyncall fears removal from CRAN
On Mon, Aug 20, 2012 at 4:05 AM, Daniel Adler wrote: > Dear R Core and CRAN Team, > > I received a warning that the rdyncall package [1] will be archived and > removed from the main CRAN distribution at 7th of September > if I can not get rid of .Internal calls. > >> From: rip...@stats.ox.ac.uk (Prof Brian Ripley) >> Subject: Use of .Internal in CRAN package rdyncall >> Date: August 14, 2012 11:09:06 AM GMT+02:00 >> To: dad...@uni-goettingen.de >> >> R CMD check has been warning about the use of .Internal in packages >> for several months now, in R-release since 2.15.0. We have decided >> that it will not be allowed at all in the next release of R (not least >> because the work on long vectors means we need to move >> argument-checking code between internal code and the R wrapper). >> >> So can we please have a package update without .Internal calls by >> September 7 (or the package will be archived). You should also check >> the R-devel CRAN check pages at >> http://cran.r-project.org/web/checks/check_results_.html (replace >> by the name of your package) for any other issues that need to >> be addressed. > > > The use of .Internal in rdyncall was due to a missing interface for namespace > object management. > Since the main task of this package is to offer an alternative FFI *AND* a > catalog of ready-to-use bindings to > popular C libraries (across platforms) and interface for attach/remove of > namespace objects was required. > The current implementation uses a small snippet of code "makeNamespace" from > src/library/base/R/namespace.R and we have to make a > call to .Internal(registerNamespace). > > A request was made on the mailing list in the past: > > https://stat.ethz.ch/pipermail/r-devel/2011-December/062839.html > > Since the deadline is very soon, I emphasize and repeat my request for an R > programming interface to namespace objects > and I please you for advices to go about this issue. > > Are there any other plans for opening the interface to namespace management? > > The namespace creation function 'makeNamespace' is currently defined in a > local scope to another function > making it not accessible from the outside. > 'registerNamespace' is a functionality only available via '.Internal'. > So what is 'good pratice' for opening access to this - another wrapper in > 'base' that calls '.Internal' ? > > It would be very sad if rdyncall is dropped from CRAN since more and more > package authors are using it for different applications. > For those that need more detail, there is an article on R Journal > (http://journal.r-project.org/archive/2012-1/RJournal_2012-1_Adler.pdf) > > Any help, comment and advice is very appreciated. > > Thank you > - Daniel > This is also very relevant for devtools. There have been some recent changes to the in-development version of devtools, so that it loads development packages into a namespace. Previously, it didn't use namespaces, but now that it does, it much more closely approximates normal package loading behavior. It now uses the internal functions registerNamespace and unregisterNamespace. Is there a workaround to do these things without using the internal functions? -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rdyncall fears removal from CRAN
> This is also very relevant for devtools. There have been some recent > changes to the in-development version of devtools, so that it loads > development packages into a namespace. Previously, it didn't use > namespaces, but now that it does, it much more closely approximates > normal package loading behavior. > > It now uses the internal functions registerNamespace and > unregisterNamespace. Is there a workaround to do these things without > using the internal functions? We're very aware that using these internal functions ties us to a specific version of R, and that they may change at any point in the future and break our code. That's an acceptable trade-off - using these internal functions gives us capabilities that makes fixing the code in the future worthwhile. A minimal change to R that would satisfy our needs (and I suspect Daniel's) would be to move makeNamespace into the base package (i.e. up out of the function it is currently contained in), and to create R wrapper functions for registerNamespace and unregisterNamespace. They wouldn't even need to be exported - we know what we're doing is dangerous. If that solution isn't acceptable, we'd also be very happy to work with any R-core member to help develop a public facing API for namespace manipulation, including providing tests for common use cases. Please let us know what we can do to help! Hadley -- Assistant Professor Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with initializiing R main loop under Windows (R.dll-version: 2.15.1)
Dear R-developers,
even though I may not be the first one to encounter the problem
described below, I would really appreciate some help or a link to a
forum where this topic is being discussed. Probably I am simply
misinformed on the usage of structRstart but see for youselve.
I did check multiple forums and the whole internet on the topic without
success.
I am using the shared library version of R under Windows and my
application is intended to provide a two-way interaction with R.
The code snippet, I use to initialize and start the repl is:
void RServer::run()
{
// If we have no GUI frontend running, don't init the R-server
if (!connectToGui()) return;
// set the start time
R_setStartTime();
// Definel callback handler struct
structRstart RParams;
R_DefParams (&RParams);
RParams.R_Quiet= FALSE; //
RParams.R_Interactive = TRUE;
RParams.R_Verbose = FALSE;
RParams.R_Slave= FALSE;
RParams.RestoreAction = SA_RESTORE;
RParams.SaveAction = SA_NOSAVE;
RParams.rhome = get_R_HOME ();
RParams.home = getRUser ();
RParams.CharacterMode = LinkDLL; // RGui;
RParams.ShowMessage= RShowMessage;
RParams.ReadConsole= RReadConsoleWin;
RParams.WriteConsoleEx = RWriteConsoleEx;
RParams.WriteConsole = 0;
RParams.CallBack = RDoProcessEvents;
RParams.YesNoCancel= RAskYesNoCancel;
RParams.Busy = RBusy;
// Install own handlers
R_SetParams(&RParams);
// flush the console input buffer
// call to WINAPI: clears all that's in stdin
FlushConsoleInputBuffer(GetStdHandle(STD_INPUT_HANDLE));
// Fake a command line
int argc = 2;
char* argv[2] = { qstrdup ("--no-save"), qstrdup
("--no-restore") };
// redirect the BREAK signal to own handler
signal(SIGBREAK, pi_onintr);
// set the arguments in R
R_set_command_line_arguments (argc, argv);
// Here, the main initialization of R is performed
setup_Rmainloop ();
// Init the IO buffer and the global context
R_ReplDLLinit();
// if I use the following instead, no problem occurs on error
in evaluation:
// run_Rmainloop ();
while ((_state== Connected || _state == Running) &&
R_ReplDLLdo1() > 0) {
Pi::msleep(5); // to keep the processor cool
};
// Usually we don't get here on q()
R_RunExitFinalizers();
Rf_KillAllDevices();
}
This, however is mostly adapted from 'writing R extensions'.
Nonetheless, this way I receive an abnormal program termination whenever
an error occurs in the evaluation of code returned from
'RReadConsoleWin'. I'm pretty sure that there is no problem in my code,
since, if I use 'run_Rmainloop ()' instead, everyting works fine but I
have no control on the exit of the program. This implies that my program
would not be able to do proper clean up at end.
I would really appreciate some help here.
Yours sincerely,
Peter
--
Institute of Earth and Environmental Sciences, University of Potsdam
Karl-Liebknecht-Str. 24/25 (House 12), 14476 Potsdam, Germany
office: +49 331 977 2469
mobile: +49 173 3732867
e-mail: peter.vorp...@uni-potsdam.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
