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

[SHIMA Tatsuya]

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.

Best,
Tatsuya

On 2023/08/29 19:12, SHIMA Tatsuya wrote:

Hi Uwe, thanks for the summary of the background.
Let me ask you a few questions about a couple of points.

> Accepting a package that downloads crates from github

I don't think prqlr 0.5.0 downloads crates on GitHub.
prqlr <= 0.4.0 use crate on GitHub which I patched to support old Rust 
on Debian , but with 0.5.0 I 
switched to installing from crates.io completely.
(This was made possible because Debian recently upgraded Rust for the 
first time in six months.)


> All the correspondence we see claims that the submission had bundled 
the rust code, but the version that got archived after publication was 
104KB and did not.


I am aware that in the first submission of prqlr 0.5.0, the size of 
the source was 12MB due to the vendoring all Rust dependent crates and 
CRAN pointed out the size of 12MB as a reason for rejection.
That is why in my second submission I wrote the following comment that 
I had removed the vendoring tarball.


> To reduce package size on CRAN, it does not vendor dependent Rust 
crates.


https://github.com/eitsupi/prqlr/pull/161/commits/9aba66647fa5e48da0a5983643a4df001721b3f7#diff-cf8c1cd4cfb6a9ceb5ba522a5711321831948fea41fbb0cd9f799506c7caca1bR22-R27 



In other words, I did not claim to have bundled the Rust code.
And that second submission was accepted by CRAN and I have not 
received any further messages from CRAN.


I am aware that the CRAN policy says that we can ask CRAN for 
permission to download from the internet.

I intended to ask for that in this comment.

If I am doing this wrong, what should I do?

Thanks for reading this.

Best,
Tatsuya

On 2023/08/28 17:24, Uwe Ligges wrote:

Friends,

CRAN wrote initially to some rust using maintainers:

The CRAN policy on authorship/copyright is very clear:

"(’All components’ includes any downloaded at installation or during 
use.) "


Please explain how your package complies if you believe it does.

Further, we ask that you use the 'cargo vendor' mechanism to avoid 
downloading during installation and limit the number of CPUs 'cargo 
build' can use during installation.  Both points are covered in 
."





Accepting a package that downloads crates from github happened 
automatically, but incorrectly (a false negative):
All the correspondence we see claims that the submission had bundled 
the rust code, but the version that got archived after publication 
was 104KB and did not.


So please simply follow the mails you got and fix the package folwing 
the "using_rust" documentation.


In addition, it was mentined already to get the authorship straight.

Best,
Uwe Ligges







On 27.08.2023 17:28, SHIMA Tatsuya wrote:

Hi Tim, thank you for sharing this information. i didn't know this.

If this is the cause, the problem seems to have been resolved in the 
latest serde , so it 
seems to be possible to deal with it.


Best,
Tatsuya

On 2023/08/27 20:24, Tim Taylor wrote:
Could you have been caught out with the precompiled binary that 
serde started distributing in a few of it’s versions 
(https://github.com/serde-rs/serde/issues/2538)? That could have 
been a reason if you pinned a version with it present but only CRAN 
could confirm if that was the reason.


Tim


On 26 Aug 2023, at 22:22, Ivan Krylov  wrote:

On Sat, 26 Aug 2023 11:46:44 +0900
SHIMA Tatsuya  wrote:


I noticed that my submitted package `prqlr` 0.5.0 was archived from
CRAN on 2023-08-19.


I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only
received word from CRAN that it passed the automated release 
process.


Sarah gave a good guess (although there are CRAN packages containing
C++ and Rust code with NOTEs about size of their libs, 18.2Mb is 
still

a lot), though I do find it strange that you didn't receive anything
from CRAN prior to having your package archived. I don't think I ever
had problems with e-mails being delivered from CRAN to GMail, but we
can't rule that out.

You've obviously made an effort to follow the Rust policy, and I 
don't

see any obvious problems with this part of the package, although I
haven't tried it myself to verify the installation working offline 
from

bundled source code.

You've also made an effort to list all the authors of the code
comprising your package in inst/AUTHORS, which is the right thing 
to do

to avoid making the list of authors in DESCRIPTION long enough to be
unreadable.

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. You 
named
the 

Re: [R-pkg-devel] DESCRITION error

[Duncan Murdoch]

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
 



--
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 



__
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]

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 <
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
>
>
> --
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

Re: [R-pkg-devel] DESCRITION error

[Duncan Murdoch]

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

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

[R-pkg-devel] DESCRITION error

[Emanuele Cordano]

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)

Thank you
Best
Emanuele
-- 
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

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

[Ivan Krylov]

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.

-- 
Best regards,
Ivan

[*]
https://stevelionel.com/drfortran/2017/03/27/doctor-fortran-in-it-takes-all-kinds/

__
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

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

[Thomas Petzoldt]

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