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://
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
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 functi
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
> updat
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 +010
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 a
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 ve
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 hashf
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)
[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
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 i
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 de
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
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-proje
14 matches
Mail list logo
