Re: [R-pkg-devel] windows i386

[Simon Urbanek]

Florian,

since there was no direct response and given the earlier discussion I figured I 
chime. The main problem seems to be your build system that doesn't work. Since 
you didn't post the actual version of the package, I can only see the CRAN 
version which still don't set any of the necessary flags from R so it won't 
work (the error is that it can't even use the C compiler). Your package has to 
work both in 32-bit and 64-bit, so you need to make sure you pass the correct 
flags for cmake for each architecture - it's really the same concept as 
discussed earlier. As for multi-arch, if you have configure.win then you may 
need to use --merge-multiarch such that each architecture is built separately 
and the merged into one binary.

I think an easier approach would be if you simply dropped configure* and just 
used Makevars to build the dependent library as part of the build process since 
you are building in a sub-directory, so you don't really need the configure and 
could build both archs in one R CMD INSTALL run.

Cheers,
Simon



> On 13/09/2022, at 11:14 PM, Florian Schwendinger  
> wrote:
> 
> Dear R-package-developers,
> 
> On 'r-oldrel-windows-ix86_x86_64' I get in 'check.log' the error message
> "Error: package 'highs' is not installed for 'arch = i386'"
> the statement that for arch = i386 the package is not installed is correct 
> and expected,
> since in 'install.out' I see the warning
> "Warning: this package has a non-empty 'configure.win' file, so building only 
> the main architecture"
> 
> Looking at r-package-devel archive, I found the suggestion to set Biarch TRUE 
> in the DESCRIPTION file.
> I don't want to force the build of "i386" by setting Biarch: TRUE,
> since as far as I see from the source I link to this should not work and I 
> don't want
> to alter the library I link to as little as possible.
> Therefore, I want skip the step "loading checks for arch 'i386'". Is this 
> possible?
> 
> I know locally this can be resolved by adding the option '--no-multiarch',
> but can a similar effect be accomplished at the CRAN checks?
> Furthermore, I know I can could this issue by adding R >= 4.2 to the depends 
> since Rtools 4.2
> does not build for i386. But this does not seem like a nice fix.
> 
> Is there a better option and how would it work?
> 
> Best regards,
> Florian
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Save and restoring random number seed in a package function

[Bill Dunlap]

> Yes, set.seed() cannot accept .Random.Seed as an input; it can only take
a single integer.

If I recall correctly, S-plus's set.seed() would accept a .Random.seed
value as an input.  It did some basic validation checks on it and set it as
the current .Random.seed.  I don't recall the name of the argument.  The
format of the seed depends on the generator used - I think it used the
nature of the proffered seed to get the likely generator, but there may
have also been arguments to specify the generator explicitly.

I think this would be a nice thing to add to R's set.seed.

-Bill

On Wed, Sep 14, 2022 at 8:11 AM Noah Greifer  wrote:

> Yes, set.seed() cannot accept .Random.Seed as an input; it can only take a
> single integer. As said in this answer
> , there is a one-way
> relationship between set.seed() and .Random.Seed. My understanding is that
> the recommended way to restore the seed is to assign the saved seed to
> .Random.Seed in the global environment, though this is the method that is
> not allowed by the CRAN policy. Unfortunately saving it in the environment
> of the inner function is not sufficient.
>
> One potential inconsistency with CRAN's policy is that generating a random
> number itself changes the global environment by changing the value of
> .Random.Seed. The boot.array() code just does it manually using assign().
> Indeed, the boot.array() code does less damage to the global environment in
> that it resets the seed to what it would have been had boot.array() not
> been run.
>
> Noah
>
> On Wed, Sep 14, 2022 at 10:39 AM James Pustejovsky 
> wrote:
>
> > I'm interested in this question too. Noah, is there a reason you are
> using
> > assign(".Random.seed",...) rather than set.seed()?
> >
> > On Wed, Sep 14, 2022 at 9:31 AM Noah Greifer 
> > wrote:
> >
> >> Hello fellow developers,
> >>
> >> I am attempting to solve the problem of saving the state of the random
> >> generator so that the state can be recovered in a future call.
> >> Essentially,
> >> my function generates random numbers, performs an operation on them
> >> (saving
> >> the result), and throws them out (saving them would require too much
> >> memory). A second function is meant to take the output of the first
> >> function, generate the same random numbers, and perform a different
> >> operation on them.
> >>
> >> This is exactly what happens in the *boot* package: the boot() function
> >> saves the random seed (extracted from .Random.Seed), and the
> boot.array()
> >> function extracts the saved seed from the boot() output, sets the seed
> to
> >> that value, re-generates the same set of random numbers, and then
> >> re-sets the seed to what it was before boot.array() was called. This has
> >> the following benefits: 1) it allows the same random numbers to be
> drawn;
> >> 2) the random numbers don't need to be saved, which is good because they
> >> would take up a lot of memory and boot.array() is an optional function
> (it
> >> is used in boot.ci() with type = "bca" for those curious); and 3) the
> >> seed
> >> carries on from where it left off before boot.array() was called instead
> >> of
> >> being set to what it was after boot() was called.
> >>
> >> This is implemented in boot in the following way (code abbreviated):
> >>
> >> boot <- function(...) {
> >>   seed <- .Random.Seed
> >>   #Random numbers generated
> >>   out <- list(seed = seed
> >>   #Other stuff is in this list
> >>   )
> >>   out
> >> }
> >>
> >> boot.array <- function(boot.out) {
> >>   #Save current random seed in `temp`
> >>   if (exists(".Random.seed", envir = .GlobalEnv, inherits = FALSE))
> >> temp <- get(".Random.seed", envir = .GlobalEnv, inherits = FALSE)
> >>   else temp <- NULL
> >>
> >>   #Assign saved seed from boot.out
> >>   assign(".Random.seed", boot.out$seed, envir = .GlobalEnv)
> >>
> >>   #Generate same random numbers from boot() call
> >>
> >>   #Restore random seed to what it was before boot.array() call
> >>   if (!is.null(temp))
> >> assign(".Random.seed", temp, envir = .GlobalEnv)
> >>   else rm(.Random.seed, pos = 1)
> >> }
> >>
> >> This seems to work as intended. However, this violates the CRAN policy
> of
> >> changing the global environment. When I used this exact code in a
> package
> >> I
> >> submitted, the package was rejected for it. The message I received was
> >>
> >> > Please do not modify the .GlobalEnv (e.g.: by changing the
> .Random.seed
> >> > which is part of the global environment). This is not allowed by the
> >> CRAN
> >> > policies.
> >>
> >>
> >> I'm curious what you think the best course of action might be, and what
> >> the
> >> current policy means for the *boot* package. Thanks for your help.
> >>
> >> Noah
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-de

