Re: [R-pkg-devel] New test in R-devel causes existing packages to fail: "Error: connections left open"
Henrik, Thanks for the suggest. Yes, definitely, I think your more nuanced test would be a big improvement. The only wrinkle is that the connection is established *not* when the package is *loaded* but rather when the connection is *first needed* (using delayedAssign when the package is loaded). That way, loading the package doesn't block the REPL for ~5 seconds while Scala and the JVM first start. -- David On Thu, Aug 23, 2018 at 11:19 PM Henrik Bengtsson wrote: > > Does R CMD check --as-cran test for newly opened connections or any > open connections? Could the check for stray connection in > examples/vignettes be: > > 1. Record what connections are open > 2. Attach the package > 3. Record what connections are open > 4. Run the example > 5. Assert that no *new* connections in addition to what's recorded in > Step 3 are open > 6. Unload the package > 7. Assert that no *new* connections in addition to what's recorded in > Step 1 are open > > Step 5 asserts that the code in the example does not leave stray > connections behind, and Step 7 that the package itself does not leave > stray connections behind. > > /Henrik > On Thu, Aug 23, 2018 at 1:25 PM David B. Dahl wrote: > > > > Oops, I accidentally did not "reply-all" Here is my message: > > > > Thanks Uwe, Duncan, and Gabor for the response, advise, and flexibility. > > > > Regarding Uwe's suggestion: "... there should be a function that > > creates the connction and one that closes the connection," I should > > clarify. The rscala package does just that. There is a function > > (named "scala") that creates the connection (using delayedAssign) and > > another the closes the function (namely an S3 close method). The > > examples for the rscala package do this full open/close semantics, > > but... > > > > The problem comes when authors of another package, let's call it the > > "FooBar" package, want to implement an algorithm in Scala based on > > functionality provided by the rscala package. Let's say they write a > > function called "neatAlgorithm" based on Scala. Yes, the FooBar > > package author could require that, before the user calls the > > "neatAlgorithm" function, they first call a function to set up the > > connection (which itself would call the "rscala::scala" function) and > > then, after calling the "neatAlgorithm" function, they call a function > > to close the connection. > > > > But that is not very user friendly and exposes the user to > > implementation details of the algorithm. The user of the FooBar > > package don't really care whether the "neatAlgorithm" is implemented > > in pure R, C++, Scala, or whatever, much like the users of the 'lm' > > function don't need to know the implementation details or do any setup > > before and after calling the function. > > > > The current approach is that the connection to Scala is transparent to > > the end user of a package. Behind the scenes, the package author > > establish the connection once it is needed and the rscala package > > manages the connection and explicitly closes it when 1. the package is > > unloaded or 2. the R session ends. This approach does not leave > > dangling connections --- which I believe is the point of the new test > > --- yet my package is caught up in the test. > > > > I hope that this approach is still valid. Perhaps the test could > > result in a warning (instead of an error) and CRAN could accept > > packages with such a warning. > > > > If not, a work-around is to have a \dontshow section in the examples > > that will close the connection (but leave the Scala process running) > > and then automatically reestablish the connection as needed. This > > would not be very efficient but, as Duncan mentioned, it mostly only > > effects the package examples themselves. Plus, it would not be too > > burdensome for package developers. > > > > Again, thanks for considering my situation. > > > > Best regards, > > > > -- David > > > > On Mon, Aug 20, 2018 at 11:11 PM Uwe Ligges > > wrote: > > > > > > My advise: > > > > > > Apparently you want to have communication via sockets to scala. > > > > > > So there should be a function that creates the connction and one tha > > > closes the connection. > > > Comparable to starting some parallel cluster and stopping it again. > > > > > > In the meantime, you can allow for all sorts of communication. > > > > > > So that's fine. > > > > > > Then in your examples, simply design them to be standalone, i.e. in > > > *your* examples always start the connection and stop it again at the end > > > of one examples block, i.e. the exampels defined in one Rd file. > > > > > > Best, > > > Uwe Ligges > > > > > > > > > > > > On 20.08.2018 02:11, Duncan Murdoch wrote: > > > > On 19/08/2018 12:34 PM, Gábor Csárdi wrote: > > > >> Sorry, missed that these were examples, so, yeah, that's harder. G. > > > > > > > > How about a function that checks if the connection is open before doing > > > > anything, and then at the end you
Re: [Rd] Where does L come from?
> the lack of a decimal place had historically not been significant Version 4 of S (c. 1991) and versions of S+ based on it treated a sequence of digits without a decimal point as integer. Bill Dunlap TIBCO Software wdunlap tibco.com On Sat, Aug 25, 2018 at 4:33 PM, Duncan Murdoch wrote: > On 25/08/2018 4:49 PM, Hervé Pagès wrote: > >> The choice of the L suffix in R to mean "R integer type", which >> is mapped to the "int" type at the C level, and NOT to the "long int" >> type, is really unfortunate as it seems to be misleading and confusing >> a lot of people. >> > > Can you provide any evidence of that (e.g. a link to a message from one of > these people)? I think a lot of people don't really know about the L > suffix, but that's different from being confused or misleaded by it. > > And if you make a criticism like that, it would really be fair to suggest > what R should have done instead. I can't think of anything better, given > that "i" was already taken, and that the lack of a decimal place had > historically not been significant. Using "I" *would* have been confusing > (3i versus 3I being very different). Deciding that 3 suddenly became an > integer value different from 3. would have led to lots of inefficient > conversions (since stats mainly deals with floating point values). > > Duncan Murdoch > > > >> The fact that nowadays "int" and "long int" have the same size on most >> platforms is only anecdotal here. >> >> Just my 2 cents. >> >> H. >> >> On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: >> >>> >>> On 25 August 2018 at 09:28, Carl Boettiger wrote: >>> | I always thought it meant "Long" (I'm assuming R's integers are long >>> | integers in C sense (iirrc one can declare 'long x', and it being >>> common to >>> | refer to integers as "longs" in the same way we use "doubles" to mean >>> | double precision floating point). But pure speculation on my part, so >>> I'm >>> | curious! >>> >>> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & >>> Ritchie. It >>> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and >>> 'long' is >>> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for >>> constants. So >>> "back then when" 32 bit was indeed long. And as R uses 32 bit integers >>> ... >>> >>> (It is all murky because the size is an implementation detail and later >>> "essentially everybody" moved to 32 bit integers and 64 bit longs as the >>> 64 >>> bit architectures became prevalent. Which is why when it matters one >>> should >>> really use more explicit types like int32_t or int64_t.) >>> >>> Dirk >>> >>> >> > __ > 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
[R-pkg-devel] compiling a Windows package with the PGI compiler
Hello! I am building a new package with source code that requires the Portland group compiler. How would I go about building the package with this compiler rather than gfortran, please? Thank you in advance. Sincerely, Erin PS. Windows 10, and R-3.5.1. Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Thanks for help with validspamobject
I'm curious about a warning coming from the use of package sqldf. I opened a file and read it using a SQLite select statement: f = "/Users/ronaldbarry/Desktop/Three-Dee/LakeMichDepth.txt" > sql_statement = "select long,lat,depth,(lat - 41.62) as templat, (long + > 88) as templong > from file > where (abs(templat - 0.1*round(templat/0.1,0)) < 0.01)and(abs(templong - > 0.15*round(templong/0.15,0)) < 0.01)" > Mich_depth = sqldf::read.csv.sql(file=f,sql = > sql_statement,header=TRUE,sep=' ') Which ran perfectly well, but it threw a warning: Warning messages: 1: In stopifnot(is.list(hooks)) : closing unused connection 6 (/Users/ronaldbarry/Desktop/Three-Dee/LakeMichDepth.txt) 2: In stopifnot(is.list(hooks)) : closing unused connection 5 (/Users/ronaldbarry/Desktop/Three-Dee/LakeMichDepth.txt) It looks like it would be good practice to close the connection in code, but I don't see any function in sqldf to do so. Is there a way to nicely close the connection, or should I just ignore the warning? Operating system is Mac OSX 13.16 High Sierra, R Studio version 1.1.146, R version 3.5.0. Thanks for any info. On Thu, Aug 16, 2018 at 12:00 PM, Ronald Barry wrote: > Hi, > Thanks for all your help. The problem with an error involving > validspamobject() has been resolved, as a new version of spdep (0.7-7) was > just released and it seems to have stopped using the deprecated function. > > Ron B. > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposed patch to /src/library/datasets/man/mtcars.Rd
Mara Averick noticed some oddities in the mtcars data set:
https://twitter.com/dataandme/status/1033341784959709184
I propose the following patch. While anyone with access to JSTOR could
dig in and find this information themselves, it would seem a friendly
gesture to include it ...
cheers
Ben Bolker
===
--- mtcars.Rd (revision 75186)
+++ mtcars.Rd (working copy)
@@ -35,6 +35,14 @@
Building multiple regression models interactively.
\emph{Biometrics}, \bold{37}, 391--411.
}
+\details{
+Henderson and Velleman (1981) comment in a footnote to Table 1:
+\sQuote{Hocking [original transcriber]'s noncrucial coding of the
+Mazda's rotary engine as a straight six-cylinder engine and the
+Porsche's flat engine as a V engine, as well as the inclusion of the diesel
+Mercedes 240D, have been retained to enable direct comparisons to be made
+with previous analyses.}
+}
\examples{
require(graphics)
pairs(mtcars, main = "mtcars data", gap = 1/4)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath degree symbol
Hello, Same here. Tested on R 3.1.1 and R 3.5.1 and they look *exactly* the same. Hope this helps, Rui Barradas On 26/08/2018 22:36, Paul Murrell wrote: Hi Sorry, but this seems to be working ok for me ... > sessionInfo() R version 3.4.2 (2017-09-28) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.5 LTS Matrix products: default BLAS: /usr/lib/libblas/libblas.so.3.6.0 LAPACK: /usr/lib/lapack/liblapack.so.3.6.0 locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8 LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.2 ... and ... > sessionInfo() R Under development (unstable) (2018-08-22 r75177) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix products: default BLAS: /home/pmur002/R/r-devel/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/r-devel/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8 LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics utils datasets grDevices methods base loaded via a namespace (and not attached): [1] compiler_3.6.0 ... what is your setup ? Paul On 25/08/18 05:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. --- This email has been checked for viruses by AVG. https://www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath degree symbol
Hi Sorry, but this seems to be working ok for me ... > sessionInfo() R version 3.4.2 (2017-09-28) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.5 LTS Matrix products: default BLAS: /usr/lib/libblas/libblas.so.3.6.0 LAPACK: /usr/lib/lapack/liblapack.so.3.6.0 locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.2 ... and ... > sessionInfo() R Under development (unstable) (2018-08-22 r75177) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix products: default BLAS: /home/pmur002/R/r-devel/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/r-devel/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics utils datasets grDevices methods base loaded via a namespace (and not attached): [1] compiler_3.6.0 ... what is your setup ? Paul On 25/08/18 05:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] The warning about 'biocLite()'
What is the name of your package? It is possible it could be coming from one of the packages you depend or import. If you are sure you replaced all the instances in your package this could be the case. Lori Shepherd Bioconductor Core Team Roswell Park Cancer Institute Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of r04945...@ntu.edu.tw Sent: Sunday, August 26, 2018 4:26:05 PM To: bioc-devel Subject: [Bioc-devel] The warning about 'biocLite()' Hi, I have already use 'BiocManager' to replace every 'biocLite' in my code, like vignette and README, but I still got "Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the 'BiocManager' CRAN" in my report. Any suggestion? Best, Ti Tai ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] The warning about 'biocLite()'
Hi, I have already use 'BiocManager' to replace every 'biocLite' in my code, like vignette and README, but I still got "Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the 'BiocManager' CRAN" in my report. Any suggestion? Best, Ti Tai ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Where does L come from?
As long as we're on this point about not many users knowing about "L" notation, I'm going bump my earlier suggestion that it be at least mentioned in the `? integer` documentation page: https://stat.ethz.ch/pipermail/r-devel/2018-May/076203.html Cheers, -Thomas > From: Duncan Murdoch > To: =?UTF-8?B?SGVydsOpIFBhZ8Oocw==?= , Dirk > Eddelbuettel , Carl Boettiger > Subject: Re: [Rd] Where does L come from? > > On 25/08/2018 4:49 PM, Hervé Pagès wrote: > > The choice of the L suffix in R to mean "R integer type", which > > is mapped to the "int" type at the C level, and NOT to the "long int" > > type, is really unfortunate as it seems to be misleading and confusing > > a lot of people. > > Can you provide any evidence of that (e.g. a link to a message from one > of these people)? I think a lot of people don't really know about the L > suffix, but that's different from being confused or misleaded by it. > > And if you make a criticism like that, it would really be fair to > suggest what R should have done instead. I can't think of anything > better, given that "i" was already taken, and that the lack of a decimal > place had historically not been significant. Using "I" *would* have > been confusing (3i versus 3I being very different). Deciding that 3 > suddenly became an integer value different from 3. would have led to > lots of inefficient conversions (since stats mainly deals with floating > point values). > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
