Re: [Rd] Telling Windows how to find DLL's from R?
Dominick,
Dominick Samperi wrote:
> On Fri, Jul 9, 2010 at 3:48 PM, Duncan Murdoch
> wrote:
>
>> On 09/07/2010 2:38 PM, Dominick Samperi wrote:
>>
>>> Is it possible to set Windows' search path from within R, or to tell
>>> Windows how to find a DLL in some other way from R? Specifically, if
>>> a package DLL depends on another DLL the normal requirement is that
>>> the second DLL be in the search path so Windows can find it (there
>>> are other tricks, but they apply at the Windows level, not at the R
>>> level).
>>>
>>>
>>
>>
>> I haven't tried this, but can't you use Sys.setenv() to change the
>> PATH to what you want? Presumably you'll want to change it back
>> afterwards.
>>
>
> Thanks, good suggestion, but it does not seem to work. If PATH is
> updated in this way the change is local to the current process, not to
> the top-level Windows process, so a subsequent
> dyn.load('foo.dll') will fail if foo.dll depends on bar.dll, unless
> bar.dll is placed in the search path for the top-level shell. Seems
> like this needs to be done as part of system startup outside of R.
>
> On the other hand, if foo.dll is the package library for package foo,
> and if foo depends on package bar, then there is no need to place
> bar.dll in the top-level search path. R takes care of this (more
> typical) situation.
there is another Windows "feature" which will do the trick for you without
modifying the search path. Windows normally only loads DLLs once, so this
means if you first load the dependent DLL (manually, e.g. using dyn.load())
then the already loaded DLL will be used instead of trying to load one from
path.
E.g. in your example:
dyn.load("mypath/bar.dll")
dyn.load("foo.dll")
will work, as bar.dll (a dependency of foo.dll) is already loaded.
Thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommendations for a quick UI.
Alex, Kevin R. Coombes wrote: > The following idea only partially answers your question > > I have successfully written a GUI using the tcl/tk package > that ships with standard R. It is then possible (in Windows) > to create a shortcut icon that runs the following command: > C:\R\R-2.8.1\bin\R.exe --vanilla -e > library(SuperCurveGUI);sc(); Note two features: > [1] the first part of the -e switch loads the library > containing the GUI [2] the second part (after the semicolon) launches > the GUI > > If you make a "normal" shortcut this way, a batch window will > open showing the ongoing R session, which is not quite what you want. > However, if you adjust the shortcut to "Run: Minimized", then > (most) users will never see the batch window, and will only > see the GUI. > > The reasons that this only partially answers your question > are [1] It is Windows-specific [2] I do not know how to set > up the shortcut automatically upon installation. depending on how deep you want to dig into programming (aside from R), you could use any COM client (on Windows), e.g., Visual Basic, C# using statconnDCOM (just download and install the package rcom) or using Java (RServe) Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-code embedded in VBE -- Type mismatch errors
Pietro, [EMAIL PROTECTED] wrote: > Hello, > > I am trying to embed R-code inside VB for Excel (probably a perverse > endeavour anyway) and I am running into difficulties, especially when > passing vectors back and forth between the two environments. > > (1) I am using the RExcel package. There is a mailing list for RExcel where this should be discussed. Please re-post your message to rcom-l. Please be sure to browse the list archives first. Have a look at the RExcel documentation for sources of information. Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] LinkingTo on Windows
Dear List, R packages may specify a "LinkingTo" attribute to specify dependencies to the source code (mainly the header files) of other packages. Unfortunately, it is not possible to also have a reference to the generated library (.dll on Windows) of the other package. So including a header file from another package to call an (exported) function will just not help. I've tried to implement a workaround for my package rcom (depending on exported functions from rscproxy) by "manually" setting the library when linking, but unfortunately this does not work for me, when rscproxy gets installed into a different library (not the default one). OK, I could set the library path relative to the source drive and absolute for the standard library, so the "R CMD check" on CRAN is passed, but I don't think this would be a good solution. Of course, I could implement true dynamic binding by getting a handle to the rscproxy.dll (which already has been loaded at the time of loading rcom) and getting out procedure addresses, but I don't think this is a good (general and portable) solution either. How can this issue be addressed? How can I solve the problem of linking to another package's library (if possible by just using "LinkingTo") Best regards, Thomas Baier __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
Simon Urbanek wrote:
> FWIW: technically, you don't have to match the patch level version.
> Although default DLL checks usually require perfect match, it should
> be safe to require that R version lies in [x.y.z, x.y+1.0) where
> x.y.z is the R version that the interfacing DLL was compiled against.
> (And hence it is safe to use R x.y.0 as the base for compilation until
> R x.y+1.0 is released).
The check that has been implemented works as:
snprintf(Rversion, 25, "%s.%s", R_MAJOR, R_MINOR);
if(strncmp(getDLLVersion(), Rversion, 25) != 0) {
... check failed
}
... check ok
Quoting from http://cran.r-project.org/doc/manuals/R-exts.html
int main (int argc, char **argv)
{
structRstart rp;
Rstart Rp = &rp;
char Rversion[25], *RHome;
sprintf(Rversion, "%s.%s", R_MAJOR, R_MINOR);
if(strcmp(getDLLVersion(), Rversion) != 0) {
fprintf(stderr, "Error: R.DLL version does not match\n");
exit(1);
}
...
this looks very similar. According to your message, full binary
compatibility is given for same R (major.minor) versions, e.g. 2.8.0 is
fully compatible with 2.8.1, but may not be fully compatible with 2.9.0.
Is there a "compatible DLL version" that can be queried or is using
getDLLVersion() the recommended approach and ignoring everything after the
second '.'?
And if 2.8.0 and 2.8.1 are fully compatible, why is a warning issued, if a
package built with R 2.8.1 is loaded in R 2.8.0?
Thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
Simon, first, I'd like to apologize, that my previous message has been sent to you directly. I have not checked the receivers list when clicking reply in my E-mail program. Simon Urbanek wrote: > On Jan 7, 2009, at 2:05 , Thomas Baier wrote: > >> Simon, >> >> Simon Urbanek wrote: >>>> And if 2.8.0 and 2.8.1 are fully compatible, why is a warning >>>> issued, if a package built with R 2.8.1 is loaded in R 2.8.0? >>>> >>> >>> It's ok to use a package built for 2.8.0 in 2.8.1 but not vice >>> versa. It is rare, but it has happened before that a bugfix or >>> visibility change adds a symbol in x.y.1 that was not there in >>> x.y.0. Then if your package checks for that particular feature and >>> uses it you cannot use that binary with x.y.0. Again, this is >>> rather rare and you as the >> >> so this was exactly what has occured. Users having installed R 2.8.0 >> (as >> 2.8.1 has not been released then) and installing a package from CRAN >> which has been built for 2.8.1. >> >> >>> package author know about it, but to be on the safe side I was >>> recommending against that. However, as Brian pointed out this >>> happens far more often on the R function level than on the C API >>> level. >>> >>> (I know about this DLL version check because it was the first >>> change I >>> made to JRI since I wasn't willing to release Windows binary some >>> five times a year ;)). >> >> As far as I have understood Brian's message, one should just parse >> for the second '.' in the version string and omit everything >> afterwards for comparison. >> >> What I would really like to have is some new API function to check >> compatibility. If this was there both on R user level (for R language >> constructs and functions) and on C level (for packages/applications >> relying on the C API), then this would be a fine solution for >> compatiblity without issuing any warnings about wrong versions. >> > > Semantically that's not really possible since the result would always > be FALSE. The point is that if you use something that has been fixed > or added, you may run into issues since the behavior changed. R cannot > know whether that affects you package or not. Therefore it's safer to > declare patch-level releases compatible (they don't "break" existing > binaries) and everything else incompatible (as Brian was suggesting). > However, my point was that *you* can decide to exploit changes in > patch-level updates if you desire so (a practical example here is > R_SignalHandlers which was introduced (exposed) in 2.3.1 and thus a > patch-level), but in that case it is your decision not some R > incompatibility. I hope this makes clear what I was describing > earlier. In general forward binary compatibility between patch-level > versions is guaranteed and backward if you don't use features added > later on. That's true for fixes, which will break compatibity (but are required as well). If I had used R_SignalHandlers in a package, then I would have had to restrict the package to be compatible with R >= 2.3.1, not with versions before. This should be something in the DESCRIPTION file. The only thing (but code-breaking fixes) I can imagine is a compile-time check in the package, so it behaves differently for < 2.3.1 and >= 2.3.1. Best, Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
