Re: [Rd] link to an alias in another package
On Tue, 8 Feb 2005 07:18:28 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Mon, 7 Feb 2005, Paul Gilbert wrote:
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an alias
under \name{varimax}. This kind of link works within a package, but I'm not
sure if it is suppose to work when it is a link to another package. Is this
a
known limitation or bug, or something I should explore more carefully?
Definitely the latter! Don't include [stats] (why are you including it?),
or do read the documentation in R-exts:
There are optional arguments specified as \link[pkg]{foo} and
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
so you need \code{\link[stats:varimax]{promax}}. Note the difference
between `topic' and `alias' here.
This is not a bug, but is it a design flaw? The problem is that Paul
wants to refer to the documentation for promax. Currently that's in
the varimax topic, but if someone were to split the topics, that
wouldn't be true any more: and then Paul's link would point to the
wrong place.
It is inconsistent that \link{foo} looks for the alias foo, but
\link[pkg]{foo} and \link[pkg:foo]{bar} look for the topic foo.
It is probably impossible to implement links to aliases perfectly
(e.g. if pkg is unavailable at the time the .html file for Paul's
topic is being built, it's not clear what the link should be), but
doing at least as well as \link{foo} does would take very little work.
The algorithm could be:
- attempt to look up the alias foo in pkg. If that succeeds, use the
resulting topic in the link.
- if pkg exists but the lookup fails, that's an error.
- if the lookup fails because pkg does not exist, print a warning,
and create a link as though the alias is a topic.
This would mean \link[stats]{promax} would be fine, and would survive
the addition of a promax topic to another package, or the splitting of
promax out of the varimax topic.
You only need the [] to disambiguate crossreferences, or to refer to
packages that might not yet be installed, which does not apply to [stats].
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot: space makes beside=F (PR#7668)
[EMAIL PROTECTED] wrote: Full_Name: Ondrej Medek Version: 2.0.1 OS: Linux/Debian Sarge Submission from: (NULL) (147.32.127.204) Hi, I had a R version 1.5.1 and I used a 'barplot' with 'beside=T' and 'space' has been vector of 8 numbers 'space=c(1,0.5,rep(c(0.5,-0.5),3))'. Then I upgraded to the R 2.0.1 and my graphs are broken. If I use any vector of more than 2 elements for 'space' then the graph is drawn as 'beside=F' even if I specify 'beside=T'. In the previous version my graph was a graph of groups of eight bars separated by a big spaces. Every group consisted of 4 pairs of bars separated by a small space. It's impossible now. This is not a bug. See ?barplot which tells us: space: [...] If height is a matrix and beside is TRUE, space may be specified by two numbers, where the first is the space between bars in the same group, and the second the space between the groups. [...] and it works as described: barplot(matrix(1:10, 2), beside = TRUE, space = c(1, 7)) Uwe Ligges __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot: space makes beside=F (PR#7668)
Hi Ondrej,
can you give a very small *REPRODUCIBLE* example
of R code that worked in R 1.5.1 and doesn't work the same in R
2.0.1.
I know that we made some changes for barplot() on purpose,
documented it, announced it in NEWS, etc, etc.
So I'm sure it's not a bug.
{ I'm also sure that your
``It's impossible now ''
must be wrong. R is a full-fledged programming language, and in
principle everything is possible :-)
}
Ondrej == o medek [EMAIL PROTECTED]
on Mon, 7 Feb 2005 21:03:19 +0100 (CET) writes:
Ondrej Full_Name: Ondrej Medek
Ondrej Version: 2.0.1
Ondrej OS: Linux/Debian Sarge
Ondrej Submission from: (NULL) (147.32.127.204)
Ondrej Hi, I had a R version 1.5.1 and I used a 'barplot'
Ondrej with 'beside=T' and 'space' has been vector of 8
Ondrej numbers 'space=c(1,0.5,rep(c(0.5,-0.5),3))'. Then I
Ondrej upgraded to the R 2.0.1 and my graphs are broken. If
Ondrej I use any vector of more than 2 elements for 'space'
Ondrej then the graph is drawn as 'beside=F' even if I
Ondrej specify 'beside=T'.
Ondrej In the previous version my graph was a graph of
Ondrej groups of eight bars separated by a big
Ondrej spaces. Every group consisted of 4 pairs of bars
Ondrej separated by a small space. It's impossible now.
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to an alias in another package
On Tue, 8 Feb 2005, Duncan Murdoch wrote:
On Tue, 8 Feb 2005 07:18:28 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Mon, 7 Feb 2005, Paul Gilbert wrote:
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an alias
under \name{varimax}. This kind of link works within a package, but I'm not
sure if it is suppose to work when it is a link to another package. Is this a
known limitation or bug, or something I should explore more carefully?
Definitely the latter! Don't include [stats] (why are you including it?),
or do read the documentation in R-exts:
There are optional arguments specified as \link[pkg]{foo} and
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
so you need \code{\link[stats:varimax]{promax}}. Note the difference
between `topic' and `alias' here.
This is not a bug, but is it a design flaw? The problem is that Paul
wants to refer to the documentation for promax. Currently that's in
Not a design flaw, just a rather more carefully researched design that
actually works.
Unless the package is present, you have no idea in what file the help for
promax is, and you need to know to generate hyperlinks (or you don't need
to use this notation).
Now, hyperlinks to other packages are no real use in current PDF (unless
you merge PDF files), and HTML help will if java/javascript is enabled
resolve the references at run time, BUT neither HTML without the search
engine nor CHTML can do that.
Since two packages can cross-reference each other, you cannot assume that
the one you want to reference is currently installed without a potential
deadlock.
the varimax topic, but if someone were to split the topics, that
wouldn't be true any more: and then Paul's link would point to the
wrong place.
It is inconsistent that \link{foo} looks for the alias foo, but
\link[pkg]{foo} and \link[pkg:foo]{bar} look for the topic foo.
Not in my understanding. That's the whole (and documented) point of the
notation, to tell Rdconv where to look when aliases are not
known/available.
It is probably impossible to implement links to aliases perfectly
(e.g. if pkg is unavailable at the time the .html file for Paul's
topic is being built, it's not clear what the link should be), but
However, that is the only common reason to use this form of link.
doing at least as well as \link{foo} does would take very little work.
The algorithm could be:
- attempt to look up the alias foo in pkg. If that succeeds, use the
resulting topic in the link.
- if pkg exists but the lookup fails, that's an error.
- if the lookup fails because pkg does not exist, print a warning,
and create a link as though the alias is a topic.
The last is the only time you really need this, and what is done now is
better than your suggestion. We set up a mechanism for precisely this
case, and to break it would be a design flaw.
The only other known circumstance can be seen in links like
\link[stats]{logLik}
\link[stats4:logLik-methods]{logLik},
since two packages have such a topic/alias and they need to refer to each
other. That's most likely for S4 methods.
--
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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problems with tcltk in R2.0.1
Hello, I have an tcltk application that runs without problems in R1.9.1, but when I press the run-button in R2.0.1, I get the message Error in function () : can't change value of a locked binding. I have another tcltk application that runs fine on R2.0.1, so tcltk seems to be properly installed. Does anyone have a good idea? The code is available at ftp.imr.no/vidarh/diva.zip Best regards, Vidar Hjellvik Institute of Marine Research P.O.Box 1870 Nordnes N-5817 Bergen phone: +47 55 23 86 62 email: [EMAIL PROTECTED] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-patched Make Check Fails on reg-tests-1.R on linux and OS X
Since no one else has this problem, I suggest you check the integrity of your checkout, or, better, use an R-patched tarball that can easily be verified. This looks very like a mismatched build and test: that is your R build has not be updated to include the patch which is being tested. A completely clean build from a tarball will ensure that is not the case. Reporting problems using unreleased compilers (gcc 3.4.4 is not released) isn't going to win you a lot of sympathy: they have been responsible for a large number of (mis-directed) problem reports. If you didn't have the problem on two machines I would be suggesting using released versions of the tools. FYI, R is tested on released compilers on i686 Linux several times a day, and at least weekly on other common platforms. We would know soon enough if there was an R problem in 'make all check' on those platforms. On Mon, 7 Feb 2005, Jake Bowers wrote: Dear Developers, I've been playing around with compiling R on my Debian Linux machine (dual Athlon 1.4ghz) and my OS X machine (dual G5). I'm emailing now because reg-tests-1.R fails during make check on my debian machine using gcc-3.4, and on my OS X machine using gcc-3.3. I am using r-patched updated via svn today (Updated to revision 33075.) Here are some details: **Using gcc-3.4 on debian: gcc-3.4 (GCC) 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) wes:/home/temp/R/r-patched/tests# tail reg-tests-1.Rout.fail ## automatic row.names can be number-like, MM, 2004-11-26 d0 - data.frame(x=1:3, y=pi*2:0) row.names(d0)[3] - c(01.00) write.table(d0, (tf - tempfile())) d - read.table(tf) ## gave error (duplicate row.names) in 2.0.1 stopifnot(all.equal(d,d0)) unlink(tf) **Using gcc-3.3 on debian works fine (passes all make check). gcc (GCC) 3.3.5 (Debian 1:3.3.5-5) **Using gcc-3.3 on OS X. gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671) More info on my OS X build: ./configure --with-blas='-framework vecLib' --with-lapack --with-aqua --with-x --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh --enable-R-shlib TCLTK_LIBS='-framework Tcl -framework Tk' TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers -I/Library/Frameworks/Tk.Framework/Headers' --with-recommended g77 is version 3.4 downloaded from hpc.sf.net. GNU Fortran (GCC) 3.4.2 echo $PATH /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/sw/bin:/sw/sbin:/usr/local/pvm3/lib:/usr/local/pvm3/bin/DARWIN and, to prevent it from using stuff in the fink directory: CPPFLAGS='-I/usr/local/include' Here is the output where make check fails: running regression tests running code in 'reg-tests-1.R' ...make[3]: *** [reg-tests-1.Rout] Error 1 make[2]: *** [test-Reg] Error 2 make[1]: *** [test-all-basics] Error 1 make: *** [check-all] Error 2 sphere:~/TEMP/R/r-patched/tests jwbowers$ tail reg-tests-1.Rout.fail ## automatic row.names can be number-like, MM, 2004-11-26 d0 - data.frame(x=1:3, y=pi*2:0) row.names(d0)[3] - c(01.00) write.table(d0, (tf - tempfile())) d - read.table(tf) ## gave error (duplicate row.names) in 2.0.1 stopifnot(all.equal(d,d0)) unlink(tf) Should I be very concerned about this? I tend to mostly use my OS X machine since the Linux box is about 4 years old. I hope this information is helpful --- I'm sorry if this is something obvious! (I found some posts from last summer about problems with gcc-3.4, which might explain the problems with gcc-3.4 on linux, but I didn't find anything obvious about gcc-3.3 on the Mac). Thanks so much for all of your work!! Best, Jake Jake Bowers Assistant Professor Dept of Political Science University of Michigan http://www.umich.edu/~jwbowers __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: Packages and Libraries (was: Re: lme4 package etc ..)
tony == A J Rossini [EMAIL PROTECTED]
on Tue, 8 Feb 2005 13:33:23 +0100 writes:
tony For OBVIOUS reasons, is there any chance that we could introduce
tony package() and deprecate library()?
This idea is not new {as you must surely have guessed}. In fact,
there's a much longer standing proposition of usePackage()
(IIRC, or use.package() ?). However, we (R-core) always had
wanted to also provide a ``proper'' class named package
along with this, but for several reasons didn't get around to it.. yet.
-- I've diverted to R-devel now that we are really talking about
desired future behavior of R
tony (well, I'll also ask if we could deprecate = for assignment, but
tony that's hopeless).
:-)
tony On Tue, 8 Feb 2005 11:49:39 +0100, Martin Maechler
tony [EMAIL PROTECTED] wrote:
Pavel == Pavel Khomski [EMAIL PROTECTED]
on Tue, 08 Feb 2005 10:20:03 +0100 writes:
Pavel this is a question, how can i specify the random part
Pavel in the GLMM-call (of the lme4 library) for compound
Pavel matrices just in the the same way as they defined in
Pavel the lme-Call (of the nlme library).
``twice in such a short paragraph -- yikes !!'' ... I'm getting
convulsive...
There is NO lme4 library nor an nlme one !
There's the lme4 *PACKAGE* and the nlme *PACKAGE* -- please --
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to an alias in another package
On Tue, 8 Feb 2005 12:21:05 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Tue, 8 Feb 2005, Duncan Murdoch wrote:
On Tue, 8 Feb 2005 07:18:28 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Mon, 7 Feb 2005, Paul Gilbert wrote:
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an alias
under \name{varimax}. This kind of link works within a package, but I'm not
sure if it is suppose to work when it is a link to another package. Is
this a
known limitation or bug, or something I should explore more carefully?
Definitely the latter! Don't include [stats] (why are you including it?),
or do read the documentation in R-exts:
There are optional arguments specified as \link[pkg]{foo} and
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
so you need \code{\link[stats:varimax]{promax}}. Note the difference
between `topic' and `alias' here.
This is not a bug, but is it a design flaw? The problem is that Paul
wants to refer to the documentation for promax. Currently that's in
Not a design flaw, just a rather more carefully researched design that
actually works.
Unless the package is present, you have no idea in what file the help for
promax is, and you need to know to generate hyperlinks (or you don't need
to use this notation).
Now, hyperlinks to other packages are no real use in current PDF (unless
you merge PDF files), and HTML help will if java/javascript is enabled
resolve the references at run time, BUT neither HTML without the search
engine nor CHTML can do that.
Since two packages can cross-reference each other, you cannot assume that
the one you want to reference is currently installed without a potential
deadlock.
the varimax topic, but if someone were to split the topics, that
wouldn't be true any more: and then Paul's link would point to the
wrong place.
It is inconsistent that \link{foo} looks for the alias foo, but
\link[pkg]{foo} and \link[pkg:foo]{bar} look for the topic foo.
Not in my understanding. That's the whole (and documented) point of the
notation, to tell Rdconv where to look when aliases are not
known/available.
It is probably impossible to implement links to aliases perfectly
(e.g. if pkg is unavailable at the time the .html file for Paul's
topic is being built, it's not clear what the link should be), but
However, that is the only common reason to use this form of link.
doing at least as well as \link{foo} does would take very little work.
The algorithm could be:
- attempt to look up the alias foo in pkg. If that succeeds, use the
resulting topic in the link.
- if pkg exists but the lookup fails, that's an error.
- if the lookup fails because pkg does not exist, print a warning,
and create a link as though the alias is a topic.
The last is the only time you really need this, and what is done now is
better than your suggestion. We set up a mechanism for precisely this
case, and to break it would be a design flaw.
I only see two differences between the current scheme and the last
case:
- now no warning is printed, which does seem reasonable, given that
there exist mutual cross-references.
- my scheme would require that a topic name be repeated as an alias
if both the first and last type of lookups were possible.
Alternatively, we could allow lookups by topic name as well as alias
for back-compatibility.
Other than these, I don't see how the current scheme is better. In
the current system:
- If I use an unadorned \link{promax}, I run the risk of having it go
to the wrong place if someone defines a promax alias in some other
package that is installed before mine.
- If I use \link[stats:varimax]{promax}, then I run the risk of
having it go to the wrong place if someone splits promax.Rd out of
varimax.Rd in the stats package.
- If I have a spelling error in the link (e.g.
\link[stats:varmax]{promax}), then neither INSTALL nor CHECK will tell
me about it.
None of these would be a problem if I used \link[stats]{promax} under
my proposal, unless my package were being installed before stats was,
in which case the link would fail.
But if that's a possibility (e.g. we're talking about a core package,
or a package with mutual dependencies with the referenced one so that
we can't be sure which will be installed first), then we could simply
document that references to aliases might fail. Two packages with
mutual dependencies are presumably being maintained together, so the
second problem above wouldn't be an issue.
Have I missed some advantages of the current scheme over the one I
proposed? There's the obvious one of the fact that it exists, whereas
mine will take a bit of work to do, but if I don't hear of some fatal
flaw, I'll volunteer to do the work. I don't think it will be hard.
Duncan Murdoch
Re: [Rd] R-patched Make Check Fails on reg-tests-1.R on linux and OS X
Hi Jake, with this config hal:~ jago$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) hal:~ jago$ g77 -v Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/specs Configured with: ../gcc/configure --enable-threads=posix --enable-languages=f77 --disable-shared --enable-static Thread model: posix gcc version 3.4.2 btw, in configure you don't need to use --with-x, --enable-R-shlib and --with-recommended You did not report the OS X version which might be the source of the problem. Please also get the latest g77 from http://hpc.sourceforge.net/ The above setup works fine on OS X 10.2 and 10.3. stefano ./configure --with-blas='-framework vecLib' --with-lapack --with-aqua --with-x --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh --enable-R-shlib TCLTK_LIBS='-framework Tcl -framework Tk' TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers -I/Library/Frameworks/Tk.Framework/Headers' --with-recommended On Feb 8, 2005, at 2:43 PM, Prof Brian Ripley wrote: Since no one else has this problem, I suggest you check the integrity of your checkout, or, better, use an R-patched tarball that can easily be verified. This looks very like a mismatched build and test: that is your R build has not be updated to include the patch which is being tested. A completely clean build from a tarball will ensure that is not the case. Reporting problems using unreleased compilers (gcc 3.4.4 is not released) isn't going to win you a lot of sympathy: they have been responsible for a large number of (mis-directed) problem reports. If you didn't have the problem on two machines I would be suggesting using released versions of the tools. FYI, R is tested on released compilers on i686 Linux several times a day, and at least weekly on other common platforms. We would know soon enough if there was an R problem in 'make all check' on those platforms. On Mon, 7 Feb 2005, Jake Bowers wrote: Dear Developers, I've been playing around with compiling R on my Debian Linux machine (dual Athlon 1.4ghz) and my OS X machine (dual G5). I'm emailing now because reg-tests-1.R fails during make check on my debian machine using gcc-3.4, and on my OS X machine using gcc-3.3. I am using r-patched updated via svn today (Updated to revision 33075.) Here are some details: **Using gcc-3.4 on debian: gcc-3.4 (GCC) 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) wes:/home/temp/R/r-patched/tests# tail reg-tests-1.Rout.fail ## automatic row.names can be number-like, MM, 2004-11-26 d0 - data.frame(x=1:3, y=pi*2:0) row.names(d0)[3] - c(01.00) write.table(d0, (tf - tempfile())) d - read.table(tf) ## gave error (duplicate row.names) in 2.0.1 stopifnot(all.equal(d,d0)) unlink(tf) **Using gcc-3.3 on debian works fine (passes all make check). gcc (GCC) 3.3.5 (Debian 1:3.3.5-5) **Using gcc-3.3 on OS X. gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671) More info on my OS X build: ./configure --with-blas='-framework vecLib' --with-lapack --with-aqua --with-x --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh --enable-R-shlib TCLTK_LIBS='-framework Tcl -framework Tk' TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers -I/Library/Frameworks/Tk.Framework/Headers' --with-recommended g77 is version 3.4 downloaded from hpc.sf.net. GNU Fortran (GCC) 3.4.2 echo $PATH /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/sw/bin:/ sw/sbin:/usr/local/pvm3/lib:/usr/local/pvm3/bin/DARWIN and, to prevent it from using stuff in the fink directory: CPPFLAGS='-I/usr/local/include' Here is the output where make check fails: running regression tests running code in 'reg-tests-1.R' ...make[3]: *** [reg-tests-1.Rout] Error 1 make[2]: *** [test-Reg] Error 2 make[1]: *** [test-all-basics] Error 1 make: *** [check-all] Error 2 sphere:~/TEMP/R/r-patched/tests jwbowers$ tail reg-tests-1.Rout.fail ## automatic row.names can be number-like, MM, 2004-11-26 d0 - data.frame(x=1:3, y=pi*2:0) row.names(d0)[3] - c(01.00) write.table(d0, (tf - tempfile())) d - read.table(tf) ## gave error (duplicate row.names) in 2.0.1 stopifnot(all.equal(d,d0)) unlink(tf) Should I be very concerned about this? I tend to mostly use my OS X machine since the Linux box is about 4 years old. I hope this information is helpful --- I'm sorry if this is something obvious! (I found some posts from last summer about problems with gcc-3.4, which might explain the problems with gcc-3.4 on linux, but I didn't find anything obvious about gcc-3.3 on the Mac). Thanks so much for all of your work!! Best, Jake Jake Bowers Assistant Professor Dept of Political Science University of Michigan http://www.umich.edu/~jwbowers __ R-devel@stat.math.ethz.ch mailing
[Rd] Pre-building lazyload DB
Hi all, Bioconductor has several metaData packages that contain quite large data sets. In the past, these data were simply held in the /data directory of the package as .rda files and load()ed as needed. Converting to using lazy data loading may have memory and performance advantages, but for the larger metaData packages the installation is painfully slow (it has taken 30 min to install a large metaData package on a PIII, 933 MHz box running Mandrake 9.2). The vast majority of the time is spent moving datasets to lazyload DB. It takes a long time to build the win32 packages as well, but once the package is built, the installation is quick, so there is no real problem for our end users. So my question is this; is there a mechanism that can be used to pre-build the lazyload DB for source packages to decrease the installation time for our end users? Best, Jim James W. MacDonald Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623 ** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Environment with no parent?
Is it possible to create an environment that has no parent (or an
empty parent)? I would have thought
e - new.env(parent=NULL)
would work, but it acts as though the parent is the base namespace:
get(close, envir = e)
function (con, ...)
UseMethod(close)
environment: namespace:base
I can use inherits = FALSE in this case:
get(close, envir = e, inherits = F)
Error in get(x, envir, mode, inherits) : variable close was not
found
but what I want to do is to create my own hierarchy of environments
that allow inheritance from their parents, but which stop when they
get to e, and don't continue on into base. For example
assign('x', 1, envir = e)
f - new.env(parent = e)
assign('y', 2, envir = f)
# The first two of these work as desired, but I'd like a not found error
from the last:
get('y', envir=f)
[1] 2
get('x', envir=f)
[1] 1
get('close', envir=f)
function (con, ...)
UseMethod(close)
environment: namespace:base
Looking in envir.c, I see this:
/* env is now R_NilValue, the base environment */
which doesn't give me much hope, but maybe there's a trick
If not, would it be reasonable to install a magic EmptyEnv to use as
a parent in this sort of situation?
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RE: [R] Windows Printing and Line Widths
... Moved from R-help ...
Thank you for your suggestion, Professor Ripley. Postscript does seem
like the way to go for printing line widths correctly in Windows.
On Linux I am using a simple dev.print() wrapper (as suggested), with a
pipe to lpr.
However, I had an extremely difficult time getting postscript printing
under windows.
?postscript recommends the RedMon suite of tools for printing PS files
to printers. I had no trouble installing and using this utility from my
shell, but under R, I observed this odd behavior:
options(printcmd='redpr')
plot(1:10)
dev.print(file = Rplots.ps, print.it = TRUE)
dev.off()
## Nothing happens!!
q()
## Now it prints
That is, the file only prints when the R session is closed, and not when
the device is closed (contrary to the documentation). After some head
banging, I changed the printcmd options to lpr (the one that comes with
Windows XP), and the PS file printed out correctly after the dev.off()
command. If other people observe this behavior with Windows / RedMon,
then perhaps Windows lpr is the better tool.
Either way, I'm happy to now have beautiful Windows plots again on both
my R screen and R printer.
Thanks,
Robert
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 08, 2005 12:10 PM
To: McGehee, Robert
Cc: r-help@stat.math.ethz.ch
Subject: Re: [R] Windows Printing and Line Widths
Those printers AFAIK support postscript.
How are you printing to them on Linux? I suggest you use dev.print
under
Windows (it needs some setup, see ?postscript). That makes more sense
than going via PDF as the support is all already in R and it is AFAIK
the
printer's native mode.
We've seen far too many problems with HP Windows printer drivers on 8000
and 4000 series printers.
On Tue, 8 Feb 2005, McGehee, Robert wrote:
Hi all,
I develop and print from both Windows and Linux, and am seeing some
printing inconsistencies first described about a year and a half ago
by
Andy Liaw (see below). Specifically, the line widths on my windows
plots
are about 5 times smaller than that on Linux, and my windows printouts
do not match what my screen looks like. However, if I print to a pdf
file first, then I can get accurate Windows reproduction of my screen.
I
was thinking of writing a windows.print() wrapper that creates a
temporary pdf file and then prints that. However, I wanted to see if a
better solution now exists to get identical printouts on both Linux
and
Windows (since Andy's original post), or any comments on what printers
this does or does not affect.
Thanks,
Robert
HP Laserjet 8150DN
HP Color Laserjet 4600DN
HP Laserjet 4050TN
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major2
minor0.1
year 2004
month11
day 15
language R
-
From: Prof Brian Ripley
Date: Mon Jun 23 2003 - 23:59:29 EDT
What printer driver are you using?
I've just tried this and it works exactly as one would expect on my HP
970CXi, as well as cut-and-paste into other applications. It also
worked
printing to Acrobat Distiller (although all the lines were thinner
there
than on-screen and on the 970CXi, the ratio was still 1:5).
We've been here before, and had to abandon some optimizations because
of
a
bug in interpreting Windows metafiles in Word.
On Mon, 23 Jun 2003, Sundar Dorai-Raj wrote:
Andy,
I've experienced the same thing. What's interesting is that printing
a plot (CTRL-P) with lwd = 25 makes lines on the hardcopy look like
lwd
= 5. I'm using R1.7.1 on Win2000Pro.
Regards,
Sundar
Liaw, Andy wrote:
Dear R-help,
Has anyone notice the problem that, on Windows (NT and XP), when
printing a
graph using the File - Print... menu in the graphics window to
print the
graph, that line width seemed to be ignored in the printed output?
For
example, if I make a plot with plot(1:10, type=l, lwd=5), it looks
right
on screen, but when printed out using the menu, it looks like the
plot was
made with lwd=1. I've had this problem for quite a while (at least
since
1.3.x) and still present in 1.7.1. Has anyone else seen this, or
just me?
Best,
Andy
Andy Liaw, PhD
Biometrics Research PO Box 2000, RY33-300
Merck Research Labs Rahway, NJ 07065
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 732-594-0820
--
Notice: This e-mail message, together with any attachments, cont...
{{dropped}}
__
R-help@stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
__
R-help@stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
[Rd] Crash when R-devel is started from a shortcut
Hi, I am in a habit of frequently building R-devel daily snapshots. I use Win2000 Pro system with all the necessary tools installed and the builds usually go without a problem. I also build R-patched snapshots, so my production R is up-to-date. Hence, I have two parallel installations of R: R-devel and R-patched. In Windows environmental variables I set R_HOME to my R-patched path. I have shortcuts to both versions of R on my desktop. Starting from February 7 build, I noticed the following problem. The build itself and the installation (I build the *.exe installer) run with no errors but, when I try to start R-devel from a shortcut, I get The instruction at 0x77fcc128 referenced memory at 0x00230010. The memory could not be read. error. The same happens when I just go in the Windows Explorer to the bin directory and double-click on the Rgui.exe icon. When I double-click on the Rterm.exe icon, it starts fine in its own terminal window. When I open a cygwin terminal window, change the directory to .../R-devel/bin and type Rgui.exe from there, it starts with no problem, so I guess something either this is a Windows problem or something else interferes with the proper path. Any help will be appreciated. Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: [EMAIL PROTECTED] Tel: (651) 733-6092 Fax: (651) 736-3122 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
Duncan Murdoch [EMAIL PROTECTED] writes: Looking in envir.c, I see this: /* env is now R_NilValue, the base environment */ which doesn't give me much hope, but maybe there's a trick If not, would it be reasonable to install a magic EmptyEnv to use as a parent in this sort of situation? I'm fairly sure the answer is nope. It's been annoying me for years, for language aesthetic reasons mostly, but also with some consideration of cases like yours, and I've been on the brink of implementing a version where the base environment was a true environment. Apart from the usual issue of round tuits, I was held back by the fact that one has to consider at least two things: (a) efficiency. Is it expensive no longer to have the base functions bound directly to their symbol? (My gut feeling is that with suitable hashing and cacheing, the penalty is minimal.) (b) you can *only* use get and simple variable retrieval in a non-base environment with a NULL parent (eval(x - 1, envir=foo) would give 'couldn't find function -' or so). This could cause some confusion. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
On Feb 8, 2005, at 12:49 PM, Peter Dalgaard wrote: Duncan Murdoch [EMAIL PROTECTED] writes: Looking in envir.c, I see this: /* env is now R_NilValue, the base environment */ which doesn't give me much hope, but maybe there's a trick If not, would it be reasonable to install a magic EmptyEnv to use as a parent in this sort of situation? I'm fairly sure the answer is nope. It's been annoying me for years, for language aesthetic reasons mostly, but also with some consideration of cases like yours, and I've been on the brink of implementing a version where the base environment was a true environment. Apart from the usual issue of round tuits, I was held back by the fact that one has to consider at least two things: (a) efficiency. Is it expensive no longer to have the base functions bound directly to their symbol? (My gut feeling is that with suitable hashing and cacheing, the penalty is minimal.) (b) you can *only* use get and simple variable retrieval in a non-base environment with a NULL parent (eval(x - 1, envir=foo) would give 'couldn't find function -' or so). This could cause some confusion. And, I think, that a better approach is to implement a proper hash table class and to then implement environments as hash table + parent (rather than the current version, which would be environment - parent), but the tuit shortage is devastating on this side of the atlantic (possibly due to the disadvantageous $/euro exchange rate; I'm sure you all can afford more of them :-)) Robert -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel +--- + | Robert Gentleman phone: (206) 667-7700 | | Head, Program in Computational Biology fax: (206) 667-1319 | | Division of Public Health Sciences office: M2-B865 | | Fred Hutchinson Cancer Research Center | | email: [EMAIL PROTECTED] | +--- + __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On 08-Feb-05 Kurt Hornik wrote: Afaic, one of the issues is that it seems common practice to refer to collections of code as libraries or packages, and we're trying to use these rather general-purpose terms in a very precise meaning, and obviously not very successful, in particular because the use of library is highly non-standard. One idea might be to replace the library by something else like ... a place where R knows where to find packages ... hmm, now that's too long, so ... The only issue I have with library vs package (or vice versa) is the following. I *know* that a collection of functions etc. (such as nlme) is properly called a package. I could (and do) get ticked off if I refer to it as a library. However, if I want to use it then I enter library(nlme) As a result, the little daemons who potter around re-wiring my mental circuits sometimes cross-connect these two. As a result, I can inadvertently refer to the nlme library. An example is a recent mailing of mine to the list where I twice referred to a certain library (and was amiably rebuked by Martic Maechler) -- but then I saw that I had also twice referred to the same package in the same mail! Personally I don't mind whether it is called package or library, though using the command library() to load a package does tend, as described, to get me treading on my own shoelaces. But, a propos, is there an R entity called a library (other than the command) as distinct from a package? If so, then I can accept the necessity for disciplined distinction between them, since calling one sort of thing by the name of another sort of thing necessarily creates confusion. But if not, then I'm inclined to feel that a bit of loose talk is acceptable (since then a reference to a library would be understood as a reference to a package, since what else would it be?) Just my thoughts ... Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Fax-to-email: +44 (0)870 094 0861 Date: 08-Feb-05 Time: 22:19:46 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
Robert Gentleman [EMAIL PROTECTED] writes: And, I think, that a better approach is to implement a proper hash table class and to then implement environments as hash table + parent (rather than the current version, which would be environment - parent), Sounds like a good idea. Environments probably need to be *references* to hash tables plus parent, though. but the tuit shortage is devastating on this side of the atlantic (possibly due to the disadvantageous $/euro exchange rate; I'm sure you all can afford more of them :-)) I'm sure my publisher will have suggestions for the use of any tuit that I can get (and they pay in $, notwithstanding the IRS wanting me to spend my copious free time on wrapping up enough red tape to prevent them from taxing income which they are clearly not entitled to do. Puff, pant...) -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On Tue, 08 Feb 2005 22:19:46 - (GMT) (Ted Harding) wrote: On 08-Feb-05 Kurt Hornik wrote: Afaic, one of the issues is that it seems common practice to refer to collections of code as libraries or packages, and we're trying to use these rather general-purpose terms in a very precise meaning, and obviously not very successful, in particular because the use oflibrary is highly non-standard. One idea might be to replace thelibrary by something else like ... a place where R knows where to find packages ... hmm, now that's too long, so ... The only issue I have with library vs package (or vice versa) is the following. I *know* that a collection of functions etc. (such as nlme) is properly called a package. I could (and do) get ticked off if I refer to it as a library. However, if I want to use it then I enter library(nlme) As a result, the little daemons who potter around re-wiring my mental circuits sometimes cross-connect these two. As a result, I can inadvertently refer to the nlme library. An example is a recent mailing of mine to the list where I twice referred to a certain library (and was amiably rebuked by Martic Maechler) -- but then I saw that I had also twice referred to the same package in the same mail! Personally I don't mind whether it is called package or library, though using the command library() to load a package does tend, as described, to get me treading on my own shoelaces. But, a propos, is there an R entity called a library (other than the command) as distinct from a package? A *library* is a directory in which you can find R *packages* (just as in real life you can find books in a library) and with library(foo, lib.loc = /path/to/bar) you want to get the package (book) foo from the library bar located at /path/to/bar. So the two are really distinct...in real life, you also wouldn't say that you have been in the book where they had a lot of libraries on the shelves, would you? ;-) But as Kurt explained: this distinction between library and package is specific to R and does not correspond to common practice for other software systems. Z If so, then I can accept the necessity for disciplined distinction between them, since calling one sort of thing by the name of another sort of thing necessarily creates confusion. But if not, then I'm inclined to feel that a bit of loose talk is acceptable (since then a reference to a library would be understood as a reference to a package, since what else would it be?) Just my thoughts ... Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Fax-to-email: +44 (0)870 094 0861 Date: 08-Feb-05 Time: 22:19:46 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On Tue, 8 Feb 2005 [EMAIL PROTECTED] wrote: [...] But, a propos, is there an R entity called a library (other than the command) as distinct from a package? Yes. That is what the argument 'lib.loc' to library() and other functions refers to. A 'library' is a collection of packages stored in one directory. library(pkg) means `go to one or more libraries, find package pkg and load it up' In S parlance what in R is a `package' is a `library section' or (latterly) also `chapter'. In English usage a library is a collection of volumes, not of recipes or stories or articles. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
Duncan Murdoch [EMAIL PROTECTED] writes: (a) efficiency. Is it expensive no longer to have the base functions bound directly to their symbol? (My gut feeling is that with suitable hashing and cacheing, the penalty is minimal.) (b) you can *only* use get and simple variable retrieval in a non-base environment with a NULL parent (eval(x - 1, envir=foo) would give 'couldn't find function -' or so). This could cause some confusion. (b) means that the default should stay the way it is, but I think there should be a way to set up a truly empty environment. We have a fair number of cases where envir=NULL is used, so it would be safest to make it a different value -- even if NULL is the obvious value for an empty environment. Not necessarily. It just means that you should think about it. It is not a given that envir=NULL really means what the author expected, and fixing them up to read envir=.BaseEnv is probably quite doable. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On Wed, 9 Feb 2005, Achim Zeileis wrote: A *library* is a directory in which you can find R *packages* (just as in real life you can find books in a library) and with library(foo, lib.loc = /path/to/bar) you want to get the package (book) foo from the library bar located at /path/to/bar. Out of pure curiosity, could anyone tell me the historical reason that library() is used here? Does it tie in to the S ancestry of R? __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Linux: /usr/shar/doc/R-2.0.1/*.pdf all have bad fonts (PR#7675)
Full_Name: Bruce Foster Version: 2.0.1 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 4) Submission from: (NULL) (129.105.110.38) All of the pdf files in /usr/share/doc/R-2.0.1 from the CRAN RedHat RPM have invalid fonts. A build from source yields the same problem. [EMAIL PROTECTED] R-2.0.1]# ll *.pdf -rw-r--r--1 root root 259886 Nov 19 10:50 R-FAQ.pdf -rw-r--r--1 root root 127067 Nov 19 10:50 R-admin.pdf -rw-r--r--1 root root 143761 Nov 19 10:50 R-data.pdf -rw-r--r--1 root root 374269 Nov 19 10:50 R-exts.pdf -rw-r--r--1 root root 435252 Nov 19 10:50 R-intro.pdf -rw-r--r--1 root root 268142 Nov 19 10:50 R-lang.pdf The files are unreadable with xpdf and acroread, and pdf2ps shows this: [EMAIL PROTECTED] R-2.0.1]# pdf2ps R-admin.pdf Error: /invalidfont in /F72 Operand stack: --dict:5/5(L)-- F72 20.659 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 2 1 29 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- --dict:92/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)-- --dict:19/24(L)-- --dict:4/6(L)-- --dict:23/31(L)-- Current allocation mode is local GNU Ghostscript 7.05: Unrecoverable error, exit code 1 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On Wed, 9 Feb 2005 00:02:53 +0100, Achim Zeileis [EMAIL PROTECTED] wrote: On Tue, 08 Feb 2005 22:19:46 - (GMT) (Ted Harding) wrote: On 08-Feb-05 Kurt Hornik wrote: Afaic, one of the issues is that it seems common practice to refer to collections of code as libraries or packages, and we're trying to use these rather general-purpose terms in a very precise meaning, and obviously not very successful, in particular because the use oflibrary is highly non-standard. One idea might be to replace thelibrary by something else like ... a place where R knows where to find packages ... hmm, now that's too long, so ... The only issue I have with library vs package (or vice versa) is the following. I *know* that a collection of functions etc. (such as nlme) is properly called a package. I could (and do) get ticked off if I refer to it as a library. However, if I want to use it then I enter library(nlme) As a result, the little daemons who potter around re-wiring my mental circuits sometimes cross-connect these two. As a result, I can inadvertently refer to the nlme library. An example is a recent mailing of mine to the list where I twice referred to a certain library (and was amiably rebuked by Martic Maechler) -- but then I saw that I had also twice referred to the same package in the same mail! Personally I don't mind whether it is called package or library, though using the command library() to load a package does tend, as described, to get me treading on my own shoelaces. But, a propos, is there an R entity called a library (other than the command) as distinct from a package? A *library* is a directory in which you can find R *packages* (just as in real life you can find books in a library) and with library(foo, lib.loc = /path/to/bar) you want to get the package (book) foo from the library bar located at /path/to/bar. So the two are really distinct...in real life, you also wouldn't say that you have been in the book where they had a lot of libraries on the shelves, would you? ;-) But as Kurt explained: this distinction between library and package is specific to R and does not correspond to common practice for other software systems. Z Sure, but I'm not specifying which library I'd like to get the packages from, thus it might be make perfect sense to say: loadPackage(foo,library=bar) But when I'm typing library, I'm loading a package, NOT specifying a library to use. Package is also confusing -- I keep thinking of it as a noun, as a package specifier, while others like it as a verb; this was a useful point for me that one person made. But perhaps then adding the verb (well, I can see the point against, but hear it out) might be useful. Thus, package(action,location,name) might be a useful function signature, though possibly not in that order. -- best, -tony Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes (AJR, 4Jan05). A.J. Rossini [EMAIL PROTECTED] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
A J Rossini writes: On Tue, 8 Feb 2005 23:05:20 + (GMT), Prof Brian Ripley [EMAIL PROTECTED] wrote: On Tue, 8 Feb 2005 [EMAIL PROTECTED] wrote: [...] But, a propos, is there an R entity called a library (other than the command) as distinct from a package? Yes. That is what the argument 'lib.loc' to library() and other functions refers to. A 'library' is a collection of packages stored in one directory. library(pkg) means `go to one or more libraries, find package pkg and load it up' And this is the problem, that the description doesn't clearly match the specification. One might easily expect that library(pkg) implies use library pkg for further package loading. It's almost too bad that libraries weren't books, with packages being chapters, or libraries being postOffices, with packages being packages, or packages being libraries, with libraries being cities or libraries being libraries, with packages being books. But the current mess wastes a good bit of time aggravating people who want things just so, responding to people who are just careless. As I wrote earlier, we need to have alternatives to change this. The R system is highly extensible through standardized add-ons called *packages*. That is one of its key strengths, and I don't think we should stop referring to packages as packages. Packages are made available by putting them into *libraries*, defined as places where R knows to find packages. If we do not like this term, we need a better one. Packages are loaded and attached using library(), which in principle is something for which a replacement is desired anyways. But as Brian and I [at least] said, we need not only a new name, but also a careful redesign, and someone taking charge. -k __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux: /usr/shar/doc/R-2.0.1/*.pdf all have bad fonts (PR#7675)
Please report this to the RPM provider: it is not true of R in general. This is the R bug repository, not the CRAN error address. On Wed, 9 Feb 2005 [EMAIL PROTECTED] wrote: Full_Name: Bruce Foster Version: 2.0.1 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 4) Submission from: (NULL) (129.105.110.38) All of the pdf files in /usr/share/doc/R-2.0.1 from the CRAN RedHat RPM have invalid fonts. A build from source yields the same problem. [EMAIL PROTECTED] R-2.0.1]# ll *.pdf -rw-r--r--1 root root 259886 Nov 19 10:50 R-FAQ.pdf -rw-r--r--1 root root 127067 Nov 19 10:50 R-admin.pdf -rw-r--r--1 root root 143761 Nov 19 10:50 R-data.pdf -rw-r--r--1 root root 374269 Nov 19 10:50 R-exts.pdf -rw-r--r--1 root root 435252 Nov 19 10:50 R-intro.pdf -rw-r--r--1 root root 268142 Nov 19 10:50 R-lang.pdf The files are unreadable with xpdf and acroread, and pdf2ps shows this: [EMAIL PROTECTED] R-2.0.1]# pdf2ps R-admin.pdf Error: /invalidfont in /F72 Operand stack: --dict:5/5(L)-- F72 20.659 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 2 1 29 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- --dict:92/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)-- --dict:19/24(L)-- --dict:4/6(L)-- --dict:23/31(L)-- Current allocation mode is local GNU Ghostscript 7.05: Unrecoverable error, exit code 1 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux: /usr/shar/doc/R-2.0.1/*.pdf all have bad fonts (PR#7677)
Please report this to the RPM provider: it is not true of R in general. This is the R bug repository, not the CRAN error address. On Wed, 9 Feb 2005 [EMAIL PROTECTED] wrote: Full_Name: Bruce Foster Version: 2.0.1 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 4) Submission from: (NULL) (129.105.110.38) All of the pdf files in /usr/share/doc/R-2.0.1 from the CRAN RedHat RPM have invalid fonts. A build from source yields the same problem. [EMAIL PROTECTED] R-2.0.1]# ll *.pdf -rw-r--r--1 root root 259886 Nov 19 10:50 R-FAQ.pdf -rw-r--r--1 root root 127067 Nov 19 10:50 R-admin.pdf -rw-r--r--1 root root 143761 Nov 19 10:50 R-data.pdf -rw-r--r--1 root root 374269 Nov 19 10:50 R-exts.pdf -rw-r--r--1 root root 435252 Nov 19 10:50 R-intro.pdf -rw-r--r--1 root root 268142 Nov 19 10:50 R-lang.pdf The files are unreadable with xpdf and acroread, and pdf2ps shows this: [EMAIL PROTECTED] R-2.0.1]# pdf2ps R-admin.pdf Error: /invalidfont in /F72 Operand stack: --dict:5/5(L)-- F72 20.659 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 2 1 29 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- --dict:92/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)-- --dict:19/24(L)-- --dict:4/6(L)-- --dict:23/31(L)-- Current allocation mode is local GNU Ghostscript 7.05: Unrecoverable error, exit code 1 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
