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] tibbles are not data frames
Hi Thierry, You write: "If a package requires a data.frame, then it is up to the _user_ to provide a data.frame (and a tibble is not a data.frame). " Actually, as pointed out before, calling is.data.frame on a tibble returns TRUE. So I think that R says - yes, a tibble is a data frame. What would be the point of having a "is.data.frame" function, if you can't trust its answer? And you can also look at it from the other side: Why does tibble need to inherit from a data.frame? I don't know exactly what the original intention behind this was, but I would guess that it was intended to make tibbles a drop-in replacement for data.frames. And it looks like it is not succeeding at this task. Best Holger Hoefling On Tue, Sep 26, 2017 at 1:32 PM, Thierry Onkelinx wrote: > Dear all, > > IMHO the problem is being look at from the wrong perspective. The > tibble doesn't change the data.frame, it uses all methods from > data.frame which it doesn't implement itself. Hence it behaves like at > data.frame to some extent. > > If a package requires a data.frame, then it is up to the _user_ to > provide a data.frame (and a tibble is not a data.frame). Documenting > this in the package documentation/FAQ or issuing a warning "don't use > tibble" when the package is loaded should be sufficient. > > Best regards, > > ir. Thierry Onkelinx > Statisticus/ Statistician > > Vlaamse Overheid / Government of Flanders > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE > AND FOREST > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance > thierry.onkel...@inbo.be > Kliniekstraat 25, B-1070 Brussel > www.inbo.be > > > /// > To call in the statistician after the experiment is done may be no > more than asking him to perform a post-mortem examination: he may be > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does > not ensure that a reasonable answer can be extracted from a given body > of data. ~ John Tukey > > /// > > > Van 14 tot en met 19 december 2017 verhuizen we uit onze vestiging in > Brussel naar het Herman Teirlinckgebouw op de site Thurn & Taxis. > Vanaf dan ben je welkom op het nieuwe adres: Havenlaan 88 bus 73, 1000 > Brussel. > > > /// > > > 2017-09-26 13:18 GMT+02:00 Joris Meys : > > > > On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi > > wrote: > > > > > > > > I have yet to see an OOP system in which a subclass cannot override the > > > methods > > > of its superclass. Not only is this in line with OOP paradigms, it is > > > actually one of > > > the essential OOP features. > > > > > > > Fair enough. And I shouldn't have used the word "inherit" in the first > > place, we're talking S3 after all. Fwiw, overriding a method to do the > > exact same except for one detail isn't encouraged in the OOP world > either. > > > > > > > To be more constructive, if you have a function that only works with > > > data frame inputs, then > > > it is good practice to check that the supplied input is indeed a data > > > frame. This is > > > independent of tibbles. > > > > > > > Actually it's not independent of tibbles as illustrated by others. > > is.data.frame() returns TRUE for tibbles. It doesn't for matrices or > > vectors. > > > > > > > > > > In practice it seems to me that an easy fix is to just call > > > as.data.frame on the input. This should > > > either convert it to a data frame, or throw an error. For tibbles it > > > drops the tbl* classes. > > > > > > > This would also allow matrices or vectors to be converted to data.frames, > > and that might or might not be warranted. > > > > I agree that the S3 system allows you to do this, and think it's up to > the > > package manager to decide whether or not they would allow their users to > > use tibbles instead of data.frame objects. > > > > I think the bigger frustration is that tibble users are more prone to > > expect all code to work exactly like it does with data.frames. Which it > > obviously doesn't. > > > > -- > > Joris Mey
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 wrote: > Sorry - forgot to cc the list > > > Begin forwarded message: > > > > From: Rainer Krug > > 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 > > > > > >> On 11 May 2017, at 14:35, Holger Hoefling 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>> 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 > >> > >> Fax (D):+49 - (0)3 21 21 25 22 44 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 > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel < > https://stat.ethz.ch/mailman/listinfo/r-package-devel> > >> > > > > -- > > Rainer M. Krug, PhD (Conservation Ecology
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
[R-pkg-devel] Package requiring cmake; windows only package dependency?
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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
