[Rd] How to get DLL paths in a package?
I'm writing a package that I hope to make available on CRAN. The package interfaces to the FAME database via a .so file supplied by FAME, which should be loaded in the package .onLoad() function. Unfortunately, so far as I know, there is no standard location where this .so file can always be found. So I need to have some way for the package installer to indicate where the file can be found. Also, FAME needs stuff from either the Motif or LessTif library, so I have to make sure that one of them can be found via the LD_LIBRARY_PATH. (Just why FAME needs this stuff when there's no user interface involved is a question to be pondered for the ages.) So I need a way for the package installer to supply the locations of the FAME hli library (the .so file) and the location of the Motif/LessTif library directory. How should I do this? I'd rather not assume that either the installer or the package writer (me) know much about autoconf. Can I get away with a simple text file in the 'inst' directory, or will CRAN reject my package if I do it that way? Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mixed effects model and r-squared
Indermaur Lukas eawag.ch> writes: > > Heya > > I am fitting linear mixed effects model in R [snip] > > ts.model <- lme(LOG_FOC_MW ~ R_DN_SUM + ANIMAL + SEX+ YY, data = t.data, random = ~ 1 | ANIMAL, > correlation=corCAR1(0.2, form = ~1 | ANIMAL ), method='ML', na.action=na.omit)). > > Is there a possability to easly compute an R-square from the output of the model summary? > > I would appreciate any hint. > Best regards > > Lukas > You probably need to repost this on r-help instead of r-devel; it's not a "development" question. The other bad news for you is that I suspect it may be difficult to define r-squared uniquely for a mixed model. The resid() command will give you residuals, and you could take (1-resid()^2)/var(x) -- but how do you decide which var(x) to put in the denominator ... ? Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [EMAIL PROTECTED]: dyn.load and function calls without 'PACKAGE' argument
I sent this to r-help and then realized it should really go to r-devel.
--- Begin Message ---
I'm writing a package that interfaces to the FAME database, via a
library of compiled C routines accessible through a Linux .so file. My
.onLoad() function loads the .so like this:
dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
and after that I also load my own fame.so via
library.dynam("fame", package = "fame")
The code in fame.so uses functions found in libjchli.so, making the
'local = F' argument in dyn.load() necessary. But since Fame symbols
are found in libjchli.so, which is NOT part of my package, I can't, for
example, do this:
.C("cfmfin", status = integer(1), PACKAGE = "fame")
since the PACKAGE argument tells R to look only in fame.so for symbols.
Instead, I have to do it without specifying 'PACKAGE', i.e.,
.C("cfmfin", status = integer(1))
This works, but 'R CMD check' complains:
"Foreign function calls without 'PACKAGE' argument:"
followed by a list of the functions called from libjchli.so.
Is there a way to make R CMD check happy here?
Jeff
--- End Message ---
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pre-compilation and server-side parallel execution
Folks, My company operates a platform that distributes real-time financial data from exchanges to users. To extend our services I want to allow users to write and submit custom R scripts to our platform that operate on our streaming data to do real-time analysis. We have thousands of users deploying scripts and each script is evaluated repeatedly when certain conditions in the stream apply. For example, a script could compute the NASDAQ100 index value each time one of its 100 constituents trade. Scripts are typically small and execute quickly. Each script is registered once and then repeatedly evaluated with different parameters (possibly several times per second per script). In this context my biggest concern is scalability. The evaluation engine is a pure server-side component without display abilities. An R-script is invoked with parameters and whatever it returns is sent to the user. Ideally I'd need a C api to interact with the interpreter. I've looked at projects like R/Apache, RServe and RSJava for inspiration and came to the conclusion that all these projects work by forking multiple instances of the R-engine where each instance evaluates one script at a time. As our service must evaluate many different scripts concurrently (isolated from one another), I have the following concerns: 1. Spawning a pool of engine instances for massive parallel execution is expensive, but might work with lots of memory. 2. R's native C-api [http://cran.r-project.org/doc/manuals/R-exts.html#The-R-API] does not separate parsing from evaluation. When the same script is evaluated 10 times, it is also parsed 10 times. I'm mostly concerned about the second issue. Our scripts are registered once and continuously evaluated. I want to avoid parsing the same script again each time it is evaluated. Does the engine recognize previously parsed scripts (like oracle does for SQL queries)? I interested to hear your thoughts on my concerns and whether you think R would work in this architecture. kind regards, Erik van Zijst -- And on the seventh day, He exited from append mode. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dyn.load and function calls without 'PACKAGE' argument
I'm writing a package that interfaces to the FAME database, via a
library of compiled C routines accessible through a Linux .so file. My
.onLoad() function loads the .so like this:
dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
and after that I also load my own fame.so via
library.dynam("fame", package = "fame")
The code in fame.so uses functions found in libjchli.so, making the
'local = F' argument in dyn.load() necessary. But since Fame symbols
are found in libjchli.so, which is NOT part of my package, I can't, for
example, do this:
.C("cfmfin", status = integer(1), PACKAGE = "fame")
since the PACKAGE argument tells R to look only in fame.so for symbols.
Instead, I have to do it without specifying 'PACKAGE', i.e.,
.C("cfmfin", status = integer(1))
This works, but 'R CMD check' complains:
"Foreign function calls without 'PACKAGE' argument:"
followed by a list of the functions called from libjchli.so.
Is there a way to make R CMD check happy here?
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load and function calls without 'PACKAGE' argument
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> I'm writing a package that interfaces to the FAME database, via a
> library of compiled C routines accessible through a Linux .so file. My
> .onLoad() function loads the .so like this:
>
> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
>
> and after that I also load my own fame.so via
>
> library.dynam("fame", package = "fame")
>
> The code in fame.so uses functions found in libjchli.so, making the
> 'local = F' argument in dyn.load() necessary.
Well, that is one approach.
A more regular and in most senses "better" approach is to
have your fame.so link against libjchli.so when creating
the fame.so DLL/SO. Then you don't have to pollute the
global symbol table for the process with libjchli.so
and you can use the PACKAGE argument.
That said, the PACKAGE argument is not necessary if you use
a NAMESPACE file for the package.
Load the fame.so with useDynLib() in the NAMESPACE file
and not library.dynam()
And if you explicitly list the routines you want to use
in the useDynLib() call, you can refer to them as
.Call(foo, ...)
with no quotes, no PACKAGE and you will be able to handle
multiple versions and provide aliases for the routine names.
> But since Fame symbols
> are found in libjchli.so, which is NOT part of my package, I can't, for
> example, do this:
>
> .C("cfmfin", status = integer(1), PACKAGE = "fame")
>
> since the PACKAGE argument tells R to look only in fame.so for symbols.
> Instead, I have to do it without specifying 'PACKAGE', i.e.,
>
> .C("cfmfin", status = integer(1))
>
> This works, but 'R CMD check' complains:
>
> "Foreign function calls without 'PACKAGE' argument:"
>
> followed by a list of the functions called from libjchli.so.
>
> Is there a way to make R CMD check happy here?
>
> Jeff
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
- --
Duncan Temple Lang[EMAIL PROTECTED]
Department of Statistics work: (530) 752-4782
4210 Mathematical Sciences Building fax: (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFFeZ3E9p/Jzwa2QP4RAoJ5AJsFZAFVuvmoEWhKFWxmncbHTLtpgwCfT84w
eN2RaXPav1/8erL08urKxT0=
=NksI
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] empty pages in xyplot (2.4.0)
On 12/8/06, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
>
> In 2.4.0 (and SVN) I am seeing xyplot creating empty pages for high page
> counts in layout - contrary to the manual which says high page counts should
> not matter. Everything works fine in 2.3.1.
>
> library("lattice")
> A<-data.frame(x=1:10, y=sin(1:10), z=round(1:10/3))
> xyplot(x~y|z, A, layout=c(1,1,10))
>
> The snippet above produces a valid plot in R 2.3.1, while in 2.4.0 and later I
> see a blank page with "x" and "y" letters on it.
>
> Can anyone else reproduce this ?
Yes. I will update the manual (but probably not in 2.4.1 as this
doesn't seem very critical) and in the longer run, perhaps add some
settings to control what should happen.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] empty pages in xyplot (2.4.0)
In 2.4.0 (and SVN) I am seeing xyplot creating empty pages for high page
counts in layout - contrary to the manual which says high page counts should
not matter. Everything works fine in 2.3.1.
library("lattice")
A<-data.frame(x=1:10, y=sin(1:10), z=round(1:10/3))
xyplot(x~y|z, A, layout=c(1,1,10))
The snippet above produces a valid plot in R 2.3.1, while in 2.4.0 and later I
see a blank page with "x" and "y" letters on it.
Can anyone else reproduce this ?
thank you very much !
Vladimir Dergachev
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load and function calls without 'PACKAGE' argument
Duncan Temple Lang <[EMAIL PROTECTED]> wrote:
dtl> [EMAIL PROTECTED] wrote:
>> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
>> library.dynam("fame", package = "fame")
>> The code in fame.so uses functions found in libjchli.so, making the
>> 'local = F' argument in dyn.load() necessary.
dtl> Well, that is one approach.
dtl> A more regular and in most senses "better" approach is to
dtl> have your fame.so link against libjchli.so when creating
dtl> the fame.so DLL/SO. Then you don't have to pollute the
dtl> global symbol table for the process with libjchli.so
dtl> and you can use the PACKAGE argument.
Will that work? Some of the functions in libjchli.so get called
directly via .C(). How would linking fame.so against libjchli.so help
when fame.so doesn't know what functions in libjchli.so I am going to
call? Perhaps I don't understand how linking works. Please feel free to
enlighten me.
dtl> That said, the PACKAGE argument is not necessary if you use
dtl> a NAMESPACE file for the package.
dtl> Load the fame.so with useDynLib() in the NAMESPACE file
dtl> and not library.dynam()
As I understand it, useDynLib(fame) is actually a directive that results
in fame.so being loaded via library.dynam(). I am using a NAMESPACE, so
I will try your advice and thank you for it.
dtl> And if you explicitly list the routines you want to use
dtl> in the useDynLib() call, you can refer to them as
dtl> .Call(foo, ...)
dtl> with no quotes, no PACKAGE and you will be able to handle
dtl> multiple versions and provide aliases for the routine names.
What if I don't explicitly list the routines? Many of the routines are
only compiled in for Unix, not Windows. Is there a way to use a
different useDynLib() directive depending on the operating system?
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pre-compilation and server-side parallel execution
On Dec 8, 2006, at 9:51 AM, Erik van Zijst wrote: > 2. R's native C-api > [http://cran.r-project.org/doc/manuals/R-exts.html#The-R-API] does > not separate parsing from evaluation. Actually it does - see "R_ParseVector" and "eval". You're free to run the parser once (or even construct the expression directly) and evaluate it many times. (Also note that you can serialize the parsed expression if desired). If your worries are really at this level, then you will have to create entirely your own solution, because the overhead of IPC will be way more that the time spent in the parser. Actually I'm wondering whether you checked it at all, because I'd almost certainly expect the evaluation to take way more time than the parsing step. If it does, I'd be inclined to think that you have rather a design problem. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load and function calls without 'PACKAGE' argument
Jeff
You might look at the package padi (and also dsepadi) in the dseplus
bundle in the devel area of CRAN. This provides an R to Fame link, and I
have tried to do it in a generic way that can potentially interface to
other time series data bases. It also handles endian issues, if your
servers do not have the same architecture as the clients. Padi does not
link the Fame stuff directly into R. Instead, it links a client side rpc
program that talks to a server side that is linked to the Fame hli. This
means the client is independent of the server side database, which has
some advantages. Compiling is handled by a Makefile in the src directory
and the location of run time code is handled by environment variables.
It is a bit more complicated than this, because of the server and client
modes. You may actually want something simpler, but the packages builds
without errors (at least the client mode part of it). I have left it in
the devel area mainly because the documentation is incomplete.
The package is very stable. I have been using it for fifteen years
(first on Splus and now in R). It has a few shortcomings, but they are
not things I need much. There are lots of improvements I could suggest.
Paul Gilbert
[EMAIL PROTECTED] wrote:
> I'm writing a package that interfaces to the FAME database, via a
> library of compiled C routines accessible through a Linux .so file. My
> .onLoad() function loads the .so like this:
>
> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
>
> and after that I also load my own fame.so via
>
> library.dynam("fame", package = "fame")
>
> The code in fame.so uses functions found in libjchli.so, making the
> 'local = F' argument in dyn.load() necessary. But since Fame symbols
> are found in libjchli.so, which is NOT part of my package, I can't, for
> example, do this:
>
> .C("cfmfin", status = integer(1), PACKAGE = "fame")
>
> since the PACKAGE argument tells R to look only in fame.so for symbols.
> Instead, I have to do it without specifying 'PACKAGE', i.e.,
>
> .C("cfmfin", status = integer(1))
>
> This works, but 'R CMD check' complains:
>
> "Foreign function calls without 'PACKAGE' argument:"
>
> followed by a list of the functions called from libjchli.so.
>
> Is there a way to make R CMD check happy here?
>
> Jeff
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
