Re: [R-pkg-devel] Winbuilder down?

[Balasubramanian Narasimhan]

Dear Uwe,

Mea culpa. that was a false alarm. I forgot that the email goes to the 
maintainer, which is not me. Apologies.


-Naras

On 2/1/24 7:40 AM, Uwe Ligges wrote:

Dear Naras,

the queues are empty, so everything has been processed.
Which package are you talking about? Then I can take a look what went 
wrong.


Best,
Uwe

On 01.02.2024 15:53, Balasubramanian Narasimhan wrote:
Just FYI: Winbuilder seems to be unresponsive. My uploads over the 
last 2 days have not resulted in any output or messages.


Thank you.

-Naras

__
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

[R-pkg-devel] Winbuilder down?

[Balasubramanian Narasimhan]

Just FYI: Winbuilder seems to be unresponsive. My uploads over the last 
2 days have not resulted in any output or messages.


Thank you.

-Naras

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

Re: [Rd] Matrix 1.6.2+ versus Matrix 1.6.2-

[Balasubramanian Narasimhan]

Thanks Mikael.

[I too wondered if this topic was appropriate for the list and in the 
end thought it might be. We can probably take this offline after this 
exchange and summarize if appropriate.]


The actual source of the package is here: 
https://download.mosek.com/R/10.1/src/contrib/Rmosek_10.1.14.tar.gz


and requires a download of the optimizer first using an academic 
license: https://www.mosek.com/products/academic-licenses/


The optimizer typically installs under ~/mosek.

Then one installs Rmosek from CRAN as usual and follows the instructions 
it emits as it is loaded. The installation needs to know the Mosek bin 
directory: on a mac it is "~/mosek/10.1/tools/platform/osx64x86/bin". 
That begins the source installation process.


-Naras


On 11/22/23 1:14 PM, Mikael Jagan wrote:

Naras,

Thanks.  I'm a bit confused, because Rmosek does not declare Matrix as a
dependency:

    > tools::package_dependencies("Rmosek", which = "all")[[1L]]
    [1] "pkgbuild"

nor does it contain code needing compilation:

    > packageDescription("Rmosek", fields="NeedsCompilation")
    [1] "no"

Can you explain the nature of the dependency and how I can reproduce your
output?  Is an _external_ library somehow linking Matrix ... ?

Note that the 3 removed entry points were unused by all reverse LinkingTo
on CRAN and BioC at the time that Matrix 1.6-2 was released.  We can
suggest replacements (probably off list; I don't know that R-devel is the
right forum) but only if we are able to see the code being compiled ...

Mikael

> Package Rmosek compiles fine using Matrix versions 1.6.2- but not with
> anything beyond Matrix 1.6.2.  (FYI, Rmosek provides R interfaces to 
the

> excellent MOSEK solver; academic licenses are free.)
>
> Here is the error message:
>
> rmsk_obj_matrices.cc:50:9: error: use of undeclared identifier 
'Matrix_isclass_Csparse'

> 50 | if (Matrix_isclass_Csparse(val)) {
>    | ^
> rmsk_obj_matrices.cc:171:9: error: use of undeclared identifier 
'Matrix_isclass_triplet'

>    171 | if (Matrix_isclass_triplet(val)) {
>    | ^
> rmsk_obj_matrices.cc:225:24: error: use of undeclared identifier 
'M_chm_triplet_to_SEXP'
>    225 | matrixhandle.protect(M_chm_triplet_to_SEXP(tmp, 0, 0, 
0, NULL, R_NilValue));

>
> These API entry points are no longer in the recent headers. My quick
> examination shows that the first two seem like mostly R API stuff 
and so
> can be copied over to Rmosek easily but the last one looks more 
involved

> in my cursory examination.
>
> I was going to let the author of Rmosek know, but I do not see any
> mention of these API entries going away in the NEWS for Matrix.
>
> Would be good to point the author to a suggested approach or even
> provide the beginnings of a fix. Any thoughts, particularly by Matrix
> authors (Martin, Mikael)?
>
> Thanks in advance.
>
> -Naras


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

[Rd] Matrix 1.6.2+ versus Matrix 1.6.2-

[Balasubramanian Narasimhan]

Package Rmosek compiles fine using Matrix versions 1.6.2- but not with 
anything beyond Matrix 1.6.2.  (FYI, Rmosek provides R interfaces to the 
excellent MOSEK solver; academic licenses are free.)

Here is the error message:

rmsk_obj_matrices.cc:50:9: error: use of undeclared identifier 
'Matrix_isclass_Csparse'
    50 | if (Matrix_isclass_Csparse(val)) {
   | ^
rmsk_obj_matrices.cc:171:9: error: use of undeclared identifier 
'Matrix_isclass_triplet'
   171 | if (Matrix_isclass_triplet(val)) {
   | ^
rmsk_obj_matrices.cc:225:24: error: use of undeclared identifier 
'M_chm_triplet_to_SEXP'
   225 |   matrixhandle.protect(M_chm_triplet_to_SEXP(tmp, 0, 0, 0, NULL, 
R_NilValue));

These API entry points are no longer in the recent headers. My quick 
examination shows that the first two seem like mostly R API stuff and so 
can be copied over to Rmosek easily but the last one looks more involved 
in my cursory examination.

I was going to let the author of Rmosek know, but I do not see any 
mention of these API entries going away in the NEWS for Matrix.

Would be good to point the author to a suggested approach or even 
provide the beginnings of a fix. Any thoughts, particularly by Matrix 
authors (Martin, Mikael)?

Thanks in advance.

-Naras


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [UNCLASSIFIED] Remotes in description when submitting a package until a dependency is fixed

[Balasubramanian Narasimhan]

(Disclaimer: User bias here.)

I can vouch for drat repos; they have saved me in developing APIs for 
packages under development, e.g. rcbc which is only on Github and not on 
CRAN.  (As Dirk notes, this only applies to Enhances/Suggests dependence.)


-Naras


On 11/16/22 8:17 AM, Dirk Eddelbuettel wrote:

On 16 November 2022 at 06:36, Duncan Murdoch wrote:
| On 15/11/2022 11:59 p.m., Hugh Parsonage wrote:
| > I think you've misunderstood that excerpt.  By "temporary development
| > state", it means _between_ CRAN releases; packages in a development
| > state are not suitable for CRAN, as the policy states:
| >
| >> CRAN hosts packages of publication quality and is not a development 
platform.
| >
| > You'll need to stop depending on that package until it's fixed and the
| > fix is on CRAN. That said, it looks like it might be relatively
| > straightforward to disentangle yourself from the package -- just
| > rewrite the offending example?
|
| Another solution is to put a version of that package in your own drat
| repository, and use "Additional_repositories".  For example, at one
| point rgl used webshot2 before it was released, and I had
|
|Suggests:  webshot2, ...
|Additional_repositories:  https://dmurdoch.github.io/drat
|
| with a copy of webshot2 in the drat repository.
|
| The disadvantage of this approach is that you'll need to keep that
| repository up to date as the third party package evolves, and eventually
| remove the Additional_repositories: line from your DESCRIPTION, which
| requires your own package update.
|
| See https://github.com/eddelbuettel/drat for instructions on setting up
| the drat repository.

(Disclaimer: Author bias here.) Let me vouch for Additional_repositories:
along with packages in Suggests: (you cannot do this for Imports / Depends /
LinkingTo per CRAN Policy).  I have recently been relying on it a lot for a
package I (similarly) could not change that frequently at CRAN, and a
'semi-private / semi-public package' providing functionality I expect to be
provided by another package 'eventually'. With the caveat that you need the
Suggests: mechanism and hence _conditional_ use, it works just like CRAN.

In the meantime Additional_repositories: just works. It expands the set of
repos, so all operations relying on standard install.packages() calls (and
that includes using the remotes package to parse dependencies in CI, say)
just work, both at CRAN and in CI.

`drat` simply helps along by making it easier to provide compatible 
repositories.

Dirk



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

Re: [R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Thank you, Simon!

On 11/8/21 5:57 PM, Simon Urbanek wrote:

 From CRAN Policy:



Explain any change in the maintainer’s email address and if possible send 
confirmation from the previous address (by a separate email to 
cran-submissi...@r-project.org) or explain why it is not possible



Cheers,
Simon



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

[R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Is there any way at all to update the email address of the maintainer of 
a package? (The address of the maintainer of CVXR which is in need of an 
update for the new SCS solver has changed from  @stanford.edu to 
@alumni.stanford.edu, with no access to the former.)


-Naras

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

Re: [Rd] FLIBS in MacOS M1 binary at odds with documentation for optional libraries/tools

[Balasubramanian Narasimhan]

Thanks, Simon.  I only had sporadic access to a M1 laptop but now 
actually have one. Will try to do my part.


Best,

-Naras

On 11/1/21 8:22 PM, Simon Urbanek wrote:

Naras,

thanks. It seems that the FLIBS check resolves symlinks, unfortunately (all 
others are fine).

I would like to remind people that reports are a lot more useful *before* the 
release - that's why we publish RCs.

Thanks,
Simon



On Nov 2, 2021, at 3:03 PM, Balasubramanian Narasimhan  
wrote:

The Mac OS M1 pre-built binary arrives with a
/Library/Frameworks/R.framework/Resources/etc/Makevars containing

FLIBS =  
-L/Volumes/Builds/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0
 -L/Volumes/Builds/opt/R/arm64/gfortran/lib/gcc 
-L/Volumes/Builds/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm

This is inconsistent with what is at said at the top of
https://mac.r-project.org/libs-arm64/: that all binaries live in
/opt/R/arm64, not /Volumes/Builds/opt/R/arm64.

So no one would be able to build a source package containing Fortran
without either modifying Makevars or creating symbolic links.

-Naras


[[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] FLIBS in MacOS M1 binary at odds with documentation for optional libraries/tools

[Balasubramanian Narasimhan]

The Mac OS M1 pre-built binary arrives with a 
/Library/Frameworks/R.framework/Resources/etc/Makevars containing

FLIBS =  
-L/Volumes/Builds/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0
 -L/Volumes/Builds/opt/R/arm64/gfortran/lib/gcc 
-L/Volumes/Builds/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm

This is inconsistent with what is at said at the top of 
https://mac.r-project.org/libs-arm64/: that all binaries live in 
/opt/R/arm64, not /Volumes/Builds/opt/R/arm64.

So no one would be able to build a source package containing Fortran 
without either modifying Makevars or creating symbolic links.

-Naras


[[alternative HTML version deleted]]

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

Re: [Rd] subset argument in nls() and possibly other functions

[Balasubramanian Narasimhan]

For the example provided below, the subsetting happens in evaluating the 
call to stats::model.formula in line 583 of nls.R 
(https://github.com/wch/r-source/blob/e91be22f6f37644e5a0ba74a3dfe504a3a29e9f7/src/library/stats/R/nls.R#L583) 
returning an appropriate (subsetted) data frame.


-Naras

On 7/13/21 4:21 PM, J C Nash wrote:

In mentoring and participating in a Google Summer of Code project "Improvements to 
nls()",
I've not found examples of use of the "subset" argument in the call to nls(). 
Moreover,
in searching through the source code for the various functions related to 
nls(), I can't
seem to find where subset is used, but a simple example, included below, 
indicates it works.
Three approaches all seem to give the same results.

Can someone point to documentation or code so we can make sure we get our 
revised programs
to work properly? The aim is to make them more maintainable and provide 
maintainer documentation,
along with some improved functionality. We seem, for example, to already be 
able to offer
analytic derivatives where they are feasible, and should be able to add 
Marquardt-Levenberg
stabilization as an option.

Note that this "subset" does not seem to be the "subset()" function of R.

John Nash

# CroucherSubset.R -- https://walkingrandomly.com/?p=5254

xdata = c(-2,-1.64,-1.33,-0.7,0,0.45,1.2,1.64,2.32,2.9)
ydata = 
c(0.699369,0.700462,0.695354,1.03905,1.97389,2.41143,1.91091,0.919576,-0.730975,-1.42001)
Cform <- ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata)
Cstart<-list(p1=1,p2=0.2)
Cdata<-data.frame(xdata, ydata)
Csubset<-1:8 # just first 8 points

# Original problem - no subset
fit0 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
start=list(p1=1,p2=.2))
summary(fit0)

# via subset argument
fit1 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
start=list(p1=1,p2=.2), subset=Csubset)
summary(fit1)

# via explicit subsetting
Csdata <- Cdata[Csubset, ]
Csdata
fit2 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Csdata, 
start=list(p1=1,p2=.2))
summary(fit2)

# via weights -- seems to give correct observation count if zeros not recognized
wts <- c(rep(1,8), rep(0,2))
fit3 = nls(ydata ~ p1*cos(p2*xdata) + p2*sin(p1*xdata), data=Cdata, 
weights=wts, start=list(p1=1,p2=.2))
summary(fit3)

__
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: [R-pkg-devel] Suggesting gurobi

[Balasubramanian Narasimhan]

Suggests" would trigger an attempt to install gurobi, which is not on CRAN.

We used "Enhances" for our CVXR  because

(1) None of the functionality in the package requires gurobi;

(2) Packages in "Enhances" are not required to check the package by CRAN.

Your package mirrors ours in these respects and so I would suggest going 
with "Enhances".


-Naras

On 6/4/21 12:35 PM, Noah Greifer wrote:

Hello,

I have been working on adding an option for my users to use integer
programming (a method of optimization) to enhance the results of a function
in my package. There are several R packages on CRAN that perform integer
programming, including Rglpk and Rsymphony. However, there is a commercial
solver called Gurobi that dramatically outperforms all open-source solvers,
and it comes with an R interface through the gurobi package. I want to
allow my users to use Gurobi to perform the package actions.

A potential issue is that the gurobi package is not on CRAN; it comes with
an installation of the Gurobi software, which requires a license. I am not
sure how to add gurobi to my Description file to satisfy CRAN's
requirements. In CMD CHECK, I get the warning that the package is not
available for checking. However, I have noticed some other packages do use
gurobi just as I want to (i.e., as an option), such as CVXR
 and designmatch
, which put gurobi in
Enhances (though I would have thought it would belong in Suggests). It
seems that neither of these packages passes the CRAN checks, though.

I'm wondering what the best practices are for including gurobi in my
package. To be clear, its use is optional and the package can be functional
without it, but it greatly enhances performance so I want my users to be
able to use it. Thank you!

Noah Greifer

[[alternative HTML version deleted]]

__
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] Unable to get past CRAN submission checks for package cubature

[Balasubramanian Narasimhan]

Thanks to the encouragement of Brodie Gaslam and Tomas Kalibera (private 
email), I was able to hack the code to avoid the warnings.


The code in question had the following structure:

    int inibits = -1, bit;
    for( j = powers; j; j >>= 1 ) ++inibits;
    memcpy(pv, pini, inibits*sizeof(*pini));


which I changed to:

    int inibits = -1, bit;
    for( j = powers; j; j >>= 1 ) ++inibits;

    int sz = inibits * sizeof(*pini);
    sz = (sz > 0) ? sz : 0;

    memcpy(pv, pini, sz);

to guard against the erroneous gcc 8.3 inference that inibits could 
remain at -1 if powers is zero, known to be not possible.


Best,

-Naras

On 5/11/21 3:02 PM, brodie gaslam wrote:

At the risk of only being mildly (if at all) helpful, I was able
to reproduce your warnings on Rhub, which has the same compiler,
with:

     rhub::check('cubature_2.0.4.1.tar.gz', platform='windows-x86_64-release')

Absent feedback from CRAN you could try tweaking your code so that
it does not produce those warnings while no changing behavior.
Obviously, iterating with rhub is not the easiest way to do this,
but might be easier than trying to get GCC 8.3.

For reference, you might be hitting:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273

Maybe you knew that already but it might be useful for others to be
aware there is an actual bug that at least is in the general area
that affects GCC 8.2-8.3.

Best,

B.




On Monday, May 10, 2021, 4:01:36 PM EDT, Balasubramanian Narasimhan 
 wrote:





I submitted a minor update of cubature (suggesting rmarkdown for
vignettes) and received a message that the package generated warnings.
However, the warnings were noted to be untrustworthy (see email below).
I noted this in the submission comments as well as the reply to the
auto-check email.

It appears that I am unable to get beyond the auto-check service. Any
suggestions?

-Naras

 Forwarded Message 

Subject:     Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date:     Thu, 6 May 2021 12:51:37 -0700
From:     Balasubramanian Narasimhan 
To:     cran-submissi...@r-project.org, na...@stat.stanford.edu



Dear CRAN,

As explained in my submission comment, the warning is noted to be flaky
in the message below.

Thank you.

-Naras

On 18/03/2021 13:05, Kurt Hornik wrote:


Uwe Ligges writes:

Dear Naras,
your package cubature shows compiler warnings under Windows:
<https://cran.r-project.org/web/checks/check_results_cubature.html>
Any chance getting rid of these? Please try and resubmit.

Interestingly, r-release-macos shows this too ...

I think -Warray-bounds is known to be flaky in earlier compilers.  I do
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or
12.4 (current) and nor does Tomas for GCC 10 on Windows.




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

[R-pkg-devel] Unable to get past CRAN submission checks for package cubature

[Balasubramanian Narasimhan]

I submitted a minor update of cubature (suggesting rmarkdown for 
vignettes) and received a message that the package generated warnings. 
However, the warnings were noted to be untrustworthy (see email below). 
I noted this in the submission comments as well as the reply to the 
auto-check email.

It appears that I am unable to get beyond the auto-check service. Any 
suggestions?

-Naras

 Forwarded Message 

Subject:Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date:   Thu, 6 May 2021 12:51:37 -0700
From:   Balasubramanian Narasimhan 
To: cran-submissi...@r-project.org, na...@stat.stanford.edu



Dear CRAN,

As explained in my submission comment, the warning is noted to be flaky 
in the message below.

Thank you.

-Naras

On 18/03/2021 13:05, Kurt Hornik wrote:

>>>>>> Uwe Ligges writes:
>
>> Dear Naras,
>> your package cubature shows compiler warnings under Windows:
>> <https://cran.r-project.org/web/checks/check_results_cubature.html>
>
>> Any chance getting rid of these? Please try and resubmit.
>
> Interestingly, r-release-macos shows this too ...

I think -Warray-bounds is known to be flaky in earlier compilers.  I do 
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or 
12.4 (current) and nor does Tomas for GCC 10 on Windows.


-- 
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
On 5/6/21 12:27 PM, lig...@statistik.tu-dortmund.de wrote:
> Dear maintainer,
>   
> package cubature_2.0.4.2.tar.gz does not pass the incoming checks 
> automatically, please see the following pre-tests:
> Windows:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Windows/00check.log>
> Status: 1 WARNING
> Debian:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Debian/00check.log>
> Status: OK
>   
> Last released version's CRAN status: WARN: 3, NOTE: 10
> See:<https://CRAN.R-project.org/web/checks/check_results_cubature.html>
>   
> CRAN Web:<https://cran.r-project.org/package=cubature>
>   
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the 
> R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please reply-all 
> to this message and explain.
>   
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/>
> The files will be removed after roughly 7 days.
>   
> *** Strong rev. depends ***: ALTopt apTreeshape bivquant BNSP calibrator 
> clusteredinterference coga cold dbmss DRAYL dvmisc ei equivalenceTest 
> fMultivar GAS GB2 GPCMlasso GRCdata highfrequency hyper2 ICAOD inctools 
> MCMCglmm MIRES MMDCopula MWright NonNorMvtDist np OBASpatial ODS optimStrat 
> PCMRS planar pooling Power2Stage PowerTOST ProFit QGglmm robustlmm skedastic 
> SphericalCubature spNetwork statsr SurvDisc symmoments TCIU tseriesEntropy 
> UPCM vines WLinfer yuima
>   
> Best regards,
> CRAN teams' auto-check service
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
>Maintainer: 'Balasubramanian Narasimhan'
>
> Flavor: r-devel-windows-ix86+x86_64
> Check: whether package can be installed, Result: WARNING
>Found the following significant warnings:
>  ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
> offset 0 and size [4294967292, 2147483647] [-Warray-bounds]
>  ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
> offset 0 and size [-4, 9223372036854775807] [-Warray-bounds]
>See 'd:/RCompile/CRANincoming/R-devel/cubature.Rcheck/00install.out' for 
> details.

[[alternative HTML version deleted]]

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

Re: [Rd] Possible x11 window manager window aggregation under one icon?

[Balasubramanian Narasimhan]

Confession: haven't done this in decades.

Isn't the usual way to use 'xwininfo' to figure out the information 
about any X window and set a specific resource in the .X11defaults or 
equivalent?  Also doing the same with windows that aggregate could yield 
a common resource, perhaps?


-Naras

On 3/20/21 9:51 AM, Dirk Eddelbuettel wrote:

[ I hope the Subject: is arcane enough to reduce readership to a handful :) ]

Running the default window manager in the Linux distribution I am running,
multiple 'windows' of the same program are usually aggregated under one icon.
I typically have numerous (gnome) terminals, several top-level emacs windows,
likely more than brower window (even with tabs) and so on. They all aggregate
under the top-level icon

R plots however all have one each. Needless to say I may also have more than
one plot device open...  Would anyone know how we can force these to
aggregate under just one?  I had some digital fingerprints on the .desktop
file that ships with simply because someone first sent it to me as a patch
for the Debian package. But I know nuttin' about the XDG desktop
specification and all that. I had one idea regarding window titles, but those
are different for the terminals and emacs windows too.  Anybody have an idea?

Dirk



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

Re: [R-pkg-devel] Subarchitectures

[Balasubramanian Narasimhan]

If GNU make is acceptable as a system requirement, you can get any R 
configuration/runtime variable in Makevars, e.g.


R_ARCH=$(shell $(R_HOME)/bin/Rscript -e 'cat(.Platform$r_arch)')

-Naras

On 2/9/21 9:45 AM, Duncan Murdoch wrote:

On 09/02/2021 11:01 a.m., Duncan Murdoch wrote:

I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.


Actually, I probably misread the section about environment variables.

Duncan

__
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

[R-pkg-devel] Winbuilder seems stuck

[Balasubramanian Narasimhan]

This is just FYI to CRAN as no results came back from an upload over a 
day and a half ago. A repeat upload gives:

ERROR: Access to the path 'C:\Inetpub\ftproot\R-devel\...' is denied.

-Naras



[[alternative HTML version deleted]]

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

Re: [Rd] From .Fortran to .Call?

[Balasubramanian Narasimhan]

Also, just came to know about dotcall64::.C64() (on CRAN) which allows 
for Fortran to be called using .Call().


-Naras

On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
I think it should be pretty easy to fix up SUtools to use the .Call 
instead of .Fortran following along the lines of


https://github.com/wrathematics/Romp

I too deal with a lot of f77 and so I will most likely finish it 
before the new year, if not earlier. (Would welcome testers besides 
myself.)


Incidentally, any idea of what the performance hit is, quantitatively? 
I confess I never paid attention to it myself as most Fortran code I 
use seems pretty fast, i.e. glmnet.


-Naras


On 12/23/20 3:57 AM, Koenker, Roger W wrote:

Thanks to all and best wishes for a better 2021.

Unfortunately I remain somewhat confused:

o  Bill reveals an elegant way to get from my rudimentary 
registration setup to

one that would explicitly type the C interface functions,

o Ivan seems to suggest that there would be no performance gain 
from doing this.


o  Naras’s pcLasso package does use the explicit C typing, but 
then uses .Fortran

not .Call.

o  Avi uses .Call and cites the Romp package 
https://github.com/wrathematics/Romp
where it is asserted that "there is a (nearly) deprecated 
interface .Fortran() which you

should not use due to its large performance overhead.”

As the proverbial naive R (ab)user I’m left wondering:

o  if I updated my quantreg_init.c file in accordance with Bill’s 
suggestion could I

then simply change my .Fortran calls to .Call?

o  and if so, do I need to include ALL the fortran subroutines in 
my src directory

or only the ones called from R?

o  and in either case could I really expect to see a significant 
performance gain?


Finally, perhaps I should stipulate that my fortran is strictly f77, 
so no modern features
are in play, indeed most of the code is originally written in ratfor, 
Brian Kernighan’s

dialect from ancient times at Bell Labs.

Again,  thanks to all for any advice,
Roger


On Dec 23, 2020, at 1:11 AM, Avraham Adler  
wrote:


Hello, Ivan.

I used .Call instead of .Fortran in the Delaporte package [1]. What
helped me out a lot was Drew Schmidt's Romp examples and descriptions
[2]. If you are more comfortable with the older Fortran interface,
Tomasz Kalinowski has a package which uses Fortran 2018 more
efficiently [3]. I haven't tried this last in practice, however.

Hope that helps,

Avi

[1] 
https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
[2] 
https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
[3] 
https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$


Tomasz Kalinowski



On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
 wrote:

To deal with such Fortran issues in several packages I deal with, I
wrote the SUtools package 
(https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$ 
) that you

can try.  The current version generates the registration assuming
implicit Fortran naming conventions though. (I've been meaning to
upgrade it to use the gfortran -fc-prototypes-external flag which 
should

be easy; I might just finish that during these holidays.)

There's a vignette as well:
https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$ 



-Naras


On 12/19/20 9:53 AM, Ivan Krylov wrote:

On Sat, 19 Dec 2020 17:04:59 +
"Koenker, Roger W"  wrote:


There are comments in various places, including R-extensions §5.4
suggesting that .Fortran is (nearly) deprecated and hinting that use
of .Call is more efficient and now preferred for packages.
My understanding of §5.4 and 5.5 is that explicit routine 
registration
is what's important for efficiency, and your package already does 
that

(i.e. calls R_registerRoutines()). The only two things left to add
would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
R_ARG_OUT/...) of the arguments of each subroutine.

Switching to .Call makes sense if you want to change the interface of
your native subroutines to accept arbitrary heavily structured SEXPs
(and switching to .External could be useful if you wanted to play 
with

evaluation of the arguments).


__
R-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 



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

Re: [Rd] From .Fortran to .Call?

[Balasubramanian Narasimhan]

I think it should be pretty easy to fix up SUtools to use the .Call 
instead of .Fortran following along the lines of


https://github.com/wrathematics/Romp

I too deal with a lot of f77 and so I will most likely finish it before 
the new year, if not earlier. (Would welcome testers besides myself.)


Incidentally, any idea of what the performance hit is, quantitatively? I 
confess I never paid attention to it myself as most Fortran code I use 
seems pretty fast, i.e. glmnet.


-Naras


On 12/23/20 3:57 AM, Koenker, Roger W wrote:

Thanks to all and best wishes for a better 2021.

Unfortunately I remain somewhat confused:

o  Bill reveals an elegant way to get from my rudimentary  registration 
setup to
one that would explicitly type the C interface functions,

o Ivan seems to suggest that there would be no performance gain from 
doing this.

o  Naras’s pcLasso package does use the explicit C typing, but then 
uses .Fortran
not .Call.

o  Avi uses .Call and cites the Romp package 
https://github.com/wrathematics/Romp
where it is asserted that "there is a (nearly) deprecated interface 
.Fortran() which you
should not use due to its large performance overhead.”

As the proverbial naive R (ab)user I’m left wondering:

o  if I updated my quantreg_init.c file in accordance with Bill’s 
suggestion could I
then simply change my .Fortran calls to .Call?

o  and if so, do I need to include ALL the fortran subroutines in my 
src directory
or only the ones called from R?

o  and in either case could I really expect to see a significant 
performance gain?

Finally, perhaps I should stipulate that my fortran is strictly f77, so no 
modern features
are in play, indeed most of the code is originally written in ratfor, Brian 
Kernighan’s
dialect from ancient times at Bell Labs.

Again,  thanks to all for any advice,
Roger



On Dec 23, 2020, at 1:11 AM, Avraham Adler  wrote:

Hello, Ivan.

I used .Call instead of .Fortran in the Delaporte package [1]. What
helped me out a lot was Drew Schmidt's Romp examples and descriptions
[2]. If you are more comfortable with the older Fortran interface,
Tomasz Kalinowski has a package which uses Fortran 2018 more
efficiently [3]. I haven't tried this last in practice, however.

Hope that helps,

Avi

[1] 
https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
[2] 
https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
[3] 
https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$

Tomasz Kalinowski



On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
 wrote:

To deal with such Fortran issues in several packages I deal with, I
wrote the SUtools package 
(https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$
 ) that you
can try.  The current version generates the registration assuming
implicit Fortran naming conventions though. (I've been meaning to
upgrade it to use the gfortran -fc-prototypes-external flag which should
be easy; I might just finish that during these holidays.)

There's a vignette as well:
https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$

-Naras


On 12/19/20 9:53 AM, Ivan Krylov wrote:

On Sat, 19 Dec 2020 17:04:59 +
"Koenker, Roger W"  wrote:


There are comments in various places, including R-extensions §5.4
suggesting that .Fortran is (nearly) deprecated and hinting that use
of .Call is more efficient and now preferred for packages.

My understanding of §5.4 and 5.5 is that explicit routine registration
is what's important for efficiency, and your package already does that
(i.e. calls R_registerRoutines()). The only two things left to add
would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
R_ARG_OUT/...) of the arguments of each subroutine.

Switching to .Call makes sense if you want to change the interface of
your native subroutines to accept arbitrary heavily structured SEXPs
(and switching to .External could be useful if you wanted to play with
evaluation of the arguments).


__
R-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$


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

Re: [Rd] From .Fortran to .Call?

[Balasubramanian Narasimhan]

To deal with such Fortran issues in several packages I deal with, I 
wrote the SUtools package (https://github.com/bnaras/SUtools) that you 
can try.  The current version generates the registration assuming 
implicit Fortran naming conventions though. (I've been meaning to 
upgrade it to use the gfortran -fc-prototypes-external flag which should 
be easy; I might just finish that during these holidays.)


There's a vignette as well: 
https://bnaras.github.io/SUtools/articles/SUtools.html


-Naras


On 12/19/20 9:53 AM, Ivan Krylov wrote:

On Sat, 19 Dec 2020 17:04:59 +
"Koenker, Roger W"  wrote:


There are comments in various places, including R-extensions §5.4
suggesting that .Fortran is (nearly) deprecated and hinting that use
of .Call is more efficient and now preferred for packages.

My understanding of §5.4 and 5.5 is that explicit routine registration
is what's important for efficiency, and your package already does that
(i.e. calls R_registerRoutines()). The only two things left to add
would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
R_ARG_OUT/...) of the arguments of each subroutine.

Switching to .Call makes sense if you want to change the interface of
your native subroutines to accept arbitrary heavily structured SEXPs
(and switching to .External could be useful if you wanted to play with
evaluation of the arguments).



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

Re: [R-pkg-devel] checking windows timing?

[Balasubramanian Narasimhan]

FWIW, we dealt with the tests-taking-too-long problem for CVXR (which 
has a lot of tests) by mercilessly cutting out all tests on CRAN 
(testthat::skip_on_cran()) except for some fundamental ones on atoms, 
curvature, etc.  We then rely on Github actions (with NOT_CRAN = true) 
to run the full test suite on several platforms. Not perfect, but that's 
what worked for us.


-Naras

On 10/13/20 9:46 AM, Ben Bolker wrote:


  Following up on my questions from yesterday:

  I've been advised to (drastically) reduce the checking time of my 
package on CRAN's Windows platform (currently at 23 min). I've gone 
through and added a lot of conditionals to skip tests on CRAN.  I 
could reduce it farther but I'm starting to encounter seriously 
diminishing returns, e.g.


 * do I condition out some particular test that takes 6 seconds? 
(e.g., a little slow, but not egregious)
 * do I put \dontrun{} around an example that takes 6 seconds [I'm a 
bit confused about this, but as I understand it CRAN checks with 
--run-donttest ? \dontrun{} also sometimes provokes complaints from 
CRAN, because "you should only use \dontrun{} for code that cannot be 
run by users" ...]


  I don't want to spend forever tweaking things, and I don't want to 
comment/condition out all of my tests, but I would really prefer to 
avoid bouncing from CRAN again. I don't know a *reliable* way to test 
whether CRAN-checking on Windows will take <10 mins or not ...


  I don't have a local Windows test platform.

  win-builder gives timings for long-running components, but not for 
the whole run.


  r-hub gives a time for the entire build (19 min in my case) - but 
this includes the time to set up the virtual machine, install all 
packages, etc..


  I can approximately predict that most examples and tests will take 
twice as long on CRAN's windows machines (and four times as long since 
tests, at least, are checked on both i386 and x86_64 architectures).


  Testing is currently taking 6 minutes on my local machine (newish 
Ubuntu 18.04 laptop), so I guess have more work to do, but I wonder if 
anyone has suggestions ...


  cheers
    Ben Bolker

__
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] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

Just to close the loop on this: the drat suggestion for both packages 
and also moving things to enhances worked. I could do this also for 
Gurobi because it is LGPL'd. Thanks Toby and Dirk (for drat).


-Naras

On 9/9/20 5:16 PM, Balasubramanian Narasimhan wrote:

Thanks Toby, so there is hope.  The drat suggestion for rcbc is worth a
try, gurobi is noted as you recommend.

-Naras

On 9/9/20 4:38 PM, Toby Hocking wrote:

Hi Naras
I had a similar issue recently with
https://cloud.r-project.org/web/packages/nc/ --- it Suggests: re2r
which is a package that is no longer on CRAN, but available on github.
To solve the issue I just copied the re2r into a drat repo, which is a
CRAN-like repository hosted on github. More info on drat here
http://eddelbuettel.github.io/drat/DratForPackageAuthors.html So if
those solver packages you have in Suggests are open-source, you can
just copy them to your drat repo, and list that drat repo in
Additional_repositories. If they aren't open-source then you should
provide a description of how to obtain those packages in Description.
Something like "gurobi package is not available in any public
open-source repositories but can be downloaded for academic use free
of charge from $GUROBI_URL"
BTW thanks for your efforts in getting CVXR on CRAN, that is really
important work!
Toby


On Wed, Sep 9, 2020 at 10:40 AM Balasubramanian Narasimhan
mailto:na...@stanford.edu>> wrote:

 We've been struggling to get past CRAN's rejections for a new
 upload of
 CVXR.  The new version makes essentially one change to the existing
 version on CRAN: the addition of a DOI to an article to appear in
 JSS.
 We realize that CRAN may tighten policies in the meantime forcing
 some
 changes to be made, which we are happy to do. But we are not sure
 what.

 The automated check
 
<https://win-builder.r-project.org/incoming_pretest/CVXR_1.0-6_20200908_223033/>

 came back with 2 notes on Debian and Windows, both addressed in
 replies
 and submission comments. (Solaris failures are expected, also noted.)

 The communications with CRAN indicates that the problem might be that
 our package (the current version too) _suggests_ solvers not
 available
 on CRAN. These are either on github or on vendor websites (free to
 academics after login).  One reply from CRAN suggested that we either
 use the "Additional_repositories" field or provide some text in
 Description. The former is not applicable---these are not CRAN-like
 repositories---so we added text in the description with URL links.

 What could we be missing?

 Thanks.

 -Naras

 __
 R-package-devel@r-project.org
 <mailto: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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

Thanks Toby, so there is hope.  The drat suggestion for rcbc is worth a 
try, gurobi is noted as you recommend.

-Naras

On 9/9/20 4:38 PM, Toby Hocking wrote:
> Hi Naras
> I had a similar issue recently with 
> https://cloud.r-project.org/web/packages/nc/ --- it Suggests: re2r 
> which is a package that is no longer on CRAN, but available on github. 
> To solve the issue I just copied the re2r into a drat repo, which is a 
> CRAN-like repository hosted on github. More info on drat here 
> http://eddelbuettel.github.io/drat/DratForPackageAuthors.html So if 
> those solver packages you have in Suggests are open-source, you can 
> just copy them to your drat repo, and list that drat repo in 
> Additional_repositories. If they aren't open-source then you should 
> provide a description of how to obtain those packages in Description. 
> Something like "gurobi package is not available in any public 
> open-source repositories but can be downloaded for academic use free 
> of charge from $GUROBI_URL"
> BTW thanks for your efforts in getting CVXR on CRAN, that is really 
> important work!
> Toby
>
>
> On Wed, Sep 9, 2020 at 10:40 AM Balasubramanian Narasimhan 
> mailto:na...@stanford.edu>> wrote:
>
> We've been struggling to get past CRAN's rejections for a new
> upload of
> CVXR.  The new version makes essentially one change to the existing
> version on CRAN: the addition of a DOI to an article to appear in
> JSS.
> We realize that CRAN may tighten policies in the meantime forcing
> some
> changes to be made, which we are happy to do. But we are not sure
> what.
>
> The automated check
> 
> <https://win-builder.r-project.org/incoming_pretest/CVXR_1.0-6_20200908_223033/>
>
> came back with 2 notes on Debian and Windows, both addressed in
> replies
> and submission comments. (Solaris failures are expected, also noted.)
>
> The communications with CRAN indicates that the problem might be that
> our package (the current version too) _suggests_ solvers not
> available
> on CRAN. These are either on github or on vendor websites (free to
> academics after login).  One reply from CRAN suggested that we either
> use the "Additional_repositories" field or provide some text in
> Description. The former is not applicable---these are not CRAN-like
> repositories---so we added text in the description with URL links.
>
> What could we be missing?
>
> Thanks.
>
> -Naras
>
> __
> R-package-devel@r-project.org
> <mailto: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] Help in getting past CRAN submission rejections

[Balasubramanian Narasimhan]

We've been struggling to get past CRAN's rejections for a new upload of 
CVXR.  The new version makes essentially one change to the existing 
version on CRAN: the addition of a DOI to an article to appear in JSS.  
We realize that CRAN may tighten policies in the meantime forcing some 
changes to be made, which we are happy to do. But we are not sure what.


The automated check 
 
came back with 2 notes on Debian and Windows, both addressed in replies 
and submission comments. (Solaris failures are expected, also noted.)


The communications with CRAN indicates that the problem might be that 
our package (the current version too) _suggests_ solvers not available 
on CRAN. These are either on github or on vendor websites (free to 
academics after login).  One reply from CRAN suggested that we either 
use the "Additional_repositories" field or provide some text in 
Description. The former is not applicable---these are not CRAN-like 
repositories---so we added text in the description with URL links.


What could we be missing?

Thanks.

-Naras

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

[R-pkg-devel] Uncaught use of internal functions from other packages in R CMD check

[Balasubramanian Narasimhan]

At least one package on CRAN uses

get("foo", envir=asNamespace("imported_package"))

and passes check.

Is this known?

-Naras

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

Re: [R-pkg-devel] How to account for optional packages not necessarily on CRAN

[Balasubramanian Narasimhan]

Thanks Dirk!  I did not realize that suggested packages are not required 
to be on primary repos like CRAN, BioC.  We do indeed condition our code 
to check that. So I guess, we are good to go, as is.


I will, in due time, read the paper too...

-N

On 12/10/19 5:52 PM, Dirk Eddelbuettel wrote:

On 10 December 2019 at 17:22, Balasubramanian Narasimhan wrote:
| We've run into the following problem in integrating commercial and open
| source solvers in to our package CVXR. We have "Suggests" dependency on
| some packages that may not be available to CRAN.
|
| There are two main scenarios.
|
| 1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must
| further take action to ensure the binary is installed.  The recommended
| requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee
| the functionality desired even if it succeeds.
|
| 2. A suggested package is on github or a commercial vendor site only.
| The package code has references to such packages in the code, causing
| problems while checking on CRAN.
|
| It would seem, at least for 2 above, that separating the suggested
| functionality into other packages can ensure that birds of the same
| feather can flock together. But the shared internals make this
| impossible to do at the moment.
|
| The only thing I can think of is to ask CRAN to consider
| _R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?

You could use drat (or, if you prefer, roll a CRAN repo by hand) to host a
"CRAN-alike" repo on, say, GitHub or any other http(s)-accessible site, and
then use Additional_repository: with it.

Brooke and I have a fully worked in example for the case of large data
packages in the R Journal:

https://journal.r-project.org/archive/2017/RJ-2017-026/index.html

Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data

G. Brooke Anderson and Dirk Eddelbuettel , The R Journal (2017) 9:1, pages
486-497.

Abstract Data-only packages offer a way to provide extended functionality
for other R users. However, such packages can be large enough to exceed
the package size limit (5 megabytes) for the Comprehen sive R Archive
Network (CRAN). As an alternative, large data packages can be posted to
additional repostiories beyond CRAN itself in a way that allows smaller
code packages on CRAN to access and use the data. The drat package
facilitates creation and use of such alternative repositories and makes it
particularly simple to host them via GitHub. CRAN packages can draw on
packages posted to drat repositories through the use of the
‘Additonal_repositories’ field in the DESCRIPTION file. This paper
describes how R users can create a suite of coordinated packages, in which
larger data packages are hosted in an alternative repository created with
drat, while a smaller code package that interacts with this data is
created that can be submitted to CRAN.

Don't be misled by 'data' here--it works the same way with code. And it is
the _one_ option you have because Suggests: are not required to be on a
primary repo like CRAN or BioC.  Naturally, you then need to condition your
code on "is it here yet?" but you likely already do.

Hope this helps,  Dirk



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

[R-pkg-devel] How to account for optional packages not necessarily on CRAN

[Balasubramanian Narasimhan]

We've run into the following problem in integrating commercial and open 
source solvers in to our package CVXR. We have "Suggests" dependency on 
some packages that may not be available to CRAN.


There are two main scenarios.

1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must 
further take action to ensure the binary is installed.  The recommended 
requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee 
the functionality desired even if it succeeds.


2. A suggested package is on github or a commercial vendor site only. 
The package code has references to such packages in the code, causing 
problems while checking on CRAN.


It would seem, at least for 2 above, that separating the suggested 
functionality into other packages can ensure that birds of the same 
feather can flock together. But the shared internals make this 
impossible to do at the moment.


The only thing I can think of is to ask CRAN to consider 
_R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?


Thank you.

-Naras

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

Re: [Rd] gfortran 9 quantreg bug

[Balasubramanian Narasimhan]

On 8/4/19 7:26 AM, Berend Hasselman wrote:
> Roger,
>
> I have run
>
>   gfortran -c -fsyntax-only -fimplicit-none -Wall -pedantic rqbr.f
>
> in the src folder of quantreg.
>
> There are many warnings about defined but not used labels.
> Also two errors such as "Symbol ‘in’ at (1) has no IMPLICIT type".
> And warnings such as: Warning: "Possible change of value in conversion from 
> REAL(8) to INTEGER(4)  at ..."
>
> No offense intended but this fortran code is awful. I wouldn't want to debug 
> this before an extensive cleanup by
> getting rid of as many numerical labels as possible, indenting and doing 
> something about the warnings "Possible change of value ...".

The unused labels at least can be removed automatically at least for 
fixed form along the lines shown in steps 8 and 9 of

https://bnaras.github.io/SUtools/articles/SUtools.html

which pertain to lines 261--281 of

https://github.com/bnaras/SUtools/blob/master/R/process.R

In fact, here it is, excerpted.

library(stringr)
code_lines  <- readLines(con = "rqbr.f")
cat("Running gfortran to detect warning lines on unused labels\n")
system2(command = "gfortran",
 args = c("-Wunused", "-c", "rqbr.f", "-o", "temp.o"),
 stderr = "gfortran.out")
cat("Scanning gfortran output for warnings on unusued labels\n")
warnings <- readLines("gfortran.out")
line_numbers <- grep('rqbr.f', warnings)
label_warning_line_numbers <- grep(pattern = "^Warning: Label [0-9]+ at", 
warnings)
just_warnings <- sum(grepl('Warning:', warnings))

nW <- length(label_warning_line_numbers)
for (i in seq_len(nW)) {
 offending_line <- 
as.integer(stringr::str_extract(warnings[line_numbers[i]], pattern = 
"([0-9]+)"))
 code_line <- code_lines[offending_line]
 offending_label <- 
stringr::str_extract(warnings[label_warning_line_numbers[i]],
 pattern = "([0-9]+)")
 code_lines[offending_line] <- sub(pattern = offending_label,
   replacement = str_pad("", width = 
nchar(offending_label)),
   x = code_lines[offending_line])
}
writeLines(code_lines, con = "rqbr-new.f")

-Naras

> This is going to be very difficult.
>
> Berend Hasselman
>
>> On 4 Aug 2019, at 08:48, Koenker, Roger W  wrote:
>>
>> I’d like to solicit some advice on a debugging problem I have in the 
>> quantreg package.
>> Kurt and Brian have reported to me that on Debian machines with gfortran 9
>>
>> library(quantreg)
>> f = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5))
>> plot(f)
>>
>> fails because summary() produces bogus estimates of the coefficient bounds.
>> This example has been around in my R package from the earliest days of R, and
>> before that in various incarnations of S.  The culprit is apparently rqbr.f 
>> which is
>> even more ancient, but must have something that gfortran 9 doesn’t approve 
>> of.
>>
>> I note that in R-devel there have been some other issues with gfortran 9, 
>> but these seem
>> unrelated to my problem.  Not having access to a machine with an R/gfortran9
>> configuration, I can’t  apply my rudimentary debugging methods.  I’ve 
>> considered
>> trying to build gfortran on my mac air and then building R from source, but 
>> before
>> going down this road, I wondered whether others had other suggestions, or
>> advice about  my proposed route.  As far as I can see there are not yet
>> binaries for gfortran 9 for osx.
>>
>> Thanks,
>> Roger
>>
>> Roger Koenker
>> r.koen...@ucl.ac.uk
>> Department of Economics, UCL
>> London  WC1H 0AX.
>>
>>
>>
>>  [[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

[[alternative HTML version deleted]]

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

Re: [Rd] f951.exe: sorry, unimplemented: 64-bit mode not compiled

[Balasubramanian Narasimhan]

The original post below refers to an issue that arose with glmnet. It 
has since been fixed but the underlying problem (I believe) is a bug in 
gcc/gfortran 2.6.3 toolchain.  Here is a reproducible example, test.f90.


program dblbug
  real :: x, y
  x=2
  y=exp(dble(x))
end program dblbug

Compile with gfortran -fdefault-real-8 -o test test.f90.

The program will crash on Windows but not on i386 or x86_64 linux (same 
version of toolchain) but I think that says nothing.


Note: The glmnet code was originally written for single precision and 
hence the flag -fdefault-real-8. The fix was to just to remove the dble.


-Naras



On 5/4/12 6:58 PM, Simon Urbanek wrote:

On May 4, 2012, at 8:48 PM, Spencer Graves wrote:


Hello:


  Under my Windows 7 system, R CMD check DiercxkSpline_1.1-5.tar.gz fails 
because:


f951.exe: sorry, unimplemented: 64-bit mode not compiled in


This typically means that you're using the wrong (old) compiler. The new MinGW 
compilers support both -m32 and -m64. You have to set the PATH to the new 
compilers (in the gcc-4.6.3 subdirectory of Rtools) *before* any old compilers 
in Rtools.

Cheers,
Simon



make: *** [bispev.o] Error 1
gfortran -m64 -O2  -mtune=core2 -c bispev.f -o bispev.o
f951.exe: sorry, unimplemented: 64-bit mode not compiled in

make: *** [bispev.o] Error 1
ERROR: compilation failed for package 'DierckxSpline'


  A similar problem was reported for package glmnet 
(http://stackoverflow.com/questions/10291189/compiling-glmnet-failed-in-windows) plus one with R 
2.14.2 
(http://r.789695.n4.nabble.com/Problems-when-building-a-package-for-Windows-64-td4464488.html).  
However, I get this with R 2.15.0 and the latest R tools (reinstalled earlier today).  On R-Forge, 
DierckxSpline has Build status:  Current, which suggests that R-Forge does NOT have 
this problem.  I read through the two replies to these two earlier questions without seeing how to 
fix my problem.





  Thanks in advance for any suggestions.


  Spencer Graves

__
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


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