[Rd] Undocumented S4 methods: generic 'show'
Dear R-Devel subsriber,
during the set-up of a package with a NAMESPACE I stumbled over the
following warning during:
R CMD check -l c:/R/package smem
## skipped output
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
generic 'show' and siglist 'equation'
All user-level objects in a package (including S4 classes and methods)
## skipped output
However, I do have in the Rd.-file for class 'equation' an \alias{} as:
\alias{show, equation-method}
and I have included in the same file:
\section{Methods}{
\describe{
\item{show}{\code{signature(object = "equation")}: Prints the
formula and the type of an equation.}
}
}
The show-method for objects of class 'equation' is defined as:
setMethod("show", signature(object = "equation"), function(object){
cat("\nFormula:\n")
print([EMAIL PROTECTED])
cat(paste("Type of equation:", [EMAIL PROTECTED], "\n"))
}
)
In the NAMESPACE, I have included:
exportMethods("show")
Any pointers are most welcome.
Best,
Bernhard
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major 2
minor 5.0
year 2006
month 10
day10
svn rev39600
language R
version.string R version 2.5.0 Under development (unstable) (2006-10-10
r39600)
>
Dr. Bernhard Pfaff
Global Structured Products Group
(Europe)
Invesco Asset Management Deutschland GmbH
Bleichstrasse 60-62
D-60313 Frankfurt am Main
Tel: +49(0)69 29807 230
Fax: +49(0)69 29807 178
Email: [EMAIL PROTECTED]
*
Confidentiality Note: The information contained in this mess...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented S4 methods: generic 'show'
On Wed, 22 Nov 2006, Pfaff, Bernhard Dr. wrote:
> Dear R-Devel subsriber,
>
> during the set-up of a package with a NAMESPACE I stumbled over the
> following warning during:
>
> R CMD check -l c:/R/package smem
>
> ## skipped output
> * checking for missing documentation entries ... WARNING
> Undocumented S4 methods:
> generic 'show' and siglist 'equation'
> All user-level objects in a package (including S4 classes and methods)
> ## skipped output
>
> However, I do have in the Rd.-file for class 'equation' an \alias{} as:
>
> \alias{show, equation-method}
There are no spaces in the examples in Writing R Extensions, so I would
not have assumed they are allowed. Does it work without the space? (If
it supposed to, we need to document that.)
--
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] Undocumented S4 methods: generic 'show'
>On Wed, 22 Nov 2006, Pfaff, Bernhard Dr. wrote:
>>
>> \alias{show, equation-method}
>
>There are no spaces in the examples in Writing R Extensions,
>so I would
>not have assumed they are allowed. Does it work without the
>space? (If
>it supposed to, we need to document that.)
Dear Prof. Ripley, Dear Kurt,
many thanks for your swift replies. Yes, after dropping the space in the
\alias{} everything works fine.
Apologies for not having read the documentation carefully enough and
indeed in section 2.1.3 it is stated:
"generic,signature_list-method"
furthermore, in the following paragraph it is clearly written:
"...where signature list contains the names of the classes in the
signature of the method (without
quotes) separated by ',' (without whitespace),..."
Hence, the fine manual is pretty explicit about whitespaces (which I
have not compared carefully enough with my ill-footed \alias{}
directive).
Best,
Bernhard
>
>--
>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
>
*
Confidentiality Note: The information contained in this mess...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package vignettes, suggests and R CMD check
Peter Ruckdeschel wrote:
> Dear R-devels,
>
> We have encountered a problem concerning a dead lock in the dependency graph:
>
> We have two packages A1 and A2 where A2 extends A1.
>
> We have one package vignette for both packages, but which should be included
> into package A1.
>
> So in the "suggests" field of the DESCRIPTION file of A1 we suggest A2
> to be able to produce the vignette at build/install time.
>
> On the other hand this means that A2 has to be installed before being
> able to check A1, and A1, of course, has to be installed before being
> able to check A2.
>
> How can this dead lock be resolved?
>
> Is this a case for a bundle? And can a bundle have its own vignette?
Vignettes just go in one of the packages. There is not really a "bundle
vignette", and also no really good place to put vignettes if they are
more general than one of the packages. I'm not sure if a bundle will
resolve the deadlock. (Kurt might know if it should.) The way I have
handle this problem in dse is to put pieces of the vignettes in
different packages, so the part that requires the additional
functionality goes in A2, and A1 does not require A2. That allows me to
check the packages individually. Then when I build the bundle I splice
together the pdf files and put the combined pdf in one of the packages
(which I think users may find a bit confusing, but there is no other place).
Paul
>
> Thanks for listening
> Peter, Matthias, Florian, Thomas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package vignettes, suggests and R CMD check
Assuming you don't want to split it tup: In A1 place a file A1-packages.Rd which documents all sources of documentation for A1. That can refers the user to the vignette in A2. packages?A1 will bring it up this information help file. You could also considering having a one line vignette in A1 which just says see the vignette in A2 and/or which provides a link which when clicked gets it from the web. Another possibility is to include the vignette in A2 and just the pdf of it in A1. On 11/21/06, Peter Ruckdeschel <[EMAIL PROTECTED]> wrote: > Dear R-devels, > > We have encountered a problem concerning a dead lock in the dependency graph: > > We have two packages A1 and A2 where A2 extends A1. > > We have one package vignette for both packages, but which should be included > into package A1. > > So in the "suggests" field of the DESCRIPTION file of A1 we suggest A2 > to be able to produce the vignette at build/install time. > > On the other hand this means that A2 has to be installed before being > able to check A1, and A1, of course, has to be installed before being > able to check A2. > > How can this dead lock be resolved? > > Is this a case for a bundle? And can a bundle have its own vignette? > > Thanks for listening > Peter, Matthias, Florian, Thomas > > __ > 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] dyn.load
To answer my own question - you can use DllMain with Rwin_fpset() to get
around this error message.
Am still struggling though as it crashes when it tries to call a function
in the wrapped DLL - any ideas on how to debug this?
Hope this is of help to some one
Tom
On Tue, 21 Nov 2006 17:30:56 -, Tom McCallum
<[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> Now I know there is information on this in the help files - which I have
> read. I am very close to implementing this but can't quite get how to
> remove this final hurdle.
>
> I have a DLL called "X.DLL" which I have no original code for, just the
> DLL.
> I have created a wrapper C file for the calls in X.DLL, and have
> successfully (I think) created a wrapper DLL for X called, lets say,
> WRAPX.DLL.
>
> On performing:
>
>> dyn.load("WRAPX.dll")
>
> in the Rgui terminal, I then received this warning:
>
> Warning message:
> DLL attempted to change FPU control word from 8001f to 9001f
>
> Getting rid of this error was part of the reason for writing WRAPX.DLL,
> as
> X.DLL seems to play about with this register.
>
> So having another look at the manual entry, I then used the function
> Rwin_fpset() (in gnuwin32/extra.c) to reset the FPU control register when
> I leave all the functions in WRAPX.DLL. But the problem persists. In
> the
> Delphi example in the manual, which I have put at the end of this
> message,
> ( and I have never programmed in Delphi before so I am guessing ) there
> is
> the opportunity on loading the dynamic library to set this register, but
> I
> am wondering where in the C file I can put this command so that when
> dyn.load is called it is not upset by X.DLL changing this register. I
> think I need the following passage of play to occur:
>
> USER : > dyn.load("WRAPX.DLL");
> R : Calls WRAPX.DLL
> WRAPX.DLL : WRAPX.DLL initialises X.DLL which interferes with FPU
> register
> WRAPX.DLL : Calls Rwin_fpset() to reset FPU register
> R : R tests FPU register and is happy
> USER : Sees "Success library is loaded!" or something to that effect
> :)
>
> Any ideas on how to achieve this?
>
> Many thanks
>
> Tom
>
> DELPHI CODE=
>
> procedure Rwin_fpset; cdecl; external 'R.dll';
>
> function Get8087CW:word;
> begin
>asm
> fstcw result
>end;
> end;
>
> begin
>Rwin_fpset(); <== these lines I think is called on
> loading
> of the DLL to reset the register
>Set8087CW(Get8087CW); <
> end.
>
> ===END DELPHI CODE=
>
>
>
> --
> Dr. Thomas McCallum
> Systems Architect,
> Level E Limited
> ETTC, The King's Buildings
> Mayfield Road,
> Edinburgh EH9 3JL, UK
> Work +44 (0) 131 472 4813
> Fax: +44 (0) 131 472 4719
> http://www.levelelimited.com
> Email: [EMAIL PROTECTED]
>
> Level E is a limited company incorporated in Scotland. The
> c...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ralloc clash
Hi everyone,
Have been trying to include windows.h (from MinGW) and R.h into a package
and have found that Ralloc is coming up as a clash no matter which include
ordering I use. In windows it has 2 arguments and is defined in objidl.h
and in R.h it is 3 arguments. Any ideas of how to work round this? Have
checked the web and have not seen anyone else comment on this.
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c.factor
I noticed that a new feature in R 2.4 is that unlist of a list of factors
already does the operation that I proposed :
> x = factor(letters[1:5])
> y = factor(letters[4:8])
> unlist(list(x,y))
[1] a b c d e d e f g h
Levels: a b c d e f g h
>
Therefore, does it not make sense that c(x,y) should return the same as
unlist(list(x,y)) ?
Also, the specific "if" for factors inside the definition of unlist, not
surprisingly, uses a very similar method to those previously posted.
However, it first coerces the factors with as.character, before matching to
the new level set. This is inefficient. Here is the c.factor method again
that I proposed, which avoids the as.character and is therefore more
efficient. Leaving aside the discussion about c.factor, or concat, or
whatever, could 'unlist' be changed to use this method instead ? After
all one of the key advantages of factors is to save main memory, anything
which coerces back to character is going to defeat the benefit.
> c.factor = function(...) {
args <- list(...)
if (!all(sapply(args, is.factor))) stop("all arguments must be factor")
newlevels = unique(unlist(lapply(args,levels)))
ans = unlist(lapply(args, function(x) {
m = match(levels(x), newlevels)
m[as.integer(x)]
}))
levels(ans) = newlevels
class(ans) = "factor"
ans
}
> identical(c(x,y), unlist(list(x,y)))
[1] TRUE
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.0
year 2006
month 10
day03
svn rev39566
language R
version.string R version 2.4.0 (2006-10-03)
>
"Brian Ripley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Tue, 14 Nov 2006, Bill Dunlap wrote:
>
>> On Tue, 14 Nov 2006, Prof Brian Ripley wrote:
>>
>>> Well, R has managed without a factor method for c() for most of its
>>> decade
>>> of existence (not that it originally had factors as we know them).
>>>
>>> I would argue that factors are best viewed as an enumeration type, and
>>> anything which silently changes their level set is a bad idea. I can
>>> see
>>> a case for a c() method for factors that combines factors with the same
>>> level sets, but I can also see this is best done by users who know the
>>> level sets are same (c.factor would have to expend a considerable effort
>>> to check).
>>>
>>> You also need to consider the dispatch rules. c.factor will be called
>>> whenever the first argument is a factor, whatever the others are. S4 (I
>>> think, definitely S4-based versions of S-PLUS) has an alternative
>>> concat()
>>> that works differently (recursively) and seems a more natural model.
>>
>> In addition, c() has always had a double meaning of
>> (a) turning an object into a simple "vector" (an object
>> without "attributes"), as in
>> > c(factor(c("Cat","Dog","Cat")))
>> [1] 1 2 1
>> > c(data.frame(x=1:2,y=c("Dog","Cat")))
>> $x
>> [1] 1 2
>>
>> $y
>> [1] Dog Cat
>> Levels: Cat Dog
>
> To my surprise that was not documented at all on the R help page, and I've
> clarified it. (BTW, at least in R it does not remove names, just all
> other attributes.)
>
>> (b) concatenating several such vectors into one.
>>
>> The proposed c.factor does only (b).
>
> (Strictly not, as a factor is not a vector.)
>
> But the help page explicitly only describes the default method, and some
> of the other methods do preserve some attributes, AFAIR.
>
>> Should we just
>> throw c() into the ash heap and use as.vector() or
>> concat() instead?
>>
>> The whole concept of concatenating objects of disparate
>> types is suspect.
>
> I think working on a concat() for R would be helpful. I vaguely recalled
> something like it in the Green Book, but the index does not help (but then
> it is not very complete).
>
> Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sued Tuerkei.
Sehr geehrte Damen und Herren, Als SI GROUP Für Herbst und Winter haben wir Ihnen ein preislich unschlagbares Angebot an die türkische Riviera-BELEK Halb Pansion 5 Sterne Hotels anzubieten. Ab Zuerich und Basel. INCLUSIV FLUG Hin und Zurück und 8-tägige Ferien an der Türkischen Riviera-Antalya-5 Sterne Halb Pansion(Frühstück und Abendessen) TERMINE UND PREISE- 06.01. bis 13.01.2007 Euro 295 13.01. bis 20.01.2007 Euro 295 20.01. bis 27.01.2007 Euro 295 27.01. bis 03.02.2007 Euro 295 03.02. bis 10.02.2007 Euro 295 10.02. bis 17.02.2007 Euro 295 17.02. bis 24.02.2007 Euro 295 24.02. bis 03.03.2007 Euro 295 03.03. bis 10.03.2007 Euro 295 10.03. bis 17.03.2007 Euro 295 17.03. bis 24.03.2007 Euro 295 24.03. bis 31.03.2007 Euro 295 31.03. bis 07.04.2007 Euro 295 07.04. bis 14.04.2007 Euro 295 14.04. bis 21.04.2007 Euro 295 21.04. bis 28.04.2007 Euro 395 28.04. bis 05.05.2007 Euro 390 Inklusivleistungen: 6 Übernachtungen im 5 - Sterne - Hotel im Doppelzimmer. 1 Übernachtung in einem Thermalhotel in Pamukkale. 7 x Halbpension. Begrüßungscocktail. 1 eintägiger Ausflug nach Antalya mit Bootsfahrt. Alle Eintritte während der Reise. Klimatisierte Busse für 2 Ausflüge. Reiseleitung. Mit Herzlichen Grüssen. SI GROUP www.si-groupreisen.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c.factor
I just noticed that a new feature in R 2.4 is that unlist of a list of
factors
already does the operation that I proposed :
> x = factor(letters[1:5])
> y = factor(letters[4:8])
> unlist(list(x,y))
[1] a b c d e d e f g h
Levels: a b c d e f g h
>
Therefore, does it not make sense that c(x,y) should return the same as
unlist(list(x,y)) ?
Also, the specific "if" for factors inside the definition of unlist, not
surprisingly, uses a very similar method to those previously posted.
However, it first coerces the factors with as.character, before matching
to
the new level set. This is inefficient. Here is the c.factor method
again
that I proposed, which avoids the as.character and is therefore more
efficient. Leaving aside the discussion about c.factor, or concat, or
whatever, could 'unlist' be changed to use this method instead ? After
all one of the key advantages of factors is to save main memory,
anything
which coerces back to character is going to defeat the benefit.
> c.factor = function(...) {
args <- list(...)
if (!all(sapply(args, is.factor))) stop("all arguments must be factor")
newlevels = unique(unlist(lapply(args,levels)))
ans = unlist(lapply(args, function(x) {
m = match(levels(x), newlevels)
m[as.integer(x)]
}))
levels(ans) = newlevels
class(ans) = "factor"
ans
}
> identical(c(x,y), unlist(list(x,y)))
[1] TRUE
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.0
year 2006
month 10
day 03
svn rev 39566
language R
version.string R version 2.4.0 (2006-10-03)
>
"Brian Ripley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Tue, 14 Nov 2006, Bill Dunlap wrote:
>
>> On Tue, 14 Nov 2006, Prof Brian Ripley wrote:
>>
>>> Well, R has managed without a factor method for c() for most of its
>>> decade
>>> of existence (not that it originally had factors as we know them).
>>>
>>> I would argue that factors are best viewed as an enumeration type,
and
>>> anything which silently changes their level set is a bad idea. I can
>>> see
>>> a case for a c() method for factors that combines factors with the
same
>>> level sets, but I can also see this is best done by users who know
the
>>> level sets are same (c.factor would have to expend a considerable
effort
>>> to check).
>>>
>>> You also need to consider the dispatch rules. c.factor will be
called
>>> whenever the first argument is a factor, whatever the others are. S4
(I
>>> think, definitely S4-based versions of S-PLUS) has an alternative
>>> concat()
>>> that works differently (recursively) and seems a more natural model.
>>
>> In addition, c() has always had a double meaning of
>> (a) turning an object into a simple "vector" (an object
>> without "attributes"), as in
>> > c(factor(c("Cat","Dog","Cat")))
>> [1] 1 2 1
>> > c(data.frame(x=1:2,y=c("Dog","Cat")))
>> $x
>> [1] 1 2
>>
>> $y
>> [1] Dog Cat
>> Levels: Cat Dog
>
> To my surprise that was not documented at all on the R help page, and
I've
> clarified it. (BTW, at least in R it does not remove names, just all
> other attributes.)
>
>> (b) concatenating several such vectors into one.
>>
>> The proposed c.factor does only (b).
>
> (Strictly not, as a factor is not a vector.)
>
> But the help page explicitly only describes the default method, and
some
> of the other methods do preserve some attributes, AFAIR.
>
>> Should we just
>> throw c() into the ash heap and use as.vector() or
>> concat() instead?
>>
>> The whole concept of concatenating objects of disparate
>> types is suspect.
>
> I think working on a concat() for R would be helpful. I vaguely
recalled
> something like it in the Green Book, but the index does not help (but
then
> it is not very complete).
>
> Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How can I call a function R from C
Hi wizards, I have a function in R for example: anyfunction<-function(beta0, popsize, maxgen), but I have a function in C for example: SEXP otherfunction(SEXP beta0, SEXP popsize, SEXP maxgen) I call it function with .Call but I need to call to anyfunction on otherfunction. Does somebody know how to do it? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How can I call a function R from C
Ricardo Rios wrote: > Hi wizards, I have a function in R for example: > anyfunction<-function(beta0, popsize, maxgen), > > but I have a function in C for example: > > SEXP otherfunction(SEXP beta0, SEXP popsize, SEXP maxgen) > > I call it function with .Call but I need to call to anyfunction on > otherfunction. Does somebody know how to do it? Scope out tests/Embedding/RNamedCall.c in the R sources. It's got what you want. Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ralloc clash
Where exactly did you get windows.h from? The recommended source is w32api-3.7.tar.gz, and there is no Ralloc in any of its header files, including objidl.h. BTW, do you know about defining WIN32_LEAN_AND_MEAN when including windows.h? If not, it is worth finding out about. On Wed, 22 Nov 2006, Tom McCallum wrote: > Hi everyone, > > Have been trying to include windows.h (from MinGW) and R.h into a package > and have found that Ralloc is coming up as a clash no matter which include > ordering I use. In windows it has 2 arguments and is defined in objidl.h > and in R.h it is 3 arguments. Any ideas of how to work round this? Have > checked the web and have not seen anyone else comment on this. -- 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
