[Rd] Advice debugging M1Mac check errors
Hi, I wanted to ask if people have good advice on how to debug M1Mac package check errors when you don´t have a Mac? Is a cloud machine the best option or is there something else? Thanks Holger [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] replacements of sprintf in compiled code
Hi, thanks for the tip! Is that available everywhere or do I need to set compiler requirements? Best Holger Hoefling On Sat, Jan 21, 2023 at 11:27 AM Duncan Murdoch wrote: > On 21/01/2023 5:15 a.m., Holger Hoefling wrote: > > Hi, > > > > In my recent re-submission with a bug-fix of the hdf5r package, I got a > new > > set of warnings from the compiler, one being that I shouldn't be using > > 'sprintf'. > > > > Is there a simple replacement that I can use? > > You should use snprintf() which has an extra argument to state the size > of the buffer receiving the string. For example, > > char text[32]; > sprintf(text, "%.4g", value); > > could be written as > > char text[32]; > snprintf(text, 32, "%.4g", value); > > This will write a string with at most 31 characters before the NUL at > the end, and avoids the possibility of a buffer overrun. > > Duncan Murdoch > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] replacements of sprintf in compiled code
Hi, In my recent re-submission with a bug-fix of the hdf5r package, I got a new set of warnings from the compiler, one being that I shouldn't be using 'sprintf'. Is there a simple replacement that I can use? Thanks Holger Hoefling [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Notes from rchk on hdf5r package
Hi all,
I have been submitting a bug-fix version of a package and was alerted
to some notes that rchk brought up for it.
A link to the notes
https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/hdf5r.out
and to the version of the code the package refers to
https://github.com/cran/hdf5r/blob/master/src/convert.c
To be more specific:
The errors are more specific about usage of Rf_lang2 and Rf_lang1. I
am not very familiar with them and would appreciate some guidance on
how to fix.
Example
Suspicious call (two or more unprotected arguments) to Rf_lang2 at
H5ToR_Post_REFERENCE hdf5r/src/convert.c:1140
Code: SEXP hdf5r_ns = PROTECT(eval(lang2(install("getNamespace"), mkString("
hdf5r")), R_GlobalEnv));
I assume this can be fixed by wrapping the "install" and "mkString" in
an additional PROTECT? Is this what it is complaining about?
The other:
calling allocating function Rf_eval with argument allocated using
Rf_lang3(S:set_ref.H5R,?,?) hdf5r/src/convert.c:1141
Code:
eval(lang3(install("set_ref.H5R"), result, _Robj), hdf5r_ns);
I remember cobbling these parts together off of the internet and don't
understand enough about the internals of R functions to know what is
going wrong and how to fix.
Any help anyone can offer would be appreciated.
Thank you!
Holger
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Fwd: Re-creating vignettes after update of data or different mechanism to create reports?
Hi Rainer, thanks for the explanation. You probably already considered this - but you could version-bump the analysis package with every data package update (and make the latest data package the minimum requirement). Given how large the data package is - the overhead of an analysis package version bum seems small. Then people would update the analysis package - which would trigger the data package update and the vignette would be built correctly. That being said - how exactly this would work may also depend on how you plan to host this large package (CRAN would likely not accept it). Bioconductor on the other hand requires version bumps for every package for every release anyway - so this concurs with my suggestion. Best Holger On Thu, May 11, 2017 at 2:43 PM, Rainer Krug <rai...@krugs.de> wrote: > Sorry - forgot to cc the list > > > Begin forwarded message: > > > > From: Rainer Krug <rai...@krugs.de> > > Subject: Re: [R-pkg-devel] Re-creating vignettes after update of data or > different mechanism to create reports? > > Date: 11 May 2017 at 14:41:03 GMT+2 > > To: Holger Hoefling <hhoef...@gmail.com> > > > > > >> On 11 May 2017, at 14:35, Holger Hoefling <hhoef...@gmail.com hhoef...@gmail.com>> wrote: > >> > >> Hi Rainer, > >> > >> could you elaborate a little more on why you split this into two > packages in the first place? If you all kept it in one, you would have to > update this package regularly - but rebuilding the vignette would not be a > problem. > >> > >> As you designed it with 2 packages - you also have to update the data > package regularly. > >> > >> I guess I just don't understand what you gain by splitting the packages. > > > > I am aware that I wouldn’t have this problem with a single package, but > there are some reasons why I would like to keep them separate (see below): > > > > 1) The dataset will be huge. So combining it with the analysis package > is not a good idea in case that the analysis package needs to be updated > and the data package stays the same. > > > > 2) I like the separation between data package and analysis package - it > is cleaner > > > > 3) The data is not (but will hopefully be sometime later) public. So we > can have two versions of the data package: one for internal usage, and one > witch dummy data which can be made publicly available, as we want to make > the code of the analysis public. > > > > Hope this explains why I want to keep them separate, > > > > Rainer > > > >> > >> Best > >> > >> Holger > >> > >> On Thu, May 11, 2017 at 2:31 PM, Rainer Krug <rai...@krugs.de rai...@krugs.de>> wrote: > >> Hi > >> > >> I am building two packages: > >> > >> - a data package which contains the data and function to extract it > (several datasets, linked, like an sql database) and > >> - an analysis package which contains functions to analyse the data in > the data package and depends on the data package. > >> > >> The data package is updated often as the data is updated regularly, > while the analysis package will (hopefully) be more static. > >> > >> Now I created a report which I put in the vignette of the analysis > package, which works nicely and the report is created when the analysis > package is installed, but when the data package is updated, the user has to > re-install the analysis package to re-create the report (vignette) of the > updated dataset. > >> > >> I know that I am abusing the vignette, but it works nicely. > >> > >> My question: Is there a way of re-creating the vignette by a user > after they installed a newer version of the data package, or is there a > better way of creating the report(s)? > >> > >> Thanks, > >> > >> Rainer > >> > >> -- > >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > >> > >> University of Zürich > >> > >> Cell: +41 (0)78 630 66 57 <tel:%2B41%20%280%2978%20630%2066%2057> > >> > >> Fax (D):+49 - (0)3 21 21 25 22 44 <tel:%2B49%20-%20%280%293% > 2021%2021%2025%2022%2044> > >> > >> email: rai...@krugs.de <mailto:rai...@krugs.de> > >> > >> Skype: RMkrug > >> > >> > >> __ > >> R-package-devel@r-project.org <mailto:R-package-devel@r-project.org> > mailing list > >
Re: [R-pkg-devel] Source code of an existing package
Hi, If you are interested in the source code of an entire package in its original form - you can also download the .tar.gz version of the package from CRAN. In a .tar.gz, you find the sources, unlike the .zip for windows, which is already compiled. If you are under windows, you can use a program such as 7-zip to unzip the .tar.gz (which is mostly used on unix systems). The R code of the package is in the R subfolder In your case, the function boot.ci, is in R/bootfuns.q and starts in the latest version on line 859 Best Holger On Thu, Aug 11, 2016 at 3:42 AM, Marcelo Carvalho Fernandes < mcf2...@gmail.com> wrote: > Hi all! > > I am interested in seeing the source code of the boot.ci() function of > the boot package. > > Is it possible to have such source code? How? > > Thanks in advance, > > --- > Marcelo Carvalho Fernandes > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] A package requiring cmake
Hi, I am currently preparing a package for hdf5 that ships and compiles from source on windows. The intention here is to avoid having to ship or download a binary from an unknown source. As a dependency, I need the cmake program installed. Here my question: 1. Is cmake installed on win-builder? If not, could it be installed? If yes, in a specified standard location or available through the PATH variable? 2. How do I specify that a package is only intended for a specific OS? On another note here: The package I am preparing would only compile the binaries on windows. On other systems, I would prefer to have people install them thought native services (e.g. apt-get) to make configuration etc. more manageable for system administrators (even though that puts a little more burden on the end-user on these systems). Second question: Is there a way to specify an OS-specific dependency? As the hdf5lib package is rather large and intended for windows only, I would prefer if it isn't downloaded anywhere else. thanks for your help Holger [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package manuals as html page instead of pdf
Hi, I wanted to pose a question to the R developers that I was wondering about for a while. Currently, the standard way of rendering the manual of an R package on CRAN is in the form of a pdf-file. From my perspective, this pdf-file has many drawbacks: - It makes the load (relatively) long - requires at least a plug-in in a browser, - breaks the forward-backward functionality of browser - Does not contain reformattable text so that the monitor space cannot be optimally used when displaying it - Has many page breaks that require space on the monitor and need to be skipped over - Introduces the dependency on latex itself. Therefore, I wanted to ask if the R core team has thought about moving away from pdf-manuals and on to (single page) HTML manuals? I think that would have several advantages, those being - faster loadtimes - could still be sent around as a single file - Are more flexible on how the text would be displayed - forward-backward navigation in the browser and browser full text search would work Of course, printing it would be slightly worse out of an HTML document than it currently is from a pdf. Thank you already for providing comments Holger [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question about CHARSXP and garbage collection
Hi, I had a technical question about CHARSXP and garbage collection and couldn't find the answer in the R manual. The question is this. Are CHARSXP garbage collected like any other object, despite being part of the CHARSXP cache? i.e. is the cache being cleaned by garbage collection regularly and therefore, when I am in C code, do I need to protect a CHARSXP? Thanks! Holger [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Different serialization of functions in interactive vs. batch mode
Hi Luke,
Ah - I see - thank you! This at least points me to a way on how to
fix this. I tried setting the srcref attribute to NULL, but the hash
value is still different and so is the serialization. So this looks
like it is one difference, but not all of them
Even if all differences were identified - it still leaves me with
different behavior between interactive and batch-mode, though. I am
curious as to why that is. Do you know why in interactive mode the
attribute with the srcref is set, but not in batch mode?
Thanks!
Holger
P.S. I attached the output I get when i set the attributes to NULL
On Wed, Feb 18, 2015 at 3:04 PM, luke-tier...@uiowa.edu wrote:
Add
attributes(testfun)
and you will see where the two functions differ.
luke
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I am using hash-values to cache certain results in R. This caching
also depends on the hash-value of the function that is being cached
(calculated using the digest package). I noticed that computations
that should already be cached are recomputed when switching from an
interactive session to a BATCH session. Therefore, I wrote a test
script
library(digest)
testfun - function() {
return(NULL)
}
testval - testval
print(digest(testfun))
print(serialize(testfun, connection = NULL))
and executed it once using input-redirection from a file (testFile.R)
and once copying the code into an interactive R session. The
hash-values of the functions differ. As digest internally relies on
serialize, I also checked there and found that digest is not the
reason for the discrepancy. Instead, the serialized value of the
function already differs between the BATCH and inteactive sessions.
I was wondering if someone knows if
1. Is this a feature or a bug? It feels like a bug to me as all the
inputs are identical, I would expect that the output is identical as
well. Is there something I am overlooking?
2. Is there a way to get consistent hash-values for functions between
BATCH and interactive sessions.
The output from the BATCH and interactive runs are below (as well as
sessionInfo)
Thank you very much for your help!
Holger Hoefling
-
BATCH run (via input redirection):
$ R --vanilla testFile.R
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] b03160b9250f0d5b5bcce42bd86d8e56
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 04 03 00 00 00 fd 00
00 00
[26] fe 00 00 00 06 00 00 00 01 00 04 00 09 00 00 00 01 7b 00 00 00 02 00
00 00
[51] 06 00 00 00 01 00 04 00 09 00 00 00 06 72 65 74 75 72 6e 00 00 00 02
00 00
[76] 00 fe 00 00 00 fe 00 00 00 fe
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] digest_0.6.4
--
Interactive run:
$ R --vanilla
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] fada482d2894088b079a8e56b7044862
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 06 03 00 00 04 02 00
00 00
[26] 01 00 04 00 09 00 00 00 06 73 72 63 72 65 66 00 00 03 0d 00 00 00 08
00 00
[51] 00 01 00 00 00 0c 00 00 00 03 00 00 00 01 00 00 00 0c 00 00 00 01 00
00 00
[76] 01 00 00 00 03 00 00 04 02 00 00 00 01 00
[Rd] Different serialization of functions in interactive vs. batch mode
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I am using hash-values to cache certain results in R. This caching
also depends on the hash-value of the function that is being cached
(calculated using the digest package). I noticed that computations
that should already be cached are recomputed when switching from an
interactive session to a BATCH session. Therefore, I wrote a test
script
library(digest)
testfun - function() {
return(NULL)
}
testval - testval
print(digest(testfun))
print(serialize(testfun, connection = NULL))
and executed it once using input-redirection from a file (testFile.R)
and once copying the code into an interactive R session. The
hash-values of the functions differ. As digest internally relies on
serialize, I also checked there and found that digest is not the
reason for the discrepancy. Instead, the serialized value of the
function already differs between the BATCH and inteactive sessions.
I was wondering if someone knows if
1. Is this a feature or a bug? It feels like a bug to me as all the
inputs are identical, I would expect that the output is identical as
well. Is there something I am overlooking?
2. Is there a way to get consistent hash-values for functions between
BATCH and interactive sessions.
The output from the BATCH and interactive runs are below (as well as
sessionInfo)
Thank you very much for your help!
Holger Hoefling
-
BATCH run (via input redirection):
$ R --vanilla testFile.R
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] b03160b9250f0d5b5bcce42bd86d8e56
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 04 03 00 00 00 fd 00 00 00
[26] fe 00 00 00 06 00 00 00 01 00 04 00 09 00 00 00 01 7b 00 00 00 02 00 00 00
[51] 06 00 00 00 01 00 04 00 09 00 00 00 06 72 65 74 75 72 6e 00 00 00 02 00 00
[76] 00 fe 00 00 00 fe 00 00 00 fe
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] digest_0.6.4
--
Interactive run:
$ R --vanilla
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] fada482d2894088b079a8e56b7044862
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 06 03 00 00 04 02 00 00 00
[26] 01 00 04 00 09 00 00 00 06 73 72 63 72 65 66 00 00 03 0d 00 00 00 08 00 00
[51] 00 01 00 00 00 0c 00 00 00 03 00 00 00 01 00 00 00 0c 00 00 00 01 00 00 00
[76] 01 00 00 00 03 00 00 04 02 00 00 00 01 00 04 00 09 00 00 00 07 73 72 63 66
[101] 69 6c 65 00 00 00 04 00 00 00 00 00 00 00 f2 00 00 04 02 00 00 00 01 00 04
[126] 00 09 00 00 00 05 6c 69 6e 65 73 00 00 00 10 00 00 00 01 00 04 00 09 00 00
[151] 00 2b 74 65 73 74 66 75 6e 20 3c 2d 20 66 75 6e 63 74 69 6f 6e 28 29 20 7b
[176] 0a 20 20 20 20 72 65 74 75 72 6e 28 4e 55 4c 4c 29 0a 7d 0a 00 00 04 02 00
[201] 00 00 01 00 04 00 09 00 00 00 08 66 69 6c 65 6e 61 6d 65 00 00 00 10 00 00
[226] 00 01 00 04 00 09 00 00 00 00 00 00 00 fe 00 00 00 fe 00 00 04 02 00 00 00
[251] 01 00 04 00 09 00 00 00 05 63 6c 61 73 73 00 00 00 10 00 00 00 02 00 04 00
[276] 09 00 00 00 0b 73 72 63 66 69 6c 65 63 6f 70 79 00 04 00 09 00 00 00 07 73
[301] 72 63 66 69 6c 65 00 00 00 fe 00 00 04 02 00 00 06 ff 00 00 00 10 00 00 00
[326] 01 00 04 00 09 00 00 00 06 73 72 63 72 65 66 00 00 00 fe 00 00 00 fe 00 00
[351] 00 fd 00 00 00 fe 00 00 02 06 00 00 04 02 00 00 01 ff
Re: [Rd] Different serialization of functions in interactive vs. batch mode
Luke, thank you so much - that solves my problem!
Holger
On Wed, Feb 18, 2015 at 3:56 PM, luke-tier...@uiowa.edu wrote:
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi Luke,
Ah - I see - thank you! This at least points me to a way on how to
fix this. I tried setting the srcref attribute to NULL, but the hash
value is still different and so is the serialization. So this looks
like it is one difference, but not all of them
when source attributes are attached they are attached to calls within
the body as well, so
attributes(body(testfun))
$srcref
$srcref[[1]]
...
Even if all differences were identified - it still leaves me with
different behavior between interactive and batch-mode, though. I am
curious as to why that is. Do you know why in interactive mode the
attribute with the srcref is set, but not in batch mode?
I can't speak to why the default for the keep.source option is
different in the two cases, but you can set it to be the same: in
interactive mode
options(keep.source = FALSE)
testfun - function() {return(NULL)}
digest(testfun)
[1] b03160b9250f0d5b5bcce42bd86d8e56
Or use options(keep.source = TRUE) in the other case.
Best,
luke
Thanks!
Holger
P.S. I attached the output I get when i set the attributes to NULL
On Wed, Feb 18, 2015 at 3:04 PM, luke-tier...@uiowa.edu wrote:
Add
attributes(testfun)
and you will see where the two functions differ.
luke
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I am using hash-values to cache certain results in R. This caching
also depends on the hash-value of the function that is being cached
(calculated using the digest package). I noticed that computations
that should already be cached are recomputed when switching from an
interactive session to a BATCH session. Therefore, I wrote a test
script
library(digest)
testfun - function() {
return(NULL)
}
testval - testval
print(digest(testfun))
print(serialize(testfun, connection = NULL))
and executed it once using input-redirection from a file (testFile.R)
and once copying the code into an interactive R session. The
hash-values of the functions differ. As digest internally relies on
serialize, I also checked there and found that digest is not the
reason for the discrepancy. Instead, the serialized value of the
function already differs between the BATCH and inteactive sessions.
I was wondering if someone knows if
1. Is this a feature or a bug? It feels like a bug to me as all the
inputs are identical, I would expect that the output is identical as
well. Is there something I am overlooking?
2. Is there a way to get consistent hash-values for functions between
BATCH and interactive sessions.
The output from the BATCH and interactive runs are below (as well as
sessionInfo)
Thank you very much for your help!
Holger Hoefling
-
BATCH run (via input redirection):
$ R --vanilla testFile.R
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] b03160b9250f0d5b5bcce42bd86d8e56
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 04 03 00 00 00 fd 00
00 00
[26] fe 00 00 00 06 00 00 00 01 00 04 00 09 00 00 00 01 7b 00 00 00 02
00
00 00
[51] 06 00 00 00 01 00 04 00 09 00 00 00 06 72 65 74 75 72 6e 00 00 00
02
00 00
[76] 00 fe 00 00 00 fe 00 00 00 fe
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] digest_0.6.4
--
Interactive run:
$ R --vanilla
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many
Re: [Rd] Different serialization of functions in interactive vs. batch mode
Hi Gabriel,
thanks for your reply - it does solve the problem of my toy function,
but does come with some other problems though.
a) as.list(f)[[1]] yields an expression, not a function. In order to
go the route you are suggesting, I would more likely use deparse in
order to get the original back
b) and more seriously - as.list strips the environment of the function
(and thus associated information) as well as information about parent
environments. For the execution of a function, this would however be
crucial. This is also why a pure deparse alone in my opinion would
not work.
Thanks
Holger
On Wed, Feb 18, 2015 at 3:36 PM, Gabriel Becker gmbec...@ucdavis.edu wrote:
Holger,
For me (see session info) using
digest(as.list(f))
gets around this problem.
~G
sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] digest_0.6.8
On Wed, Feb 18, 2015 at 6:22 AM, Holger Hoefling hhoef...@gmail.com wrote:
Hi Luke,
Ah - I see - thank you! This at least points me to a way on how to
fix this. I tried setting the srcref attribute to NULL, but the hash
value is still different and so is the serialization. So this looks
like it is one difference, but not all of them
Even if all differences were identified - it still leaves me with
different behavior between interactive and batch-mode, though. I am
curious as to why that is. Do you know why in interactive mode the
attribute with the srcref is set, but not in batch mode?
Thanks!
Holger
P.S. I attached the output I get when i set the attributes to NULL
On Wed, Feb 18, 2015 at 3:04 PM, luke-tier...@uiowa.edu wrote:
Add
attributes(testfun)
and you will see where the two functions differ.
luke
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I am using hash-values to cache certain results in R. This caching
also depends on the hash-value of the function that is being cached
(calculated using the digest package). I noticed that computations
that should already be cached are recomputed when switching from an
interactive session to a BATCH session. Therefore, I wrote a test
script
library(digest)
testfun - function() {
return(NULL)
}
testval - testval
print(digest(testfun))
print(serialize(testfun, connection = NULL))
and executed it once using input-redirection from a file (testFile.R)
and once copying the code into an interactive R session. The
hash-values of the functions differ. As digest internally relies on
serialize, I also checked there and found that digest is not the
reason for the discrepancy. Instead, the serialized value of the
function already differs between the BATCH and inteactive sessions.
I was wondering if someone knows if
1. Is this a feature or a bug? It feels like a bug to me as all the
inputs are identical, I would expect that the output is identical as
well. Is there something I am overlooking?
2. Is there a way to get consistent hash-values for functions between
BATCH and interactive sessions.
The output from the BATCH and interactive runs are below (as well as
sessionInfo)
Thank you very much for your help!
Holger Hoefling
-
BATCH run (via input redirection):
$ R --vanilla testFile.R
R version 3.1.0 (2014-04-10) -- Spring Dance
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library(digest)
testfun - function() {
+ return(NULL)
+ }
print(digest(testfun))
[1] b03160b9250f0d5b5bcce42bd86d8e56
print(serialize(testfun, connection = NULL))
[1] 58 0a 00 00 00 02 00 03 01 00 00 02 03 00 00 00 04 03 00 00 00 fd
00
00 00
[26] fe 00 00 00 06 00 00 00 01 00 04 00 09 00 00 00 01 7b 00 00 00 02
00
00 00
[51] 06 00 00 00 01 00 04 00 09 00 00 00 06 72 65 74 75 72 6e
