I'm not sure the idea of having a generic 'sd' extract the residual standard
deviation from a linear model quite jives with me. Personally, I think a
generic function with name like 'residSD' or something similar would be better.
Either way, I think it would be nice to have some function like t
I've often missed the ability to get the directory of the currently
running script. It's actually been possible for a while:
FILE <- (function() {
attr(body(sys.function()), "srcfile")
})()
thanks to Duncan's recent changes to file parsing. This is pretty
useful for sourcing in files relative
Sorry, that should be:
FILE <- (function() {
attr(body(sys.function()), "srcfile")
})()$filename
Hadley
On Fri, Apr 4, 2008 at 10:34 AM, hadley wickham <[EMAIL PROTECTED]> wrote:
> I've often missed the ability to get the directory of the currently
> running script. It's actually been possib
I have R-261 running on a Linux 2.6 system, which has gcc-4.1.2
installed. It was working fine until the sysadmin installed an older
version of gcc (3.4.6) which was required for an older app. The
gcc-3.4.6 install is under /usr/local/bin.
Now when a user invokes R, the error message
"/opt/r-2
Full_Name: Nick Henriquez
Version: 2.6.2; 2.6.1 and 2.4.1
OS: Vista business 64
Submission from: (NULL) (144.82.49.16)
I try to increase memory size (by copy-pasting from FAQ) --max-mem-size=1Gb at
the end of the Target field (after any final double quote, and separated by a
space) and changing t
This is (sort of) correct, and as documented. What you cannot increase to
4Gb is the internal *limit* on the allocated memory size, not the 'memory
size' in any sense.
The rw-FAQ in R 2.6.2 patched says
'It can be set to any amount between 32Mb and 4095Mb.'
as does
http://cran.r-project.org/
Although its kludgy this previously (and still works) too:
parent.frame(2)$ofile
if called from top level within a sourced file.
On Fri, Apr 4, 2008 at 11:50 AM, hadley wickham <[EMAIL PROTECTED]> wrote:
> Sorry, that should be:
>
> FILE <- (function() {
> attr(body(sys.function()), "srcfile")
There is a new version of the just-in-time compiler for R at
www.milbo.users.sonic.net/ra/index.html
With just-in-time compilation enabled, the convolution example from the
"Extending R" manual now runs about 30 times faster. The web page has more
information.
Stephen Milborrow
www.milbo.users.s
I'm always forgetting to update the date in DESCRIPTION. Would it be
possible to add a warning to R CMD check if it's old?
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
> hadley wickham writes:
> I'm always forgetting to update the date in DESCRIPTION. Would it be
> possible to add a warning to R CMD check if it's old?
I recently thought about this. I see several issues.
* How can we determine if it is "old"? Relative to the time when the
package was u
On Fri, Apr 4, 2008 at 2:26 PM, Kurt Hornik <[EMAIL PROTECTED]> wrote:
> > hadley wickham writes:
>
> > I'm always forgetting to update the date in DESCRIPTION. Would it be
> > possible to add a warning to R CMD check if it's old?
>
> I recently thought about this. I see several issues.
>
> I recently thought about this. I see several issues.
>
> * How can we determine if it is "old"? Relative to the time when the
> package was uploaded to a repository?
>
> * Some developers might actually want a different date for a variety of
> reasons ...
>
> * What we currently say in
I think its somewhat inspiring to be able to get R CMD check to the
point that there are no warnings so having a situation where a warning
is ok would interfere with that.
On Fri, Apr 4, 2008 at 3:54 PM, hadley wickham <[EMAIL PROTECTED]> wrote:
> > I recently thought about this. I see several i
> hadley wickham writes:
>> I recently thought about this. I see several issues.
>>
>> * How can we determine if it is "old"? Relative to the time when the
>> package was uploaded to a repository?
>>
>> * Some developers might actually want a different date for a variety of
>> reasons ...
I don't think having 'R CMD check' spit out a warning about the date would be
all that productive. I do think it would be nice to have 'R CMD build' add a
Date: field to the DESCRIPTION file if there isn't already a Date: field. And
I
think such an addition would solve the first problem since
I agree.
It sounds odd to explicitely ask someone to set the 'Date:' field and
then worring because it doesn't match your precise expectation that it
should equal the build time.
A.F.
2008/4/4, Roger D. Peng <[EMAIL PROTECTED]>:
> I don't think having 'R CMD check' spit out a warning about the d
On 4 April 2008 at 14:05, hadley wickham wrote:
| I'm always forgetting to update the date in DESCRIPTION. Would it be
| possible to add a warning to R CMD check if it's old?
As I mentioned to Hadley in private mail, a version control system can update
a field like $Date$ or $LastChangedDate$ au
Kurt Hornik wrote:
>> hadley wickham writes:
>
>>> I recently thought about this. I see several issues.
>>>
>>> * How can we determine if it is "old"? Relative to the time when the
>>> package was uploaded to a repository?
>>>
>>> * Some developers might actually want a different date for
> Please no. If people want one then they should add it manually. It is
> optional, and some of us have explicitly opted out and would like to
> continue to do so.
To clarify, do you mean you have decided not to provide a date field
in the DESCRIPTION file? If so, would you mind elaborating wh
Actually, now that I think about it, 'R CMD build' already adds the 'Packaged:'
field, so perhaps it wouldn't really make sense to add yet another field with
exactly the same information
-roger
Robert Gentleman wrote:
>
> Kurt Hornik wrote:
>>> hadley wickham writes:
I recently th
What do you think about adding this to section 1.1.1 of "Writing R
Extensions", something like the following, between the paragraphs on
"The 'package' and 'version' fields" and "The 'License' field:
The optional 'Date' field can be either a fixed date (preferably
in the -mm-dd
hadley wickham wrote:
>> Please no. If people want one then they should add it manually. It is
>> optional, and some of us have explicitly opted out and would like to
>> continue to do so.
>
> To clarify, do you mean you have decided not to provide a date field
> in the DESCRIPTION file? If
2008/4/4, Dirk Eddelbuettel <[EMAIL PROTECTED]>:
>
> On 4 April 2008 at 14:05, hadley wickham wrote:
> | I'm always forgetting to update the date in DESCRIPTION. Would it be
> | possible to add a warning to R CMD check if it's old?
>
>
> As I mentioned to Hadley in private mail, a version contr
optim ignores misspelled control parameters, so that trying
to set (e.g.) "maxint=1000" in the control argument silently
does nothing. The patch below (watch out for line breaks! also
posted at http://www.zoo.ufl.edu/bolker/optim_patch.R , and
http://www.zoo.ufl.edu/bolker/optim_new.R) adds
> > To clarify, do you mean you have decided not to provide a date field
> > in the DESCRIPTION file? If so, would you mind elaborating why?
> >
>
> Sure: The date of what?
That's a good question. Another possible solution would be to remove
(or down-weight the importance of) the date field, a
On 4 April 2008 at 23:15, Antonio, Fabio Di Narzo wrote:
| 2008/4/4, Dirk Eddelbuettel <[EMAIL PROTECTED]>:
| >
| > On 4 April 2008 at 14:05, hadley wickham wrote:
| > | I'm always forgetting to update the date in DESCRIPTION. Would it be
| > | possible to add a warning to R CMD check if it's
26 matches
Mail list logo
