[R-pkg-devel] extra license (ODbL) on https://svn.r-project.org/R/trunk/share/licenses/license.db
Hi, I would like to add an R package to CRAN which is now available at github: https://github.com/jwijffels/BelgiumMaps.Admin The package contains data from OpenStreetMap which should be released under the Open Database license (ODbL 1.0) which can be found at http://opendatacommons.org/licenses/odbl/1-0/ Unfortunately ODbL is not part of https://svn.r-project.org/R/trunk/share/licenses/license.db So I presume it will be rejected by the CRAN policy which states that other licenses than in that license.db file will generally be rejected. Hence my question. What can I do to make ODbL part of https://svn.r-project.org/R/trunk/share/licenses/license.db thanks, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] found ... marked UTF-8 strings
Dear, I trying to fix all notes from R CMD check on a package. The package contains a data.frame inside the data folder where character vectors in the dataset are set with an UTF-8 encoding. R CMD check gives me. * checking data for non-ASCII characters ... NOTE Note: found 1163 marked UTF-8 strings I would like to keep the strings as correctly encoded as UTF-8 instead of having to convert them to ASCII. Hence my questions: Question 1: What can I do to make this NOTE disappear? Now that http://win-builder.r-project.org/ with R-devel doesn't give me the NOTE, while with R-release, I'm still getting the NOTE. Question 2: Will the note disappear in the next release of R allowing to have encoded character strings in a data.frame in the data folder? thanks, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] invalid DOIs
Hello everyone, I'm updating the R package image.textlinedetector which is already on CRAN. When doing R CMD check on winbuilder. I receive the note: Found the following (possibly) invalid DOIs: DOI: 10.1117/12.704538 From: DESCRIPTION Status: Internal Server Error Message: 500 The relevant part in the DESCRIPTION file which caused this note looks like this: ... by Arivazhagan M. et al (2007) , and a wrapper for an image segmentation ... This DOI hasn't changed and CRAN seems to parse it fine as the link is shown at the DESCRIPTION of the web page of the package at https://cran.r-project.org/package=image.textlinedetector How to solve this? What is the correct doi to put in here? many thanks for your help, Jan [https://cran.r-project.org/CRANlogo.png]<https://cran.r-project.org/package=image.textlinedetector> CRAN - Package image.textlinedetector<https://cran.r-project.org/package=image.textlinedetector> Version: 0.1.3: Imports: Rcpp (≥ 0.12.9), magick: LinkingTo: Rcpp: Suggests: opencv: Published: 2021-01-25: Author: Jan Wijffels [aut, cre, cph] (R wrapper), Vrije Universiteit Brussel - DIGI: Brussels Platform for Digital Humanities [cph] (R wrapper), Jeroen Ooms [ctb, cph] (More details in LICENSE.note file), Arthur Flôr [ctb, cph] (More details in LICENSE.note file), Saverio Meucci [ctb ... cran.r-project.org [[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] invalid DOIs
Thank you, Uwe. Jan From: Uwe Ligges Sent: Wednesday, July 7, 2021 4:28 PM To: Jan Wijffels ; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] invalid DOIs On 06.07.2021 10:37, Jan Wijffels wrote: > Hello everyone, > > I'm updating the R package image.textlinedetector which is already on CRAN. > When doing R CMD check on winbuilder. I receive the note: > > Found the following (possibly) invalid DOIs: >DOI: 10.1117/12.704538 > From: DESCRIPTION > Status: Internal Server Error > Message: 500 Many publishers (one worse than the other) seem to have very flakey internet resources and web servers are poorly set up, hence simply ignore this. Best, Uwe Ligges > The relevant part in the DESCRIPTION file which caused this note looks like > this: > ... by Arivazhagan M. et al (2007) , and a wrapper for > an image segmentation ... > > This DOI hasn't changed and CRAN seems to parse it fine as the link is shown > at the DESCRIPTION of the web page of the package at > https://cran.r-project.org/package=image.textlinedetector > How to solve this? What is the correct doi to put in here? > > many thanks for your help, > Jan > [https://cran.r-project.org/CRANlogo.png]<https://cran.r-project.org/package=image.textlinedetector> > CRAN - Package > image.textlinedetector<https://cran.r-project.org/package=image.textlinedetector> > Version: 0.1.3: Imports: Rcpp (≥ 0.12.9), magick: LinkingTo: Rcpp: Suggests: > opencv: Published: 2021-01-25: Author: Jan Wijffels [aut, cre, cph] (R > wrapper), Vrije Universiteit Brussel - DIGI: Brussels Platform for Digital > Humanities [cph] (R wrapper), Jeroen Ooms [ctb, cph] (More details in > LICENSE.note file), Arthur Flôr [ctb, cph] (More details in LICENSE.note > file), Saverio Meucci [ctb ... > cran.r-project.org > > > >[[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] use g++ instead of clang++ on Mac OS
Hi, I'm trying to fix an issue with the ruimtehol R package https://github.com/bnosac/ruimtehol on Mac OS. The package contains C++ code following the C++11 standard. The package is built on Mac OS with clang++ but I would like to compile it with g++ instead. The manual on R extensions at https://cran.r-project.org/doc/manuals/R-exts.html#Using-C_002b_002b11-code mentions that > It is possible to specify ‘CXX11’ to be a distinct compiler just for > C++11–using packages, e.g. g++ on Solaris. I tried to set such a directive in my src/Makevars file but appartently failed to set it correctly. How do I set in the src/Makevars such that the compilation is done using g++ instead of clang++ My src/Makevars looks like this. I appreciate any help on this matter. CXX_STD = CXX11 PKG_LIBS = -pthread PKG_CPPFLAGS = -DSTRICT_R_HEADERS -DBOOST_NO_AUTO_PTR -include compliance.h $(SHLIB_PTHREAD_FLAGS) -I./Starspace/src SOURCES = Starspace/src/utils/args.cpp Starspace/src/utils/normalize.cpp Starspace/src/utils/utils.cpp SOURCES += Starspace/src/data.cpp Starspace/src/dict.cpp Starspace/src/doc_data.cpp Starspace/src/doc_parser.cpp Starspace/src/model.cpp Starspace/src/parser.cpp Starspace/src/proj.cpp Starspace/src/starspace.cpp SOURCES += rcpp_textspace.cpp SOURCES += compliance.cpp SOURCES += RcppExports.cpp OBJECTS = $(SOURCES:.cpp=.o) .PHONY: all all: $(SHLIB); rm -f $(OBJECTS) thank you, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[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] use g++ instead of clang++ on Mac OS
Ralf, Thank you for the input. Does that mean also using a configure script would not work to make it use g++ instead of clang++ on Mac OS? Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 On Thu, 24 Jan 2019 at 16:02, Ralf Stubner wrote: > > The manual on R extensions at > > > https://cran.r-project.org/doc/manuals/R-exts.html#Using-C_002b_002b11-code > > mentions that > > > >> It is possible to specify ‘CXX11’ to be a distinct compiler just for > >> C++11–using packages, e.g. g++ on Solaris. > > > > I tried to set such a directive in my src/Makevars file but appartently > > failed to set it correctly. How do I set in the src/Makevars such that > the > > compilation is done using g++ instead of clang++ > > It is not possible to alter the compiler via src/Makevars, c.f. > https://stat.ethz.ch/pipermail/r-package-devel/2017q4/002087.html. You > have to use $HOME/.R/Makevars or $R_HOME/etc/Makeconf for that. > > Greetings > Ralf > > -- > Ralf Stubner > Senior Software Engineer / Trainer > > daqana GmbH > Dortustraße 48 > 14467 Potsdam > > T: +49 331 23 61 93 11 > F: +49 331 23 61 93 90 > M: +49 162 20 91 196 > Mail: ralf.stub...@daqana.com > > Sitz: Potsdam > Register: AG Potsdam HRB 27966 > Ust.-IdNr.: DE300072622 > Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze > > __ > 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] what is difference between Mac setup of rhub and CRAN
Hello, I'm trying to find out what is different between the rhub and CRAN software for Mac OS to fix the FAIL statement on a package I maintain called ruimtehol (https://CRAN.R-project.org/package=ruimtehol). The package builds and checks fine on all CRAN platforms except Mac OS r-release-osx-x86_64. >From what I see, the Mac setups on CRAN are currently: 1/ CRAN running R 3.4.4: r-oldrel-osx-x86_64 : OS X 10.11.6: Xcode 8.2.1, clang 4.0.0, GNU Fortran 6.1 2/ CRAN running R 3.5.2: r-release-osx-x86_64 : OS X 10.11.6: Xcode 8.2.1, clang 4.0.0, GNU Fortran 6.1 3/ rhub running R 3.5.2: unknown setup The ruimtehol R package builds and checks fine on both CRAN running R 3.4.4 and rhub running R 3.5.2 but apparently FAILS on CRAN running R 3.5.2. *Question 1*: Can someone indicate what is the difference between the 3 platforms regarding Mac setup (which possibly might give an indication on what this check problem on the ruimtehol package) *Question 2*: What can be a reason why a package fails on r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64? FYI. Rhub build on Mac OS with R 3.5.2. is available at https://artifacts.r-hub.io/ruimtehol_0.1.2.tar.gz-147a4e1367b49538e6134bf0fdf76a32 CRAN check restuls of the package are at https://cran.r-project.org/web/checks/check_results_ruimtehol.html thank you, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[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 is difference between Mac setup of rhub and CRAN
Gabor. Thanks for the input. I don't have a Mac machine at my disposal but another user of the package tried helping out debugging here: https://github.com/bnosac/ruimtehol/issues/10 The package has C++ code which relies on clang-3.3 or newer and relies on -pthread. It has in it's src/Makevars ( https://github.com/bnosac/ruimtehol/blob/master/src/Makevars) PKG_LIBS = -pthread PKG_CPPFLAGS = -pthread Is that what you mean with linking to a system library? What version of the compiler is running on rhub and how is it different from CRAN r-release-osx-x86_64 or even CRAN r-oldrel-osx-x86_64 About CRAN (Question 2): What can be a reason why a package fails on r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64 Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 On Thu, 31 Jan 2019 at 10:50, Gábor Csárdi wrote: > The R-hub macOS machine is also 10.11.6, and has XCode 8.2.1, but does > not use the CRAN clang 4.0.0 compiler currently. Seems like your > package has compiled code, so this _might_ matter. Sometimes there are > issues when linking C++ libs produced by different compilers, because > the ABIs can be slightly different. E.g. exceptions are sometimes lost > between compilation units. So if you are linking to a system library > that was compiled with the standard macOS compiler, then this can come > up. I suggest you download the clang compiler from CRAN and try to > reproduce it locally. > > Best, > Gabor > > > > On Thu, Jan 31, 2019 at 9:03 AM Jan Wijffels wrote: > > > > Hello, > > > > I'm trying to find out what is different between the rhub and CRAN > software > > for Mac OS to fix the FAIL statement on a package I maintain called > > ruimtehol (https://CRAN.R-project.org/package=ruimtehol). > > The package builds and checks fine on all CRAN platforms except Mac > > OS r-release-osx-x86_64. > > > > From what I see, the Mac setups on CRAN are currently: > > > > 1/ CRAN running R 3.4.4: r-oldrel-osx-x86_64 : OS X 10.11.6: Xcode > 8.2.1, > > clang 4.0.0, GNU Fortran 6.1 > > 2/ CRAN running R 3.5.2: r-release-osx-x86_64 : OS X 10.11.6: Xcode > 8.2.1, > > clang 4.0.0, GNU Fortran 6.1 > > 3/ rhub running R 3.5.2: unknown setup > > > > > > The ruimtehol R package builds and checks fine on both CRAN running R > 3.4.4 > > and rhub running R 3.5.2 but apparently FAILS on CRAN running R 3.5.2. > > > > *Question 1*: Can someone indicate what is the difference between the 3 > > platforms regarding Mac setup (which possibly might give an indication on > > what this check problem on the ruimtehol package) > > *Question 2*: What can be a reason why a package fails on > r-release-osx-x86_64 > > but checked fine on r-oldrel-osx-x86_64? > > > > FYI. Rhub build on Mac OS with R 3.5.2. is available at > > > https://artifacts.r-hub.io/ruimtehol_0.1.2.tar.gz-147a4e1367b49538e6134bf0fdf76a32 > >CRAN check restuls of the package are at > > https://cran.r-project.org/web/checks/check_results_ruimtehol.html > > > > thank you, > > Jan > > > > Jan Wijffels > > Statistician > > www.bnosac.be | +32 486 611708 > > > > [[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] what is difference between Mac setup of rhub and CRAN
Gabor. Thanks for the input. I unfortunately do not have a Mac at my disposal to check this at that would be indeed the most optimal solution to find out differences in the setups. Is there someone on this mailing list which can comment on the CRAN machines about MacOS to answer What can be a reason why a package fails on r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64 as the https://cran.r-project.org/web/checks/check_flavors.html seem to indicate they have the same setup? My package is using C++ code which relies on clang-3.3 or newer and relies on -pthread. The src/Makevars are at https://github.com/bnosac/ruimtehol/blob/master/src/Makevars Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 On Thu, 31 Jan 2019 at 11:26, Gábor Csárdi wrote: > See answers inline. > > On Thu, Jan 31, 2019 at 10:16 AM Jan Wijffels wrote: > [...] > > The package has C++ code which relies on clang-3.3 or newer and relies > on -pthread. It has in it's src/Makevars ( > https://github.com/bnosac/ruimtehol/blob/master/src/Makevars) > > > > PKG_LIBS = -pthread > > PKG_CPPFLAGS = -pthread > > > > Is that what you mean with linking to a system library? > > Possibly, yes. > > > What version of the compiler is running on rhub and how is it different > from CRAN r-release-osx-x86_64 or even CRAN r-oldrel-osx-x86_64 > > R-hub uses the standard system compiler in Xcode. CRAN checks use > their custom built clang compiler. This is usually compatible with the > system compiler, except for some rare ABI issues. You can download it > at https://cran.r-project.org/bin/macosx/tools/ The check flavors > page at https://cran.r-project.org/web/checks/check_flavors.html might > be outdated, as it still shows clang 4.0.0. I don't know, I cannot > speak for CRAN. > > > About CRAN (Question 2): What can be a reason why a package fails on > r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64 > > Hard to say. I think you only have a real chance to fix this if you > can reproduce it on your machine. > > Gabor > > [...] > [[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 is difference between Mac setup of rhub and CRAN
Yes, that is exactly the problem I'm facing with that R package.
Anyone knows how do I find out which ABI issue it is & who should I contact
to try to find a solution?
Jan Wijffels
Statistician
www.bnosac.be | +32 486 611708
On Thu, 31 Jan 2019 at 11:59, Gábor Csárdi wrote:
> I can reproduce your problem, and indeed it seems that it is a
> compiler ABI incompatibility issue. I am not sure how it could be
> fixed, though.
>
> With the CRAN compiler it gets stuck here:
>
> ### Name: embed_articlespace
> ### Title: Build a Starspace model for learning the mapping between
> ### sentences and articles (articlespace)
> ### Aliases: embed_articlespace
>
> ### ** Examples
>
> library(udpipe)
> data(brussels_reviews_anno, package = "udpipe")
> x <- subset(brussels_reviews_anno, language == "nl")
> x$token <- x$lemma
> x <- x[, c("doc_id", "sentence_id", "token")]
> set.seed(123456789)
> model <- embed_articlespace(x, early_stopping = 1,
> dim = 25, epoch = 25, minCount = 2,
> negSearchLimit = 1, maxNegSamples = 2)
> #> Start to initialize starspace model.
> #> Build dict from input file :
>
> /var/folders/59/0gkmw1yj2w7bf2dfc3jznv5wgn/T//RtmpL18Wso/textspace_1200026295f3c.txt
> #> Read 0M words
> #> Number of words in dictionary: 1274
> #> Number of labels in dictionary: 0
> #> Loading data from file :
>
> /var/folders/59/0gkmw1yj2w7bf2dfc3jznv5wgn/T//RtmpL18Wso/textspace_1200026295f3c.txt
> #> Total number of examples loaded : 470
> #> 2019-01-31 10:50:04 Start training epoch 1 with learning rate 0.01
>
> Gabor
>
> On Thu, Jan 31, 2019 at 10:34 AM Jan Wijffels wrote:
> >
> > Gabor. Thanks for the input. I unfortunately do not have a Mac at my
> disposal to check this at that would be indeed the most optimal solution to
> find out differences in the setups.
> >
> > Is there someone on this mailing list which can comment on the CRAN
> machines about MacOS to answer
> >
> > What can be a reason why a package fails on r-release-osx-x86_64 but
> checked fine on r-oldrel-osx-x86_64 as the
> https://cran.r-project.org/web/checks/check_flavors.html seem to indicate
> they have the same setup? My package is using C++ code which relies on
> clang-3.3 or newer and relies on -pthread. The src/Makevars are at
> https://github.com/bnosac/ruimtehol/blob/master/src/Makevars
> >
> > Jan
> >
> > Jan Wijffels
> > Statistician
> > www.bnosac.be | +32 486 611708
> >
> >
> > On Thu, 31 Jan 2019 at 11:26, Gábor Csárdi
> wrote:
> >>
> >> See answers inline.
> >>
> >> On Thu, Jan 31, 2019 at 10:16 AM Jan Wijffels
> wrote:
> >> [...]
> >> > The package has C++ code which relies on clang-3.3 or newer and
> relies on -pthread. It has in it's src/Makevars (
> https://github.com/bnosac/ruimtehol/blob/master/src/Makevars)
> >> >
> >> > PKG_LIBS = -pthread
> >> > PKG_CPPFLAGS = -pthread
> >> >
> >> > Is that what you mean with linking to a system library?
> >>
> >> Possibly, yes.
> >>
> >> > What version of the compiler is running on rhub and how is it
> different from CRAN r-release-osx-x86_64 or even CRAN r-oldrel-osx-x86_64
> >>
> >> R-hub uses the standard system compiler in Xcode. CRAN checks use
> >> their custom built clang compiler. This is usually compatible with the
> >> system compiler, except for some rare ABI issues. You can download it
> >> at https://cran.r-project.org/bin/macosx/tools/ The check flavors
> >> page at https://cran.r-project.org/web/checks/check_flavors.html might
> >> be outdated, as it still shows clang 4.0.0. I don't know, I cannot
> >> speak for CRAN.
> >>
> >> > About CRAN (Question 2): What can be a reason why a package fails on
> r-release-osx-x86_64 but checked fine on r-oldrel-osx-x86_64
> >>
> >> Hard to say. I think you only have a real chance to fix this if you
> >> can reproduce it on your machine.
> >>
> >> Gabor
> >>
> >> [...]
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] how to specify to let a package only build 64bit on CRAN
Hello everyone, I have a package which I would like to host on CRAN. The package is at https://github.com/bnosac/golgotha The package only builds on 64bit however because the package uses R package reticulate which requires a python library called torch which does not build on 32 bit platforms. So installation only works using INSTALL_opts = "--no-multiarch" How do you specify this to the CRAN maintainers that this is the way it should be set up on CRAN such that it only is built for 64bit systems. thanks, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[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] how to specify to let a package only build 64bit on CRAN
Duncan, Thanks for the reply. Let me make this more clear. The R package reticulate works on 32bit and 64bit. My golgotha package depends on reticulate and an extra Python package called torch which is not available for 32bit platforms. This is specified in the DESCRIPTION file at https://github.com/bnosac/golgotha/blob/master/DESCRIPTION#L17 For that reason R CMD check will fail on CRAN for 32bit. Hence my question. How do I specify this in the package such that I can distribute it on CRAN. best, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 ‐‐‐ Original Message ‐‐‐ On Monday 11 May 2020 14:39, Duncan Murdoch wrote: > On 11/05/2020 7:54 a.m., Jan Wijffels wrote: > > > Hello everyone, > > I have a package which I would like to host on CRAN. The package is at > > https://github.com/bnosac/golgotha > > The package only builds on 64bit however because the package uses R package > > reticulate which requires a python library called torch which does not > > build on 32 bit platforms. > > So installation only works using INSTALL_opts = "--no-multiarch" > > How do you specify this to the CRAN maintainers that this is the way it > > should be set up on CRAN such that it only is built for 64bit systems. > > I don't see how your package has any 32 bit dependence, since it has no > src directory. It's probably sufficient to declare the dependency on > reticulate, which indirectly implies the 32 bit dependence. But if > reticulate works on 32 bit systems as long as users don't need "torch", > then just state that. > > One thing I'd recommend: you should try to change the dependency from > Depends to Imports. If there are a few reticulate functions that you > want your users to have access to, you can import them and re-export > them so they're available from your package as well. > > Duncan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN
Duncan, Thanks for the confirmation that there isn't a formal way to state this 64bit dependency. have a nice day, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 ‐‐‐ Original Message ‐‐‐ On Monday 11 May 2020 14:55, Duncan Murdoch wrote: > On 11/05/2020 8:46 a.m., Jan Wijffels wrote: > > > Duncan, > > Thanks for the reply. Let me make this more clear. > > The R package reticulate works on 32bit and 64bit. My golgotha package > > depends on reticulate and an extra Python package called torch which is not > > available for 32bit platforms. This is specified in the DESCRIPTION file at > > https://github.com/bnosac/golgotha/blob/master/DESCRIPTION#L17 > > For that reason R CMD check will fail on CRAN for 32bit. Hence my question. > > How do I specify this in the package such that I can distribute it on CRAN. > > I don't think there's a formal way to state that, and there shouldn't > be. Maybe some day someone will make 32 bit torch available, and then > your restriction would be unnecessary. Just state the current situation > in your submission comments. You may get an automatic rejection because > of the build failure, then follow the instructions for getting a human > to look at things. > > It's possible that CRAN will not be flexible on this, because it aims > for wide portability of the packages it hosts. However, 32 bit systems > are less and less common, so a good argument about why your package is > useful even if not usable on some old systems would probably get it > accepted. > > Duncan Murdoch > > > best, > > Jan > > Jan Wijffels > > Statistician > > www.bnosac.be | +32 486 611708 > > ‐‐‐ Original Message ‐‐‐ > > On Monday 11 May 2020 14:39, Duncan Murdoch murdoch.dun...@gmail.com wrote: > > > > > On 11/05/2020 7:54 a.m., Jan Wijffels wrote: > > > > > > > Hello everyone, > > > > I have a package which I would like to host on CRAN. The package is at > > > > https://github.com/bnosac/golgotha > > > > The package only builds on 64bit however because the package uses R > > > > package reticulate which requires a python library called torch which > > > > does not build on 32 bit platforms. > > > > So installation only works using INSTALL_opts = "--no-multiarch" > > > > How do you specify this to the CRAN maintainers that this is the way it > > > > should be set up on CRAN such that it only is built for 64bit systems. > > > > > > I don't see how your package has any 32 bit dependence, since it has no > > > src directory. It's probably sufficient to declare the dependency on > > > reticulate, which indirectly implies the 32 bit dependence. But if > > > reticulate works on 32 bit systems as long as users don't need "torch", > > > then just state that. > > > One thing I'd recommend: you should try to change the dependency from > > > Depends to Imports. If there are a few reticulate functions that you > > > want your users to have access to, you can import them and re-export > > > them so they're available from your package as well. > > > Duncan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN
Gabor/Joris, Thanks for the suggestions! I'll try it out and see if it reaches the CRAN servers. best, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 ‐‐‐ Original Message ‐‐‐ On Monday 11 May 2020 15:13, Joris Meys wrote: > Hi Jan, > > To add to the suggestion of Gabor and Duncan, it might be a good idea to add > a packageStartupMessage that warns the user about the problem when running on > a 32bit system. You can easily extract that info from R.Version()$arch . That > might help negotiating with CRAN. > > Kind regards > Joris > > Joris Meys > Statistician > T +32 9 264 61 79 > > Department Data Analysis and Mathematical Modelling > > Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent, > Belgium > T administration office +32 9 264 59 32 > > www.ugent.be > > e-maildisclaimer > > From: R-package-devel r-package-devel-boun...@r-project.org on behalf of Jan > Wijffels jwijff...@bnosac.be > Sent: Monday, May 11, 2020 2:46 PM > To: Duncan Murdoch > Cc: r-package-devel@r-project.org > Subject: Re: [R-pkg-devel] how to specify to let a package only build 64bit > on CRAN > > Duncan, > > Thanks for the reply. Let me make this more clear. > The R package reticulate works on 32bit and 64bit. My golgotha package > depends on reticulate and an extra Python package called torch which is not > available for 32bit platforms. This is specified in the DESCRIPTION file at > https://github.com/bnosac/golgotha/blob/master/DESCRIPTION#L17 > > For that reason R CMD check will fail on CRAN for 32bit. Hence my question. > How do I specify this in the package such that I can distribute it on CRAN. > > best, > Jan > > Jan Wijffels > Statistician > www.bnosac.be | +32 486 611708 > > ‐‐‐ Original Message ‐‐‐ > On Monday 11 May 2020 14:39, Duncan Murdoch murdoch.dun...@gmail.com wrote: > > > On 11/05/2020 7:54 a.m., Jan Wijffels wrote: > > > > > Hello everyone, > > > I have a package which I would like to host on CRAN. The package is at > > > https://github.com/bnosac/golgotha > > > The package only builds on 64bit however because the package uses R > > > package reticulate which requires a python library called torch which > > > does not build on 32 bit platforms. > > > So installation only works using INSTALL_opts = "--no-multiarch" > > > How do you specify this to the CRAN maintainers that this is the way it > > > should be set up on CRAN such that it only is built for 64bit systems. > > > > I don't see how your package has any 32 bit dependence, since it has no > > src directory. It's probably sufficient to declare the dependency on > > reticulate, which indirectly implies the 32 bit dependence. But if > > reticulate works on 32 bit systems as long as users don't need "torch", > > then just state that. > > One thing I'd recommend: you should try to change the dependency from > > Depends to Imports. If there are a few reticulate functions that you > > want your users to have access to, you can import them and re-export > > them so they're available from your package as well. > > Duncan > > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN
Dirk, Thanks. I'll use this suggestion as well. have a nice day, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 ‐‐‐ Original Message ‐‐‐ On Monday 11 May 2020 15:51, Dirk Eddelbuettel wrote: > > > On 11 May 2020 at 13:13, Joris Meys wrote: > | To add to the suggestion of Gabor and Duncan, it might be a good idea to > add a packageStartupMessage that warns the user about the problem when > running on a 32bit system. You can easily extract that info from > R.Version()$arch . That might help negotiating with CRAN. > > Related: As CRAN does not give you a hook, approximate one yourself in the > package. I.e. demote reticulate to a mere Suggests:, then in .onAttach() > check a) if it is present and howl if not as well as b) if on 32 bit and say > you're sorry if so. Obviously, a real switch would be better but ... > > Dirk > > --- > > http://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] c++17 on solaris cran
Hello everyone, I've got at package on CRAN which uses C++17. Package is at https://cran.r-project.org/web/packages/image.binarization/index.html The package fails on Solaris with the following message as my Makevars just contains CXX_STD = CXX17 indicating it requires C++17 * installing to library ‘/home/ripley/R/Lib32’ * installing *source* package ‘image.binarization’ ... ** package ‘image.binarization’ successfully unpacked and MD5 sums checked ** using staged installation ** libs Error: C++17 standard requested but CXX17 is not defined * removing ‘/home/ripley/R/Lib32/image.binarization’ real1.0 user0.7 sys 0.1 Looks like Solaris does not support C++17 yet. Is this error something that needs to be fixed by me? Will the package be removed from CRAN because of this. Any other people with C++17 code who can provide some advise. best, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
