[Rd] Windows builder: Package X did not pass R CMD check
Dear package maintainers, due to some hicc up in my autobuilder, many CRAN package maintainers got a message about an error in their packages for R-2.5.1. Please ignore that one. My sincere apologies for spamming around, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R2.6 bug in arithmetics of S4 classes inherited from 'array', or intended behavior?
Hi,
I have an S4 class directly derived from 'array' as shown in the code
below (EBImage package of Bioconductor 2.1, devel), it simply contains
array adding a couple of slots:
setClass ("Image",
representation (colormode="integer", filename="character",
compression="character", resolution="numeric", features="list"
),
prototype (colormode= Grayscale, filename="no-name",
compression="JPEG",
resolution=c(2.5e+6, 2.5e+6), features=list()
),
contains = "array"
)
No mathematical/arithmetical routines have been redefined for the class
and this is what I was getting since R2.0, sum of two objects of class
Image is Image again:
version.string R version 2.5.1 (2007-06-27):
> library(EBImage)
> a <- Image(0, c(2,2))
> class(a+a)
[1] "Image"
attr(,"package")
[1] "EBImage"
The same stands for
version.string R version 2.6.0 Under development (unstable) (2007-07-11
r42199)
> library(EBImage)
> a <- Image(0, c(2,2))
> class(a+a)
[1] "Image"
attr(,"package")
[1] "EBImage"
Now, in the yesterday's revision of R2.6 I get the following:
version.string R version 2.6.0 Under development (unstable) (2007-07-21
r42284)
> library(EBImage)
> a <- Image(0, c(2,2))
> class(a+a)
[1] "array"
Is this the intended behavior to fall back to the base class (same for
*,/,-)? If yes, could someone point me to the following two things: what
are the reasons behind and WHAT operators and functions have been
affected -- I will need to redefine all those then. Moreover, it is not
consistent:
> class(a*2)
[1] "Image"
attr(,"package")
[1] "EBImage"
> class(2*a)
[1] "Image"
attr(,"package")
[1] "EBImage"
Unfortunately, I do not have R versions installed between revisions
42199 and 42284, so I cannot narrow down to the particular revision.
Thanks in advance,
Oleg
--
Dr. Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +441223493366
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R2.6 bug in arithmetics of S4 classes inherited from 'array', or intended behavior?
I believe this occurred with the change to make use of implicit generics,
r42246. Please check that for yourself (see the comment at the end).
If so it will need John Chambers' attention (he is currently offline).
On Mon, 23 Jul 2007, Oleg Sklyar wrote:
> Hi,
>
> I have an S4 class directly derived from 'array' as shown in the code
> below (EBImage package of Bioconductor 2.1, devel), it simply contains
> array adding a couple of slots:
>
> setClass ("Image",
> representation (colormode="integer", filename="character",
>compression="character", resolution="numeric", features="list"
> ),
> prototype (colormode= Grayscale, filename="no-name",
> compression="JPEG",
>resolution=c(2.5e+6, 2.5e+6), features=list()
> ),
> contains = "array"
> )
Which is unfortunately not self-contained.
> No mathematical/arithmetical routines have been redefined for the class
> and this is what I was getting since R2.0, sum of two objects of class
> Image is Image again:
>
> version.string R version 2.5.1 (2007-06-27):
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
> The same stands for
>
> version.string R version 2.6.0 Under development (unstable) (2007-07-11
> r42199)
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
> Now, in the yesterday's revision of R2.6 I get the following:
>
> version.string R version 2.6.0 Under development (unstable) (2007-07-21
> r42284)
>
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "array"
>
> Is this the intended behavior to fall back to the base class (same for
> *,/,-)? If yes, could someone point me to the following two things: what
> are the reasons behind and WHAT operators and functions have been
> affected -- I will need to redefine all those then. Moreover, it is not
> consistent:
>
>> class(a*2)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>> class(2*a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
>
> Unfortunately, I do not have R versions installed between revisions
> 42199 and 42284, so I cannot narrow down to the particular revision.
But you can of course get any version out of SVN and thereby narrow this
down. Please don't expect others to do this for you.
svn up -r42245
make
...
svn up -r42246
make
...
confirms it for me.
--
Brian D. Ripley, [EMAIL PROTECTED]
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
[Rd] postscript bug? (PR#9803)
postscript() produces files that are not encoded as eps, according to
the standard. Hence, word processors such as OpenOffice and AbiWord do
not recognise the files as eps. See
http://www.postscript.org/FAQs/language/node80.html
The problem is in the first line of the postscript file: The header is
wrong. It should be:
%!PS-Adobe-3.0 EPSF-3.0
whereas postscript() produces:
%!PS-Adobe-3.0
The following code replicates the problem:
x <- rnorm(10)
y <- rnorm(10)
postscript("test.eps")
plot(x,y)
dev.off()
# Now try importing test.eps into your favorite word processor.
# Now edit test.eps and change the header to the correct header above,
and try importing the file again. Works! (This took me a couple of hours
of hair-pulling to figure out. I sure hope it is a genuine bug. :-) )
Cheers,
Simon.
Version:
platform = x86_64-pc-linux-gnu
arch = x86_64
os = linux-gnu
system = x86_64, linux-gnu
status =
major = 2
minor = 5.1
year = 2007
month = 06
day = 27
svn rev = 42083
language = R
version.string = R version 2.5.1 (2007-06-27)
Locale:
LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;
LC_MESSAGES=en_AU.UTF-8;LC_PAPER=en_AU.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;
LC_MEASUREMENT=en_AU.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
--
Simon Blomberg, BSc (Hons), PhD, MAppStat.
Lecturer and Consultant Statistician
Faculty of Biological and Chemical Sciences
The University of Queensland
St. Lucia Queensland 4072
Australia
Room 320 Goddard Building (8)
T: +61 7 3365 2506
email: S.Blomberg1_at_uq.edu.au
Policies:
1. I will NOT analyse your data for you.
2. Your deadline is your problem.
The combination of some data and an aching desire for
an answer does not ensure that a reasonable answer can
be extracted from a given body of data. - John Tukey.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript bug? (PR#9803)
[EMAIL PROTECTED] wrote:
> postscript() produces files that are not encoded as eps, according to
> the standard. Hence, word processors such as OpenOffice and AbiWord do
> not recognise the files as eps. See
> http://www.postscript.org/FAQs/language/node80.html
>
> The problem is in the first line of the postscript file: The header is
> wrong. It should be:
>
> %!PS-Adobe-3.0 EPSF-3.0
>
> whereas postscript() produces:
>
> %!PS-Adobe-3.0
>
> The following code replicates the problem:
>
> x <- rnorm(10)
> y <- rnorm(10)
> postscript("test.eps")
> plot(x,y)
> dev.off()
>
> # Now try importing test.eps into your favorite word processor.
>
> # Now edit test.eps and change the header to the correct header above,
> and try importing the file again. Works! (This took me a couple of hours
> of hair-pulling to figure out. I sure hope it is a genuine bug. :-) )
>
It isn't a bug. It is as it should be, because a plot file with multiple
pages cannot be EPS.
Try reading the help page for postscript again, this time ( ;-) ) paying
attention to the 'onefile' argument.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R2.6 bug in arithmetics of S4 classes inherited from 'array', or intended behavior?
Narrowed down to Rev. 42246: * ~/R/Rsvn: svn up -r42245 * ~/R/Rsvn: make * ~/R/Rsvn: Rsvn CMD INSTALL ~/tmp/EBImage_2.1.13.tar.gz * ~/R/Rsvn: Rsvn > version$version.string [1] "R version 2.6.0 Under development (unstable) (2007-07-16 r42245)" > library(EBImage) > a <- Image(0,c(2,2)) > class(a+a) [1] "Image" attr(,"package") [1] "EBImage" * ~/R/Rsvn: svn up -r42246 * ~/R/Rsvn: make * ~/R/Rsvn: Rsvn CMD INSTALL ~/tmp/EBImage_2.1.13.tar.gz * ~/R/Rsvn: Rsvn > version$version.string [1] "R version 2.6.0 Under development (unstable) (2007-07-16 r42246)" > library(EBImage) > a <- Image(0,c(2,2)) > class(a+a) [1] "array" * ~/R/Rsvn: svn log -r42246 r42246 | jmc | 2007-07-16 14:32:16 +0100 (Mon, 16 Jul 2007) | 1 line implicitGeneric() and structure class -- Dr. Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +441223494466 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dict package: dictionary data structure for R
Hi Seth. Glad you did this. As you know, I think we need more specialized data structures and the ability to be able to introduce them easily into R computations, both internally and at the R language-level. A few things that come to mind after a quick initial look. The HashFunc typedef in hashfuncs.h would be more flexible if it took an additional argument of type void * to allow for user defined data. Alternatively, it might take the hash table object itself. The function might want to do some updating of the table itself, or look at some table (e.g. for perfect hashing). And if we had a place to provide additional information, it is easy to allow the hash function object to be an R function. Also, you are using a "global" table of hash functions (i.e. Dict_HashFunctions) and looking up the C routine using GET_HASHFUN which is tied to the integer indexing for this global table. Why not use the C routines directly from R, i.e. using getNativeSymbolInfo and pass this from R to the newly created dict. This avoids the lookup, the global table and makes things extensible with routines in packages and simply extends to allowing R functions to be passed instead of C routines. It also removes the need to synchronize the labeling system in R and in C, i.e. that 0L corresponds to PJW. The reliance on synchronized names rather than direct handles is unnecessary although widely used in S/R code. I'm more than happy to give some code to illustrate what I mean more precisely if you'd like it. D. Seth Falcon wrote: > Hi all, > > The dict package provides a dictionary (hashtable) data > structure much like R's built-in environment objects, but with the > following differences: > > - The Dict class can be subclassed. > > - Four different hashing functions are implemented and the user can > specify which to use when creating an instance. > > I'm sending this here as opposed to R-packages because this package > will only be of interest to developers and because I'd like to get > feedback from a slightly smaller community before either putting it on > CRAN or retiring it to /dev/null. > > The design makes it fairly easy to add additional hashing functions, > although currently this must be done in C. If nothing else, this > package should be useful for evaluating hashing functions (see the > vignette for some examples). > > Source: > R-2.6.x: http://userprimary.net/software/dict_0.1.0.tar.gz > R-2.5.x: http://userprimary.net/software/dict_0.0.4.tar.gz > > Windows binary: > R-2.5.x: http://userprimary.net/software/dict_0.0.4.zip > > > + seth > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CHAR(STRING_ELT( - OK but CHAR(asChar(STRING_ELT( - not, why?
Any idea why CHAR(asChar(STRING_ELT( produces NA whereas
CHAR(STRING_ELT( gets a pointer to a string? It's generally expected
that STRING_ELT should already be a character, but why the coercion does
not work? Here is a simple example (consistent over R2.5.1-R2.6 rev
42284, I didn't check earlier versions, but it used to be different in
2.4):
install.packages("inline")
library(inline)
sig <- signature(x="character")
code1 <- "
for (int i = 0; i < LENGTH(x); i++ )
Rprintf(\"%s\\n\", CHAR(STRING_ELT(x, i)));
return R_NilValue;
"
code2 <- "
for (int i = 0; i < LENGTH(x); i++ )
Rprintf(\"%s\\n\", CHAR(asChar(STRING_ELT(x, i;
return R_NilValue;
"
setCMethod(c("p1","p2"), list(sig,sig), list(code1,code2))
#--
p1(c("str1", "str2"))
# str1
# str2
# NULL
p2(c("str1", "str2"))
# NA
# NA
# NULL
--
Dr. Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +441223494466
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CHAR(STRING_ELT( - OK but CHAR(asChar(STRING_ELT( - not, why?
I think you are asking why calling asChar on a CHARSXP gives NA_STRING.
In particular, the calls you mention *are* perfectly OK and work as
intended.
As barely documented in R-exts, asChar is designed for vector arguments: a
CHARSXP is not a vector. It gives NA_STRING for invalid inputs.
The as family of functions are designed to coerce as necessary user
inputs, and CHARSXPs are not visible at R level.
In general, with internal functions you are expected to read the code to
find out what they do before using them.
On Mon, 23 Jul 2007, Oleg Sklyar wrote:
> Any idea why CHAR(asChar(STRING_ELT( produces NA whereas
> CHAR(STRING_ELT( gets a pointer to a string? It's generally expected
> that STRING_ELT should already be a character,
It is required to be a CHARSXP, but 'character' usually refers to STRSXP.
> but why the coercion does not work? Here is a simple example (consistent
> over R2.5.1-R2.6 rev 42284, I didn't check earlier versions, but it used
> to be different in 2.4):
There is no R '2.4', but the behaviour of asChar was the same in R 2.4.0
except for the adding of SYMSXP at
-
r40358 | maechler | 2007-01-04 11:07:04 + (Thu, 04 Jan 2007) | 1 line
eliminate CHAR_STAR in methods/src/ as per old "todo"
-
which message does not help me at all. Perhaps Martin can explain?
> install.packages("inline")
>
> library(inline)
>
> sig <- signature(x="character")
> code1 <- "
> for (int i = 0; i < LENGTH(x); i++ )
>Rprintf(\"%s\\n\", CHAR(STRING_ELT(x, i)));
> return R_NilValue;
> "
>
> code2 <- "
> for (int i = 0; i < LENGTH(x); i++ )
>Rprintf(\"%s\\n\", CHAR(asChar(STRING_ELT(x, i;
> return R_NilValue;
> "
>
> setCMethod(c("p1","p2"), list(sig,sig), list(code1,code2))
>
>
> #--
> p1(c("str1", "str2"))
> # str1
> # str2
> # NULL
>
> p2(c("str1", "str2"))
> # NA
> # NA
> # NULL
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] CHAR(STRING_ELT( - OK but CHAR(asChar(STRING_ELT( - not, why?
Thank you Prof. Ripley. Funny enough after digging in the R sources I
was just writing a reply to my own question (in case someone else would
find it interesting) and it was approximately the same as what you
write. It just slipped from my attention initially.
O.
On Mon, 2007-07-23 at 13:22 +0100, Prof Brian Ripley wrote:
> I think you are asking why calling asChar on a CHARSXP gives NA_STRING.
> In particular, the calls you mention *are* perfectly OK and work as
> intended.
>
> As barely documented in R-exts, asChar is designed for vector arguments: a
> CHARSXP is not a vector. It gives NA_STRING for invalid inputs.
> The as family of functions are designed to coerce as necessary user
> inputs, and CHARSXPs are not visible at R level.
>
> In general, with internal functions you are expected to read the code to
> find out what they do before using them.
>
> On Mon, 23 Jul 2007, Oleg Sklyar wrote:
>
> > Any idea why CHAR(asChar(STRING_ELT( produces NA whereas
> > CHAR(STRING_ELT( gets a pointer to a string? It's generally expected
> > that STRING_ELT should already be a character,
>
> It is required to be a CHARSXP, but 'character' usually refers to STRSXP.
>
> > but why the coercion does not work? Here is a simple example (consistent
> > over R2.5.1-R2.6 rev 42284, I didn't check earlier versions, but it used
> > to be different in 2.4):
>
> There is no R '2.4', but the behaviour of asChar was the same in R 2.4.0
> except for the adding of SYMSXP at
>
> -
> r40358 | maechler | 2007-01-04 11:07:04 + (Thu, 04 Jan 2007) | 1 line
>
> eliminate CHAR_STAR in methods/src/ as per old "todo"
> -
>
> which message does not help me at all. Perhaps Martin can explain?
>
>
> > install.packages("inline")
> >
> > library(inline)
> >
> > sig <- signature(x="character")
> > code1 <- "
> > for (int i = 0; i < LENGTH(x); i++ )
> >Rprintf(\"%s\\n\", CHAR(STRING_ELT(x, i)));
> > return R_NilValue;
> > "
> >
> > code2 <- "
> > for (int i = 0; i < LENGTH(x); i++ )
> >Rprintf(\"%s\\n\", CHAR(asChar(STRING_ELT(x, i;
> > return R_NilValue;
> > "
> >
> > setCMethod(c("p1","p2"), list(sig,sig), list(code1,code2))
> >
> >
> > #--
> > p1(c("str1", "str2"))
> > # str1
> > # str2
> > # NULL
> >
> > p2(c("str1", "str2"))
> > # NA
> > # NA
> > # NULL
> >
> >
> >
>
--
Dr. Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +441223494466
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dict package: dictionary data structure for R
Duncan Temple Lang <[EMAIL PROTECTED]> writes: > The HashFunc typedef in hashfuncs.h would be more flexible if it > took an additional argument of type void * to allow for user > defined data. Alternatively, it might take the hash table > object itself. The function might want to do some > updating of the table itself, or look at some table (e.g. for perfect > hashing). And if we had a place to provide additional information, it > is easy to allow the hash function object to be an R function. Worth considering. I don't think perfect hashing is in scope here, but would need to give it more thought -- seems to me that perfect hashing would be better served by something separate. > Also, you are using a "global" table of hash functions > (i.e. Dict_HashFunctions) and looking up the C routine using > GET_HASHFUN > which is tied to the integer indexing for this global table. > Why not use the C routines directly from R, i.e. using > getNativeSymbolInfo and pass this from R to the newly created > dict. This avoids the lookup, the global table and makes things > extensible with routines in packages and simply extends to allowing > R functions to be passed instead of C routines. > It also removes the need to synchronize the labeling system in > R and in C, i.e. that 0L corresponds to PJW. The reliance on > synchronized names rather than direct handles is unnecessary > although widely used in S/R code. Why not? Only because I didn't think of it ;-) > I'm more than happy to give some code to illustrate what I mean > more precisely if you'd like it. Sure. At the same time, I'm a bit hesitant to invest further in dict until I get a sense of whether or not it might actually be useful to people. It's main use may turn out to be for investigating hash functions behavior and for a test tool it may be sufficient as-is. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dict package: dictionary data structure for R
Bill Dunlap <[EMAIL PROTECTED]> writes: > With environments, if you use a prime number for the size > you get considerably better results. E.g., > Perhaps new.env() should push the requested size up > to the next prime by default. Perhaps. I think we should also investigate other hashing functions since computing the next prime and doing so for resizes will take longer than not having to do it and it will add complexity to the code. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.5.1 - typo in ?'::'
Within ?'::' output, just before "See Also:", "environent" might be a misspelling of "environment". -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript bug? (PR#9803)
D'oh!
Simon.
On Mon, 2007-07-23 at 12:36 +0200, Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
> > postscript() produces files that are not encoded as eps, according to
> > the standard. Hence, word processors such as OpenOffice and AbiWord do
> > not recognise the files as eps. See
> > http://www.postscript.org/FAQs/language/node80.html
> >
> > The problem is in the first line of the postscript file: The header is
> > wrong. It should be:
> >
> > %!PS-Adobe-3.0 EPSF-3.0
> >
> > whereas postscript() produces:
> >
> > %!PS-Adobe-3.0
> >
> > The following code replicates the problem:
> >
> > x <- rnorm(10)
> > y <- rnorm(10)
> > postscript("test.eps")
> > plot(x,y)
> > dev.off()
> >
> > # Now try importing test.eps into your favorite word processor.
> >
> > # Now edit test.eps and change the header to the correct header above,
> > and try importing the file again. Works! (This took me a couple of hours
> > of hair-pulling to figure out. I sure hope it is a genuine bug. :-) )
> >
> It isn't a bug. It is as it should be, because a plot file with multiple
> pages cannot be EPS.
>
> Try reading the help page for postscript again, this time ( ;-) ) paying
> attention to the 'onefile' argument.
>
--
Simon Blomberg, BSc (Hons), PhD, MAppStat.
Lecturer and Consultant Statistician
Faculty of Biological and Chemical Sciences
The University of Queensland
St. Lucia Queensland 4072
Australia
Room 320 Goddard Building (8)
T: +61 7 3365 2506
email: S.Blomberg1_at_uq.edu.au
Policies:
1. I will NOT analyse your data for you.
2. Your deadline is your problem.
The combination of some data and an aching desire for
an answer does not ensure that a reasonable answer can
be extracted from a given body of data. - John Tukey.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
