roduce 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 Ope
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, -
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, -
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_
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
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
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
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 prov
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
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 fiel
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 f
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 dependenc
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
13 matches
Mail list logo
