Re: [Rd] Undocumented 'use.names' argument to c()
> Martin Maechler
> on Mon, 26 Sep 2016 18:26:25 +0200 writes:
> Suharto Anggono Suharto Anggono
> on Mon, 26 Sep 2016 14:51:11 + writes:
>> By "an argument named 'use.names' is included for concatenation", I
meant something like this, that someone might try.
>>> c(as.Date("2016-01-01"), use.names=FALSE)
>> use.names
>> "2016-01-01" "1970-01-01"
>> See, 'use.names' is in the output. That's precisely because 'c.Date'
doesn't have 'use.names', so that 'use.names' is absorbed into '...'.
> Yes, of course.
> Thank you for the explanation; now I understand what you meant.
> Indeed, the situation is not entirely satisfactory:
> Ideally, *both* the 'recursive' and 'use.names' arguments of
> c() should be considered arguments of only the *default* method of c(),
> not the generic.
> OTOH, c() being .Primitive() the implementation is in C only,
> and (in some sense) of *both* the generic function and the
> default method.
> The C code clearly treats 'recursive' and 'use.names' "the
> same", and has been part of R "forever".
> I think that ideally, we should aim for
> 1) The generic function c() only has arguments "..." (or possibly
> --- because of history of the S4 part --- "x, ...").
> 2) The default method has additional arguments
> 'recursive = FALSE, use.names = TRUE'
> and other methods of c() can choose if they want to also
> support one or two or none of these extras.
> Somewhat related, but in principle independent of '1)'
> and '2)' above -- I think, because of the ".Primitive"-ness of c() --
> is the quite how 'c' should print in R.
> Currently it prints like what I say should just be the default
> method.
> Honestly, I'm not sure if it would be straightforward or even
> just relatively painless to go to '1) + 2)' ... may change
> r71349 (to the S4 generic definition of "c") had dramatical
> effects in "package land" and hence reversion of that (with
> r71354) was necessary, for the time being.
I have just now committed a change to R-devel which on the ?c
help page gives
| Usage:
|
| ## S3 Generic function
| c(...)
|
| ## Default S3 method:
| c(..., recursive = FALSE, use.names = TRUE)
and in the console, simply
| > c
| function (...) .Primitive("c")
| >
and am considering committing a similar change to the place
where S4 generic c() is setup in the 'methods' package.
If this persists, methods for c(), S3 or S4, will have the
freedom to carry none, one, or both of 'recursive' and
'use.names' arguments.
> methods(c)
[1] c.bibentry* c.Datec.difftimec.noquote
[5] c.numeric_version c.person* c.POSIXct c.POSIXlt
[9] c.warnings
Currently, most existing c() methods have a 'recursive = FALSE'
*and* ignore a 'recursive' specification completely .. and as
Suharto has noted already, of course they do not have a
'use.names' argument yet and so do not ignore it, but treat it
as a regular argument (to be concatenated).
One consequence of this change (the above commit) is that in
principle all c() methods which have more than the '...'
arguments should be documented as "they have surprising
arguments": They have a 'recursive' argument which is not part
of the generic.
I would say that this "should be documented" is rather a good
thing, because indeed they do silently ignore any 'recursive = foobar()'
and that should be documented, e.g., in current R (and R-devel):
> c(Sys.Date(), recursive=quote(foobar_nonsense()))
[1] "2016-09-29"
>
which is not well documented, I'd say
Martin
>>
>> On Sun, 25/9/16, Martin Maechler wrote:
>> Subject: Re: [Rd] Undocumented 'use.names' argument to c()
>> To: "Suharto Anggono Suharto Anggono"
>> Cc: "R-devel"
>> Date: Sunday, 25 September, 2016, 10:14 PM
> Suharto Anggono Suharto Anggono via R-devel
> on Sun, 25 Sep 2016 14:12:10 + writes:
From comments in
http://stackoverflow.com/questions/24815572/why-does-function-c-accept-an-undocumented-argument/24815653
: The code of c() and unlist() was formerly shared but
has been (long time passing) separated. From July 30,
1998, is where do_c got split into do_c and do_unlist.
>>> With the implementation of 'c.Date' in R devel r71350, an
>>> argument named 'use.names' is included for
>>> concatenation. So, it doesn't follow the documented
>>> 'c'. But, 'c.Date' is not explicitly documented in
>>> Dates.Rd, that has 'c.Date' as an alias.
>> I do not see any c.Date in R-devel with a 'use.names'; its a
>> base function, hence not hidden ..
>> As mentioned before, 'use.names' is used in unlist() in quite a
>> few places, and such an argument also exists for
[Rd] Web site for MacOSX R-devel precompiled version
From several years, I used this site http://r.research.att.com to get a precompiled version of macosx R-devol but the most recent version is frozen at the 18/8 build (r 71112). Is there an alternative (except than compile myself !) ? Thanks, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Web site for MacOSX R-devel precompiled version
I've had a TODO on the list for a while to produce a daily R-devel binary build for macOS since I have some spare macOS compute cycles available. If there's sufficient interest I can copy the build setup and start generating them. I'm also a registered Apple developer so can make signed binaries as well. On Thu, Sep 29, 2016 at 8:42 AM, Marc Girondot via R-devel < r-devel@r-project.org> wrote: > From several years, I used this site http://r.research.att.com to get a > precompiled version of macosx R-devol but the most recent version is frozen > at the 18/8 build (r 71112). > > Is there an alternative (except than compile myself !) ? > > Thanks, > > Marc > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with sub() due to inability to set encoding of ASCII strings
I'm encountering a problem using sub() on strings in R 3.3.1 in
Windows, using both RGui and RStudio. The problem happens when the
starting string is ASCII, but the replacement string is UTF-8.
If we create an ASCII string x1, its encoding is marked as "unknown",
and doing a sub() on that string with a UTF-8 replacement results in
weird characters:
x1 <- "a b c"
Encoding(x1)
# [1] "unknown"
replacement <- "中文"
Encoding(replacement)
# [1] "UTF-8"
(y1 <- sub("a", replacement, x1))
#[1] "ä¸æ–‡ b c"
Encoding(y1)
# [1] "unknown"
If the starting string x2 has Chinese characters, it'll be marked as
UTF-8, and replacement works fine:
x2 <- "a b c 中文"
Encoding(x2)
# [1] "UTF-8"
(y2 <- sub("a", replacement, x2))
# [1] "中文 b c 中文"
Encoding(y2)
# [1] "UTF-8"
It seems like the solution should be to mark the starting string as
UTF-8, but apparently it doesn't work if the string is ASCII, and so
the sub() still gives weird characters:
# Not possible to mark x1 as UTF-8
Encoding(x1) <- "UTF-8"
Encoding(x1)
# [1] "unknown"
(y3 <- sub("a", replacement, x1))
# [1] "ä¸æ–‡ b c"
Encoding(y3)
# [1] "unknown"
It is possible to tell R that the final string y3 is UTF-8, but it
doesn't seem like this should be necessary:
Encoding(y3) <- "UTF-8"
y3
# [1] "中文 b c"
Is there some way to mark the starting string x1 as UTF-8 so that the
result of sub() comes out marked as UTF-8? If the inputs are both
UTF-8, it shouldn't be necessary to explicitly tell R that the output
is also UTF-8.
-Winston
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Web site for MacOSX R-devel precompiled version
> On Sep 29, 2016, at 8:42 AM, Marc Girondot via R-devel > wrote: > > From several years, I used this site http://r.research.att.com to get a > precompiled version of macosx R-devol but the most recent version is frozen > at the 18/8 build (r 71112). > > Is there an alternative (except than compile myself !) ? > It is the official build - there may be other alternatives but they are not supported by us. The fact that is didn't update would be best reported so we can look into this. I just checked and the build are still working: $ ls -l *.pkg -rw-r--r-- 1 urbanek admin 77935686 Sep 28 23:32 R-devel-mavericks.pkg but it seems that there is a problem with signing the package. I'll look into it. Cheers, Simon > > Thanks, > > Marc > > __ > 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] winbuilder down
Dear all, winbuilder is down. Given current inspection results and circumstances, I expect a downtime of *at least* 24 hours. This applies to on-demand check services, CRAN check service results and CRAN binary builds for Windows. Best, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Web site for MacOSX R-devel precompiled version
[Moving to R-SIG-Mac where it belongs] The machine building 10.6 binaries has died and since it was responsible for merging the 10.9 and 10.6 binaries to the website it means neither were published. 10.9 binaries are now up. > On Sep 29, 2016, at 2:09 PM, Simon Urbanek > wrote: > > >> On Sep 29, 2016, at 8:42 AM, Marc Girondot via R-devel >> wrote: >> >> From several years, I used this site http://r.research.att.com to get a >> precompiled version of macosx R-devol but the most recent version is frozen >> at the 18/8 build (r 71112). >> >> Is there an alternative (except than compile myself !) ? >> > > It is the official build - there may be other alternatives but they are not > supported by us. The fact that is didn't update would be best reported so we > can look into this. I just checked and the build are still working: > > $ ls -l *.pkg > -rw-r--r-- 1 urbanek admin 77935686 Sep 28 23:32 R-devel-mavericks.pkg > > but it seems that there is a problem with signing the package. I'll look into > it. > > Cheers, > Simon > > >> >> Thanks, >> >> Marc >> >> __ >> 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
[Rd] A package that traces base functions
I'm working on a package that implements a REPL. A typical interaction with the package might look like: > launch_REPL()REPL> 1 + 1[1] 2REPL> QDo you wish to save results? [y/n]REPL> > ygoodbye ...> This is very similar to what happens when in `browser()`: the REPL evaluates arbitrary R user expressions and offers some additional commands. In order to implement functionality required for the REPL I must trace some functions in the base package. The trace is removed `on.exit()` from the REPL, so the functions are only modified while the `launch_REPL` function is evaluating. Unfortunately this is against the letter of the law (as per CRAN policy): > A package must not tamper with the code already loaded into R: anyattempt to > change code in the standard and recommended packages whichship with R is > prohibited. Is there any chance that this very limited (only during my function evaluation) modification of base functions with `trace` could be considered to meet the spirit of the law, if not the letter? Package users would be duly notified this is happening. Regards, Brodie Gaslam. PS: More details for those who care: the REPL among other things implements an environment that has for parent `as.environment(2)` so that objects in the global environment are not visible while in the REPL, but otherwise the full search path is. Anytime the search path changes I need to update the REPL environment to re-point to `as.environment(2)`, which means I need to know when the search path changes. I do this by tracing `library`/`attach`/`detach` and triggering a side effect that updates the REPL environment parent any time those are called. The search path itself is untouched. I cannot just parse user expressions searching for those functions as the user can use any arbitrary expressions, including sourcing files that contain the `library`, etc. calls. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
