Re: [Rd] Rgui 3.5.0 print issue
Fixed in R-devel and R-patched. Best Tomas On 06/13/2018 01:36 PM, Tomas Kalibera wrote: Thanks for the report, I can reproduce. In Rgui, the output of "print(cars)" is incorrect, the line numbers appear as part of the command prompt string (printed in reverse order, without newlines), while the rest of the output is correctly displayed. This is a bug, I will have a closer look Best, Tomas On 06/11/2018 11:10 AM, Diego Zardetto wrote: Dear all, I would like to have your opinion about an issue I have recently run into while using tcltk in R 3.5.0 under Windows 7 64bit. Here is a reproducible example of the issue, along with information about platform and OS. ### # R 3.5.0 issue: print does not work properly for data.frames # # when called from a tcltk window. # # # # NOTE: The issue shows up when using Rgui, but disappears # # if Rterm is used. # # # # NOTE: The issue starts with R 3.5.0, and is still there # # in R 3.5.0 patched build for Windows, as well as in # # R-Devel. # ### # Reproducible example library(tcltk) data(cars) win1 <- tktoplevel() butOK <- tkbutton(win1, text = "OK", command = function() print(cars)) tkgrid(butOK) # NOTE: Upon pressing OK, the rownames of cars are not printed on # screen, but end up into R's prompt. # R version and platform info. # R.version _ platform x86_64-w64-mingw32 arch x86_64 os mingw32 system x86_64, mingw32 status major 3 minor 5.0 year 2018 month 04 day 23 svn rev 74626 language R version.string R version 3.5.0 (2018-04-23) nickname Joy in Playing ## # Operating system info. # ## Sys.info() sysname release "Windows" "7 x64" version nodename "build 7601, Service Pack 1" "PC79258" machine login "x86-64" "zardetto" user effective_user "zardetto" "zardetto" I would appreciate any feedback you could provide. Thanks D. [[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] incomplete results from as.character.srcref() in some cases involving quote()
wholeSrcref attribute is documented in ?parse to be the source reference
corresponding to the already parsed text. The implementation in the
parser matches the documentation - the code stops at the last
byte/character of the expression, that is, on the closing brace - which
is the "already parsed text". I think this works as documented (also
source() uses the current implementation of wholeSrcref).
Best
Tomas
On 06/18/2018 04:20 PM, Georgi Boshnakov wrote:
Hi,
The result of as,character() on 'srcref' objects doesn't have the closing ')'
in some cases involving 'quote':
e4 <- quote({2+2})
class(attr(e4, "wholeSrcref"))
[1] "srcref"
as.character(attr(e4, "wholeSrcref"))
[1] "e4 <- quote({2+2}"
As a result printing the object also lacks it and gives an incomplete
expression:
attr(e4, "wholeSrcref")
e4 <- quote({2+2}
It seems that it is the top level quote that suffers from this. Here the inner
'quote' has the matching ')' but the outer one doesn't:
e5 <- quote({quote({2+2})})
class(attr(e5, "wholeSrcref"))
[1] "srcref"
attr(e5, "wholeSrcref")
e5 <- quote({quote({2+2})}
as.character(attr(e5, "wholeSrcref"))
[1] "e5 <- quote({quote({2+2})}"
attributes(e5)
...
$wholeSrcref
e5 <- quote({quote({2+2})}
Attribute 'wholeSrcref' seems undocumented but it is of class 'srcref' which is
documented (eg ?srcref) and has supporting methods.
Georgi Boshnakov
[[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] Automatic Compression by Save Causes Check Warning
Dear Dario, this question may be more suitable for R-pkg-devel or perhaps R-help list, if you have subsequent questions, you might get better advice there. In short, save() does no automated selection of a compression algorithm - it just uses the one specified, by default "gzip". For automated selection, please use resaveRdaFiles(). You can also use "--resave-data" when building your package (see "Building package tarballs" in R-exts) for this to be done automatically for all your data files. Finally, "R CMD check --as-cran" will report when it can find a significantly better compression (note that CRAN policies ask for --as-cran check being run locally before submitting a package, anyway). The CRAN repository policy mentions that packages should be of minimum necessary size and the checks are in line with that (and there are already heuristics in place to avoid the warning if possible gains are small). I don't think in principle things could be made any simpler than they are now: "R CMD check --as-cran" will report a possible improvement by resave, "R CMD build --resave-data" will do the resave. Note that the detection of the best compression algorithm cannot be done without actually compressing the data using different algorithms, which is what resaveRdaFiles() does -- doing this in save() by default is not possible due to the performance overhead. Best Tomas On 06/18/2018 10:00 AM, Dario Strbenac wrote: Good day, Save sometimes chooses a compression method which causes a warning during package checking. An example of this is: measurements <- matrix(round(rnorm(2000*190), 2), nrow = 2000, ncol = 190) classes <- factor(sample(LETTERS[1:2], 190, replace = TRUE)) save(measurements, classes, file = "data/experiment.RData") then, when the package is checked, * checking data for ASCII and uncompressed saves ... WARNING Note: significantly better compression could be obtained by using R CMD build --resave-data old_size new_size compress experiment.RData689Kb447Kbbzip2 Could save and R CMD check consistently agree on a suitable compression scheme? Could R CMD check not emit warnings if the data is already small and the alternative compression doesn't reduce the size much, such as for this example? Perhaps it could only emit warnings when the data file is more than 5 MB and the alternative scheme's resulting file is 50% or more than the size of the existing file. There is also no explanation in Section 1.1.6 Data in Packages of Writing R Extensions that compression of data files is implicitly mandatory for R packages to pass the checking process these days. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia __ 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] incomplete results from as.character.srcref() in some cases involving quote()
Thanks for looking into this and sorry for the noise. I should have realised
that the outermost quote() in my examples is not part of the parsed expression.
Best,
Georgi
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: 20 June 2018 11:01
To: Georgi Boshnakov; r-devel@r-project.org
Subject: Re: [Rd] incomplete results from as.character.srcref() in some cases
involving quote()
wholeSrcref attribute is documented in ?parse to be the source reference
corresponding to the already parsed text. The implementation in the
parser matches the documentation - the code stops at the last
byte/character of the expression, that is, on the closing brace - which
is the "already parsed text". I think this works as documented (also
source() uses the current implementation of wholeSrcref).
Best
Tomas
On 06/18/2018 04:20 PM, Georgi Boshnakov wrote:
> Hi,
>
> The result of as,character() on 'srcref' objects doesn't have the closing
> ')' in some cases involving 'quote':
>
>> e4 <- quote({2+2})
>> class(attr(e4, "wholeSrcref"))
> [1] "srcref"
>> as.character(attr(e4, "wholeSrcref"))
> [1] "e4 <- quote({2+2}"
>
> As a result printing the object also lacks it and gives an incomplete
> expression:
>
>> attr(e4, "wholeSrcref")
> e4 <- quote({2+2}
>
> It seems that it is the top level quote that suffers from this. Here the
> inner 'quote' has the matching ')' but the outer one doesn't:
>
>> e5 <- quote({quote({2+2})})
>> class(attr(e5, "wholeSrcref"))
> [1] "srcref"
>> attr(e5, "wholeSrcref")
> e5 <- quote({quote({2+2})}
>> as.character(attr(e5, "wholeSrcref"))
> [1] "e5 <- quote({quote({2+2})}"
>> attributes(e5)
> ...
>
> $wholeSrcref
> e5 <- quote({quote({2+2})}
>
>
> Attribute 'wholeSrcref' seems undocumented but it is of class 'srcref' which
> is documented (eg ?srcref) and has supporting methods.
>
>
> Georgi Boshnakov
>
>
>
> [[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
[Rd] DOCUMENTATION(?): parallel::mcparallel() gives various types of "Error in unserialize(r) : ..." errors if value is of type raw
I stumbled upon the following: f <- parallel::mcparallel(raw(0L)) parallel::mccollect(f) # $`77083` # NULL but f <- parallel::mcparallel(raw(1L)) parallel::mccollect(f) # Error in unserialize(r) : read error traceback() # 2: unserialize(r) # 1: parallel::mccollect(f) (restarting because the above appears to corrupt the R session) f <- parallel::mcparallel(raw(2L)) parallel::mccollect(f) # Error in unserialize(r) : unknown input format I can reproduce this on Linux using R 3.5.0 all the way back to R 3.3.2 (didn't try further) and R development (unstable) (2018-06-19 r74919). Diving into the code of parallel::mccollect(), it looks that the 'raw' data type has a special purpose: r <- readChild(pid) if (is.integer(r) || is.null(r)) fin[pid == pids] <- TRUE if (is.raw(r)) res[which(pid == pids)] <- list(unserialize(r)) However, I don't see this behavior document in ?parallel::mcparallel. The closest I get is that under the 'Value' section it says: "mccollect returns any results that are available in a list. [...]" Not sure if that should be interpreted as only values that are of type 'list' should be used. OTH, the example use values of type double. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
