Re: [Rd] Comments in the DESCRIPTION file
Hi all, Since R 3.0.0, the '#' does no longuer works for comments. But as noticed above, comments can be introduce by 'anyWord:' or 'myComment;' or 'toto:'. Since '#' can be used to name a field, we can also used '#:' or '###:' (or even '%:' for LaTeX's fans). So '#:' is a new possible way for adding comments in DESCRIPTION file. Christophe -- View this message in context: http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4665892.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Comments in the DESCRIPTION file
On May 1, 2013, at 6:01 AM, cgenolin wrote: > Hi all, > > Since R 3.0.0, the '#' does no longuer works for comments. > But as noticed above, comments can be introduce by 'anyWord:' or > 'myComment;' or 'toto:'. > > Since '#' can be used to name a field, we can also used '#:' or '###:' (or > even '%:' for LaTeX's fans). > > So '#:' is a new possible way for adding comments in DESCRIPTION file. > No, it's not, they are not permitted -- please read the DCF specs: "Field names must not begin with the comment character, #." Cheers, Simon > Christophe > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Comments-in-the-DESCRIPTION-file-tp4648678p4665892.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > 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] Windows, format.POSIXct and character encodings
Hi all,
In what encoding does format.POSIXct return its output? It doesn't
seem to be utf-8:
Sys.setlocale("LC_ALL", "Japanese_Japan.932")
times <- c("1970-01-01 01:00:00 UTC", "1970-02-02 22:00:00 UTC")
ampm <- format(as.POSIXct(times), format = "%p")
x <- gsub(">", "*", paste(ampm, collapse = "+>"))
y <- "午前+*午後"
identical(x, y)
# [1] TRUE
# But, confusingly, ...
charToRaw(x)
# [1] e5 8d 88 e5 89 8d 2b 2a e5 8d 88 e5 be 8c
charToRaw(y)
# [1] 8c df 91 4f 2b 2a 8c df 8c e3
# So there's at least a small bug with identical
# And this causes a problem when you attempt to do
# stuff with the string
gsub("+", "*", x, fixed = T)
# Error in gsub("+", "*", x, fixed = T) :
# invalid multibyte string at '<8c>'
gsub("+", "*", y, fixed = T)
# [1] "午前**午後"
My session info is
R version 3.0.0 (2013-04-03)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=Japanese_Japan.932 LC_CTYPE=Japanese_Japan.932
[3] LC_MONETARY=Japanese_Japan.932 LC_NUMERIC=C
[5] LC_TIME=Japanese_Japan.932
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.0.0
Any ideas? Thanks!
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trace with reference class
No intended change. The trace method was not updated when reference class generators became functions. Should be fixed now in r-devel and 3.0.0 patched (rev 62699). Thanks for the catch. John On 4/29/13 11:30 PM, Kohske Takahashi wrote: Hi The final line of the example in ?setRefClass induces an error: ## debugging all objects from class mEdit in method $undo() mEdit$trace(undo, browser) Error in envRefInferField(x, what, getClass(class(x)), selfEnv) : 'undo' is not a valid field or method name for reference class "refGeneratorSlot" $trace tries to embed the trace in the generator object (instead of the generated object). Has this functionality been removed? best, kohske -- Kohske Takahashi Assistant Professor, Research Center for Advanced Science and Technology, The University of Tokyo, Japan. http://www.fennel.rcast.u-tokyo.ac.jp/profilee_ktakahashi.html __ 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] Patch proposal for R style consistency (concerning deparse.c)
Whoa.
Don't let my valuable suggestion get lost.
I want "} else {". Yihue wants "} else {". And I have not heard anybody
say they prefer the other way, unless you interpret Duncan's comment
"that's nonsense" as a blanket defense of the status quo. But I don't think
he meant that. This is a matter of style consistency and avoidance of new
R-user confusion and error.
After reading the help for "if", I don't see how anybody can argue against
this. Good R code has this style:
} else {
and not
}
else
because the latter fails if it is run line-by-line. While trying to teach
people how to write R programs, it would be nice if the output of
print.function was consistent with the good way, the way that is actually
practiced in the R source code itself. This is a major source of new
programmer confusion. Its very tough to explain and teach.
pj
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
+1 to having runnable code emitted
patch seems to work nicely, hopefully R-core will agree to apply it to HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson wrote:
> Whoa.
>
> Don't let my valuable suggestion get lost.
>
> I want "} else {". Yihue wants "} else {". And I have not heard anybody
> say they prefer the other way, unless you interpret Duncan's comment
> "that's nonsense" as a blanket defense of the status quo. But I don't think
> he meant that. This is a matter of style consistency and avoidance of new
> R-user confusion and error.
>
> After reading the help for "if", I don't see how anybody can argue against
> this. Good R code has this style:
>
> } else {
>
> and not
>
> }
> else
>
> because the latter fails if it is run line-by-line. While trying to teach
> people how to write R programs, it would be nice if the output of
> print.function was consistent with the good way, the way that is actually
> practiced in the R source code itself. This is a major source of new
> programmer confusion. Its very tough to explain and teach.
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science Assoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://quant.ku.edu
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] objects with tsp attribute but no class
What is the intended difference between objects of class "ts", which must have an attribute called "tsp", and objects with that attribute but not that class? Calling time series oriented functions like time() or window() on vectors of numbers produce the classless objects with the tsp attribute. Should methods for atomic vectors check for the tsp attribute and do special things for it? I was wondering if it was just to be compatible with S or S+, where in ancient (pre-class) times, the ".Tsp" attribute indicated that you were dealing with a time series, just as the presence of of a ".Dim" attribute meant the object was a matrix. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
+1 to having runnable code emitted
It does emit runnable code, which is why Herve's complaint was
nonsense. It doesn't emit code of which every substring is runnable.
Duncan Murdoch
patch seems to work nicely, hopefully R-core will agree to apply it to HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson wrote:
> Whoa.
>
> Don't let my valuable suggestion get lost.
>
> I want "} else {". Yihue wants "} else {". And I have not heard anybody
> say they prefer the other way, unless you interpret Duncan's comment
> "that's nonsense" as a blanket defense of the status quo. But I don't think
> he meant that. This is a matter of style consistency and avoidance of new
> R-user confusion and error.
>
> After reading the help for "if", I don't see how anybody can argue against
> this. Good R code has this style:
>
> } else {
>
> and not
>
> }
> else
>
> because the latter fails if it is run line-by-line. While trying to teach
> people how to write R programs, it would be nice if the output of
> print.function was consistent with the good way, the way that is actually
> practiced in the R source code itself. This is a major source of new
> programmer confusion. Its very tough to explain and teach.
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science Assoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://quant.ku.edu
>
> [[alternative HTML version deleted]]
>
> __
> 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] Patch proposal for R style consistency (concerning deparse.c)
+1 for "} else {" . It might seem a detail, but I agree wholeheartedly that
this would make teaching R easier.
Btw, thank you Paul for the link to your coding style document. It was a
nice read.
Cheers
Joris
On Wed, May 1, 2013 at 9:19 PM, Duncan Murdoch wrote:
> On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
>
>> +1 to having runnable code emitted
>>
>
> It does emit runnable code, which is why Herve's complaint was nonsense.
> It doesn't emit code of which every substring is runnable.
>
> Duncan Murdoch
>
>
>> patch seems to work nicely, hopefully R-core will agree to apply it to
>> HEAD
>>
>>
>>
>> On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
>> wrote:
>>
>> > Whoa.
>> >
>> > Don't let my valuable suggestion get lost.
>> >
>> > I want "} else {". Yihue wants "} else {". And I have not heard
>> anybody
>> > say they prefer the other way, unless you interpret Duncan's comment
>> > "that's nonsense" as a blanket defense of the status quo. But I don't
>> think
>> > he meant that. This is a matter of style consistency and avoidance of
>> new
>> > R-user confusion and error.
>> >
>> > After reading the help for "if", I don't see how anybody can argue
>> against
>> > this. Good R code has this style:
>> >
>> > } else {
>> >
>> > and not
>> >
>> > }
>> > else
>> >
>> > because the latter fails if it is run line-by-line. While trying to
>> teach
>> > people how to write R programs, it would be nice if the output of
>> > print.function was consistent with the good way, the way that is
>> actually
>> > practiced in the R source code itself. This is a major source of new
>> > programmer confusion. Its very tough to explain and teach.
>> >
>> > pj
>> > --
>> > Paul E. Johnson
>> > Professor, Political Science Assoc. Director
>> > 1541 Lilac Lane, Room 504 Center for Research Methods
>> > University of Kansas University of Kansas
>> > http://pj.freefaculty.org http://quant.ku.edu
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __**
>> > 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
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
What harm comes of having the code be cut-and-paste-able?
I do not mean to be contrary but a downside to applying the patch seems to
be lacking.
Perhaps I am missing something obvious and if so I beg your pardon for
wasting your time.
Thanks,
--t
On Wed, May 1, 2013 at 12:19 PM, Duncan Murdoch wrote:
> On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
>
>> +1 to having runnable code emitted
>>
>
> It does emit runnable code, which is why Herve's complaint was nonsense.
> It doesn't emit code of which every substring is runnable.
>
> Duncan Murdoch
>
>
>
>> patch seems to work nicely, hopefully R-core will agree to apply it to
>> HEAD
>>
>>
>>
>> On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
>> wrote:
>>
>> > Whoa.
>> >
>> > Don't let my valuable suggestion get lost.
>> >
>> > I want "} else {". Yihue wants "} else {". And I have not heard
>> anybody
>> > say they prefer the other way, unless you interpret Duncan's comment
>> > "that's nonsense" as a blanket defense of the status quo. But I don't
>> think
>> > he meant that. This is a matter of style consistency and avoidance of
>> new
>> > R-user confusion and error.
>> >
>> > After reading the help for "if", I don't see how anybody can argue
>> against
>> > this. Good R code has this style:
>> >
>> > } else {
>> >
>> > and not
>> >
>> > }
>> > else
>> >
>> > because the latter fails if it is run line-by-line. While trying to
>> teach
>> > people how to write R programs, it would be nice if the output of
>> > print.function was consistent with the good way, the way that is
>> actually
>> > practiced in the R source code itself. This is a major source of new
>> > programmer confusion. Its very tough to explain and teach.
>> >
>> > pj
>> > --
>> > Paul E. Johnson
>> > Professor, Political Science Assoc. Director
>> > 1541 Lilac Lane, Room 504 Center for Research Methods
>> > University of Kansas University of Kansas
>> > http://pj.freefaculty.org http://quant.ku.edu
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __**
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/**listinfo/r-devel
>> >
>>
>>
>>
>>
>
--
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows, format.POSIXct and character encodings
On May 1, 2013, at 10:06 AM, Hadley Wickham wrote:
> Hi all,
>
> In what encoding does format.POSIXct return its output? It doesn't
> seem to be utf-8:
>
> Sys.setlocale("LC_ALL", "Japanese_Japan.932")
>
> times <- c("1970-01-01 01:00:00 UTC", "1970-02-02 22:00:00 UTC")
> ampm <- format(as.POSIXct(times), format = "%p")
> x <- gsub(">", "*", paste(ampm, collapse = "+>"))
>
> y <- "午前+*午後"
> identical(x, y)
> # [1] TRUE
>
> # But, confusingly, ...
>
> charToRaw(x)
> # [1] e5 8d 88 e5 89 8d 2b 2a e5 8d 88 e5 be 8c
>
> charToRaw(y)
> # [1] 8c df 91 4f 2b 2a 8c df 8c e3
>
That's not confusing at all:
> Encoding(x)
[1] "UTF-8"
> Encoding(y)
[1] "unknown"
The first string is in UTF-8 the second is in the local locale (here 932).
> # So there's at least a small bug with identical
>
Nope: ?identical
"Character strings are regarded as identical if they are in different marked
encodings but would agree when translated to UTF-8."
> # And this causes a problem when you attempt to do
> # stuff with the string
>
> gsub("+", "*", x, fixed = T)
> # Error in gsub("+", "*", x, fixed = T) :
> # invalid multibyte string at '<8c>'
> gsub("+", "*", y, fixed = T)
> # [1] "午前**午後"
>
This is where the problem lies - and it has nothing to do with format:
> z=enc2utf8("午前+*午後")
> gsub("+", "*", z, fixed = T)
Error in gsub("+", "*", z, fixed = T) :
invalid multibyte string at '<8c>'
The cause is that fgrep_one() gives higher precedence to mbcslocale than
use_UTF8 so the grep is actually done in the MBCS locale and not UTF-8.
Consequently, you'll see this only in multi-byte locales other than UTF-8, so
on let's say OS X you can reproduce it with
> x="午前+*午後"
> gsub("+", "*", x, fixed = T)
Error in gsub("+", "*", x, fixed = T) :
invalid multibyte string at '<8c>'
Inverting the precedence would fix this issue, but I'm not sure if it would
have unwanted side-effects on MBCS locales ...
Cheers,
Simon
>
> My session info is
>
> R version 3.0.0 (2013-04-03)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=Japanese_Japan.932 LC_CTYPE=Japanese_Japan.932
> [3] LC_MONETARY=Japanese_Japan.932 LC_NUMERIC=C
> [5] LC_TIME=Japanese_Japan.932
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_3.0.0
>
> Any ideas? Thanks!
>
> Hadley
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/
>
> __
> 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] Windows, format.POSIXct and character encodings
On May 1, 2013, at 5:33 PM, Simon Urbanek wrote:
>
> On May 1, 2013, at 10:06 AM, Hadley Wickham wrote:
>
>> Hi all,
>>
>> In what encoding does format.POSIXct return its output? It doesn't
>> seem to be utf-8:
>>
>> Sys.setlocale("LC_ALL", "Japanese_Japan.932")
>>
>> times <- c("1970-01-01 01:00:00 UTC", "1970-02-02 22:00:00 UTC")
>> ampm <- format(as.POSIXct(times), format = "%p")
>> x <- gsub(">", "*", paste(ampm, collapse = "+>"))
>>
>> y <- "午前+*午後"
>> identical(x, y)
>> # [1] TRUE
>>
>> # But, confusingly, ...
>>
>> charToRaw(x)
>> # [1] e5 8d 88 e5 89 8d 2b 2a e5 8d 88 e5 be 8c
>>
>> charToRaw(y)
>> # [1] 8c df 91 4f 2b 2a 8c df 8c e3
>>
>
> That's not confusing at all:
>
>> Encoding(x)
> [1] "UTF-8"
>> Encoding(y)
> [1] "unknown"
>
> The first string is in UTF-8 the second is in the local locale (here 932).
>
>
>> # So there's at least a small bug with identical
>>
>
> Nope: ?identical
> "Character strings are regarded as identical if they are in different marked
> encodings but would agree when translated to UTF-8."
>
>
>> # And this causes a problem when you attempt to do
>> # stuff with the string
>>
>> gsub("+", "*", x, fixed = T)
>> # Error in gsub("+", "*", x, fixed = T) :
>> # invalid multibyte string at '<8c>'
>> gsub("+", "*", y, fixed = T)
>> # [1] "午前**午後"
>>
>
> This is where the problem lies - and it has nothing to do with format:
>
>> z=enc2utf8("午前+*午後")
>> gsub("+", "*", z, fixed = T)
> Error in gsub("+", "*", z, fixed = T) :
> invalid multibyte string at '<8c>'
>
> The cause is that fgrep_one() gives higher precedence to mbcslocale than
> use_UTF8 so the grep is actually done in the MBCS locale and not UTF-8.
> Consequently, you'll see this only in multi-byte locales other than UTF-8, so
> on let's say OS X you can reproduce it with
>
>> x="午前+*午後"
>> gsub("+", "*", x, fixed = T)
> Error in gsub("+", "*", x, fixed = T) :
> invalid multibyte string at '<8c>'
>
This should have been
> Sys.getlocale()
[1] "en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8"
> x="午前+*午後"
> Encoding(x)
[1] "UTF-8"
> Sys.setlocale("LC_ALL", "ja_JP.SJIS")
[1] "ja_JP.SJIS/ja_JP.SJIS/ja_JP.SJIS/C/ja_JP.SJIS/en_US.UTF-8"
> gsub("+", "*", x, fixed = T)
Error in gsub("+", "*", x, fixed = T) :
invalid multibyte string at '<8c>'
Cheers,
S
> Inverting the precedence would fix this issue, but I'm not sure if it would
> have unwanted side-effects on MBCS locales ...
>
> Cheers,
> Simon
>
>
>>
>> My session info is
>>
>> R version 3.0.0 (2013-04-03)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>
>> locale:
>> [1] LC_COLLATE=Japanese_Japan.932 LC_CTYPE=Japanese_Japan.932
>> [3] LC_MONETARY=Japanese_Japan.932 LC_NUMERIC=C
>> [5] LC_TIME=Japanese_Japan.932
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> loaded via a namespace (and not attached):
>> [1] tools_3.0.0
>>
>> Any ideas? Thanks!
>>
>> Hadley
>>
>> --
>> Chief Scientist, RStudio
>> http://had.co.nz/
>>
>> __
>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
On 05/01/2013 12:19 PM, Duncan Murdoch wrote:
On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
+1 to having runnable code emitted
It does emit runnable code, which is why Herve's complaint was
nonsense. It doesn't emit code of which every substring is runnable.
Perdon me, but I was not of course suggesting that every substring be
runnable. That would be non-sense. So please, don't make me say what
I didn't say. Thank you!
H.
Duncan Murdoch
patch seems to work nicely, hopefully R-core will agree to apply it to
HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
wrote:
> Whoa.
>
> Don't let my valuable suggestion get lost.
>
> I want "} else {". Yihue wants "} else {". And I have not heard
anybody
> say they prefer the other way, unless you interpret Duncan's comment
> "that's nonsense" as a blanket defense of the status quo. But I
don't think
> he meant that. This is a matter of style consistency and avoidance
of new
> R-user confusion and error.
>
> After reading the help for "if", I don't see how anybody can argue
against
> this. Good R code has this style:
>
> } else {
>
> and not
>
> }
> else
>
> because the latter fails if it is run line-by-line. While trying to
teach
> people how to write R programs, it would be nice if the output of
> print.function was consistent with the good way, the way that is
actually
> practiced in the R source code itself. This is a major source of new
> programmer confusion. Its very tough to explain and teach.
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science Assoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://quant.ku.edu
>
> [[alternative HTML version deleted]]
>
> __
> 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
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)
On 13-05-01 4:08 PM, Tim Triche, Jr. wrote:
What harm comes of having the code be cut-and-paste-able?
I do not mean to be contrary but a downside to applying the patch seems to
be lacking.
Perhaps I am missing something obvious and if so I beg your pardon for
wasting your time.
I think you are missing some downsides which may not be obvious:
- it would mean that lots of published results would no longer match
what R produces.
- it would mean that lots of tests for changes in output would
suddenly fail.
- it would support the mistaken belief that some people have that the
current output is not valid code (even though there are nearly 200,000
instances of similar usage on CRAN).
Perhaps 20 years ago it should have been written the way you suggest,
but it would cause far more harm than benefit to change it now.
Duncan Murdoch
Thanks,
--t
On Wed, May 1, 2013 at 12:19 PM, Duncan Murdoch wrote:
On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
+1 to having runnable code emitted
It does emit runnable code, which is why Herve's complaint was nonsense.
It doesn't emit code of which every substring is runnable.
Duncan Murdoch
patch seems to work nicely, hopefully R-core will agree to apply it to
HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
wrote:
Whoa.
Don't let my valuable suggestion get lost.
I want "} else {". Yihue wants "} else {". And I have not heard
anybody
say they prefer the other way, unless you interpret Duncan's comment
"that's nonsense" as a blanket defense of the status quo. But I don't
think
he meant that. This is a matter of style consistency and avoidance of
new
R-user confusion and error.
After reading the help for "if", I don't see how anybody can argue
against
this. Good R code has this style:
} else {
and not
}
else
because the latter fails if it is run line-by-line. While trying to
teach
people how to write R programs, it would be nice if the output of
print.function was consistent with the good way, the way that is
actually
practiced in the R source code itself. This is a major source of new
programmer confusion. Its very tough to explain and teach.
pj
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
[[alternative HTML version deleted]]
__**
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] Patch proposal for R style consistency (concerning deparse.c)
On 05/01/2013 07:20 PM, Duncan Murdoch wrote:
On 13-05-01 4:08 PM, Tim Triche, Jr. wrote:
What harm comes of having the code be cut-and-paste-able?
I do not mean to be contrary but a downside to applying the patch
seems to
be lacking.
Perhaps I am missing something obvious and if so I beg your pardon for
wasting your time.
I think you are missing some downsides which may not be obvious:
- it would mean that lots of published results would no longer match
what R produces.
What kind of published results? Results that do statistics on the nb
of lines of code in a function based on the output of print.function()?
Would it make sense to try to reproduce results that were published 5
or 10 years ago with R >= 3.0.0? Too many things have changed in R
and on CRAN anyway so it's hopeless. The only reasonable/realistic way
to reproduce is to use the version of R and packages that were used
at the time of the publication.
- it would mean that lots of tests for changes in output would
suddenly fail.
Lots of tests really? Where are they?
- it would support the mistaken belief that some people have that the
current output is not valid code (even though there are nearly 200,000
instances of similar usage on CRAN).
Is that number supposed to impress someone?
Running
grep -E '^[[:space:]]*else' */R/*
produces 112,518 lines of output on the 4479 source packages currently
available on CRAN. So 112,518 "if else" statements use the formatting
that breaks copy/paste.
Also, interestingly, running
grep else */R/*
on those packages produces 276028 lines of output. So only 34% of the
"if else" statements use the formatting that breaks copy/paste. Far
from being the dominant idiom, which is probably a good sign for CRAN.
Unfortunately, with the current output of print.function(), 100% of
the "if else" statements on CRAN break copy/paste. Unfair for the
majority of CRAN contributors to see their nicely formatted code
exposed that way to the end-user. Unfair for the end-user, especially
the R novice, to get code s/he cannot copy/paste.
Perhaps 20 years ago it should have been written the way you suggest,
but it would cause far more harm than benefit to change it now.
You clearly underestimate the harm the current formatting causes
every day to many R users, developers, teachers, students...
H.
Duncan Murdoch
Thanks,
--t
On Wed, May 1, 2013 at 12:19 PM, Duncan Murdoch
wrote:
On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
+1 to having runnable code emitted
It does emit runnable code, which is why Herve's complaint was nonsense.
It doesn't emit code of which every substring is runnable.
Duncan Murdoch
patch seems to work nicely, hopefully R-core will agree to apply it to
HEAD
On Wed, May 1, 2013 at 9:45 AM, Paul Johnson
wrote:
Whoa.
Don't let my valuable suggestion get lost.
I want "} else {". Yihue wants "} else {". And I have not heard
anybody
say they prefer the other way, unless you interpret Duncan's comment
"that's nonsense" as a blanket defense of the status quo. But I don't
think
he meant that. This is a matter of style consistency and avoidance of
new
R-user confusion and error.
After reading the help for "if", I don't see how anybody can argue
against
this. Good R code has this style:
} else {
and not
}
else
because the latter fails if it is run line-by-line. While trying to
teach
people how to write R programs, it would be nice if the output of
print.function was consistent with the good way, the way that is
actually
practiced in the R source code itself. This is a major source of new
programmer confusion. Its very tough to explain and teach.
pj
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
[[alternative HTML version deleted]]
__**
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
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
