Re: [R-pkg-devel] RCMD check --as-cran on Windows

[Avraham Adler]

If it helps, in my experience, r-devel has those notes as well, so if you
send your package to the r-devel option on winbuilder, and it comes back
clean, you should be OK on all OSs, at least as respects the global
function issues.

Avi

On Thu, Jul 2, 2015 at 10:51 AM, Fay, Michael (NIH/NIAID) [E] <
m...@niaid.nih.gov> wrote:

> Hi,
>
> I am trying to update my NAMESPACE to include importFrom for packages that
> are included in the basic R distribution.
>
> When I build my packages and run: RMCD check --as-cran  on from Windows I
> get no NOTES. But   in other flavors, there are NOTES about "no visible
> global function definition for...".
>
> For example, see
>
> ftp://cran.r-project.org/pub/R/web/checks/check_results_bpcp.html
>
> I can get the NOTES from the website and attempt to fix them. But I cannot
> check them on my Windows machine since I have not installed linux on it.
>
> Is there a way to check for those NOTES without installing another
> operating system?
>
>
> mike
>
>
>
> **
> Michael P. Fay, PhD
> Mathematical Statistician
> Biostatistics Research Branch/DCR/NIAID
> 5601 Fishers Lane,  Room 4B53
> Rockville, MD 20852
> 240-669-5228
>
> For FexEx/UPS use:
> Rockville, MD 20852
>
> For US Mail use:
> Bethesda, MD 20892
>
> Disclaimer: The information in this e-mail and any of its attachments is
> confidential and may contain sensitive information.  It should not be used
> by anyone who is not the original intended recipient.  If you have received
> this e-mail in error please inform the sender and delete it from your
> mailbox or any other storage devices.  The National Institute of Allergy
> and Infectious Diseases (NIAID)  shall not accept liability for any
> statement made that are the sender's own and not expressly made on behalf
> of the NIAID by one of its representatives.
>
>
>
> [[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] recreating CRAN Testing environment

[Avraham Adler]

Even if you don't use Windows, it pays to submit your package to the
Winbuilder test of buth R-release and R-devel. The error reports, if any,
are often not-OS dependant and will serve as a good gaage as to how the
real CRAN will respond.

Avi

On Mon, Jul 20, 2015 at 1:59 PM, Ben Bolker  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 15-07-20 01:50 PM, Jonathan Callahan wrote:
> > I am (hopefully) at the end of a series of back-and-forth
> > submissions of a package to the CRAN upload site.
> >
> > I have done my best to test things by:
> >
> > - using devtools - running "R CMD check --as-cran" on the command
> > line - checking my package on OSX, win-builder.R and various 32 and
> > 64 bit linux virtual machines at DigitalOcean
> >
> > But I have never managed to recreate all of the notes and warning
> > messages that the CRAN testing comes up with.
> >
> > In an effort to save time and effort on both ends, can anyone
> > advise on what I need to do to generate ALL the warning messages
> > that the CRAN testing will find?
>
>The most important thing that you haven't explicitly mentioned is
> to test on the most recent development version of R (check out via
> Subversion/configure/make/make install from scratch).  Can you adjust
> your DigitalOcean settings accordingly?
>
>   Ben Bolker
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJVrTcSAAoJEOCV5YRblxUHNqUIAKMpuDZ5viQSBlyXpIqjtjEW
> Na6LhC5O/XcjmmrZHDftXAat2gTrRM0OJAn0cfzSZttdcJKowbMYfJzDWe/5oBCE
> QRQ0zwxbJY1cFHFyYR6r1zCe4ah4SzoGt+FmBYjtAKefvjm12tfQubhQlxPxZ1kV
> XFIfYTWHmHWNGlhZuokPE/GtdXK5/4MNF/32HxseNBRzc2SWqP3i6VKPnbN7LFgl
> xrjXsHQdqU3UaY37D44mInl+qm5y5reRSUi6NO0SrSh2WcVWTnqZ3HsUkFPND5tM
> NyzrfhtGN2wISsFq1J+dC87ajyeh6D8LTYBiokUnWQFOj8tPi1Zhff0LuTJi7Vc=
> =gytX
> -END PGP SIGNATURE-
>
> __
> 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] Delaporte: Test Errors on Sun Sparc

[Avraham Adler]

I recently changed the back-end compiled code for the Delaporte
package from C++ to Fortran/C, and after some birthing pains (and a
lot of patience shown by CRAN), it's fully functional _except_ on
sparc-sun-solaris2.10 [1]. There, 10 of the 44 tests return errors.
I've done enough research to know that there may be endian issues
involved, but I do not know how to address them.

Interestingly, some of the errors look as if they are caused by
returning the "ones-complement" (if that is a word, meaning returning
1 - x instead of x) in some cases. See tests 3, 4, 6, and 7 for
examples. In the next version (which won't be posted to CRAN for at
least a month 8-) ), I've expanded the number of tests from 44 to (at
least) 86 to try to more cleanly isolate possible failures, but I
don't have access to a sparc-based Sun server, nor is there one on
Rhub and win-builder, so I cannot test it.

Has anyone seen anything similar or does this ring any bells?

Thank you,

Avi

[1] 


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

[R-pkg-devel] Packages which use Fortran call "rwarn" for warnings?

[Avraham Adler]

Hello.

Would anyone know of a package which uses the rwarn subroutine, as
described in Writing R extensions 6.2.1, for error handling from
Fortran? I'm experimenting with it and getting overwhelmed with stack
errors and crashes, and could benefit from seeing it used properly.

Thank you,

Avi

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

[R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Avraham Adler]

Hello.

The Delaporte package works properly on all R-core platforms except
Solaris SPARC, where it  compiles properly but fails a number of its
tests [1]. Not having access to a SPARC testbed, I'm limited in what
kind of diagnostics I can do. One thing I have noticed is that a lot
of the failures occur when I am passing non-default logicals (like
lower tail or log). For example, the first failure at that link is
when "log = true" is supposed to be passed, but the SPARC answers are
the unlogged values. Of the 22 failed tests, 12 of them pass logicals.

I'll bring an example of how it is coded below, and if anyone
recognizes where SPARC specifically goes wrong, I'd appreciate. I
guess, if I absolutely had to, I could convert the logical to an
integer in C and pass the integer to Fortran which should work even
for SPARC, but I'd prefer not to if I could help it.

Thank you,

Avi

[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html

*Example Code*

R code:

ddelap <- function(x, alpha, beta, lambda, log = FALSE){
  if(!is.double(x)) {storage.mode(x) <- 'double'}
  if(!is.double(alpha)) {storage.mode(alpha) <- 'double'}
  if(!is.double(beta)) {storage.mode(beta) <- 'double'}
  if(!is.double(lambda)) {storage.mode(lambda) <- 'double'}
  if(any(x > floor(x))) {
warning("Non-integers passed to ddelap. These will have 0 probability.")
  }
  .Call(ddelap_C, x, alpha, beta, lambda, log)
}

C code:

void ddelap_f(double *x, int nx, double *a, int na, double *b, int nb,
double *l, int nl,
  int *lg, double *ret);

extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP lg){
  const int nx = LENGTH(x);
  const int na = LENGTH(alpha);
  const int nb = LENGTH(beta);
  const int nl = LENGTH(lambda);
  SEXP ret;
  PROTECT(ret = allocVector(REALSXP, nx));
  ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb, REAL(lambda),
nl, LOGICAL(lg), REAL(ret));
  UNPROTECT(1);
  return(ret);
}

Fortran: (not posting ddelap_f_s as that doesn't handle the logging)

subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")

integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
logical(kind = c_bool), intent(in)   :: lg
! Log flag
integer  :: i
! Integer

!$omp parallel do default(shared) private(i)
do i = 1, nx
if (x(i) > floor(x(i))) then
pmfv(i) = ZERO
else
pmfv(i) = ddelap_f_s(x(i), a(mod(i - 1, na) + 1), &
 b(mod(i - 1, nb) + 1), l(mod(i -
1, nl) + 1))
end if
end do
!$omp end parallel do

if (lg) then
pmfv = log(pmfv)
end if

end subroutine ddelap_f

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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Avraham Adler]

On Wed, Mar 15, 2017 at 12:19 PM, William Dunlap  wrote:
> I don't know about the current Sparc Fortran compilers, but over the
> years have learned not to try to pass logicals and character strings
> between C and Fortran.  I have seen Fortran compilers that treated
> integer -1 (all bits 1) as .true. and anything else as .false. and I
> have see ones that looked only at bit 7, counting from the right, to
> determine the value.
>
> I recommend changing your Fortran code to accept an integer instead of
> a logical for boolean inputs and outputs.


I was using the iso_c_bindings in Fortran 2003, but I guess they are
not part of the SPARC compiler. I will probably end up doing that.
Thank you.

Avi

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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Avraham Adler]

On Wed, Mar 15, 2017 at 11:09 AM, J C Nash  wrote:
> Possibly tangential, but has there been any effort to set up a Sparc
> testbed? It
> seems we could use a network-available (virtual?) machine, since this
> platform is
> often the unfortunate one. Unless, of course, there's a sunset date.
>

Is this something that can be linked to the rhub suite of testbeds at
github? That would be fantastic.

Avi

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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Avraham Adler]

On Wed, Mar 15, 2017 at 12:19 PM, William Dunlap  wrote:
> I don't know about the current Sparc Fortran compilers, but over the
> years have learned not to try to pass logicals and character strings
> between C and Fortran.  I have seen Fortran compilers that treated
> integer -1 (all bits 1) as .true. and anything else as .false. and I
> have see ones that looked only at bit 7, counting from the right, to
> determine the value.
>
> I recommend changing your Fortran code to accept an integer instead of
> a logical for boolean inputs and outputs.

Posting for posterity's and future similar questions' sakes [1], I am
relieved to find that removing reliance on the Fortran 2003
ISO_C_binding of c_bool, casting logicals explicitly as integers of 0
or 1, and testing for those integers in Fortran, seems to have finally
sated the SPARCmonster's appetite. [2]

Thank you very much!

Avi

[1] https://xkcd.com/979/
[2] https://cran.r-project.org/web/checks/check_results_Delaporte.html
- Version 6.0.0

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

Re: [R-pkg-devel] R_registerRoutines, etc.

[Avraham Adler]

On Sat, Apr 22, 2017 at 6:13 PM, Rolf Turner  wrote:
>
> The foregoing "official" way would seem to apply to functions called by
> ".Call" (which I never use; it is way over my head).  What about functions
> called by ".Fortran()" or ".C()"?
>
>> | (b) For the sake of completeness, how *does* one replace the "void
>> *"
>> | constructions with "actual types" in a correct manner?
>> |
>> |  Example:  In my init.c file I currently have (as produced by
>> |  package_native_routine_registration_skeleton()) :
>> |
>> | > extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);
>> |
>> |  The code in mnnd.f reads:
>> |
>> | > subroutine mnnd(x,y,n,dminbig,dminav)
>> | > implicit double precision(a-h,o-z)
>> | > .
>> |
>> |  I.e. the "actual types are "double precision",
>> |  "double precision", "integer", "double precision",
>> |  "double precision".
>> |
>> |  So in this case I should (?) replace
>> |
>> | > extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);
>> |
>> |  by  what?  Can anyone tell me?
>>
>> No idea. I don't deal in Fortran. C++ is more than enough fun for me ;-)
>
>
> Well, C++ is too much for me.  I find Fortran generally very easy.  Be that
> as it were, are there any Fortran users out there who can answer my
> question, above?
>

I cannot answer your question completely, as I use .Call() to call
Fortran from R via C instead of using .Fortran—from what I have read
and researched, it is faster.

That being said, maybe this will help. Given a subroutine in Fortran
which starts like:

subroutine ddelap_f(x, nx, a, na, b, nb, l, nl, lg, pmfv) bind(C,
name="ddelap_f")

integer(kind = c_int), intent(in), value :: nx, na, nb, nl
! Sizes
real(kind = c_double), intent(in), dimension(nx) :: x
! Observations
real(kind = c_double), intent(out), dimension(nx):: pmfv
! Result
real(kind = c_double), intent(in):: a(na), b(nb),
l(nl)! Parameters
integer(kind = c_int), intent(in):: lg
! Log flag
integer  :: i
! Integer

The corresponding C code which calls it is

void ddelap_f(double *x, int nx, double *a, int na, double *b, int
nb, double *l, int nl,
  int *lg, double *ret);

and the actual code called by R is:

extern SEXP ddelap_C(SEXP x, SEXP alpha, SEXP beta, SEXP lambda, SEXP lg){
  const int nx = LENGTH(x);
  const int na = LENGTH(alpha);
  const int nb = LENGTH(beta);
  const int nl = LENGTH(lambda);
  SEXP ret;
  PROTECT(ret = allocVector(REALSXP, nx));
  ddelap_f(REAL(x), nx, REAL(alpha), na, REAL(beta), nb,
REAL(lambda), nl, INTEGER(lg), REAL(ret));
  UNPROTECT(1);
  return(ret);
}

Also, I don't use the "automatic" concatenation of the "c_" to my
Fortran functions, but name them individually and use Fortran 2003 ISO
C bindings (except for booleans).

If it helps, take a look at the source code at
. As of now, it passes all R
checks and so must have appeased the registration requirements 8-)

Thank you,

Avi

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

Re: [R-pkg-devel] R_registerRoutines, etc.

[Avraham Adler]

On Sun, Apr 23, 2017 at 7:36 PM, Duncan Murdoch
 wrote:
> On 23/04/2017 6:18 PM, Rolf Turner wrote:
[SNIP]
> This is important:  *there is no way to pass a Fortran "LOGICAL" from R to
> Fortran*.
>
> The issue is that different Fortran compilers store LOGICAL in different
> ways.  Some are equivalent to int with 0 for FALSE, all else for TRUE, but
> not all are.  So don't rely on it.
>
> If you need to call a Fortran subroutine that takes a LOGICAL argument, you
> need to write another Fortran subroutine that takes an INTEGER argument.
> Then compute "arg NE 0" (or whatever the Fortran version is for testing not
> equal to zero) and pass that to the original routine.

I went through this very headache over the last few months. Even using
Fortran 2003 ISO C bindings, I ended up having to convert to integers
for Solaris SPARC. I know you are using .Fortran() and not .Call(),
but perhaps you would find this commit of some value
,

Good luck!

Avi

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

Re: [R-pkg-devel] R_registerRoutines, etc.

[Avraham Adler]

On Sun, Apr 23, 2017 at 7:51 PM, Dirk Eddelbuettel  wrote:
>
> On 24 April 2017 at 11:47, Rolf Turner wrote:
>
> And per Duncan's last (and his earlier emails) maybe you need to call from R
> into C (for finer control over the interface) and only then call your Fortran
> worker function.  To hide it, and its plausibly more limited interface,
> entirely from R.
>

What I found useful was Drew Schmidt's example Romp. Where he also
recommends against .Fortran() in general due to performance overheads.



Avi

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

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

[Avraham Adler]

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry  wrote:
> I tried to upload my package to CRAN and did not pass the the incoming 
> checks. This was because the use of ieee_arithmetic module in a fortran 
> subroutine in the src folder. I built and checked the package using (R CMD 
> build) and (R CMD check) under IOS system and it is working fine without 
> errors. The gcc version in my system is (GNU Fortran (GCC) 5.2.0) while the 
> gcc version in the CRAN system is 4.9.3. This is the message that I have got 
> from the CRAN:

I ran into this problem with my Delaporte package. GCC 4.9.3 does not
support the IEEE modules, which were added in the GFortran tied to GCC
5.0. I believe you will have to re-write your code to comply with
4.9.3 until Jeroen et. al. release a new version of Rtolls built on a
newer version of GCC.

Avi

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

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

[Avraham Adler]

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry  wrote:
> Hi all,
>
> I tried to upload my package to CRAN and did not pass the the incoming 
> checks. This was because the use of ieee_arithmetic module in a fortran 
> subroutine in the src folder. I built and checked the package using (R CMD 
> build) and (R CMD check) under IOS system and it is working fine without 
> errors. The gcc version in my system is (GNU Fortran (GCC) 5.2.0) while the 
> gcc version in the CRAN system is 4.9.3. This is the message that I have got 
> from the CRAN:
[snip]
>
> I used the ieee_arithmetic in some subroutines to read and write results of 
> Infinity values. I used it inside the subroutine as
>
> IF (ieee_support_inf(Inf)) THEN Inf = ieee_value(Inf, ieee_positive_inf) END 
> IF
>

Hello, Waleed.

I handled Inf and NaN by writing a C function that passes the magic
code words R_NaN and INFINITY and called them as external functions in
Fortran. See the source code of 'utils_and_wrappers.c' and
'delaporte.f95' at [1] for a working example of "set_nan" and
"set_inf"ideas. Originally, I used the actual bitpatterns to make the
functions pure, if not elemental, but Soldaris SPARC through a fit
since it was the opposite endian from the rest of the known universe.
Using the magic R words will ensure that the proper values will be
passed regardless of platform.

Hope that helps,

Avi

[1] https://bitbucket.org/aadler/delaporte

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

Re: [R-pkg-devel] Trouble installing XML on Windows 7 (64-bit)

[Avraham Adler]

On Fri, Dec 15, 2017 at 12:02 PM, Haigh, Rowan
 wrote:
> Hi Duncan,
>
> Well I finally managed to install XML from source in Windows under R-devel. 
> Basically it was a clue provided by user wlandau-lilly (last message on 
> https://github.com/igraph/igraph/issues/915), and discussions between Gábor 
> and user stewid 
> (https://github.com/krlmlr-archive/r-portable/issues/3#issuecomment-72928971) 
> that lead to success.
>
> 1. Download local323.zip from http://www.stats.ox.ac.uk/pub/Rtools/libs.html ;
>
> 2. Copy the files in local323.zip/include/libxml2/libxml/ directory to 
> R-devel/include/libxml/ ;
>
> 3. Copy entire contents of local323.zip (directories include/ and lib/) to 
> new directory C:/Apps/R/Rtools/local323/ ;
>
> 4. Change line 31 of two files `Makeconf' (in C:/Apps/R/Rdev/etc/i386/ and 
> C:/Apps/R/Rdev/etc/x64/),  from `#LOCAL_SOFT' to `LOCAL_SOFT = 
> C:/Apps/R/Rtools/local323'  ;
>
> 5. In R-devel, issue command `install.packages("XML", type = "source")'.
>

Sorry I didn't see this earlier. I've been building R from source on
Windows for years, although XML is one of the three packages I usually
build from binary (the other two being stringi and BH).

As per the instructions (which also tell you where to get the extras)
[1], you don't need to change MakeConf. You need to copy Mkrules.dist
to Mkrules.local and set LOCAL_SOFT to the directory you need and then
ensure EXT_LIBS = $(LOCAL_SOFT) is active. And yes, you need to put
the extra goodies in RLocalSoft (EXCEPT for Tcl), and that includes
Curl and ICU if you want to include that support.

Thanks,

Avi

[1] https://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source

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

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Avraham Adler]

Exactly. Is square is just brow=ncol, is positive definite can be
implemented as a check that all eigenvalues > 0, which can be done with
base, and is.symmetric can be simply brute forced in a loop comparing i,j
with j,i.

The fewer dependencies a package has, the more robust it is. It’s a fine
balance between not reinventing the wheel and ceding too much stability to
other packages.

Thanks,

Avi

On Wed, Jun 2, 2021 at 3:15 PM John Harrold 
wrote:

> To add another option. In the past when this has happened to me I've found
> other packages that provide similar functionality.
>
> I'm assuming that is.square just checks the number of columns == number of
> rows? And the others can probably be implemented pretty easily.
>
> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton  wrote:
>
> > My package uses the MIT license, so would that not meet the compatibility
> > requirements?
> >
> > I will attempt to reach out to the package author - thanks for your help!
> >
> > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:
> >
> > > That all sounds exactly right.
> > >GPL >= 2 allows you to use the material without asking permission as
> > > long as your package is compatibly licensed (e.g. also GPL).
> > >Under normal circumstances it would be polite to ask permission, but
> > > if the reason for doing this is that the maintainer is unreachable in
> > > the first place ...
> > >
> > >   If you want to try a little harder, it seems quite possible that you
> > > can reach the matrixcalc maintainer at the (personal) e-mail address
> > > shown in this page:
> > >
> > >
> >
> https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042
> > >
> > >(Possibly an identity confusion, but I rate that as unlikely based
> on
> > > other facebook snooping)
> > >
> > >I don't think a short, polite e-mail request would be out of bounds,
> > > they can always ignore it or tell you to go away.
> > >
> > >cheers
> > > Ben Bolker
> > >
> > > On 6/2/21 1:15 PM, Ben Staton wrote:
> > > > Hello,
> > > >
> > > > Thank you for your detailed list of solutions.
> > > >
> > > > I was initially tempted to go with option 1 (move matrixcalc to
> > suggests
> > > > and check for its existence before using functions that rely on it),
> > but
> > > as
> > > > mentioned, this is not a long term fix.
> > > >
> > > > I unfortunately can't take on the responsibilities of option 2
> > (becoming
> > > > the package maintainer) -- there is much that this package does that
> I
> > do
> > > > not understand, and do not wish to feign authority!
> > > >
> > > > I plan to take option 3 (copy the needed functions into my package).
> > > There
> > > > are only three functions I need from matrixcalc, and all three are
> > fairly
> > > > simple (is.square.matrix
> > > > ,
> > > > is.symmetric.matrix
> > > > , and
> > > > is.positive.definite
> > > > ) and
> > > there
> > > > is only one function in postpack that needs them. I plan to define
> them
> > > > within the postpack function. matrixcalc is licensed under GPL >= 2
> and
> > > > based on my scan of the license text, this is allowed. Is that
> correct?
> > > >
> > > > Regarding option 4 (contacting the matrixcalc maintainer), the
> original
> > > > email from CRAN mentioned that they have attempted to contact the
> > package
> > > > author with no response.
> > > >
> > > > Thank you!
> > > >
> > > > On Wed, Jun 2, 2021 at 9:52 AM J C Nash 
> wrote:
> > > >
> > > >> I just downloaded the source matrixcalc package to see what it
> > > contained.
> > > >> The functions
> > > >> I looked at seem fairly straightforward and the OP could likely
> > develop
> > > >> equivalent features
> > > >> in his own code, possibly avoiding a function call. Avoiding the
> > > function
> > > >> call means NAMESPACE etc. are not involved, so fewer places for
> > getting
> > > >> into
> > > >> trouble, assuming the inline code works properly.
> > > >>
> > > >> JN
> > > >>
> > > >>
> > > >> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
> > > >>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
> > >  Hello,
> > > 
> > >  I received an email notice from CRAN indicating that my R package
> > >  ('postpack') will be archived soon if I do not take any action
> and I
> > > >> want
> > >  to avoid that outcome. The issue is not caused by my package, but
> > > >> instead a
> > >  package that my package depends on:
> > > 
> > >  "... package 'matrixcalc' is now scheduled for archival on
> > 2021-06-09,
> > >  and archiving this will necessitate also archiving its strong
> > reverse
> > >  dependencies."
> > > 
> > >  Evidently, xyz has been returning errors on new R builds prompting
> > > CRAN
> > > >> to
> > >  list it as a package to be archived. My package, 'postpack' has
>

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Avraham Adler]

On the other hand, MIT does not restrict what you do with your own
contributions, just the included code. GPL restricts rights on
redistributing your own work if a component is GPL as well.

Avi

On Thu, Jun 3, 2021 at 6:51 AM Berwin A Turlach
 wrote:
>
> G'day Jeff,
>
> On Wed, 02 Jun 2021 11:34:21 -0700
> Jeff Newmiller  wrote:
>
> Not that I want to get involved in old discussions :), but...
>
> > MIT is more permissive than GPL2,
>
> ... this statement depends on how one defines "permissive".
>
> MIT requires that you fulfil: "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software." (https://opensource.org/licenses/MIT)
>
> Whereas GPL 2 merely requires that you "[...] conspicuously and
> appropriately publish on each copy an appropriate copyright notice and
> disclaimer of warranty [...]".
>
> Thus, arguably, GPL 2 is more permissive.
>
> >  so there is a collision there.
>
> Well, luckily the FSF does not think that the MIT license is
> incompatible with the GPL license, though it finds the term "MIT
> license" misleading and discourages its use, see
> https://www.gnu.org/licenses/license-list.html
>
> Cheers,
>
> Berwin
>
> __
> 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] Tools beyond roxygen2 to write Rd documentation

[Avraham Adler]

I always write mine by hand. Used to do it in notepad++. Now I just do it
as a text file in the Rstudio IDE.

Avi

On Thu, Aug 5, 2021 at 11:52 AM Martin Maechler 
wrote:

> > Iago Giné-Vázquez
> > on Thu, 05 Aug 2021 08:09:48 + writes:
>
> > Dear all, Are there any tools to edit .Rd files by hand
> > (so avoiding roxygen2), as an editor (like could be
> > *RdStudio*, à la RStudio or TeXstudio) or a plugin for ViM
> > or another editor (like could be *vim-Rd*, à la
> > vim-latex)?
>
> > Thanks for your answers,
>
> > Stay safe, Iago
>
> Yes, of course:
> "All good" R package authors edit *.Rd files by hand
> ((;-), well no, I know it's not true ..
>  I personally use roxygen (in ESS, see below) only sometimes at the very
>  beginning of writing a new function, or for functions that I
>  do *not* export, because there's a nice key stroke to create
>  the outline). ... and if I export that function use the
>  Roxygen -> Rd *once* only, and from then on, I edit the *.Rd nicely
>  including using descriptions lists, some math, etc... all well
>  indented, nicely human-readable etc, much nicer than hidden in
>  roxygen R comments)
>
> Rstudio has supported *.Rd in the past but as I'm not using it
> regularly .. I don't know if they dropped it now... that would
> honestly surprise me, though.
>
> Rather  ESS (Emacs Speaks Statistics) has always well supported
> Rd editing, and I thought the  vim - plugin for R would also
> support *.Rd  but probably not ??
>
> Best,
> Martin
>
> --
> Martin Maechler
> ETH Zurich,  R Core Team  (*and* ESS Core team)
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] "Connections left open" Error

[Avraham Adler]

On Fri, Aug 27, 2021 at 10:25 AM Uwe Ligges 
wrote:

>
>
> On 23.08.2021 18:07, Alan Aw wrote:
> > Hi,
> >
> > I submitted a package to CRAN, but it keeps failing a particular check
> for
> > Windows. This error shows up when I check my code examples.
> >
> > Error: connections left open:
> >>  <-CRANwin.fb05.statistik.uni-dortmund.de:11602
> >>  (sockconn)
> >>  <-CRANwin.fb05.statistik.uni-dortmund.de:11602
> >>  (sockconn)
> >> Execution halted
> >
> >
> > For context, my code example does the following.
> >
> > suppressWarnings(require(doParallel))
> >> registerDoParallel(cores = 2)
> >>
> >
> >
> > # Some code examples that use foreach and %dopar%
> >
> >
> >
> > stopImplicitCluster()
> >
> >
> > Other contextual information:
> >
> > - I already import doParallel in the DESCRIPTION file.
> > - My package passes all checks on the Linux machine.
> >
> > I have read elsewhere (e.g., this thread
> > ) that examples
> with
> > parallelization lead to this error. However stopImplicitCluster() does
> not
> > seem to fix it.
> >
> > Could someone familiar with this please troubleshoot? Thank you.
>
> No idea about the doParallel package, but perhaps it helps to open a
> cluster explicitly and in the end stop exactly that cluster?
>
> Best,
> Uwe Ligges
> >
> > Alan


As per Dr. Ligges, I’ve had more success closing the named cluster than
using stopImplicit.

Avi

>
> --
Sent from Gmail Mobile

[[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] CRAN no longer checking for solaris?

[Avraham Adler]

Would this mean we could start using little endian bit strings, as I think
only the Solaris platform was big endian (or was it the other way around)?

Avi

On Sun, Dec 5, 2021 at 8:56 PM Dirk Eddelbuettel  wrote:

>
> On 5 December 2021 at 17:23, Travers Ching wrote:
> | I see that there doesn't exist a Solaris flavor on any CRAN check page.
> | However, I'm certain that Solaris was being checked up until very
> recently.
> |
> | Is this just temporary?
> |
> | Is there any information for the future of Solaris on CRAN?
>
> No "official" word yet on this list, r-devel or elsewhere, or via commits
> to
> the CRAN Policy (which a cron job of mine monitors).
>
> But Henrik was eagle-eyed and spotted a number of changes to the svn (or
> git
> mirror thereof) writing Solaris out of the official documentation:
>
>   https://twitter.com/henrikbengtsson/status/1466877096471379970
>
> So yes it seems like an era is coming to a close.
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] Two problems with fda

[Avraham Adler]

Hello, Spencer.

I am solely on Windows, so I am not familiar with the workflow you
need, but I have found the following posts which discuss tlmgr in the
context of a Github action. Perhaps they can provide you with insight:
[1], [2].

Hope that helps!

Avi

[1] 
https://tex.stackexchange.com/questions/551383/cant-run-tex-lives-tlmgr-in-a-github-action
[2] https://github.com/xu-cheng/texlive-action

On Thu, Apr 28, 2022 at 2:28 PM Duncan Murdoch  wrote:
>
> On 28/04/2022 10:17 a.m., Spencer Graves wrote:
> > Hi, Duncan et al.:
> >
> >
> > I passed Duncan's suggestions to Jim Ramsay, who implemented
> > something -- not sure what -- and "fda_6.0.3.tar.gz has been built for
> > Windows and will be published within 24 hours in the corresponding CRAN
> > directory"!  (Thanks, Duncan!)
>
> You're welcome.
>
> > My attempts to fix ".github/workflows/R-CMD-check.yaml" have so far
> > been unsuccessful:
> >
> >
> > https://github.com/JamesRamsay5/fda/commit/3dd1938d95055ed798a8b6caebcfe0eb8a03668b
>
> Line 50 in that update looks wrong.  It might make sense to have "tlmgr
> --version" just after line 53, indented like lines 54 and 55.
>
> Duncan Murdoch
>
> >
> > For me currently, yaml = "yet another misunderstood language" ;-)
> > And I've misplaced Yihui Xie's recommendations on how to ask for help.
> > I remember he suggested submitting a question first to Stack Exchange or
> > Stack Overflow or ..., but I can't find those recommendations, so I
> > thought I'd here thank Avraham Adler  and
> > everyone else who has considered replying to this question, hoping that
> > someone can help me take the next step.
> >
> >
> > Thanks again,
> > Spencer Graves
> >
> >
> > On 4/26/22 11:46 AM, Duncan Murdoch wrote:
> >> On 25/04/2022 8:24 p.m., Duncan Murdoch wrote:
> >>...
> >>>
> >>> \value{
> >>>  These functions return either a standard \code{fRegress} fit
> >>> object or
> >>>  or a model specification:
> >>>  \item{The \code{fRegress} fit object case:}{
> >>>
> >>>
> >>> Aha, in a \value{} section, bare \items are supposed to mark components
> >>> of the value, so they are automatically code.  I think the fix for this
> >>> is to make it an explicit \describe list:
> >>>
> >>> \value{
> >>>  These functions return either a standard \code{fRegress} fit
> >>> object or
> >>>  or a model specification:
> >>>  \describe{
> >>>\item{The \code{fRegress} fit object case:}{
> >>>
> >>>  ... eventually ...
> >>>
> >>>  }
> >>
> >> An even simpler fix:  don't mark the section title as an \item, i.e.
> >> write as
> >>
> >> \value{
> >>  These functions return either a standard \code{fRegress} fit object or
> >>  or a model specification.
> >>
> >>  The \code{fRegress} fit object case:
> >>
> >>
> >>  \item{field}{description  }
> >>
> >>
> >> Duncan Murdoch
>
> __
> 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] No package called 'scales' (r-oldrel-windows)

[Avraham Adler]

Scales is the package which is called when you use something like
"dollar" or "comma" in scale_x_whatever(); perhaps you have a similar
invocation without realizing it?

Thanks,

Avi

On Tue, Aug 23, 2022 at 5:40 PM Paul Hibbing  wrote:
>
> Hi all,
>
> I recently submitted an update to `PAutilities`.
>
> It has errored for r-oldrel-windows with "there is no package called
> 'scales'" (see 
> https://www.r-project.org/nosvn/R.check/r-oldrel-windows-ix86+x86_64/PAutilities-00install.html).
>
> I am a bit mystified by this, as the package builds fine on Winbuilder
> old release (see
> https://win-builder.r-project.org/g6EPG1y3nGN9/00check.log), as well
> as my older local Windows installation (4.0.5) and all other platforms
> I have checked.
>
> Does anyone have insights about this? I assume it is related to
> dependency on ggplot2, but I'm struggling to replicate the error and
> thus unsure where to start.
>
> Many thanks,
> Paul
>
> __
> 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] Proper way to express Fortran 2008 dependence for R package

[Avraham Adler]

I would like to convert some of my hand-rolled Fortran code to Fortran
intrinsics which entered the language in Fortran 2008, which should be
extremely widely supported at this time. Specifically, I would like to
use the log_gamma function and ieee_arithmetic functions and values.
If it helps, the current package is at [1] and devel branch with new
code is at [2].

If I understand it correctly, WRE allows for dependence on Fortran
2008 by explicitly passing -std=f2008 in PKG_FFLAGS (WRE section 1.2.3
Using F9x code [3]). However, checking a package as-cran with that
addition delivers a warning (further confirmed by win-builder and
rhub).

My question is is it appropriate to submit a package with that warning
and note it in the submission or is there a better way to express
reliance on Fortran 2008. The implication from WRE 1.2.4 is that
passing standards in Makevars is preferable to stating them in
DESCRIPTION, at least as regards C++.

What somewhat complicates matters is that if I build my package
(Rtools43 on Windows 10) without passing "-std=f2008" it still builds
properly and passes all the tests because Rtools43 is based on GCC12.2
which supports Fortran 2008 intrinsics. So I can probably submit it
without the flag, but someone with a very old Fortran installation may
suffer.

I understand being told I should just address CRAN directly, but I
thought I would try the collected institutional memory here first.

Thank you,

Avi

[1] https://github.com/aadler/Delaporte
[2] https://github.com/aadler/Delaporte/tree/devel
[3] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-F9x-code

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

Re: [R-pkg-devel] Proper way to express Fortran 2008 dependence for R package

[Avraham Adler]

For closure, I was advised by Professor Ripley to both pass
"-std=f008" in Makevars and add "SystemRequirements: A version of
gfortran supporting Fortran 2008" to the DESCRIPTION. CRAN accepted
the package with those two changes. I also note that the R Daily News
of 2023-02-03 [1] has the following entry under "R-devel": ‘check’'s
‘checking compilation flags in Makevars’ has been relaxed to accept
the use of flags such as ‘-std=f2008’ in ‘PKG_FFLAGS’. Hopefully, this
means future packages will have an easier time relying on more modern
features, albeit they are 5 or 15 years old by now :).

Thank you,

Avi

[1]: 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2023/02/02#n2023-02-02

On Mon, Jan 30, 2023 at 12:12 AM Avraham Adler  wrote:
>
> I would like to convert some of my hand-rolled Fortran code to Fortran
> intrinsics which entered the language in Fortran 2008, which should be
> extremely widely supported at this time. Specifically, I would like to
> use the log_gamma function and ieee_arithmetic functions and values.
> If it helps, the current package is at [1] and devel branch with new
> code is at [2].
>
> If I understand it correctly, WRE allows for dependence on Fortran
> 2008 by explicitly passing -std=f2008 in PKG_FFLAGS (WRE section 1.2.3
> Using F9x code [3]). However, checking a package as-cran with that
> addition delivers a warning (further confirmed by win-builder and
> rhub).
>
> My question is is it appropriate to submit a package with that warning
> and note it in the submission or is there a better way to express
> reliance on Fortran 2008. The implication from WRE 1.2.4 is that
> passing standards in Makevars is preferable to stating them in
> DESCRIPTION, at least as regards C++.
>
> What somewhat complicates matters is that if I build my package
> (Rtools43 on Windows 10) without passing "-std=f2008" it still builds
> properly and passes all the tests because Rtools43 is based on GCC12.2
> which supports Fortran 2008 intrinsics. So I can probably submit it
> without the flag, but someone with a very old Fortran installation may
> suffer.
>
> I understand being told I should just address CRAN directly, but I
> thought I would try the collected institutional memory here first.
>
> Thank you,
>
> Avi
>
> [1] https://github.com/aadler/Delaporte
> [2] https://github.com/aadler/Delaporte/tree/devel
> [3] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-F9x-code

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

Re: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Avraham Adler]

On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch  wrote:
>
> On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> >> I recently submitted a package to CRAN with "SystemRequirements: C++11".
> >> This raises the following NOTE on R-devel, and I was asked to fix and
> >> resubmit:
> >>
> >> * checking C++ specification ... NOTE
> >> Specified C++11: please update to current default of C++17
> >>
> >> If I understand correctly, I have two options, neither of which will work:
> >> 1. Remove "SystemRequirements: C++11" entirely. The problem with this is
> >> that on systems with older versions of R (3.6 and below, I believe), it may
> >> try to compile the package with an older C++ standard, which will fail.
> >> 2. Update it to "SystemRequirements: C++17". The problem here is that on
> >> systems that don't have a C++17 compiler, the package won't build -- even
> >> though the package only actually requires a C++11 compiler.
> >>
> >> How should I deal with this?
> >
> > Are you allowed to say "C++11 or C++17"?
>
> Actually I can partially answer this:  the test is not based on
> SystemRequirements, but on the log of the build, which now contains
> lines like this:
>
>using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
>using C++ compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
>using C++11
>using SDK: ‘MacOSX11.1.sdk’
>
> I get "using C++11" because of this line in Makevars:
>
>CXX_STD = CXX11
>
> So I guess the answer is to change your Makevars to make that line
> conditional on running under an old version of R.  If you figure out how
> to do that, could you post the recipe here?

I believe this is closely related to this email [1]. Dirk and I and
Aymeric have been going through the same issue with nloptr as well.
Our current opinion is to leave it out, as it would restrict more
users to demand C++17, which is unneeded, than to have users with over
a decade old compiler which does not have C++11. Dirk and Aymeric,
please chime in if I have misstated. Regardless, according to
Professor Ripley, if you require specific features, you should mark
them in _both_ Makevars and SystemRequirements, which is implied in
the "r-devel" version of WRE which adds the words "also" in section
1.2.4.

Thanks,

Avi

[1] https://stat.ethz.ch/pipermail/r-package-devel/2023q1/008865.html

>
> Duncan Murdoch
>
> __
> 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] How to update "SystemRequirements: C++11"?

[Avraham Adler]

"If a package does have a src/Makevars[.win] file then also setting
the make variable ‘CXX_STD’ there is recommended,"

Avi

On Mon, Feb 6, 2023 at 10:58 PM Iñaki Ucar  wrote:
>
> On Mon, 6 Feb 2023 at 23:27, Avraham Adler  wrote:
> >
> > On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch  
> > wrote:
> > >
> > > On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > > > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> > > >> I recently submitted a package to CRAN with "SystemRequirements: 
> > > >> C++11".
> > > >> This raises the following NOTE on R-devel, and I was asked to fix and
> > > >> resubmit:
> > > >>
> > > >> * checking C++ specification ... NOTE
> > > >> Specified C++11: please update to current default of C++17
> > > >>
> > > >> If I understand correctly, I have two options, neither of which will 
> > > >> work:
> > > >> 1. Remove "SystemRequirements: C++11" entirely. The problem with this 
> > > >> is
> > > >> that on systems with older versions of R (3.6 and below, I believe), 
> > > >> it may
> > > >> try to compile the package with an older C++ standard, which will fail.
> > > >> 2. Update it to "SystemRequirements: C++17". The problem here is that 
> > > >> on
> > > >> systems that don't have a C++17 compiler, the package won't build -- 
> > > >> even
> > > >> though the package only actually requires a C++11 compiler.
> > > >>
> > > >> How should I deal with this?
> > > >
> > > > Are you allowed to say "C++11 or C++17"?
> > >
> > > Actually I can partially answer this:  the test is not based on
> > > SystemRequirements, but on the log of the build, which now contains
> > > lines like this:
> > >
> > >using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > >using C++ compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > >using C++11
> > >using SDK: ‘MacOSX11.1.sdk’
> > >
> > > I get "using C++11" because of this line in Makevars:
> > >
> > >CXX_STD = CXX11
> > >
> > > So I guess the answer is to change your Makevars to make that line
> > > conditional on running under an old version of R.  If you figure out how
> > > to do that, could you post the recipe here?
> >
> > I believe this is closely related to this email [1]. Dirk and I and
> > Aymeric have been going through the same issue with nloptr as well.
> > Our current opinion is to leave it out, as it would restrict more
> > users to demand C++17, which is unneeded, than to have users with over
> > a decade old compiler which does not have C++11. Dirk and Aymeric,
> > please chime in if I have misstated. Regardless, according to
> > Professor Ripley, if you require specific features, you should mark
> > them in _both_ Makevars and SystemRequirements, which is implied in
> > the "r-devel" version of WRE which adds the words "also" in section
> > 1.2.4.
>
> Could you please point to the specific passage? According to [1],
> section 1.2.4, declaring the C++ standard in SystemRequirements is
> only mandatory for C++17 or later.
>
> [1] 
> https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code
>
> --
> Iñaki Úcar

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

Re: [R-pkg-devel] How to update "SystemRequirements: C++11"?

[Avraham Adler]

On Tue, Feb 7, 2023 at 12:10 AM Iñaki Ucar  wrote:
>
> On Tue, 7 Feb 2023 at 00:09, Avraham Adler  wrote:
> >
> > "If a package does have a src/Makevars[.win] file then also setting
> > the make variable ‘CXX_STD’ there is recommended,"
>
> That doesn't refer to the SystemRequirements field.
>
> Iñaki
>

No, but the prior sentence does. The complete excerpt is:

  ::Packages without a src/Makevars or src/Makefile file may specify a
C++ standard for code in the src directory by including something like
‘C++14’ in the ‘SystemRequirements’ field of the DESCRIPTION file,
e.g.
  SystemRequirements: C++14
 ::If a package does have a src/Makevars[.win] file then also setting
the make variable ‘CXX_STD’ there is recommended, as it allows R CMD
SHLIB to work correctly in the package’s src directory.

So one is supposed to add the requirement to DESCRIPTION via
SystemRequitements. If there is a Makevars, one should ALSO set the
variable in there.

If you wish, I can forward you personal communication with Professor
Ripley from last week where he makes this clear as well.

Thanks,

Avi


> >
> > Avi
> >
> > On Mon, Feb 6, 2023 at 10:58 PM Iñaki Ucar  wrote:
> > >
> > > On Mon, 6 Feb 2023 at 23:27, Avraham Adler  
> > > wrote:
> > > >
> > > > On Mon, Feb 6, 2023 at 9:46 PM Duncan Murdoch 
> > > >  wrote:
> > > > >
> > > > > On 06/02/2023 4:01 p.m., Duncan Murdoch wrote:
> > > > > > On 06/02/2023 3:46 p.m., Winston Chang wrote:
> > > > > >> I recently submitted a package to CRAN with "SystemRequirements: 
> > > > > >> C++11".
> > > > > >> This raises the following NOTE on R-devel, and I was asked to fix 
> > > > > >> and
> > > > > >> resubmit:
> > > > > >>
> > > > > >> * checking C++ specification ... NOTE
> > > > > >> Specified C++11: please update to current default of C++17
> > > > > >>
> > > > > >> If I understand correctly, I have two options, neither of which 
> > > > > >> will work:
> > > > > >> 1. Remove "SystemRequirements: C++11" entirely. The problem with 
> > > > > >> this is
> > > > > >> that on systems with older versions of R (3.6 and below, I 
> > > > > >> believe), it may
> > > > > >> try to compile the package with an older C++ standard, which will 
> > > > > >> fail.
> > > > > >> 2. Update it to "SystemRequirements: C++17". The problem here is 
> > > > > >> that on
> > > > > >> systems that don't have a C++17 compiler, the package won't build 
> > > > > >> -- even
> > > > > >> though the package only actually requires a C++11 compiler.
> > > > > >>
> > > > > >> How should I deal with this?
> > > > > >
> > > > > > Are you allowed to say "C++11 or C++17"?
> > > > >
> > > > > Actually I can partially answer this:  the test is not based on
> > > > > SystemRequirements, but on the log of the build, which now contains
> > > > > lines like this:
> > > > >
> > > > >using C compiler: ‘Apple clang version 12.0.0 (clang-1200.0.32.28)’
> > > > >using C++ compiler: ‘Apple clang version 12.0.0 
> > > > > (clang-1200.0.32.28)’
> > > > >using C++11
> > > > >using SDK: ‘MacOSX11.1.sdk’
> > > > >
> > > > > I get "using C++11" because of this line in Makevars:
> > > > >
> > > > >CXX_STD = CXX11
> > > > >
> > > > > So I guess the answer is to change your Makevars to make that line
> > > > > conditional on running under an old version of R.  If you figure out 
> > > > > how
> > > > > to do that, could you post the recipe here?
> > > >
> > > > I believe this is closely related to this email [1]. Dirk and I and
> > > > Aymeric have been going through the same issue with nloptr as well.
> > > > Our current opinion is to leave it out, as it would restrict more
> > > > users to demand C++17, which is unneeded, than to have users with over
> > > > a decade old compiler which does not have C++11. Dirk and Aymeric,
> > > > please chime in if I have misstated. Regardless, according to
> > > > Professor Ripley, if you require specific features, you should mark
> > > > them in _both_ Makevars and SystemRequirements, which is implied in
> > > > the "r-devel" version of WRE which adds the words "also" in section
> > > > 1.2.4.
> > >
> > > Could you please point to the specific passage? According to [1],
> > > section 1.2.4, declaring the C++ standard in SystemRequirements is
> > > only mandatory for C++17 or later.
> > >
> > > [1] 
> > > https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-C_002b_002b-code
> > >
> > > --
> > > Iñaki Úcar
>
>
>
> --
> Iñaki Úcar

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

Re: [R-pkg-devel] Package PowerSDI NOTES

[Avraham Adler]

Hello, Gabriel. 

CRAN policy is to rarely, if ever, allow long-running examples. It would be 
best if you could give an example of the function which requires as little run 
time as possible. Perhaps pre-compute some stages?

Avi

Sent from my iPhone

> On Jul 18, 2023, at 9:07 PM, Gabriel Constantino Blain 
>  wrote:
> 
> Dears,
> I submitted my R package to CRAN.
> However, it didn't pass the CRAN checks because of 2 notes:
> Note 1:
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
> Check: CRAN incoming feasibility, Result: NOTE
>  Maintainer: 'Gabriel Constantino Blain '
>  New submission
>Possibly misspelled words in DESCRIPTION:
>EP (14:45)
>NASAPOWER (11:18)
>OperatSDI (12:9)
>PowerSDI (7:18, 13:9)
>SPEI (3:31, 7:50, 10:20)
>SPI (3:23, 7:42, 10:12)
>ScientSDI (9:19)
>evapotranspitation (13:44)
>subperiods (15:76)
> Note 2:
> Flavor: r-devel-windows-x86_64
> Check: examples, Result: NOTE
>  Examples with CPU (user + system) or elapsed time > 10s
> user system elapsed
>  ScientSDI 82.71   0.75   88.00
>  Reference 29.75   0.05   29.80
>  Accuracy  10.02   1.11   11.12
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: examples, Result: NOTE
>  Examples with CPU (user + system) or elapsed time > 5s
>  user system elapsed
>  ScientSDI 52.674  0.176  57.765
>  Reference 20.749  0.148  20.898
>  Accuracy   6.001  0.024   6.024
> 
> Regarding note 1, not all the words are misspelled,
> EP, SPI and SPEI are acronyms
> OperatSDI and ScientSDI are functions of my package
> PowerSDI is the name of my package's name
> NASAPOWER is the project's name.
> 
> Regarding note 2, I don't know what's wrong. Is it related to the time to run 
> the examples (>5s)? If is it so, it is not an error. There are so many 
> calculations that it does take some time to do it.
> 
> The package is available at https://github.com/gabrielblain/PowerSDI
> I really appreciate any help you can provide.
> Best regards
> Gabriel
> 
>[[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] status of "possibly invalid URL/403 error" NOTEs?

[Avraham Adler]

I had a similar issue with a paper on JSTOR. Usually CRAN let it through. 
However, I eventually switched from URL to DOI and now the user needs to find 
the free source so to rid myself of the constant hassle. CRAN really doesn’t 
like redirects. I guess you could wrap it in \code{} so as not to hyperlink. 

Avi

Sent from my iPhone

> On Aug 13, 2023, at 3:17 PM, Ben Bolker  wrote:
> 
>   I have a package whose documentation includes the reference 
> \doi{10.1137/18M1186411} which redirects here:
> https://epubs.siam.org/doi/10.1137/18M1186411
> 
> Running R CMD check --as-cran on the package gives
> 
> Found the following (possibly) invalid URLs:
>  URL: https://epubs.siam.org/doi/10.1137/18M1186411
>From: man/llig.Rd
>Status: 403
>Message: Forbidden
> 
>  I can access this perfectly well in the browser.
> 
>  Is there any way to avoid this (other than, say, including the URL in a form 
> that does *not* provide a link so that R CMD check won't try to access it? 
> (As Uwe Ligges says 
> [here](https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005195.html) 
> (for a more obviously problematic case), "mention the URL in plain text but 
> not link"
> 
>  Here Hadley Wickham says that these NOTEs can be ignored
> 
> https://twitter.com/hadleywickham/status/1358170607314235392
> 
> but "Hadley said it on twitter" is not an ideal source. The CRAN repository 
> policy says that packages must pass checks without "significant" notes, but 
> it's always hard to know what's significant and what's not ...
> 
>  There's a thread here: 
> https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005171.html
> 
>   Tangentially: is there a more convenient way to search the r-package-devel 
> archives than googling (e.g.) 
> "site:https://stat.ethz.ch/pipermail/r-package-devel  403" ?
> 
> __
> 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] Re-building vignettes had CPU time 9.2 times elapsed time

[Avraham Adler]

To be fair, data.table defaults to using 1/2 the available cores; they do not 
take the entire machine by default. 

Avi

Sent from my iPhone

> On Aug 25, 2023, at 6:46 PM, Duncan Murdoch  wrote:
> 
> On 25/08/2023 6:13 p.m., Toby Hocking wrote:
>> Thanks Dirk. I agree.
>> data.table is not in a situation to update very soon, so the easiest
>> solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
>> to 2 on the Windows and Debian machines doing this test.
>> Otherwise the 1400+ packages with hard dependencies on data.table will
>> each have to implement custom logic to limit threads to 2.
> 
> That doesn't follow.  data.table could update soon even if that wasn't their 
> intention:  just include bug fixes and set the default OMP_THREAD_LIMIT to 2 
> in data.table.
> 
> The real problem is that there are two stubborn groups opposing each other:  
> the data.table developers and the CRAN maintainers.  The former think users 
> should by default dedicate their whole machine to data.table.  The latter 
> think users should opt in to do that.
> 
> Duncan Murdoch
> 
>> Toby
>>> On Fri, Aug 25, 2023 at 6:46 AM Dirk Eddelbuettel  wrote:
>>> 
>>> 
 On 24 August 2023 at 07:42, Fred Viole wrote:
>>> | Hi, I am receiving a NOTE upon submission regarding the re-building of
>>> | vignettes for CPU time for the Debian check.
>>> |
>>> | I am unable to find any documented instances or solutions to this issue.
>>> | The vignettes currently build in 1m 54.3s locally and in 56s on the Win
>>> | check.
>>> |
>>> | 
>>> https://win-builder.r-project.org/incoming_pretest/NNS_10.1_20230824_132459/Debian/00check.log
>>> 
>>> Please see, inter alia, the long running thread
>>> 
>>>"Trouble with long-running tests on CRAN debian server"
>>> 
>>> started earlier this week (!!) on this list covering exactly this issue.
>>> 
>>> We can only hope CRAN comes to understand our point that _it_ should set a
>>> clearly-identifable variable (the OpenMP thread count would do) so that
>>> package data.table can this for its several hundred users.
>>> 
>>> As things currently stand, CRAN expects several hundred packages (such as
>>> your, guessing there this comes from data.table which I do not know for sure
>>> but you do import it) to make the change which is pretty close to the text
>>> book definition of madness.
>>> 
>>> Also see https://github.com/Rdatatable/data.table/issues/5658 with by now 24
>>> comments.  It is on the same issue.
>>> 
>>> Uwe, Kurt: Please please please set OMP_THREAD_LIMIT to 2 on the Windows and
>>> Debian machines doing this test.
>>> 
>>> Dirk
>>> 
>>> --
>>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>> 
>>> __
>>> 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-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] Modernizing legacy Fortran:, REAL(kind=8)

[Avraham Adler]

I’ve had no issues using the iso_c_binding schema. 

Avi

Sent from my iPhone

> On Aug 30, 2023, at 2:43 AM, Thomas Petzoldt  
> wrote:
> 
> Hi,
> 
> some package maintainers including me got a reminder from Prof. Brian Ripley 
> to modernize REAL and INTEGER declarations using the KIND option:
> 
>> On 29.08.2023 at 19:31 Prof Brian Ripley wrote:
>> According to the Fortran standards, numerical values are just an 
>> enumeration, and what e.g. real(kind=4) means (or even if it is accepted) is 
>> implementation dependent.
>> We see such constructs in packages
> 
> [... line with packages deleted to avoid exposing the other packages and 
> authors]
> 
>> Please change them to something portable (kind(1.0) or kind(1.0d0} are 
>> commonly used, as is c_double from iso_c_binding).
>> Before 2023-09-26 to safely retain your package on CRAN (some of you have 
>> earlier deadlines for other issues).
> 
> We use a lot of legacy code that though partly modernized due to similar 
> requests, still uses a mix of DOUBLE PRECISION and a few REAL(KIND=8) and 
> COMPLEX(KIND=8). As the code will still remain legacy style with respect to 
> some other constructs, I wonder what to use to go a step forward, but remain 
> as consistent as possible, which is of course a compromise. I see the 
> following options:
> 
> a) change REAL(kind=8) back to DOUBLE PRECISION that is again old style. It 
> seems to be portable and is still widely used.
> 
> b) just formally change the few occurrences to:REAL(kind=0.0d) as suggested. 
> It is easy, but inconsistency remains.
> 
> c) or, define "dp" as recommended in modern style guides and use it instead 
> of REAL(kind=8) and the future also for DOUBLE PRECISION this way:
> 
> integer,parameter::dp=kind(0.0d0)
> 
> and then
> 
> real(dp)::a,b,c
> 
> However, this would need changes at many places, the mix between old and new 
> constructswill generally get worse.
> 
> Another question is, that with either of these, we may not be sure to use 8 
> byte double. Changing this could influence for precision and pointer 
> arithmetics.
> 
> Any recommendations? Thanks a lot!
> 
> Thomas
> 
> __
> 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] Modernizing legacy Fortran:, REAL(kind=8)

[Avraham Adler]

Hi, Thomas.

Since all the Fortran code must talk to R through SEXP's written in C,
wouldn't it make sense to use " C_DOUBLE_COMPLEX" and " C_DOUBLE" to ensure
maximum compatibility?

Thanks,

Avi

On Thu, Aug 31, 2023 at 9:42 AM Thomas Petzoldt <
thomas.petzo...@tu-dresden.de> wrote:

> On 30.08.2023 at 11:58 Ivan Krylov wrote:
> > On Wed, 30 Aug 2023 08:43:04 +0200
> > Thomas Petzoldt  wrote:
> >
> >> a) change REAL(kind=8) back to DOUBLE PRECISION that is again old
> >> style. It seems to be portable and is still widely used.
> >
> > I don't have a reference as good as the Fortran standard, but Steve
> > Lionel said in Dr. Fortran [*] that DOUBLE PRECISION is still part of
> > the standard fixed-form syntax.
> >
> >>   COMPLEX(KIND=8)
> >
> > This could be particularly problematic if you're trying to interoperate
> > with C, but will probably not surface unless you use LTO:
> > https://bugs.r-project.org/show_bug.cgi?id=18430
> >
> > Unfortunately, there's no standard DOUBLE COMPLEX.
> >
>
> Thank you, this helps. I had a look in Dr. Fortran myself and some other
> sites, but especially the COMPLEX definitions remain unclear.
>
> I tried now the following, because the included original Fortran codes
> follow slightly different standards:
>
> - replace COMPLEX(KIND=8) with DOUBLE COMPLEX in source files that use
> DOUBLE PRECISION otherwise
>
> - replace real(kind=8) with real(kind=kind(0.0d0)) in the more modern
> source files
>
> This is pragmatic and may not be the best way, but looks mostly
> consistent. Now I checked the package and everything was ok, but I was
> not able reproduce the warnings from the previous version.
>
> I assume that I have to set an environment variable to see the warnings,
> but which one?
>
> I use gfortran/gcc 13.2.1-1 on Fedora 38.
>
> Thanks!
>
> Thomas
>
> --
> https://tu-dresden.de/Members/thomas.petzoldt
> __
> 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] Spelling of PDB in Package Description

[Avraham Adler]

Regarding PDB, in Rd format it’s best to wrap that in an \acronym{} tag. See 
section 2.3 of https://cran.r-project.org/doc/manuals/R-exts.html#Marking-text

Avi

Sent from my iPhone

> On Sep 14, 2023, at 3:40 PM, Leonard Mada via R-package-devel 
>  wrote:
> 
> Dear List Members,
> 
> After resubmitting the updated version of the Rpdb package (2.3.1), the 
> following Notes were generated:
> 
> 1.) Spelling PDB
> https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Windows/00check.log
> https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Debian/00check.log
> 
> The PDB stands for Protein Data Bank:
> http://www.wwpdb.org/documentation/file-format-content/format33/v3.3.html
> 
> It should be the correct spelling (and was the same in the previous versions 
> of the package).
> 
> 2.)  Small Sample PDB Files
> * checking for non-standard things in the check directory ...
> NOTE Found the following files/directories: ‘Rpdb.pdb’
> 
> There is a directory with 3 very small sample pdb-files. The directory was 
> also present in the previous version.
> 
> How should I proceed? Or did I miss something?
> 
> 
> Sincerely,
> 
> 
> Leonard
> 
> __
> 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] What happened to mlr3proba on CRAN?

[Avraham Adler]

https://cran-archive.r-project.org/web/checks/2022/2022-05-16_check_results_mlr3proba.html

On Mon, Oct 9, 2023 at 12:37 AM Dr. Franz Király 
wrote:

> Dear all,
>
> can someone explain to me what exactly happened to mlr3proba on CRAN?
> https://cran.r-project.org/web/packages/mlr3proba/index.html
>
> Thanks
> Franz
>
>
> [[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

[R-pkg-devel] Unable to access log operator in C

[Avraham Adler]

I am hoping the solution to this question is simple, but I have not
been able to find one. I am building a routine in C to be called from
R. I am including Rmath.h. However, when I have a call to "log", I get
the error "called object 'log' is not a function or a function
pointer. When I "trick" it by calling log1p(x - 1), which I *know* is
exported from Rmath.h, it works.

More completely, my includes are:
#include 
#include 
#include 
#include 
#include  // for NULL
#include 

The object being logged is a double, passed into C as an SEXP, call it
"a", which for now will always be a singleton. I initialize a pointer
double *pa = REAL(a). I eventually call log(pa[0]), which does not
compile and throws the error listed above. Switching the call to
log1p(pa[0] - 1.0) works and returns the proper answer.

Even including math.h explicitly does not help, which makes sense as
it is included by Rmath.h.

Thank you,

Avi

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

Re: [R-pkg-devel] Unable to access log operator in C

[Avraham Adler]

Thank you, Dirk.

However, I am an absolute clod.I just realized; I was passing in the
SEXP indicating whether or not to log the function as "log", so I
"overwrote" the symbol.

Excuse me while I go bang my head into the wall a few dozen times.

My apologies,

Avi

On Wed, Feb 28, 2024 at 7:14 PM Dirk Eddelbuettel  wrote:
>
>
> On 28 February 2024 at 19:05, Avraham Adler wrote:
> | I am hoping the solution to this question is simple, but I have not
> | been able to find one. I am building a routine in C to be called from
> | R. I am including Rmath.h. However, when I have a call to "log", I get
> | the error "called object 'log' is not a function or a function
> | pointer. When I "trick" it by calling log1p(x - 1), which I *know* is
> | exported from Rmath.h, it works.
> |
> | More completely, my includes are:
> | #include 
> | #include 
> | #include 
> | #include 
> | #include  // for NULL
> | #include 
> |
> | The object being logged is a double, passed into C as an SEXP, call it
> | "a", which for now will always be a singleton. I initialize a pointer
> | double *pa = REAL(a). I eventually call log(pa[0]), which does not
> | compile and throws the error listed above. Switching the call to
> | log1p(pa[0] - 1.0) works and returns the proper answer.
> |
> | Even including math.h explicitly does not help, which makes sense as
> | it is included by Rmath.h.
>
> Can you show the actual line?  Worst case rename your source file to end in
> .cpp, include  and call std::log.
>
>   > Rcpp::cppFunction("double mylog(double x) { return std::log(x); }")
>   > mylog(exp(42))
>   [1] 42
>   >
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] Check results on r-devel-windows claiming error but tests seem to pass?

[Avraham Adler]

I noticed that a few of my packages appear to be failing on
"r-devel-windows-x86_64". Specficially, Delaporte [1], lamW [2], and
revss[3]. However, checking the output of the tests shows that all
passed. Is this a hiccup or is there something that needs to be
changed? And why would my other two packages not suffer from this
(minimaApprox [4] and Pade [5])? I'm a bit confused.

Thank you,

Avi

[1] https://cran.r-project.org/web/checks/check_results_Delaporte.html
[2] https://cran.r-project.org/web/checks/check_results_lamW.html
[3] https://cran.r-project.org/web/checks/check_results_revss.html
[4] https://cran.r-project.org/web/checks/check_results_minimaxApprox.html
[5] https://cran.r-project.org/web/checks/check_results_Pade.html

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

Re: [R-pkg-devel] package removed from CRAN

[Avraham Adler]

According to the CRAN links
,
your package had an error on r-devel-windows-x86_64 and
r-patched-linux-x86_64 which was not addressed. Specifically, some
examples failed. See

for more specific details. Usually, fixing the problem and
incrementing the version is enough to resubmit it to CRAN.

Thanks,

Avi

On Wed, May 8, 2024 at 11:33 AM Jose V. Die Ramon  wrote:
>
> Hello,
>
> I just discovered that my package 'refseqR' was removed from the CRAN 
> repository on April 30th.
> https://cran.r-project.org/web/packages/refseqR/index.html
>
> This news is extremely upsetting, especially because I did not receive any 
> communication or warning regarding the issue. Could anyone please help me 
> understand the reasons behind this, or suggest any steps I should take to 
> resolve it?
>
> Thanks,
> Jose
> __
> 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] SIAM Wilkinson prize

[Avraham Adler]

Seems as if it is restricted to people with PhDs.

Avi

On Fri, May 18, 2018 at 1:13 PM J C Nash  wrote:

> It occurs to me that there could be packages developed by early career R
> developers that might fit
> this prize which is considered quite prestigious (not to mention the cash)
> in the numerical methods community.
> It is also likely that people may not be aware of the award in the R
> community.
>
> Cheers, JN
>
>
>
>  Forwarded Message 
> Subject:[SIAM-OPT] June 1 Entry Deadline - James H. Wilkinson
> Prize for Numerical Software
> Date:   Thu, 17 May 2018 14:22:41 +
> From:   SIAM Prize Program 
> CC: Optimization SIAG mailing list 
>
>
>
> James H. Wilkinson Prize for Numerical Software
>
> *cid:image001.png@01D29F3D.6ECC9B50* <
> https://siam2019.secure-platform.com/a/solicitations/home/5>
>
> The deadline is June 1 for entries for the James H. Wilkinson Prize for
> Numerical Software
> . We are
> looking for submissions of high-quality numerical
> software from early career teams. If you or your team are developing
> numerical software for scientific computing, act as
> a nominator and enter your software for the prize. To submit an entry, you
> first need to create an account at the SIAM
> Prize Portal. Click on the “Submit” button above to start the process.
>
> The James H. Wilkinson Prize for Numerical Software is awarded every four
> years to the authors of an outstanding piece
> of numerical software. The prize is awarded for an entry that best
> addresses all phases of the preparation of
> high-quality numerical software. It is intended to recognize innovative
> software in scientific computing and to
> encourage researchers in the earlier stages of their career.
>
> SIAM will award the Wilkinson Prize for Numerical Software at the SIAM
> Conference on Computational Science and
> Engineering (CSE19). The award will consist of $3,000 and a plaque. As
> part of the award, the recipient(s) will be
> expected to present a lecture at the conference.
>
>
>
>
> 
>
> *Eligibility Criteria:*
>
> Selection will be based on: clarity of the software implementation and
> documentation, importance of the application(s)
> addressed by the software; portability, reliability, efficiency, and
> usability of the software implementation; clarity
> and depth of analysis of the algorithms and the software in the
> accompanying paper; and quality of the test software.
>
> Candidates must have worked in mathematics or science for at most 12 years
> (full time equivalent) after receiving their
> PhD as of January 1 of the award year, allowing for breaks in continuity.
> The prize committee can make exceptions, if in
> their opinion the candidate is at an equivalent stage in their career.
>
> For the 2019 award, a candidate must have received their PhD no earlier
> than January 1, 2007.
>
>
> 
>
> *Entry Deadline:*
>
> *June 1, 2018*
>
>
> 
>
> *Required Materials:*
>
> · CVs of the authors of the software, at most two pages per author
> (PDF)
>
> · A two-page summary of the main features of the algorithm and
> software implementation (PDF)
>
> · A paper describing the algorithm and the software implementation
> (PDF)
>
> · Open source software written in a widely available high-level
> programming language. The software should be
> submitted in a gzipped .tar archive with a README file describing the
> contents of the archive. Each submission should
> include documentation, examples of the use of the software, a test
> program, and scripts for executing the test programs.
>
>
> 
>
>
>
> *Previous recipients:*
>
>
>
> Previous recipients of the James H. Wilkinson Prize for Numerical Software
> are:
>
>
>
> *2015*Patrick Farrell, Simon Funke, David Ham, and Marie Rognes for
> dolfin-adjoint
> *2011 *Andreas Waechter and Carl Laird for IPOPT
>
> *2007 *Wolfgang Bangerth, Guido Kanschat, and Ralf Hartmann for deal.II
>
> *2003 *Jonathan Shewchuk for Triangle
>
> *1999 *Matteo Frigo and Steven Johnson for FFTW
> *1995 *Chris Bischof and Alan Carle for ADIFOR 2.0
> *1991 *Linda Petzold for DASSL
>
>
>
>
> 
>
> *Selection Committee:*
>
> Jorge Moré (Chair), Argonne National Laboratory
> Sven Hammarling, Numerical Algorithms Group Ltd and University of
> Manchester
> Michael Heroux, Sandia National Laborato

Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

Try following the directions here. They have worked for me for years.
Please see the comments too.

https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

Hope that helps,

Avi

On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
wrote:

> Hello!
>
> I'm building a package that needs Openblas for matrix manipulation speed
> up.
>
> I built Openblas on Windows 10.  I updated the MkRules.local,
> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>
> However, when I run "make recommended", I have trouble with the Matrix
> package build.  The components of the Cholesky all appear as unreferenced.
>
> Has anyone else run into this, please?  I'm working with R-3.5.1 source.
>
> Thanks,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS
recently. Does it work if you use the vanilla BLAS?

Avi

On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess 
wrote:

> Hi again!
>
> I checked everything, did "make distribution" and the same thing occurred.
>
>
> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a
> SuiteSparse_config.o
> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file
> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll tmp.def
> CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o
> cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o dpoMatrix.o
> dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o dtTMatrix.o
> dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o sparseQR.o
> abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack -LD:/erinm/R-3.5.1/bin/x64
> -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 -LD:/erinm/R-3.5.1/extsoft/lib
> -LD:/erinm/R-3.5.1/bin/x64 -lR
> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to
> `cholmod_change_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to
> `cholmod_factor_to_sparse'
> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to
> `cholmod_free_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to
> `cholmod_solve'
> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to
> `cholmod_updown'
> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to
> `cholmod_spsolve'
> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to
> `cholmod_factorize_p'
> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to
> `cholmod_change_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to
> `cholmod_copy_factor'
> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to
> `cholmod_free_factor'
> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to
> `cholmod_sparse_to_dense'
> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye'
> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add'
> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to
> `cholmod_free_sparse'
> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to
> `cholmod_copy_sparse'
> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to
> `cholmod_free_sparse'
> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy'
>
> Does this look familiar, please?
>
> Thanks,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler 
> wrote:
>
>> Try following the directions here. They have worked for me for years.
>> Please see the comments too.
>>
>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>>
>> Hope that helps,
>>
>> Avi
>>
>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
>> wrote:
>>
>>> Hello!
>>>
>>> I'm building a package that needs Openblas for matrix manipulation speed
>>> up.
>>>
>>> I built Openblas on Windows 10.  I updated the MkRules.local,
>>> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>>>
>>> However, when I run "make recommended", I have trouble with the Matrix
>>> package build.  The components of the Cholesky all appear as
>>> unreferenced.
>>>
>>> Has anyone else run into this, please?  I'm working with R-3.5.1 source.
>>>
>>> Thanks,
>>> Erin
>>>
>>> Erin Hodgess, PhD
>>> mailto: erinm.hodg...@gmail.com
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[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] Trying to compile R-3.5.1 with openblas for windows

[Avraham Adler]

Fantastic!

Avi

On Sat, Sep 15, 2018 at 7:26 PM Erin Hodgess 
wrote:

> Finally got Openblas installed!  The speed up is amazing!  Thanks for your
> help and patience.
>
> Sincerely,
> Erin
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler 
> wrote:
>
>> No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS
>> recently. Does it work if you use the vanilla BLAS?
>>
>> Avi
>>
>> On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess 
>> wrote:
>>
>>> Hi again!
>>>
>>> I checked everything, did "make distribution" and the same thing
>>> occurred.
>>>
>>>
>>> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a
>>> SuiteSparse_config.o
>>> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file
>>> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll
>>> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o
>>> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o
>>> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o
>>> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o
>>> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack
>>> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64
>>> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR
>>> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to
>>> `cholmod_change_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to
>>> `cholmod_factor_to_sparse'
>>> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to
>>> `cholmod_free_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to
>>> `cholmod_solve'
>>> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to
>>> `cholmod_updown'
>>> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to
>>> `cholmod_spsolve'
>>> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to
>>> `cholmod_factorize_p'
>>> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to
>>> `cholmod_change_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to
>>> `cholmod_copy_factor'
>>> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to
>>> `cholmod_free_factor'
>>> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to
>>> `cholmod_sparse_to_dense'
>>> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye'
>>> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add'
>>> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to
>>> `cholmod_free_sparse'
>>> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to
>>> `cholmod_copy_sparse'
>>> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to
>>> `cholmod_free_sparse'
>>> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy'
>>>
>>> Does this look familiar, please?
>>>
>>> Thanks,
>>> Erin
>>>
>>> Erin Hodgess, PhD
>>> mailto: erinm.hodg...@gmail.com
>>>
>>>
>>> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler 
>>> wrote:
>>>
>>>> Try following the directions here. They have worked for me for years.
>>>> Please see the comments too.
>>>>
>>>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>>>>
>>>> Hope that helps,
>>>>
>>>> Avi
>>>>
>>>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess 
>>>> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> I'm building a package that needs Openblas for matrix manipulation
>>>>> speed up.
>>>>>
>>>>> I built Openblas on Windows 10.  I updated the MkRules.local,
>>>>> src/extra/blas/Makefile.win, etc.  Things are working with "make all".
>>>>>
>>>>> However, when I run "make recommended", I have trouble with the Matrix
>>>>> package build.  The components of the Cholesky all appear as
>>>>> unreferenced.
>>>>>
>>>>> Has anyone else run into this, please?  I'm working with R-3.5.1
>>>>> source.
>>>>>
>>>>> Thanks,
>>>>> Erin
>>>>>
>>>>> Erin Hodgess, PhD
>>>>> mailto: erinm.hodg...@gmail.com
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>> __
>>>>> R-package-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>
>>>> --
>>>> Sent from Gmail Mobile
>>>>
>>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[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] avoiding .mod files

[Avraham Adler]

On Tue, Nov 20, 2018 at 4:45 AM Rampal Etienne  wrote:
>
> Dear Thomas,
>
> My FORTRAN code to be used with deSolve contains a module dimmod. During
> build a file called dimmod.mod is created in the src directory. I can
> avoid this by including it in the .RBuildignore file, but when I submit
> the package to CRAN, the package is rejected because it keeps creating
> the dimmod.mod file. How do I solve this?
>
> Kind regards,
>
> Rampal Etienne

Hello, Rampal.

I use Fortran modules with my Delaporte package [1]. I clean them by
having a clean (actually two clean) routines in Makvars [2]. Perhaps
something like that would work for you.

Good Luck,

Avi

[1] https://CRAN.R-project.org/package=Delaporte
[2] https://bitbucket.org/aadler/delaporte/src/master/src/Makevars

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

[R-pkg-devel] Best practices for R package requiring Fortran 2003

[Avraham Adler]

Following the news, I've been trying to clean up my package which uses
Fortran in preparation for the changes that appear to be coming in
R-devel. The package has implicitly been relying on Fortran 2003,
since it uses iso_c_binding. In practice, is it proper that
"-std=f2003" be explicitly added to PKG_FCFLAGS (or possibPKG_FFLAGS
in 3.6.0)? Should "Fortran 2003" be listed in SystemRequirements? It
currently passes CRAN checks, but that's because all the Fortran
compilers in use have the iso_c_bindings implemented (GCC 4.5 already
had it, and it's clearly in Oracle Developer Studio 12.5).

Thank you,

Avi

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

Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?

[Avraham Adler]

If you want to use .NOTPARRALLEL, that’s considered non-portable as it’s
GNU-make specific, (I got an email from Dr. Ripley this week) so you have
to add Gnu Make to the system requirements in the DESCRIPTION or find the
right sequence of targets to ensure order is maintained even in parallel
make.

Avi

On Mon, Jan 14, 2019 at 1:29 PM Paul Gilbert  wrote:

> (I didn't see an answer to this, so ...)
>
> I think using .NOTPARALLEL will usually get rid of the error but, in my
> experience, this problem is usually caused by an incorrect or incomplete
> Makefile. When not done in parallel this missing target is usually
> getting done first as a side-affect of something that happens before and
> usually finishes before it is needed. Your luck does not hold in
> parallel. The better fix is to correct your Makefile.
>
> Paul
>
> On 1/10/19 4:54 PM, Satyaprakash Nayak wrote:
> > Dear R package developers
> >
> > I published a package on CRAN last year (sundialr) which is now failing
> > with as it is not make to compile a static library with parallel make.
> >
> > In this package, I compile a static library (libsundials_all.a) from
> source
> > files of a third party. The specifics of compiling the static library can
> > be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars
> >
> > Now, I got the following error message from CRAN (actually, I was
> informed
> > of this before, but had neglected to fix it). Here is the message from
> one
> > of the CRAN maintainers ..
> >
> >
> ***
> > This have just failed to install for me with a parallel make:
> >
> > g++ -std=gnu++98 -std=gnu++98 -shared
> > -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so
> > cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack
> > -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm
> > -lquadmath -L../inst/ ../inst/libsundials_all.a
> > g++: error: ../inst/libsundials_all.a: No such file or directory
> > make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6:
> > sundialr.so] Error 1
> >
> *
> >
> > It seems the package fails to generate the static library with the
> parallel
> > make. The easiest solution I could think of for this problem was to
> force a
> > serial version of make using the .NOTPARALLEL phony command in Makevars
> and
> > Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars).
> I
> > have made this change and it seems to work on my machine and on testing
> > with TravisCI and Appveyor(https://github.com/sn248/sundialr).
> >
> > However, before I re-submit to CRAN, I wanted to get an opinion as to
> will
> > this be enough to get rid of the error with parallel make?
> >
> > Any suggestions would be very much appreciated, thank you!
> > Satyaprakash
> >
> >   [[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
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] OpenMP & Fortran: Seemingly contradictory responses from CRAN

[Avraham Adler]

Hello.

I am at my wits end as to how to comply with CRAN regarding my
Delaporte package which uses Fortran and OpenMP [1].

Recently, it was announced [2] that going forward, OpenMP should be
linked with SHLIB_OPENMP_CFLAGS.

Moreover, I received an email from Professor Ripley, stating:

---START Prof. Ripley--
There are two issues

- Linking in R-devel is done by C or C++ even for F95 code, so PKG_LIBS
needs to contain the appropriate macro, SHLIB_OPENMP_CFLAGS for all
these packages.

- SHLIB_OPENMP_FFLAGS is preferred to SHLIB_OPENMP_FCFLAGS

There are two possibilities to correct this:

A) Make a version of the package depending on R(>=3.6.0) and submit
stating it is intended for the 3.6.0/Others area.

B) With both points changed the package should still work under R 3.5.x
as for current platforms SHLIB_OPENMP_FFLAGS, SHLIB_OPENMP_FCFLAGS and
SHLIB_OPENMP_CFLAGS have the same value.  So it could be submitted for
the main CRAN area.
---STOP Prof. Riple--

My first attempt had the following Makevars submitted the to CRAN:

PKG_FFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

Granted, this would not have had OpenMP for other reasons (FFLAGS will
only be recognized for free-form Fortran in R 3.6+) but the submission
was denied with the following note:

-START CRAN-

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: incorrect macro SHLIB_OPENMP_CFLAGS included in PKG_FFLAGS
src/Makevars: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not
in PKG_CFLAGS
-STOP CRAN-

Uwe Ligges was kind enough to clarify:

-START Prof. Ligges-
Sun, Jan 13, 12:16 PM (8 days ago)

to me, CRAN-submissions
Pls re-read Brian's comment and note that we already check with R-devel.
He daid:

" PKG_LIBS needs to contain the appropriate macro, SHLIB_OPENMP_CFLAGS "

but you have it in PKG_FFLAGS now?
(first) and then
" SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not in PKG_CFLAGS", si
please declare it there, too.
-STOP Prof. Ligges-

So, I declared CFLAGS too. However, When I passed (substituting
FCFLAGS so that OpenMP will work in R-release):

PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_FCFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

I got:

-START CRAN-
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: incorrect macro SHLIB_OPENMP_CFLAGS included in PKG_FCFLAGS
-STOP CRAN-

If I give up and focus just on R-release by passing:

PKG_FCFLAGS = $(SHLIB_OPENMP_FCFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_FCFLAGS)

I get:

-START CRAN-
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: use of SHLIB_OPENMP_*FLAGS in Makefiles, Result: NOTE
src/Makevars: SHLIB_OPENMP_FFLAGS is preferred to
SHLIB_OPENMP_FCFLAGS in PKG_FCFLAGS
src/Makevars: SHLIB_OPENMP_FCFLAGS is included in PKG_FCFLAGS but
not SHLIB_OPENMP_CFLAGS in PKG_LIBS
src/Makevars: SHLIB_OPENMP_FCFLAGS is included in PKG_LIBS but
linking is by C
-STOP CRAN-

If I really give up and pass Depend: R <= 3.5.2 in the DESCRIPTION,
*noting in the comments that I will submit a new R 3.6+ only version
when it is released* I still get a failure:

-START CRAN-
Flavor: r-devel-windows-ix86+x86_64
Check: whether package can be installed, Result: ERROR
  Installation failed.
  See 'd:/RCompile/CRANincoming/R-devel/Delaporte.Rcheck/00install.out'
for details.

Flavor: r-devel-linux-x86_64-debian-gcc
Check: whether package can be installed, Result: ERROR
  Installation failed.
  See '/srv/hornik/tmp/CRAN/Delaporte.Rcheck/00install.out' for details

-STOP CRAN-

Which actually was the point, to be honest. It wasn't supposed to pass R-devel.

I cannot pass JUST:

PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)

AS OpenMP would not be compiled into the Fortran.

I really would like to have oe version of the package that is CRAN
compliant, but at this point, I cannot see how to do that based on the
various rejection messages I got. Maybe I'm missing something simple,
in which case, please explain. Any guidance would be much appreciated.

Thank you,

Avi

[1] https://cran.r-project.org/package=Delaporte
[2] 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2018/12/04#n2018-12-04

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

Re: [R-pkg-devel] registering native routines

[Avraham Adler]

https://stat.ethz.ch/pipermail/r-devel/2017-February/073755.html

On Sat, Feb 16, 2019 at 3:22 PM Charles Geyer  wrote:
>
> I just noticed that R package foo in the github repo
> https://github.com/cjgeyer/foo no longer passes R CMD check --as-cran.  The
> problem seems to be that it does not register native routines and thus the
> C routines cannot be found.  It does pass R CMD check (without --as-cran).
> The version of the package that does register native routines (package
> fooRegister) in the same repo passes with or without --as-cran.  So did I
> miss the announcement?  Is registration of native routines now mandatory
> for CRAN?
>
> Just asking because I am currently teaching about R packages in PhD level
> statistical confusing and don't want to provide erroneous info.
>
> These packages are toy packages to introduce the class to R packages.  I
> don't actually want to put them on CRAN.
>
> --
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
>
> [[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] .Fortran opinion

[Avraham Adler]

If you read further in Drew's posts (which I highly recommend) he says
that C++/Rcpp isn't the best for wrapping Fortran calls, and that it
is faster and cleaner to use C. I have a relatively detailed blog post
on building packages with Fortran (or raw C) code; I hope you may find
it useful in your case [1].

Thanks,

Avi

[1] 
https://www.avrahamadler.com/2018/12/09/the-need-for-speed-part-1-building-an-r-package-with-fortran/

On Sun, May 26, 2019 at 3:22 PM Neal Fultz  wrote:
>
> I think the current best practice is to wrap the Fortran code in a C
> helper, and invoke that using .Call - more information on that is available
> in Hadley's book - http://adv-r.had.co.nz/C-interface.html
>
> It shouldn't be too much work, maybe another 10-20 lines of code, most of
> which could probably autogenerated using Rcpp if you wanted to take that
> route.
>
> On Sun, May 26, 2019 at 6:31 AM Berry Boessenkool <
> berryboessenk...@hotmail.com> wrote:
>
> >
> > Recently, users of my package rdwd have provided Fortran code for a nice
> > extension of the package.
> > According to the following site, calling .Fortran() is no longer
> > recommended:
> > https://github.com/wrathematics/Romp/blob/master/README.md#fortran
> >
> > Since this is my first time using native code, I'd highly appreciate any
> > thoughts on the following question:
> > How much additional work should I put into avoiding .Fortran() for
> > long-term CRAN suitability?
> >
> > Thanks ahead,
> > Berry
> >
> > PS: In case you want a look at the (two very short) Fortran routines:
> > https://github.com/brry/rdwd/tree/master/src
> > and their call in R:
> > https://github.com/brry/rdwd/blob/master/R/readRadarFile.R#L119
> >
> >
> > [[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

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

Re: [R-pkg-devel] Using FORTRAN libraries and compiler options

[Avraham Adler]

If I’m not mistaken, dgemm is a BLAS call. That should be accessible from
Fortran via an external call. I think the mvtnorm package calls BLAS/LAPACK
from Fortran if that helps.

Avi

On Mon, Nov 11, 2019 at 6:40 AM Rampal S. Etienne 
wrote:

> Hello,
>
> I am using FORTRAN code with the deSolve package. However, the code
> still runs slowly. Googling tells me that there are two options to speed
> up my code:
>
> 1. Compile with option -O3
>
> 2. Use the library dgemm.
>
> I understand that this can be set in makevars. However, as I have
> limited experience with FORTRAN (never loaded libraries or set compiling
> options), I was wondering whether anyone can give me a hint on how to
> set this. I have just a single FORTRAN file (with multiple subroutines).
>
> Cheers, Rampal
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] For reproducibility issue

[Avraham Adler]

Hi.

If it helps, I call the R RNG from Fortran in my Delaporte package
[1], also using iso_c_bindings. Specifically, I have the following C
code [2]:

void F77_SUB(unifrnd) (int *n, double *x){
GetRNGstate();
for (int i = 0; i < *n; ++i){
*(x + i) = unif_rand();
}
PutRNGstate();
}
and call it in Fortran like so [3]:

subroutine rdelap_f(n, a, na, b, nb, l, nl, vars) bind(C, name="rdelap_f_")

external unifrnd

integer(kind = c_int), intent(in), value :: n, na, nb, nl
real(kind = c_double), intent(out), dimension(n) :: vars
real(kind = c_double), intent(in) :: a(na), b(nb), l(nl)
real(kind = c_double), dimension(n) :: p
integer(kind = c_int) :: lg, lt

call unifrnd(n, p)
lt = 1_c_int
lg = 0_c_int
call qdelap_f(p, n, a, na, b, nb, l, nl, lt, lg, vars)

end subroutine rdelap_f

The package passes CRAN tests (at least as of now) on anything between
GCC 4 and GCC9 [4].

Hope that helps,

Avi

[1] https://bitbucket.org/aadler/delaporte/src/master/
[2] https://bitbucket.org/aadler/delaporte/src/master/src/utils_and_wrappers.c
[3] https://bitbucket.org/aadler/delaporte/src/master/src/delaporte.f95
[4] https://cran.r-project.org/web/checks/check_results_Delaporte.html


On Fri, Jan 17, 2020 at 2:39 PM Ivan Krylov  wrote:
>
> On Fri, 17 Jan 2020 13:55:39 +
> وليد خلف معوض المطيرى  wrote:
>
> > So, does anyone have an idea of how to solve this issue.
>
> "Writing R Extensions", 1.6. Writing portable packages:
>
> >> Compiled code should not call the system random number generators
> >> such as rand, drand48 and random, but rather use the interfaces to
> >> R’s RNGs described in Random numbers. In particular, if more than
> >> one package initializes the system RNG (e.g. via srand), they will
> >> interfere with each other.
>
> >> Nor should the C++11 random number library be used, nor any other
> >> third-party random number generators such as those in GSL.
>
> It somewhat less convenient to call the R random number generator from
> Fortran than it would be from C or C++, but still possible. There is a
> F77-style example of such use [1], but since you are already using
> iso_c_binding, you should be able to declare the C API [2] right in the
> Fortran source:
>
> subroutine GetRNGState() bind(c)
> end subroutine
>
> subroutine PutRNGstate() bind(c)
> end subroutine
>
> As a bonus, you get to use the R distribution functions [3], without
> the need to implement them yourself from uniformly distributed samples:
>
> function rnorm(mu, sigma) bind(c) result(ret)
>  use intrinsic, iso_c_binding, only: c_double
>  real(c_double), value :: mu, sigma
>  real(c_double) ret
> end function
>
> function rgamma(shape, scale) bind(c) result(ret)
>  use intrinsic, iso_c_binding, only: c_double
>  real(c_double), value :: shape, scale
>  real(c_double) ret
> end function
>
> (The prototypes above are unchecked; I haven't written any Fortran 2003
> in more than a year.)
>
> --
> Best regards,
> Ivan
>
> [1]:
> https://cran.r-project.org/doc/manuals/R-exts.html#index-Random-numbers-in-Fortran
>
> [2]: https://cran.r-project.org/doc/manuals/R-exts.html#Random-numbers
>
> [3]:
> https://cran.r-project.org/doc/manuals/R-exts.html#Distribution-functions
>
> __
> 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] For reproducibility issue

[Avraham Adler]

If I understand what you're doing, your Fortran seed knows nothing
about the R state. Is it possible to switch to using the R random
number generators? Or can you at least use the probability integral
transform to generate uniform [0, 1] via R and then convert those to
observations in Fortran (that's what I did)?

Avi

‪On Fri, Jan 17, 2020 at 7:10 PM ‫وليد خلف معوض المطيرى‬‎
 wrote:‬
>
> Hi all,
>
>
>
> I think what I’ve done is something different. Inside the Fortran subroutine, 
> I have a subroutine for setting the seed value of the RNG of GNU Fortran 
> which I think it is not related to the R RNG like the one below:
>
>
>
> subroutine initrandomseedsinr(temp)
>
> implicit none
>
> integer :: n
>
> integer, intent(in):: temp
>
> integer, dimension(:), allocatable :: seed
>
>
>
> call random_seed(size = n)
>
> allocate(seed(n))
>
> seed = temp
>
> call random_seed(PUT = seed)
>
> deallocate(seed)
>
>
>
> end subroutine initrandomseedsinr
>
> , where temp is an argument of the Fortran subroutine as well as in the 
> wrapper R function. This will be related to the RNG method used in the GNU 
> Fortran that build on GCC not to the R. I am not sure if I am right on this, 
> but tried with using RNGkind(sample.kind = "Rounding") and it doesn’t help. 
> The difference in the results were not major. The output at the end of 
> running the functions kept having very similar results, but still have the 
> issue of reproducing exact results which I need it for relating work that is 
> based on the package.
>
>
>
> Many thanks,
>
>
>
> Waleed
>
>
>
>
>
>
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Avraham Adler
> Sent: ‏Friday,‏ ‏January ‏17,‏ ‏2020 ‏06:30 ‏م
> To: Ivan Krylov
> Cc: وليد خلف معوض المطيرى; R Package Development
> Subject: Re: [R-pkg-devel] For reproducibility issue
>
>
>
> Hi.
>
> If it helps, I call the R RNG from Fortran in my Delaporte package
> [1], also using iso_c_bindings. Specifically, I have the following C
> code [2]:
>
> void F77_SUB(unifrnd) (int *n, double *x){
> GetRNGstate();
> for (int i = 0; i < *n; ++i){
> *(x + i) = unif_rand();
> }
> PutRNGstate();
> }
> and call it in Fortran like so [3]:
>
> subroutine rdelap_f(n, a, na, b, nb, l, nl, vars) bind(C, name="rdelap_f_")
>
> external unifrnd
>
> integer(kind = c_int), intent(in), value :: n, na, nb, nl
> real(kind = c_double), intent(out), dimension(n) :: vars
> real(kind = c_double), intent(in) :: a(na), b(nb), l(nl)
> real(kind = c_double), dimension(n) :: p
> integer(kind = c_int) :: lg, lt
>
> call unifrnd(n, p)
> lt = 1_c_int
> lg = 0_c_int
> call qdelap_f(p, n, a, na, b, nb, l, nl, lt, lg, vars)
>
> end subroutine rdelap_f
>
> The package passes CRAN tests (at least as of now) on anything between
> GCC 4 and GCC9 [4].
>
> Hope that helps,
>
> Avi
>
> [1] https://bitbucket.org/aadler/delaporte/src/master/
> [2] https://bitbucket.org/aadler/delaporte/src/master/src/utils_and_wrappers.c
> [3] https://bitbucket.org/aadler/delaporte/src/master/src/delaporte.f95
> [4] https://cran.r-project.org/web/checks/check_results_Delaporte.html
>
>
> On Fri, Jan 17, 2020 at 2:39 PM Ivan Krylov  wrote:
> >
> > On Fri, 17 Jan 2020 13:55:39 +
> > وليد خلف معوض المطيرى  wrote:
> >
> > > So, does anyone have an idea of how to solve this issue.
> >
> > "Writing R Extensions", 1.6. Writing portable packages:
> >
> > >> Compiled code should not call the system random number generators
> > >> such as rand, drand48 and random, but rather use the interfaces to
> > >> R’s RNGs described in Random numbers. In particular, if more than
> > >> one package initializes the system RNG (e.g. via srand), they will
> > >> interfere with each other.
> >
> > >> Nor should the C++11 random number library be used, nor any other
> > >> third-party random number generators such as those in GSL.
> >
> > It somewhat less convenient to call the R random number generator from
> > Fortran than it would be from C or C++, but still possible. There is a
> > F77-style example of such use [1], but since you are already using
> > iso_c_binding, you should be able to declare the C API [2] right in the
> > Fortran source:
> >
> > subroutine GetRNGState() bind(c)
> > end subroutine
> >
> > subroutine PutRNGstate() bind(c)
> > end subroutine
> >
> > As a bonus, you get to use the R distribution functions [3],

Re: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

On Tue, Jun 2, 2020 at 5:04 PM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:
> QUESTION:  How much money have people on this list received for what
> they've written?  I've received not one penny for any technical article
> I've written or for software contributed to CRAN.
>
>Spencer

Ditto. What's even more annoying is when people clearly use one's package
in their published work and do not cite it, but that is for a different
thread.

Avi

[[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] [R] a question of etiquette

[Avraham Adler]

IANAL, but the GPL family of licenses is VIRAL copy left so it infects
anything it touched, which is why many shy away and prefer something like
the Mozilla Public License 2 (MPL) as a compromise between viral copyleft
and the permissive MIT/ISC/BSD2.

Avi

On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:

> Spencer,
>
> I apologize for my obvious (in hindsight) error in bringing up the topic.
> I will bring up one example, because of your request. Google has listed
> GPL-1, 2, and 3 as one of several licenses that are restricted and cannot
> be used by a Google product delivered to outside customers. This include
> downloadable client software and software such as insdie the Google Search
> Appliance. This includes having scripts that load packages dynamically as
> with “library()” and “require()”. Please see
> https://opensource.google/docs/thirdparty/licenses/#restricted for their
> wording.
>
> I am not defending their position and disagree with it. However, it is
> their position based on what I think is a conservative or overly cautious
> legal interpretation. I am not a lawyer, however, so my opinions are of no
> import.
>
> Mark
> R. Mark Sharp, Ph.D.
> Data Scientist and Biomedical Statistical Consultant
> 7526 Meadow Green St.
> San Antonio, TX 78251
> mobile: 210-218-2868
> rmsh...@me.com
>
>
>
>
>
>
>
>
>
>
>
> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> spencer.gra...@effectivedefense.org> wrote:
> >
> >   Can Dr. Sharp kindly provide a credible reference, discussing the
> alleged ambiguities in GPL-2 and GPL-3 that convince some companies to
> avoid them?
> >
> >
> >   I like Wikimedia Foundation projects like Wikipedia, where almost
> anyone can change almost anything, and what stays tends to be written from
> a neutral point of view, citing credible sources.  I get several emails a
> day notifying me of changes in articles I'm "watching".  FUD, vandalism,
> etc., are generally reverted fairly quickly or moved to the "Talk" page
> associated with each article, where the world is invited to provide
> credible source(s).
> >
> >
> >   Spencer Graves
> >
> >
> > On 2020-06-02 10:12, Dirk Eddelbuettel wrote:
> >> On 2 June 2020 at 10:06, R. Mark Sharp wrote:
> >> | The GPL-2 and GPL-3 licenses are apparently sufficiently ambiguous in
> the legal community that some companies avoid them.
> >>
> >> Wittgenstein:  'That whereof we cannot speak, thereof we must remain
> silent'
> >>
> >> This is a mailing list of the R project. R is a GNU Project. R is
> licensed
> >> under the GPL, version two or later. That has not stopped large
> corporations
> >> from using R, adopting R, or starting or acquiring R related businesses.
> >>
> >> If you have a strong urge to spread FUD about the GPL and R, could you
> have the
> >> modicum of etiquette to not do it on a mailing list of the R Project?
> >>
> >> Dirk
> >>
> >
> > __
> > 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>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] [R] a question of etiquette

[Avraham Adler]

Apologies; my intent was not to disparage, but that is the term is used in
the industry and in venues which discuss FLOSS because it reflects that the
addition of one component with that kind of copyleft license causes the
entire project to need that particular copyleft license. If there is a term
which reflects that mechanism from a discipline other than biology,
please let me know.

Thanks,

Avi

On Tue, Jun 2, 2020 at 8:25 PM Jeff Newmiller 
wrote:

> "Viral" is has connotations that reflect the biases of the person using
> the term. A less loaded perspective is that some people don't want you to
> take their contributions out of circulation by using it as the foundation
> of your proprietary work. If you want to close it up, build from scratch or
> find some other code that isn't GPL.
>
> Describing it as "viral" makes it sound as if they were trying to steal
> something you did instead of protecting their code from being stolen.
> Please refrain from being inflammatory.
>
> On June 2, 2020 4:49:25 PM PDT, Avraham Adler 
> wrote:
> >IANAL, but the GPL family of licenses is VIRAL copy left so it infects
> >anything it touched, which is why many shy away and prefer something
> >like
> >the Mozilla Public License 2 (MPL) as a compromise between viral
> >copyleft
> >and the permissive MIT/ISC/BSD2.
> >
> >Avi
> >
> >On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
> >
> >> Spencer,
> >>
> >> I apologize for my obvious (in hindsight) error in bringing up the
> >topic.
> >> I will bring up one example, because of your request. Google has
> >listed
> >> GPL-1, 2, and 3 as one of several licenses that are restricted and
> >cannot
> >> be used by a Google product delivered to outside customers. This
> >include
> >> downloadable client software and software such as insdie the Google
> >Search
> >> Appliance. This includes having scripts that load packages
> >dynamically as
> >> with “library()” and “require()”. Please see
> >> https://opensource.google/docs/thirdparty/licenses/#restricted for
> >their
> >> wording.
> >>
> >> I am not defending their position and disagree with it. However, it
> >is
> >> their position based on what I think is a conservative or overly
> >cautious
> >> legal interpretation. I am not a lawyer, however, so my opinions are
> >of no
> >> import.
> >>
> >> Mark
> >> R. Mark Sharp, Ph.D.
> >> Data Scientist and Biomedical Statistical Consu
> <https://www.google.com/maps/search/a+Scientist+and+Biomedical+Statistical+Consu?entry=gmail&source=g>
> ltant
> >> 7526 Meadow Green St.
> >> San Antonio, TX 78251
> >> mobile: 210-218-2868
> >> rmsh...@me.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> >> spencer.gra...@effectivedefense.org> wrote:
> >> >
> >> >   Can Dr. Sharp kindly provide a credible reference, discussing
> >the
> >> alleged ambiguities in GPL-2 and GPL-3 that convince some companies
> >to
> >> avoid them?
> >> >
> >> >
> >> >   I like Wikimedia Foundation projects like Wikipedia, where
> >almost
> >> anyone can change almost anything, and what stays tends to be written
> >from
> >> a neutral point of view, citing credible sources.  I get several
> >emails a
> >> day notifying me of changes in articles I'm "watching".  FUD,
> >vandalism,
> >> etc., are generally reverted fairly quickly or moved to the "Talk"
> >page
> >> associated with each article, where the world is invited to provide
> >> credible source(s).
> >> >
> >> >
> >> >   Spencer Graves
> >> >
> >> >
> >> > On 2020-06-02 10:12, Dirk Eddelbuettel wrote:
> >> >> On 2 June 2020 at 10:06, R. Mark Sharp wrote:
> >> >> | The GPL-2 and GPL-3 licenses are apparently sufficiently
> >ambiguous in
> >> the legal community that some companies avoid them.
> >> >>
> >> >> Wittgenstein:  'That whereof we cannot speak, thereof we must
> >remain
> >> silent'
> >> >>
> >> >> This is a mailing list of the R project. R is a GNU Project. R is
> >> licensed
> >> >> under the GPL, version two or

Re: [R-pkg-devel] [R] a question of etiquette

[Avraham Adler]

I respectfully submit that the mechanism is accurately described as “viral”
albeit the connotations may be uncomfortable. I will refrain from
commenting further in this thread. Happy to continue with you off-list if
you wish.

Thank you,

Aavi

On Tue, Jun 2, 2020 at 8:43 PM Jeff Newmiller 
wrote:

> The obvious answer is simply to refer to GPL. It isn't necessary to
> propagate a derogatory point of view by finding another word for an
> incorrect idea.  Try re-reading my previous words without trying to hold on
> to a flawed interpretation.
>
> On June 2, 2020 5:33:56 PM PDT, Avraham Adler 
> wrote:
> >Apologies; my intent was not to disparage, but that is the term is used
> >in
> >the industry and in venues which discuss FLOSS because it reflects that
> >the
> >addition of one component with that kind of copyleft license causes the
> >entire project to need that particular copyleft license. If there is a
> >term
> >which reflects that mechanism from a discipline other than biology,
> >please let me know.
> >
> >Thanks,
> >
> >Avi
> >
> >On Tue, Jun 2, 2020 at 8:25 PM Jeff Newmiller
> >
> >wrote:
> >
> >> "Viral" is has connotations that reflect the biases of the person
> >using
> >> the term. A less loaded perspective is that some people don't want
> >you to
> >> take their contributions out of circulation by using it as the
> >foundation
> >> of your proprietary work. If you want to close it up, build from
> >scratch or
> >> find some other code that isn't GPL.
> >>
> >> Describing it as "viral" makes it sound as if they were trying to
> >steal
> >> something you did instead of protecting their code from being stolen.
> >> Please refrain from being inflammatory.
> >>
> >> On June 2, 2020 4:49:25 PM PDT, Avraham Adler
> >
> >> wrote:
> >> >IANAL, but the GPL family of licenses is VIRAL copy left so it
> >infects
> >> >anything it touched, which is why many shy away and prefer something
> >> >like
> >> >the Mozilla Public License 2 (MPL) as a compromise between viral
> >> >copyleft
> >> >and the permissive MIT/ISC/BSD2.
> >> >
> >> >Avi
> >> >
> >> >On Tue, Jun 2, 2020 at 7:32 PM R. Mark Sharp  wrote:
> >> >
> >> >> Spencer,
> >> >>
> >> >> I apologize for my obvious (in hindsight) error in bringing up the
> >> >topic.
> >> >> I will bring up one example, because of your request. Google has
> >> >listed
> >> >> GPL-1, 2, and 3 as one of several licenses that are restricted and
> >> >cannot
> >> >> be used by a Google product delivered to outside customers. This
> >> >include
> >> >> downloadable client software and software such as insdie the
> >Google
> >> >Search
> >> >> Appliance. This includes having scripts that load packages
> >> >dynamically as
> >> >> with “library()” and “require()”. Please see
> >> >> https://opensource.google/docs/thirdparty/licenses/#restricted for
> >> >their
> >> >> wording.
> >> >>
> >> >> I am not defending their position and disagree with it. However,
> >it
> >> >is
> >> >> their position based on what I think is a conservative or overly
> >> >cautious
> >> >> legal interpretation. I am not a lawyer, however, so my opinions
> >are
> >> >of no
> >> >> import.
> >> >>
> >> >> Mark
> >> >> R. Mark Sharp, Ph.D.
> >> >> Data Scientist and Biomedical Statistical Consu
> >>
> ><
> https://www.google.com/maps/search/a+Scientist+and+Biomedical+Statistical+Consu?entry=gmail&source=g
> >
> >> ltant
> >> >> 7526 Meadow Green St.
> >> >> San Antonio, TX 78251
> >> >> mobile: 210-218-2868
> >> >> rmsh...@me.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > On Jun 2, 2020, at 10:22 AM, Spencer Graves <
> >> >> spencer.gra...@effectivedefense.org> wrote:
> >> >> >
> >> >> >   Can Dr. Sharp kindly provide a credible reference,
>

Re: [R-pkg-devel] Cannot create C code with acceptable performance with respect to internal R command.

[Avraham Adler]

Sent from my iPhone

> On Dec 5, 2024, at 4:11 PM, Sokol Serguei  wrote:
> 
> Luc,
> 
> There can be many reasons explaining the difference in compiled code 
> performances. Tuning such code to achieve a pick performance is generally a 
> fine art.
> Optimizations techniques can include but are not limited to:
>  - SIMD instructions (and memory alignment for their optimal use);
>  - instruction level parallelism;
>  - unrolling loops;
>  - cache level (mis-)hits;
>  - multi-thread parallelism;
>  - ...
> Approaches in optimization are not the same depending on kind of application: 
> CPU-bound, memory-bound or IO-bound.
> Many of this techniques can be directly used (or not) by compiler depending 
> on chosen options. Are you sure to use the same options and compiler that 
> were used during R compilation?
> And finally, the compared code could be plainly not the same. R can use BLAS 
> call, e.g. OpenBLAS to multiply two matrices. This latter is heavily 
> optimized for such operations and can achieve x10 acceleration compared to 
> plain "naive" BLAS.
> The R code you cite can be just the code for a fallback in case no BLAS was 
> found during R compilation.
> Look at what your sessionInfo() says about used BLAS.

That doesn’t always work. I build R on Windows (10) linking to a pre-compiled 
static OpenBLAS (3.28) and my sessionInfo has an empty string for BLAS. I 
reckon that is because I’m using Rblas.dll, it’s just that my Rblas isn’t 
vanilla. 

Avi

> 
> Best,
> Serguei.
> 
>> Le 05/12/2024 à 14:21, Luc De Wilde a écrit :
>> Dear package developers,
>> 
>> in creating a package lavaanC for use in lavaan, I need to perform some 
>> matrix computations involving matrix products and crossproducts. As far as I 
>> see I cannot directly call the C code in the R core. So I copied the code in 
>> the R core, but the same C/C++ code in a package is 2.5 à 3 times slower 
>> than executed directly in R :
>> 
>> C code in package :
>>   SEXP prod0(SEXP mat1, SEXP mat2) {
>> SEXP u1 = Rf_getAttrib(mat1, R_DimSymbol);
>> int m1 = INTEGER(u1)[0];
>> int n1 = INTEGER(u1)[1];
>> SEXP u2 = Rf_getAttrib(mat2, R_DimSymbol);
>> int m2 = INTEGER(u2)[0];
>> int n2 = INTEGER(u2)[1];
>> if (n1 != m2) Rf_error("matrices not conforming");
>> SEXP retval = PROTECT(Rf_allocMatrix(REALSXP, m1, n2));
>> double* left = REAL(mat1);
>> double* right = REAL(mat2);
>> double* ret = REAL(retval);
>> double werk = 0.0;
>> for (int j = 0; j < n2; j++) {
>>   for (int i = 0; i < m1; i++) {
>>   werk = 0.0;
>> for (int k = 0; k < n1; k++) werk += (left[i + m1 * k] * right[k + 
>> m2 * j]);
>> ret[j * m1 + i] =  werk;
>>   }
>> }
>> UNPROTECT(1);
>> return retval;
>>   }
>> 
>> Test script :
>> m1 <- matrix(rnorm(30), nrow = 60)
>> m2 <- matrix(rnorm(30), ncol = 60)
>> print(microbenchmark::microbenchmark(
>>   m1 %*% m2, .Call("prod0", m1, m2), times = 100
>> ))
>> 
>> Result on my pc:
>> Unit: milliseconds
>>expr min  lq mean  median   uq max 
>> neval
>>   m1 %*% m2 10.5650 10.8967 11.13434 10.9449 11.02965 15.8397   
>> 100
>>  .Call("prod0", m1, m2) 29.3336 30.7868 32.05114 31.0408 33.85935 45.5321   
>> 100
>> 
>> 
>> Can anyone explain why the compiled code in the package is so much slower 
>> than in R core?
>> 
>> and
>> 
>> Is there a way to improve the performance in R package?
>> 
>> 
>> Best regards,
>> 
>> Luc De Wilde
>> 
>> 
>> 
>> __
>> 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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel