Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Uwe Ligges]

To clarify:
A packae must be single under a single license or a license and 
alternative licenes.
You cannot have 2 licenses at the same time, hence ou have to relicense 
anyway. Of course, you have to check whether the licneses allow for it 
or seek confirmation from all copyright holders.


If that (relicensing) is nt possible, you cannpt bundle such software 
components in a single package.


Best,
Uwe Ligges


On 31.08.2023 17:04, Iñaki Ucar wrote:

About licensing,

On Sun, 27 Aug 2023 at 17:30, SHIMA Tatsuya  wrote:


Hi Ivan, thanks for taking the time to look at all the details of this.

  > You licensed the package as MIT. Are your dependencies compatible
with MIT? All direct dependencies of your Rust code seem to be licensed
under either MIT or Apache-2.0, which seems to be compatible.

I am not a legal expert, but as you have seen all of prqlr's dependent crates 
are compatible with the MIT license, and I interpret this to mean that there is 
no problem distributing anything containing them under the MIT license.


No, that's not what "compatibility" means. You cannot just take n
pieces of software, bundle them, and release them under a license of
your choice (unless their licenses enable you to do so via some
re-licensing clause, like the Artistic-2.0 license does).

That's not the case here. By licensing your package as MIT, you are
violating the terms of the Apache-2.0 license, because I assume that
you are not modifying those dependencies at all. So your work should
be both MIT and Apache-2.0 (and others, should they exist, and
provided they are compatible).

Best,


__
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] What to do when a package is archived from CRAN

[Iñaki Ucar]

About licensing,

On Sun, 27 Aug 2023 at 17:30, SHIMA Tatsuya  wrote:
>
> Hi Ivan, thanks for taking the time to look at all the details of this.
>
>  > You licensed the package as MIT. Are your dependencies compatible
> with MIT? All direct dependencies of your Rust code seem to be licensed
> under either MIT or Apache-2.0, which seems to be compatible.
>
> I am not a legal expert, but as you have seen all of prqlr's dependent crates 
> are compatible with the MIT license, and I interpret this to mean that there 
> is no problem distributing anything containing them under the MIT license.

No, that's not what "compatibility" means. You cannot just take n
pieces of software, bundle them, and release them under a license of
your choice (unless their licenses enable you to do so via some
re-licensing clause, like the Artistic-2.0 license does).

That's not the case here. By licensing your package as MIT, you are
violating the terms of the Apache-2.0 license, because I assume that
you are not modifying those dependencies at all. So your work should
be both MIT and Apache-2.0 (and others, should they exist, and
provided they are compatible).

Best,
-- 
Iñaki Úcar

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

Re: [R-pkg-devel] What to do when a package is archived from CRAN

[Lluís Revilla]

