Re: [Rd] R_PAPERSIZE and LC_PAPER
On Thu, 2006-04-20 at 20:56 +0100, Prof Brian Ripley wrote:
> On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
>
> > Roger,
> >
> > Thanks.
> >
> > Yes, this I know. In fact I have a line in my shell script for building
> > R[-patched]:
> >
> > ./configure R_PAPERSIZE=letter
> >
> >
> > R_PAPERSIZE is document in several places, however R_PAPERSIZE_DEFAULT
> > is not, unless I am going blind in my middle age... :-)
>
> It does not exist in any system at present (not even mine): just an idea
> in my head to represent the default found at configure time.
>
> In some sense LC_PAPER is set on FC3:
>
> gannet% locale -ck LC_PAPER
> LC_PAPER
> height=297
> width=210
> paper-codeset="ISO-8859-1"
>
> and it is unsupported on Solaris 8. And
>
> > Sys.getlocale("LC_PAPER")
> [1] "en_GB"
>
> in the system I am prototyping just now.
>
> Brian
OK...so as I surmised below, R_PAPERSIZE_DEFAULT is part of the proposed
change. Makes sense.
BTW, on my FC4 system:
$ locale -ck LC_PAPER
LC_PAPER
height=279
width=216
paper-codeset="UTF-8"
However, as I note below LC_ALL is unset:
$ locale -ck LC_ALL
$
Googling seems to be somewhat inconclusive as to the default use of
LC_ALL, but it is clearly used/set in some locales and by some
applications.
However, the official POSIX definition is:
LC_ALL
This variable shall determine the values for all locale
categories. The value of the LC_ALL environment variable has
precedence over any of the other environment variables starting
with LC_ ( LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY ,
LC_NUMERIC , LC_TIME ) and the LANG environment variable.
Consistent with some comments that I found, it seems to suggest that
LC_ALL can serve as something of an override relative to the other LC_*
variables.
This position would support an argument that if set, it would override
the logic below as a system default, perhaps and unless R_PAPERSIZE is
set in the site or user profile.
Thus, a possible hierarchy of precedence from high to low might be:
R_PAPERSIZE
LC_ALL
LC_PAPER
R_PAPERSIZE_DEFAULT
Thoughts?
Regards,
Marc
> > On Thu, 2006-04-20 at 14:44 -0400, Roger D. Peng wrote:
> >> Papersize can be set at compile time in the 'config.site' file
> >> (R_PAPERSIZE).
> >>
> >> -roger
> >>
> >> Marc Schwartz (via MN) wrote:
> >>> Prof. Ripley,
> >>>
> >>> Happy to help.
> >>>
> >>> So, it sounds like we are thinking along the same lines then.
> >>>
> >>> A couple of follow up questions:
> >>>
> >>> 1. Is R_PAPERSIZE_DEFAULT to be the proposed new compile time setting in
> >>> 2.4.0? Unless I missed it, I did not see it documented anywhere (ie.
> >>> R-admin/NEWS for 2.2.1 patched or 2.3.0 devel) and it is not in the
> >>> configure related files that I have here.
> >>>
> >>> 2. For LC_ALL, it is not set (at least on my FC4 system, have not had
> >>> the time yet to go to FC5) in en_US.UTF-8. Is it set in other locales
> >>> such that it would be of value?
> >>>
> >>>
> >>> Thanks also for the pointer to the devel guidelines. I had read through
> >>> them at some point in the past, but it has been a while.
> >>>
> >>> Regards,
> >>>
> >>> Marc
> >>>
> >>> On Thu, 2006-04-20 at 18:48 +0100, Prof Brian Ripley wrote:
> Marc,
>
> Thanks for the comments. The 2.3.x series is in feature freeze, and
> although a few features do break though for patch releases, they had
> better be `badly needed' see
> http://developer.r-project.org/devel-guidelines.txt).
>
> So I was thinking of 2.4.0.
>
> My suggestion was going to be along the lines of
>
> local({
> papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
> if(!nchar(papersize)) {
> lcpaper <- Sys.getlocale("LC_PAPER")
> if(nchar(lcpaper))
> papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
> else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
> }
> options(papersize = papersize)
> })
>
> This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
> its value takes precedence over the compile-time default. That's almost
> exactly equivalent to what happens on Windows (which sets LC_MONETARY for
> this purpose, as LC_PAPER is not a locale category there).
>
> Now, one could argue that if LC_PAPER is unset it should default to
> LC_ALL, but I think is less desirable.
>
> Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
> that's part of the TODO.
>
> Brian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
On Apr 20, 2006, at 1:23 PM, Henrik Bengtsson (max 7Mb) wrote: > Is it a general consensus on R-devel that *.tar.gz distributions > should only be treated as a distribution for *building* packages > and not for developing them? I don't know whether this is a general consensus, but it definitely an important distinction. Some authors put their own Makefiles in src although they are not needed and in fact harmful, preventing the package to build on other systems - only because they are too lazy to use R building mechanism for development and don't make the above distinction. I'm not saying anything about make check here - my point is that tar- balls and development sources are definitely two separate concepts. For simple packages it may be possible to just tar-up the development sources, but that's rather a special case. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_PAPERSIZE and LC_PAPER
On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
> Roger,
>
> Thanks.
>
> Yes, this I know. In fact I have a line in my shell script for building
> R[-patched]:
>
> ./configure R_PAPERSIZE=letter
>
>
> R_PAPERSIZE is document in several places, however R_PAPERSIZE_DEFAULT
> is not, unless I am going blind in my middle age... :-)
It does not exist in any system at present (not even mine): just an idea
in my head to represent the default found at configure time.
In some sense LC_PAPER is set on FC3:
gannet% locale -ck LC_PAPER
LC_PAPER
height=297
width=210
paper-codeset="ISO-8859-1"
and it is unsupported on Solaris 8. And
> Sys.getlocale("LC_PAPER")
[1] "en_GB"
in the system I am prototyping just now.
Brian
>
> Regards,
>
> Marc
>
> On Thu, 2006-04-20 at 14:44 -0400, Roger D. Peng wrote:
>> Papersize can be set at compile time in the 'config.site' file (R_PAPERSIZE).
>>
>> -roger
>>
>> Marc Schwartz (via MN) wrote:
>>> Prof. Ripley,
>>>
>>> Happy to help.
>>>
>>> So, it sounds like we are thinking along the same lines then.
>>>
>>> A couple of follow up questions:
>>>
>>> 1. Is R_PAPERSIZE_DEFAULT to be the proposed new compile time setting in
>>> 2.4.0? Unless I missed it, I did not see it documented anywhere (ie.
>>> R-admin/NEWS for 2.2.1 patched or 2.3.0 devel) and it is not in the
>>> configure related files that I have here.
>>>
>>> 2. For LC_ALL, it is not set (at least on my FC4 system, have not had
>>> the time yet to go to FC5) in en_US.UTF-8. Is it set in other locales
>>> such that it would be of value?
>>>
>>>
>>> Thanks also for the pointer to the devel guidelines. I had read through
>>> them at some point in the past, but it has been a while.
>>>
>>> Regards,
>>>
>>> Marc
>>>
>>> On Thu, 2006-04-20 at 18:48 +0100, Prof Brian Ripley wrote:
Marc,
Thanks for the comments. The 2.3.x series is in feature freeze, and
although a few features do break though for patch releases, they had
better be `badly needed' see
http://developer.r-project.org/devel-guidelines.txt).
So I was thinking of 2.4.0.
My suggestion was going to be along the lines of
local({
papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
if(!nchar(papersize)) {
lcpaper <- Sys.getlocale("LC_PAPER")
if(nchar(lcpaper))
papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
}
options(papersize = papersize)
})
This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
its value takes precedence over the compile-time default. That's almost
exactly equivalent to what happens on Windows (which sets LC_MONETARY for
this purpose, as LC_PAPER is not a locale category there).
Now, one could argue that if LC_PAPER is unset it should default to
LC_ALL, but I think is less desirable.
Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
that's part of the TODO.
Brian
On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
> On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote:
>> R uses the environment variable R_PAPERSIZE to set its papersize, e.g.
>> for
>> postscript.
>>
>> It seems the modern way is to via LC_PAPER, e.g.
>>
>> http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html
>>
>> and Googling will show that people expect this to work.
>>
>> However, that is not set on my FC3 system, and it would affect people who
>> use en_US as their locale in, say, Austria.
>>
>> Should we be making use of LC_PAPER, or would it just cause further
>> complications? (On Windows, the locale name is used to set the default
>> papersize, but there it is unlikely to be set inappropriately.)
>
> Here's my 0.0162 Euros (at current conversion rates):
>
> For R 2.4.0, announce that LC_PAPER will become the default environment
> variable used to set the default R papersize and then not set
> R_PAPERSIZE by default (ie. in build scripts, etc.)
>
> However, If someone sets R_PAPERSIZE in their site or local profile,
> this will supercede the LC_PAPER setting. This would allow for a R
> setting that may need to be different than the system default.
>
> Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and
> time to consider the impact on their local installations and code, while
> enabling future users to take advantage of the standard.
>
> I think that in general, R should abide by published standards unless
> there are very compelling reasons not to.
>
> HTH,
>
> Marc Schwartz
>
>
>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
>
--
Brian D. Ripley,
Re: [Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
One thing which I personally disagree with is that the procedure for
the check is different when run on a directory than on a tarball (I
am talking about the defaults here, I now know I can change it
locally). I could understand the difference if the check resulted in
an _error_ such that I would be unable to install the package if I
have eg. object files in the src directory.
I did the original checking for the package Jim (the OP) referred to,
and I did expect that since it passed R CMD check (on my svn checkout
directory), everything would be fine (this was with R-beta from
Sunday). It was a bit of a surprise for me to learn that there was
differences.
This is a case where I fail to see the advantage of the default
settings, and I do see some disadvantages. But probably not important
enough for R-2.3.0.
/Kasper
On Apr 20, 2006, at 12:40 PM, Prof Brian Ripley wrote:
> On Thu, 20 Apr 2006, Robert Gentleman wrote:
>
>> Hi,
>>
>> Well, I guess if someone thinks they know how I am going to
>> configure and
>> build the sources needed to construct appropriate dynamic
>> libraries so well
>> that they can feel free to exclude files at their whim at install
>> time,
>> perhaps they could feel just as free to exclude them at build time?
>
> The checks are different if there is a configure file:
>
>Further, the check on the @file{src} directory is only run if the
>package/bundle does not contain a @file{configure} script (which
>corresponds to the value @samp{yes-maybe}) and there is no
>@file{src/Makefile} or @file{src/Makefile.in}.
>> This makes no sense to me and certainly does not solve the size
>> problem
>> mentioned by Brian. If there is a single example of something that
>> was better
>> this way, I would be interested to hear it. I can think of several
>> things
>> that are worse.
>
> We found several examples with large and unnecessary files in the src
> directory via this check, as well as files in directories other
> than the
> ones the package author had intended.
>
> It `makes no sense to me' to discuss situations that are not as
> implemented. This was discussed some months ago, ideas trialled
> and those
> that were found worthwhile retained. And now we are in code freeze.
>
>>
>> best wishes
>> Robert
>>
>>
>> Roger Bivand wrote:
>>> On Thu, 20 Apr 2006, Robert Gentleman wrote:
>>>
>>>
I disagree, things like README files and other objects are
important and
should be included. I don't see the real advantage to such
warnings, if
someone wants them they could be turned on optionally.
>
> Well, they are turned on optionally, but as the CRAN maintainers
> want them, submitters to CRAN ought to be aware that they will be run.
>
>
>>> Isn't the point at least partly that all those files are lost on
>>> installation? If the README is to be accessible after
>>> installation, it can
>>> be placed under inst/, so that both users reading the source and
>>> installed
>>> versions can access it. So maybe the warning could be re-phrased
>>> to suggest
>>> use of the inst/ tree for files with important content?
>>>
>>> Best wishes,
>>>
>>> Roger
>>>
>>>
If size is an issue then authors should be warned that their
package is
large (in the top 1% at CRAN would be useful to some). I also
find it
helpful to know whose packages take forever to build, which we
don't do.
Just because someone put something in TFM doesn't mean it is
either a good
idea or sensible, in my experience.
best wishes
Robert
Prof Brian Ripley wrote:
> On Wed, 19 Apr 2006, James Bullard wrote:
>
>
>
>> Hello, I am having an issue with R CMD check with the nightly
>> build of
>> RC 2.3.0 (listed in the subject.)
>
>
> This is all explained in TFM, `Writing R Extensions'.
>
>
>
>> The problem is this warning:
>>
>> * checking if this is a source package ... WARNING
>> Subdirectory 'src' contains:
>> README _Makefile
>> These are unlikely file names for src files.
>>
>> In fact, they are not source files, but I do not see any
>> reason why they
>> cannot be there, or why I need to be warned of their presence.
>> Potentially I could be informed of their presence, but that is
>> another
>> matter.
>
>
> Having unnecessary files in other people's packages just waste
> space and
> download bandwidth for each one of the users.
>
>
>
>> Now, I only get this warning when I do:
>>
>> R CMD build affxparser
>> R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz
>>
>> If I do:
>>
>> R CMD check -l ~/R-packages affxparser
>>
>> I do not get the warning. Is this inconsistent, or is there
>> rationale
>> behind this? I think the warning is inappropriate, or at the
>> least a
Re: [Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
On Thu, 20 Apr 2006, Robert Gentleman wrote:
> Hi,
>
> Well, I guess if someone thinks they know how I am going to configure and
> build the sources needed to construct appropriate dynamic libraries so well
> that they can feel free to exclude files at their whim at install time,
> perhaps they could feel just as free to exclude them at build time?
The checks are different if there is a configure file:
Further, the check on the @file{src} directory is only run if the
package/bundle does not contain a @file{configure} script (which
corresponds to the value @samp{yes-maybe}) and there is no
@file{src/Makefile} or @file{src/Makefile.in}.
> This makes no sense to me and certainly does not solve the size problem
> mentioned by Brian. If there is a single example of something that was better
> this way, I would be interested to hear it. I can think of several things
> that are worse.
We found several examples with large and unnecessary files in the src
directory via this check, as well as files in directories other than the
ones the package author had intended.
It `makes no sense to me' to discuss situations that are not as
implemented. This was discussed some months ago, ideas trialled and those
that were found worthwhile retained. And now we are in code freeze.
>
> best wishes
> Robert
>
>
> Roger Bivand wrote:
>> On Thu, 20 Apr 2006, Robert Gentleman wrote:
>>
>>
>>> I disagree, things like README files and other objects are important and
>>> should be included. I don't see the real advantage to such warnings, if
>>> someone wants them they could be turned on optionally.
Well, they are turned on optionally, but as the CRAN maintainers
want them, submitters to CRAN ought to be aware that they will be run.
>> Isn't the point at least partly that all those files are lost on
>> installation? If the README is to be accessible after installation, it can
>> be placed under inst/, so that both users reading the source and installed
>> versions can access it. So maybe the warning could be re-phrased to suggest
>> use of the inst/ tree for files with important content?
>>
>> Best wishes,
>>
>> Roger
>>
>>
>>> If size is an issue then authors should be warned that their package is
>>> large (in the top 1% at CRAN would be useful to some). I also find it
>>> helpful to know whose packages take forever to build, which we don't do.
>>>
>>> Just because someone put something in TFM doesn't mean it is either a good
>>> idea or sensible, in my experience.
>>>
>>> best wishes
>>> Robert
>>>
>>>
>>> Prof Brian Ripley wrote:
>>>
On Wed, 19 Apr 2006, James Bullard wrote:
> Hello, I am having an issue with R CMD check with the nightly build of
> RC 2.3.0 (listed in the subject.)
This is all explained in TFM, `Writing R Extensions'.
> The problem is this warning:
>
> * checking if this is a source package ... WARNING
> Subdirectory 'src' contains:
> README _Makefile
> These are unlikely file names for src files.
>
> In fact, they are not source files, but I do not see any reason why they
> cannot be there, or why I need to be warned of their presence.
> Potentially I could be informed of their presence, but that is another
> matter.
Having unnecessary files in other people's packages just waste space and
download bandwidth for each one of the users.
> Now, I only get this warning when I do:
>
> R CMD build affxparser
> R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz
>
> If I do:
>
> R CMD check -l ~/R-packages affxparser
>
> I do not get the warning. Is this inconsistent, or is there rationale
> behind this? I think the warning is inappropriate, or at the least a
> little restrictive. It seems as if I should be able to put whatever I
> want in there, especially the _Makefile as I like to build test programs
> directly and I want to be able to build exactly what I check out from
> my source code repository without having to copy files in and out.
All described in TFM, including how to set defaults for what is checked.
> The output from R CMD check is below. Any insight would be appreciated.
> As always thanks for your patience.
[...]
>>>
>>>
>>
>
>
--
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] Typo in R-devel assign.Rd
On Thu, 2006-04-20 at 15:08 -0400, Duncan Murdoch wrote:
> On 4/20/2006 2:47 PM, Marc Schwartz (via MN) wrote:
> > Hi all,
> >
> > I had mentioned this as a PS in a recent prior post on r-help on the use
> > of assign(), but presumably it got buried in the noise.
>
> Noise? I didn't hear anything...
>
> I'll fix this.
>
> Duncan Murdoch
Thanks Duncan.
Well, the S/N ratio on the list is generally pretty high... ;-)
Regards,
Marc
> >
> > There is a typo in the R-patched and R-devel versions of assign.Rd in
> > the first example comments.
> >
> > It is presently:
> >
> > #-- Create objects 'r1', 'r2', ... 'r6' --
> >
> > Note the line where paste() is used in the example is:
> >
> > nam <- paste("r",i, sep=".") # Note 'sep'
> >
> >
> > Hence, the comment should be:
> >
> > #-- Create objects 'r.1', 'r.2', ... 'r.6' --
> >
> > I have attached a text file containing the patch against today's r-devel
> > tarball version of assign.Rd.
> >
> > HTH,
> >
> > Marc Schwartz
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
Hi, Well, I guess if someone thinks they know how I am going to configure and build the sources needed to construct appropriate dynamic libraries so well that they can feel free to exclude files at their whim at install time, perhaps they could feel just as free to exclude them at build time? This makes no sense to me and certainly does not solve the size problem mentioned by Brian. If there is a single example of something that was better this way, I would be interested to hear it. I can think of several things that are worse. best wishes Robert Roger Bivand wrote: > On Thu, 20 Apr 2006, Robert Gentleman wrote: > > >>I disagree, things like README files and other objects are important and >>should be included. I don't see the real advantage to such warnings, if >>someone wants them they could be turned on optionally. > > > Isn't the point at least partly that all those files are lost on > installation? If the README is to be accessible after installation, it can > be placed under inst/, so that both users reading the source and installed > versions can access it. So maybe the warning could be re-phrased to > suggest use of the inst/ tree for files with important content? > > Best wishes, > > Roger > > >>If size is an issue then authors should be warned that their package is >>large (in the top 1% at CRAN would be useful to some). I also find it >>helpful to know whose packages take forever to build, which we don't do. >> >>Just because someone put something in TFM doesn't mean it is either a >>good idea or sensible, in my experience. >> >>best wishes >> Robert >> >> >>Prof Brian Ripley wrote: >> >>>On Wed, 19 Apr 2006, James Bullard wrote: >>> >>> >>> Hello, I am having an issue with R CMD check with the nightly build of RC 2.3.0 (listed in the subject.) >>> >>> >>>This is all explained in TFM, `Writing R Extensions'. >>> >>> >>> The problem is this warning: * checking if this is a source package ... WARNING Subdirectory 'src' contains: README _Makefile These are unlikely file names for src files. In fact, they are not source files, but I do not see any reason why they cannot be there, or why I need to be warned of their presence. Potentially I could be informed of their presence, but that is another matter. >>> >>> >>>Having unnecessary files in other people's packages just waste space and >>>download bandwidth for each one of the users. >>> >>> >>> Now, I only get this warning when I do: R CMD build affxparser R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz If I do: R CMD check -l ~/R-packages affxparser I do not get the warning. Is this inconsistent, or is there rationale behind this? I think the warning is inappropriate, or at the least a little restrictive. It seems as if I should be able to put whatever I want in there, especially the _Makefile as I like to build test programs directly and I want to be able to build exactly what I check out from my source code repository without having to copy files in and out. >>> >>> >>>All described in TFM, including how to set defaults for what is checked. >>> >>> >>> The output from R CMD check is below. Any insight would be appreciated. As always thanks for your patience. >>> >>> >>>[...] >>> >>> >> >> > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo in R-devel assign.Rd
On 4/20/2006 2:47 PM, Marc Schwartz (via MN) wrote:
> Hi all,
>
> I had mentioned this as a PS in a recent prior post on r-help on the use
> of assign(), but presumably it got buried in the noise.
Noise? I didn't hear anything...
I'll fix this.
Duncan Murdoch
>
> There is a typo in the R-patched and R-devel versions of assign.Rd in
> the first example comments.
>
> It is presently:
>
> #-- Create objects 'r1', 'r2', ... 'r6' --
>
> Note the line where paste() is used in the example is:
>
> nam <- paste("r",i, sep=".") # Note 'sep'
>
>
> Hence, the comment should be:
>
> #-- Create objects 'r.1', 'r.2', ... 'r.6' --
>
> I have attached a text file containing the patch against today's r-devel
> tarball version of assign.Rd.
>
> HTH,
>
> Marc Schwartz
>
>
>
>
>
> __
> 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] R_PAPERSIZE and LC_PAPER
Roger,
Thanks.
Yes, this I know. In fact I have a line in my shell script for building
R[-patched]:
./configure R_PAPERSIZE=letter
R_PAPERSIZE is document in several places, however R_PAPERSIZE_DEFAULT
is not, unless I am going blind in my middle age... :-)
Regards,
Marc
On Thu, 2006-04-20 at 14:44 -0400, Roger D. Peng wrote:
> Papersize can be set at compile time in the 'config.site' file (R_PAPERSIZE).
>
> -roger
>
> Marc Schwartz (via MN) wrote:
> > Prof. Ripley,
> >
> > Happy to help.
> >
> > So, it sounds like we are thinking along the same lines then.
> >
> > A couple of follow up questions:
> >
> > 1. Is R_PAPERSIZE_DEFAULT to be the proposed new compile time setting in
> > 2.4.0? Unless I missed it, I did not see it documented anywhere (ie.
> > R-admin/NEWS for 2.2.1 patched or 2.3.0 devel) and it is not in the
> > configure related files that I have here.
> >
> > 2. For LC_ALL, it is not set (at least on my FC4 system, have not had
> > the time yet to go to FC5) in en_US.UTF-8. Is it set in other locales
> > such that it would be of value?
> >
> >
> > Thanks also for the pointer to the devel guidelines. I had read through
> > them at some point in the past, but it has been a while.
> >
> > Regards,
> >
> > Marc
> >
> > On Thu, 2006-04-20 at 18:48 +0100, Prof Brian Ripley wrote:
> >> Marc,
> >>
> >> Thanks for the comments. The 2.3.x series is in feature freeze, and
> >> although a few features do break though for patch releases, they had
> >> better be `badly needed' see
> >> http://developer.r-project.org/devel-guidelines.txt).
> >>
> >> So I was thinking of 2.4.0.
> >>
> >> My suggestion was going to be along the lines of
> >>
> >> local({
> >> papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
> >> if(!nchar(papersize)) {
> >> lcpaper <- Sys.getlocale("LC_PAPER")
> >> if(nchar(lcpaper))
> >> papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
> >> else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
> >> }
> >> options(papersize = papersize)
> >> })
> >>
> >> This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
> >> its value takes precedence over the compile-time default. That's almost
> >> exactly equivalent to what happens on Windows (which sets LC_MONETARY for
> >> this purpose, as LC_PAPER is not a locale category there).
> >>
> >> Now, one could argue that if LC_PAPER is unset it should default to
> >> LC_ALL, but I think is less desirable.
> >>
> >> Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
> >> that's part of the TODO.
> >>
> >> Brian
> >>
> >>
> >> On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
> >>
> >>> On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote:
> R uses the environment variable R_PAPERSIZE to set its papersize, e.g.
> for
> postscript.
>
> It seems the modern way is to via LC_PAPER, e.g.
>
> http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html
>
> and Googling will show that people expect this to work.
>
> However, that is not set on my FC3 system, and it would affect people who
> use en_US as their locale in, say, Austria.
>
> Should we be making use of LC_PAPER, or would it just cause further
> complications? (On Windows, the locale name is used to set the default
> papersize, but there it is unlikely to be set inappropriately.)
> >>>
> >>> Here's my 0.0162 Euros (at current conversion rates):
> >>>
> >>> For R 2.4.0, announce that LC_PAPER will become the default environment
> >>> variable used to set the default R papersize and then not set
> >>> R_PAPERSIZE by default (ie. in build scripts, etc.)
> >>>
> >>> However, If someone sets R_PAPERSIZE in their site or local profile,
> >>> this will supercede the LC_PAPER setting. This would allow for a R
> >>> setting that may need to be different than the system default.
> >>>
> >>> Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and
> >>> time to consider the impact on their local installations and code, while
> >>> enabling future users to take advantage of the standard.
> >>>
> >>> I think that in general, R should abide by published standards unless
> >>> there are very compelling reasons not to.
> >>>
> >>> HTH,
> >>>
> >>> Marc Schwartz
> >>>
> >>>
> >>>
> >
> > __
> > 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] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
On Thu, 20 Apr 2006, Robert Gentleman wrote: > I disagree, things like README files and other objects are important and > should be included. I don't see the real advantage to such warnings, if > someone wants them they could be turned on optionally. Isn't the point at least partly that all those files are lost on installation? If the README is to be accessible after installation, it can be placed under inst/, so that both users reading the source and installed versions can access it. So maybe the warning could be re-phrased to suggest use of the inst/ tree for files with important content? Best wishes, Roger > > If size is an issue then authors should be warned that their package is > large (in the top 1% at CRAN would be useful to some). I also find it > helpful to know whose packages take forever to build, which we don't do. > > Just because someone put something in TFM doesn't mean it is either a > good idea or sensible, in my experience. > > best wishes >Robert > > > Prof Brian Ripley wrote: > > On Wed, 19 Apr 2006, James Bullard wrote: > > > > > >>Hello, I am having an issue with R CMD check with the nightly build of > >>RC 2.3.0 (listed in the subject.) > > > > > > This is all explained in TFM, `Writing R Extensions'. > > > > > >>The problem is this warning: > >> > >>* checking if this is a source package ... WARNING > >>Subdirectory 'src' contains: > >> README _Makefile > >>These are unlikely file names for src files. > >> > >>In fact, they are not source files, but I do not see any reason why they > >>cannot be there, or why I need to be warned of their presence. > >>Potentially I could be informed of their presence, but that is another > >>matter. > > > > > > Having unnecessary files in other people's packages just waste space and > > download bandwidth for each one of the users. > > > > > >>Now, I only get this warning when I do: > >> > >>R CMD build affxparser > >>R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz > >> > >>If I do: > >> > >>R CMD check -l ~/R-packages affxparser > >> > >>I do not get the warning. Is this inconsistent, or is there rationale > >>behind this? I think the warning is inappropriate, or at the least a > >>little restrictive. It seems as if I should be able to put whatever I > >>want in there, especially the _Makefile as I like to build test programs > >>directly and I want to be able to build exactly what I check out from > >>my source code repository without having to copy files in and out. > > > > > > All described in TFM, including how to set defaults for what is checked. > > > > > >>The output from R CMD check is below. Any insight would be appreciated. > >>As always thanks for your patience. > > > > > > [...] > > > > > > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in R-devel assign.Rd
Hi all,
I had mentioned this as a PS in a recent prior post on r-help on the use
of assign(), but presumably it got buried in the noise.
There is a typo in the R-patched and R-devel versions of assign.Rd in
the first example comments.
It is presently:
#-- Create objects 'r1', 'r2', ... 'r6' --
Note the line where paste() is used in the example is:
nam <- paste("r",i, sep=".") # Note 'sep'
Hence, the comment should be:
#-- Create objects 'r.1', 'r.2', ... 'r.6' --
I have attached a text file containing the patch against today's r-devel
tarball version of assign.Rd.
HTH,
Marc Schwartz
--- assign.Rd 2006-04-09 17:19:28.0 -0500
+++ assign.patched.Rd 2006-04-20 13:35:15.0 -0500
@@ -62,7 +62,7 @@
\code{\link{environment}}.
}
\examples{
-for(i in 1:6) { #-- Create objects 'r1', 'r2', ... 'r6' --
+for(i in 1:6) { #-- Create objects 'r.1', 'r.2', ... 'r.6' --
nam <- paste("r",i, sep=".")
assign(nam, 1:i)
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_PAPERSIZE and LC_PAPER
Papersize can be set at compile time in the 'config.site' file (R_PAPERSIZE).
-roger
Marc Schwartz (via MN) wrote:
> Prof. Ripley,
>
> Happy to help.
>
> So, it sounds like we are thinking along the same lines then.
>
> A couple of follow up questions:
>
> 1. Is R_PAPERSIZE_DEFAULT to be the proposed new compile time setting in
> 2.4.0? Unless I missed it, I did not see it documented anywhere (ie.
> R-admin/NEWS for 2.2.1 patched or 2.3.0 devel) and it is not in the
> configure related files that I have here.
>
> 2. For LC_ALL, it is not set (at least on my FC4 system, have not had
> the time yet to go to FC5) in en_US.UTF-8. Is it set in other locales
> such that it would be of value?
>
>
> Thanks also for the pointer to the devel guidelines. I had read through
> them at some point in the past, but it has been a while.
>
> Regards,
>
> Marc
>
> On Thu, 2006-04-20 at 18:48 +0100, Prof Brian Ripley wrote:
>> Marc,
>>
>> Thanks for the comments. The 2.3.x series is in feature freeze, and
>> although a few features do break though for patch releases, they had
>> better be `badly needed' see
>> http://developer.r-project.org/devel-guidelines.txt).
>>
>> So I was thinking of 2.4.0.
>>
>> My suggestion was going to be along the lines of
>>
>> local({
>> papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
>> if(!nchar(papersize)) {
>> lcpaper <- Sys.getlocale("LC_PAPER")
>> if(nchar(lcpaper))
>> papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
>> else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
>> }
>> options(papersize = papersize)
>> })
>>
>> This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
>> its value takes precedence over the compile-time default. That's almost
>> exactly equivalent to what happens on Windows (which sets LC_MONETARY for
>> this purpose, as LC_PAPER is not a locale category there).
>>
>> Now, one could argue that if LC_PAPER is unset it should default to
>> LC_ALL, but I think is less desirable.
>>
>> Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
>> that's part of the TODO.
>>
>> Brian
>>
>>
>> On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
>>
>>> On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote:
R uses the environment variable R_PAPERSIZE to set its papersize, e.g. for
postscript.
It seems the modern way is to via LC_PAPER, e.g.
http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html
and Googling will show that people expect this to work.
However, that is not set on my FC3 system, and it would affect people who
use en_US as their locale in, say, Austria.
Should we be making use of LC_PAPER, or would it just cause further
complications? (On Windows, the locale name is used to set the default
papersize, but there it is unlikely to be set inappropriately.)
>>>
>>> Here's my 0.0162 Euros (at current conversion rates):
>>>
>>> For R 2.4.0, announce that LC_PAPER will become the default environment
>>> variable used to set the default R papersize and then not set
>>> R_PAPERSIZE by default (ie. in build scripts, etc.)
>>>
>>> However, If someone sets R_PAPERSIZE in their site or local profile,
>>> this will supercede the LC_PAPER setting. This would allow for a R
>>> setting that may need to be different than the system default.
>>>
>>> Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and
>>> time to consider the impact on their local installations and code, while
>>> enabling future users to take advantage of the standard.
>>>
>>> I think that in general, R should abide by published standards unless
>>> there are very compelling reasons not to.
>>>
>>> HTH,
>>>
>>> Marc Schwartz
>>>
>>>
>>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_PAPERSIZE and LC_PAPER
Prof. Ripley,
Happy to help.
So, it sounds like we are thinking along the same lines then.
A couple of follow up questions:
1. Is R_PAPERSIZE_DEFAULT to be the proposed new compile time setting in
2.4.0? Unless I missed it, I did not see it documented anywhere (ie.
R-admin/NEWS for 2.2.1 patched or 2.3.0 devel) and it is not in the
configure related files that I have here.
2. For LC_ALL, it is not set (at least on my FC4 system, have not had
the time yet to go to FC5) in en_US.UTF-8. Is it set in other locales
such that it would be of value?
Thanks also for the pointer to the devel guidelines. I had read through
them at some point in the past, but it has been a while.
Regards,
Marc
On Thu, 2006-04-20 at 18:48 +0100, Prof Brian Ripley wrote:
> Marc,
>
> Thanks for the comments. The 2.3.x series is in feature freeze, and
> although a few features do break though for patch releases, they had
> better be `badly needed' see
> http://developer.r-project.org/devel-guidelines.txt).
>
> So I was thinking of 2.4.0.
>
> My suggestion was going to be along the lines of
>
> local({
> papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
> if(!nchar(papersize)) {
> lcpaper <- Sys.getlocale("LC_PAPER")
> if(nchar(lcpaper))
> papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
> else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
> }
> options(papersize = papersize)
> })
>
> This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
> its value takes precedence over the compile-time default. That's almost
> exactly equivalent to what happens on Windows (which sets LC_MONETARY for
> this purpose, as LC_PAPER is not a locale category there).
>
> Now, one could argue that if LC_PAPER is unset it should default to
> LC_ALL, but I think is less desirable.
>
> Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
> that's part of the TODO.
>
> Brian
>
>
> On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
>
> > On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote:
> >> R uses the environment variable R_PAPERSIZE to set its papersize, e.g. for
> >> postscript.
> >>
> >> It seems the modern way is to via LC_PAPER, e.g.
> >>
> >> http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html
> >>
> >> and Googling will show that people expect this to work.
> >>
> >> However, that is not set on my FC3 system, and it would affect people who
> >> use en_US as their locale in, say, Austria.
> >>
> >> Should we be making use of LC_PAPER, or would it just cause further
> >> complications? (On Windows, the locale name is used to set the default
> >> papersize, but there it is unlikely to be set inappropriately.)
> >
> >
> > Here's my 0.0162 Euros (at current conversion rates):
> >
> > For R 2.4.0, announce that LC_PAPER will become the default environment
> > variable used to set the default R papersize and then not set
> > R_PAPERSIZE by default (ie. in build scripts, etc.)
> >
> > However, If someone sets R_PAPERSIZE in their site or local profile,
> > this will supercede the LC_PAPER setting. This would allow for a R
> > setting that may need to be different than the system default.
> >
> > Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and
> > time to consider the impact on their local installations and code, while
> > enabling future users to take advantage of the standard.
> >
> > I think that in general, R should abide by published standards unless
> > there are very compelling reasons not to.
> >
> > HTH,
> >
> > Marc Schwartz
> >
> >
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
I disagree, things like README files and other objects are important and should be included. I don't see the real advantage to such warnings, if someone wants them they could be turned on optionally. If size is an issue then authors should be warned that their package is large (in the top 1% at CRAN would be useful to some). I also find it helpful to know whose packages take forever to build, which we don't do. Just because someone put something in TFM doesn't mean it is either a good idea or sensible, in my experience. best wishes Robert Prof Brian Ripley wrote: > On Wed, 19 Apr 2006, James Bullard wrote: > > >>Hello, I am having an issue with R CMD check with the nightly build of >>RC 2.3.0 (listed in the subject.) > > > This is all explained in TFM, `Writing R Extensions'. > > >>The problem is this warning: >> >>* checking if this is a source package ... WARNING >>Subdirectory 'src' contains: >> README _Makefile >>These are unlikely file names for src files. >> >>In fact, they are not source files, but I do not see any reason why they >>cannot be there, or why I need to be warned of their presence. >>Potentially I could be informed of their presence, but that is another >>matter. > > > Having unnecessary files in other people's packages just waste space and > download bandwidth for each one of the users. > > >>Now, I only get this warning when I do: >> >>R CMD build affxparser >>R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz >> >>If I do: >> >>R CMD check -l ~/R-packages affxparser >> >>I do not get the warning. Is this inconsistent, or is there rationale >>behind this? I think the warning is inappropriate, or at the least a >>little restrictive. It seems as if I should be able to put whatever I >>want in there, especially the _Makefile as I like to build test programs >>directly and I want to be able to build exactly what I check out from >>my source code repository without having to copy files in and out. > > > All described in TFM, including how to set defaults for what is checked. > > >>The output from R CMD check is below. Any insight would be appreciated. >>As always thanks for your patience. > > > [...] > > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gsummary function (nlme library) (PR#8782)
The documentation for gsummary describes the argument FUN as FUN: an optional summary function or a list of summary functions to be applied to each variable in the frame. The function or functions are applied only to variables in 'object' that vary within the groups defined by 'groups'. Invariant variables are always summarized by group using the unique value that they assume within that group. If 'FUN' is a single function it will be applied to each non-invariant variable by group to produce the summary for that variable. If 'FUN' is a list of functions, the names in the list should designate classes of variables in the frame such as 'ordered', 'factor', or 'numeric'. The indicated function will be applied to any non-invariant variables of that class. The default functions to be used are 'mean' for numeric factors, and 'Mode' for both 'factor' and 'ordered'. The 'Mode' function, defined internally in 'gsummary', returns the modal or most popular value of the variable. It is different from the 'mode' function that returns the S-language mode of the variable. so the behavior you noticed is documented. The "summary" in "gsummary" is used in the sense of a representative value, not in the more general sense of a numerical summary of any sort. If the values do not vary within a group then the common value within the group is, according to our definition, the representative value. On 4/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Full_Name: Ben Saville > Version: 2.1 > OS: Windows XP > Submission from: (NULL) (152.2.94.145) > > > I'm using the gsummary function to calculate a sum of V1 (column one) from my > data 'mytest' by group (V2,or column 2). If V1 (the variable of interest) is > all the same value (in this case all 2's), I do not get back the correct > summation. If there is at least one difference in V1 (all 2's except for one > 1), it gives me correct values. So either I am doing something wrong or there > is a bug in the gsummary function. > ># Incorrect sums > mytest <- as.data.frame(matrix(c(2,rep(2,8),1,1,2,2,2,3,3,3,3),ncol=2)) > mytest > gsummary(mytest,form=V1~1|V2, FUN=sum)[,1] > ># Correct sums > mytest <- as.data.frame(matrix(c(1,rep(2,8),1,1,2,2,2,3,3,3,3),ncol=2)) > mytest > gsummary(mytest,form=V1~1|V2, FUN=sum)[,1] > > __ > 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] R_PAPERSIZE and LC_PAPER
Marc,
Thanks for the comments. The 2.3.x series is in feature freeze, and
although a few features do break though for patch releases, they had
better be `badly needed' see
http://developer.r-project.org/devel-guidelines.txt).
So I was thinking of 2.4.0.
My suggestion was going to be along the lines of
local({
papersize <- as.vector(Sys.getenv("R_PAPERSIZE"))
if(!nchar(papersize)) {
lcpaper <- Sys.getlocale("LC_PAPER")
if(nchar(lcpaper))
papersize <- if(length(grep(, lcpaper)) > 0) "letter" else "a4"
else papersize <- as.vector(Sys.getenv("R_PAPERSIZE_DEFAULT"))
}
options(papersize = papersize)
})
This is unchanged if LC_PAPER is unset. For those with LC_PAPER set,
its value takes precedence over the compile-time default. That's almost
exactly equivalent to what happens on Windows (which sets LC_MONETARY for
this purpose, as LC_PAPER is not a locale category there).
Now, one could argue that if LC_PAPER is unset it should default to
LC_ALL, but I think is less desirable.
Of course, at present Sys.getlocale("LC_PAPER") is not supported, so
that's part of the TODO.
Brian
On Thu, 20 Apr 2006, Marc Schwartz (via MN) wrote:
> On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote:
>> R uses the environment variable R_PAPERSIZE to set its papersize, e.g. for
>> postscript.
>>
>> It seems the modern way is to via LC_PAPER, e.g.
>>
>> http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html
>>
>> and Googling will show that people expect this to work.
>>
>> However, that is not set on my FC3 system, and it would affect people who
>> use en_US as their locale in, say, Austria.
>>
>> Should we be making use of LC_PAPER, or would it just cause further
>> complications? (On Windows, the locale name is used to set the default
>> papersize, but there it is unlikely to be set inappropriately.)
>
>
> Here's my 0.0162 Euros (at current conversion rates):
>
> For R 2.4.0, announce that LC_PAPER will become the default environment
> variable used to set the default R papersize and then not set
> R_PAPERSIZE by default (ie. in build scripts, etc.)
>
> However, If someone sets R_PAPERSIZE in their site or local profile,
> this will supercede the LC_PAPER setting. This would allow for a R
> setting that may need to be different than the system default.
>
> Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and
> time to consider the impact on their local installations and code, while
> enabling future users to take advantage of the standard.
>
> I think that in general, R should abide by published standards unless
> there are very compelling reasons not to.
>
> HTH,
>
> Marc Schwartz
>
>
>
--
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] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
On 4/19/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Wed, 19 Apr 2006, James Bullard wrote: > > > Hello, I am having an issue with R CMD check with the nightly build of > > RC 2.3.0 (listed in the subject.) > > This is all explained in TFM, `Writing R Extensions'. > > > The problem is this warning: > > > > * checking if this is a source package ... WARNING > > Subdirectory 'src' contains: > > README _Makefile > > These are unlikely file names for src files. > > > > In fact, they are not source files, but I do not see any reason why they > > cannot be there, or why I need to be warned of their presence. > > Potentially I could be informed of their presence, but that is another > > matter. > > Having unnecessary files in other people's packages just waste space and > download bandwidth for each one of the users. I hope the contents of a README file is more valuable than the what it costs to download it though. You gave a similar comment on a similar question I had in February this year and also said "quoting you last reply "Can you not put your master sources on your own web site." Is it a general consensus on R-devel that *.tar.gz distributions should only be treated as a distribution for *building* packages and not for developing them? What do others think? If so there are plenty of ways to make source packages even smaller like having R CMD build removing source code comments and empty lines etc. This could possibly be an option to "build". Personally, I prefer paying for the extra bandwidth and treat *.tar.gz as a very convenient base for development too. Best, /Henrik > > Now, I only get this warning when I do: > > > > R CMD build affxparser > > R CMD check -l ~/R-packages/ affxparser_1.3.3.tar.gz > > > > If I do: > > > > R CMD check -l ~/R-packages affxparser > > > > I do not get the warning. Is this inconsistent, or is there rationale > > behind this? I think the warning is inappropriate, or at the least a > > little restrictive. It seems as if I should be able to put whatever I > > want in there, especially the _Makefile as I like to build test programs > > directly and I want to be able to build exactly what I check out from > > my source code repository without having to copy files in and out. > > All described in TFM, including how to set defaults for what is checked. > > > The output from R CMD check is below. Any insight would be appreciated. > > As always thanks for your patience. > > [...] > > > -- > 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 > > -- Henrik Bengtsson Mobile: +46 708 909208 (+2h UTC) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_PAPERSIZE and LC_PAPER
On Thu, 2006-04-20 at 08:09 +0100, Prof Brian Ripley wrote: > R uses the environment variable R_PAPERSIZE to set its papersize, e.g. for > postscript. > > It seems the modern way is to via LC_PAPER, e.g. > > http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html > > and Googling will show that people expect this to work. > > However, that is not set on my FC3 system, and it would affect people who > use en_US as their locale in, say, Austria. > > Should we be making use of LC_PAPER, or would it just cause further > complications? (On Windows, the locale name is used to set the default > papersize, but there it is unlikely to be set inappropriately.) Here's my 0.0162 Euros (at current conversion rates): For R 2.4.0, announce that LC_PAPER will become the default environment variable used to set the default R papersize and then not set R_PAPERSIZE by default (ie. in build scripts, etc.) However, If someone sets R_PAPERSIZE in their site or local profile, this will supercede the LC_PAPER setting. This would allow for a R setting that may need to be different than the system default. Doing this for 2.4.0 (as opposed to 2.3.x) would give folks notice and time to consider the impact on their local installations and code, while enabling future users to take advantage of the standard. I think that in general, R should abide by published standards unless there are very compelling reasons not to. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist for promptPackage / index
On 4/19/2006 2:11 PM, Peter Ruckdeschel wrote: > On 4/19/2006 1:49 AM, Duncan Murdoch wrote: > >> On 4/18/2006 7:02 PM, Peter Ruckdeschel wrote: >>> would it be possible to enhance either promptPackage() >>> or the default indexing mechanism for packages >>> so that -- if it exists -- (the contents of) file >>> -package.Rd is sorted first in >>> >>> * the .dvi / .pdf documentation file >>> * the .chm documentation file >>> * the package 00index.html documentation file > >> They already sort first in the last of those. I don't think it is >> really possible in the index of a .chm file; they are alphabetical >> sorting only, as far as I know. (The package topic does sort first in >> the main contents page, which is the same as the 00index.html file.) > > Yes, you are right: the first two cases are already settled > in a completely satisfying way [even with "+","-"-type methods!]. > > Sorry to have stirred you up --- I should have tried first. > >> It probably makes sense in a .dvi/.pdf, > > I tried out with an example now: > at least for this case my request still applies ... > >> but as far as I recall, at the time I thought those were produced >> by the shell script for Rd2dvi, and it just seemed like too much trouble >> to change the collation order there. >> In fact, now I look closer I see they are produced by the Perl >> script tools/pkg2tex.pl so it shouldn't be hard to port the changes I >> made to Rdlists.pm over. I'll take a look. > > would be very nice; thank you very much Done now in R-devel; after the 2.3.0 release I'll port it over to R-patched as well. (In the process of doing this I noticed that grDevices-package wasn't making it into the reference manual due to a bug; I fixed that too.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R and Commercial applications
> > From: Philippe Grosjean <[EMAIL PROTECTED]> > > However, I was suprised to learn that the Pipeline Pilot R Collection is > not GPL and is not free (in term of money, i.e., you have to pay > 3500$/year to use it). I am not sure, but I think they break the GPL > license here since they use a commercial license for, basically, a > collection of R scripts embedded in their 'PP components'. It shouldn't suprise you. There are plenty of similar examples, such as CSIRO's gene expression image analysis viewer, Spotfire allows for a similar interaction, and BioConductor is "repackaged" for S-PLUS without much returned to the developers (by license design). And at least where I work, that $3500/year is pocket change for IT tools (vs. doing something bespoke to solve a similar problem). Pipeline pilot is an excellent product for what it does, fast and flexible screening of large numbers of readouts). And just wait until commercial companies provide "supported R" distributions, and will sell you a "supported" value of R for a group for such pocket change (i.e. the Red Hat model). Now there's serious value, if done correctly. Analytics/decision making is getting on VC radar screens these days. Think, "Red Hat Enterprise Edition" vs. Fedora. The latter has been usefully helped by people who have bought the former. It takes someone's money to do these things. Now, as Peter mentioned, "embedding" is a bit of a tricky thing. It's never been clear why shell'ing out commands is any different than linking to a shared library when you consider the general activities (yes, system/robustness, vs "a hack") but they are viewed differently from the GPL perspective, as far as I'm aware of the relevant sections. But I'm not a lawyer. best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug: code not working as expected (PR#8783)
Hi Nicolai, 2006/4/20, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > This is a multi-part message in MIME format. > --020909040800030906040005 > Content-Type: text/plain; charset=KOI8-R; format=flowed > Content-Transfer-Encoding: 7bit > > Hi, > > I've attached two files with the sources for a function to implement the > finite difference method for solving a particular differential equation. > > One of them works correctly, the other gives wrong results or returns an > error, depending on the version of R. > > The difference between them is that in the 'broken' version in line 42 I > check if the items in the two-dimensional array are bigger than a > certain value, and in the working one I do it in a separate loop. diff working.r broken.r also reveals that your expression is differently bracketed broken.txt says in line 42: (...) = (X-(j-1)*dS); working.txt: (...) = X-(j-1)*dS; Don't know what the rationale of this difference really is since I'm no expert for finite difference methods. But your examples apparently don't only differ in terms of checking the size of your array-values. Does this matter? Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug: code not working as expected (PR#8783)
[EMAIL PROTECTED] writes:
> This is a multi-part message in MIME format.
> --020909040800030906040005
> Content-Type: text/plain; charset=KOI8-R; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi,
>
> I've attached two files with the sources for a function to implement the
> finite difference method for solving a particular differential equation.
>
> One of them works correctly, the other gives wrong results or returns an
> error, depending on the version of R.
>
> The difference between them is that in the 'broken' version in line 42 I
> check if the items in the two-dimensional array are bigger than a
> certain value, and in the working one I do it in a separate loop.
>
> A 2.1.1 build for Solaris returns the following error
>
> Error in if ((X - (j - 1) * dS) > f[i, j]) f[i, j] = (X - (j - 1) * dS)
> : missing value where TRUE/FALSE needed
>
> On Windows both the stable 2.2.1 and 2.3.0rc gui versions will silently
> produce incorrect data.
Why do you file a bug report for a bug in your own code?
The two loops can not be expected to give the same result since the
term f[i,2] might differ when j is in 3:M.
The platform difference could easily be due to floating point issues,
e.g. the difference between divide by zero and divide by near-zero.
> Nikolai.
>
> --020909040800030906040005
> Content-Type: text/plain;
> name="broken.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="broken.txt"
>
> findiff<-function(T,S_0,X,sigma,r,N,M)
> {
> f=array(,c(N+1,M+1))
> dT=T/N;
> dS=2*S_0/M;
> for (i in (1:(N+1)))
> {
> f[i,1]=X;
> f[i,M+1]=0;
> }
> for (j in (1:(M+1)))
> {
> f[N+1,j]=max(X-(j-1)*dS,0);
> }
> a=0;
> b=0;
> c=0;
> for (j in 1:M-1)
> {
> a[j+1]=.5*r*j*dT-.5*sigma^2*j^2*dT;
> b[j+1]=1+sigma^2*j^2*dT+r*dT;
> c[j+1]=-.5*r*j*dT-.5*sigma^2*j^2*dT;
> }
> i=N;
> while (i>0)
> {
> d=0;
> e=0;
> d[1]=f[i+1,1];
> e[1]=0;
> d[2]=0;
> e[2]=1;
> for (j in 2:M)
> {
> d[j+1]=(f[i+1,j]-a[j]*d[j-1]-b[j]*d[j])/c[j];
> e[j+1]=(-a[j]*e[j-1]-b[j]*e[j])/c[j];
> }
> f[i,2]=(f[i,M+1]-d[M+1])/e[M+1];
> for (j in 2:M)
> {
> f[i,j]=d[j]+e[j]*f[i,2];
> if ((X-(j-1)*dS)>f[i,j]) f[i,j] = (X-(j-1)*dS);
> }
> i=i-1;
> }
> f;
> }
>
> findiff(1,10,10,.3,.1,2,4)
>
> --020909040800030906040005
> Content-Type: text/plain;
> name="working.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="working.txt"
>
> findiff<-function(T,S_0,X,sigma,r,N,M)
> {
> f=array(,c(N+1,M+1))
> dT=T/N;
> dS=2*S_0/M;
> for (i in (1:(N+1)))
> {
> f[i,1]=X;
> f[i,M+1]=0;
> }
> for (j in (1:(M+1)))
> {
> f[N+1,j]=max(X-(j-1)*dS,0);
> }
> a=0;
> b=0;
> c=0;
> for (j in 1:M-1)
> {
> a[j+1]=.5*r*j*dT-.5*sigma^2*j^2*dT;
> b[j+1]=1+sigma^2*j^2*dT+r*dT;
> c[j+1]=-.5*r*j*dT-.5*sigma^2*j^2*dT;
> }
> i=N;
> while (i>0)
> {
> d=0;
> e=0;
> d[1]=f[i+1,1];
> e[1]=0;
> d[2]=0;
> e[2]=1;
> for (j in 2:M)
> {
> d[j+1]=(f[i+1,j]-a[j]*d[j-1]-b[j]*d[j])/c[j];
> e[j+1]=(-a[j]*e[j-1]-b[j]*e[j])/c[j];
> }
> f[i,2]=(f[i,M+1]-d[M+1])/e[M+1];
> for (j in 2:M)
> {
> f[i,j]=d[j]+e[j]*f[i,2];
> }
> for (j in 2:M)
> {
> if ((X-(j-1)*dS)>f[i,j]) f[i,j]=X-(j-1)*dS;
> }
> i=i-1;
> }
> f;
> }
>
> findiff(1,10,10,.3,.1,2,4)
>
> --020909040800030906040005--
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
[Rd] bug: code not working as expected (PR#8783)
This is a multi-part message in MIME format.
--020909040800030906040005
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I've attached two files with the sources for a function to implement the
finite difference method for solving a particular differential equation.
One of them works correctly, the other gives wrong results or returns an
error, depending on the version of R.
The difference between them is that in the 'broken' version in line 42 I
check if the items in the two-dimensional array are bigger than a
certain value, and in the working one I do it in a separate loop.
A 2.1.1 build for Solaris returns the following error
Error in if ((X - (j - 1) * dS) > f[i, j]) f[i, j] = (X - (j - 1) * dS)
: missing value where TRUE/FALSE needed
On Windows both the stable 2.2.1 and 2.3.0rc gui versions will silently
produce incorrect data.
Nikolai.
--020909040800030906040005
Content-Type: text/plain;
name="broken.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="broken.txt"
findiff<-function(T,S_0,X,sigma,r,N,M)
{
f=array(,c(N+1,M+1))
dT=T/N;
dS=2*S_0/M;
for (i in (1:(N+1)))
{
f[i,1]=X;
f[i,M+1]=0;
}
for (j in (1:(M+1)))
{
f[N+1,j]=max(X-(j-1)*dS,0);
}
a=0;
b=0;
c=0;
for (j in 1:M-1)
{
a[j+1]=.5*r*j*dT-.5*sigma^2*j^2*dT;
b[j+1]=1+sigma^2*j^2*dT+r*dT;
c[j+1]=-.5*r*j*dT-.5*sigma^2*j^2*dT;
}
i=N;
while (i>0)
{
d=0;
e=0;
d[1]=f[i+1,1];
e[1]=0;
d[2]=0;
e[2]=1;
for (j in 2:M)
{
d[j+1]=(f[i+1,j]-a[j]*d[j-1]-b[j]*d[j])/c[j];
e[j+1]=(-a[j]*e[j-1]-b[j]*e[j])/c[j];
}
f[i,2]=(f[i,M+1]-d[M+1])/e[M+1];
for (j in 2:M)
{
f[i,j]=d[j]+e[j]*f[i,2];
if ((X-(j-1)*dS)>f[i,j]) f[i,j] = (X-(j-1)*dS);
}
i=i-1;
}
f;
}
findiff(1,10,10,.3,.1,2,4)
--020909040800030906040005
Content-Type: text/plain;
name="working.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="working.txt"
findiff<-function(T,S_0,X,sigma,r,N,M)
{
f=array(,c(N+1,M+1))
dT=T/N;
dS=2*S_0/M;
for (i in (1:(N+1)))
{
f[i,1]=X;
f[i,M+1]=0;
}
for (j in (1:(M+1)))
{
f[N+1,j]=max(X-(j-1)*dS,0);
}
a=0;
b=0;
c=0;
for (j in 1:M-1)
{
a[j+1]=.5*r*j*dT-.5*sigma^2*j^2*dT;
b[j+1]=1+sigma^2*j^2*dT+r*dT;
c[j+1]=-.5*r*j*dT-.5*sigma^2*j^2*dT;
}
i=N;
while (i>0)
{
d=0;
e=0;
d[1]=f[i+1,1];
e[1]=0;
d[2]=0;
e[2]=1;
for (j in 2:M)
{
d[j+1]=(f[i+1,j]-a[j]*d[j-1]-b[j]*d[j])/c[j];
e[j+1]=(-a[j]*e[j-1]-b[j]*e[j])/c[j];
}
f[i,2]=(f[i,M+1]-d[M+1])/e[M+1];
for (j in 2:M)
{
f[i,j]=d[j]+e[j]*f[i,2];
}
for (j in 2:M)
{
if ((X-(j-1)*dS)>f[i,j]) f[i,j]=X-(j-1)*dS;
}
i=i-1;
}
f;
}
findiff(1,10,10,.3,.1,2,4)
--020909040800030906040005--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R_PAPERSIZE and LC_PAPER
R uses the environment variable R_PAPERSIZE to set its papersize, e.g. for postscript. It seems the modern way is to via LC_PAPER, e.g. http://mail.nl.linux.org/linux-utf8/2002-05/msg00010.html and Googling will show that people expect this to work. However, that is not set on my FC3 system, and it would affect people who use en_US as their locale in, say, Austria. Should we be making use of LC_PAPER, or would it just cause further complications? (On Windows, the locale name is used to set the default papersize, but there it is unlikely to be set inappropriately.) -- 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
