[Rd] Compilation of R-2.2.0 under SUSE 10
Hi I hope this is the right list for the question. I want to install R from source under SUSE 10. When executing ./Configure, I get the following error message: checking for xmkmf... /usr/X11R6/bin/xmkmf configure: WARNING: I could not determine FPICFLAGS. configure: error: See the file INSTALL for more information. and it taborts. Consequently, make does not work. Any ideas? Rainer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation of R-2.2.0 under SUSE 10
Could you give me a hint what I should look for? I am quite new to Linux. Rainer On Friday 14 October 2005 14:19, Peter Dalgaard wrote: > Rainer M Krug <[EMAIL PROTECTED]> writes: > > Hi > > > > I hope this is the right list for the question. > > I want to install R from source under SUSE 10. When executing > > ./Configure, I get the following error message: > > > > checking for xmkmf... /usr/X11R6/bin/xmkmf > > configure: WARNING: I could not determine FPICFLAGS. > > configure: error: See the file INSTALL for more information. > > > > and it taborts. Consequently, make does not work. > > > > Any ideas? > > You probably want to look into config.log and see what caused the > FPICFLAGS message. It could be an oblique way of telling you that you > haven't installed a Fortran compiler. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation of R-2.2.0 under SUSE 10
Hi
I solved the problem.
I hd a fortran compuiler installed and it is found:
configure:5331: g77 --version &5
GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.
butr it was not working. I installed another fortran compiler (gccfortran) and
it worked.
Thanks a lot for your help Peter
Rainer
On Friday 14 October 2005 15:30, Peter Dalgaard wrote:
> Rainer M Krug <[EMAIL PROTECTED]> writes:
> > Could you give me a hint what I should look for? I am quite new to Linux.
> >
> > Rainer
>
> As long as you can see where it goes wrong, just ask again, citing the
> relevant bit of the log. Finding this is a bit convoluted for the
> FPICFLAGS issue because the failing test is just for whether the
> variable was set earlier, which AFAICS should happen here:
>
>
> ## Step 2. GNU compilers.
> if test "${GCC}" = yes; then
> cpicflags="-fPIC"
> shlib_ldflags="-shared"
> fi
> if test "${G77}" = yes; then
> fpicflags="-fPIC"
> fi
> if test "${GXX}" = yes; then
> cxxpicflags="-fPIC"
> shlib_cxxldflags="-shared"
> fi
>
> Now, the natural guess is that ${G77} wasn't set earlier on, so look
> for the place where it figures out the Fortran compiler.
>
> > On Friday 14 October 2005 14:19, Peter Dalgaard wrote:
> > > Rainer M Krug <[EMAIL PROTECTED]> writes:
> > > > Hi
> > > >
> > > > I hope this is the right list for the question.
> > > > I want to install R from source under SUSE 10. When executing
> > > > ./Configure, I get the following error message:
> > > >
> > > > checking for xmkmf... /usr/X11R6/bin/xmkmf
> > > > configure: WARNING: I could not determine FPICFLAGS.
> > > > configure: error: See the file INSTALL for more information.
> > > >
> > > > and it taborts. Consequently, make does not work.
> > > >
> > > > Any ideas?
> > >
> > > You probably want to look into config.log and see what caused the
> > > FPICFLAGS message. It could be an oblique way of telling you that you
> > > haven't installed a Fortran compiler.
> >
> > __
> > 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] Compilation of R-2.2.0 under SUSE 10
As I wrote in my other email, I solved the problem and it is make'ing. I agree - on the CD's there is no fortran compiler. I found it on a mirror of OpenSuse - including many more. Concerning the rpm I don't know - never did it (anyway - that's my first compile under Linux...). Rainer On Friday 14 October 2005 15:37, Detlef Steuer wrote: > Hi, > > most probably you are missing xorg-devel packages. > But there is another problem: > At least the downloadable version of 10.0 does not contain _any_ fortran > compiler. At least I´m unable to find one. I don`t know about the retail > box. > > Still looking for an easy way to build an rpm package for 10.0 using some > additional yast sources. > > Hope that helps > Detlef > > On Fri, 14 Oct 2005 14:48:26 +0200 > > Rainer M Krug <[EMAIL PROTECTED]> wrote: > > Could you give me a hint what I should look for? I am quite new to Linux. > > > > Rainer > > > > On Friday 14 October 2005 14:19, Peter Dalgaard wrote: > > > Rainer M Krug <[EMAIL PROTECTED]> writes: > > > > Hi > > > > > > > > I hope this is the right list for the question. > > > > I want to install R from source under SUSE 10. When executing > > > > ./Configure, I get the following error message: > > > > > > > > checking for xmkmf... /usr/X11R6/bin/xmkmf > > > > configure: WARNING: I could not determine FPICFLAGS. > > > > configure: error: See the file INSTALL for more information. > > > > > > > > and it taborts. Consequently, make does not work. > > > > > > > > Any ideas? > > > > > > You probably want to look into config.log and see what caused the > > > FPICFLAGS message. It could be an oblique way of telling you that you > > > haven't installed a Fortran compiler. > > > > __ > > 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] Control R from another program (written in Delphi)
Hi I want to analysis data (generatet in a simulation written in Delphi) in R and the user interface will also written in Delpni -0 i.e. I want to control R from another program which is written in Delphi. At the moment I am using the (D)COM interface but as I would like to run R on a Linux Cluster, thits is not an option any more. What is the easiest way of copntrolluing R over the network? I thought about sockets, but I am a little bit stuck. Any tips welcome, Rainer -- NEW TELEPHONE NUMBER Tel:+27 - (0)72 808 2975 (w) Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology University of Stellenbosch Matieland 7602 South Africa Tel:+27 - (0)72 808 2975 (w) Fax:+27 - (0)21 808 3304 Cell: +27 - (0)83 9479 042 email: [EMAIL PROTECTED] [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Socks under R
Hi
when I use
con1 <- socketConnection(...)
in R and want to send text from another application written in Delphi to
R, do I just have to send the text or do I have to implement more
control characters and so on?
Is
con1 <- socketConnection(port=6011, server=TRUE)
writeLines("plot(rnorm(100))", con1)
just sending the text in "plot(rnorm(100))" to the socket or is it doing
more (R specific protocoll for socks comminication)?
Thanks,
Rainer
--
NEW TELEPHONE NUMBER
Tel:+27 - (0)72 808 2975 (w)
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation
Biology (UCT)
Department of Conservation Ecology
University of Stellenbosch
Matieland 7602
South Africa
Tel:+27 - (0)72 808 2975 (w)
Fax:+27 - (0)21 808 3304
Cell: +27 - (0)83 9479 042
email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Socks under R
That's brilliant!
Thanks a lot for your help,
Rainer
Simon Urbanek wrote:
> Rainer,
>
> On Oct 19, 2005, at 3:29 PM, Rainer M. Krug wrote:
>
>> when I use
>>
>> con1 <- socketConnection(...)
>>
>> in R and want to send text from another application written in Delphi
>> to R, do I just have to send the text or do I have to implement more
>> control characters and so on?
>
> Sockets are just reliable bi-directional communication channels (in the
> default mode), so their use is entirely up to you (both on R side and
> other application's side).
>
>> Is
>>
>> con1 <- socketConnection(port=6011, server=TRUE)
>> writeLines("plot(rnorm(100))", con1)
>>
>> just sending the text in "plot(rnorm(100))" to the socket or is it
>> doing more (R specific protocoll for socks comminication)?
>
> It basically equivalent to using "send" on the socket API level [i.e.
> the above effectively does send(s, "plot(rnorm(100))\n", 17, 0)], so
> it's up to the other side to receive it properly. There is no "R
> specific protocol" - socket connections in R use regular TCP (neither
> red nor white "socks" ;)), so the literature on socket programming is
> your friend (e.g. using readLines(con1) for incoming traffic in your
> example would be a bad idea).
>
> Cheers,
> Simon
>
--
NEW TELEPHONE NUMBER
Tel:+27 - (0)72 808 2975 (w)
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation
Biology (UCT)
Department of Conservation Ecology
University of Stellenbosch
Matieland 7602
South Africa
Tel:+27 - (0)72 808 2975 (w)
Fax:+27 - (0)21 808 3304
Cell: +27 - (0)83 9479 042
email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to uninstall R when installed with "make install"
Hi How can I uninstall R when I installed it with "make install"? Thanks, Rainer -- NEW TELEPHONE NUMBER Tel:+27 - (0)72 808 2975 (w) Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology University of Stellenbosch Matieland 7602 South Africa Tel:+27 - (0)72 808 2975 (w) Fax:+27 - (0)21 808 3304 Cell: +27 - (0)83 9479 042 email: [EMAIL PROTECTED] [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Sounds interesting. Do you have it on GitHub or similar?
Rainer
> On 8 Feb 2019, at 09:09, David Lindelof wrote:
>
> Yesterday I wrote and submitted to CRAN a package `run`, which implements
> the ideas discussed in this thread. Given a package tarball
> foo_0.1.0.tar.gz, users will be able to run
>
> Rscript -e "run::run('foo_0.1.0.tar.gz')"
>
> which will pull all the dependencies of package `foo`, lookup a function
> `main` in that package's namespace, and call it.
>
> It's an early draft but I'd appreciate any feedback (once its submission is
> accepted, of course).
>
> Thanks all for your help and advice,
>
> David
>
> On Sat, Feb 2, 2019 at 3:37 PM Duncan Murdoch
> wrote:
>
>> On 02/02/2019 8:27 a.m., Barry Rowlingson wrote:
>>> I don't think anyone denies that you *could* make an EXE to do all
>>> that. The discussion is on *how easy* it should be to create a single
>>> file that contains an initial "main" function plus a set of bundled
>>> code (potentially as a package) and which when run will install its
>>> package code (which is contained in itself, its not in a repo),
>>> install dependencies, and run the main() function.
>>>
>>> Now, I could build a self-executable shar file that bundled a package
>>> together with a script to do all the above. But if there was a "RUN"
>>> command in R, and a convention that a function called "foo::main"
>>> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much
>>> easier to develop and test.
>>
>> I don't believe the "so much easier" argument that this requires a
>> change to base R. If you put that functionality into a package, then
>> the only extra effort the user would require is to install that other
>> package. After that, they could run
>>
>> Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')"
>>
>> as I suggested before. This is no harder than running
>>
>> R CMD RUN foo_1.1.1.tar.gz
>>
>> The advantage of this from R Core's perspective is that you would be
>> developing and maintaining "yourpackage", you wouldn't be passing the
>> burden on to them. The advantage from your perspective is that you
>> could work with whatever packages you liked. The "remotes" package has
>> almost everything you need so that "yourpackage" could be nearly
>> trivial. You wouldn't need to duplicate it within base R.
>>
>> Duncan Murdoch
>>
>>>
>>> If people think this adds value, then if they want to offer that value
>>> to me as $ or £, I'd consider writing it if their total value was more
>>> than my cost
>>>
>>> Barry
>>>
>>>
>>> On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote:
>>>>
>>>> Further to my previous post,
>>>> it would be possible to create an .exe file, say:
>>>>
>>>> my_r_application.exe
>>>>
>>>> That starts R, loads your R package(s), calls the R function of your
>> choice
>>>> and does whatever else you want.
>>>>
>>>> However, I don't think that it would add much value.
>>>> But feel free to correct me if you think that I'm wrong.
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> __
>>>> 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
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland
Office: +41 (0)44 635 47 64
Cell: +41 (0)78 630 66 57
email: rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Usage of options() for user defined options
Hi I want to use options() to store session wide options - is that a reasonable approach, or should options() be reserved for core options? Thanks Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding inter-function dependencies within a package
On Thu, Sep 29, 2011 at 1:11 PM, Keith Jewell wrote: > Hi, > > I'd like to know which functions in a package call one specific function. > I think I've seen a tool for identifying such dependencies, but now I can't > find it :-( > Roxygen had the functionality to draw dependency graphs - but I think it has been excluded in Roxygen2? Rainer > Searches of help and R site search for keywords like function, call, tree, > depend haven't helped :-( > > Can anyone point me in the right direction? > > Thanks in advance, > > Keith Jewell > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH vs R CMD batch
Dirk Eddelbuettel writes: > On 28 October 2015 at 21:39, Marius Hofert wrote: > | Out of laziness I just used "R CMD batch" instead of "R CMD BATCH". I > | didn't get an error so didn't think about the consequences... One > | consequence is (at least on Mac OS X 10.11 but probably in more > | generality) that R_BATCH_OPTIONS are ignored, which was kind of fatal > | in my case... I am thus wondering whether it makes sense to either a) > | have R_BATCH_OPTIONS also be respected for "R CMD batch" or b) simply > | not allow "R CMD batch" as a valid command (so requiring to use "R CMD > | BATCH"). Both approaches might be delicate... just wanted to point > | this issue out... > > Same reason we have 'R CMD INSTALL' as there often is /usr/bin/install with > different options ... > > In general 'R CMD foo' will run for any 'foo' in the path: > >edd@max:~$ R CMD date >Wed Oct 28 21:05:01 CDT 2015 >edd@max:~$ So what is R CMD exactly doing in this example? The output is the same if I say only the command (using pwd as otherwise the time has changed...): , | 09:35:03 ~$ R CMD pwd | /Users/rainerkrug | 09:35:37 ~$ R CMD pwd | /Users/rainerkrug | 09:37:44 ~$ pwd | /Users/rainerkrug | 09:37:49 ~$ ` And this happens, except in cases where the foo is defined as a CMD in R (build, ...): , | Commands: | BATCH Run R in batch mode | COMPILE Compile files for use with R | SHLIB Build shared library for dynamic loading | INSTALL Install add-on packages | REMOVE Remove add-on packages | build Build add-on packages | check Check add-on packages | LINKFront-end for creating executable programs | Rprof Post-process R profiling files | Rdconv Convert Rd format to various other formats | Rd2pdf Convert Rd format to PDF | Rd2txt Convert Rd format to pretty text | Stangle Extract S/R code from Sweave documentation | Sweave Process Sweave documentation | Rdiff Diff R output ignoring headers etc | config Obtain configuration information about R | javareconf Update the Java configuration variables | rtags Create Emacs-style tag files from C, R, and Rd files ` Unless I miss something, is this is an inconsistency in R? Rainer > > Dirk -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH vs R CMD batch
Deepayan Sarkar writes: > On Thu, Oct 29, 2015 at 2:09 PM, Rainer M Krug wrote: >> Dirk Eddelbuettel writes: >> >>> On 28 October 2015 at 21:39, Marius Hofert wrote: >>> | Out of laziness I just used "R CMD batch" instead of "R CMD BATCH". I >>> | didn't get an error so didn't think about the consequences... One >>> | consequence is (at least on Mac OS X 10.11 but probably in more >>> | generality) that R_BATCH_OPTIONS are ignored, which was kind of fatal >>> | in my case... I am thus wondering whether it makes sense to either a) >>> | have R_BATCH_OPTIONS also be respected for "R CMD batch" or b) simply >>> | not allow "R CMD batch" as a valid command (so requiring to use "R CMD >>> | BATCH"). Both approaches might be delicate... just wanted to point >>> | this issue out... >>> >>> Same reason we have 'R CMD INSTALL' as there often is /usr/bin/install with >>> different options ... >>> >>> In general 'R CMD foo' will run for any 'foo' in the path: >>> >>>edd@max:~$ R CMD date >>>Wed Oct 28 21:05:01 CDT 2015 >>>edd@max:~$ >> >> So what is R CMD exactly doing in this example? The output is the same if >> I say only the command (using pwd as otherwise the time has changed...): >> >> , >> | 09:35:03 ~$ R CMD pwd >> | /Users/rainerkrug >> | 09:35:37 ~$ R CMD pwd >> | /Users/rainerkrug >> | 09:37:44 ~$ pwd >> | /Users/rainerkrug >> | 09:37:49 ~$ >> ` >> >> And this happens, except in cases where the foo is defined as a CMD in R >> (build, ...): >> >> , >> | Commands: >> | BATCH Run R in batch mode >> | COMPILE Compile files for use with R >> | SHLIB Build shared library for dynamic loading >> | INSTALL Install add-on packages >> | REMOVE Remove add-on packages >> | build Build add-on packages >> | check Check add-on packages >> | LINKFront-end for creating executable programs >> | Rprof Post-process R profiling files >> | Rdconv Convert Rd format to various other formats >> | Rd2pdf Convert Rd format to PDF >> | Rd2txt Convert Rd format to pretty text >> | Stangle Extract S/R code from Sweave documentation >> | Sweave Process Sweave documentation >> | Rdiff Diff R output ignoring headers etc >> | config Obtain configuration information about R >> | javareconf Update the Java configuration variables >> | rtags Create Emacs-style tag files from C, R, and Rd >> files >> ` >> >> Unless I miss something, is this is an inconsistency in R? > > One important difference (not sure if the only one) is that R CMD > defines more environment variables. Compare > > env | grep -i tex > R CMD env | grep -i tex > > So for example > > R CMD pdflatex > > will behave differently from plain pdflatex. Reading Dirk's email again, I think I get the picture of what ~R CMD foo~ is doing: running ~foo~ after doing some initial magic. Out of interest: What is the magic ~R CMD~ is doing? Is it documented anywhere? Rainer > > -Deepayan -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH vs R CMD batch
peter dalgaard writes:
> On 29 Oct 2015, at 10:44 , Rainer M Krug wrote:
>
>> Out of interest: What is the magic ~R CMD~ is doing? Is it documented
>> anywhere?
>
>
> R is open source (and shell scripts are considered self-documenting by
> some)
True - should have looked in the sources...
>
> On Unix-alikes, R is a shell script which, if called with 1st argument
> CMD, calls ${R_HOME}/bin/Rcmd, which is another shell script that ends
> with
>
> case "${1}" in
> ## this was a separate command prior to 2.10.0
> Rd2txt)
> cmd="${R_HOME}/bin/Rdconv"
> extra="-t txt"
> ;;
> ## removed in 2.15.0
> Rd2dvi)
> echo "R CMD Rd2dvi is defunct: use Rd2pdf instead"
> exit 1
> ;;
> *)
> if test -x "${R_HOME}/bin/${1}"; then
> cmd="${R_HOME}/bin/${1}"
> else
> cmd="${1}"
> fi
> ;;
> esac
> shift
>
> exec "${cmd}" ${extra} "${@}"
>
> I.e., except for setting up variables and such, R CMD ${foo}
> essentially looks for ${R_HOME}/bin/${foo} and executes it if it
> exists and is executable, otherwise it just executes ${foo}.
Thanks for that detailed explanation of the mechanism - it is much
clearer now. And as usual, if one knows how something is happening, it's
not "magical" anymore.
>
> Notice that, somewhat contrary to what Dirk said, this logic works at
> the mercy of the file system when it comes to case sensitivity. On OSX
> with the default case-insensitive setup we get
>
> Peters-iMac:IBP pd$ R CMD install
> Error: ERROR: no packages specified
>
> which comes from R's package installer, whereas a case-sensitive FS
> would pick up /usr/bin/install instead. That is just how the "test"
> shell built-in works:
>
> Peters-iMac:~ pd$ test -x `R RHOME`/bin/INSTALL ; echo $?
> 0
> Peters-iMac:~ pd$ test -x `R RHOME`/bin/UNSTALL ; echo $?
> 1
> Peters-iMac:~ pd$ test -x `R RHOME`/bin/install ; echo $?
> 0
Yeah - true. I was already starting to wonder as I always was using ~R
CMD install~ and it always worked on my Mac.
Thanks again,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
signature.asc
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warn on partial matches in R CMD check
Hadley Wickham writes: > Hi all (but especially Kurt), > > Would it be possible to have a flag to R CMD check that warned on > partial all matches, i.e. turning on: > > options( > warnPartialMatchDollar = TRUE, > warnPartialMatchArgs = TRUE, > warnPartialMatchAttr = TRUE > ) > > I think this is good practice for package code. +1 I think that would be brilliant because I already spend a few days chasing down an error because of an unintended partial match. > > I don't think it can currently be made part of the default (because > sometimes the warnings come from other packages), but it would be > really convenient to have as a switch. and also possibly to enable this for normal running of code outside of packages. Cheers, Rainer > > Hadley -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Perplexed with environment
Hi
I migrated from Linux to Mac, but I don't this has anything to do with
it, but I am not sure.
I am writing a small logger package, in which I have a file
aaa.R:
,
| .logData <- new.env()
| assign("loggingThreshold", 10, envir = .logData)
| assign("logToFile", FALSE, envir = .logData)
| assign("logFileName", NULL, envir = .logData)
|
| assign("logToConsole", TRUE, envir = .logData)
| ##
| assign("logHeaderLevel", 0, envir = .logData)
| assign("logHeader", "", envir = .logData)
| assign("logHeaderClock", "", envir = .logData)
| assign("timeFormat", "", envir = .logData)
`
to initialize some logging parameter.
When I load my package, everything looks fine, only that the environment
logger:::.logData is (nearly) empty:
,
| > library(logger)
| > ls(envir=logger:::.logData, all.names=TRUE)
| [1] ".logHeader" ".logHeaderClock" ".logHeaderLevel"
`
I assume I am doing something really basic wrong?
A copy of the package is available at:
https://www.dropbox.com/s/hv6abepcczrljum/logger_0.0-1.tar.gz
Thanks,
Rainer
PS: I am planning to making it available when it is working (again)
--
Rainer M. Krug
email: RMKruggmailcom
pgp_a9eqrII9M.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ASCII art in function documentation - difference html and text output?
Found a solution.
putting \cr at the end of each line inserts a carriage return, but no
additional empty line. So
,
| \code{+--+--+--+} \cr
| \code{| 1/16 | 1/16 | 1/16 |} \cr
| \code{+--+--+--+} \cr
| \code{| 1/16 | 8/16 | 1/16 |} \cr
| \code{+--+--+--+} \cr
| \code{| 1/16 | 1/16 | 1/16 |} \cr
| \code{+--+--+--+} \cr
`
produces the desired output.
But interestingly,
,
| \code{
| +--+--+--+ \cr
| | 1/16 | 1/16 | 1/16 | \cr
| +--+--+--+ \cr
| | 1/16 | 8/16 | 1/16 | \cr
| +--+--+--+ \cr
| | 1/16 | 1/16 | 1/16 | \cr
| +--+--+--+ \cr
| }
`
produces the correct output in html,
,
|
| +--+--+--+ | 1/16 | 1/16 | 1/16 |
|+--+--+--+ | 1/16 | 8/16 | 1/16 |
| +--+--+--+ | 1/16 | 1/16 | 1/16 |
| +--+--+--+
|
`
but
,
| ' +--+--+--+
| | 1/16 | 1/16 | 1/16 |
|
| +--+--+--+
| | 1/16 | 8/16 | 1/16 |
| +--+--+--+
| | 1/16 | 1/16 | 1/16 |
| +--+--+--+
`
in the text version - is there a bug somewhere?
Thanks,
Rainer
Rainer M Krug writes:
> Sarah Goslee writes:
>
>> Untested, but did you try wrapping the whole thing in a single code block:
>
> Nope - also in one line.
>
> Rainer
>
>>
>> \code{
>> all
>> the
>> things
>> }
>>
>> Sarah
>>
>> On Thu, Sep 5, 2013 at 10:10 AM, Rainer M Krug wrote:
>>> Hi
>>>
>>> I want to include ascii art in a function documentation which should
>>> look as follow:
>>>
>>> ,
>>> | +--+--+--+
>>> | | 1/16 | 1/16 | 1/16 |
>>> | +--+--+--+
>>> | | 1/16 | 8/16 | 1/16 |
>>> | +--+--+--+
>>> | | 1/16 | 1/16 | 1/16 |
>>> | +--+--+--+
>>> `
>>>
>>>
>>> to keep the monospaced font even in html, I decided to use \code{}:
>>>
>>> ,
>>> | \code{+--+--+--+}
>>> |
>>> | \code{| 1/16 | 1/16 | 1/16 |}
>>> |
>>> | \code{+--+--+--+}
>>> |
>>> | \code{| 1/16 | 8/16 | 1/16 |}
>>> |
>>> | \code{+--+--+--+}
>>> |
>>> | \code{| 1/16 | 1/16 | 1/16 |}
>>> |
>>> | \code{+--+--+--+}
>>> `
>>>
>>> But the result was an empty line between each text:
>>>
>>> ,
>>> | '+--+--+--+'
>>> |
>>> | '| 1/16 | 1/16 | 1/16 |'
>>> |
>>> | '+--+--+--+'
>>> |
>>> | '| 1/16 | 8/16 | 1/16 |'
>>> |
>>> | '+--+--+--+'
>>> |
>>> | '| 1/16 | 1/16 | 1/16 |'
>>> |
>>> | '+--+--+--+'
>>> `
>>>
>>> and when no empty lines were included obviously put everything behind
>>> each other.
>>>
>>> My question:
>>>
>>> Is there a way that I can achieve the ASCII art as shown above? Is there
>>> a way of having a \linebreak which does not insert a new line?
>>>
>>> Thanks,
>>>
>>> Rainer
>>>
>>>
>>> --
> <#secure method=pgpmime mode=sign>
>
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ASCII art in function documentation?
Hi
I want to include ascii art in a function documentation which should
look as follow:
,
| +--+--+--+
| | 1/16 | 1/16 | 1/16 |
| +--+--+--+
| | 1/16 | 8/16 | 1/16 |
| +--+--+--+
| | 1/16 | 1/16 | 1/16 |
| +--+--+--+
`
to keep the monospaced font even in html, I decided to use \code{}:
,
| \code{+--+--+--+}
|
| \code{| 1/16 | 1/16 | 1/16 |}
|
| \code{+--+--+--+}
|
| \code{| 1/16 | 8/16 | 1/16 |}
|
| \code{+--+--+--+}
|
| \code{| 1/16 | 1/16 | 1/16 |}
|
| \code{+--+--+--+}
`
But the result was an empty line between each text:
,
| '+--+--+--+'
|
| '| 1/16 | 1/16 | 1/16 |'
|
| '+--+--+--+'
|
| '| 1/16 | 8/16 | 1/16 |'
|
| '+--+--+--+'
|
| '| 1/16 | 1/16 | 1/16 |'
|
| '+--+--+--+'
`
and when no empty lines were included obviously put everything behind
each other.
My question:
Is there a way that I can achieve the ASCII art as shown above? Is there
a way of having a \linebreak which does not insert a new line?
Thanks,
Rainer
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ASCII art in function documentation?
OK - it boils down to an roxygen problem.
I will send a separate email for it.
Thanks,
Rainer
Sarah Goslee writes:
> Now that I'm at the computer with my R code, I've used both
> \preformatted{}
> and \cr to force line breaks.
>
> Some combination of those may work for you.
>
> Sarah
>
>
> On Thu, Sep 5, 2013 at 11:10 AM, Rainer M Krug wrote:
>> Sarah Goslee writes:
>>
>>> Untested, but did you try wrapping the whole thing in a single code block:
>>
>> Nope - also in one line.
>>
>> Rainer
>>
>>>
>>> \code{
>>> all
>>> the
>>> things
>>> }
>>>
>>> Sarah
>>>
>>> On Thu, Sep 5, 2013 at 10:10 AM, Rainer M Krug wrote:
>>>> Hi
>>>>
>>>> I want to include ascii art in a function documentation which should
>>>> look as follow:
>>>>
>>>> ,
>>>> | +--+--+--+
>>>> | | 1/16 | 1/16 | 1/16 |
>>>> | +--+--+--+
>>>> | | 1/16 | 8/16 | 1/16 |
>>>> | +--+--+--+
>>>> | | 1/16 | 1/16 | 1/16 |
>>>> | +--+--+--+
>>>> `
>>>>
>>>>
>>>> to keep the monospaced font even in html, I decided to use \code{}:
>>>>
>>>> ,
>>>> | \code{+--+--+--+}
>>>> |
>>>> | \code{| 1/16 | 1/16 | 1/16 |}
>>>> |
>>>> | \code{+--+--+--+}
>>>> |
>>>> | \code{| 1/16 | 8/16 | 1/16 |}
>>>> |
>>>> | \code{+--+--+--+}
>>>> |
>>>> | \code{| 1/16 | 1/16 | 1/16 |}
>>>> |
>>>> | \code{+--+--+--+}
>>>> `
>>>>
>>>> But the result was an empty line between each text:
>>>>
>>>> ,
>>>> | '+--+--+--+'
>>>> |
>>>> | '| 1/16 | 1/16 | 1/16 |'
>>>> |
>>>> | '+--+--+--+'
>>>> |
>>>> | '| 1/16 | 8/16 | 1/16 |'
>>>> |
>>>> | '+--+--+--+'
>>>> |
>>>> | '| 1/16 | 1/16 | 1/16 |'
>>>> |
>>>> | '+--+--+--+'
>>>> `
>>>>
>>>> and when no empty lines were included obviously put everything behind
>>>> each other.
>>>>
>>>> My question:
>>>>
>>>> Is there a way that I can achieve the ASCII art as shown above? Is there
>>>> a way of having a \linebreak which does not insert a new line?
>>>>
>>>> Thanks,
>>>>
>>>> Rainer
>>>>
>>>>
>>>> --
>> <#secure method=pgpmime mode=sign>
>>
>> --
>> Rainer M. Krug
>>
>> email: RMKruggmailcom
>>
>
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ASCII art in function documentation?
Sarah Goslee writes:
> Untested, but did you try wrapping the whole thing in a single code block:
Nope - also in one line.
Rainer
>
> \code{
> all
> the
> things
> }
>
> Sarah
>
> On Thu, Sep 5, 2013 at 10:10 AM, Rainer M Krug wrote:
>> Hi
>>
>> I want to include ascii art in a function documentation which should
>> look as follow:
>>
>> ,
>> | +--+--+--+
>> | | 1/16 | 1/16 | 1/16 |
>> | +--+--+--+
>> | | 1/16 | 8/16 | 1/16 |
>> | +--+--+--+
>> | | 1/16 | 1/16 | 1/16 |
>> | +--+--+--+
>> `
>>
>>
>> to keep the monospaced font even in html, I decided to use \code{}:
>>
>> ,
>> | \code{+--+--+--+}
>> |
>> | \code{| 1/16 | 1/16 | 1/16 |}
>> |
>> | \code{+--+--+--+}
>> |
>> | \code{| 1/16 | 8/16 | 1/16 |}
>> |
>> | \code{+--+--+--+}
>> |
>> | \code{| 1/16 | 1/16 | 1/16 |}
>> |
>> | \code{+--+--+--+}
>> `
>>
>> But the result was an empty line between each text:
>>
>> ,
>> | '+--+--+--+'
>> |
>> | '| 1/16 | 1/16 | 1/16 |'
>> |
>> | '+--+--+--+'
>> |
>> | '| 1/16 | 8/16 | 1/16 |'
>> |
>> | '+--+--+--+'
>> |
>> | '| 1/16 | 1/16 | 1/16 |'
>> |
>> | '+--+--+--+'
>> `
>>
>> and when no empty lines were included obviously put everything behind
>> each other.
>>
>> My question:
>>
>> Is there a way that I can achieve the ASCII art as shown above? Is there
>> a way of having a \linebreak which does not insert a new line?
>>
>> Thanks,
>>
>> Rainer
>>
>>
>> --
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ASCII art in function documentation?
"Brian G. Peterson" writes:
> On 09/05/2013 09:10 AM, Rainer M Krug wrote:
>> want to include ascii art in a function documentation which should
>> look as follow:
>>
>> ,
>> | +--+--+--+
>> | | 1/16 | 1/16 | 1/16 |
>> | +--+--+--+
>> | | 1/16 | 8/16 | 1/16 |
>> | +--+--+--+
>> | | 1/16 | 1/16 | 1/16 |
>> | +--+--+--+
>> `
>>
>>
>> to keep the monospaced font even in html, I decided to use \code{}:
>
> Wouldn't it be best to use the relatively new \figure markup with
> alternate text?
>
> http://cran.r-project.org/doc/manuals/R-exts.html#Figures
Thanks - mus't have overlooked it.
This would definitely work, but in this case I think ASCII art would be
the better solution.
Thanks,
Rainer
>
> Regards,
>
> Brian
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] check warning with .onLoad() and setClass()
Hi
I am writing a package in which I define a new class in the .onLoad()
hook:
,
| .onLoad <- function(libname, pkgname) {
| setClass(
| "inDrak",
| representation(
| init = "SpatialGridDataFrame"
| ),
| contains = "simObj"
| )
| }
`
The class "simObj" is defined in the package, which is in the depends
section in the DESCRIPTION file:
,
| Package: InDrak
| Type: Package
| Title: Alien spread management simulation model for the Drakensberg
| Version: 0.1-0
| Date: 2013-10-03_11-55
| Author: Rainer M. Krug
| Maintainer: Rainer M Krug
| Description: Simulate the spread of three Invasive Alien Plants under
different
| management and budget scenarios
| License: GPL-3
| LazyLoad: yes
| Depends:
| RSQLite,
| simecol
| Imports:
| methods,
| sp,
| spgrass6,
| DBI,
| logger,
| fireSim,
| seedProd,
| seedGerm,
| seedDisp
| LinkingTo: Rcpp
| Collate:
| 'beginYear.R'
| 'clearAliens.R'
| 'competition.R'
| 'cumulativeDc.R'
| 'dcToIndLayer.R'
| 'dispProb2D.R'
| 'endYear.R'
| 'fireAliens.R'
| 'germEst.R'
| 'initfunc.R'
| 'layerIO.R'
| 'layerNames.R'
| 'main.R'
| 'newInDrak.R'
| 'onLoad.R'
| 'package.R'
| 'parameter.R'
| 'parmsAcacia.R'
| 'parmsBudget.R'
| 'parmsFire.R'
| 'parmsPinus.R'
| 'parmsRubus.R'
| 'resetOptions.R'
| 'seedDispersal.R'
| 'seedProduction.R'
| 'stats.R'
`
If important, the NAMESPACE file is here:
,
| export(depRateName)
| export(exportRaster)
| export(fireLayerName)
| export(ignitionRiskName)
| export(importAliens)
| export(importClearingHistory)
| export(importFireHistory)
| export(importIgnitionRisk)
| export(importSpecies)
| export(importVegetation)
| export(layerExists)
| export(layerName)
| export(newInDrak)
| export(parameter)
| export(parmsAcacia)
| export(parmsBudget)
| export(parmsFire)
| export(parmsPinus)
| export(parmsRubus)
| export(resetOptions)
| export(statDistName)
| export(suitName)
| import(DBI)
| import(fireSim)
| import(logger)
| import(methods)
| import(seedDisp)
| import(seedGerm)
| import(seedProd)
| import(sp)
| import(spgrass6)
`
The package builds fine, it installs without problems and works as
expected, but when checking it, I get the following error:
,
| $ R CMD check ./InDrak_0.1-0.tar.gz
| * using log directory
‘/Users/rainerkrug/Documents/Projects/R-Packages/inDrak/InDrak.Rcheck’
| * using R version 3.0.1 (2013-05-16)
| * using platform: x86_64-apple-darwin10.8.0 (64-bit)
| * using session charset: UTF-8
| * checking for file ‘InDrak/DESCRIPTION’ ... OK
| * checking extension type ... Package
| * this is package ‘InDrak’ version ‘0.1-0’
| * checking package namespace information ... OK
| * checking package dependencies ... OK
| * checking if this is a source package ... OK
| * checking if there is a namespace ... OK
| * checking for executable files ... OK
| * checking for hidden files and directories ... OK
| * checking for portable file names ... OK
| * checking for sufficient/correct file permissions ... OK
| * checking whether package ‘InDrak’ can be installed ... OK
| * checking installed package size ... OK
| * checking package directory ... OK
| * checking DESCRIPTION meta-information ... OK
| * checking top-level files ... OK
| * checking for left-over files ... OK
| * checking index information ... OK
| * checking package subdirectories ... OK
| * checking R files for non-ASCII characters ... OK
| * checking R files for syntax errors ... OK
| * checking whether the package can be loaded ... OK
| * checking whether the package can be loaded with stated dependencies ... OK
| * checking whether the package can be unloaded cleanly ... OK
| * checking whether the namespace can be loaded with stated dependencies ...
WARNING
| Error: .onLoad failed in loadNamespace() for ‘InDrak’, details:
| call: reconcilePropertiesAndPrototype(name, slots, prototype, superClasses,
| error: no definition was found for superclass “simObj” in the specification
of class “inDrak”
| Execution halted
|
| A namespace must be able to be loaded with just the base namespace
| loaded: otherwise if the namespace gets loaded by a saved object, the
| session will be unable to start.
|
| Probably some imports need to be declared in the NAMESPACE file.
| * checking whether the namespace can be unloaded cleanly ... WARNING
| Error: .onLoad failed in loadNamespace() for ‘InDrak’, details:
| call: reconcilePropertiesAndPrototype(name, slots, prototype, superClasses,
| error: no definition was found for superclass “simObj” in the specific
Re: [Rd] check warning with .onLoad() and setClass()
Thanks John
that is likely the solution to my problem, but I don't understand how I
can use it and I can't find the example in the Rcpp package (I did grep
for setLoadAtion on the whole source package of Rcpp, but nothing came up with
). Could you
please provide me a link (or the filename) where I can see how to use
this function?
Thanks,
Rainer
John Chambers writes:
> Don't use .onLoad() to set class (or other nontrivial) information at
> load time. Use setLoadActions(), which was created exactly to get
> around the limitations of .onLoad().
>
> For an example, see the Rcpp package, which uses this to set up load-time C++
> linkages.
>
> John Chambers
>
> On Oct 3, 2013, at 3:22 AM, Rainer M Krug wrote:
>
>> Hi
>>
>> I am writing a package in which I define a new class in the .onLoad()
>> hook:
>>
>> ,
>> | .onLoad <- function(libname, pkgname) {
>> | setClass(
>> | "inDrak",
>> | representation(
>> | init = "SpatialGridDataFrame"
>> | ),
>> | contains = "simObj"
>> | )
>> | }
>> `
>>
>> The class "simObj" is defined in the package, which is in the depends
>> section in the DESCRIPTION file:
>>
>> ,----
>> | Package: InDrak
>> | Type: Package
>> | Title: Alien spread management simulation model for the Drakensberg
>> | Version: 0.1-0
>> | Date: 2013-10-03_11-55
>> | Author: Rainer M. Krug
>> | Maintainer: Rainer M Krug
>> | Description: Simulate the spread of three Invasive Alien Plants under
>> different
>> | management and budget scenarios
>> | License: GPL-3
>> | LazyLoad: yes
>> | Depends:
>> | RSQLite,
>> | simecol
>> | Imports:
>> | methods,
>> | sp,
>> | spgrass6,
>> | DBI,
>> | logger,
>> | fireSim,
>> | seedProd,
>> | seedGerm,
>> | seedDisp
>> | LinkingTo: Rcpp
>> | Collate:
>> | 'beginYear.R'
>> | 'clearAliens.R'
>> | 'competition.R'
>> | 'cumulativeDc.R'
>> | 'dcToIndLayer.R'
>> | 'dispProb2D.R'
>> | 'endYear.R'
>> | 'fireAliens.R'
>> | 'germEst.R'
>> | 'initfunc.R'
>> | 'layerIO.R'
>> | 'layerNames.R'
>> | 'main.R'
>> | 'newInDrak.R'
>> | 'onLoad.R'
>> | 'package.R'
>> | 'parameter.R'
>> | 'parmsAcacia.R'
>> | 'parmsBudget.R'
>> | 'parmsFire.R'
>> | 'parmsPinus.R'
>> | 'parmsRubus.R'
>> | 'resetOptions.R'
>> | 'seedDispersal.R'
>> | 'seedProduction.R'
>> | 'stats.R'
>> `
>>
>> If important, the NAMESPACE file is here:
>>
>> ,
>> | export(depRateName)
>> | export(exportRaster)
>> | export(fireLayerName)
>> | export(ignitionRiskName)
>> | export(importAliens)
>> | export(importClearingHistory)
>> | export(importFireHistory)
>> | export(importIgnitionRisk)
>> | export(importSpecies)
>> | export(importVegetation)
>> | export(layerExists)
>> | export(layerName)
>> | export(newInDrak)
>> | export(parameter)
>> | export(parmsAcacia)
>> | export(parmsBudget)
>> | export(parmsFire)
>> | export(parmsPinus)
>> | export(parmsRubus)
>> | export(resetOptions)
>> | export(statDistName)
>> | export(suitName)
>> | import(DBI)
>> | import(fireSim)
>> | import(logger)
>> | import(methods)
>> | import(seedDisp)
>> | import(seedGerm)
>> | import(seedProd)
>> | import(sp)
>> | import(spgrass6)
>> `
>>
>> The package builds fine, it installs without problems and works as
>> expected, but when checking it, I get the following error:
>>
>> ,
>> | $ R CMD check ./InDrak_0.1-0.tar.gz
>> | * using log directory
>> ‘/Users/rainerkrug/Documents/Projects/R-Packages/inDrak/InDrak.Rcheck’
>> | * using R version 3.0.1 (2013-05-16)
>> | * using platform: x86_64-apple-darwin10.8.0 (64-bit)
>> | * using session charset: UTF-8
>> | * checking for file ‘InDrak/DESCRIPTION’ ... OK
>> | * checking extension type ... Package
>> | * this is package ‘InDrak’ version ‘0.1-0’
>> | * checki
Re: [Rd] check warning with .onLoad() and setClass()
Dirk Eddelbuettel writes:
> On 4 October 2013 at 12:59, Rainer M Krug wrote:
> | Thanks John
> |
> | that is likely the solution to my problem, but I don't understand
> | how I
> | can use it and I can't find the example in the Rcpp package (I did
> | grep
> | for setLoadAtion on the whole source package of Rcpp, but nothing
> | came up with ). Could you
> | please provide me a link (or the filename) where I can see how to
> | use
> | this function?
>
> Alternatively just call
>
>loadModules("simObj", TRUE)
Hm. loadModule is Rcpp function, but I am only interested in using the
setClass() function, which has nothing to do with Rcpp. I don't even use
Rcpp in the package, only in one which is imported.
>
> in one of the R/*R files, eg in RcppCNPy I load the module from
> R/cnpy.R --
> and it's the sole R statement in that package as everything happens in
> the
> Modules declaration over in in the src/ directory:
>
>edd@max:~$ cat svn/rcpp/pkg/RcppCNPy/R/*
>
>loadModule("cnpy", TRUE)
>
>
>edd@max:~$
>
> If you had several modules, you'd need to issue a loadModules(...) for
> each.
> Oh, and rcpp-devel is still ready, willing and able for Rcpp
> questions. ;-)
Thanks - but unless I am missing something here, this has nothing to do
with Rcpp and only concerns basic package writing. John Chambers only
referred me to an example in Rcpp which I can not find.
And I am definitely going to ask Rcpp questions there.
>
> Hth, Dirk
I guess not much this time - sorry Dirk.
Rainer
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] check warning with .onLoad() and setClass()
Dirk Eddelbuettel writes:
> On 4 October 2013 at 14:15, Rainer M Krug wrote:
> | Hm. loadModule is Rcpp function, but I am only interested in using the
> | setClass() function, which has nothing to do with Rcpp. I don't even use
> | Rcpp in the package, only in one which is imported.
>
> Sorry, assumed Reference Class created via Modules. My bad, and never mind.
>
> But as John said, .onLoad() can be replaces since he made those changes in R
> (and also in Rcpp). See ?setLoadAction, evalOnLoad(), ...
Ok - theat far I folow you. But how do I implement this?
I have now the following .onLoad() function:
,
| .onLoad <- function(libname, pkgname) {
| setClass(
| "inDrak",
| representation(
| init = "SpatialGridDataFrame"
| ),
| contains = "simObj"
| )
| }
`
in the file ./R/onLoad.R in my package.
Now how can I now use the setLoadFunction()? I tried to simply put the
setClass in the setLoadFunction() as follow into the ./R/onLoad.R file:
,
| setLoadFunction( function(libname, pkgname) {
| setClass(
| "inDrak",
| representation(
| init = "SpatialGridDataFrame"
| ),
| contains = "simObj"
| )
| }
`
but this did not work.
So what do I have to do with it? I only find very few examples using
setLoadFunction().
Rainer
>
> Dirk
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SOLVED: check warning with .onLoad() and setClass()
Thanks John and Dirk for your input.
I solved the problem by importing the package "simecol" which defines
the superclass simEcol in the NAMESPACE file with import(simEcol) and to
leave it in the DESCRIPTION file in the Depends section (as the
functions have to be available for the end user).
I reverted back to the .onLoad() function:
,
| .onLoad <- function(libname, pkgname) {
| setClass(
| "inDrak",
| representation(
| init = "SpatialGridDataFrame"
| ),
| contains = "simObj"
| )
| }
`
and it works and does not give an error on R CMD check.
Thanks a lot,
Rainer
John Chambers writes:
> The basic tool is setLoadActions(), which takes a function definition,
> with the package's namespace as its argument. Read ?setLoadActions
>
> There is no such thing as setLoadFunction, as far as the standard code in R.
>
> While you haven't defined "didn't work", an off-the-top-of-the-head
> idea would be something like:
>
> setLoadActions(function(ns) {setClass(., where = ns)})
>
>
> On Oct 4, 2013, at 7:07 AM, Rainer M Krug wrote:
>
>> Dirk Eddelbuettel writes:
>>
>>> On 4 October 2013 at 14:15, Rainer M Krug wrote:
>>> | Hm. loadModule is Rcpp function, but I am only interested in using the
>>> | setClass() function, which has nothing to do with Rcpp. I don't even use
>>> | Rcpp in the package, only in one which is imported.
>>>
>>> Sorry, assumed Reference Class created via Modules. My bad, and never mind.
>>>
>>> But as John said, .onLoad() can be replaces since he made those changes in R
>>> (and also in Rcpp). See ?setLoadAction, evalOnLoad(), ...
>>
>> Ok - theat far I folow you. But how do I implement this?
>>
>> I have now the following .onLoad() function:
>>
>> ,
>> | .onLoad <- function(libname, pkgname) {
>> | setClass(
>> | "inDrak",
>> | representation(
>> | init = "SpatialGridDataFrame"
>> | ),
>> | contains = "simObj"
>> | )
>> | }
>> `
>>
>> in the file ./R/onLoad.R in my package.
>>
>> Now how can I now use the setLoadFunction()? I tried to simply put the
>> setClass in the setLoadFunction() as follow into the ./R/onLoad.R file:
>>
>> ,
>> | setLoadFunction( function(libname, pkgname) {
>> | setClass(
>> | "inDrak",
>> | representation(
>> | init = "SpatialGridDataFrame"
>> | ),
>> | contains = "simObj"
>> | )
>> | }
>> `
>>
>> but this did not work.
>>
>> So what do I have to do with it? I only find very few examples using
>> setLoadFunction().
>>
>> Rainer
>>
>>
>>>
>>> Dirk
>>
>>
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
>> UCT), Dipl. Phys. (Germany)
>>
>> Centre of Excellence for Invasion Biology
>> Stellenbosch University
>> South Africa
>>
>> Tel : +33 - (0)9 53 10 27 44
>> Cell: +33 - (0)6 85 62 59 98
>> Fax : +33 - (0)9 58 10 27 44
>>
>> Fax (D):+49 - (0)3 21 21 25 22 44
>>
>> email: rai...@krugs.de
>>
>> Skype: RMkrug
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] search for variable in package in .GlobalEnv first
Hi First, sorry if I get the terminology wrong, I am still quite new to the concept of using environments and workspaces. Say I have a statement in a package SIM like sim <- TYPE where the variable TYPE is initialized in the package to e.g. "exponential" (SIM::TYPE == "exponential"). Now, I want to give the user the option of specifying the variable TYPE, but to the effect, that if the user does not define a variable TYPE in the user workspace (.GobalEnv), the one in the namespace from the package is used. In other words, I want to look first in the workspace, and then in SIM:: for the variable TYPE. How can do this? Thanks, Rainer -- Rainer M. Krug email: RMKruggmailcom pgpFvdLZpRyLG.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SOLVED: search for variable in package in .GlobalEnv first
Duncan Murdoch writes:
> On 07/10/2013 10:29 AM, Rainer M Krug wrote:
>> Hi
>>
>> First, sorry if I get the terminology wrong, I am still quite new to the
>> concept of using environments and workspaces.
>>
>> Say I have a statement in a package SIM like
>>
>> sim <- TYPE
>>
>> where the variable TYPE is initialized in the package to
>> e.g. "exponential" (SIM::TYPE == "exponential").
>>
>> Now, I want to give the user the option of specifying the variable TYPE,
>> but to the effect, that if the user does not define a variable TYPE in
>> the user workspace (.GobalEnv), the one in the namespace from the
>> package is used.
>>
>> In other words, I want to look first in the workspace, and then in SIM::
>> for the variable TYPE. How can do this?
>
> The rgl package does this when looking for defaults for
> graphics. Here's the code:
>
>
> getr3dDefaults <- function()
> tryCatch(get("r3dDefaults", envir=.GlobalEnv),
> error = function(e) r3dDefaults)
>
> This will find the variable r3dDefaults if it is in the global
> environment or in a package on the search path; if that fails, it
> returns the local one. Since that function is defined in the package,
> it can see the local r3dDefaults variable. You might not want to
> accept anything except what is in .GlobalEnv; in that case, use
> inherits = FALSE in the call to get().
Thanks a lot - works like a charm.
I actually like the ide of searching the searchpath down.
Thanks,
Rainer
>
> Duncan Murdoch
>
<#secure method=pgpmime mode=sign>
--
Rainer M. Krug
email: RMKruggmailcom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating Namespace and locking it during runtime?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I would like to create a Namespace during runtime, and not during loading a package. My reasoning is that I want to be able to store a number of variables and to "protect them from the user" (might be even myself). The code will not be in a package, but will be source()ed. Next step: pass variables from org mode / emacs to R and to protect these variables from accidental change / removal. Any suggestions on how to do this? Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS4C+KAAoJENvXNx4PUvmCVZUIALEi/MfHuGEioPbSpw2TOmcx lw5WCeGlsfQoWFPuX8XZOvc+bE0iv/qz5IuTjHbHrrgdV1Oz0k3ufvukPNhFKr51 r7k3dKJCC5xF0KMXV5sRZYgKc8VL6yGHkrZJw+JrZhmiHnDXiQ41LiPhcd920IU9 68eHMOQKeloiWADPPPseJ7VlWwtMTKOzDem3AdBVL5U3fOFPe8qWy/F/uwuuf6+B NMEYA7z/JxK80Ud6X8sO/1gAiXZsNdzV4Q8i018LUE5mlO1NiAaB0VNKUCSEzAeM FM3+9P99ijjaUhmAl58JYNMkYTcwxHFCOuDPaTvRG0h0JBvg3873AZTY4uLF1p0= =GSUq -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating Namespace and locking it during runtime?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks - looks very promising. Rainer On 01/23/14, 09:23 , Prof Brian Ripley wrote: > See ?lockEnvironment, which ??lock shows as ?bindenv . > > On 22/01/2014 20:52, Rainer M Krug wrote: Hi > > I would like to create a Namespace during runtime, and not during > loading a package. > > My reasoning is that I want to be able to store a number of > variables and to "protect them from the user" (might be even > myself). The code will not be in a package, but will be > source()ed. > > Next step: pass variables from org mode / emacs to R and to > protect these variables from accidental change / removal. > > Any suggestions on how to do this? > > Cheers, > > Rainer > > >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS4NyLAAoJENvXNx4PUvmCXyIH/2+SzGPuvHqBcWBrnRbZV1sV nLa/NUKCgKq74fvDFbkCocOlVo6Cxkd5+r/FCQXpibiMUmgMyJTsABO1VkuPzNeT ACXIwRKaci7/91el5OrvL1HBXcAWVdrYBXV6hO7mRqgp/Ait0G49L5rHekDjOhh0 9EJCi81pyzclnXpiu0IEjD2USVq3+VFKBxIiFTcMX6j8Lnzjud5cfVAhH0AOCqN0 asN+BCzNe43moKv1fxyYnSbXTflx56a6/cCWF+XEPpGTvJGhuaZ/WouvA8AledBt /ViEraWKzvNIcWZAyCbV4aDK83Xu2EJel8cfiXuUUbp2dCZSce3pbifpYUQXqyg= =FT1o -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question re: NA, NaNs in R
removed.
>>
>>
>>
>>
>> >There is one NA but mulitple NaNs.
>> >
>> >And please re-read 'man memcmp': your cast is wrong.
>> >
>> >On 10/02/2014 06:52, Kevin Ushey wrote:
>> >> Hi R-devel,
>> >>
>> >> I have a question about the differentiation between NA and NaN values
>> >> as implemented in R. In arithmetic.c, we have
>> >>
>> >> int R_IsNA(double x)
>> >> {
>> >> if (isnan(x)) {
>> >> ieee_double y;
>> >> y.value = x;
>> >> return (y.word[lw] == 1954);
>> >> }
>> >> return 0;
>> >> }
>> >>
>> >> ieee_double is just used for type punning so we can check the final
>> >> bits and see if they're equal to 1954; if they are, x is NA, if
>> >> they're not, x is NaN (as defined for R_IsNaN).
>> >>
>> >> My question is -- I can see a substantial increase in speed (on my
>> >> computer, in certain cases) if I replace this check with
>> >>
>> >> int R_IsNA(double x)
>> >> {
>> >> return memcmp(
>> >> (char*)(&x),
>> >> (char*)(&NA_REAL),
>> >> sizeof(double)
>> >> ) == 0;
>> >> }
>> >>
>> >> IIUC, there is only one bit pattern used to encode R NA values, so
>> >> this should be safe. But I would like to be sure:
>> >>
>> >> Is there any guarantee that the different functions in R would return
>> >> NA as identical to the bit pattern defined for NA_REAL, for a given
>> >> architecture? Similarly for NaN value(s) and R_NaN?
>> >>
>> >> My guess is that it is possible some functions used internally by R
>> >> might encode NaN values differently; ie, setting the lower word to a
>> >> value different than 1954 (hence being NaN, but potentially not
>> >> identical to R_NaN), or perhaps this is architecture-dependent.
>> >> However, NA should be one specific bit pattern (?). And, I wonder if
>> >> there is any guarantee that the different functions used in R would
>> >> return an NaN value as identical to R_NaN (which appears to be the
>> >> 'IEEE NaN')?
>> >>
>> >> (interested parties can see + run a simple benchmark from the gist at
>> >> https://gist.github.com/kevinushey/8911432)
>> >>
>> >> Thanks,
>> >> Kevin
>> >>
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >
>> >
>> >--
>> >Brian D. Ripley, rip...@stats.ox.ac.uk
>> >Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
>> >University of Oxford, Tel: +44 1865 272861 (self)
>> >1 South Parks Road, +44 1865 272866 (PA)
>> >Oxford OX1 3TG, UKFax: +44 1865 272595
>>
>> __
>> 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
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
d be there to make it easy! My points are: 1) I think the snapshot idea of CRAN is a good idea which should be followed 2) The snapshots should be incorporated at CRAN as I assume that CRAN will be there longer then any third party repository. 3) the default for the user should *not* change, i.e. normal users will always get the newest packages as it is now 4) If this can / will not be done because of workload, storage space, ... commands should be incorporated in a package (preferably which becomes part of the core packages) to store snapshots of installed package and R version information as a human readable text file, but which can be parsed by a second command to re-create this setup. Cheers, and thanks for this important discussion (could have been a GSoC project?), Rainer > > >> Gavin >> A scientist, very much interested in reproducibility of my work and others. > > Michael > In finance, where we call it "Auditability" and care very much as well :-) > > > [[alternative HTML version deleted]] > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgp0EotWauDSe.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
Hadley Wickham writes: >> What would be more useful in terms of reproducibility is the capability of >> installing a specific version of a package from a repository using >> install.packages(), which would require archiving older versions in a >> coordinated fashion. I know CRAN archives old versions, but I am not aware >> if we can programmatically query the repository about this. > > See devtools::install_version(). > > The main caveat is that you also need to be able to build the package, > and ensure you have dependencies that work with that version. The compiling will always be the problem when using older source packages, whatever is done. But for the dependencies: an automatic parsing of the dependencies (DEPENDS, IMPORTS, ...) would help a lot. Together with a command which scans the installed package in the session and stores them in a parsable human readable format so that all packages (with the specified version) required can be installed with one command, and I think the problem would be much closer to be solved. Rainer > > Hadley -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpfAhwo1bQBT.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
This is a long and (mainly) interesting discussion, which is fanning out in many different directions, and I think many are not that relevant to the OP's suggestion. I see the advantages of having such a dynamic CRAN, but also of having a more stable CRAN. I prefer CRAN as it is now, but ion many cases a more stable CRAN might b an advantage. So having releases of CRAN might make sense. But then there is the archiving issue of CRAN. The suggestion was made to move the responsibility away from CRAN and the R infrastructure to the user / researcher to guarantee that the results can be re-run years later. It would be nice to have this build in CRAN, but let's stick at the scenario that the user should care for reproducability. Leaving the issue of compilation out, a package which is creating a custom installation of the R version which includes the source of the R version used and the sources of the packages in a on Linux compilable format, given that the relevant dependencies are installed, would be a huge step forward. I know - compilation on Windows (and sometimes Mac) is a serious problem), but to archive *all* binaries and to re-compile all older versions of R and all packages would be an impossible task. Apart from that - doing your analysis in a Virtual Machine and then simply archiving this Virtual Machine, would also be an option, but only for the more tech savy users. In a nutshell: I think a package would be able to provide the solution for a local archiving to make it possible to re-run the simulation with the same tools at a later stage - although guarantees would not be possible. Cheers, Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
Jari Oksanen writes: > Freezing CRAN solves no problem of reproducibility. If you know the > sessionInfo() or the version of R, the packages used and their > versions, you can reproduce that set up. If you do not know, then you > cannot. You can try guess: source code of old release versions of R > and old packages are in CRAN archive, and these files have dates. So > you can collect a snapshot of R and packages for a given date. This is > not an ideal solution, but it is the same level of reproducibility > that you get with strictly frozen CRAN. CRAN is no the sole source of > packages, and even with strictly frozen CRAN the users may have used > packages from other source. I am sure that if CRAN would be frozen > (but I assume it happens the same day hell freezes), people would > increasingly often use other package sources than CRAN. The choice is > easy if the alternatives are to wait for the next year for the bug fix > release, or do the analysis now and use package versions in R-Forge or > github. Then you could not assume that frozen CRAN packages were used. Agree completely here - the solution would be a package, which is packaging the source (or even binaries?) of your local R setup including R and packages used. The solution is local - not on a server. > > CRAN policy is not made in this mailing list, and CRAN maintainers are > so silent that it hurts ears. +1 > However, I hope they won't freeze CRAN. Yes and no - if they do, we need a devel branch which acts like the current CRAN. > > Strict reproduction seems to be harder than I first imagined: > ./configure && make really failed for R 2.14.1 and older in my office > desktop. To reproduce older analysis, I would also need to install > older tool sets (I suspect gfortran and cairo libraries). Absolutely - let's not go there. And then there is also the hardware issue. > > CRAN is one source of R packages, and certainly its policy does not > suit all developers. There is no policy that suits all. Frozen CRAN > would suit some, but certainly would deter some others. > > There seems to a common sentiment here that the only reason anybody > would use R older than 3.0.3 is to reproduce old results. My > experience form the Real Life(™) is that many of us use computers that > we do not own, but they are the property of our employer. This may > mean that we are not allowed to install there any software or we have > to pay, or the Department of project has to pay, to the computer > administration for installing new versions of software (our > case). > This is often called security. Personally I avoid this by using > Mac laptop and Linux desktop: these are not supported by the > University computer administration and I can do what I please with > these, but poor Windows users are stuck. Nicely put. > Computer classes are also > maintained by centralized computer administration. This January they > had new R, but last year it was still two years old. However, users > can install packages in their personal "folders" so that they can use > current packages even with older R. Therefore I want to take care that > the packages I maintain also run in older R. Therefore I also applaud > the current CRAN policy where new versions of packages are > "backported" to previous R release: Even if you are stuck with stale > R, you need not be stuck with stale packages. Currently I cannot test > with older R than 2.14.2, though, but I do that regularly and > certainly before CRAN releases. If somebody wants to prevent this, > they can set their package to unnecessarily depend on the current > version of R. I would regard this as antisocial, but nobody would ask > what I think about this so it does not matter. > > The development branch of my package is in R-Forge, and only bug fixes > and (hopefully) non-breaking enhancements (isolated so that they do > not influence other functions, safe so that API does not change or > format of the output does not change) are merged to the CRAN release > branch. This policy was adopted because it fits the current CRAN > policy, and probably would need to change if CRAN policy changes. > > Cheers, Jari Oksanen -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgp00NlNd0VYd.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Docker versus Vagrant for reproducability - was: The case for freezing CRAN
Dirk Eddelbuettel writes: > o Roger correctly notes that R scripts and packages are just one issue. >Compilers, libraries and the OS matter. To me, the natural approach these >days would be to think of something based on Docker or Vagrant or (if you >must, VirtualBox). The newer alternatives make snapshotting very cheap >(eg by using Linux LXC). That approach reproduces a full environemnt as >best as we can while still ignoring the hardware layer (and some readers >may recall the infamous Pentium bug of two decades ago). These two tools look very interesting - but I have, even after reading a few discussions of their differences, no idea which one is better suited to be used for what has been discussed here: Making it possible to run the analysis later to reproduce results using the same versions used in the initial analysis. Am I right in saying: - Vagrant uses VMs to emulate the hardware - Docker does not wherefore - Vagrant is slower and requires more space - Docker is faster and requires less space Therefore, could one say that Vagrant is more "robust" in the long run? How do they compare in relation to different platforms? Vagrant seems to be platform agnostic, I can develop and run on Linux, Mac and Windows - how does it work with Docker? I just followed [1] and setup Docker on OSX - loos promising - it also uses an underlying VM. SO both should be equal in regards to reproducability in the long run? Please note: I see these questions in the light of this discussion of reproducability and not in regards to deployment of applications what the discussions on the web are. Any comments, thoughts, remarks? Rainer Footnotes: [1] http://docs.docker.io/en/latest/installation/mac/ -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpCqWmH1aUM1.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
Jari Oksanen writes: > On 21/03/2014, at 10:40 AM, Rainer M Krug wrote: > >> >> >> This is a long and (mainly) interesting discussion, which is fanning out >> in many different directions, and I think many are not that relevant to >> the OP's suggestion. >> >> I see the advantages of having such a dynamic CRAN, but also of having a >> more stable CRAN. I prefer CRAN as it is now, but ion many cases a more >> stable CRAN might b an advantage. So having releases of CRAN might make >> sense. But then there is the archiving issue of CRAN. >> >> The suggestion was made to move the responsibility away from CRAN and >> the R infrastructure to the user / researcher to guarantee that the >> results can be re-run years later. It would be nice to have this build >> in CRAN, but let's stick at the scenario that the user should care for >> reproducability. > > There are two different problems that alternate in the discussion: > reproducibility and breakage of CRAN dependencies. Frozen CRAN could > make *approximate* reproducibility easier to achieve, but real > reproducibility needs stricter solutions. Actual sessionInfo() is > minimal information, but re-building a spitting image of old > environment may still be demanding (but in many cases this does not > matter). > > Another problem is that CRAN is so volatile that new versions of > packages break other packages or old scripts. Here the main problem is > how package developers work. Freezing CRAN would not change that: if > package maintainers release breaking code, that would be frozen. I > think that most packages do not make distinction between development > and release branches, and CRAN policy won't change that. > > I can sympathize with package maintainers having 150 reverse > dependencies. My main package only has ~50, and it is sure that I > won't test them all with new release. I sometimes tried, but I could > not even get all those built because they had other dependencies on > packages that failed. Even those that I could test failed to detect > problems (in one case all examples were \dontrun and passed nicely > tests). I only wish that if people *really* depend on my package, they > test it against R-Forge version and alert me before CRAN releases, but > that is not very likely (I guess many dependencies are not *really* > necessary, but only concern marginal features of the package, but CRAN > forces to declare those). Breakage of CRAN packages is a problem, to which I can not comment much. I have no idea how this could be saved unless one introduces more checks, which nobody wants. CRAN is a (more or less) open repository for packages written by engineers / programmers but also scientists of other fields - and that is the strength of CRAN - a central repository to find packages which conform to a minimal standard and format. > > Still a few words about reproducibility of scripts: this can be hardly > achieved with good coverage, because many scripts are so very ad > hoc. When I edit and review manuscripts for journals, I very often get > Sweave or knitr scripts that "just work", where "just" means "just so > and so". Often they do not work at all, because they had some > undeclared private functionalities or stray files in the author > workspace that did not travel with the Sweave document. One reason why I *always* start my R sessions --vanilla and ave a local initialization script which I call manually. > I think these > -- published scientific papers -- are the main field where the code > really should be reproducible, but they often are the hardest to > reproduce. And this is completely ouyt of the hands of R / CRAN / ... and in the hand of Journals and Authors. But R could provide a framework to make this more easy in form of a package which provides functions to make this a one-command approach. > Nothing CRAN people do can help with sloppy code scientists > write for publications. You know, they are scientists -- not > engineers. Absolutely - and I am also a sloppy scientists - I put my code online, but hope that not many people ask me later about it. Cheers, Rainer > > Cheers, Jari Oksanen >> >> Leaving the issue of compilation out, a package which is creating a >> custom installation of the R version which includes the source of the R >> version used and the sources of the packages in a on Linux compilable >> format, given that the relevant dependencies are installed, would be a >> huge step forward. >> >> I know - compilation on Windows (and sometimes Mac) is a serious >> problem), but to archive *all* binaries and to re-compile all older >> versions of R and all packages would
Re: [Rd] Docker versus Vagrant for reproducability - was: The case for freezing CRAN
Gábor Csárdi writes: > You might want to look at packer as well, which can build virtual machines > from an ISO, without any user intaraction. I successfully used it to build > VMs with Linux, OSX and Windows. It can also create vagrant boxes. You can > specify provisioners, e.g. to install R, or a set of R packages, etc. It is > under heavy development, by the same team as vagrant. I think I am getting lost in these - I looked ad Docker, and it looks promising, but I actually didn't even manage to sh into the running container. Is there somewhere an howto on how one can use these in R, to the purpose discussed in this thread? If not, I really think this would be needed. It is extremely difficult for me to translate what I want to do into the deployment / management / development scenarios discussed in the blogs I have found. Cheers, (a confused) Rainer > > Gabor > > On Fri, Mar 21, 2014 at 9:03 AM, Philippe GROSJEAN < > philippe.grosj...@umons.ac.be> wrote: > >> >> ..<}))>< >> ) ) ) ) ) >> ( ( ( ( (Prof. Philippe Grosjean >> ) ) ) ) ) >> ( ( ( ( (Numerical Ecology of Aquatic Systems >> ) ) ) ) ) Mons University, Belgium >> ( ( ( ( ( >> .. >> >> On 21 Mar 2014, at 10:59, Rainer M Krug wrote: >> >> > Dirk Eddelbuettel writes: >> > >> >> o Roger correctly notes that R scripts and packages are just one issue. >> >> Compilers, libraries and the OS matter. To me, the natural approach >> these >> >> days would be to think of something based on Docker or Vagrant or (if >> you >> >> must, VirtualBox). The newer alternatives make snapshotting very >> cheap >> >> (eg by using Linux LXC). That approach reproduces a full environemnt >> as >> >> best as we can while still ignoring the hardware layer (and some >> readers >> >> may recall the infamous Pentium bug of two decades ago). >> > >> > These two tools look very interesting - but I have, even after reading a >> > few discussions of their differences, no idea which one is better suited >> > to be used for what has been discussed here: Making it possible to run >> > the analysis later to reproduce results using the same versions used in >> > the initial analysis. >> > >> > Am I right in saying: >> > >> > - Vagrant uses VMs to emulate the hardware >> > - Docker does not >> > >> Yes. >> >> >> > wherefore >> > - Vagrant is slower and requires more space >> > - Docker is faster and requires less space >> > >> It depends. For instance, if you run R in VirtualBox under Windows, it may >> run faster depending on the code you run and, say, the Lapack library used. >> On Linux, you typically got R code run in the VM 2-3% slower than natively, >> but In a Windows host, most of my R code runs faster in the VM... But yes, >> you need more RAM. >> >> With Vagrant, you do not need to keep you VM once you don't use it any >> more. Then, disk space is shrunk down to a few kB, corresponding to the >> Vagrant configuration file. I guess the same is true for Docker? >> >> A big advantage of Vagrant + VirtualBox is that you got a very similar >> virtual hardware, no matter if your host system is Linux, Windows or Mac OS >> X. I see this as a good point for better reproducibility. >> >> >> > Therefore, could one say that Vagrant is more "robust" in the long run? >> > >> May be,... but it depends almost entirely how VirtualBox will support old >> VMs in the future! >> >> PhG >> >> > How do they compare in relation to different platforms? Vagrant seems to >> > be platform agnostic, I can develop and run on Linux, Mac and Windows - >> > how does it work with Docker? >> > >> > I just followed [1] and setup Docker on OSX - loos promising - it also >> > uses an underlying VM. SO both should be equal in regards to >> > reproducability in the long run? >> > >> > Please note: I see these questions in the light of this discussion of >> > reproducability and not in regards to deployment of applications what >> > the discussions on the web are. >> > >> > Any comments, thoughts, remarks? >> > >> > Rainer >> > >> > >> > Footnotes: >> > [1] http://docs.docker.io/en/latest/installation/mac/ >> > >> > -- >> > Rainer M. Krug >> > email: Rainerkrugsde >> > PGP: 0x0F52F982 >> > __ >> > 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 >> > > [[alternative HTML version deleted]] > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpiXFN9ZrFux.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Docker versus Vagrant for reproducability - was: The case for freezing CRAN
Thanks everybody for their input - interesting suggestions and useful information - thanks. But I am still struggling to use this information. What I got so far: 1) I have decided to try docker [1] 2) Installed docker and boot2docker on a Mac via homebrew and it works 3) I found some Dockerfiles to create an image with R and ssh 4) The dockerfile runs and creates the image 5) I can interactively connect to the image by using bash and R is running there 5) As I am using emacs / ess, I want to use ssh do R stuff (other suggestions welcome) Problems: 1) I don't manage to connect to the running docker image following [2] - I even managed to freeze my computer while trying. 2) Even if I could, I understand that the ssh port would be different each time - not very nice. Is there a way of setting the port? Questions: 1) Am I right in saying, that I have to use ssh to access the running image, or is there a (faster?) alternative? I mean - I am working locally and I don't need any encryption. 2) Would Vagrant make the process easier? And finally: I think it would be great if this information could be collected in a wiki page, as I did not find anything about the usage scenario of docker / vagrant discussed here - I will certainly see that I blog about my tries. Cheers, Rainer Kirill Müller writes: > On 03/22/2014 02:10 PM, Nathaniel Smith wrote: >> On 22 Mar 2014 12:38, "Philippe GROSJEAN" >> wrote: >>> On 21 Mar 2014, at 20:21, Gábor Csárdi wrote: >>>> In my opinion it is somewhat cumbersome to use this for everyday work, >>>> although good virtualization software definitely helps. >>>> >>>> Gabor >>>> >>> Additional info: you access R into the VM from within the host by ssh. >> You can enable x11 forwarding there and you also got GUI stuff. It works >> like a charm, but there are still some problems on my side when I try to >> disconnect and reconnect to the same R process. I can solve this with, say, >> screen. However, if any X11 window is displayed while I disconnect, R >> crashes immediately on reconnection. >> >> You might find the program 'xpra' useful. It's like screen, but for x11 >> programs. >> >> -n > I second that. However, by default, xpra and GNU Screen are not aware > of each other. To connect to xpra from within GNU Screen, you usually > need to set the DISPLAY environment variable manually. I have > described a solution that automates this, so that GUI applications > "just work" from within GNU Screen and also survive a disconnect: > http://krlmlr.github.io/integrating-xpra-with-screen/ . > > > -Kirill > Footnotes: [1] https://www.docker.io [2] http://docs.docker.io/en/latest/examples/running_ssh_service/ -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpECO52k0Gfp.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Docker versus Vagrant for reproducability - was: The case for freezing CRAN
Forgot: My Dockerfiloe is on github: https://github.com/rkrug/R-docker Rainer M Krug writes: > Thanks everybody for their input - interesting suggestions and useful > information - thanks. > > But I am still struggling to use this information. What I got so far: > > 1) I have decided to try docker [1] > 2) Installed docker and boot2docker on a Mac via homebrew and it works > 3) I found some Dockerfiles to create an image with R and ssh > 4) The dockerfile runs and creates the image > 5) I can interactively connect to the image by using bash and R is > running there > 5) As I am using emacs / ess, I want to use ssh do R stuff (other > suggestions welcome) > > Problems: > 1) I don't manage to connect to the running docker image following [2] - > I even managed to freeze my computer while trying. > 2) Even if I could, I understand that the ssh port would be different each > time - not very nice. Is there a way of setting the port? > > Questions: > > 1) Am I right in saying, that I have to use ssh to access the running > image, or is there a (faster?) alternative? I mean - I am working > locally and I don't need any encryption. > > 2) Would Vagrant make the process easier? > > And finally: > > I think it would be great if this information could be collected in a > wiki page, as I did not find anything about the usage scenario of docker > / vagrant discussed here - I will certainly see that I blog about my > tries. > > Cheers, > > Rainer > > Kirill Müller writes: > >> On 03/22/2014 02:10 PM, Nathaniel Smith wrote: >>> On 22 Mar 2014 12:38, "Philippe GROSJEAN" >>> wrote: >>>> On 21 Mar 2014, at 20:21, Gábor Csárdi wrote: >>>>> In my opinion it is somewhat cumbersome to use this for everyday work, >>>>> although good virtualization software definitely helps. >>>>> >>>>> Gabor >>>>> >>>> Additional info: you access R into the VM from within the host by ssh. >>> You can enable x11 forwarding there and you also got GUI stuff. It works >>> like a charm, but there are still some problems on my side when I try to >>> disconnect and reconnect to the same R process. I can solve this with, say, >>> screen. However, if any X11 window is displayed while I disconnect, R >>> crashes immediately on reconnection. >>> >>> You might find the program 'xpra' useful. It's like screen, but for x11 >>> programs. >>> >>> -n >> I second that. However, by default, xpra and GNU Screen are not aware >> of each other. To connect to xpra from within GNU Screen, you usually >> need to set the DISPLAY environment variable manually. I have >> described a solution that automates this, so that GUI applications >> "just work" from within GNU Screen and also survive a disconnect: >> http://krlmlr.github.io/integrating-xpra-with-screen/ . >> >> >> -Kirill >> > > > Footnotes: > [1] https://www.docker.io > > [2] http://docs.docker.io/en/latest/examples/running_ssh_service/ -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpotOzBykSRL.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] creating namespaces outside packages
Hi I would like to use namespaces outside packages, but I could not find any references on how to do it (only a thread [1] which says "use a package"). Using a package is not possible in my case, as I am passing variables from org-mode / emacs to R and would like to avoid name clashes. This is a dynamic process, and each time the code is evaluated, the variable can be different. I am putting them at the moment into an environment which is locked, but I would like to avoid name clashes, so the idea of using environments. So: is there a way to create a namespace and populate it as I can do with an environment? Thanks, Rainer Footnotes: [1] http://r.789695.n4.nabble.com/create-namespace-without-creating-a-package-td3485968.html -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 pgpSpia44kJmE.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SOLVED: creating namespaces outside packages
Duncan Murdoch writes:
> On 28/03/2014, 7:01 AM, Rainer M Krug wrote:
>> Hi
>>
>> I would like to use namespaces outside packages, but I could not find
>> any references on how to do it (only a thread [1] which says "use a
>> package"). Using a package is not possible in my case, as I am passing
>> variables from org-mode / emacs to R and would like to avoid name
>> clashes. This is a dynamic process, and each time the code is evaluated,
>> the variable can be different.
>>
>> I am putting them at the moment into an environment which is locked, but
>> I would like to avoid name clashes, so the idea of using environments.
>>
>> So: is there a way to create a namespace and populate it as I can do
>> with an environment?
>
> I don't know what you think is the difference between a namespace and
> an environment. I would say a namespace is one of the environments
> associated with a package, i.e. it's just an environment in a
> particular context.
>
> So depending on what you are trying to accomplish, it may be fine to
> just set up an environment. Why do you think that won't work?
An environment is what I use at the moment, but there is one aspect I
was not happy with: accessing the original value in the environment when
it is overwritten in a higher environment in the search path. But then I
discovered then notation of using $:
,
| env <- new.env()
| assign("value", 99, env)
| attach(env)
| value <- FALSE
| value
| env$value
`
So I can access the original value. I only thought initially about
the :: (or is it :::) to access the objects in a namespace, which do not
work for an environment.
So: Different solution and works perfectly.
Thanks,
Rainer
>
> Duncan Murdoch
>
--
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982
pgplciMLn7RLU.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Access variable in attached but removed object
How can I access an object in an attached but deleted environment, when the object also exists in the .GolbalEnv? I hope the example below makes the question clear: --8<---cut here---start->8--- tmp <- attach(what=NULL, name="org:variables") tmp$test = 13 rm(tmp) test # > 13 test <- 24 test # > 24 ls(all=TRUE) # > character(0) # # how can I access the variable test in the object org:variables in the # search path? # rm(test) test # > 13 --8<---cut here---end--->8--- Any suggestions? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpGXsRAdJ4qT.pgp Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Access variable in attached but removed object
Duncan Murdoch writes:
> On 09/05/2014, 6:54 AM, Rainer M Krug wrote:
>>
>> How can I access an object in an attached but deleted environment, when
>> the object also exists in the .GolbalEnv?
>
> Attaching a variable to the search list generally makes a copy of it,
> so it can't be "attached but deleted". However, "making a copy" of an
> environment just copies the reference to it, so your environment still
> exists on the search list, it just doesn't have a name in the global
> environment.
I was aware that my wording was not the best - your explanation makes
the whole process much clearer - thanks.
>
>>
>> I hope the example below makes the question clear:
>>
>> --8<---cut here---start->8---
>> tmp <- attach(what=NULL, name="org:variables")
>> tmp$test = 13
>> rm(tmp)
>> test
>> # > 13
>> test <- 24
>> test
>> # > 24
>> ls(all=TRUE)
>> # > character(0)
>
> I don't know why you would have seen character(0) here. You should
> have seen "test" in the list, because you created it a couple of lines
> earlier.
You are right. Wrong copy - paste. My fault.
>
>> #
>> # how can I access the variable test in the object org:variables in the
>> # search path?
>> #
>> rm(test)
>> test
>> # > 13
>> --8<---cut here---end--->8---
>>
>> Any suggestions?
>
> You can use assign, or get a reference to the environment using
> as.environment("org:variables"), and access it within that. For
> example,
>
> assign("test", 24, pos="org:variables")
>
> or
>
> e <- as.environment("org:variables")
> e$test <- 24
Perfect - that is what I was looking for.
Both will work perfectly in my case.
Thanks lot,
Rainer
>
> Duncan Murdoch
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
pgpwlcZ10K4Mk.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.packages with ask = FALSE will sometimes ask about updates
Richard Cotton writes: > Today while running update.packages(ask = FALSE), R stopped to ask me > a question: > > There are binary versions available but the source versions are later: > binary source needs_compilation > KernSmooth 2.23-13 2.23-14 TRUE > mixture1.2 1.3 TRUE > > Do you want to install from sources the packages which need compilation? > y/n: > > > update.packages calls install.packages which calls getDependencies, > which was where there question originated. > > It seems to me that if I've set ask = FALSE, stopping to ask questions > is a bug. There are a few possible interpretations of the best > behaviour though, so I thought I'd put it up for discussion here > before (maybe) submitting as a bug. > > 1. The existing behaviour is correct: the case of out-of-date binaries > causes a special situation, and R is right to ask. > > 2. ask = FALSE means I want all updates, so don't ask me any > questions, just install all possible updates. > > 3. ask = FALSE means that I don't want any interactivity, but > out-of-date binaries is a special case, so R should just fail to > update these packages, with an error message stating that they need to > be manually updated. > > 4. There should be an extra argument that decides between the some or > all of the behaviours described in 1, 2 and 3. > > Which of these options is best? (Or have I missed an option?) I am with R (and youre first option). If I ask for binaries, I want binaries (because I can not install from source, because I want them fast, because I have locally different compilers, ...). So to silently try to install sources instead of binaries could be completely wrong. Although unlikely, the same applies the other way round, when I ask for source. THe other possible option would be 4, but instead of failing (the binaries might still be newer then the installed versions) to give a warning - as it is not more: For the settings asked for, these are, the newest versions are installed - but be warned that there are newer versions from source. Thinking about it now, option 4 with warning should be the way to go. Cheers, Rainer > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MetaCran website v1.0.0-alpha
Gábor Csárdi writes: > Dear All, > > [ I was wondering if this should have gone to the new mailing list. Maybe. ] > > As some of you maybe know from my earlier posts, I am building a simple > search engine for R packages. Now the search engine has a proper web site, > where you can also browse CRAN packages. > > http://www.r-pkg.org/ > > As I see the value is in > 1. package search (search box on top right) > 2. APIs, see http://www.r-pkg.org/services > > It is in alpha version, meaning that things seem to work, some pages are a > bit slow and there are a lot of glitches to fix. I had a quick peek, and it looks really nice! I particularly think the github integration for diff-ing versions can be very use full! It might be an idea, to also add R itself to the github repo for diff-ing? Thanks a lot, Rainer > > Please tell me what you think. > > Best, > Gabor > > [[alternative HTML version deleted]] > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote: > Dear R developers, > > I am seeking advice on some $subject matter. > > My package will have an update soon, that is not backward compatible > with the current version. It will likely break much of the existing > code. Many (~50) packages depend on 'igraph' and they, too, will most > probably break with the new version. > Don't forget the indirect dependencies - might be many more. One approach used by e.g. ggplot and roxygen, is to call the new package ggplot2 or roxygen2. This would not break old packages. > My intended solution is, that I create a snapshot of the current > package, under another name (igraph0), and ask package maintainers to > depend on that version. Then, after a short time, I'll update the > current igraph version. > I would rather give the new one a a new name by appending the 2 > Do you see any drawbacks of this solution? Is there some existing > practice for situations like this? Suggestions are greatly > appreciated. > Well - they require immediate action by the package maintainers. Yo could put a warning in the original iplot package, that the package is not updated any more and that a switch to iplot 2 is suggested. So no immediate action by the package maintainers is required. Cheers, Rainer > Btw. an alternative would be to ask them to depend on the exact > current version of the package. This is an easier solution, but it > won't give people the opportunity to load both versions of the package > at the same time, if they want to run their old code. > > Thank You, Best Regards, > Gabor > > -- > Gabor Csardi Dept. Statistics, Harvard University > > __________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: 'igraph' package update and backward compatibility
Sorry - not iplot, but igraph. On Thu, Oct 20, 2011 at 9:21 AM, Rainer M Krug wrote: > > > On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote: > >> Dear R developers, >> >> I am seeking advice on some $subject matter. >> >> My package will have an update soon, that is not backward compatible >> with the current version. It will likely break much of the existing >> code. Many (~50) packages depend on 'igraph' and they, too, will most >> probably break with the new version. >> > > Don't forget the indirect dependencies - might be many more. > > One approach used by e.g. ggplot and roxygen, is to call the new package > ggplot2 or roxygen2. This would not break old packages. > > >> My intended solution is, that I create a snapshot of the current >> package, under another name (igraph0), and ask package maintainers to >> depend on that version. Then, after a short time, I'll update the >> current igraph version. >> > > I would rather give the new one a a new name by appending the 2 > > >> Do you see any drawbacks of this solution? Is there some existing >> practice for situations like this? Suggestions are greatly >> appreciated. >> > > Well - they require immediate action by the package maintainers. Yo could > put a warning in the original iplot package, that the package is not updated > any more and that a switch to iplot 2 is suggested. So no immediate action > by the package maintainers is required. > > Cheers, > > Rainer > > >> Btw. an alternative would be to ask them to depend on the exact >> current version of the package. This is an easier solution, but it >> won't give people the opportunity to load both versions of the package >> at the same time, if they want to run their old code. >> >> Thank You, Best Regards, >> Gabor >> >> -- >> Gabor Csardi Dept. Statistics, Harvard >> University >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Stellenbosch University > South Africa > > Tel : +33 - (0)9 53 10 27 44 > Cell: +33 - (0)6 85 62 59 98 > Fax (F): +33 - (0)9 58 10 27 44 > > Fax (D):+49 - (0)3 21 21 25 22 44 > > email: rai...@krugs.de > > Skype: RMkrug > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in documentation of "merge"
Hi there seems to be an error in the documentation of the "merge" function: Arguments: x, y: data frames, or objects to be coerced to one. by, by.x, by.y: specifications of the common columns. See Details. all: logical; all = L is shorthand for all.x = L and all.y = L. The "L" should be a T or a TRUE. Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in documentation of "merge"
On Fri, Nov 4, 2011 at 1:20 PM, peter dalgaard wrote: > > On Nov 4, 2011, at 13:11 , Rainer M Krug wrote: > > > Hi > > > > there seems to be an error in the documentation of the "merge" function: > > > > Arguments: > > > >x, y: data frames, or objects to be coerced to one. > > > > by, by.x, by.y: specifications of the common columns. See Details. > > > > all: logical; all = L is shorthand for all.x = L and all.y = > > L. > > > > > > The "L" should be a T or a TRUE. > > > I think it's on purpose: L indicates a logical value, TRUE _or_ FALSE. > Makes sense - In this case, I would suggest to add, "where L is either TRUE or FALSE" or similar to clarify. > > -pd > -- > Peter Dalgaard, Professor > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Case: package removed from CRAN, but not orphaned
2011/11/25 Uwe Ligges
> On 25.11.2011 11:56, Pfaff, Bernhard Dr. wrote:
>
>> Dear R-Devel subscriber,
>>
>> I would like to raise a topic and ask for your advice, guidance.
>> Today on R-help an issue with a certain package popped up that has been
>> removed from CRAN, because it failed the checks and/or the dependencies are
>> not any longer available. The package maintainer has been alerted to this
>> issue a couple of times and kindly asked to fix the code, such that it
>> fullfills the CRAN requirements. However, neither a fix is applied, nor has
>> the package been orphaned such that someone else could take over the
>> ownership and rectify the package.
>> In principal, and if I am not mistaken, one could simply take the code,
>> fix it and release it (the package is under GPL-2). However, I would
>> consider this as a rather rude approach. Hence, my question would be, if
>> the R Core team can take the initiative, to declare the package as being
>> orphaned after a 'warning period' has been elapsed in which the current
>> maintainer is kindly asked to fix his package. Would it be feasible to ask
>> R Core to orphan a package?
>>
>> Best,
>> Bernhard
>>
>> ps: Incidentally, I am aware of the new 'orphaned package rules', in
>> particular under the rubrique 'Possible reasons for orphanizing a package',
>> point 2). In the case of the package in question, the maintainer does
>> respond to emails, but either seems to lack action and/or has a different
>> time scale and awareness of time.
>>
>
>
> As Duncan wrote already, CRAN is not run by R-core - as you probably know,
> I have already maintained parts of CRAN for quite some time before I became
> core member.
>
> Let me as one of the CRAN maintainers add:
>
> We know that orphaning would be a nice hint to the community, but it takes
> some work and given we have >> 3000 packages, many of them not well
> maintained, we have to archive or orphan many packages a year nowadays. Due
> the already huge amount of work CRAN maintenance generates, we simply
> cannot invest more time given the time constraints.
>
> Note that we archive packages if a maintainer asks us to do so or if the
> maintainer is unresponsive on our requests to fix the package. Since we as
> CRAN maintainers were unsuccessful to contact or convince the maintainer to
> fix, we typically won't invest more time/work on such a package.
>
> Of course, if someone wants to take over an archived package and cannot
> get a response from the maintainer (but first try to do so yourself!) then
> a request to take over as maintainer can be sent to CRAN.
>
> Currently we are working on a new CRAN policy document that will soon be
> published. This document may clarify some further questions and establishes
> some stricter policies to reduce the workload of CRAN maintainers.
>
Just as an idea to make sure that CRAN only contains maintained packages
with a maintainer who feels responsible: Would it be feasible to introduce
a system, so that each year (or for each release of a new version of R) the
maintainers are automatically contacted via email and must reply to have
their packages included in the new spring cleaned version of CRAN? This
process could be automated, including the email confirmations (like mailing
list subscriptions) and the non-maintained packages could be relocated to a
second CRAN or marked as "will be removed at next springclean"? This would
make sure that CRAN contains only "active" packages.
Cheers,
Rainer
>
> Best wishes,
> Uwe Ligges
>
>
>
>
>
>
>> *
>> Confidentiality Note: The information contained in this ...{{dropped:10}}
>>
>> ______**____
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in rank(), order(), is.unsorted() on character vector
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/11 15:48, Joris Meys wrote:
> @Barry : regardless of whether '_' comes before or after '1' , it
> should be consistent. Adding an 'a' shouldn't shift '_' from
> before '1' to between '1' and '2', that's clearly an error. The
> help files are not stating anything about that. The only thing I
> can imagine, is that '_' gets ignored (in that case 19a would rank
> before 1a).
>
> This said, I can't reproduce.
I can:
> x <- c("_1_", "1_9", "2_9") xa <- paste(x,'a',sep='') rank(x)
[1] 1 2 3
> rank(xa)
[1] 2 1 3
> sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 14.0
year 2011
month 10
day31
svn rev57496
language R
version.string R version 2.14.0 (2011-10-31)
>
Interesting.
Rainer
>
>> x <- c("_1_", "1_9", "2_9") xa <- paste(x,'a',sep='') rank(x)
> [1] 1 2 3
>> rank(xa)
> [1] 1 2 3
>
>> sessionInfo()
> R version 2.14.0 Patched (2006-00-00 r0) Platform:
> i386-pc-mingw32/i386 (32-bit)
>
> locale: [1] LC_COLLATE=English_United States.1252
> LC_CTYPE=English_United States.1252LC_MONETARY=English_United
> States.1252 [4] LC_NUMERIC=C
> LC_TIME=English_United States.1252
>
> attached base packages: [1] grDevices datasets splines graphics
> stats tcltk utils methods base
>
> other attached packages: [1] svSocket_0.9-51 TinnR_1.0.3
> R2HTML_2.2 Hmisc_3.8-3 survival_2.36-9
>
> loaded via a namespace (and not attached): [1] cluster_1.14.1
> grid_2.14.0 lattice_0.19-33 svMisc_0.9-63 tools_2.14.0
>
>
> 2011/12/7 Hervé Pagès :
>> Hi,
>>
>> This looks OK:
>>
>>> x <- c("_1_", "1_9", "2_9") rank(x)
>> [1] 1 2 3
>>
>> But this does not:
>>
>>> xa <- paste(x, "a", sep="") xa
>> [1] "_1_a" "1_9a" "2_9a"
>>> rank(xa)
>> [1] 2 1 3
>>
>> Cheers, H.
>>
>>> sessionInfo()
>> R version 2.14.0 (2011-10-31) Platform: x86_64-unknown-linux-gnu
>> (64-bit)
>>
>> locale: [1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C [3]
>> LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8 [5]
>> LC_MONETARY=en_CA.UTF-8LC_MESSAGES=en_CA.UTF-8 [7] LC_PAPER=C
>> LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11]
>> LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages: [1] stats graphics grDevices utils
>> datasets methods base
>>
>> loaded via a namespace (and not attached): [1] tools_2.14.0
>>
>>
>> -- Hervé Pagès
>>
>> Program in Computational Biology Division of Public Health
>> Sciences Fred Hutchinson Cancer Research Center 1100 Fairview
>> Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024
>>
>> E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206)
>> 667-1319
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7fgQMACgkQoYgNqgF2egrjvACffUhSUEriYGSQY8MstwVbvAj6
+w8An1FrwX0YXqDUqDoRq/zW31FW7WOj
=zQr1
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Version control (git, mercurial) for R packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CCd to r-devel as suggested by Peter.
On 09/02/12 19:28, Hadley Wickham wrote:
>>> I'm exploring using a version control system to keep better
>>> track of changes to the packages I maintain. I'm leaning
>>> towards git (although mercurial also looks good) but am not
>>> sure what is the best way to set up the repository. It seems I
>>> can't set the repository directly within the R package main
>>> directory, since it will be incompatible with the standard
>>> package structure. I can set the repository in the directory
>>> that contains my R packages, but then I have a single
>>> repository for all of my packages, which is not ideal.
>>
>> Git is nice - but if you ar looking for simplicity in usage for
>> R packages, I guess r-forge and rforge are the easiest to use.
>
> I think git + github is substantially easier to use, especially if
> you want to incorporate patches from the community.
>
>> But I would be interested in the workflow when using github as
>> the main VCS.
>
> The thing that has made this really successful for me is the
> install_github function in devtools. Then it's easy for people to
> try out development versions:
>
> install.packages("devtools") library(devtools)
> install_github("myrepo", "myusername")
Thanks Hadley - I should definitely look closer into the devtools
package - there really seem to be some gems in there.
One example is this function - sounds perfect for small scale usages
and for developers.
But what I was thinking about (in my other post as well) is to include
github (or any other git repo provider) into r-forge for the automatic
creation of packages.
So is there an easy way to kind of push a certain revision up to
r-forge to have the automatic builds?
One could do it manualy, but automatic would be so much nicer.
>
> This requires a working R development environment but thanks to
> the hard work of Simon Urbanek, Duncan Murdoch, Brian Ripley and
> others, this is a one-install process on all major platforms.
True - no problem for developers.
Cheers,
Rainer
>
> Hadley
>
>
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk800TcACgkQoYgNqgF2ego0QgCfcDIpUlxmVHfYMHi/IlCNKSJ3
1sIAnjQEmBYoTXIE5SlvRUqs/eAioibC
=38uA
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Version control (git, mercurial) for R packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/02/12 22:05, Davor Cubranic wrote: > On February 10, 2012 09:11:35 AM Rainer M Krug wrote: >> But what I was thinking about (in my other post as well) is to >> include github (or any other git repo provider) into r-forge for >> the automatic creation of packages. >> >> So is there an easy way to kind of push a certain revision up to >> r-forge to have the automatic builds? One could do it manualy, >> but automatic would be so much nicer. > > With Git, it is possible to add a remote branch that points to a > Subversion repository. That way, you do your work on Github, and > when you're ready to release, just push your changes to R-Forge > SVN. > > Details: http://cameron.bracken.bz/git-with-r-forge > > Davor Thanks - then I'll look into it again - hope I'll understand it this time. Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk84ynEACgkQoYgNqgF2egqsOgCeOUeo0asKMn59eDaO0l/gzZyU Nd0AoIGo96eBbV+01ymBmrxN3s5I2we0 =kaBh -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] requesting a new SIG mailing list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/02/12 17:30, Mauricio Zambrano-Bigiarini wrote: > Dear R developers, > > Due to the increasing use R in hydrology and other close-related > environmental sciences, I would like to ask if it would be possible > to create a new Special Interest Group mailing list, called > 'R-sig-hydro', specially devoted those topics. If possible to do > so, I'd offer myself to maintain such mailing list (if needed). I think it would be more useful to use the R-sig-geo for that, as hydrology (please correct me if I am wrong - I am not an expert in hydrology) is mainly spatial. A fragmentation of the lists would need to duplicate effort by members. Cheers, Rainer > > > Thanks in advance, > > Mauricio Zambrano-Bigiarini > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk86HRQACgkQoYgNqgF2egp1pwCfXrUJEBhQ8+50iwv7iYEZXa1C 7l4Anj9EmGCL3QE61VGZ/bw+/3r8n5b4 =bVRp -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Deprecating partial matching in $.data.frame
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/03/13 17:58, Hadley Wickham wrote: > On Wed, Mar 20, 2013 at 11:26 AM, peter dalgaard wrote: >> >> On Mar 20, 2013, at 16:59 , William Dunlap wrote: >> >>> Will you be doing the same for attribute names? >> >> Not at this point. > > It would be really nice to have consistent behaviour across argument names, > attributes, lists > and data frames, at least for R CMD check. I agree with Hadley that consistency is quite important. This is especially true for data.frames and lists, as this concerns the data itself, and not names or attributes of the data. I would very much like to see at least at the level of R CMD check warnings for *all* partial matching so that they can be ironed out before in the next stage warnings are give to the user (as mentioned by Milan). I was bitten at least once by a bug, which cost me quite some time to figure out, caused by partial completion and would very much like to see it go (or at least have the option to show warnings if it occurs). Cheers, Rainer > > Hadley > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRSsQOAAoJENvXNx4PUvmC7zkH/Rp0yFMmgQD9D2Z2EpWm5vGR T0ojk8WKCeqoGY4IKpCPP0rSKJqPI0HxjdAplOclFSdfBaCDrHdALLaxzqJWG6TJ 346A/lAgdgbJWNTTWMXiXcq2vqDKAvoOVhZ/A1YDo7CzjZsgpcBPzmUZREFNSDKu TeFNM29GgLIaQ2JqV6wRPQee/j36+iLpcCfACTdsXs0H/kRkcogV96g75OTGsxJr 9pZRzOQpH0fv9DsdLGkOCO1twZ+XtWOKSCmTTcOJ97wBWcYk80jrwJObKFG7qMz7 VVoz38hWjgLKj9RRKSLtEtIfUhNogvT5bayPO3ZBD1jDx8qRfm8BtNV+ofEvnd0= =akLx -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ess completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/03/13 13:30, Terry Therneau wrote: > The thread is strange to me as well, since completion is logically impossible > for my Sweave > files. - an emacs buffer is open working on an .Rnw file - there is no copy > of R running > anywhere on the machine - the code chunk in the .Rnw file refers to a R data > object saved > somewhere else Of course it cannot do "name completion" on a bit of code I'm > writing, lacking > omniscient powers. Emacs is good but not that good :-) > > The ESS manual section 12.1 states that for .R files it has "completion of > object names and > file names". I'm puzzled by exactly what this means, since it is logically > impossible (without > a running R session) to do this in general. Linking an .Rnw file to an > inferior R process > doesn't make sense to me. > > However, I think it's time to move this sub-thread off of R-devel. Respond > to me privately > about the answer or the proper list for this discussion. If anybody wants to continue this ESS discussion: The proper list is the ESS mailing list: https://stat.ethz.ch/mailman/listinfo/ess-help See you there, Rainer > > Terry T > > On 03/22/2013 06:00 AM, r-devel-requ...@r-project.org wrote: >> This thread is strange for me to read as I've been getting completion of >> object names, >> function arguments names, and whatnot in ESS buffers for as long as I can >> have been using it. >> And I'm only on ESS 12.09. >> >> Perhaps you need to set `ess-use-R-completion` to non-nil. Or check the >> value of >> `completion-at-point-functions`. Mine is '(ess-roxy-tag-completion >> ess-filename-completion >> ess-object-completion t) >> >> Peter > > __ R-devel@r-project.org mailing > list > https://stat.ethz.ch/mailman/listinfo/r-devel - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRTF8CAAoJENvXNx4PUvmCrSQH/inP6c5JT+YEJYDEGOkLQOiA 8GLGzgCdO+iekF1EMrKVvcPjim14gRu+y2HcryxMO44w1gIutcY2wpq6m7OYvCXI BV40TjKut6nLzopx0IWVr0vX+mA5IybKiziup+lSS86gb5E8QNRVlBFIw3Xp2TXP rMlS6kkNiQR6y94lwdnUJTy/FerqsV9sQNnNUNipTPt9coL4qISyl1TDoDImrtgM kCG/kSoUnazzldH39qHgfEJb4rhgCLISNFKbPmtCuCbKh+iF0bHJF4rlEXrSkiRu GsmfV1Ln3hWmYijtOygHUlmeSiiVTZVVtfXA5oXrW/GXVvDCYEkSTDuu3JbIj7o= =DJwz -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rf_errorcall - translate to Pascal
Hans-Peter wrote: > Hello! > > I (try to) convert the external R header files to Pascal (Delphi). At > one place I stumbled over a macro that uses a method that is not . . . Sounds interesting - Could you keep me updated about your progress? I would be interested in the header files to use them in the analysis of simulations from Delphi. Rainer -- -- Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology University of Stellenbosch Matieland 7602 South Africa email:[EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
