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
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
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:
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
(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
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
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
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
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
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
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
s://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
.
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
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
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
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]]
__
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
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 SU
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
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
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
ike "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
>
>
> O
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
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
:
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
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
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
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
28 matches
Mail list logo