Re: [R-pkg-devel] Unable to create manual

[Edward Wei]

My next steps in debugging this is:
1. make sure my latex CAN generate PDFs by editing .tex file
2. Run pdflatex as an Admin
3. Download "texinfo" externally (unable to do in R studio as it says it is
incompatible with this version of R)
4. Inspect Rd files

I have made no real progress on this bug...

What is interesting is that previously, before I changed my code for
feedback from manual review, this didn't happen.

On Wed, Sep 14, 2022 at 1:30 PM Matthias Gondan 
wrote:

> That’s interesting. I was just wondering if it is installed, given the
> message „pdflatex is not available“.
>
>
>
>
>
>
>
> *Von: *Edward Wei 
> *Gesendet: *Mittwoch, 14. September 2022 22:26
> *An: *Matthias Gondan 
> *Cc: *r-package-devel@r-project.org
> *Betreff: *Re: [R-pkg-devel] Unable to create manual
>
>
>
> Hello Matthias.
>
>
>
> This is what is returned when I try pdflatex on terminal
>
>
>
> This is pdfTeX, Version 3.141592653-2.6-1.40.24 (MiKTeX 22.8.28)
> (preloaded format=pdflatex.fmt)
>  restricted \write18 enabled.
> **
>
>
>
>
>
>
>
> On Mon, Sep 12, 2022 at 7:20 AM Matthias Gondan 
> wrote:
>
> You may wish to check first if pdflatex works from the folder, i.e.
>
>
>
> C:\Users\edmon\Documents\R\RFIN> pdflatex
>
>
>
> The problem with Rd.sty may be unrelated.
>
>
>
>
>
> *Von: *Edward Wei 
> *Gesendet: *Montag, 12. September 2022 15:09
> *An: *r-package-devel@r-project.org
> *Betreff: *[R-pkg-devel] Unable to create manual
>
>
>
> This is the following error message I get from R CMD check:
>
>
>
> LaTeX errors when creating PDF version.
>
> This typically indicates Rd problems.
>
> * checking PDF version of manual without index ... ERROR
>
> Re-running with no redirection of stdout/stderr.
>
> Hmm ... looks like a package
>
> Converting parsed Rd's to LaTeX ...
>
> Creating pdf output from LaTeX ...
>
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>
>   pdflatex is not available
>
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>
>   pdflatex is not available
>
> Error in running tools::texi2pdf()
>
> You may want to clean up by 'rm -Rf
>
> C:/Users/edmon/AppData/Local/Temp/RtmpWkD7Iy/Rd2pdf35d81e3e188c'
>
> * DONE
>
>
>
> Status: 1 ERROR, 1 WARNING, 2 NOTEs
>
>
>
>
>
> Then, I tried debugging by isolating errors from the Rd to PDF conversion.
>
>
>
>
>
> C:\Users\edmon\Documents\R\RFIN> R CMD Rd2pdf avfintools --no-clean
>
> Hmm ... looks like a package
>
> Converting Rd files to LaTeX ...
>
> Creating pdf output from LaTeX ...
>
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>
>   pdflatex is not available
>
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>
>   pdflatex is not available
>
> Error in running tools::texi2pdf()
>
> You may want to clean up by 'rm -Rf .Rd2pdf27964'
>
>
>
>
>
> In this folder is the file Rd2.tex which I tried to complie into a pdf. But
>
> this error returns and PDF cannot be compiled. :
>
>
>
>
>
> LaTeX Error: File `Rd.sty' not found.
>
>
>
> Type X to quit or  to proceed,
>
> or enter new name. (Default extension: sty)
>
>
>
> Enter file name:
>
> ! Emergency stop.
>
> 
>
>
>
> l.4 \usepackage
>
>{makeidx}^^M
>
> ==> Fatal error occurred, no output PDF file produced!
>
>
>
>
>
> Thanks for your help,
>
>
>
>  [[alternative HTML version deleted]]
>
>
>
> __
>
> 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

Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[Ivan Krylov]

On Wed, 14 Sep 2022 12:31:49 -0400
Duncan Murdoch  wrote:

> It's also possible to put .R files in the data directory, and they
> are executed to create the data object.  I think that happens at the
> time when you call data() rather than at install time, so it might
> not be helpful.

Some time ago I was hoping to compress a package of mine by generating a
dataset during a data() call instead loading it from an .rda file, but
it turned out that the .R file is executed during R CMD build:
https://github.com/r-devel/r-svn/blob/03df313ad37456c6a62158328d4e373408ce4d59/src/library/tools/R/build.R#L794

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Advice on resubmitting when no response from CRAN

[David B. Dahl]

Thanks for the reply, Ben.

The SystemRequirements is "Cargo (>= 1.56) for installation from source:
see INSTALL file".  The INSTALL notes that the package contains Rust source
code compiled by Cargo (the Rust package manager) which can be obtained
from the Rust project at https://rustup.rs.  On Windows, this involves
downloading an executable and following the onscreen instructions.

In my follow-up email, I wrote, "Alternatively, if you prefer, could these
packages please download
binary libraries produced by Cargo in accordance with the CRAN policy:
'Only as a last resort and with the agreement of the CRAN team should a
package download pre-compiled software.'"

So you suggest I politely nudge instead of resubmitting?  I don't think
that CRAN even has a copy of my submission anymore.  (It was here
https://cran.r-project.org/incoming/archive/ for several weeks, but is now
gone.)

Thanks!

-- David


On Wed, Sep 14, 2022 at 9:47 AM Ben Bolker  wrote:

> One question and one suggestion.
>
> Is the software required/indicated by the SystemRequirements field
> unusual/possibly burdensome to install across platforms? That wouldn't
> justify not responding to your e-mails, but it might explain why the
> package didn't make it onto CRAN.
>
>For some context, can you tell us what the system
> requirement/alternative is?
>
>The suggestion would be to politely nudge again.
>
> On 9/14/22 11:24 AM, David B. Dahl wrote:
> > Hi colleagues.  I am hoping to get some advice from you on how to get
> > a package "unstuck" at CRAN without antagonizing the busy CRAN
> > maintainers.
> >
> > I submitted to CRAN an update to one of my packages on August 5.  The
> > submission passed the automatic tests on Debian, but not Windows.  The
> > automated response said, "If you are fairly certain the rejection is a
> > false positive, please reply-all to this message and explain."  I
> > replied-all and noted that the failure should be resolved by please
> > installing software as described in the SystemRequirements field and
> > the referenced INSTALL file.  After three weeks of not hearing back, I
> > sent a polite nudge (again via reply-all) on August 26 and suggested
> > an alternative if my original solution was not feasible.  I still have
> > not heard back and notice that now my package source is no longer on
> > https://cran.r-project.org/incoming/archive/.
> >
> > How would you recommend that I proceed in a professional fashion?
> Thanks!
> >
> > -- David B. Dahl
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Dr. Benjamin Bolker
> Professor, Mathematics & Statistics and Biology, McMaster University
> Director, School of Computational Science and Engineering
> Graduate chair, Mathematics & Statistics
>
> __
> 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] Save and restoring random number seed in a package function

[Noah Greifer]

Hello fellow developers,

I am attempting to solve the problem of saving the state of the random
generator so that the state can be recovered in a future call. Essentially,
my function generates random numbers, performs an operation on them (saving
the result), and throws them out (saving them would require too much
memory). A second function is meant to take the output of the first
function, generate the same random numbers, and perform a different
operation on them.

This is exactly what happens in the *boot* package: the boot() function
saves the random seed (extracted from .Random.Seed), and the boot.array()
function extracts the saved seed from the boot() output, sets the seed to
that value, re-generates the same set of random numbers, and then
re-sets the seed to what it was before boot.array() was called. This has
the following benefits: 1) it allows the same random numbers to be drawn;
2) the random numbers don't need to be saved, which is good because they
would take up a lot of memory and boot.array() is an optional function (it
is used in boot.ci() with type = "bca" for those curious); and 3) the seed
carries on from where it left off before boot.array() was called instead of
being set to what it was after boot() was called.

This is implemented in boot in the following way (code abbreviated):

boot <- function(...) {
  seed <- .Random.Seed
  #Random numbers generated
  out <- list(seed = seed
  #Other stuff is in this list
  )
  out
}

boot.array <- function(boot.out) {
  #Save current random seed in `temp`
  if (exists(".Random.seed", envir = .GlobalEnv, inherits = FALSE))
temp <- get(".Random.seed", envir = .GlobalEnv, inherits = FALSE)
  else temp <- NULL

  #Assign saved seed from boot.out
  assign(".Random.seed", boot.out$seed, envir = .GlobalEnv)

  #Generate same random numbers from boot() call

  #Restore random seed to what it was before boot.array() call
  if (!is.null(temp))
assign(".Random.seed", temp, envir = .GlobalEnv)
  else rm(.Random.seed, pos = 1)
}

This seems to work as intended. However, this violates the CRAN policy of
changing the global environment. When I used this exact code in a package I
submitted, the package was rejected for it. The message I received was

> Please do not modify the .GlobalEnv (e.g.: by changing the .Random.seed
> which is part of the global environment). This is not allowed by the CRAN
> policies.


I'm curious what you think the best course of action might be, and what the
current policy means for the *boot* package. Thanks for your help.

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel