Re: [Rd] polygon kills X-server (PR#14055)
Ben Bolker wrote: xs4all.nl> writes: Full_Name: Ludo Pagie Version: 2.10.0 OS: linux, ubuntu, 8.04 Submission from: (NULL) (83.163.218.221) when I make a polygon with 100,000 vertices my X-server is being killed. This occurs in R-2.9.0 and a freshly installed R-2.10.0 I'm running Ubuntu with a locally compiled R: [snip] It took quite a while, and every time I obscure the window it hangs R while it redraws, but that all seems as expected. The rest of my system seems to be running fine while it works on that (one core is pegged at 100% CPU, but the other is handling everything OK). Linux bolker-lap2 2.6.27-15-generic #1 SMP Tue Oct 20 06:52:09 UTC 2009 i686 GNU/Linux Ubuntu 8.10 for what it's worth, I'm not running a window manager with any fancy screen effects (don't know if that would matter??) R 2.10.0, stock Ubuntu installation Maybe related to graphics card driver that cannot handle it or even graphics hardware. I will try on some machine with really different graphics hardware as well as on some virtual machine. Uwe __ 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] Help with fPortfolio
Hi I'm getting the following errors while using the efficientPortfolio function even though I'm setting the target return to the mean of the TargetReturn I obtain from the portfolio object created by the feasiblePortfolio function. First Error: Error: targetReturn >= min(mu) is not TRUE Second Error: Error in .rquadprog(Dmat = args$Dmat, dvec = args$dvec, Amat = args$Amat, : NA/NaN/Inf in foreign function call (arg 8) I'm using a timeSeries created from daily stock prices of selected stocks on the Bombay Sensex. My timeSeries is of the following format date stock1 stock2 stock3 I don't understand why I'm getting these errors. I tried the same functions using the SWX.RET and LPPDATA2005.RET time series and I got results. Regards Abhijit Bera [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in docs for unlink()
On 10/11/2009 11:16 PM, Tony Plate wrote: PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on a Linux system. The docs that appear in a Windows installation of R are different (the Windows docs do not mention that not all systems support recursive=TRUE). Here's a plea for docs to be uniform across all systems! Trying to write R code that works on all systems is much harder when the docs are different across systems, and you might only see system specific notes on a different system than the one you're working on. That's a good point, but in favour of the current practice, it is very irritating when searches take you to functions that don't work on your system. One thing that might be possible is to render all versions of the help on all systems, but with some sort of indicator (e.g. a colour change) to indicate things that don't apply on your system, or only apply on your system. I think the hardest part of doing this would be designing the output; actually implementing it would not be so bad. Duncan Murdoch -- Tony Plate Tony Plate wrote: The VALUE section in the help for 'unlink' says: | 0| for success, |1| for failure. Not deleting a non-existent file is not a failure, nor is being unable to delete a directory if |recursive = FALSE|. However, missing values in |x| result are regarded as failures. The last phrase doesn't make sense to me. Should it be either "missing values in x are regarded as failures" or "missing values in x result in failure" ? Also, after reading the docs, I'm still unable to work out if unlink() will return 1 when the user tries to recursively delete a directory on systems that don't support recursive=T. The DETAILS section says "recursive=TRUE is not supported on all platforms, and may be ignored, with a warning", which could be interpreted as implying no special action when recursive=TRUE is not implemented (other than a warning()), and the VALUE section doesn't say what the return value will be under such conditions. I've skimmed the various *_unlink functions in src/main/platform.c, and it looks like they all implement recursive=TRUE, so I'm still in the dark about the required behavior on systems that don't support it. Could this be clarified in the help file? thanks, Tony Plate __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help with fPortfolio
"AB" == Abhijit Bera on Wed, 11 Nov 2009 15:34:50 +0500 Hi Abhijit, Please note that cross-posting is considered to be impolite. AB> I'm getting the following errors while using the AB> efficientPortfolio function AB> even though I'm setting the target return to the mean of the AB> TargetReturn I AB> obtain from the portfolio object created by the AB> feasiblePortfolio function. AB> AB> First Error: AB> Error: targetReturn >= min(mu) is not TRUE As stated by the error message, the target return should be larger or equal to the minimum return of your time series. AB> AB> Second Error: AB> Error in .rquadprog(Dmat = args, dvec = args, Amat = args, : AB> AB> NA/NaN/Inf in foreign function call (arg 8) HTH, Yohan -- PhD candidate Swiss Federal Institute of Technology Zurich www.ethz.ch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in docs for unlink()
On Wed, Nov 11, 2009 at 11:36 AM, Duncan Murdoch wrote:
> On 10/11/2009 11:16 PM, Tony Plate wrote:
>>
>> PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on
>> a Linux system. The docs that appear in a Windows installation of R are
>> different (the Windows docs do not mention that not all systems support
>> recursive=TRUE).
>>
>> Here's a plea for docs to be uniform across all systems! Trying to write
>> R code that works on all systems is much harder when the docs are different
>> across systems, and you might only see system specific notes on a different
>> system than the one you're working on.
>
> That's a good point, but in favour of the current practice, it is very
> irritating when searches take you to functions that don't work on your
> system.
>
> One thing that might be possible is to render all versions of the help on
> all systems, but with some sort of indicator (e.g. a colour change) to
> indicate things that don't apply on your system, or only apply on your
> system. I think the hardest part of doing this would be designing the
> output; actually implementing it would not be so bad.
I 2nd this wishlist - to see the documentation for all (known)
platforms, if possible. A very simple solution is to have an Rd
section on operating-system specific features, e.g.
\section{Differences between operating systems}{...}.
This would decrease the trial and error of producing cross-platform code.
/Henrik
>
> Duncan Murdoch
>
>>
>> -- Tony Plate
>>
>> Tony Plate wrote:
>>>
>>> The VALUE section in the help for 'unlink' says:
>>>
>>> | 0| for success, |1| for failure. Not deleting a non-existent file is
>>> not a failure, nor is being unable to delete a directory if |recursive =
>>> FALSE|. However, missing values in |x| result are regarded as failures.
>>>
>>> The last phrase doesn't make sense to me. Should it be either "missing
>>> values in x are regarded as failures" or "missing values in x result in
>>> failure" ?
>>>
>>> Also, after reading the docs, I'm still unable to work out if unlink()
>>> will return 1 when the user tries to recursively delete a directory on
>>> systems that don't support recursive=T.
>>>
>>> The DETAILS section says "recursive=TRUE is not supported on all
>>> platforms, and may be ignored, with a warning", which could be interpreted
>>> as implying no special action when recursive=TRUE is not implemented (other
>>> than a warning()), and the VALUE section doesn't say what the return value
>>> will be under such conditions.
>>>
>>> I've skimmed the various *_unlink functions in src/main/platform.c, and
>>> it looks like they all implement recursive=TRUE, so I'm still in the dark
>>> about the required behavior on systems that don't support it. Could this be
>>> clarified in the help file?
>>>
>>> thanks,
>>>
>>> Tony Plate
>>>
>>> __
>>> 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
>
> __
> 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] typo in docs for unlink()
Henrik Bengtsson wrote:
On Wed, Nov 11, 2009 at 11:36 AM, Duncan Murdoch wrote:
On 10/11/2009 11:16 PM, Tony Plate wrote:
PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on
a Linux system. The docs that appear in a Windows installation of R are
different (the Windows docs do not mention that not all systems support
recursive=TRUE).
Here's a plea for docs to be uniform across all systems! Trying to write
R code that works on all systems is much harder when the docs are different
across systems, and you might only see system specific notes on a different
system than the one you're working on.
That's a good point, but in favour of the current practice, it is very
irritating when searches take you to functions that don't work on your
system.
One thing that might be possible is to render all versions of the help on
all systems, but with some sort of indicator (e.g. a colour change) to
indicate things that don't apply on your system, or only apply on your
system. I think the hardest part of doing this would be designing the
output; actually implementing it would not be so bad.
I 2nd this wishlist - to see the documentation for all (known)
platforms, if possible.
One way to see this is to read the .Rd files, rather than the rendered
version.
A very simple solution is to have an Rd
section on operating-system specific features, e.g.
\section{Differences between operating systems}{...}.
This would decrease the trial and error of producing cross-platform code.
This is not easy. For example, with unlink should the "recursive=TRUE"
option not be mentioned except in the platform-specific section? I
think that would make the docs a lot harder to read.
Duncan Murdoch
/Henrik
Duncan Murdoch
-- Tony Plate
Tony Plate wrote:
The VALUE section in the help for 'unlink' says:
| 0| for success, |1| for failure. Not deleting a non-existent file is
not a failure, nor is being unable to delete a directory if |recursive =
FALSE|. However, missing values in |x| result are regarded as failures.
The last phrase doesn't make sense to me. Should it be either "missing
values in x are regarded as failures" or "missing values in x result in
failure" ?
Also, after reading the docs, I'm still unable to work out if unlink()
will return 1 when the user tries to recursively delete a directory on
systems that don't support recursive=T.
The DETAILS section says "recursive=TRUE is not supported on all
platforms, and may be ignored, with a warning", which could be interpreted
as implying no special action when recursive=TRUE is not implemented (other
than a warning()), and the VALUE section doesn't say what the return value
will be under such conditions.
I've skimmed the various *_unlink functions in src/main/platform.c, and
it looks like they all implement recursive=TRUE, so I'm still in the dark
about the required behavior on systems that don't support it. Could this be
clarified in the help file?
thanks,
Tony Plate
__
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
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Unexpected behaviour of seq(from,to,by) (PR#14057)
Full_Name: Raimon Massanet Version: 2.9.2 OS: Linux Ubuntu 8.10 Submission from: (NULL) (147.83.71.76) # Hi there. # I'm not sure whether or not this is a bug. # But it surely is an unexpected behaviour. V <- seq(from=0,to=1,by=0.1) # Should generate a sequence with a step of 0.1 V==0 # [1] TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE # Ok! V==0.1 # [1] FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE # Ok! V==0.6 # [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE # None? V[7] # [1] 0.6 V[7]==0.6 # [1] FALSE # Rounding!? V[8] # [1] 0.7 V[8]==0.7 # [1] FALSE # Rounding!? V[9] # [1] 0.8 V[9]==0.8 # [1] TRUE # Back to normal # The generated sequence is fine for all values except for 0.6 # and 0.7, which appear to be somewhat off the expected value. # According to the R manual the sequence is generated in the form: # from, from+by, ..., to # which is not the case. # Either the function or the documentation lead to an unexpected # behaviour of seq(from,to,by). # Thanks! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] polygon kills X-server (PR#14055)
I was thinking along the same line. I have an NVidia, GeForce 6600 GT, 256 MB, NVIDIA Driver Version:169.12. Ludo On Wed, Nov 11, 2009 at 10:01:02AM +0100, Uwe Ligges wrote: > > > Ben Bolker wrote: >> xs4all.nl> writes: >> >>> Full_Name: Ludo Pagie >>> Version: 2.10.0 >>> OS: linux, ubuntu, 8.04 >>> Submission from: (NULL) (83.163.218.221) >>> >>> when I make a polygon with 100,000 vertices my X-server is being >>> killed. This occurs in R-2.9.0 and a freshly installed R-2.10.0 >>> I'm running Ubuntu with a locally compiled R: >> >> >>> [snip] >> >> It took quite a while, and every time I obscure the window >> it hangs R while it redraws, but that all seems as expected. >> The rest of my system seems to be running fine while it works >> on that (one core is pegged at 100% CPU, but the other is >> handling everything OK). >> >> Linux bolker-lap2 2.6.27-15-generic #1 SMP Tue Oct 20 06:52:09 UTC 2009 i686 >> GNU/Linux >> >> Ubuntu 8.10 >> for what it's worth, I'm not running a window manager with any >> fancy screen effects (don't know if that would matter??) >> >> R 2.10.0, stock Ubuntu installation > > Maybe related to graphics card driver that cannot handle it or even > graphics hardware. I will try on some machine with really different > graphics hardware as well as on some virtual machine. > > Uwe > > >> __ >> 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behaviour of seq(from,to,by) (PR#14057)
> # Hi there. > # I'm not sure whether or not this is a bug. No, this is not a bug. See FAQ 7.31 at http://cran.r-project.org/doc/FAQ/R-FAQ.html and the comments below. > # But it surely is an unexpected behaviour. > > V <- seq(from=0,to=1,by=0.1) > > # Should generate a sequence with a step of 0.1 > > V==0 > # [1] TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE > # Ok! > > V==0.1 > # [1] FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE > # Ok! > > V==0.6 > # [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE > # None? > > V[7] > # [1] 0.6 > V[7]==0.6 > # [1] FALSE > # Rounding!? Yes. The sequence of operations, which leads to V[7], produce slightly different rounding error than the direct conversion of 0.6 to binary representation. So, we have formatC(V[7], digits=20) # [1] "0.60008882" formatC(0.6, digits=20) # [1] "0.5999778" See http://wiki.r-project.org/rwiki/doku.php?id=misc:r_accuracy for more examples and explanations. Petr Savicky. > V[8] > # [1] 0.7 > V[8]==0.7 > # [1] FALSE > # Rounding!? > > V[9] > # [1] 0.8 > V[9]==0.8 > # [1] TRUE > # Back to normal > > # The generated sequence is fine for all values except for 0.6 > # and 0.7, which appear to be somewhat off the expected value. > > # According to the R manual the sequence is generated in the form: > # from, from+by, ..., to > # which is not the case. > > # Either the function or the documentation lead to an unexpected > # behaviour of seq(from,to,by). > > # Thanks! > > __ > 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] typo in docs for unlink()
On Wed, Nov 11, 2009 at 12:55 PM, Duncan Murdoch wrote:
> Henrik Bengtsson wrote:
>>
>> On Wed, Nov 11, 2009 at 11:36 AM, Duncan Murdoch
>> wrote:
>>
>>>
>>> On 10/11/2009 11:16 PM, Tony Plate wrote:
>>>
PS, I should have said that I'm reading the docs for unlink in R-2.10.0
on
a Linux system. The docs that appear in a Windows installation of R are
different (the Windows docs do not mention that not all systems support
recursive=TRUE).
Here's a plea for docs to be uniform across all systems! Trying to
write
R code that works on all systems is much harder when the docs are
different
across systems, and you might only see system specific notes on a
different
system than the one you're working on.
>>>
>>> That's a good point, but in favour of the current practice, it is very
>>> irritating when searches take you to functions that don't work on your
>>> system.
>>>
>>> One thing that might be possible is to render all versions of the help on
>>> all systems, but with some sort of indicator (e.g. a colour change) to
>>> indicate things that don't apply on your system, or only apply on your
>>> system. I think the hardest part of doing this would be designing the
>>> output; actually implementing it would not be so bad.
>>>
>>
>> I 2nd this wishlist - to see the documentation for all (known)
>> platforms, if possible.
>
> One way to see this is to read the .Rd files, rather than the rendered
> version.
>>
>> A very simple solution is to have an Rd
>> section on operating-system specific features, e.g.
>> \section{Differences between operating systems}{...}.
>>
>> This would decrease the trial and error of producing cross-platform code.
>>
>>
>
> This is not easy. For example, with unlink should the "recursive=TRUE"
> option not be mentioned except in the platform-specific section? I think
> that would make the docs a lot harder to read.
I'd say the union across all OSes should be mentioned under the
\arguments{}. Then one can add to \item{} making it clear that this
is specific to a particular OS, e.g. \item{recursive}{(Unix only)
...}. That is in line with how some arguments are flagged
"(optional)" in \item{}.
At a minimum it is useful to have a note that makes the
reader/users/developer aware that the function differ between
platforms. (With the new help system, this can be automated if such
functions have been flagged with an attribute, e.g. attr(fcn,
"differAcrossOSes") <- TRUE)
Just thoughts.
/Henrik
>
> Duncan Murdoch
>
>> /Henrik
>>
>>
>>>
>>> Duncan Murdoch
>>>
>>>
-- Tony Plate
Tony Plate wrote:
>
> The VALUE section in the help for 'unlink' says:
>
> | 0| for success, |1| for failure. Not deleting a non-existent file is
> not a failure, nor is being unable to delete a directory if |recursive
> =
> FALSE|. However, missing values in |x| result are regarded as failures.
>
> The last phrase doesn't make sense to me. Should it be either "missing
> values in x are regarded as failures" or "missing values in x result in
> failure" ?
>
> Also, after reading the docs, I'm still unable to work out if unlink()
> will return 1 when the user tries to recursively delete a directory on
> systems that don't support recursive=T.
>
> The DETAILS section says "recursive=TRUE is not supported on all
> platforms, and may be ignored, with a warning", which could be
> interpreted
> as implying no special action when recursive=TRUE is not implemented
> (other
> than a warning()), and the VALUE section doesn't say what the return
> value
> will be under such conditions.
>
> I've skimmed the various *_unlink functions in src/main/platform.c, and
> it looks like they all implement recursive=TRUE, so I'm still in the
> dark
> about the required behavior on systems that don't support it. Could
> this be
> clarified in the help file?
>
> thanks,
>
> Tony Plate
>
> __
> 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
>>>
>>> __
>>> 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
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Clarification on generic functions and methods
I have constructed the following functions and need a little clarification:
### function to fit the model parameters
jml.fit <- function(dat, con = 1e-3, bias=FALSE, ...){
do stuff ...
}
### default function which calls jml.fit
jml.default <- function(dat, con = 1e-3, bias=FALSE, ...){
result <- jml.fit(dat, con = 1e-3, bias)
result$call <- match.call()
class(result) <- "jml"
result
}
### Function to make use of formula
jml.formula <- function(formula, data, na.action, subset, ...){
mf <- match.call(expand.dots = FALSE)
m <- match(c("formula", "data", "na.action", "subset"), names(mf), 0L)
mf <- mf[c(1L, m)]
mf$drop.unused.levels <- TRUE
mf[[1L]] <- as.name("model.frame")
mf <- eval(mf, parent.frame())
mt <- attr(mf, "terms")
dat <- mf
result <- jml.default(dat, ...)
result$call <- match.call()
result$formula <- formula
result
}
### and the generic function
jml <- function(dat, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
Writing R Extensions states, "If the generic specifies defaults, all methods
should use the same defaults."
In my example above, the generic function has 2 defaults: one for argument con
and another bias. I'm a little confused on exactly how the generic function
should be structured for proper package development.
I think the options are:
1) jml <- function(dat, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
2) jml <- function(x, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
3) jml <- function(formula, data, na.action, subset, con = 1e-3, bias = FALSE,
...) UseMethod("jml")
I'm inclined to believe #3 is correct because the .Rd page needs to reflect the
args in this function, is that right? Then, this generic function would include
the formula, data, na.action, and subset and it includes the proper defaults as
the other functions.
Thank you
Harold
> sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] scoreFoo_1.1 MiscPsycho_1.4 statmod_1.4.1
loaded via a namespace (and not attached):
[1] tools_2.10.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.10.0 Mac OS X 10.6 (PR#14058)
Stephen, I cannot reproduce it (using Leopard build). Please supply full information (including sessionInfo() and version of the GUI used) as required by the posing guide. Thanks, Simon On Nov 11, 2009, at 7:50 , step...@prollenium.com wrote: > > --Apple-Mail-56-463481941 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii; > format=flowed; > delsp=yes > > If you search for help on a phrase and double click on one of the > items matching list an error is generated and R is hung. This is very > repeatable. Using a MacBook Pro with 10.6.1 . > > Here is a screen capture of the console window. > > Best, > > Steve Kennedy > > > --Apple-Mail-56-463481941 > Content-Disposition: inline; > filename="R Error.tiff" > Content-Type: image/tiff; > x-mac-hide-extension=yes; > x-unix-mode=0644; > name="R Error.tiff" > Content-Transfer-Encoding: base64 > > TU0AKgACY0CAACBAAXQUYFOEFYnQspCWHCeBxGJROKRWLReMRmNRuOR2PR > +QSGRSOSSWTSeUSmVS > uWS2XS+YTGZTOaTWbTecTmdTueT2fT+gUGhUOiUWjUekUmlUumU2nU > +oSZtVNsLWrLFWVlUtGuM8 > X18YoexI4c2UgP60VG1Wu2W23W+4XG5XO6XW7Xe8Xm9Xu+X2/X/ > AYHBYPCSgBYcAMjFME8Y04oDI > IY3ZM8v/LYXMZnNZvOZ3PZ/ > QaHRaPSaXTafUanVavAAHXABJ7FEMzaNkQ7cTazdbveb3fb/gcHhc > PicXjcfkcnlU5v81tO3oP+U5bpWh/AB99kAPTuABw98APHxAACeWJPz0AAH+sAB/ > 3AAGfEAAX6AD > DgIAa4AybqADrOw7TxHiABrwKAB2HYdYAH6frroiAcIAACkJgAFMLPU9j6AK+zEP0/jLv > +7J9vC8 > ZsRMAB1xS/x/H6AD+tc/ALxkAAURrDAHvm > +r7vy17lx9H8gSDIUhyJIsjSPJEkyUwjoHa6SUQZFp __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clarification on generic functions and methods
Using
jml <- function(...) UseMethod("jml")
will do.
/Henrik
On Wed, Nov 11, 2009 at 4:26 PM, Doran, Harold wrote:
> I have constructed the following functions and need a little clarification:
>
> ### function to fit the model parameters
> jml.fit <- function(dat, con = 1e-3, bias=FALSE, ...){
> do stuff ...
> }
>
> ### default function which calls jml.fit
> jml.default <- function(dat, con = 1e-3, bias=FALSE, ...){
> result <- jml.fit(dat, con = 1e-3, bias)
> result$call <- match.call()
> class(result) <- "jml"
> result
> }
>
> ### Function to make use of formula
> jml.formula <- function(formula, data, na.action, subset, ...){
> mf <- match.call(expand.dots = FALSE)
> m <- match(c("formula", "data", "na.action", "subset"), names(mf), 0L)
> mf <- mf[c(1L, m)]
> mf$drop.unused.levels <- TRUE
> mf[[1L]] <- as.name("model.frame")
> mf <- eval(mf, parent.frame())
> mt <- attr(mf, "terms")
> dat <- mf
> result <- jml.default(dat, ...)
> result$call <- match.call()
> result$formula <- formula
> result
> }
>
> ### and the generic function
> jml <- function(dat, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
>
> Writing R Extensions states, "If the generic specifies defaults, all methods
> should use the same defaults."
>
> In my example above, the generic function has 2 defaults: one for argument
> con and another bias. I'm a little confused on exactly how the generic
> function should be structured for proper package development.
>
> I think the options are:
>
> 1) jml <- function(dat, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
> 2) jml <- function(x, con = 1e-3, bias=FALSE, ...) UseMethod("jml")
> 3) jml <- function(formula, data, na.action, subset, con = 1e-3, bias =
> FALSE, ...) UseMethod("jml")
>
> I'm inclined to believe #3 is correct because the .Rd page needs to reflect
> the args in this function, is that right? Then, this generic function would
> include the formula, data, na.action, and subset and it includes the proper
> defaults as the other functions.
>
> Thank you
> Harold
>
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] scoreFoo_1.1 MiscPsycho_1.4 statmod_1.4.1
>
> loaded via a namespace (and not attached):
> [1] tools_2.10.0
> __
> 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] Help in 2.10 lost its "Find" feature
Sirs: I understand that no one wanted to maintain the old Help, but one feature I used extensively -- as a newbie to R or to an unfamiliar package -- was the capability of searching for a word or phrase on the Help page itself. Ctrl-F/Command-F (Windows/mac) 'differently-phrased-capability' was a fast way to find out how to specify the arguments for a function call to accommodate a "capability" phrased differently than could be found in the author's designed argument list, especially for long and informative Help's. If new-Help could easily be enhanced to resurrect that feature, I believe many users would appreciate it. Thanks. Dan Murphy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help in 2.10 lost its "Find" feature
> I understand that no one wanted to maintain the old Help, but one feature I > used extensively -- as a newbie to R or to an unfamiliar package -- was the > capability of searching for a word or phrase on the Help page itself. > Ctrl-F/Command-F (Windows/mac) 'differently-phrased-capability' was a fast > way to find out how to specify the arguments for a function call to > accommodate a "capability" phrased differently than could be found in the > author's designed argument list, especially for long and informative Help's. > If new-Help could easily be enhanced to resurrect that feature, I believe > many users would appreciate it. Thanks. Most browsers offer this feature - it certainly works in safari and firefox, and I'm sure in internet explorer too. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help in 2.10 lost its "Find" feature
For the text based help, there is no search feature on Windows, e.g. options(help_type="text"); help(readLines); but if you use the HTML-based help, you can use the browser's search features as suggested/wanted: options(help_type="html"); help(readLines); /Henrik On Wed, Nov 11, 2009 at 5:40 PM, hadley wickham wrote: >> I understand that no one wanted to maintain the old Help, but one feature I >> used extensively -- as a newbie to R or to an unfamiliar package -- was the >> capability of searching for a word or phrase on the Help page itself. >> Ctrl-F/Command-F (Windows/mac) 'differently-phrased-capability' was a fast >> way to find out how to specify the arguments for a function call to >> accommodate a "capability" phrased differently than could be found in the >> author's designed argument list, especially for long and informative Help's. >> If new-Help could easily be enhanced to resurrect that feature, I believe >> many users would appreciate it. Thanks. > > Most browsers offer this feature - it certainly works in safari and > firefox, and I'm sure in internet explorer too. > > Hadley > > -- > http://had.co.nz/ > > __ > 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] Help in 2.10 lost its "Find" feature
On 11/11/2009 11:40 AM, hadley wickham wrote: I understand that no one wanted to maintain the old Help, but one feature I used extensively -- as a newbie to R or to an unfamiliar package -- was the capability of searching for a word or phrase on the Help page itself. Ctrl-F/Command-F (Windows/mac) 'differently-phrased-capability' was a fast way to find out how to specify the arguments for a function call to accommodate a "capability" phrased differently than could be found in the author's designed argument list, especially for long and informative Help's. If new-Help could easily be enhanced to resurrect that feature, I believe many users would appreciate it. Thanks. Most browsers offer this feature - it certainly works in safari and firefox, and I'm sure in internet explorer too. I think Daniel was talking about the full text search of all pages. This index for this was built by the Microsoft Help Compiler so it was available in CHM help; the Mac has the full text search available in lots of places, so it worked there just because the system automatically indexed the static HTML pages. I think it would be nice to get this back and make it less platform specific. It would need indexing of the content of the pages, and Javascript or similar to access the indices. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help in 2.10 lost its "Find" feature
That did it. Was having trouble searching 'help' for how to optionally configure 'help'. Thanks. -Dan On Wed, Nov 11, 2009 at 8:57 AM, Henrik Bengtsson wrote: > For the text based help, there is no search feature on Windows, e.g. > > options(help_type="text"); > help(readLines); > > but if you use the HTML-based help, you can use the browser's search > features as suggested/wanted: > > options(help_type="html"); > help(readLines); > > /Henrik > > > On Wed, Nov 11, 2009 at 5:40 PM, hadley wickham > wrote: > >> I understand that no one wanted to maintain the old Help, but one > feature I > >> used extensively -- as a newbie to R or to an unfamiliar package -- was > the > >> capability of searching for a word or phrase on the Help page itself. > >> Ctrl-F/Command-F (Windows/mac) 'differently-phrased-capability' was a > fast > >> way to find out how to specify the arguments for a function call to > >> accommodate a "capability" phrased differently than could be found in > the > >> author's designed argument list, especially for long and informative > Help's. > >> If new-Help could easily be enhanced to resurrect that feature, I > believe > >> many users would appreciate it. Thanks. > > > > Most browsers offer this feature - it certainly works in safari and > > firefox, and I'm sure in internet explorer too. > > > > Hadley > > > > -- > > http://had.co.nz/ > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clarification on generic functions and methods
Thank you, Henrik. This actually doesn't work when I build the package, which
may only require a slight modification to what I'm doing now. First, I create a
NAMESPACE as:
### NAMESPACE FILE CONTENTS
export(jml2)
S3method(jml2, fit)
S3method(jml2, default)
S3method(jml2, formula)
S3method(print, jml)
S3method(summary, jml)
S3method(print, summary.jml)
So, only the generic function (jml) is exported.
Now, I do as you suggest below for the generic function, but keep all others as
they were previously. That creates a situation where jml.formula, jml.default,
and jml have different arguments.
Now, in the .Rd file for the jml function I want the user to see the usage for
the jml.formula method, which obviously has more args than "...". So, the .Rd
file is structured as (for testing purposes only):
\name{jml2}
\alias{jml2}
\title{JML Estimation}
\description{JML Stuff}
\usage{
jml2(formula, data, na.action, subset, con = 1e-3, bias = FALSE, ...)
}
\arguments{
\item{formula}{Describe later}
\item{data}{Describe later}
\item{na.action}{Describe later}
\item{subset}{Describe later}
\item{con}{Describe later}
\item{bias}{Describe later}
\item{\dots}{Not implemented}
}
\author{Me}
\examples{
\dontrun{jml(~V1 + V2, data)}
}
\keyword{misc}
But, because the args in the generic functions differ from what I have placed
in the .Rd file, the check phase yields the following error, which indicates
the .Rd file and code are different.
C:\Program Files\R\R-2.10.0\bin>Rcmd check g:\jmlFoo
* checking for working pdflatex ...pdflatex: not found
NO
* checking for working latex ...latex: not found
NO
* using log directory 'C:/Program Files/R/R-2.10.0/bin/jmlFoo.Rcheck'
* using R version 2.10.0 (2009-10-26)
* using session charset: ISO8859-1
* checking for file 'jmlFoo/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'jmlFoo' version '1.0'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for executable files ... OK
* checking whether package 'jmlFoo' can be installed ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the name space can be loaded with stated dependencies ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
jml2.fit: no visible binding for global variable 'theta.max'
jml2.fit: no visible global function definition for 'fit.Stats'
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'jml2':
jml2
Code: function(...)
Docs: function(formula, data, na.action, subset, con = 0.001, bias =
FALSE, ...)
Argument names in docs not in code:
formula data na.action subset con bias
Mismatches in argument names:
Position: 1 Code: ... Docs: formula
* checking Rd \usage sections ... OK
* checking examples ... OK
WARNING: There was 1 warning, see
C:/Program Files/R/R-2.10.0/bin/jmlFoo.Rcheck/00check.log
for details
So, what I'm trying to accomplish is to export the jml generic function and
make this the only one visible to the user. All others are in the NAMESPACE as
S3 methods. But this obviously creates a conflict between what I want in the
.Rd file and what args are in the code for the generic jml function.
Can anyone help me understand how this might be resolved?
Harold
> -Original Message-
> From: henrik.bengts...@gmail.com
> [mailto:henrik.bengts...@gmail.com] On Behalf Of Henrik Bengtsson
> Sent: Wednesday, November 11, 2009 10:44 AM
> To: Doran, Harold
> Cc: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Clarification on generic functions and methods
>
> Using
>
> jml <- function(...) UseMethod("jml")
>
> will do.
>
> /Henrik
>
>
> On Wed, Nov 11, 2009 at 4:26 PM, Doran, Harold wrote:
> > I have constructed the following functions and need a
> little clarification:
> >
> > ### function to fit the model parameters jml.fit <-
> function(dat, con
> > = 1e-3, bias=FALSE, ...){
> > do stuff ...
> > }
> >
> > ### default function which calls jml.fit jml.default <-
> function(dat,
> > con = 1e-3, bias=FALSE, ...){
> > result <- jml.fit(dat, con = 1e-3, bias)
> > result$call <- match.call()
> >
Re: [Rd] Help in 2.10 lost its "Find" feature
> I think it would be nice to get this back and make it less platform > specific. It would need indexing of the content of the pages, and > Javascript or similar to access the indices. It would be nice to have an interface to something like lucene - would be useful for other projects apart from R help. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in the stats package (PR#14059)
This is a multi-part message in MIME format. --020309030400080109090707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello dear Maintainer, I report a bug (or at least a weak point needing documentation) located in the nls.c file of the stats package. ($BASE/src/library/stats/src/nls.c, svn version 50393) They lie in the line 120 and 129, where the msgbuf char array is set to the size limit of 70. Intriguingly in case of long formulaes overriding this limit, the R session will crash complaining buffer overflow detected (see the attachment session_crash_report). After changing the array size to 255 (see the patch.nls file), the error is avoided. I suggest either documentating the size limit of the formulae, or to enlarge the array. Best wishes, Jitao David Zhang Attached: R.version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Under development (unstable) major 2 minor 11.0 year 2009 month 11 day06 svn rev50320 language R version.string R version 2.11.0 Under development (unstable) (2009-11-06 r50320) - -- THINK BEFORE YOU PRINT: DO OUR ENVIRONMENT GOOD Jitao David Zhang Computational Biology/Bioinformatics Ph.D. Candidate Division of Molecular Genome Analysis, DKFZ Im Neuenheimer Feld 580, Heidelberg D-69120 Germany Tel: 49-(0)6221-424711 Calendar: http://www.google.com/calendar/embed?src=38m77vcknecr59sbpdj0vofndo%40group.calendar.google.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr64ekACgkQb+FFFSdYGiDF8ACeJJ65MQwpnd1cmjaN8aXkF7u2 ckYAn1sehdgXrxLl9gpeiNRpPlaykB2S =VRCh -END PGP SIGNATURE- --020309030400080109090707 Content-Type: text/plain; name="session_crash_report" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="session_crash_report" KioqIGJ1ZmZlciBvdmVyZmxvdyBkZXRlY3RlZCAqKio6IC9ob21lL3poYW5nL0xpdmluZ09u RWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUiB0ZXJtaW5hdGVkCj09PT09PT0gQmFja3RyYWNl OiA9PT09PT09PT0KL2xpYi90bHMvaTY4Ni9jbW92L2xpYmMuc28uNihfX2ZvcnRpZnlfZmFp bCsweDQ4KVsweGI3MmU0ZGU4XQovbGliL3Rscy9pNjg2L2Ntb3YvbGliYy5zby42WzB4Yjcy ZTNlMjBdCi9saWIvdGxzL2k2ODYvY21vdi9saWJjLnNvLjZbMHhiNzJlMzU1OF0KL2xpYi90 bHMvaTY4Ni9jbW92L2xpYmMuc28uNihfSU9fZGVmYXVsdF94c3B1dG4rMHg5ZSlbMHhiNzI2 ZDU5ZV0KL2xpYi90bHMvaTY4Ni9jbW92L2xpYmMuc28uNihfSU9fdmZwcmludGYrMHg2MGEp WzB4YjcyNDExNGFdCi9saWIvdGxzL2k2ODYvY21vdi9saWJjLnNvLjYoX192c3ByaW50Zl9j aGsrMHhhZClbMHhiNzJlMzYwZF0KL2xpYi90bHMvaTY4Ni9jbW92L2xpYmMuc28uNihfX3Nw cmludGZfY2hrKzB4MmQpWzB4YjcyZTM1NGRdCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9S L3ItZGV2ZWwvbGlicmFyeS9zdGF0cy9saWJzL3N0YXRzLnNvWzB4YjViMGYwYjBdCi9ob21l L3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUlsweDgxNzFiMWRdCi9o b21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUihSZl9ldmFsKzB4 NzJkKVsweDgxOTI2ZWRdCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwvYmlu L2V4ZWMvUlsweDgxOTQ4OWFdCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwv YmluL2V4ZWMvUihSZl9ldmFsKzB4NGVmKVsweDgxOTI0YWZdCi9ob21lL3poYW5nL0xpdmlu Z09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUlsweDgxOTQ5NjddCi9ob21lL3poYW5nL0xp dmluZ09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUihSZl9ldmFsKzB4NGVmKVsweDgxOTI0 YWZdCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUihSZl9l dmFsKzB4NGVmKVsweDgxOTI0YWZdCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3ItZGV2 ZWwvYmluL2V4ZWMvUlsweDgxOTQ5NjddCi9ob21lL3poYW5nL0xpdmluZ09uRWRnZS9SL3It ZGV2ZWwvYmluL2V4ZWMvUihSZl9ldmFsKzB4NGVmKVsweDgxOTI0YWZdCi9ob21lL3poYW5n L0xpdmluZ09uRWRnZS9SL3ItZGV2ZWwvYmluL2V4ZWMvUihSZl9hcHBseUNsb3N1cmUrMHgy OGYpWzB4ODE5NjBmZl0KL2hvbWUvemhhbmcvTGl2aW5nT25FZGdlL1Ivci1kZXZlbC9iaW4v ZXhlYy9SKFJmX2V2YWwrMHgzYmEpWzB4ODE5MjM3YV0KL2hvbWUvemhhbmcvTGl2aW5nT25F ZGdlL1Ivci1kZXZlbC9iaW4vZXhlYy9SWzB4ODE5NDg5YV0KL2hvbWUvemhhbmcvTGl2aW5n T25FZGdlL1Ivci1kZXZlbC9iaW4vZXhlYy9SKFJmX2V2YWwrMHg0ZWYpWzB4ODE5MjRhZl0K L2hvbWUvemhhbmcvTGl2aW5nT25FZGdlL1Ivci1kZXZlbC9iaW4vZXhlYy9SKFJmX1JlcGxJ dGVyYXRpb24rMHgyMGEpWzB4ODA1ZTExYV0KL2hvbWUvemhhbmcvTGl2aW5nT25FZGdlL1Iv ci1kZXZlbC9iaW4vZXhlYy9SWzB4ODA1ZTNjMl0KL2hvbWUvemhhbmcvTGl2aW5nT25FZGdl L1Ivci1kZXZlbC9iaW4vZXhlYy9SKHJ1bl9SbWFpbmxvb3ArMHg0OClbMHg4MDVlY2U4XQov aG9tZS96aGFuZy9MaXZpbmdPbkVkZ2UvUi9yLWRldmVsL2Jpbi9leGVjL1IobWFpbisweDJh KVsweDgwNWJmNGFdCi9saWIvdGxzL2k2ODYvY21vdi9saWJjLnNvLjYoX19saWJjX3N0YXJ0 X21haW4rMHhlNilbMHhiNzIxYWI1Nl0KL2hvbWUvemhhbmcvTGl2aW5nT25FZGdlL1Ivci1k ZXZlbC9iaW4vZXhlYy9SWzB4ODA1YmU1MV0KPT09PT09PSBNZW1vcnkgbWFwOiA9PT09PT09 PQowODA0ODAwMC0wODJhNDAwMCByLXhwIDAwMDAwMDAwIDA4OjAzIDU0MjMxNDQgICAgL2hv bWUvemhhbmcvTGl2aW5nT25FZGdlL1Ivci1kZXZlbC9iaW4vZXhlYy9SCjA4MmE0MDAwLTA4 MmE1MDAwIHItLXAgMDAyNWIwMDAgMDg6MDMgNTQyMzE0NCAgICAvaG9tZS96aGFuZy9MaXZp bmdPbkVkZ2UvUi9yLWRldmVsL2Jpbi9leGVjL1IKMDgyYTUwMDAtMDgyYjAwMDAgcnctcCAw MDI1YzAwMCAwODowMyA1NDIzMTQ0ICAgIC9ob21lL3poYW5nL0xpdmlu
Re: [Rd] Clarification on generic functions and methods
Doran, Harold air.org> writes: > > Thank you, Henrik. This actually doesn't work when I build the package, which may only require a slight > modification to what I'm doing now. First, I create a NAMESPACE as: > > ### NAMESPACE FILE CONTENTS > export(jml2) > S3method(jml2, fit) > S3method(jml2, default) > S3method(jml2, formula) > S3method(print, jml) > S3method(summary, jml) > S3method(print, summary.jml) > > So, only the generic function (jml) is exported. > > Now, I do as you suggest below for the generic function, but keep all others as they were previously. That > creates a situation where jml.formula, jml.default, and jml have different arguments. > > Now, in the .Rd file for the jml function I want the user to see the usage > for the jml.formula method, which > obviously has more args than "...". So, the .Rd file is structured as (for testing purposes only): How about if you document the default method as well as the generic method in your man page. See ?lag for an example, and I've come across several others recently. HTH, Ken -- Ken Knoblauch Inserm U846 Stem-cell and Brain Research Institute Department of Integrative Neurosciences 18 avenue du Doyen Lépine 69500 Bron France tel: +33 (0)4 72 91 34 77 fax: +33 (0)4 72 91 34 61 portable: +33 (0)6 84 10 64 10 http://www.sbri.fr/members/kenneth-knoblauch.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clarification on generic functions and methods
Hi Ken:
Well, I'm quite pleased with a solution I found. The t.test method and its .Rd
file showed me that I can export only the generic method, use
\alias{jml2.default} and \alias{jml2.formula} in the .Rd file for jml2, and
then use \method{jml2}{default}{args} and \method{jml2}{formula}{args}.
Using this, I was able to build the package in both windows and Ubuntu without
error.
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Ken Knoblauch
> Sent: Wednesday, November 11, 2009 3:58 PM
> To: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Clarification on generic functions and methods
>
> Doran, Harold air.org> writes:
> >
> > Thank you, Henrik. This actually doesn't work when I build the
> > package,
> which may only require a slight
> > modification to what I'm doing now. First, I create a NAMESPACE as:
> >
> > ### NAMESPACE FILE CONTENTS
> > export(jml2)
> > S3method(jml2, fit)
> > S3method(jml2, default)
> > S3method(jml2, formula)
> > S3method(print, jml)
> > S3method(summary, jml)
> > S3method(print, summary.jml)
> >
> > So, only the generic function (jml) is exported.
> >
> > Now, I do as you suggest below for the generic function,
> but keep all
> > others
> as they were previously. That
> > creates a situation where jml.formula, jml.default, and jml have
> > different
> arguments.
> >
> > Now, in the .Rd file for the jml function I want the user
> to see the
> > usage for
> the jml.formula method, which
> > obviously has more args than "...". So, the .Rd file is
> structured as
> (for testing purposes only):
>
> How about if you document the default method as well as the
> generic method in your man page. See ?lag for an example,
> and I've come across several others recently.
>
> HTH,
>
> Ken
>
> --
> Ken Knoblauch
> Inserm U846
> Stem-cell and Brain Research Institute
> Department of Integrative Neurosciences
> 18 avenue du Doyen Lépine
> 69500 Bron
> France
> tel: +33 (0)4 72 91 34 77
> fax: +33 (0)4 72 91 34 61
> portable: +33 (0)6 84 10 64 10
> http://www.sbri.fr/members/kenneth-knoblauch.html
>
> __
> 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] Building package under windows which links against a cygwin library
I am developing a package (http://r-forge.r-project.org/projects/swfdevice/) which links against the ming C library. The package builds fine under Mac OS X and Linux. I am really out of my element on windows, but I know there is a cygwin package for libming. My question is, does anyone have advice/examples on linking R packages against cygwin libraries? Is this even possible? How would I go about writing a configure.win script to do this? Cheers, -Cameron __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fwd: fameInit TSfame fame.dll
>
> Dear all,
>
> i used Paul Gilbert´s great TSfame to make R interact with fame. I had to
> dyn.load("chli.dll") and dyn.load("fame.dll") manually but everything has
> worked well so far. Unfortunately my system has been deleted and reinstalled,
> but i still have a working fame client and R left, but i always get an error
> trying to use TSconnect, saying it that fameInit could not be initialized.
> I still find chli.dll on my machine but the only fame.dll that I can find is
> the dummy fame.dll that is stored in R2-10/lib . When i look at this .dll, i
> see it has only 5 KB and contains two functions...
>
> Is fame supposed to provide this .dll ? My fame client still works, but i
> cant use it with R anymore. Or is this fame.dll being generating during
> installation ?
>
> thx for any help in advance
>
> matt
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building package under windows which links against a cygwin library
On 11/11/2009 4:41 PM, Cameron Bracken wrote: I am developing a package (http://r-forge.r-project.org/projects/swfdevice/) which links against the ming C library. The package builds fine under Mac OS X and Linux. I am really out of my element on windows, but I know there is a cygwin package for libming. My question is, does anyone have advice/examples on linking R packages against cygwin libraries? Is this even possible? How would I go about writing a configure.win script to do this? I suspect it's not going to work. Linking to any Cygwin library will pull in the rest, and I would guess that will conflict with something else in R, which does not use Cygwin. What you could do is include a copy of the source to the ming library, and get the regular R compilers to compile it. I just tried, and it compiled without errors (though there were a few warnings). Then you can write your R interface to it, and everything may just work. The tricky bit might be getting the Makevars or Makefile right, but theirs is really simple, so that shouldn't be so bad. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building package under windows which links against a cygwin library
On 11/11/2009 6:49 PM, Cameron Bracken wrote: On Wed, Nov 11, 2009 at 4:36 PM, Duncan Murdoch wrote: On 11/11/2009 4:41 PM, Cameron Bracken wrote: I am developing a package (http://r-forge.r-project.org/projects/swfdevice/) which links against the ming C library. The package builds fine under Mac OS X and Linux. I am really out of my element on windows, but I know there is a cygwin package for libming. My question is, does anyone have advice/examples on linking R packages against cygwin libraries? Is this even possible? How would I go about writing a configure.win script to do this? I suspect it's not going to work. Linking to any Cygwin library will pull in the rest, and I would guess that will conflict with something else in R, which does not use Cygwin. I figured that would be the case. What you could do is include a copy of the source to the ming library, and get the regular R compilers to compile it. I just tried, and it compiled without errors (though there were a few warnings). Then you can write your R interface to it, and everything may just work. Hey, that is great! I thought about doing this but decided arbitrarily that it would be too hard. Do I just plop a copy of the ming source in the src/ directory of my package (then adjust Makevars accordingly)? Did you run the whole ming configure script as well? I just ran make. I don't think there is any configure script. I'd probably put their stuff in a subdir of src, just to keep it cleanly separated from yours. This also gives you the option of *not* compiling it on systems like Linux and MacOS that already have it. Then make up a Makevars.win file that builds it as a static or dynamic lib on Windows and links to it, and a Makevars file that just links to it on other platforms. (You might want to do a static compile on the other systems just so you're protected against version changes.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building package under windows which links against a cygwin library
On Wed, Nov 11, 2009 at 4:36 PM, Duncan Murdoch wrote: > > On 11/11/2009 4:41 PM, Cameron Bracken wrote: >> >> I am developing a package >> (http://r-forge.r-project.org/projects/swfdevice/) which links against >> the ming C library. The package builds fine under Mac OS X and Linux. >> I am really out of my element on windows, but I know there is a cygwin >> package for libming. >> >> My question is, does anyone have advice/examples on linking R packages >> against cygwin libraries? Is this even possible? How would I go >> about writing a configure.win script to do this? > > I suspect it's not going to work. Linking to any Cygwin library will pull in > the rest, and I would guess that will conflict with something else in R, > which does not use Cygwin. > I figured that would be the case. > > What you could do is include a copy of the source to the ming library, and > get the regular R compilers to compile it. I just tried, and it compiled > without errors (though there were a few warnings). Then you can write your R > interface to it, and everything may just work. Hey, that is great! I thought about doing this but decided arbitrarily that it would be too hard. Do I just plop a copy of the ming source in the src/ directory of my package (then adjust Makevars accordingly)? Did you run the whole ming configure script as well? -Cameron __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] html help in Windows
Hi all, Another comment re: html help in Windows. It seems that we've lost the functionality of being able to browse the other functions in a package. In chm, after calling a help function on 'arrayw' in say package 'limma' in BioC, it was possible to see all of the other functions in the limma package. Now it seems we just get a flat html page with no links to the overall package and no side browsing. Can this be added to html help? Cheers, Fraser [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] html help in Windows
This has already been discussed on this list. Its now a link at the bottom of the page labeled Index. On Wed, Nov 11, 2009 at 7:54 PM, Fraser Sim wrote: > Hi all, > > > > Another comment re: html help in Windows. It seems that we've lost the > functionality of being able to browse the other functions in a package. In > chm, after calling a help function on 'arrayw' in say package 'limma' in > BioC, it was possible to see all of the other functions in the limma > package. Now it seems we just get a flat html page with no links to the > overall package and no side browsing. Can this be added to html help? > > > > Cheers, > > Fraser > > > > > [[alternative HTML version deleted]] > > __ > 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] Building package under windows which links against a cygwin library
On Wed, Nov 11, 2009 at 5:15 PM, Duncan Murdoch wrote: > On 11/11/2009 6:49 PM, Cameron Bracken wrote: >> >> On Wed, Nov 11, 2009 at 4:36 PM, Duncan Murdoch >> wrote: >>> >>> On 11/11/2009 4:41 PM, Cameron Bracken wrote: I am developing a package (http://r-forge.r-project.org/projects/swfdevice/) which links against the ming C library. The package builds fine under Mac OS X and Linux. I am really out of my element on windows, but I know there is a cygwin package for libming. My question is, does anyone have advice/examples on linking R packages against cygwin libraries? Is this even possible? How would I go about writing a configure.win script to do this? >>> >>> I suspect it's not going to work. Linking to any Cygwin library will >>> pull in the rest, and I would guess that will conflict with something else >>> in R, which does not use Cygwin. >>> >> >> I figured that would be the case. >> >>> What you could do is include a copy of the source to the ming library, >>> and get the regular R compilers to compile it. I just tried, and it >>> compiled without errors (though there were a few warnings). Then you can >>> write your R interface to it, and everything may just work. >> >> Hey, that is great! I thought about doing this but decided arbitrarily >> that it would be too hard. Do I just plop a copy of the ming source >> in the src/ directory of my package (then adjust Makevars >> accordingly)? Did you run the whole ming configure script as well? > > I just ran make. I don't think there is any configure script. > > I'd probably put their stuff in a subdir of src, just to keep it cleanly > separated from yours. This also gives you the option of *not* compiling it > on systems like Linux and MacOS that already have it. Then make up a > Makevars.win file that builds it as a static or dynamic lib on Windows and > links to it, and a Makevars file that just links to it on other platforms. > (You might want to do a static compile on the other systems just so you're > protected against version changes.) > > Duncan Murdoch > Thanks for the feedback, I agree that would be the easiest and preferable way. But which version of ming are you using that only has a makefile? The version I need (0.4.0 beta5) has a fairly involved configure script. I would have to pick out the components I need for my package and create a custom makefile for it to be easily usable (which I may end up doing, thank goodness for open source). -Cameron __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] html help in Windows
On Nov 11, 2009, at 6:54 PM, Fraser Sim wrote: Hi all, Another comment re: html help in Windows. It seems that we've lost the functionality of being able to browse the other functions in a package. In chm, after calling a help function on 'arrayw' in say package 'limma' in BioC, it was possible to see all of the other functions in the limma package. Now it seems we just get a flat html page with no links to the overall package and no side browsing. Can this be added to html help? If you scroll down to the bottom of the HTML help page, there is a link to the package index page. For example, use ?plot and scroll to the bottom of the page. There will be a link to the Index page for the graphics package. Click on that link you will have a page upon which are links to the other functions in the package. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in docs for unlink()
On 11/11/09 2:36 AM, Duncan Murdoch wrote: On 10/11/2009 11:16 PM, Tony Plate wrote: PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on a Linux system. The docs that appear in a Windows installation of R are different (the Windows docs do not mention that not all systems support recursive=TRUE). Here's a plea for docs to be uniform across all systems! Trying to write R code that works on all systems is much harder when the docs are different across systems, and you might only see system specific notes on a different system than the one you're working on. That's a good point, but in favour of the current practice, it is very irritating when searches take you to functions that don't work on your system. One thing that might be possible is to render all versions of the help on all systems, but with some sort of indicator (e.g. a colour change) to indicate things that don't apply on your system, or only apply on your system. I think the hardest part of doing this would be designing the output; actually implementing it would not be so bad. I would be strongly in favor of a change that provided documentation for all systems on all systems. Since platform specific behavior for R functions is the exception rather than the norm, I would imagine that simply displaying doc sections by platform would be sufficient. I think the benefit of being able to see what might not work on another platform far out weighs the inconvenience of finding doc during a search for something that only works on another platform -- hey, that still might be useful as it would tell you what platform you should use ;-) + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building package under windows which links against a cygwin library
On 11/11/2009 8:03 PM, Cameron Bracken wrote: On Wed, Nov 11, 2009 at 5:15 PM, Duncan Murdoch wrote: On 11/11/2009 6:49 PM, Cameron Bracken wrote: On Wed, Nov 11, 2009 at 4:36 PM, Duncan Murdoch wrote: On 11/11/2009 4:41 PM, Cameron Bracken wrote: I am developing a package (http://r-forge.r-project.org/projects/swfdevice/) which links against the ming C library. The package builds fine under Mac OS X and Linux. I am really out of my element on windows, but I know there is a cygwin package for libming. My question is, does anyone have advice/examples on linking R packages against cygwin libraries? Is this even possible? How would I go about writing a configure.win script to do this? I suspect it's not going to work. Linking to any Cygwin library will pull in the rest, and I would guess that will conflict with something else in R, which does not use Cygwin. I figured that would be the case. What you could do is include a copy of the source to the ming library, and get the regular R compilers to compile it. I just tried, and it compiled without errors (though there were a few warnings). Then you can write your R interface to it, and everything may just work. Hey, that is great! I thought about doing this but decided arbitrarily that it would be too hard. Do I just plop a copy of the ming source in the src/ directory of my package (then adjust Makevars accordingly)? Did you run the whole ming configure script as well? I just ran make. I don't think there is any configure script. I'd probably put their stuff in a subdir of src, just to keep it cleanly separated from yours. This also gives you the option of *not* compiling it on systems like Linux and MacOS that already have it. Then make up a Makevars.win file that builds it as a static or dynamic lib on Windows and links to it, and a Makevars file that just links to it on other platforms. (You might want to do a static compile on the other systems just so you're protected against version changes.) Duncan Murdoch Thanks for the feedback, I agree that would be the easiest and preferable way. But which version of ming are you using that only has a makefile? The version I need (0.4.0 beta5) has a fairly involved configure script. I would have to pick out the components I need for my package and create a custom makefile for it to be easily usable (which I may end up doing, thank goodness for open source). I was looking at ming-0.2a. It might not be the same library at all! Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building package under windows which links against a cygwin library
On Wed, Nov 11, 2009 at 8:06 PM, Duncan Murdoch wrote: > On 11/11/2009 8:03 PM, Cameron Bracken wrote: >> >> On Wed, Nov 11, 2009 at 5:15 PM, Duncan Murdoch >> wrote: >>> >>> On 11/11/2009 6:49 PM, Cameron Bracken wrote: On Wed, Nov 11, 2009 at 4:36 PM, Duncan Murdoch wrote: > > On 11/11/2009 4:41 PM, Cameron Bracken wrote: >> >> I am developing a package >> (http://r-forge.r-project.org/projects/swfdevice/) which links against >> the ming C library. The package builds fine under Mac OS X and Linux. >> I am really out of my element on windows, but I know there is a cygwin >> package for libming. >> >> My question is, does anyone have advice/examples on linking R packages >> against cygwin libraries? Is this even possible? How would I go >> about writing a configure.win script to do this? > > I suspect it's not going to work. Linking to any Cygwin library will > pull in the rest, and I would guess that will conflict with something > else > in R, which does not use Cygwin. > I figured that would be the case. > What you could do is include a copy of the source to the ming library, > and get the regular R compilers to compile it. I just tried, and it > compiled without errors (though there were a few warnings). Then you > can > write your R interface to it, and everything may just work. Hey, that is great! I thought about doing this but decided arbitrarily that it would be too hard. Do I just plop a copy of the ming source in the src/ directory of my package (then adjust Makevars accordingly)? Did you run the whole ming configure script as well? >>> >>> I just ran make. I don't think there is any configure script. >>> >>> I'd probably put their stuff in a subdir of src, just to keep it cleanly >>> separated from yours. This also gives you the option of *not* compiling >>> it >>> on systems like Linux and MacOS that already have it. Then make up a >>> Makevars.win file that builds it as a static or dynamic lib on Windows >>> and >>> links to it, and a Makevars file that just links to it on other >>> platforms. >>> (You might want to do a static compile on the other systems just so >>> you're >>> protected against version changes.) >>> >>> Duncan Murdoch >>> >> >> Thanks for the feedback, I agree that would be the easiest and >> preferable way. But which version of ming are you using that only has >> a makefile? The version I need (0.4.0 beta5) has a fairly involved >> configure script. I would have to pick out the components I need for >> my package and create a custom makefile for it to be easily usable >> (which I may end up doing, thank goodness for open source). > > I was looking at ming-0.2a. It might not be the same library at all! > > Duncan Murdoch > That is the same library but it is a very old version which has most, but not all of the features I need (unfortunately). You are correct that it does only have a makefile though. On the other hand, I don't really need the full functionality of the library, so I think I can strip out a lot of things and create a custom makefile and build just what I need. Cheers, -Cameron __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo in docs for unlink()
On 11/11/2009 9:49 PM, Seth Falcon wrote: On 11/11/09 2:36 AM, Duncan Murdoch wrote: On 10/11/2009 11:16 PM, Tony Plate wrote: PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on a Linux system. The docs that appear in a Windows installation of R are different (the Windows docs do not mention that not all systems support recursive=TRUE). Here's a plea for docs to be uniform across all systems! Trying to write R code that works on all systems is much harder when the docs are different across systems, and you might only see system specific notes on a different system than the one you're working on. That's a good point, but in favour of the current practice, it is very irritating when searches take you to functions that don't work on your system. One thing that might be possible is to render all versions of the help on all systems, but with some sort of indicator (e.g. a colour change) to indicate things that don't apply on your system, or only apply on your system. I think the hardest part of doing this would be designing the output; actually implementing it would not be so bad. I would be strongly in favor of a change that provided documentation for all systems on all systems. As I said, I don't think that's hard to implement, but it's hard to design. If you want to put together what the output (say in HTML) should look like for unlink, I'll let you know whether the implementation is really as easy as I think it will be. Duncan Murdoch Since platform specific behavior for R functions is the exception rather than the norm, I would imagine that simply displaying doc sections by platform would be sufficient. I think the benefit of being able to see what might not work on another platform far out weighs the inconvenience of finding doc during a search for something that only works on another platform -- hey, that still might be useful as it would tell you what platform you should use ;-) + seth __ 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] unname() returns a named vector when the input vector has length 0
Hi, > x <- c(aa=22, bb=555) > unname(x[FALSE]) named numeric(0) Cheers, H. > sessionInfo() R version 2.10.0 (2009-10-26) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8 [7] LC_PAPER=en_CA.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.10.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
