On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
On Tue, 13 Nov 2007, John Chambers wrote:
What's the proposal here? To eliminate double as a class? No objection
Eliminate double and single.
from this corner. As I remember, it was put in early in the
implementation of methods, when I was
Dear developeRs,
I've searched the documentation, FAQ, and mailing lists, but haven't
found the answer(*) to the following:
When should one specify LazyLoad, LazyData, and ZipData?
And what is the default if they are left unspecified?
(*)Except that
1) If the package you are writing uses the
On 11/14/2007 7:01 AM, Bjørn-Helge Mevik wrote:
Dear developeRs,
I've searched the documentation, FAQ, and mailing lists, but haven't
found the answer(*) to the following:
When should one specify LazyLoad, LazyData, and ZipData?
And what is the default if they are left unspecified?
On Wed, 14 Nov 2007, Bjørn-Helge Mevik wrote:
Dear developeRs,
I've searched the documentation, FAQ, and mailing lists, but haven't
found the answer(*) to the following:
When should one specify LazyLoad, LazyData, and ZipData?
Preferably always, and I would suggest all should be 'yes' if
On Nov 14, 2007 7:01 AM, Bjørn-Helge Mevik [EMAIL PROTECTED] wrote:
Dear developeRs,
I've searched the documentation, FAQ, and mailing lists, but haven't
found the answer(*) to the following:
When should one specify LazyLoad, LazyData, and ZipData?
And what is the default if they are left
Duncan Murdoch wrote:
On 11/14/2007 7:01 AM, Bjørn-Helge Mevik wrote:
When should one specify LazyLoad, LazyData, and ZipData?
I think that you shouldn't care about these things, and should accept
the default for them unless one of those two pieces of advice applies
to you. Let the
On Wed, November 14, 2007 09:09, Prof Brian Ripley wrote:
On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
On Tue, 13 Nov 2007, John Chambers wrote:
What's the proposal here? To eliminate double as a class? No
objection
Eliminate double and single.
from this corner. As I remember, it was
As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw = '.
If the connection has already been closed by 'close' or some other function,
then isOpen will produce an error. The problem is that when isOpen calls
'getConnection', the connection cannot be found and 'getConnection'
I have roughly 80 or so packages sources. These were obtained by taking
a snapshot of certain CRAN packages a few months ago using
install.packages(
pkgs = pckNames,
destdir = /home/max,
repos = http://cran.r-project.org;
dependencies = c(Depends, Imports, Suggests))
Hi Max,
On 14 November 2007 at 09:34, Kuhn, Max wrote:
| I have roughly 80 or so packages sources. These were obtained by taking
| a snapshot of certain CRAN packages a few months ago using
|
|install.packages(
| pkgs = pckNames,
| destdir = /home/max,
| repos =
Dirk,
Thanks for the email.
When trying to package the by-now-gargantuan Rmetrics for Debian
(which is
still ongoing), I looked around for some Depends builders. Turns out
that
BioC has this. E.g. the following worked for:
## install.packages(Biobase, repo=http://www.bioconductor.org;)
On Wed, 14 Nov 2007, Kuhn, Max wrote:
I have roughly 80 or so packages sources. These were obtained by taking
a snapshot of certain CRAN packages a few months ago using
install.packages(
pkgs = pckNames,
destdir = /home/max,
repos = http://cran.r-project.org;
Professor Ripley,
You need the information from available.packages() to do the ordering,
so
you need a non-NULL repository. This works if you convert your local
collection into a local repository. You will need a PACKAGES file, but
tools::write_PACKAGES can re-create one for you.
There
On Wed, 14 Nov 2007, Kuhn, Max wrote:
Professor Ripley,
You need the information from available.packages() to do the ordering,
so
you need a non-NULL repository. This works if you convert your local
collection into a local repository. You will need a PACKAGES file, but
Professor Ripley,
It does say 'URL(s)', hence
repos = file:///home/max/tmp/r-2.5.1-pkgs-updated
That works. Thanks for your expertise.
Max
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
On 11/14/2007 8:49 AM, Adrian Dusa wrote:
Dear all,
When creating new functions in a package, there is a See also component in
the Rd file.
Usually one uses \link{otherfun}, if the other function is from the same
package, or \link[otherpackage]{otherfun} otherwise.
The trouble is that
On Wed, 14 Nov 2007, Adrian Dusa wrote:
Dear all,
When creating new functions in a package, there is a See also component in
the Rd file.
Usually one uses \link{otherfun}, if the other function is from the same
package, or \link[otherpackage]{otherfun} otherwise.
I think you have misread
Dear R developers,
concerning the stats package,
is there a way to access more of the 'internal'
parameters of the optim() methods (e.g. BFGS),
without me rewriting optim code and using it as
an internal, patched stats package? It may not
sound useful to you, but for me it is important
to be able
Dear all,
When creating new functions in a package, there is a See also component in
the Rd file.
Usually one uses \link{otherfun}, if the other function is from the same
package, or \link[otherpackage]{otherfun} otherwise.
The trouble is that I install new packages not in the default R
On Wed, 14 Nov 2007, Mike Preuss wrote:
Dear R developers,
concerning the stats package,
is there a way to access more of the 'internal'
parameters of the optim() methods (e.g. BFGS),
without me rewriting optim code and using it as
an internal, patched stats package? It may not
sound
Dear Brian,
thanks for the hint. But my question is more
concerned with the technical procedure. Of
course, I can change the C code locally. And
then use a locally changed package. But then
nobody else beside myself can use it, right?
If changes were made in the official code
(and it's not really
On Thu, 15 Nov 2007, Adrian Dusa wrote:
Dear Prof. Ripley,
On Wednesday 14 November 2007, Prof Brian Ripley wrote:
On Wed, 14 Nov 2007, Adrian Dusa wrote:
Dear all,
When creating new functions in a package, there is a See also component
in the Rd file.
Usually one uses \link{otherfun},
On 14/11/2007 6:09 PM, Adrian Dusa wrote:
On Wednesday 14 November 2007, Duncan Murdoch wrote:
On 11/14/2007 8:49 AM, Adrian Dusa wrote:
[...]
Is there a method to create links to functions from the base package, for
example (which is installed by default in the normal library folder)?
I
On 14/11/2007 6:44 PM, Adrian Dusa wrote:
On Thursday 15 November 2007, Prof Brian Ripley wrote:
[...]
Using as above:
\code{\link{anova}}
the html help file directs to
file:///home/adi/myRlibrary/stats/html/anova.html
I hope it is actually ../../stats/html/anova.html and the browser is
On Thursday 15 November 2007, Duncan Murdoch wrote:
[...]
I understand, thank you. I learned from Prof. Ripley's answer that
Windows has link.html.help() function to resolve the html help files from
all installed packages.
I didn't know about that; I mainly use the CHMHELP files. They
On Thursday 15 November 2007, Duncan Murdoch wrote:
[...]
I tried using help.start() in .Rprofile, but it throws a (probably
obvious) error:
Error: could not find function help.start
That's just because .Rprofile is run before most packages are attached;
you should be able to say
On Nov 14, 2007 4:36 PM, Duncan Murdoch [EMAIL PROTECTED] wrote:
On Unix-alikes, the workaround is to build soft links to all the
packages in a standard location; but soft links don't work on Windows
(and we don't want to get into the almost-undocumented hard links that
exist on some Windows
On Thursday 15 November 2007, Prof Brian Ripley wrote:
[...]
Using as above:
\code{\link{anova}}
the html help file directs to
file:///home/adi/myRlibrary/stats/html/anova.html
I hope it is actually ../../stats/html/anova.html and the browser is
interpreting that as a full URL.
An extremely modest proposal:
It would be nice if packages could have a FAQ and if
faq(package.name)
would produce this faq. And if, by default
faq()
FAQ()
would produce the admirable R faq... Apologies in advance
if there is already a mechanism like this, but
Another possibility is to just place it at the end of the vignette.
That is where it is in the proto package:
http://cran.r-project.org/doc/vignettes/proto/proto.pdf
Package documentation is already quite scattered and adding
a faq() command would add just one more thing one has
to do. Here are
Roger D. Peng [EMAIL PROTECTED] writes:
As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw =
'.
If the connection has already been closed by 'close' or some other function,
then isOpen will produce an error. The problem is that when isOpen calls
'getConnection', the
31 matches
Mail list logo
