Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
On Tue, 19 Sep 2006 19:14:39 -0500,
Marc Schwartz (MS) wrote:
Hi all,
On FC5, using:
Version 2.3.1 Patched (2006-08-06 r38829)
and today's
R version 2.4.0 alpha (2006-09-19 r39397)
with the following .Rnw file:
\documentclass[10pt]{article}
\begin{document}
This line should print '2': \Sexpr{1 + 1}
%% This line should NOT print '2': \Sexpr{1 + 1}
\end{document}
The \Sexpr in the second line is processed even though the line is
commented. This results in the following .tex file content (in the case
of R 2.4.0):
\documentclass[10pt]{article}
\usepackage{/home/marcs/R.Files/SourceCode/R-alpha/share/texmf/Sweave}
\begin{document}
This line should print '2': 2
%% This line should NOT print '2': 2
\end{document}
Shouldn't Sweave just generally ignore commented LaTeX code? In
reviewing Sweave.R I did not see a check for this, so perhaps there are
circumstances where one wants a \Sexpr in commented LaTeX code
processed. An example escapes me at the moment however.
Sweave does not parse the LaTeX part of the document at all (which
makes it a lot easier), all it does is looking for its own magic
strings and replacing those, wherever they might occur.
If we would start to respect comments, we would need a some kind of
parser for LaTeX, which we currently don't need ... and starting to
parse LaTeX would also open a can of worms of possible requests (what
to do with Sexpr inside verbatim, etc, etc).
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
Friedrich Leisch [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006 19:14:39 -0500,
Marc Schwartz (MS) wrote:
Hi all,
On FC5, using:
Version 2.3.1 Patched (2006-08-06 r38829)
and today's
R version 2.4.0 alpha (2006-09-19 r39397)
with the following .Rnw file:
\documentclass[10pt]{article}
\begin{document}
This line should print '2': \Sexpr{1 + 1}
%% This line should NOT print '2': \Sexpr{1 + 1}
\end{document}
The \Sexpr in the second line is processed even though the line is
commented. This results in the following .tex file content (in the case
of R 2.4.0):
\documentclass[10pt]{article}
\usepackage{/home/marcs/R.Files/SourceCode/R-alpha/share/texmf/Sweave}
\begin{document}
This line should print '2': 2
%% This line should NOT print '2': 2
\end{document}
Shouldn't Sweave just generally ignore commented LaTeX code? In
reviewing Sweave.R I did not see a check for this, so perhaps there are
circumstances where one wants a \Sexpr in commented LaTeX code
processed. An example escapes me at the moment however.
Sweave does not parse the LaTeX part of the document at all (which
makes it a lot easier), all it does is looking for its own magic
strings and replacing those, wherever they might occur.
If we would start to respect comments, we would need a some kind of
parser for LaTeX, which we currently don't need ... and starting to
parse LaTeX would also open a can of worms of possible requests (what
to do with Sexpr inside verbatim, etc, etc).
..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
lines with % as the first character might be a viable compromise
though.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using \u2030 in plot axis label - stack smashing
On 19/09/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: Apparently FC6 will have different flags/ different default behaviour, at least for ld. Just for reference I have tested the default CFLAGS in FC-5 and FC-6. They are equal, namely: CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 this is common to all three supported archs, i386, x86_64 and ppc. (There is in addition an architecture specfic part after) Regarding the linker you are right as is discussed in the draft notes for FC6 release: http://fedora.redhat.com/docs/release-notes/fc6test2/#id3068132 -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mgcv in R-2.4.0.alpha
Kjetil == Kjetil Halvorsen [EMAIL PROTECTED] on Tue, 19 Sep 2006 16:56:24 -0400 writes: Kjetil Hola! Kjetil I am sending this to the list since emails from me to Simon Wood Kjetil has bounced earlier. Kjetil I get: library(tsDyn) Kjetil Loading required package: mgcv Kjetil Erro en `parent.env-`(`*tmp*`, value = NULL) : Kjetil use of NULL environment is defunct Kjetil Error: package 'mgcv' could not be loaded library(mgcv) Kjetil Erro en `parent.env-`(`*tmp*`, value = NULL) : Kjetil use of NULL environment is defunct Kjetil Error: package/namespace load failed for 'mgcv' Kjetil But in the package check summary on CRAN mgcv Kjetil gets OK. Yes, because it *is* ok. I'm pretty sure you are getting an old version of 'mgcv' instead of the correct one. Look at the result of ll - library() ll$res[ll$res[,1] == mgcv ,] sessionInfo() Kjetil R version 2.4.0 alpha (2006-09-16 r39365) Kjetil i386-pc-mingw32 Kjetil locale: Kjetil LC_COLLATE=Spanish_Bolivia.1252;LC_CTYPE=Spanish_Bolivia.1252;LC_MONETARY=Spanish_Bolivia.1252;LC_NUMERIC=C;LC_TIME=Spanish_Bolivia.1252 Kjetil attached base packages: Kjetil [1] methods stats graphics grDevices utils datasets Kjetil [7] base Kjetil Kjetil B Halvorsen Kjetil [[alternative HTML version deleted]] ^ (I thought you would know better ...) Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mgcv in R-2.4.0.alpha
On 9/20/06, Martin Maechler [EMAIL PROTECTED] wrote: . . . Kjetil [[alternative HTML version deleted]] ^ (I thought you would know better ...) Martin In theory, yes, but I did´nt find a way to stop the html version to be sent im gmail. Before I sent from gmail via thunderbird, now, sending from a lot of different machines, that is not practicable. Anybody knows how to tell gmail? Kjetil [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mgcv in R-2.4.0.alpha
Hola! See comments inline. On 9/20/06, Martin Maechler [EMAIL PROTECTED] wrote: Kjetil == Kjetil Halvorsen [EMAIL PROTECTED] on Tue, 19 Sep 2006 16:56:24 -0400 writes: Kjetil Hola! Kjetil I am sending this to the list since emails from me to Simon Wood Kjetil has bounced earlier. Kjetil I get: library(tsDyn) Kjetil Loading required package: mgcv Kjetil Erro en `parent.env-`(`*tmp*`, value = NULL) : Kjetil use of NULL environment is defunct Kjetil Error: package 'mgcv' could not be loaded library(mgcv) Kjetil Erro en `parent.env-`(`*tmp*`, value = NULL) : Kjetil use of NULL environment is defunct Kjetil Error: package/namespace load failed for 'mgcv' Kjetil But in the package check summary on CRAN mgcv Kjetil gets OK. Yes, because it *is* ok. I'm pretty sure you are getting an old version of 'mgcv' instead of the correct one. I will investigate when I get my machine back from the technician! But I wrote this after having done a complete update.packages. However, my package on CRAN SenSrivastava passes all the daily checks on CRAN, not even a warning, but when running the checks on my computer I get a warning. (planned to fix this week) Kjetil Look at the result of ll - library() ll$res[ll$res[,1] == mgcv ,] sessionInfo() Kjetil R version 2.4.0 alpha (2006-09-16 r39365) Kjetil i386-pc-mingw32 Kjetil locale: Kjetil LC_COLLATE=Spanish_Bolivia.1252;LC_CTYPE=Spanish_Bolivia.1252;LC_MONETARY=Spanish_Bolivia.1252;LC_NUMERIC=C;LC_TIME=Spanish_Bolivia.1252 Kjetil attached base packages: Kjetil [1] methods stats graphics grDevices utils datasets Kjetil [7] base Kjetil Kjetil B Halvorsen Kjetil [[alternative HTML version deleted]] ^ (I thought you would know better ...) Martin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
On Wed, 2006-09-20 at 12:20 +0200, Peter Dalgaard wrote:
Friedrich Leisch [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006 19:14:39 -0500,
Marc Schwartz (MS) wrote:
Hi all,
On FC5, using:
Version 2.3.1 Patched (2006-08-06 r38829)
and today's
R version 2.4.0 alpha (2006-09-19 r39397)
with the following .Rnw file:
\documentclass[10pt]{article}
\begin{document}
This line should print '2': \Sexpr{1 + 1}
%% This line should NOT print '2': \Sexpr{1 + 1}
\end{document}
The \Sexpr in the second line is processed even though the line is
commented. This results in the following .tex file content (in the case
of R 2.4.0):
\documentclass[10pt]{article}
\usepackage{/home/marcs/R.Files/SourceCode/R-alpha/share/texmf/Sweave}
\begin{document}
This line should print '2': 2
%% This line should NOT print '2': 2
\end{document}
Shouldn't Sweave just generally ignore commented LaTeX code? In
reviewing Sweave.R I did not see a check for this, so perhaps there are
circumstances where one wants a \Sexpr in commented LaTeX code
processed. An example escapes me at the moment however.
Sweave does not parse the LaTeX part of the document at all (which
makes it a lot easier), all it does is looking for its own magic
strings and replacing those, wherever they might occur.
If we would start to respect comments, we would need a some kind of
parser for LaTeX, which we currently don't need ... and starting to
parse LaTeX would also open a can of worms of possible requests (what
to do with Sexpr inside verbatim, etc, etc).
..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
lines with % as the first character might be a viable compromise
though.
Fritz and Peter,
Thanks for your replies.
First, for some context on what I was doing.
I have a large .Rnw file and was in the process of doing some debugging.
I had set some R chunks to 'eval=false' in the process. This resulted in
some R objects not being created that were in turn used in the
subsequent \Sexpr's.
Thus, using (C-c ;) in emacs/auctex to comment some blocks of LaTeX
code, I then ran Sweave and of course noted errors which I tracked down
to the evaluation of the (presumably) commented \Sexpr's.
I think that Peter's approach would be a reasonable option, at least in
this scenario and perhaps others, without getting into the need to parse
the LaTeX code for '%'s preceding a '\Sexpr'. This would, I believe,
require modifying the current 'docexpr' regex's in Sweave.R.
An alternative of sorts, would be to add another Sweave option,
something like:
\SweaveOpts{eval.Sexpr=false}
which could be placed prior to a section where one wanted to disable the
evaluation of Sexpr's and then re-enable it with a:
\SweaveOpts{eval.Sexpr=true}
at a subsequent point in the .Rnw file.
The option would of course default to 'true'. This would make the
solution more global and again not require the need to parse the LaTeX
code.
Food for thought.
Best regards,
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
Peter Dalgaard [EMAIL PROTECTED] writes:
..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
lines with % as the first character might be a viable compromise
though.
+1. You could probably ignore any lines where the first
non-whitespace char is '%'. But if that seems to risky, then only
recognizing first-char-is-% seems a worthwhile heuristic.
Another place where this has bitten people is when they do:
%\usepackage{Sweave}
Sweave picks that up and doesn't insert the usepackage line itself.
So ignoring LaTeX comment lines would solve two problems.
Best,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] seq.Date not accepting NULL length.out (PR#9239)
There seems to be a bug in seq.Date such that it will not allow the user
to pass in length.out =3D NULL, despite the fact that this is the =
default
argument.
For example:
dt1 - as.Date(2004-12-31)
dt2 - as.Date(2005-12-31)
seq.Date(dt1, dt2, length.out =3D NULL, by =3D month)
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1
This might be an issue if I want to wrap seq.Date in another function
that reports or modifies on length.out. For instance, suppose I want to
create a simple function that simply reports when length.out is NULL (or
missing), as below, but otherwise works identically to seq.Date.
FUN - function(to, from, length.out =3D NULL, by, ...) {
if (is.null(length.out)) cat(length.out is missing\n)
seq.Date(to, from, length.out =3D length.out, by =3D by, ...)
}
seq.Date(dt1, dt2, by =3D month)
[1] 2004-12-31 2005-01-31 2005-03-03 2005-03-31 2005-05-01
[6] 2005-05-31 2005-07-01 2005-07-31 2005-08-31 2005-10-01
[11] 2005-10-31 2005-12-01 2005-12-31
FUN(dt1, dt2, by =3D month)
length.out is missing
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1
I believe the patch to fix this error is as follows (on R2.4.0(alpha)
Revision 39430)
- } else if (!missing(length.out)) {
+ } else if (!missing(length.out) !is.null(length.out)) {
Another (perhaps better) patch would be to not have NULL be the default
for length.out.
HTH,
Robert
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended for us...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
2006/9/20, Seth Falcon [EMAIL PROTECTED]:
Peter Dalgaard [EMAIL PROTECTED] writes:
..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
lines with % as the first character might be a viable compromise
though.
+1. You could probably ignore any lines where the first
non-whitespace char is '%'. But if that seems to risky, then only
recognizing first-char-is-% seems a worthwhile heuristic.
Another place where this has bitten people is when they do:
%\usepackage{Sweave}
Sweave picks that up and doesn't insert the usepackage line itself.
I've found that extremely useful for sweaving Stex files which aren't
master files (i.e., only files to include in a main latex file).
Inserting '\usepackage{Sweave}' in each would result in a latex error.
So commenting it out is a useful workaround.
Antonio.
So ignoring LaTeX comment lines would solve two problems.
Best,
+ 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
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
Antonio, Fabio Di Narzo [EMAIL PROTECTED] writes:
2006/9/20, Seth Falcon [EMAIL PROTECTED]:
Peter Dalgaard [EMAIL PROTECTED] writes:
..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
lines with % as the first character might be a viable compromise
though.
+1. You could probably ignore any lines where the first
non-whitespace char is '%'. But if that seems to risky, then only
recognizing first-char-is-% seems a worthwhile heuristic.
Another place where this has bitten people is when they do:
%\usepackage{Sweave}
Sweave picks that up and doesn't insert the usepackage line itself.
I've found that extremely useful for sweaving Stex files which aren't
master files (i.e., only files to include in a main latex file).
Inserting '\usepackage{Sweave}' in each would result in a latex error.
So commenting it out is a useful workaround.
Commenting it out _and_ having Sweave see it?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq.Date not accepting NULL length.out (PR#9239)
On 9/20/2006 11:43 AM, [EMAIL PROTECTED] wrote:
There seems to be a bug in seq.Date such that it will not allow the user
to pass in length.out =3D NULL, despite the fact that this is the =
default
argument.
Yes, that's a bug: the test is is.missing, when it should be
is.null. I'll fix it. Thanks!
Duncan Murdoch
For example:
dt1 - as.Date(2004-12-31)
dt2 - as.Date(2005-12-31)
seq.Date(dt1, dt2, length.out =3D NULL, by =3D month)
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1
This might be an issue if I want to wrap seq.Date in another function
that reports or modifies on length.out. For instance, suppose I want to
create a simple function that simply reports when length.out is NULL (or
missing), as below, but otherwise works identically to seq.Date.
FUN - function(to, from, length.out =3D NULL, by, ...) {
if (is.null(length.out)) cat(length.out is missing\n)
seq.Date(to, from, length.out =3D length.out, by =3D by, ...)
}
seq.Date(dt1, dt2, by =3D month)
[1] 2004-12-31 2005-01-31 2005-03-03 2005-03-31 2005-05-01
[6] 2005-05-31 2005-07-01 2005-07-31 2005-08-31 2005-10-01
[11] 2005-10-31 2005-12-01 2005-12-31
FUN(dt1, dt2, by =3D month)
length.out is missing
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1
I believe the patch to fix this error is as follows (on R2.4.0(alpha)
Revision 39430)
- } else if (!missing(length.out)) {
+ } else if (!missing(length.out) !is.null(length.out)) {
Another (perhaps better) patch would be to not have NULL be the default
for length.out.
HTH,
Robert
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended for us...{{dropped}}
__
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] residual '*tmp*' variable after [- error
self-sanity check prior to filing a bug report: attempted replacement that generates an error leaves a '*tmp*' variable in the global environment. test - 1:10 test[2:4] - expression(e) ls() i've read section 3.4.4 of the R Language Definition which discusses the mechanism for replacement, and it is not clear to me whether this was intended, but i suspect not (to be honest, it's not clear to me why the process as described doesn't generate an infinite recursion -- perhaps the primitive treats the argument named '*tmp*' different than other arguments). i've also searched the R site, and can't find this particular issue discussed. even though, as below, i am using 2.4.0 alpha, this happens as well in 2.3.1. from my standpoint, desirable behavior would be: (i) if an error occurs, remove the '*tmp*' variable (ii) report the error as occurring in the original replacement call (rather than the '*tmp*' replacement, which may be confusing to those who haven't read the R Language Definition) franklin parlamis version _ platform powerpc-apple-darwin8.7.0 arch powerpc os darwin8.7.0 system powerpc, darwin8.7.0 status alpha major 2 minor 4.0 year 2006 month 09 day06 svn rev39158 language R version.string R version 2.4.0 alpha (2006-09-06 r39158) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] alpha, portable use
When I build one of my packages with alpha from yesterday I am getting
* checking for portable use of $BLAS_LIBS ... WARNING
apparently missing $(FLIBS) in 'PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)'
Is this something I should worry about? (Possibly I got this before and
didn't notice.)
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] alpha, portable use
On Wed, 20 Sep 2006, Paul Gilbert wrote: When I build one of my packages with alpha from yesterday I am getting * checking for portable use of $BLAS_LIBS ... WARNING apparently missing $(FLIBS) in 'PKG_LIBS=$(LAPACK_LIBS) $(BLAS_LIBS)' Is this something I should worry about? (Possibly I got this before and didn't notice.) Yes, please do check Writing R Extensions -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] residual '*tmp*' variable after [- error
On Wed, 20 Sep 2006, Parlamis Franklin wrote: self-sanity check prior to filing a bug report: attempted replacement that generates an error leaves a '*tmp*' variable in the global environment. test - 1:10 test[2:4] - expression(e) ls() i've read section 3.4.4 of the R Language Definition which discusses the mechanism for replacement, and it is not clear to me whether this was intended, but i suspect not (to be honest, it's not clear to me why the process as described doesn't generate an infinite recursion -- perhaps the primitive treats the argument named '*tmp*' different than other arguments). i've also searched the R site, and can't find this particular issue discussed. even though, as below, i am using 2.4.0 alpha, this happens as well in 2.3.1. from my standpoint, desirable behavior would be: (i) if an error occurs, remove the '*tmp*' variable That's a bug: it need a context set to clean up. (ii) report the error as occurring in the original replacement call (rather than the '*tmp*' replacement, which may be confusing to those who haven't read the R Language Definition) But by that point the call may have been transformed quite dramatically. I was going to suggest traceback() would give you a sensible call, but in this case it is not doing so: at a quick glance that is also due to no context being set. There is also the question as to whether this should have worked. It probably could be made to do so as test - as.expression(test) test[2:4] - expression(e) -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A Call for a Smaller R Core Package
(Below is my idea on an issue that has troubled me for a fairly long time. I hope it's not viewed as trouble making.) A Call for a Smaller R Core Package This document suggests downsizing the 'core' package of R by taking out some specialized functionalities to form their own packages. I'll use string related functions as examples, because I happened to be troubled by them today. 1. The core is too big R is a function rich environment. However, non-central functions are better organized in specialized packages. From time to time I felt the need to go through the core package for a complete picture of what are there at my disposal, yet so far I haven't done that. In the 'R Reference Manual' the core package runs for over 400 pages with about 400 entries, and mysteriously some functions don't show up in the TOC, e.g. 'sub'. In the two-volume reference set printed by Network-Theory, the core is the entire first book. In contrast, the 'Intrinsic Functions' chapter of the classic Fortran reference Fortran 95/2003 Explained runs for maybe 30(?) pages. I flipped through it many times and I can say with confidence, OK these are ALL the Fortran intrinsics and I know what they do. For R, I found it an intimidating task to flip through the 400+ pages core and retain a clear mind at the end. Below is a random sample of string related functions in the core package: agrep basename charmatch chartr gregexpr grep gsub regex regexpr strsplit strtrim strwrap sub In my opinion, anything that uses regular expressions belongs somewhere else. Even 'utils' seems to be a better place for random items than the 'core'. 2. Benefits of a smaller core a) A smaller core will be more carefully studied and better appreciated. If the R core functions were documented in 100 pages, I would be a much better R programmer than I am today because I would have singled out and studied the more fundamental routines about function calls, etc. The criteria for a function to be in the core seem to be: 1) fundamental; or 2) very often used. A smaller core is more stable. b) A specialized 'string' package makes string related functions much easier to find. It could be that I still need all the functions. But since they are grouped together, it greatly helps learning. I would be very rarely reinventing the wheel, because I could quickly get a sweeping view of the dedicated package. c) It will be easier to enrich string-related functionalities without perplexing the core. 3. Costs of such re-arrangements a) To the R development team (I don't really know.) For those utility functions that are frequently used in basic functions, they may well stay in the core. For those that are not, it may not be too difficult to move them around. The spin-off package may be always automatically loaded as a basic one, but as discussed above, a cleaning grouping greatly helps learning and finding things. b) To R users The system (both the core and the specialized package) will be easier to learn and use. -- Zepu Zhang, [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
