Re: [Rd] Creating a Windows import lib from R.dll (x64)?
On 10/18/2010 10:00 PM, Dominick Samperi wrote: > > The procedure for creating an import library (Rdll.lib) that is documented > in gnuwin32/README.packages works fine using the i386 architecture, but > it doesn't seem to work under x64. > > Specifically, the procedure is: > pexports R.dll > R.exp > lib /def:R.exp /out:Rdll.lib /machine:X86 R.dll > > There are two issues under x64: > 1. Older version of pexports crash when applied to an x64 R.dll. > The work-around is to use one of the newer versions that have > been fixed (pexports-9.44, say). > 2. When lib is applied to an x64 R.dll it complains as follows: > R.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x318 > > This happens even when the /def:R.exp parameter is left out, for > example, with lib /out:Rdll.lib R.dll. > > Any tips would be much appreciated. I successfully did the following recently in order to build 64 bit PL/R on Windows 7: dumpbin /exports R.dll > R.dump.csv Note that I used the csv extension so OpenOffice would import the file into a spreadsheet conveniently. Edit R.dump.csv to produce a one column file of symbols called R.def. Add the following two lines to the top of the file: LIBRARY R EXPORTS Then run the following using R.def lib /def:R.def /out:R.lib HTH, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support signature.asc Description: OpenPGP digital signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] clients and carriage returns
I've recently ported PL/R (R embedded in Postgres as a procedural language) to work on Win32 -- thank you to all involved for making the embedded interface common between *nix and Win32! This of course means users are now creating PL/R functions using Win32 based editors, which are using \r\n for EOL. I had not realized this before, but R throws a parse error when it sees \r, even on a Win32 OS. Near as I can tell browsing R source, this is true on all operating systems -- e.g. gram.y seems to look only for \n, and in src/gnuwin32/graphapp/events.c:handle_char(), \r is actively replaced with \n. I didn't find any specific mention of EOL/newline in "Writing R Extensions", and only reference to related escape sequences in "R Language Definition". My questions: - Is it safe (and indeed proper) for PL/R to always convert \r\n to \n prior to invoking the R parser? - Should the same be done for \r to \n (e.g. on OS X)? - Any other considerations I should care for? Thanks, Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] clients and carriage returns
Prof Brian Ripley wrote:
> I think the question is how are you accessing the parser? The only
> public interface is R_ParseVector, and that works like parse(text=):
Yes, I'm using R_ParseVector. PL/R basically takes the function's text
as stored in the Postgres system catalog table (prosrc field of
pg_catalog.pg_proc), and feeds it to R_ParseVector more-or-less
unchanged (currently).
> This does not happen when reading from files, as the connection
> machinery converts line endings (or fgets does). So I think the problem
> may be in how you (or PostgreSQL) are getting text from files.
That makes sense. Many people use a database client such as PgAdmin III
to create PL/R (and other) functions. PgAdmin adds standard Win32 EOLs
to multiline CREATE FUNCTION statements, and Postgres dutifully stores
them with the rest of the text in the catalog, exactly as received.
> The rules of R syntax are quite simple, e.g.
>
> Newlines have a function which is a combination of token separator and
> expression terminator. If an expression can terminate at the end of
> the line the parser will assume it does so, otherwise the newline is
> treated as whitespace. Semicolons (@samp{;}) may be used to separate
> elementary expressions on the same line.
I saw this paragraph, but it failed to register (through my thick skull)
that Newline is quite literally \n. Thanks for pointing it out.
Best regards,
Joe
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with findFun call from embedded R
I was debugging a problem reported to me regarding PL/R, and found that
I can duplicate it using only R sources. It might be characterized as
possibly a misuse of the findFun() function, but I leave that for the R
devel experts to decide.
The below results are all with R-2.5.1 (I can't seem to download
r-patched at the moment, but didn't see anything in the 2.5.1-patched
release notes indicating this issue had been noticed) on Fedora Core 6
x86_64 (also duplicated with R-2.5.0 on FC7 i386).
Steps to reproduce:
8<
configure, make, make install from source tree
cd tests/Embedding/
make RNamedCall
./RNamedCall #works as expected
mv foo.R foo.R.orig
./RNamedCall #segfaults
8<
output:
8<
Error in file(file, "r", encoding = encoding) :
unable to open connection
In addition: Warning message:
cannot open file 'foo.R', reason 'No such file or directory' in:
file(file, "r", encoding = encoding)
Error: could not find function "foo"
*** caught segfault ***
address (nil), cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
8<
The problem comes from RNamedCall starting at line 54:
8<
fun = findFun(install("foo"), R_GlobalEnv);
if(fun == R_NilValue) {
fprintf(stderr, "No definition for function foo.
Source foo.R and save the session.\n");
UNPROTECT(1);
exit(1);
}
8<
If foo.R was not found and never sourced, meaning that the object "foo"
does not exist, findFun never returns. Instead the segfault occurs at
line 719 in errors.c at the LONGJMP statement. Setting a breakpoint at
erros.c:719, the backtrace looks like this (will wrap poorly):
8<
Breakpoint 2, jump_to_top_ex (traceback=TRUE, tryUserHandler=TRUE,
processWarnings=TRUE, resetConsole=TRUE,
ignoreRestartContexts=FALSE) at errors.c:719
719 LONGJMP(R_ToplevelContext->cjmpbuf, 0);
(gdb) bt
#0 jump_to_top_ex (traceback=TRUE, tryUserHandler=TRUE,
processWarnings=TRUE, resetConsole=TRUE,
ignoreRestartContexts=FALSE) at errors.c:719
#1 0x2ab77e5d in verrorcall_dflt (call=0x609d78,
format=0x2ace4a4d "%s", ap=0x7fffa13a94c0)
at errors.c:516
#2 0x2ab7814a in Rf_errorcall (call=0x609d78,
format=0x2ace4a4d "%s") at errors.c:551
#3 0x2ab78347 in Rf_error (format=0x2ace42da "could not
find function \"%s\"") at errors.c:578
#4 0x2ab708e5 in Rf_findFun (symbol=0xc64f20, rho=0x649fa0) at
envir.c:1244
#5 0x00400e0c in bar1 () at RNamedCall.c:54
#6 0x00400d59 in main (argc=1, argv=0x7fffa13ab838) at
RNamedCall.c:16
8<
And then stepping into line 719 generates the segfault:
8<
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x2ab701ce in Rf_findVar (symbol=0x6c12b8, rho=0x0) at envir.c:998
998 if (TYPEOF(rho) == NILSXP)
8<
I believe this is happening because findFun() was not executed inside a
valid context, and therefore R_ToplevelContext->cjmpbuf is invalid.
My question is -- is the above an abuse of findFun() by RNamedCall.c
(meaning I should avoid the same pattern)? Or maybe it should be wrapped
in something similar to R_ToplevelExec?
==
On a related note, I found during my PL/R debugging that the segfault
was causing the same console based, interactive, "*** caught segfault
***" logic to execute. I was able to confirm that R_Interactive was set
to TRUE in my PL/R session.
It seems that Rf_initEmbeddedR() sets R_Interactive to TRUE and depends
on the output of isatty() to change it to FALSE in Rf_initialize_R() if
there is no tty. Unfortunately, the most common methods for starting
Postgres leave the tty attached (stdout and stderr are directed to the
log file). I ended up explicitly writing "R_Interactive = FALSE" just
after running Rf_initEmbeddedR() -- is this a safe and reasonable thing
to do?
Thanks,
Joe
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with findFun call from embedded R
Byron Ellis wrote: > Yeah, setting R_Interactive is probably fine. Great -- thanks for the confirmation. > As to the findFun issue, > there is a much more useful function (findVar1 maybe?) that wouldn't > die if the object didn't exist. OK, I'll poke around R sources some more. The function provided by Jeffrey Horner on a nearby post seems to work well too. Thanks, Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with findFun call from embedded R
Joe Conway wrote:
Yes, if I patch RNamedCall.c with the attached (based on your function),
everything seems to work.
Sorry -- I managed to mess up that patch. This one should be better.
Joe
*** ../../../R-2.5.1/tests/Embedding/RNamedCall.c Mon Sep 4 07:21:12 2006
--- RNamedCall.c Fri Jul 6 10:19:46 2007
***
*** 2,7
--- 2,9
void bar1() ;
void source(const char *name);
+ static SEXP MyfindFun(SEXP symb, SEXP envir);
+
/*
Creates and evaluates a call
to a function giving named arguments
***
*** 51,58
SEXP e;
PROTECT(e = allocVector(LANGSXP, 4));
! fun = findFun(install("foo"), R_GlobalEnv);
! if(fun == R_NilValue) {
fprintf(stderr, "No definition for function foo. Source foo.R and save the session.\n");
UNPROTECT(1);
exit(1);
--- 53,60
SEXP e;
PROTECT(e = allocVector(LANGSXP, 4));
! fun = MyfindFun(install("foo"), R_GlobalEnv);
! if(fun == R_UnboundValue) {
fprintf(stderr, "No definition for function foo. Source foo.R and save the session.\n");
UNPROTECT(1);
exit(1);
***
*** 80,82
--- 82,104
UNPROTECT(1);
}
+ static SEXP
+ MyfindFun(SEXP symb, SEXP envir)
+ {
+ SEXP fun;
+ SEXPTYPE t;
+ fun = findVar(symb,envir);
+ t = TYPEOF(fun);
+
+ /* eval promise if need be */
+ if (t == PROMSXP){
+ int error=1;
+ fun = R_tryEval(fun,envir,&error);
+ if (error) return R_UnboundValue;
+ t = TYPEOF(fun);
+ }
+
+ if (t == CLOSXP || t == BUILTINSXP || t == BUILTINSXP || t == SPECIALSXP)
+ return fun;
+ return R_UnboundValue;
+ }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with findFun call from embedded R
Jeffrey Horner wrote:
Joe Conway wrote:
I was debugging a problem reported to me regarding PL/R, and found
that I can duplicate it using only R sources. It might be
characterized as possibly a misuse of the findFun() function, but I
leave that for the R devel experts to decide.
My question is -- is the above an abuse of findFun() by RNamedCall.c
(meaning I should avoid the same pattern)? Or maybe it should be
wrapped in something similar to R_ToplevelExec?
Yes, when one embeds R, findFun() will call error() which causes the
longjmp() to the top level, so the embedding application shouldn't use
findFun().
OK, thanks for the confirmation. I just wonder if RNamedCall.c ought to
be changed then...
Here's what I've written for the next version of RApache. Note that
it's behavior is slightly different than the original findFun(), in that
it doesn't search the enclosing environments. (Also, comments welcome as
the implementation is based on the original, and I'm unsure if promise
evaluation is needed.)
/* This one doesn't longjmp when function not found */
static SEXP MyfindFun(SEXP symb, SEXP envir){
Yes, if I patch RNamedCall.c with the attached (based on your function),
everything seems to work.
Thanks,
Joe
*** ../../../R-2.5.1/tests/Embedding/RNamedCall.c Fri Jul 6 10:28:18 2007
--- RNamedCall.c Fri Jul 6 10:19:46 2007
***
*** 2,8
void bar1() ;
void source(const char *name);
! SEXP MyfindFun(SEXP symb, SEXP envir);
/*
Creates and evaluates a call
--- 2,8
void bar1() ;
void source(const char *name);
! static SEXP MyfindFun(SEXP symb, SEXP envir);
/*
Creates and evaluates a call
***
*** 82,88
UNPROTECT(1);
}
! SEXP
MyfindFun(SEXP symb, SEXP envir)
{
SEXP fun;
--- 82,88
UNPROTECT(1);
}
! static SEXP
MyfindFun(SEXP symb, SEXP envir)
{
SEXP fun;
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Plr-general] R_CHAR + 21 (memory.c:2573) in crash report...
Jeff Hamann wrote: I've been using this code for months now, and added another column to the type definition, which seemed to break something. Undoubtedly the above has something to do with the problem, and I would guess the issue is in PL/R, not R. However, in order to get to the bottom of it I'll need a self contained minimal test case that will reproduce the crash (i.e. related table definitions, some sample data, PL/R function, and other functions that are dependencies, sample use of said function). If you want you can send it to me off list. In any case, please drop r-devel from the thread from this point forward (I only maintained the cross-post so they could see that I was responding). Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] external equiv to R_serialize()?
I'm trying to efficiently allow conversion of R objects to PostgreSQL bytea (raw binary) datatype within PL/R for persistent storage in Postgres tables. I have found R_serialize() which looks like what I need, -- e.g. R_serialize(object, NULL, FALSE, NULL) -- except that it is marked attribute_hidden. Is there some other externally available interface that I can use? Thanks, Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] external equiv to R_serialize()?
Prof Brian Ripley wrote: On Mon, 30 Mar 2009, Joe Conway wrote: I'm trying to efficiently allow conversion of R objects to PostgreSQL bytea (raw binary) datatype within PL/R for persistent storage in Postgres tables. I have found R_serialize() which looks like what I need, -- e.g. R_serialize(object, NULL, FALSE, NULL) -- except that it is marked attribute_hidden. Is there some other externally available interface that I can use? R_Serialize is in Rinternals.h. R_serialize is a wrapper using connections, and connections do not have a public API. OK, thanks. Do note the comments in ?serialize: 'persistent' storage of objects in an experimental format is somewhat contradictory. Good point -- I'll put a suitable warning in my documentation. The typical use case people describe is more of a "materialized view" than it is primary storage, so I think this is still very useful. Thank you for your response. Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] external equiv to R_serialize()?
Prof Brian Ripley wrote: On Mon, 30 Mar 2009, Joe Conway wrote: I'm trying to efficiently allow conversion of R objects to PostgreSQL bytea (raw binary) datatype within PL/R for persistent storage in Postgres tables. I have found R_serialize() which looks like what I need, -- e.g. R_serialize(object, NULL, FALSE, NULL) -- except that it is marked attribute_hidden. Is there some other externally available interface that I can use? R_Serialize is in Rinternals.h. R_serialize is a wrapper using connections, and connections do not have a public API. Sorry if I'm missing something, but it seems that although R_Serialize() is public, the support functions needed to use R_outpstream_t are not. So I'm back to my initial question -- is there an alternative public interface that I can use? Thanks, Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling PL/R against R.dll in Win32/MinGW
Mike Leahy wrote: > Hello list, > > I've been trying to get the PostgreSQL PL/R library to compile on > windows (http://www.joeconway.com/plr/). The author of this library > says the problem is likely because the distributed R.dll isn't > compiled as a shared dll. Is this the case? If so, is there any way > to compile it such that it is shared? If that's not the case, than > maybe someone on this list has a better understanding of the errors > I'm getting (below). Just to clarify, I based my comment on this thread: http://tolstoy.newcastle.edu.au/R/help/03a/1690.html which may no longer be true. I have made no specific attempt to make PL/R compile under Windows because I did not think it was supported. If R.dll can be used under Windows in the same manner as libR.so on Linux, I'd bee happy to hear about it. Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling PL/R against R.dll in Win32/MinGW
Mike Leahy wrote: > Ok...well I've been hacking around with the PL/R source a bit more, and > I found that that substituting 'Rf_initEmbeddedR' with 'InitDynload' > seemed to make code compile further - this was just a total guess based > on the functions that are listed in the R.dll with dependency-walker. > Now it appears that it's an issue compiling against postgres, rather > than R.dll (see below). Should I pursue this any further, or should I > accept that it just won't happen and give up for now? > > -DDLSUFFIX=\".dll\" -c -o plr.o plr.c > plr.c: In function `plr_init': > plr.c:288: warning: implicit declaration of function `InitDynload' > plr.c: In function `fetchArgNames': > plr.c:1366: warning: passing arg 7 of `deconstruct_array' from This looks like you're trying to compile with PostgreSQL cvs HEAD (8.2devel), correct? That won't work as I've not yet adjusted PL/R to handle NULL elements in arrays (which is brand new in HEAD). But this is is now off topic here... Getting back on topic, unless someone can tell us that R.dll or some other mechanism exposes the same API as the libR shared object, I'd have to say it is probably hopeless. Joe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
