Re: [Rd] Revision of shell.exec?
On Sep 14, 2011, at 4:44 PM, Dirk Eddelbuettel wrote:
>
> On 14 September 2011 at 16:22, Simon Urbanek wrote:
> |
> | On Sep 14, 2011, at 4:15 PM, Brian Oney wrote:
> |
> | > Hi there,
> | > new idea (at 10 at night). All the emails keep me thinking (btw thanks
> for all the feedback).
> | > What does this do on linux?
> | >
> | > getOption("pdfviewer")
> | > ### I got this idea from: getS3method("print","vignette")
> | >
> |
> | It gives you the detected PDF viewer as I was explaining (essentially
> R_PDFVIEWER). The two detected settings I was referring to are R_PDFVIEWER
> (for PDF) and R_BROWSER (for URLs) which are the initial settings for the
> "pdfviewer" and "browser" options.
> |
> | Note that it's what it say it is - R_PDFVIEWER is usually something like
> acroread or evince so not particularly useful for your purpose ...
>
> R> getOption("pdfviewer")
> [1] "/usr/bin/xdg-open"
> R>
>
> We've had that as xdg-open in Debian / Ubuntu for a while now...
>
Yes, but that's merely a side-effect. For example on Ubuntu (R from sources) I
get
gis:~$ Rscript -e 'cat(getOption("pdfviewer"),"\n")'
/usr/bin/X11/evince
because xdg-open is not installed by default. My point is that the setting is
meant for something else, so misappropriating it, although possible, may not be
wise. If you really want to go down that alley, you could use some logic like
if (identical(getOption("pdfviewer"), getOption("browser"))) { # better chance
that it's something that can open things universally
} else { ## well, bad luck ... }
That will work on Macs and possibly on OSes that have generic open commands ...
(but is not guaranteed to ...).
Cheers,
Simon
> Dirk
>
> --
> New Rcpp master class for R and C++ integration is scheduled for
> San Francisco (Oct 8), more details / reg.info available at
> http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
On 14 September 2011 at 16:22, Simon Urbanek wrote:
|
| On Sep 14, 2011, at 4:15 PM, Brian Oney wrote:
|
| > Hi there,
| > new idea (at 10 at night). All the emails keep me thinking (btw thanks for
all the feedback).
| > What does this do on linux?
| >
| > getOption("pdfviewer")
| > ### I got this idea from: getS3method("print","vignette")
| >
|
| It gives you the detected PDF viewer as I was explaining (essentially
R_PDFVIEWER). The two detected settings I was referring to are R_PDFVIEWER (for
PDF) and R_BROWSER (for URLs) which are the initial settings for the
"pdfviewer" and "browser" options.
|
| Note that it's what it say it is - R_PDFVIEWER is usually something like
acroread or evince so not particularly useful for your purpose ...
R> getOption("pdfviewer")
[1] "/usr/bin/xdg-open"
R>
We've had that as xdg-open in Debian / Ubuntu for a while now...
Dirk
--
New Rcpp master class for R and C++ integration is scheduled for
San Francisco (Oct 8), more details / reg.info available at
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
On Sep 14, 2011, at 4:15 PM, Brian Oney wrote:
> Hi there,
> new idea (at 10 at night). All the emails keep me thinking (btw thanks for
> all the feedback).
> What does this do on linux?
>
> getOption("pdfviewer")
> ### I got this idea from: getS3method("print","vignette")
>
It gives you the detected PDF viewer as I was explaining (essentially
R_PDFVIEWER). The two detected settings I was referring to are R_PDFVIEWER (for
PDF) and R_BROWSER (for URLs) which are the initial settings for the
"pdfviewer" and "browser" options.
Note that it's what it say it is - R_PDFVIEWER is usually something like
acroread or evince so not particularly useful for your purpose ...
Cheers,
Simon
> On windows, (an advantage...) somebody wrote a little program "open.exe" that
> comes stock with an R-installation, which somehow accesses the file system to
> find the default program to for a certain file type. I am guessing this
> little beauty is the engine of "shell.exec".
>
> (An honest) cheers,
> Brian
>
> On 9/14/2011 7:49 PM, Simon Urbanek wrote:
>> On Sep 14, 2011, at 1:10 PM, Henrik Bengtsson wrote:
>>
>>> On Wed, Sep 14, 2011 at 8:35 AM, Simon Urbanek
>>> wrote:
On Sep 14, 2011, at 11:08 AM, Brian Oney wrote:
> Hi Steve,
>
> a quick look at "browseURL" will tell you that indeed "system" or
> "shell.exec" (on a windows platform) is used to open up a URL.
> The "open " part of the proposed function was written to work on a Mac.
> Because Mac is a unix platform, I assumed that the function "open" would
> be omnipresent on unix platforms, my mistake.
Well, the problem is that "open" is unfortunately mapped to openvt on
Linux systems which is a quite obscure anachronism. But since Linux is
Linux there is no standard way to open a file, so it doesn't really matter
;) -- xdg-utils come closest to what one may call standard but on many
systems they are not installed by default (in fact on none of the Linux
machines I have around). For URLs R does the hard work to try to figure
out what to do with them (it also does the same for PDFs), but you may end
up opening things in a browser although that's not what you had in mind.
> Well I guess, we know how to make to work on a mac.
>
Yes, "open" works very well on Macs and is extremely useful (I use it all
the time - among other things you can use it with directories to browse
them...) - it is still beyond me why other unices don't bother ...
>>> Apple probably patented it.
>>>
>> I'm pretty sure it's at least as old as NeXT so that's way before the abuse
>> of software patents ;) - but who knows ...
>>
>> Cheers,
>> S
>>
>>
>>
>>> /Henrik
>>>
Cheers,
Simon
> I will make the transition to Linux and get back to this in a while, ok?
>
> Cheers,
> Brian
>
>
> On 9/14/2011 2:50 PM, Stephen Weston wrote:
>> 2011/9/14 Uwe Ligges:
>>> On 14.09.2011 12:27, Brian Oney wrote:
Hi List,
I hope this is correct list to propose function extensions, sorry if
not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file<- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
>>> What is "open" supposed to do on a non-Windows machine? I do not have
>>> it on
>>> the only Linux installation I looked at now, hence we obviously cannot
>>> assume it exists on an arbitrary installation.
>> I think the nearest equivalent for those running Gnome or KDE may be
>> "xdg-open". So there would probably need to be a new option for
>> specifying
>> the appropriate command.
>>
>> Personally, I am more inclined to use "system" for executing commands,
>> and "browseURL" for opening documents. "browseURL" even uses
>> "xdg-open" in my R installation on my Linux machine.
>>
>> - Steve
>>
>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
> __
> R-devel@
Re: [Rd] Revision of shell.exec?
Hi there,
new idea (at 10 at night). All the emails keep me thinking (btw thanks
for all the feedback).
What does this do on linux?
getOption("pdfviewer")
### I got this idea from: getS3method("print","vignette")
On windows, (an advantage...) somebody wrote a little program "open.exe"
that comes stock with an R-installation, which somehow accesses the file
system to find the default program to for a certain file type. I am
guessing this little beauty is the engine of "shell.exec".
(An honest) cheers,
Brian
On 9/14/2011 7:49 PM, Simon Urbanek wrote:
On Sep 14, 2011, at 1:10 PM, Henrik Bengtsson wrote:
On Wed, Sep 14, 2011 at 8:35 AM, Simon Urbanek
wrote:
On Sep 14, 2011, at 11:08 AM, Brian Oney wrote:
Hi Steve,
a quick look at "browseURL" will tell you that indeed "system" or "shell.exec"
(on a windows platform) is used to open up a URL.
The "open " part of the proposed function was written to work on a Mac. Because Mac is a
unix platform, I assumed that the function "open" would be omnipresent on unix platforms,
my mistake.
Well, the problem is that "open" is unfortunately mapped to openvt on Linux
systems which is a quite obscure anachronism. But since Linux is Linux there is no
standard way to open a file, so it doesn't really matter ;) -- xdg-utils come closest to
what one may call standard but on many systems they are not installed by default (in fact
on none of the Linux machines I have around). For URLs R does the hard work to try to
figure out what to do with them (it also does the same for PDFs), but you may end up
opening things in a browser although that's not what you had in mind.
Well I guess, we know how to make to work on a mac.
Yes, "open" works very well on Macs and is extremely useful (I use it all the
time - among other things you can use it with directories to browse them...) - it is
still beyond me why other unices don't bother ...
Apple probably patented it.
I'm pretty sure it's at least as old as NeXT so that's way before the abuse of
software patents ;) - but who knows ...
Cheers,
S
/Henrik
Cheers,
Simon
I will make the transition to Linux and get back to this in a while, ok?
Cheers,
Brian
On 9/14/2011 2:50 PM, Stephen Weston wrote:
2011/9/14 Uwe Ligges:
On 14.09.2011 12:27, Brian Oney wrote:
Hi List,
I hope this is correct list to propose function extensions, sorry if not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file<- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
What is "open" supposed to do on a non-Windows machine? I do not have it on
the only Linux installation I looked at now, hence we obviously cannot
assume it exists on an arbitrary installation.
I think the nearest equivalent for those running Gnome or KDE may be
"xdg-open". So there would probably need to be a new option for specifying
the appropriate command.
Personally, I am more inclined to use "system" for executing commands,
and "browseURL" for opening documents. "browseURL" even uses
"xdg-open" in my R installation on my Linux machine.
- Steve
Best,
Uwe Ligges
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Q] Package NS Hook Lint NOTE
Have a question about the following NOTEs appearing on CRAN checks:
> .onLoad calls:
> require(methods)
>
> Package startup functions should not change the search path.
> See section ŒGood practice¹ in ?.onAttach.
For years, I have had the following in my S4-requiring packages.
##-
.onLoad <- function(libname, pkgname) {
## In case namespace is loaded (via import) by package that
## doesn't depend on S4 methods and used in a session with
## non-default set of packages
require(methods)
}
It was all based on an explanation Prof. Ripley gave to someone
about some package loading corner case (reference lost to history
though circa R-2.7 or before). Is it no longer an issue?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
On Wed, Sep 14, 2011 at 8:35 AM, Simon Urbanek
wrote:
>
> On Sep 14, 2011, at 11:08 AM, Brian Oney wrote:
>
>> Hi Steve,
>>
>> a quick look at "browseURL" will tell you that indeed "system" or
>> "shell.exec" (on a windows platform) is used to open up a URL.
>> The "open " part of the proposed function was written to work on a Mac.
>> Because Mac is a unix platform, I assumed that the function "open" would be
>> omnipresent on unix platforms, my mistake.
>
> Well, the problem is that "open" is unfortunately mapped to openvt on Linux
> systems which is a quite obscure anachronism. But since Linux is Linux there
> is no standard way to open a file, so it doesn't really matter ;) --
> xdg-utils come closest to what one may call standard but on many systems they
> are not installed by default (in fact on none of the Linux machines I have
> around). For URLs R does the hard work to try to figure out what to do with
> them (it also does the same for PDFs), but you may end up opening things in a
> browser although that's not what you had in mind.
>
>
>> Well I guess, we know how to make to work on a mac.
>>
>
> Yes, "open" works very well on Macs and is extremely useful (I use it all the
> time - among other things you can use it with directories to browse them...)
> - it is still beyond me why other unices don't bother ...
Apple probably patented it.
/Henrik
>
> Cheers,
> Simon
>
>
>
>> I will make the transition to Linux and get back to this in a while, ok?
>>
>> Cheers,
>> Brian
>>
>>
>> On 9/14/2011 2:50 PM, Stephen Weston wrote:
>>> 2011/9/14 Uwe Ligges:
On 14.09.2011 12:27, Brian Oney wrote:
> Hi List,
> I hope this is correct list to propose function extensions, sorry if not.
> I am preparing for a (hopefully painless) migration to linux. As far as
> I am aware of, the function "shell.exec" only comes with the windows
> version. I think this is a handy little function and would like to see
> my scripts work when I migrate.
>
> May I propose something (like the following)?
>
> open.file<- function(file) {
> if(.Platform$OS.type=="windows") {shell.exec(file)} else
> {system(paste("open ",file))}
> }
>
> Or just a small addition to the shell.exec function and no new named
> function.
> Hope the idea isn't received as "too stupid".
What is "open" supposed to do on a non-Windows machine? I do not have it on
the only Linux installation I looked at now, hence we obviously cannot
assume it exists on an arbitrary installation.
>>> I think the nearest equivalent for those running Gnome or KDE may be
>>> "xdg-open". So there would probably need to be a new option for specifying
>>> the appropriate command.
>>>
>>> Personally, I am more inclined to use "system" for executing commands,
>>> and "browseURL" for opening documents. "browseURL" even uses
>>> "xdg-open" in my R installation on my Linux machine.
>>>
>>> - Steve
>>>
>>>
Best,
Uwe Ligges
> Cheers,
> Brian
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
On Sep 14, 2011, at 11:08 AM, Brian Oney wrote:
> Hi Steve,
>
> a quick look at "browseURL" will tell you that indeed "system" or
> "shell.exec" (on a windows platform) is used to open up a URL.
> The "open " part of the proposed function was written to work on a Mac.
> Because Mac is a unix platform, I assumed that the function "open" would be
> omnipresent on unix platforms, my mistake.
Well, the problem is that "open" is unfortunately mapped to openvt on Linux
systems which is a quite obscure anachronism. But since Linux is Linux there is
no standard way to open a file, so it doesn't really matter ;) -- xdg-utils
come closest to what one may call standard but on many systems they are not
installed by default (in fact on none of the Linux machines I have around). For
URLs R does the hard work to try to figure out what to do with them (it also
does the same for PDFs), but you may end up opening things in a browser
although that's not what you had in mind.
> Well I guess, we know how to make to work on a mac.
>
Yes, "open" works very well on Macs and is extremely useful (I use it all the
time - among other things you can use it with directories to browse them...) -
it is still beyond me why other unices don't bother ...
Cheers,
Simon
> I will make the transition to Linux and get back to this in a while, ok?
>
> Cheers,
> Brian
>
>
> On 9/14/2011 2:50 PM, Stephen Weston wrote:
>> 2011/9/14 Uwe Ligges:
>>>
>>> On 14.09.2011 12:27, Brian Oney wrote:
Hi List,
I hope this is correct list to propose function extensions, sorry if not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file<- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
>>> What is "open" supposed to do on a non-Windows machine? I do not have it on
>>> the only Linux installation I looked at now, hence we obviously cannot
>>> assume it exists on an arbitrary installation.
>> I think the nearest equivalent for those running Gnome or KDE may be
>> "xdg-open". So there would probably need to be a new option for specifying
>> the appropriate command.
>>
>> Personally, I am more inclined to use "system" for executing commands,
>> and "browseURL" for opening documents. "browseURL" even uses
>> "xdg-open" in my R installation on my Linux machine.
>>
>> - Steve
>>
>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
Hi Steve,
a quick look at "browseURL" will tell you that indeed "system" or
"shell.exec" (on a windows platform) is used to open up a URL.
The "open " part of the proposed function was written to work on a Mac.
Because Mac is a unix platform, I assumed that the function "open" would
be omnipresent on unix platforms, my mistake. Well I guess, we know how
to make to work on a mac.
I will make the transition to Linux and get back to this in a while, ok?
Cheers,
Brian
On 9/14/2011 2:50 PM, Stephen Weston wrote:
2011/9/14 Uwe Ligges:
On 14.09.2011 12:27, Brian Oney wrote:
Hi List,
I hope this is correct list to propose function extensions, sorry if not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file<- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
What is "open" supposed to do on a non-Windows machine? I do not have it on
the only Linux installation I looked at now, hence we obviously cannot
assume it exists on an arbitrary installation.
I think the nearest equivalent for those running Gnome or KDE may be
"xdg-open". So there would probably need to be a new option for specifying
the appropriate command.
Personally, I am more inclined to use "system" for executing commands,
and "browseURL" for opening documents. "browseURL" even uses
"xdg-open" in my R installation on my Linux machine.
- Steve
Best,
Uwe Ligges
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R package with precompiled shared library
On 14.09.2011 15:52, Paul Gilbert wrote: My understanding is that this cannot be done, for both licence and security reasons. The package build expects source code and removes binaries. You can link with binaries that are provided separately from the package, possibly coming from a vendor that sells non-open source code, but you cannot include them in the package. Actually, you can include them, but then the package won't be accepted on CRAN, for example. Let me cite Writing R Extensions: "Note that CRAN does not accept submissions of precompiled binaries due to security concerns, and does not allow binary executables in packages. Maintainers who need additional software for the Windows binaries of their packages on CRAN have three options 1. To arrange for installation of the package to download the additional software from a URL, as e.g. package Cairo does. 2. To negotiate with Uwe Ligges to host the additional components on WinBuilder, and write a ‘configure.win’ file to install them. There are many examples, e.g. package rgdal." So in case you do not want to move it to CRAN, you can simply use the same tricks that rgdal uses for Windows binaries on CRAN. Uwe Ligges Paul -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Francesco Finazzi Sent: September 14, 2011 3:41 AM To: r-devel@r-project.org Subject: [Rd] Building R package with precompiled shared library Dear R users, we are trying to build a R package that includes a precompiled shared library, let's say mylib.so. We created the skeleton of the package and we moved the mylib.so file into the libs folder that we created at the same level of the folders man and R. Moreover we created the file NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). The building step seems to work correctly but when we try to install the package we get ** testing if installed package can be loaded Error in library.dynam(lib, package, package.lib) : shared library 'mylib' not found we cannot understand what's wrong and where R searches for the mylib.so files. Any suggestion? Thanks, Michela and Francesco __ 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 information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R package with precompiled shared library
On Sep 14, 2011, at 9:52 AM, Paul Gilbert wrote: > My understanding is that this cannot be done, for both licence and security > reasons. The package build expects source code and removes binaries. You can > link with binaries that are provided separately from the package, possibly > coming from a vendor that sells non-open source code, but you cannot include > them in the package. > It is not quite true and it is not the reason for it failing ;). That reason is that libs is the wrong folder to put it in. Note that libs is the folder in the *installed* package that the shared object go to, not in the sources. Also note that it is practically impossible to provide precompiled .so binaries (legal issues aside) because that would limit the package to one particular architecture and OS yet many R installations have at least two architectures. This also means that you would have to determine at build time where to put it ... (or relay on R installation mechanism but then you must make sure your binary is compatible with the currently built architecture). In practice this is occasionally done for very specific systems - for example Windows: it can be quite hard to compile some (open source) dependencies on Windows so they can be shipped as static binaries (for both x64 and i386) and used by the build process. On all other systems the system libraries are used instead (for an example of this approach see "png" or "jpeg" packages on CRAN). But still, the shared object (here .dll) is not shipped, because that depends on the R version, so it is created from the static libraries by the R package building process instead. Cheers, Simon > Paul > >> -Original Message- >> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- >> project.org] On Behalf Of Francesco Finazzi >> Sent: September 14, 2011 3:41 AM >> To: r-devel@r-project.org >> Subject: [Rd] Building R package with precompiled shared library >> >> Dear R users, >> >> we are trying to build a R package that includes a precompiled shared >> library, let's say mylib.so. We created the skeleton of the package >> and we moved the mylib.so file into the libs folder that we created at >> the same level of the folders man and R. Moreover we created the file >> NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). >> The building step seems to work correctly but when we try to install >> the package we get >> >> ** testing if installed package can be loaded >> Error in library.dynam(lib, package, package.lib) : >> shared library 'mylib' not found >> >> we cannot understand what's wrong and where R searches for the mylib.so >> files. >> >> Any suggestion? >> >> Thanks, >> >> Michela and Francesco >> >> __ >> 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 information, and the > Bank of > Canada does not waive any related rights. Any distribution, use, or copying > of this > email or the information it contains by other than the intended recipient is > unauthorized. If you received this email in error please delete it > immediately from > your system and notify the sender promptly by email that you have done so. > > > > Le présent courriel peut contenir de l'information privilégiée ou > confidentielle. > La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute > diffusion, > utilisation ou copie de ce courriel ou des renseignements qu'il contient par > une > personne autre que le ou les destinataires désignés est interdite. Si vous > recevez > ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans > délai à > l'expéditeur un message électronique pour l'aviser que vous avez éliminé de > votre > ordinateur toute copie du courriel reçu. > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R package with precompiled shared library
My understanding is that this cannot be done, for both licence and security reasons. The package build expects source code and removes binaries. You can link with binaries that are provided separately from the package, possibly coming from a vendor that sells non-open source code, but you cannot include them in the package. Paul > -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- > project.org] On Behalf Of Francesco Finazzi > Sent: September 14, 2011 3:41 AM > To: r-devel@r-project.org > Subject: [Rd] Building R package with precompiled shared library > > Dear R users, > > we are trying to build a R package that includes a precompiled shared > library, let's say mylib.so. We created the skeleton of the package > and we moved the mylib.so file into the libs folder that we created at > the same level of the folders man and R. Moreover we created the file > NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). > The building step seems to work correctly but when we try to install > the package we get > > ** testing if installed package can be loaded > Error in library.dynam(lib, package, package.lib) : > shared library 'mylib' not found > > we cannot understand what's wrong and where R searches for the mylib.so > files. > > Any suggestion? > > Thanks, > > Michela and Francesco > > __ > 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 information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Revision of shell.exec?
On 14.09.2011 12:27, Brian Oney wrote:
Hi List,
I hope this is correct list to propose function extensions, sorry if not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file <- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
What is "open" supposed to do on a non-Windows machine? I do not have it
on the only Linux installation I looked at now, hence we obviously
cannot assume it exists on an arbitrary installation.
Best,
Uwe Ligges
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R package with precompiled shared library
Dear R users, we are trying to build a R package that includes a precompiled shared library, let's say mylib.so. We created the skeleton of the package and we moved the mylib.so file into the libs folder that we created at the same level of the folders man and R. Moreover we created the file NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). The building step seems to work correctly but when we try to install the package we get ** testing if installed package can be loaded Error in library.dynam(lib, package, package.lib) : shared library 'mylib' not found we cannot understand what's wrong and where R searches for the mylib.so files. Any suggestion? Thanks, Michela and Francesco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Revision of shell.exec?
Hi List,
I hope this is correct list to propose function extensions, sorry if not.
I am preparing for a (hopefully painless) migration to linux. As far as
I am aware of, the function "shell.exec" only comes with the windows
version. I think this is a handy little function and would like to see
my scripts work when I migrate.
May I propose something (like the following)?
open.file <- function(file) {
if(.Platform$OS.type=="windows") {shell.exec(file)} else
{system(paste("open ",file))}
}
Or just a small addition to the shell.exec function and no new named
function.
Hope the idea isn't received as "too stupid".
Cheers,
Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
