Re: [Rd] MinGW and the ld bug
On 2/13/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > I believe the bug is triggered by the fairly unusual event you have a '.' > in the package name, and the change in 2.2.1 to 2.2.1 patched was to add > > > LIBRARY R.native.dll > > (which is what my workaround in ld.exe was doing another way). > > Since we are told that is the correct form and we were using it > incorrectly before, I don't really know how to work around this. For you, > just delete .dll in the following line in src/gnuwin32/MkRules > > %.dll: > @$(ECHO) LIBRARY $*.dll > $*.def Thanks. With "@$(ECHO) LIBRARY $ > $*.def" it works again. All the best, Henrik > but that is not a general solution. > > > On Mon, 13 Feb 2006, Henrik Bengtsson wrote: > > > Hi. > > > > I noticed that Brian Ripley found and corrected a bug in MinGW's > > ld.exe, see http://www.murdoch-sutherland.com/Rtools/. Thanks for > > this. I wonder if this is the same bug that cause my problems. I > > have tiny toy package with C code that installs perfectly on R Version > > 2.2.1 beta (2005-12-18 r36792) [this version was mislabelled "beta" > > the first few hours on CRAN when the stable 2.2.1 version first came > > out]. However, when I try to install the same on R Version 2.2.1 > > Patched (2006-02-09 r37305) as well as R Version 2.3.0 Under > > development (unstable) (2006-02-02 r37243), I get the following error: > > > > C:\Documents and Settings\hb\braju.com.R\R.native\build>Rcmd install > > R.native > > > > -- Making package R.native > > adding build stamp to DESCRIPTION > > making DLL ... > > making rowMedians.d from rowMedians.c > > gcc -IC:/PROGRA~1/R/R-2.2.1pat/include -Wall -O2 -c rowMedians.c -o > > rowMedia > > ns.o > > ar cr R.native.a rowMedians.o > > ranlib R.native.a > > windres --include-dir C:/PROGRA~1/R/R-2.2.1pat/include -i R.native_res.rc > > -o R. > > native_res.o > > gcc --shared -s -o R.native.dll R.native.def R.native.a R.native_res.o > > -LC:/P > > ROGRA~1/R/R-2.2.1pat/src/gnuwin32 -lg2c -lR > > c:\MinGW\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe: > > R.native.d > > ef:1: syntax error > > c:\MinGW\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe:R.native.de > > f: file format not recognized; treating as linker script > > c:\MinGW\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe:R.native.de > > f:1: syntax error > > collect2: ld returned 1 exit status > > make[3]: *** [R.native.dll] Error 1 > > make[2]: *** [srcDynlib] Error 2 > > make[1]: *** [all] Error 2 > > make: *** [pkg-R.native] Error 2 > > *** Installation of R.native failed *** > > > > Removing 'C:/PROGRA~1/R/R-2.2.1pat/library/R.native' > > Restoring previous 'C:/PROGRA~1/R/R-2.2.1pat/library/R.native' > > > > My R.native.def looks like this: > > > > LIBRARY R.native.dll > > EXPORTS > > rowMedians > > rowMediansInteger > > rowMediansReal > > > > I've tried to replace the two occurances of ld.exe in MINGW with BR's > > patch, but I get the same error. The ld of the patch and the original > > one show the same version string; > > patch: GNU ld version 2.16.91 20050827 and original: GNU ld version > > 2.16.91 20050827. I've tried to use both MINGW v5.0.0 and v5.0.2 with > > both "current" (v3.4.2) and "candidate" (v3.4.4) packages. > > Hmm, only 3.4.5 is there as a candidate. > > > Is this related to the bug BR found? Any suggestions what might go > > wrong between R v2.2.1 and v2.2.1 patched? > > > > Thanks > > > > Henrik > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > 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] addmargins
On Mon, 13 Feb 2006, J. Hosking wrote: > > addmargins(UCBAdmissions, FUN = list(Total=sum)) > > works with no problems, but consider: > > > myFUN <- list(Total=sum) > > addmargins(UCBAdmissions, FUN = myFUN) > Error in "names<-.default"(`*tmp*`, value = "") : > names() applied to a non-vector > > Is this a bug? I believe so. addmargins contains FUN <- eval(add.names(substitute(FUN))) and that only makes sense if FUN is a call and not a symbol. I've made the appropriate change to R-devel. -- 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] S4 classes and methods with optional arguments
Hi,
i have used S4 classes to implement a unified access to random number generators
(package rstream on CRAN).
I have used a construct to allow optional arguments:
if(!isGeneric("rstream.sample"))
setGeneric("rstream.sample", function(stream,...)
standardGeneric("rstream.sample"))
setMethod("rstream.sample", c("rstream","numeric"),
function(stream,n=1) { ... [ code ] ... } )
Thus if rs is an instance of an rstream object one can a random
sample of size 10 using
rstream.sample(rs, 10)
for a sample of size 1 one can use equivalently
rstream.sample(rs,1)
rstream.sample(rs)
however, with R-devel the above construct does not work any more, due to
more stringent checkings. It can be fixed by replacing it by
if(!isGeneric("rstream.sample"))
setGeneric("rstream.sample", function(stream,n)
standardGeneric("rstream.sample"))
setMethod("rstream.sample", c("rstream","numeric"),
function(stream,n=1) { ... [ code ] ... } )
then rstream.sample(rs) does not work any more.
Is there still a way to allow optional arguments for methods of
S4 classes?
Josef
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 classes and methods with optional arguments
Hi Josef,
On 14 Feb 2006, [EMAIL PROTECTED] wrote:
> I have used a construct to allow optional arguments:
>
> if(!isGeneric("rstream.sample")) setGeneric("rstream.sample",
> function(stream,...) standardGeneric("rstream.sample"))
First, a question:
Is this idiom of testing for the generic before defining it still
"recommended"? It seems to me that one should either define one's
own generic in the package namespace or define a method for a
*particular* generic defined elsewhere. Otherwise, one could end up
defining a method for the wrong generic.
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
This will work if you remove the second arg in the signature. That
is,
setMethod("rstream.sample", signature(stream="rstream"),
function(strea, n=1) { ... })
Putting an arg in the signature means dispatching on that arg. You
cannot dispatch on an arg that is not named in the definition of the
generic.
> however, with R-devel the above construct does not work any more,
> due to more stringent checkings. It can be fixed by replacing it by
>
> if(!isGeneric("rstream.sample")) setGeneric("rstream.sample",
> function(stream,n) standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
>
> then rstream.sample(rs) does not work any more.
>
> Is there still a way to allow optional arguments for methods of S4
> classes?
Here's an approach that works for me:
1. You have to specify a default value to args *in the generic*. This
doesn't make a whole lot of sense to me, but it does seem to be
needed.
setGeneric("rstream.sample",
function(stream, n=0) standardGeneric("rstream.sample"))
2. Then define a method with a signature that matches the default
case:
setMethod("rstream.sample", signature(stream="rstream", n="missing"),
function(stream, n=1) { ... })
Note that you could also use signature(stream="rstream"), but then
a call like rstream.sample(s, "foo") could match... Leaving out the
arg is like saying n="ANY".
HTH,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 classes and methods with optional arguments
The problem is not the optional argument, but the attempt to dispatch on
an argument not in the generic.
setGeneric("rstream.sample", function(stream, ...)
standardGeneric("rstream.sample"))
setMethod("rstream.sample", "rstream", function(stream,n=1) { print(n) } )
rstream.sample(rs, 10)
[1] 10
rstream.sample(rs)
[1] 1
works, and seems to work as you intended.
On Tue, 14 Feb 2006, Josef Leydold wrote:
> Hi,
>
> i have used S4 classes to implement a unified access to random number
> generators
> (package rstream on CRAN).
>
> I have used a construct to allow optional arguments:
>
> if(!isGeneric("rstream.sample"))
>setGeneric("rstream.sample", function(stream,...)
> standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
>
> Thus if rs is an instance of an rstream object one can a random
> sample of size 10 using
>
> rstream.sample(rs, 10)
>
> for a sample of size 1 one can use equivalently
>
> rstream.sample(rs,1)
> rstream.sample(rs)
>
> however, with R-devel the above construct does not work any more, due to
> more stringent checkings. It can be fixed by replacing it by
>
> if(!isGeneric("rstream.sample"))
>setGeneric("rstream.sample", function(stream,n)
> standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
>
> then rstream.sample(rs) does not work any more.
>
> Is there still a way to allow optional arguments for methods of
> S4 classes?
>
> Josef
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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] S4 classes and methods with optional arguments
Echoing similar suggestions, but with a bit of philosophy... How about:
setGeneric("rstream.sample",
function( stream, ... ) standardGeneric("rstream.sample"))
setMethod("rstream.sample", c( "numeric" ),
function( stream, n = 1, ... ) { code } )
It seems to me like the generic should (always?) just have arguments
used for dispatch -- stream, in this case -- and that methods then
specify default values. To also dispatch on the second argument, one
might
setGeneric("rstream.sample",
function( stream, n, ... ) standardGeneric("rstream.sample"))
setMethod("rstream.sample", c( "rstream.sample", "numeric" ),
function( stream, n, ... ) { code } )
setMethod("rstream.sample", c( "rstream.sample", "missing" ),
function( stream, n, ... ) rstream.sample( stream, n = 1 ))
setMethod("rstream.sample", c( "rstream.sample", "otherclass" ),
function( stream, n, ... ) n )
Martin
"Josef Leydold" <[EMAIL PROTECTED]> writes:
> Hi,
>
> i have used S4 classes to implement a unified access to random number
> generators
> (package rstream on CRAN).
>
> I have used a construct to allow optional arguments:
>
> if(!isGeneric("rstream.sample"))
> setGeneric("rstream.sample", function(stream,...)
> standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
>
> Thus if rs is an instance of an rstream object one can a random
> sample of size 10 using
>
> rstream.sample(rs, 10)
>
> for a sample of size 1 one can use equivalently
>
> rstream.sample(rs,1)
> rstream.sample(rs)
>
> however, with R-devel the above construct does not work any more, due to
> more stringent checkings. It can be fixed by replacing it by
>
> if(!isGeneric("rstream.sample"))
> setGeneric("rstream.sample", function(stream,n)
> standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c("rstream","numeric"),
> function(stream,n=1) { ... [ code ] ... } )
>
> then rstream.sample(rs) does not work any more.
>
> Is there still a way to allow optional arguments for methods of
> S4 classes?
>
> Josef
>
> __
> 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] S4 classes and methods with optional arguments
On 14 Feb 2006, [EMAIL PROTECTED] wrote:
> It seems to me like the generic should (always?) just have arguments
> used for dispatch -- stream, in this case -- and that methods then
> specify default values.
There are advantages to adding named arguments to a generic to define
the expected interface. These 'extra' args may not be *needed* for
dispatch in the sense that the first arg may be enough to decide what
method you want.
So IMO, there are two reasons to put an arg in a generic:
1. You really want to dispatch on it.
2. You want to define an interface and can handle the fact that you
will have to also dispatch on it.
I guess my point is that for downstream developers extending your
generic and for the sake of documentation, relying too much on '...'
can make things difficult.
> To also dispatch on the second argument, one
> might
>
> setGeneric("rstream.sample",
> function( stream, n, ... ) standardGeneric("rstream.sample"))
>
> setMethod("rstream.sample", c( "rstream.sample", "numeric" ),
> function( stream, n, ... ) { code } )
>
> setMethod("rstream.sample", c( "rstream.sample", "missing" ),
> function( stream, n, ... ) rstream.sample( stream, n = 1 ))
And here I might offer a slight improvement. Putting the default
value in the signature of the function will give automated tools a
chance to document:
setMethod("rstream.sample", c("rstream.sample", "missing"),
function( stream, n=1, ...) rstream.sample(stream, n))
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Legend to a heatmap
List, I want to add a color legend to a heatmap , similar to the one in levelplot and filled.contour plot. The legend should contain the colors used in the heatmap along with values for each color range. Can this be done? Please help. Thanks, Akkineni. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