The reasons that CRAN has for this (from:
https://cran.r-project.org/src/contrib/PACKAGES.in) are:

X-CRAN-History: Archived on 2023-08-19 for policy violation.
  Downloading on installation from github.
  Unarchived on 2023-08-30.
X-CRAN-Comment: Archived on 2023-08-31 for policy violation.
  .
  Downloading on installation from github.

I see your file src/rust/Cargo.lock has some references to github.com
which is probably what has triggered this.
I'm sorry I cannot help further.

Good luck!


On Thu, 31 Aug 2023 at 14:54, Dirk Eddelbuettel  wrote:

>
> On 31 August 2023 at 07:32, SHIMA Tatsuya wrote:
> | I submitted prqlr 0.5.1 yesterday, which is almost identical to prqlr
> | 0.5.0, and prqlr is now available again on CRAN.
> | Thanks to the CRAN reviewers for their quick reaction.
>
> And it is gone again (per CRANberries). Never a dull moment with CRAN.
>
> 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
>

[[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 to do when a package is archived from CRAN

[Dirk Eddelbuettel]

On 31 August 2023 at 07:32, SHIMA Tatsuya wrote:
| I submitted prqlr 0.5.1 yesterday, which is almost identical to prqlr 
| 0.5.0, and prqlr is now available again on CRAN.
| Thanks to the CRAN reviewers for their quick reaction.

And it is gone again (per CRANberries). Never a dull moment with CRAN. 

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

Re: [R-pkg-devel] Modernizing legacy Fortran:, REAL(kind=8)

[Thomas Petzoldt]

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

Re: [R-pkg-devel] fortran integer(kind=)

[Ivan Krylov]

On Thu, 31 Aug 2023 06:52:47 +
Berry Boessenkool  wrote:

> my R package dwdradar uses Fortran code with the input parameter
> integer(KIND=2):
> https://github.com/brry/dwdradar/blob/master/src/binary_to_num.f90#L20
> https://github.com/brry/dwdradar/blob/master/src/binary_to_num.f90#L55

The "raw" argument of the Fortran function originates from the
"dat" argument to the R function "bin2num", which, in turn, originates
from readBin(what = raw()):
https://github.com/brry/dwdradar/blob/master/R/bin2num.R#L21-L25
https://github.com/brry/dwdradar/blob/master/R/readRadarFile.R#L51

"Raw" vectors correspond to the C type unsigned char, which you seem to
be interpreting as 16-bit integers instead. (This might be a violation
of aliasing rules, but the compiler is not in a position to see it, and
it's been working for years.) The 16-bit integer type in Fortran can be
declared using the iso_c_binding module:

use, intrinsic :: iso_c_binding, only: c_int16_t
integer(KIND=c_int16_t),DIMENSION(Flength),INTENT(in)::raw

There's probably a safer and only slightly less performant way to
implement binary_to_num in R:

dat <- as.integer(dat)
# interpret the bytes as little-endian double-byte integers
dat <- dat[seq(1, length(dat), 2)] + 256 * dat[seq(2, length(dat), 2)]
# extract the 12-bit data
out <- bitwAnd(dat, 4095)
# set the missing flag
is.na(out) <- as.logical(bitwAnd(dat, bitwShiftL(1, 13)))
# set the negative flag
out <- -1 * as.logical(bitwAnd(dat, bitwShiftL(1, 14)))
# set the clutter flag
out[as.logical(bitwAnd(dat, bitwShiftL(1, 15)))] <- clutter

-- 
Best regards,
Ivan

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

[R-pkg-devel] fortran integer(kind=)

[Berry Boessenkool]

Dear list members,

my R package dwdradar uses Fortran code with the input parameter 
integer(KIND=2):
https://github.com/brry/dwdradar/blob/master/src/binary_to_num.f90#L20
https://github.com/brry/dwdradar/blob/master/src/binary_to_num.f90#L55

The CRAN team wrote to change that (line breaks added):
According to the Fortran standards, numerical values are just an enumeration.
What e.g. real(kind=4) means (or even if it is accepted) is implementation 
dependent.
Please change them to something portable.
kind(1.0) or kind(1.0d0} are  commonly used, as is c_double from iso_c_binding.

There are differing(?) answers on stackoverflow that I don't understand:
https://stackoverflow.com/a/3170438

With what should I replace the current code?
A pointer to relevant info would already be highly appreciated.

Thanks ahead,
Berry

PS: I contacted the original author, but his Fortran skills also do not suffice 
to solve this issue...
PPS: a related issue came up in this list yesterday:
https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009514.html


[[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] DESCRITION error

[Emanuele Cordano]

Dear List,

I thank you for the replies. Sorry for cross-posting. I solved the issue.
This error  occurred because I forgot to specify the item "Version:"  in
the DESCRIPTION file. "Protocol Error" , all mandatory items (from
protocol) should be specified in the DESCRIPTION file.

Thank you
Best
Emanuele


Il giorno mer 30 ago 2023 alle ore 18:35 Duncan Murdoch <
murdoch.dun...@gmail.com> ha scritto:

> If you are on Ubuntu, my guess is likely not relevant (unless maybe the
> server holding your files is running Windows).
>
> Duncan Murdoch
>
> On 30/08/2023 12:32 p.m., Emanuele Cordano wrote:
> > Thanks . I’m working on Linux Ubuntu 20.04. I’m seeing the url you sent.
> >
> >
> > Il giorno mer 30 ago 2023 alle 18:23 Duncan Murdoch
> > mailto:murdoch.dun...@gmail.com>> ha scritto:
> >
> > On 30/08/2023 12:03 p.m., Emanuele Cordano wrote:
> >  > Dear list,
> >  >
> >  > I'm creating a package. At a first build, I found out the
> > following error.
> >  > I parsed DESCRIPTION  file and I did not find any possible causes
> > for this
> >  > error. I searched on the web , but I found no clear explanation
> > of this
> >  > error. Have you ever experienced with this? What does this error
> > mean ?
> >  > I'm using an Rstudio server, but it's the first time it happens
> after
> >  > building several other developed packages.
> >  >
> >  >
> >  > Error reading package DESCRIPTION: system error 71 (Protocol
> error)
> >
> > That error says that R couldn't read the DESCRIPTION file.  It
> > sounds as
> > though you are on Windows, your file is on a network share, and the
> > server won't let you connect.  If that's the case, this link
> discusses
> > the issue:
> >
> >
> >
> https://answers.microsoft.com/en-us/windows/forum/all/operating-system-error-71-this-remote-computer-has/74270db8-4522-4e24-a494-5bf75becc9da
> <
> https://answers.microsoft.com/en-us/windows/forum/all/operating-system-error-71-this-remote-computer-has/74270db8-4522-4e24-a494-5bf75becc9da
> >
> >
> >
> > --
> > Emanuele Cordano, PhD
> > Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr.
> > 3587 (Albo A - Provincia di Trento)
> > cell: +39 3282818564 
> > email: emanuele.cord...@gmail.com
> > ,emanuele.cord...@rendena100.eu
> > ,
> > emanuele.cord...@eurac.edu 
> > PEC: emanuele.cord...@ingpec.eu 
> > URL: www.rendena100.eu 
> > LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333
> > 
> > GitHub: https://github.com/ecor 
> >
>
>

-- 
Emanuele Cordano, PhD
Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr.
3587 (Albo A - Provincia di Trento)
cell: +39 3282818564
email: emanuele.cord...@gmail.com,emanuele.cord...@rendena100.eu,
emanuele.cord...@eurac.edu
PEC: emanuele.cord...@ingpec.eu
URL: www.rendena100.eu
LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333
GitHub: https://github.com/ecor

[[alternative HTML version deleted]]

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