Re: [Rd] Function to recognise convert dates between gregorian and other calendars (e.g. Persian)?
Hi Ted, > > Many thanks for the suggestion. I'm afraid I'm not from a programming > background at all, hence I wouldn't even know what software to paste the > c-code into, much less how to apply it to my column of dates. I have been > using R for a few years but very much as a user rather than developer - so > I'm comfortable with R syntax but syntax in other languages is pretty alien > to me. Actually the data will be entered into an MS Access database - I've > tried asking whether there is a suitable workaround in MS access forums as > well, but so far no joy - not sure if it is possible to somehow paste the C > code in there - if so would need some detailed instructions on how to do > this. > > I hadn't thought to check out the R extensions before, if this is > straightforward I'll give it a go... > > Thanks and best wishes, > Amy > > > On Wed, Jan 7, 2009 at 5:20 PM, Ted Byers wrote: > >> On Wed, Jan 7, 2009 at 10:23 AM, Amy Mikhail >> wrote: >> >>> Dear list, >>> >>> I will shortly have some data that contains numeric dates in the Persian >>> / >>> Jalali calendar format, which I would like to convert to gregorian. At >>> the >>> moment there doesn't seem to be a function for this in R, but it would be >>> great if someone could come up with same - I would attempt it but the >>> algorithm is very complex and this is also way beyond my fairly >>> rudimentary >>> knowledge of R. >>> >>> How do you feel about mixed language programming? >> >> I don't know anything about Jalali dates, but I took the time to check and >> found that Perl has modules that handle this (use CPAN or, on windows, PPM >> to find them). However, like the C code you found, it will convert values a >> date at a time. I don't know why this would be an issue. >> >> I have never tried to use either C or perl from within R, but if you can >> handle that, it would be trivial to apply these function calls to each value >> in a vector (or array if you prefer) in functions written in either C/C++ or >> perl. In both C++ using STL and Perl, that would require only one line of >> code, and perhaps a couple more in C to manage the required loop if you >> restrict yourself to C, ignoring the benefits of C++. >> >> If I were doing this, I'd do it even before storing the data in my >> database, or at least before importing it into a dataframe in R, but that is >> primarily because I am still learning R, having used it for only a few >> months, rather than a few years using perl and 15+ years using C++. I am so >> early on my R learning curve that I haven't yet looked at writing code in >> C++ or Perl that is to be called by R. While I haven't read through it in >> enough detail to play seriously with it, the method for using such code from >> with R described in "Writing R Extensions" seems simple enough. Instead >> of writing the code to implement your 'complex' algorithm, why not just use >> the code you've found, or that available in CPAN (I don't know about you, >> but I hate reinventing the wheel), and create the trivial extension needed >> following the instructions in "Writing R Extensions", or do it to the raw >> data before you import it into R? >> >> HTH >> >> Ted >> > > > > -- > Amy Mikhail > Program Manager, ACTc Afghanistan Malaria Project > London School of Hygiene & Tropical Medicine > HPRO, Charahi-e-Shahid, Shar-e-Naw, Kabul, Afghanistan > > Email (Afg): amy.mikh...@googlemail.com > Email (UK): amy.mikh...@lshtm.ac.uk > Tel (Afg): +93 (0)706 126627 > Tel (UK): +44 (0)781 4176107 > -- Amy Mikhail Program Manager, ACTc Afghanistan Malaria Project London School of Hygiene & Tropical Medicine HPRO, Charahi-e-Shahid, Shar-e-Naw, Kabul, Afghanistan Email (Afg): amy.mikh...@googlemail.com Email (UK): amy.mikh...@lshtm.ac.uk Tel (Afg): +93 (0)706 126627 Tel (UK): +44 (0)781 4176107 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Function to recognise convert dates between gregorian and other calendars (e.g. Persian)?
Hi Whit,
Many thanks for the link. The Boost options look interesting, although
calendar conversion is mentioned in the goals I couldn't see a direct
example of it on the website.
I'm not sure how this would be coded, but the general details for the
conversion are that the date would have to be split up into day, month and
year, then:
1) For year conversion it is relatively easy - Persian calendar is 621 years
behind so to get gregorian year from the Persian year add 621;
2) For the months, there are also 12 months in the Persian year but the
Persian new year falls on the gregorian date 21st March.
3) For the date (day): the first 6 Persian months have 31 days, the next 5
have 30 and the last month has 29 or 30 depending on if it is a leap year.
Incidentally I also just got a reply from Thomas Lumley on the R-sig-epi
list, he has written an R wrapper for the c code, message below:
---
I looked at the C code from Project Pluto that Hosseini references, and
wrote R wrappers for it. The C and R code are at
http://faculty.washington.edu/tlumley/calendars
I haven't turned it into a package (anyone who wants to is welcome), and it
has only been tested to a limited extent and only on Mac OS.
Build the C code with
R CMD SHLIB convdates.c date.cpp
then source("convdates.R")
This sets up an OtherDate class that can hold Persian, Islamic, Hebrew, and
the other calendars that the C code supports, with methods to convert to and
from Date.
It should be possible to translate the C algorithms into straight R with
little loss of efficiency, but that looked like more than an hour's work.
-thomas
Thomas Lumley Assoc. Professor, Biostatistics
tlum...@u.washington.eduUniversity of Washington, Seattle
---
Best wishes,
Amy
On Wed, Jan 7, 2009 at 5:47 PM, Whit Armstrong wrote:
> probably easy to do w/ Boost DateTime
>
> http://www.boost.org/doc/libs/1_37_0/doc/html/date_time.html
>
> for which there is already an R package in development:
> http://repo.or.cz/w/RBoostDateTime.git
>
> I'm happy to write a small wrapper to do what you want if you can
> offer a pseudocode example of the conversion function.
>
> -Whit
>
>
> On Wed, Jan 7, 2009 at 12:20 PM, Ted Byers wrote:
> > On Wed, Jan 7, 2009 at 10:23 AM, Amy Mikhail >wrote:
> >
> >> Dear list,
> >>
> >> I will shortly have some data that contains numeric dates in the Persian
> /
> >> Jalali calendar format, which I would like to convert to gregorian. At
> the
> >> moment there doesn't seem to be a function for this in R, but it would
> be
> >> great if someone could come up with same - I would attempt it but the
> >> algorithm is very complex and this is also way beyond my fairly
> rudimentary
> >> knowledge of R.
> >>
> >> How do you feel about mixed language programming?
> >
> > I don't know anything about Jalali dates, but I took the time to check
> and
> > found that Perl has modules that handle this (use CPAN or, on windows,
> PPM
> > to find them). However, like the C code you found, it will convert
> values a
> > date at a time. I don't know why this would be an issue.
> >
> > I have never tried to use either C or perl from within R, but if you can
> > handle that, it would be trivial to apply these function calls to each
> value
> > in a vector (or array if you prefer) in functions written in either C/C++
> or
> > perl. In both C++ using STL and Perl, that would require only one line
> of
> > code, and perhaps a couple more in C to manage the required loop if you
> > restrict yourself to C, ignoring the benefits of C++.
> >
> > If I were doing this, I'd do it even before storing the data in my
> database,
> > or at least before importing it into a dataframe in R, but that is
> primarily
> > because I am still learning R, having used it for only a few months,
> rather
> > than a few years using perl and 15+ years using C++. I am so early on my
> R
> > learning curve that I haven't yet looked at writing code in C++ or Perl
> that
> > is to be called by R. While I haven't read through it in enough detail
> to
> > play seriously with it, the method for using such code from with R
> described
> > in "Writing R
> Extensions"
> > seems simple enough. Instead of writing the code to implement your
> > 'complex' algorithm, why not just use the code you've found, or that
> > available in CPAN (I don't know about you, but I hate reinventing the
> > wheel), and create the trivial extension needed following the
> instructions
> > in "Writing R
> Extensions",
> > or do it to the raw data before you import it into R?
> >
> > HTH
> >
> > Ted
> >
> >[[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.o
[Rd] Parse-Error creates strange function calls (completely different printouts) (PR#13436)
Full_Name: Oliver Bandel
Version: R version 2.7.1 (2008-06-23)
OS: Linux (Debian Lenny)
Submission from: (NULL) (88.73.82.147)
Hello,
I have written a small R-script.
When I inserted one line of code, the behaviour was completely different!
Instead of just printing one line more to the output,
the complete call of the function in which this line was added,
is different, and instead of one such call, the function seems to be
called more than once!
I just added a line, which prints some data,
but then the printouts were completely different than
expected; and when commenting the new stuff out,
the OK-behaviour came back.
Here a diff of the code:
=
oli...@siouxsie:~/R-BUG$ diff ok.R buggy.R
64c64
< res.txt <- paste(# "\n\n Anzahl der Messungen:", sample_times, "\n",
---
> res.txt <- paste("\n\n Anzahl der Messungen:", sample_times, "\n",
oli...@siouxsie:~/R-BUG$
==
You see, I only wanted to print out a variable.
But the output is much bigger now:
**
oli...@siouxsie:~/R-BUG$ wc -l LOG.*
125 LOG.buggy
50 LOG.ok
175 insgesamt
oli...@siouxsie:~/R-BUG$
**
The variable sample_times is just an array with some numbers:
##
> ls()
[1] "anemo.freq" "anemo.impulse_times" "anemo.T"
[4] "impulse_num" "impuls.messreihe""make_one_sample_set"
[7] "sample.dauer""sample.freq" "sample_num"
[10] "sample.T""sample_times"
> sample_times
[1] 0 1 2 3 4 5 6 7 8 9
> mode(sample_times)
[1] "numeric"
> class(sample_times)
[1] "numeric"
>
##
So, the change in the code could not bring such a strange result!
I could provide the original code for you,
if you need it for testing.
Please send me email, if you need it.
Best,
Oliver Bandel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
Simon, first, I'd like to apologize, that my previous message has been sent to you directly. I have not checked the receivers list when clicking reply in my E-mail program. Simon Urbanek wrote: > On Jan 7, 2009, at 2:05 , Thomas Baier wrote: > >> Simon, >> >> Simon Urbanek wrote: And if 2.8.0 and 2.8.1 are fully compatible, why is a warning issued, if a package built with R 2.8.1 is loaded in R 2.8.0? >>> >>> It's ok to use a package built for 2.8.0 in 2.8.1 but not vice >>> versa. It is rare, but it has happened before that a bugfix or >>> visibility change adds a symbol in x.y.1 that was not there in >>> x.y.0. Then if your package checks for that particular feature and >>> uses it you cannot use that binary with x.y.0. Again, this is >>> rather rare and you as the >> >> so this was exactly what has occured. Users having installed R 2.8.0 >> (as >> 2.8.1 has not been released then) and installing a package from CRAN >> which has been built for 2.8.1. >> >> >>> package author know about it, but to be on the safe side I was >>> recommending against that. However, as Brian pointed out this >>> happens far more often on the R function level than on the C API >>> level. >>> >>> (I know about this DLL version check because it was the first >>> change I >>> made to JRI since I wasn't willing to release Windows binary some >>> five times a year ;)). >> >> As far as I have understood Brian's message, one should just parse >> for the second '.' in the version string and omit everything >> afterwards for comparison. >> >> What I would really like to have is some new API function to check >> compatibility. If this was there both on R user level (for R language >> constructs and functions) and on C level (for packages/applications >> relying on the C API), then this would be a fine solution for >> compatiblity without issuing any warnings about wrong versions. >> > > Semantically that's not really possible since the result would always > be FALSE. The point is that if you use something that has been fixed > or added, you may run into issues since the behavior changed. R cannot > know whether that affects you package or not. Therefore it's safer to > declare patch-level releases compatible (they don't "break" existing > binaries) and everything else incompatible (as Brian was suggesting). > However, my point was that *you* can decide to exploit changes in > patch-level updates if you desire so (a practical example here is > R_SignalHandlers which was introduced (exposed) in 2.3.1 and thus a > patch-level), but in that case it is your decision not some R > incompatibility. I hope this makes clear what I was describing > earlier. In general forward binary compatibility between patch-level > versions is guaranteed and backward if you don't use features added > later on. That's true for fixes, which will break compatibity (but are required as well). If I had used R_SignalHandlers in a package, then I would have had to restrict the package to be compatible with R >= 2.3.1, not with versions before. This should be something in the DESCRIPTION file. The only thing (but code-breaking fixes) I can imagine is a compile-time check in the package, so it behaves differently for < 2.3.1 and >= 2.3.1. Best, Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] legend() in a multiple figure environment
Dear all, there seems to be a problem with displayed legends when a multiple figure environment is used, see the following example: par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) legend(-4,0.2,legend="curve",lty=1,col=4) On my machines the first time the command legend() is issued the legend box stretches over the curve. Subsequent calls to legend seems to produce a correct box instead. openSuse 11.0 platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 8.1 year 2009 month 01 day07 svn rev47501 language R version.string R version 2.8.1 Patched (2009-01-07 r47501) I see this on the same version of R on Windows VISTA 32 bit as well; I do not see this behaviour on a machine with R 2.8.0. Thank you, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Dear Simone, Did mean that the legend (text and/or box) overlap with the Normal density? If so then I think there's no problem as the legend is placed where you told R to do. And R won't check (for you) if it will overlap or not with pre-existing graphical elements. On my computer, I got the expected results - if I understood correctly your issue though. For information: R version 2.8.1 (2008-12-22) Linux mathieu-laptop 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 i686 GNU/Linux (Ubuntu Intrepid) Cheers, Mathieu Simone Giannerini a écrit : Dear all, there seems to be a problem with displayed legends when a multiple figure environment is used, see the following example: par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) legend(-4,0.2,legend="curve",lty=1,col=4) On my machines the first time the command legend() is issued the legend box stretches over the curve. Subsequent calls to legend seems to produce a correct box instead. openSuse 11.0 platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 8.1 year 2009 month 01 day07 svn rev47501 language R version.string R version 2.8.1 Patched (2009-01-07 r47501) I see this on the same version of R on Windows VISTA 32 bit as well; I do not see this behaviour on a machine with R 2.8.0. Thank you, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parse-Error creates strange function calls (completely different printouts) (PR#13436)
This is not a bug. Read ?paste: if you give it a vector, it will give
you a vector result. That's what you're seeing.
Duncan Murdoch
oli...@first.in-berlin.de wrote:
Full_Name: Oliver Bandel
Version: R version 2.7.1 (2008-06-23)
OS: Linux (Debian Lenny)
Submission from: (NULL) (88.73.82.147)
Hello,
I have written a small R-script.
When I inserted one line of code, the behaviour was completely different!
Instead of just printing one line more to the output,
the complete call of the function in which this line was added,
is different, and instead of one such call, the function seems to be
called more than once!
I just added a line, which prints some data,
but then the printouts were completely different than
expected; and when commenting the new stuff out,
the OK-behaviour came back.
Here a diff of the code:
=
oli...@siouxsie:~/R-BUG$ diff ok.R buggy.R
64c64
< res.txt <- paste(# "\n\n Anzahl der Messungen:", sample_times, "\n",
---
res.txt <- paste("\n\n Anzahl der Messungen:", sample_times, "\n",
oli...@siouxsie:~/R-BUG$
==
You see, I only wanted to print out a variable.
But the output is much bigger now:
**
oli...@siouxsie:~/R-BUG$ wc -l LOG.*
125 LOG.buggy
50 LOG.ok
175 insgesamt
oli...@siouxsie:~/R-BUG$
**
The variable sample_times is just an array with some numbers:
##
ls()
[1] "anemo.freq" "anemo.impulse_times" "anemo.T"
[4] "impulse_num" "impuls.messreihe""make_one_sample_set"
[7] "sample.dauer""sample.freq" "sample_num"
[10] "sample.T""sample_times"
sample_times
[1] 0 1 2 3 4 5 6 7 8 9
mode(sample_times)
[1] "numeric"
class(sample_times)
[1] "numeric"
##
So, the change in the code could not bring such a strange result!
I could provide the original code for you,
if you need it for testing.
Please send me email, if you need it.
Best,
Oliver Bandel
__
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] Parse-Error creates strange function calls (completely different (PR#13438)
This is not a bug. Read ?paste: if you give it a vector, it will give
you a vector result. That's what you're seeing.
Duncan Murdoch
oli...@first.in-berlin.de wrote:
> Full_Name: Oliver Bandel
> Version: R version 2.7.1 (2008-06-23)
> OS: Linux (Debian Lenny)
> Submission from: (NULL) (88.73.82.147)
>
>
> Hello,
>
> I have written a small R-script.
> When I inserted one line of code, the behaviour was completely different!
>
> Instead of just printing one line more to the output,
> the complete call of the function in which this line was added,
> is different, and instead of one such call, the function seems to be
> called more than once!
>
> I just added a line, which prints some data,
> but then the printouts were completely different than
> expected; and when commenting the new stuff out,
> the OK-behaviour came back.
>
>
> Here a diff of the code:
>
> =
> oli...@siouxsie:~/R-BUG$ diff ok.R buggy.R
> 64c64
> < res.txt <- paste(# "\n\n Anzahl der Messungen:", sample_times, "\n",
> ---
>
>> res.txt <- paste("\n\n Anzahl der Messungen:", sample_times, "\n",
>>
> oli...@siouxsie:~/R-BUG$
> ==
>
> You see, I only wanted to print out a variable.
>
>
> But the output is much bigger now:
>
> **
> oli...@siouxsie:~/R-BUG$ wc -l LOG.*
> 125 LOG.buggy
> 50 LOG.ok
> 175 insgesamt
> oli...@siouxsie:~/R-BUG$
> **
>
>
> The variable sample_times is just an array with some numbers:
> ##
>
>> ls()
>>
> [1] "anemo.freq" "anemo.impulse_times" "anemo.T"
> [4] "impulse_num" "impuls.messreihe""make_one_sample_set"
> [7] "sample.dauer""sample.freq" "sample_num"
> [10] "sample.T""sample_times"
>
>> sample_times
>>
> [1] 0 1 2 3 4 5 6 7 8 9
>
>> mode(sample_times)
>>
> [1] "numeric"
>
>> class(sample_times)
>>
> [1] "numeric"
>
> ##
>
>
> So, the change in the code could not bring such a strange result!
>
> I could provide the original code for you,
> if you need it for testing.
> Please send me email, if you need it.
>
> Best,
>Oliver Bandel
>
> __
> 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] NY Times article
Sorry if this is spam, but I couldn't see it having popped up on the list yet. http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html?emc=eta1 Anand [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu Ribatet wrote: > Dear Simone, > > Did mean that the legend (text and/or box) overlap with the Normal density? no, I mean that the two legend() commands, which are identical in all but the y-coordinates, produce different results, namely boxes with different widths. Ciao Simone > If so then I think there's no problem as the legend is placed where you told > R to do. And R won't check (for you) if it will overlap or not with > pre-existing graphical elements. > > On my computer, I got the expected results - if I understood correctly your > issue though. For information: > > R version 2.8.1 (2008-12-22) > Linux mathieu-laptop 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 > UTC 2008 i686 GNU/Linux (Ubuntu Intrepid) > > Cheers, > Mathieu > > Simone Giannerini a écrit : >> >> Dear all, >> >> there seems to be a problem with displayed legends when a multiple >> figure environment is used, see the following example: >> >> par(mfrow=c(1,2)) >> curve(dnorm,col=4,from=-4,to=4); >> legend(-4,0.3,legend="curve",lty=1,col=4) >> legend(-4,0.2,legend="curve",lty=1,col=4) >> >> >> On my machines the first time the command legend() is issued the >> legend box stretches over the curve. Subsequent calls to legend seems >> to produce a correct box instead. >> >> openSuse 11.0 >> >> platform x86_64-unknown-linux-gnu >> arch x86_64 >> os linux-gnu >> system x86_64, linux-gnu >> status Patched >> major 2 >> minor 8.1 >> year 2009 >> month 01 >> day07 >> svn rev47501 >> language R >> version.string R version 2.8.1 Patched (2009-01-07 r47501) >> >> I see this on the same version of R on Windows VISTA 32 bit as well; I >> do not see this behaviour on a machine with R 2.8.0. >> >> Thank you, >> >> Simone >> -- >> __ >> >> Simone Giannerini >> Dipartimento di Scienze Statistiche "Paolo Fortunati" >> Universita' di Bologna >> Via delle belle arti 41 - 40126 Bologna, ITALY >> Tel: +39 051 2098262 Fax: +39 051 232153 >> http://www2.stat.unibo.it/giannerini/ >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Institute of Mathematics > Ecole Polytechnique Fédérale de Lausanne > STAT-IMA-FSB-EPFL, Station 8 > CH-1015 Lausanne Switzerland > http://stat.epfl.ch/ > Tel: + 41 (0)21 693 7907 > > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
> "SG" == Simone Giannerini > on Thu, 8 Jan 2009 14:08:17 +0100 writes: SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu SG> Ribatet wrote: >> Dear Simone, >> >> Did mean that the legend (text and/or box) overlap with >> the Normal density? SG> no, I mean that the two legend() commands, which are SG> identical in all but the y-coordinates, produce SG> different results, namely boxes with different widths. I don't see that behavior at all, rather the two boxes have identical dimensions for me. What does dev.cur() say? if anything with "X11..." (as you are on Linux), what does str(X11.options()) give? SG> Ciao SG> Simone >> If so then I think there's no problem as the legend is >> placed where you told R to do. And R won't check (for >> you) if it will overlap or not with pre-existing >> graphical elements. >> >> On my computer, I got the expected results - if I >> understood correctly your issue though. For information: >> >> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >> i686 GNU/Linux (Ubuntu Intrepid) >> >> Cheers, Mathieu >> >> Simone Giannerini a écrit : >>> >>> Dear all, >>> >>> there seems to be a problem with displayed legends when >>> a multiple figure environment is used, see the following >>> example: >>> >>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>> legend(-4,0.3,legend="curve",lty=1,col=4) >>> legend(-4,0.2,legend="curve",lty=1,col=4) >>> >>> >>> On my machines the first time the command legend() is >>> issued the legend box stretches over the >>> curve. Subsequent calls to legend seems to produce a >>> correct box instead. >>> >>> openSuse 11.0 >>> >>> platform x86_64-unknown-linux-gnu arch x86_64 os >>> linux-gnu system x86_64, linux-gnu status Patched major >>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>> language R version.string R version 2.8.1 Patched >>> (2009-01-07 r47501) >>> >>> I see this on the same version of R on Windows VISTA 32 >>> bit as well; I do not see this behaviour on a machine >>> with R 2.8.0. >>> >>> Thank you, >>> >>> Simone >>> -- >>> __ >>> >>> Simone Giannerini Dipartimento di Scienze Statistiche >>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > -- > Institute of Mathematics Ecole Polytechnique Fédérale de >> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >> >> >> -- __ SG> Simone Giannerini Dipartimento di Scienze Statistiche SG> "Paolo Fortunati" Universita' di Bologna Via delle belle SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ SG> __ SG> R-devel@r-project.org mailing list SG> 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] legend() in a multiple figure environment
On linux, I get > dev.cur() null device 1 > str(X11.options()) List of 15 $ display: chr "" $ width : num NA $ height : num NA $ pointsize : num 12 $ bg : chr "transparent" $ canvas : chr "white" $ gamma : num 1 $ colortype : chr "true" $ maxcubesize: num 256 $ fonts : chr [1:2] "-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*" "-adobe-symbol-medium-r-*-*-%d-*-*-*-*-*-*-*" $ xpos : int NA $ ypos : int NA $ title : chr "" $ type : chr "cairo" $ antialias : num 1 thanks, Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: >> "SG" == Simone Giannerini >> on Thu, 8 Jan 2009 14:08:17 +0100 writes: > >SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >SG> Ribatet wrote: >>> Dear Simone, >>> >>> Did mean that the legend (text and/or box) overlap with >>> the Normal density? > >SG> no, I mean that the two legend() commands, which are >SG> identical in all but the y-coordinates, produce >SG> different results, namely boxes with different widths. > > I don't see that behavior at all, rather the two boxes have > identical dimensions for me. > > What does dev.cur() say? if anything with "X11..." (as you are > on Linux), what does > > str(X11.options()) > > give? > > >SG> Ciao > >SG> Simone > >>> If so then I think there's no problem as the legend is >>> placed where you told R to do. And R won't check (for >>> you) if it will overlap or not with pre-existing >>> graphical elements. >>> >>> On my computer, I got the expected results - if I >>> understood correctly your issue though. For information: >>> >>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> i686 GNU/Linux (Ubuntu Intrepid) >>> >>> Cheers, Mathieu >>> >>> Simone Giannerini a écrit : >>>> >>>> Dear all, >>>> >>>> there seems to be a problem with displayed legends when >>>> a multiple figure environment is used, see the following >>>> example: >>>> >>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>> >>>> >>>> On my machines the first time the command legend() is >>>> issued the legend box stretches over the >>>> curve. Subsequent calls to legend seems to produce a >>>> correct box instead. >>>> >>>> openSuse 11.0 >>>> >>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>> linux-gnu system x86_64, linux-gnu status Patched major >>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>> language R version.string R version 2.8.1 Patched >>>> (2009-01-07 r47501) >>>> >>>> I see this on the same version of R on Windows VISTA 32 >>>> bit as well; I do not see this behaviour on a machine >>>> with R 2.8.0. >>>> >>>> Thank you, >>>> >>>> Simone >>>> -- >>>> __ >>>> >>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>> >>>> __ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >> -- >> Institute of Mathematics Ecole Polytechnique Fédérale de >>> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>> >>> >>> > > > > -- > __ > >SG> Simone Giannerini Dipartimento di Scienze Statistiche >SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ > >SG> __ >SG> R-devel@r-project.org mailing list >SG> https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NY Times article
It has been all over R-help, in several threads. https://stat.ethz.ch/pipermail/r-help/2009-January/184119.html https://stat.ethz.ch/pipermail/r-help/2009-January/184170.html https://stat.ethz.ch/pipermail/r-help/2009-January/184209.html https://stat.ethz.ch/pipermail/r-help/2009-January/184232.html https://stat.ethz.ch/pipermail/r-help/2009-January/184237.html and more On Thu, 8 Jan 2009, Anand Patil wrote: Sorry if this is spam, but I couldn't see it having popped up on the list yet. http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html?emc=eta1 Anand [[alternative HTML version deleted]] __ 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
Re: [Rd] legend() in a multiple figure environment
Now I got how to reproduce it, it has nothing to do with multiple figure environment but rather with figure resizing. Here it is: curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) # Now expand the figure to full screen legend(-4,0.2,legend="curve",lty=1,col=4) Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: > > > "SG" == Simone Giannerini > > on Thu, 8 Jan 2009 14:08:17 +0100 writes: > >SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >SG> Ribatet wrote: >>> Dear Simone, >>> >>> Did mean that the legend (text and/or box) overlap with >>> the Normal density? > >SG> no, I mean that the two legend() commands, which are >SG> identical in all but the y-coordinates, produce >SG> different results, namely boxes with different widths. > > I don't see that behavior at all, rather the two boxes have > identical dimensions for me. > > What does dev.cur() say? if anything with "X11..." (as you are > on Linux), what does > > str(X11.options()) > > give? > > >SG> Ciao > >SG> Simone > >>> If so then I think there's no problem as the legend is >>> placed where you told R to do. And R won't check (for >>> you) if it will overlap or not with pre-existing >>> graphical elements. >>> >>> On my computer, I got the expected results - if I >>> understood correctly your issue though. For information: >>> >>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> i686 GNU/Linux (Ubuntu Intrepid) >>> >>> Cheers, Mathieu >>> >>> Simone Giannerini a écrit : >>>> >>>> Dear all, >>>> >>>> there seems to be a problem with displayed legends when >>>> a multiple figure environment is used, see the following >>>> example: >>>> >>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>> >>>> >>>> On my machines the first time the command legend() is >>>> issued the legend box stretches over the >>>> curve. Subsequent calls to legend seems to produce a >>>> correct box instead. >>>> >>>> openSuse 11.0 >>>> >>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>> linux-gnu system x86_64, linux-gnu status Patched major >>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>> language R version.string R version 2.8.1 Patched >>>> (2009-01-07 r47501) >>>> >>>> I see this on the same version of R on Windows VISTA 32 >>>> bit as well; I do not see this behaviour on a machine >>>> with R 2.8.0. >>>> >>>> Thank you, >>>> >>>> Simone >>>> -- >>>> __ >>>> >>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>> >>>> __ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> > > -- > > Institute of Mathematics Ecole Polytechnique Fédérale de >>> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>> >>> >>> > > > > -- > __ > >SG> Simone Giannerini Dipartimento di Scienze Statistiche >SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ > >SG> __ >SG> R-devel@r-project.org mailing list >SG> https://stat.ethz.ch/mailman/listinfo/r-devel -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
You can find the resulting graph here (produced under win Vista) http://www2.stat.unibo.it/giannerini/R/try.eps (produced under win Vista) platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 8.1 year 2008 month 12 day22 svn rev47281 language R version.string R version 2.8.1 (2008-12-22) On Thu, Jan 8, 2009 at 3:29 PM, Simone Giannerini wrote: > Now I got how to reproduce it, it has nothing to do with multiple > figure environment but rather with figure resizing. Here it is: > > curve(dnorm,col=4,from=-4,to=4); > legend(-4,0.3,legend="curve",lty=1,col=4) > > # Now expand the figure to full screen > > legend(-4,0.2,legend="curve",lty=1,col=4) > > Simone > > On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler > wrote: >> >> > "SG" == Simone Giannerini >> > on Thu, 8 Jan 2009 14:08:17 +0100 writes: >> >>SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >>SG> Ribatet wrote: >>>> Dear Simone, >>>> >>>> Did mean that the legend (text and/or box) overlap with >>>> the Normal density? >> >>SG> no, I mean that the two legend() commands, which are >>SG> identical in all but the y-coordinates, produce >>SG> different results, namely boxes with different widths. >> >> I don't see that behavior at all, rather the two boxes have >> identical dimensions for me. >> >> What does dev.cur() say? if anything with "X11..." (as you are >> on Linux), what does >> >> str(X11.options()) >> >> give? >> >> >>SG> Ciao >> >>SG> Simone >> >>>> If so then I think there's no problem as the legend is >>>> placed where you told R to do. And R won't check (for >>>> you) if it will overlap or not with pre-existing >>>> graphical elements. >>>> >>>> On my computer, I got the expected results - if I >>>> understood correctly your issue though. For information: >>>> >>>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>>> i686 GNU/Linux (Ubuntu Intrepid) >>>> >>>> Cheers, Mathieu >>>> >>>> Simone Giannerini a écrit : >>>>> >>>>> Dear all, >>>>> >>>>> there seems to be a problem with displayed legends when >>>>> a multiple figure environment is used, see the following >>>>> example: >>>>> >>>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>>> >>>>> >>>>> On my machines the first time the command legend() is >>>>> issued the legend box stretches over the >>>>> curve. Subsequent calls to legend seems to produce a >>>>> correct box instead. >>>>> >>>>> openSuse 11.0 >>>>> >>>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>>> linux-gnu system x86_64, linux-gnu status Patched major >>>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>>> language R version.string R version 2.8.1 Patched >>>>> (2009-01-07 r47501) >>>>> >>>>> I see this on the same version of R on Windows VISTA 32 >>>>> bit as well; I do not see this behaviour on a machine >>>>> with R 2.8.0. >>>>> >>>>> Thank you, >>>>> >>>>> Simone >>>>> -- >>>>> __ >>>>> >>>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>>>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>>> >>>>> __ >>>>> R-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>> >>>> >> > -- >> > Institute of Mathematics Ecole Polytechnique Fédérale de >>>> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>>> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>>> >>>> >>>> >> >> >> >> -- >> __ >> >>SG> Simone Giannerini Dipartimento di Scienze Statistiche >>SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >>SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >> >>SG> __ >>SG> R-devel@r-project.org mailing list >>SG> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > __ > > Simone Giannerini > Dipartimento di Scienze Statistiche "Paolo Fortunati" > Universita' di Bologna > Via delle belle arti 41 - 40126 Bologna, ITALY > Tel: +39 051 2098262 Fax: +39 051 232153 > http://www2.stat.unibo.it/giannerini/ > ___
[Rd] Callbacks seems to get GCed.
Dear list,
I am trying to implement a publish-subscribe mechanism in for an embedded
R interpreter. But somehow my registered closures seem to get collected by
the GC, even though I have protected them. I have reducted my code to the
following sample. Sorry if it is a little verbose.
The first couple of call of calls still work, but at some point one of the
callbacks (callback1 in my case) changes its type.
Regards and thanks for any help,
Bernd
#include
#include
#define R_INTERFACE_PTRS 1
#include
#include
#include
#include
#include
#include
#include
#include
SEXP callback1;
SEXP callback2;
void set_callback1(SEXP func) {
PROTECT(callback1 = func);
}
void set_callback2(SEXP func) {
PROTECT(callback2 = func);
}
R_CMethodDef cMethods[] = {
{NULL}
};
R_CallMethodDef callMethods[] = {
{"set_callback1", (DL_FUNC) &set_callback1, 1},
{"set_callback2", (DL_FUNC) &set_callback2, 1},
{NULL}
};
void r_trigger_callback1()
{
int errorOccurred;
SEXP f = NULL;
f = allocVector(LANGSXP, 1);
SETCAR(f, callback1);
PROTECT(f);
R_tryEval(f, R_GlobalEnv, &errorOccurred);
UNPROTECT(1);
}
void r_trigger_callback2()
{
int errorOccurred;
SEXP f = NULL;
f = allocVector(LANGSXP, 1);
SETCAR(f, callback2);
PROTECT(f);
R_tryEval(f, R_GlobalEnv, &errorOccurred);
UNPROTECT(1);
}
void r_exec(char *code)
{
SEXP cmdSexp, cmdExpr = R_NilValue;
ParseStatus status;
int i,errorOccurred;
SEXP e;
PROTECT (cmdSexp = allocVector (STRSXP, 1));
SET_STRING_ELT (cmdSexp, 0, mkChar (code));
PROTECT (cmdExpr = R_ParseVector (cmdSexp,-1,&status,R_NilValue));
UNPROTECT_PTR (cmdSexp);
if (status == PARSE_OK) {
for (i = 0; i < length (cmdExpr); i++) {
PROTECT(e = VECTOR_ELT (cmdExpr,i));
R_tryEval(e, R_GlobalEnv, &errorOccurred);
UNPROTECT_PTR(e);
if (errorOccurred) {
return;
}
}
}
}
void initR()
{
char *argv[] = {"REmbeddedPascal", "--gui=none", "--silent",
"--no-save"};
int argc = 4;
DllInfo *info;
setenv("R_HOME","/usr/lib/R",0);
structRstart rp;
Rstart Rp = &rp;
R_setStartTime();
R_DefParams(Rp);
Rp->R_Quiet = TRUE;
Rp->RestoreAction = SA_RESTORE;
Rp->SaveAction = SA_NOSAVE;
R_SetParams(Rp);
R_Interactive = TRUE;
Rf_initialize_R(argc, argv);
setup_Rmainloop();
R_ReplDLLinit();
info = R_getEmbeddingDllInfo();
R_registerRoutines(info, cMethods, callMethods, NULL, NULL);
}
int main (int argc, char** argv)
{
int i;
initR();
r_exec("x <- function (f) { .Call(\"set_callback1\",f); }");
r_exec("y <- function (f) { .Call(\"set_callback2\",f); }");
r_exec("x(function() { print(\"A\"); })");
r_exec("y(function() { print(\"B\"); })");
for (i = 0; i < 10; i++) {
r_trigger_callback1();
r_trigger_callback2();
}
Rf_endEmbeddedR(0);
}
--
Bernd Schoeller, PhD, CTO
Comerge AG, Technoparkstrasse 1, CH-8055 Zurich, www.comerge.net
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Callbacks seems to get GCed.
Hi Bernd
There are two problems here.
Firstly, routines that are invoked via the .Call() interface
must return a SEXP, not a void. (void is for .C()-callable
routines.)
The more serious problem is that yes, you are PROTECT'ing
the callbacks when you set them, but PROTECT'ing is
for the duration of the .Call() invocation, not throughout
a session. I imagine you are seeing stack imbalance messages
as you do not UNPROTECT() within the .Call() to set the
callbacks.
Because the setting of the callbacks and using them
is asynchronous, or not part of the same .Call(),
you can use R_PreserveObject() rather than PROTECT().
That prohibits the object from being garbage collected.
D.
Bernd Schoeller wrote:
> Dear list,
>
> I am trying to implement a publish-subscribe mechanism in for an embedded
> R interpreter. But somehow my registered closures seem to get collected by
> the GC, even though I have protected them. I have reducted my code to the
> following sample. Sorry if it is a little verbose.
>
> The first couple of call of calls still work, but at some point one of the
> callbacks (callback1 in my case) changes its type.
>
> Regards and thanks for any help,
> Bernd
>
> #include
> #include
>
> #define R_INTERFACE_PTRS 1
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> SEXP callback1;
> SEXP callback2;
>
> void set_callback1(SEXP func) {
> PROTECT(callback1 = func);
> }
>
> void set_callback2(SEXP func) {
> PROTECT(callback2 = func);
> }
>
> R_CMethodDef cMethods[] = {
> {NULL}
> };
>
> R_CallMethodDef callMethods[] = {
> {"set_callback1", (DL_FUNC) &set_callback1, 1},
> {"set_callback2", (DL_FUNC) &set_callback2, 1},
> {NULL}
> };
>
> void r_trigger_callback1()
> {
> int errorOccurred;
> SEXP f = NULL;
>
> f = allocVector(LANGSXP, 1);
> SETCAR(f, callback1);
> PROTECT(f);
> R_tryEval(f, R_GlobalEnv, &errorOccurred);
> UNPROTECT(1);
> }
>
> void r_trigger_callback2()
> {
> int errorOccurred;
> SEXP f = NULL;
>
> f = allocVector(LANGSXP, 1);
> SETCAR(f, callback2);
> PROTECT(f);
> R_tryEval(f, R_GlobalEnv, &errorOccurred);
> UNPROTECT(1);
> }
>
>
> void r_exec(char *code)
> {
> SEXP cmdSexp, cmdExpr = R_NilValue;
> ParseStatus status;
> int i,errorOccurred;
> SEXP e;
>
> PROTECT (cmdSexp = allocVector (STRSXP, 1));
> SET_STRING_ELT (cmdSexp, 0, mkChar (code));
> PROTECT (cmdExpr = R_ParseVector (cmdSexp,-1,&status,R_NilValue));
> UNPROTECT_PTR (cmdSexp);
>
> if (status == PARSE_OK) {
> for (i = 0; i < length (cmdExpr); i++) {
> PROTECT(e = VECTOR_ELT (cmdExpr,i));
> R_tryEval(e, R_GlobalEnv, &errorOccurred);
> UNPROTECT_PTR(e);
> if (errorOccurred) {
> return;
> }
> }
> }
> }
>
> void initR()
> {
> char *argv[] = {"REmbeddedPascal", "--gui=none", "--silent",
> "--no-save"};
> int argc = 4;
> DllInfo *info;
>
> setenv("R_HOME","/usr/lib/R",0);
>
> structRstart rp;
> Rstart Rp = &rp;
>
> R_setStartTime();
> R_DefParams(Rp);
>
> Rp->R_Quiet = TRUE;
> Rp->RestoreAction = SA_RESTORE;
> Rp->SaveAction = SA_NOSAVE;
> R_SetParams(Rp);
>
> R_Interactive = TRUE;
>
> Rf_initialize_R(argc, argv);
> setup_Rmainloop();
> R_ReplDLLinit();
> info = R_getEmbeddingDllInfo();
> R_registerRoutines(info, cMethods, callMethods, NULL, NULL);
> }
>
> int main (int argc, char** argv)
> {
> int i;
> initR();
>
> r_exec("x <- function (f) { .Call(\"set_callback1\",f); }");
> r_exec("y <- function (f) { .Call(\"set_callback2\",f); }");
> r_exec("x(function() { print(\"A\"); })");
> r_exec("y(function() { print(\"B\"); })");
>
> for (i = 0; i < 10; i++) {
> r_trigger_callback1();
> r_trigger_callback2();
> }
>
> Rf_endEmbeddedR(0);
> }
>
>
> --
> Bernd Schoeller, PhD, CTO
> Comerge AG, Technoparkstrasse 1, CH-8055 Zurich, www.comerge.net
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
"There are men who can think no deeper than a fact" - Voltaire
Duncan Temple Langdun...@wald.ucdavis.edu
Department of Statistics work: (530) 752-4782
4210 Mathematical Sciences Bldg. fax: (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
pgpSSYXJDkyZ9.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
On 1/8/2009 9:29 AM, Simone Giannerini wrote: Now I got how to reproduce it, it has nothing to do with multiple figure environment but rather with figure resizing. Here it is: curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) # Now expand the figure to full screen legend(-4,0.2,legend="curve",lty=1,col=4) I think the only advice here is "don't do that". The problem is that the box is sized appropriately to surround the text when it is first drawn, then you scale everything up except the text, so the box becomes too big. The new box is appropriate to the text at the new size. Then you scale everything again when you save to a file, and the boxes end up different again. So the advice is: draw legends with the plot at its final size if you want the sizing to work properly. R doesn't save the fact that the size is supposed to be relative to the text, rather than relative to the plot region. Duncan Murdoch Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: > "SG" == Simone Giannerini > on Thu, 8 Jan 2009 14:08:17 +0100 writes: SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu SG> Ribatet wrote: >> Dear Simone, >> >> Did mean that the legend (text and/or box) overlap with >> the Normal density? SG> no, I mean that the two legend() commands, which are SG> identical in all but the y-coordinates, produce SG> different results, namely boxes with different widths. I don't see that behavior at all, rather the two boxes have identical dimensions for me. What does dev.cur() say? if anything with "X11..." (as you are on Linux), what does str(X11.options()) give? SG> Ciao SG> Simone >> If so then I think there's no problem as the legend is >> placed where you told R to do. And R won't check (for >> you) if it will overlap or not with pre-existing >> graphical elements. >> >> On my computer, I got the expected results - if I >> understood correctly your issue though. For information: >> >> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >> i686 GNU/Linux (Ubuntu Intrepid) >> >> Cheers, Mathieu >> >> Simone Giannerini a écrit : >>> >>> Dear all, >>> >>> there seems to be a problem with displayed legends when >>> a multiple figure environment is used, see the following >>> example: >>> >>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>> legend(-4,0.3,legend="curve",lty=1,col=4) >>> legend(-4,0.2,legend="curve",lty=1,col=4) >>> >>> >>> On my machines the first time the command legend() is >>> issued the legend box stretches over the >>> curve. Subsequent calls to legend seems to produce a >>> correct box instead. >>> >>> openSuse 11.0 >>> >>> platform x86_64-unknown-linux-gnu arch x86_64 os >>> linux-gnu system x86_64, linux-gnu status Patched major >>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>> language R version.string R version 2.8.1 Patched >>> (2009-01-07 r47501) >>> >>> I see this on the same version of R on Windows VISTA 32 >>> bit as well; I do not see this behaviour on a machine >>> with R 2.8.0. >>> >>> Thank you, >>> >>> Simone >>> -- >>> __ >>> >>> Simone Giannerini Dipartimento di Scienze Statistiche >>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > -- > Institute of Mathematics Ecole Polytechnique Fédérale de >> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >> >> >> -- __ SG> Simone Giannerini Dipartimento di Scienze Statistiche SG> "Paolo Fortunati" Universita' di Bologna Via delle belle SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ SG> __ SG> R-devel@r-project.org mailing list SG> https://stat.ethz.ch/mailman/listinfo/r-devel -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list ht
Re: [Rd] legend() in a multiple figure environment
On Thu, 8 Jan 2009, Simone Giannerini wrote: Now I got how to reproduce it, it has nothing to do with multiple figure environment but rather with figure resizing. Here it is: curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) # Now expand the figure to full screen legend(-4,0.2,legend="curve",lty=1,col=4) When you resize graphics, text stays the same size (on most devices) and vector graphics does not. You can't expect the figure to be recomputed when you resize (and if you expect so, your expectations will be unfufilled). All that happens is that a low-level description is replayed. The windows() device does give you more options on resize. Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: "SG" == Simone Giannerini on Thu, 8 Jan 2009 14:08:17 +0100 writes: SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu SG> Ribatet wrote: >> Dear Simone, >> >> Did mean that the legend (text and/or box) overlap with >> the Normal density? SG> no, I mean that the two legend() commands, which are SG> identical in all but the y-coordinates, produce SG> different results, namely boxes with different widths. I don't see that behavior at all, rather the two boxes have identical dimensions for me. What does dev.cur() say? if anything with "X11..." (as you are on Linux), what does str(X11.options()) give? SG> Ciao SG> Simone >> If so then I think there's no problem as the legend is >> placed where you told R to do. And R won't check (for >> you) if it will overlap or not with pre-existing >> graphical elements. >> >> On my computer, I got the expected results - if I >> understood correctly your issue though. For information: >> >> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >> i686 GNU/Linux (Ubuntu Intrepid) >> >> Cheers, Mathieu >> >> Simone Giannerini a écrit : >>> >>> Dear all, >>> >>> there seems to be a problem with displayed legends when >>> a multiple figure environment is used, see the following >>> example: >>> >>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>> legend(-4,0.3,legend="curve",lty=1,col=4) >>> legend(-4,0.2,legend="curve",lty=1,col=4) >>> >>> >>> On my machines the first time the command legend() is >>> issued the legend box stretches over the >>> curve. Subsequent calls to legend seems to produce a >>> correct box instead. >>> >>> openSuse 11.0 >>> >>> platform x86_64-unknown-linux-gnu arch x86_64 os >>> linux-gnu system x86_64, linux-gnu status Patched major >>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>> language R version.string R version 2.8.1 Patched >>> (2009-01-07 r47501) >>> >>> I see this on the same version of R on Windows VISTA 32 >>> bit as well; I do not see this behaviour on a machine >>> with R 2.8.0. >>> >>> Thank you, >>> >>> Simone >>> -- >>> __ >>> >>> Simone Giannerini Dipartimento di Scienze Statistiche >>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> -- Institute of Mathematics Ecole Polytechnique Fédérale de >> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >> >> >> -- __ SG> Simone Giannerini Dipartimento di Scienze Statistiche SG> "Paolo Fortunati" Universita' di Bologna Via delle belle SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ SG> __ SG> R-devel@r-project.org mailing list SG> https://stat.ethz.ch/mailman/listinfo/r-devel -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ 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
Re: [Rd] Callbacks seems to get GCed.
Dear Duncan,
Thank you for your suggestion. I did not know about R_PreserveObject, this is
exactly what we needed. You have been very helpful.
Regards,
Bernd
On Thu, 08 Jan 2009 15:59:25 +0100, Duncan Temple Lang
wrote:
Hi Bernd
There are two problems here.
Firstly, routines that are invoked via the .Call() interface
must return a SEXP, not a void. (void is for .C()-callable
routines.)
The more serious problem is that yes, you are PROTECT'ing
the callbacks when you set them, but PROTECT'ing is
for the duration of the .Call() invocation, not throughout
a session. I imagine you are seeing stack imbalance messages
as you do not UNPROTECT() within the .Call() to set the
callbacks.
Because the setting of the callbacks and using them
is asynchronous, or not part of the same .Call(),
you can use R_PreserveObject() rather than PROTECT().
That prohibits the object from being garbage collected.
D.
Bernd Schoeller wrote:
Dear list,
I am trying to implement a publish-subscribe mechanism in for an
embedded
R interpreter. But somehow my registered closures seem to get collected
by
the GC, even though I have protected them. I have reducted my code to
the
following sample. Sorry if it is a little verbose.
The first couple of call of calls still work, but at some point one of
the
callbacks (callback1 in my case) changes its type.
Regards and thanks for any help,
Bernd
#include
#include
#define R_INTERFACE_PTRS 1
#include
#include
#include
#include
#include
#include
#include
#include
SEXP callback1;
SEXP callback2;
void set_callback1(SEXP func) {
PROTECT(callback1 = func);
}
void set_callback2(SEXP func) {
PROTECT(callback2 = func);
}
R_CMethodDef cMethods[] = {
{NULL}
};
R_CallMethodDef callMethods[] = {
{"set_callback1", (DL_FUNC) &set_callback1, 1},
{"set_callback2", (DL_FUNC) &set_callback2, 1},
{NULL}
};
void r_trigger_callback1()
{
int errorOccurred;
SEXP f = NULL;
f = allocVector(LANGSXP, 1);
SETCAR(f, callback1);
PROTECT(f);
R_tryEval(f, R_GlobalEnv, &errorOccurred);
UNPROTECT(1);
}
void r_trigger_callback2()
{
int errorOccurred;
SEXP f = NULL;
f = allocVector(LANGSXP, 1);
SETCAR(f, callback2);
PROTECT(f);
R_tryEval(f, R_GlobalEnv, &errorOccurred);
UNPROTECT(1);
}
void r_exec(char *code)
{
SEXP cmdSexp, cmdExpr = R_NilValue;
ParseStatus status;
int i,errorOccurred;
SEXP e;
PROTECT (cmdSexp = allocVector (STRSXP, 1));
SET_STRING_ELT (cmdSexp, 0, mkChar (code));
PROTECT (cmdExpr = R_ParseVector (cmdSexp,-1,&status,R_NilValue));
UNPROTECT_PTR (cmdSexp);
if (status == PARSE_OK) {
for (i = 0; i < length (cmdExpr); i++) {
PROTECT(e = VECTOR_ELT (cmdExpr,i));
R_tryEval(e, R_GlobalEnv, &errorOccurred);
UNPROTECT_PTR(e);
if (errorOccurred) {
return;
}
}
}
}
void initR()
{
char *argv[] = {"REmbeddedPascal", "--gui=none", "--silent",
"--no-save"};
int argc = 4;
DllInfo *info;
setenv("R_HOME","/usr/lib/R",0);
structRstart rp;
Rstart Rp = &rp;
R_setStartTime();
R_DefParams(Rp);
Rp->R_Quiet = TRUE;
Rp->RestoreAction = SA_RESTORE;
Rp->SaveAction = SA_NOSAVE;
R_SetParams(Rp);
R_Interactive = TRUE;
Rf_initialize_R(argc, argv);
setup_Rmainloop();
R_ReplDLLinit();
info = R_getEmbeddingDllInfo();
R_registerRoutines(info, cMethods, callMethods, NULL, NULL);
}
int main (int argc, char** argv)
{
int i;
initR();
r_exec("x <- function (f) { .Call(\"set_callback1\",f); }");
r_exec("y <- function (f) { .Call(\"set_callback2\",f); }");
r_exec("x(function() { print(\"A\"); })");
r_exec("y(function() { print(\"B\"); })");
for (i = 0; i < 10; i++) {
r_trigger_callback1();
r_trigger_callback2();
}
Rf_endEmbeddedR(0);
}
--
Bernd Schoeller, PhD, CTO
Comerge AG, Technoparkstrasse 1, CH-8055 Zurich, www.comerge.net
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bernd Schoeller, PhD, CTO
Comerge AG, Technoparkstrasse 1, CH-8055 Zurich, www.comerge.net
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Thanks for your clarifications, I use legends only when the plot is at its final size and also had a look at windows() before posting but at first I could not relate the legends' behaviour to the resizing effect. Kind regards, Simone On Thu, Jan 8, 2009 at 4:02 PM, Prof Brian Ripley wrote: > On Thu, 8 Jan 2009, Simone Giannerini wrote: > >> Now I got how to reproduce it, it has nothing to do with multiple >> figure environment but rather with figure resizing. Here it is: >> >> curve(dnorm,col=4,from=-4,to=4); >> legend(-4,0.3,legend="curve",lty=1,col=4) >> >> # Now expand the figure to full screen >> >> legend(-4,0.2,legend="curve",lty=1,col=4) > > When you resize graphics, text stays the same size (on most devices) and > vector graphics does not. You can't expect the figure to be recomputed when > you resize (and if you expect so, your expectations will be unfufilled). > All that happens is that a low-level description is replayed. > > The windows() device does give you more options on resize. > >> >> Simone >> >> On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler >> wrote: >>> "SG" == Simone Giannerini on Thu, 8 Jan 2009 14:08:17 +0100 writes: >>> >>> SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >>> SG> Ribatet wrote: >>> >> Dear Simone, >>> >> >>> >> Did mean that the legend (text and/or box) overlap with >>> >> the Normal density? >>> >>> SG> no, I mean that the two legend() commands, which are >>> SG> identical in all but the y-coordinates, produce >>> SG> different results, namely boxes with different widths. >>> >>> I don't see that behavior at all, rather the two boxes have >>> identical dimensions for me. >>> >>> What does dev.cur() say? if anything with "X11..." (as you are >>> on Linux), what does >>> >>> str(X11.options()) >>> >>> give? >>> >>> >>> SG> Ciao >>> >>> SG> Simone >>> >>> >> If so then I think there's no problem as the legend is >>> >> placed where you told R to do. And R won't check (for >>> >> you) if it will overlap or not with pre-existing >>> >> graphical elements. >>> >> >>> >> On my computer, I got the expected results - if I >>> >> understood correctly your issue though. For information: >>> >> >>> >> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> >> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> >> i686 GNU/Linux (Ubuntu Intrepid) >>> >> >>> >> Cheers, Mathieu >>> >> >>> >> Simone Giannerini a écrit : >>> >>> >>> >>> Dear all, >>> >>> >>> >>> there seems to be a problem with displayed legends when >>> >>> a multiple figure environment is used, see the following >>> >>> example: >>> >>> >>> >>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>> >>> legend(-4,0.3,legend="curve",lty=1,col=4) >>> >>> legend(-4,0.2,legend="curve",lty=1,col=4) >>> >>> >>> >>> >>> >>> On my machines the first time the command legend() is >>> >>> issued the legend box stretches over the >>> >>> curve. Subsequent calls to legend seems to produce a >>> >>> correct box instead. >>> >>> >>> >>> openSuse 11.0 >>> >>> >>> >>> platform x86_64-unknown-linux-gnu arch x86_64 os >>> >>> linux-gnu system x86_64, linux-gnu status Patched major >>> >>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>> >>> language R version.string R version 2.8.1 Patched >>> >>> (2009-01-07 r47501) >>> >>> >>> >>> I see this on the same version of R on Windows VISTA 32 >>> >>> bit as well; I do not see this behaviour on a machine >>> >>> with R 2.8.0. >>> >>> >>> >>> Thank you, >>> >>> >>> >>> Simone >>> >>> -- >>> >>> __ >>> >>> >>> >>> Simone Giannerini Dipartimento di Scienze Statistiche >>> >>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>> >>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>> >>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>> >>> >>> >>> __ >>> >>> R-devel@r-project.org mailing list >>> >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >>> >> -- Institute of Mathematics Ecole Polytechnique Fédérale de >>> >>> >> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>> >> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>> >> >>> >> >>> >> >>> >>> >>> >>> -- >>> __ >>> >>> SG> Simone Giannerini Dipartimento di Scienze Statistiche >>> SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >>> SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>> SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>> >>> SG> __ >>> SG> R-devel@r-project.org mailing list >>> SG> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> >> -- >> __ >> >> Simone Giannerini >> Dipartimento di Scienze Statistiche "Paolo Fortunati" >> Uni
[Rd] File name determines success or failure of package installation -- please help
Synopsis:
I am trying to build and install a package in R, but I have run into a
problem where the file names determine success or failure of the package
installation. I started with a single file containing two class
definitions. This package installs properly. If I split the classes into
two files, the build fails. If I simply change the file name of one file
with no other changes, the build and install then works properly.
This does not seem to be proper behavior. I assume I am doing something
wrong, but I have no idea how to debug or fix this problem. Details are
shown below. I welcome all help and advice!!
Ron
General Information:
R version: 2.8.1
this is an installation of a precomplied version of R
OS: Windows XP PRO SP2
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
Details:
In this example, I start with a file named "classSiteResourceCapacity.R"
that contains the defintition of two classes shown below.
file=classSiteResourceCapacity.R
setClass("SiteResourceCapacity",
representation(
site = "character",
siteResource = "character",
studyResource = "character",
capacity = "numeric",
allocation = "matrix",
priority = "matrix"
)
)
setClass("RoleCapacity", representation(loadFactor="numeric"),
contains="SiteResourceCapacity")
The package (containing only this file) works when I run R CMD CHECK or R
CMD INSTALL.
However, when I seperate the classes into two files with the contents shown
below (simply split the file contents, no additional changes), CHECK and
INSTALL now fail as can be seen in the following output.
file=classSiteResourceCapacity.R
setClass("SiteResourceCapacity",
representation(
site = "character",
siteResource = "character",
studyResource = "character",
capacity = "numeric",
allocation = "matrix",
priority = "matrix"
)
)
file=classRoleCapacity.R
setClass("RoleCapacity", representation(loadFactor="numeric"),
contains="SiteResourceCapacity")
C:\TEMP>dir Test\R
Volume in drive C is WINXP
Volume Serial Number is F893-77D5
Directory of C:\TEMP\Test\R
01/08/2009 10:11 AM .
01/08/2009 10:11 AM ..
01/08/2009 09:54 AM 97 classRoleCapacity.R
01/08/2009 09:55 AM 749 classSiteResourceCapacity.R
2 File(s) 846 bytes
2 Dir(s) 58,195,402,752 bytes free
C:\TEMP>R CMD CHECK Test
* checking for working pdflatex ...pdflatex: not found
NO
* checking for working latex ...latex: not found
NO
* using log directory 'C:/TEMP/Test.Rcheck'
* using R version 2.8.1 (2008-12-22)
* using session charset: ISO8859-1
* checking for file 'Test/DESCRIPTION' ... OK
* this is package 'Test' version '0.1'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for .dll and .exe files ... OK
* checking whether package 'Test' can be installed ... ERROR
Installation failed.
See 'C:/TEMP/Test.Rcheck/00install.out' for details.
C:\TEMP>cat 'C:/TEMP/Test.Rcheck/00install.out'
installing R.css in C:/TEMP/Test.Rcheck
-- Making package Test
adding build stamp to DESCRIPTION
installing R files
preparing package Test for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
No definition was found for superclass "SiteResourceCapacity" in the
specification of class "RoleCapacity"
Calls: ... makeClassRepresentation ->
reconcilePropertiesAndPrototype
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-Test] Error 2
*** Installation of Test failed ***
Removing 'C:/TEMP/Test.Rcheck/Test'
C:\TEMP>R CMD INSTALL Test
installing to 'c:/PROGRA~1/R/R-2.8.1/library'
-- Making package Test
adding build stamp to DESCRIPTION
installing R files
preparing package Test for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
No definition was found for superclass "SiteResourceCapacity" in the
specification of class "RoleCapacity"
Calls: ... makeClassRepresentation ->
reconcilePropertiesAndPrototype
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-Test] Error 2
*** Installation of Test failed ***
Removing 'c:/PROGRA~1/R/R-2.8.1/library/Test'
Restoring previous 'c:/PROGRA~1/R/R-2.8.1/library/Test'
Then, if I simply change the name of the file "classSiteResourceCapacity.R"
to "aR" , keeping the file "classRoleCapacity" and with no change to the
contents of either file, the package will then pass the CHECK and INSTALL
properly.
C:\TEMP>dir Test\R
Volume in drive C is WINXP
Volume Serial Number is F893-77D5
Directory of C:\TEMP\Test\R
01/08/2009 10:00 AM .
01/08/2009 10:00 AM ..
01/08/2009 09:55 AM 749 aR
01/08/2009 09:54 AM 97 classRoleCapacity.R
2 File(s) 846 bytes
2 Dir(s) 58,195,918,848 bytes free
C:\TEMP>R CMD CHECK Test
* checking for working pdflatex ...pdflatex: not found
NO
* checking for working
Re: [Rd] File name determines success or failure of package installation -- please help
The order of files does matter when your code has side effects (as here),
and I guess you did not specify a Collation: field in the DESCRIPTION
file.
The default order is alphabetic (in the C locale), which is not what you
want here.
On Thu, 8 Jan 2009, behli...@gmail.com wrote:
Synopsis:
I am trying to build and install a package in R, but I have run into a
problem where the file names determine success or failure of the package
installation. I started with a single file containing two class
definitions. This package installs properly. If I split the classes into
two files, the build fails. If I simply change the file name of one file
with no other changes, the build and install then works properly.
This does not seem to be proper behavior.
Why should the results not depend on the order of execution of R
commands?
I assume I am doing something wrong, but I have no idea how to debug or
fix this problem. Details are
How about looking in the manual ('Writing R Extensions')?
shown below. I welcome all help and advice!!
Ron
General Information:
R version: 2.8.1
this is an installation of a precomplied version of R
OS: Windows XP PRO SP2
Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
Details:
In this example, I start with a file named "classSiteResourceCapacity.R"
that contains the defintition of two classes shown below.
file=classSiteResourceCapacity.R
setClass("SiteResourceCapacity",
representation(
site = "character",
siteResource = "character",
studyResource = "character",
capacity = "numeric",
allocation = "matrix",
priority = "matrix"
)
)
setClass("RoleCapacity", representation(loadFactor="numeric"),
contains="SiteResourceCapacity")
The package (containing only this file) works when I run R CMD CHECK or R
CMD INSTALL.
However, when I seperate the classes into two files with the contents shown
below (simply split the file contents, no additional changes), CHECK and
INSTALL now fail as can be seen in the following output.
file=classSiteResourceCapacity.R
setClass("SiteResourceCapacity",
representation(
site = "character",
siteResource = "character",
studyResource = "character",
capacity = "numeric",
allocation = "matrix",
priority = "matrix"
)
)
file=classRoleCapacity.R
setClass("RoleCapacity", representation(loadFactor="numeric"),
contains="SiteResourceCapacity")
C:\TEMP>dir Test\R
Volume in drive C is WINXP
Volume Serial Number is F893-77D5
Directory of C:\TEMP\Test\R
01/08/2009 10:11 AM .
01/08/2009 10:11 AM ..
01/08/2009 09:54 AM 97 classRoleCapacity.R
01/08/2009 09:55 AM 749 classSiteResourceCapacity.R
2 File(s) 846 bytes
2 Dir(s) 58,195,402,752 bytes free
C:\TEMP>R CMD CHECK Test
* checking for working pdflatex ...pdflatex: not found
NO
* checking for working latex ...latex: not found
NO
* using log directory 'C:/TEMP/Test.Rcheck'
* using R version 2.8.1 (2008-12-22)
* using session charset: ISO8859-1
* checking for file 'Test/DESCRIPTION' ... OK
* this is package 'Test' version '0.1'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for .dll and .exe files ... OK
* checking whether package 'Test' can be installed ... ERROR
Installation failed.
See 'C:/TEMP/Test.Rcheck/00install.out' for details.
C:\TEMP>cat 'C:/TEMP/Test.Rcheck/00install.out'
installing R.css in C:/TEMP/Test.Rcheck
-- Making package Test
adding build stamp to DESCRIPTION
installing R files
preparing package Test for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
No definition was found for superclass "SiteResourceCapacity" in the
specification of class "RoleCapacity"
Calls: ... makeClassRepresentation ->
reconcilePropertiesAndPrototype
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-Test] Error 2
*** Installation of Test failed ***
Removing 'C:/TEMP/Test.Rcheck/Test'
C:\TEMP>R CMD INSTALL Test
installing to 'c:/PROGRA~1/R/R-2.8.1/library'
-- Making package Test
adding build stamp to DESCRIPTION
installing R files
preparing package Test for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
No definition was found for superclass "SiteResourceCapacity" in the
specification of class "RoleCapacity"
Calls: ... makeClassRepresentation ->
reconcilePropertiesAndPrototype
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-Test] Error 2
*** Installation of Test failed ***
Removing 'c:/PROGRA~1/R/R-2.8.1/library/Test'
Restoring previous 'c:/PROGRA~1/R/R-2.8.1/library/Test'
Then, if I simply change the name of the file "classSiteResourceCapacity.R"
to "aR" , keeping the file "classRoleCapacity" and with no change to the
contents of either file, the package will then pass the CHECK and INSTALL
properly.
C:\T
