Re: [R-pkg-devel] Change package name
If you really need a new package name, is there an accepted way to update the old name to at least provide a message for a while as to the new name to use and perhaps have the load otherwise fail? -Original Message- From: R-package-devel On Behalf Of Dirk Eddelbuettel Sent: Tuesday, June 20, 2023 12:00 PM To: William Becker Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Change package name Hi William, On 20 June 2023 at 16:06, William Becker wrote: | I am the maintainer of a package which is unfortunately involved in a complicated dispute regarding its intellectual property (since the package was partly built under a contract with an organisation), but also the "branding" of the package, i.e. the name. | | The story is long and complicated, but suffice to say that the name of the package is apparently creating a misleading connection with the organisation, and this is causing difficulties on both sides. | | I am aware that changing the name of a package is very disruptive, and I am not considering it lightly. However just for information at this stage, I wonder if anyone could tell me whether packages have ever changed names on CRAN, what the rules are in these cases, and if there is any advice for minimising the disruption. | | To reiterate, I am not (yet) planning to do this, but exploring options and looking for advice. You presented the reasoning convincingly and are aware of the general "we would rather not do this" sentiment. Ultimately, this (as so often) is CRAN's call so you have to do that (directly and not via this list). My sense is that you have a case but only CRAN can tell. Good luck, 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
[Rd] New behavior when running script in package directory?
When I run a script foo.R containing some trivial code in my home
directory, via Emacs/ESS, everything works as expected: R
starts, and a setwd() command to set the working directory is
run automatically before the code in the script is run.
But if I copy foo.R to some package/R directory strange
things happen. When I use Emacs/ESS to run the script
in its new location, R starts, and setwd() is called to set
the working directory, but then one or more libraries that the
package depends on are loaded, even though I am using no
libraries in foo.R.
Now consider foo.R that contains the following trivial code:
secsToRDateTime <- function(secs) {
day2sec <- 60*60*24
days <- secs/day2sec
}
When I try to run this from package/R I get...
Error in ss(file, echo = visibly, local = local, print.eval = output, :
/tmp/gpstime.R!CuSewT:2:0: unexpected end of input
1: secsToRDateTime <- function(secs) {
^
As I said, there are no problems when the script is run from my
home directory. This suggests that test scripts can no longer be
tested in a package's R directory?
Is this true?
Thanks,
Dominick
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installation of R-4.3.1 with intel 2022
Hi all,
I have the issue:
icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I.
-I../../src/include -I../../src/include -I/usr/local/include -I../../src/nmath
-DHAVE_CONFIG_H -fopenmp -fpic -g -O3 -wd188 -ip -mp -c eval.c -o eval.o
arithmetic.c(66): warning #274: declaration is not visible outside of function
int matherr(struct exception *exc)
^
arithmetic.c(68): error: pointer to incomplete class type is not allowed
switch (exc->type) {
^
arithmetic.c(69): error: identifier "DOMAIN" is undefined
case DOMAIN:
^
arithmetic.c(70): error: identifier "SING" is undefined
case SING:
^
arithmetic.c(73): error: identifier "OVERFLOW" is undefined
case OVERFLOW:
^
arithmetic.c(76): error: identifier "UNDERFLOW" is undefined
case UNDERFLOW:
^
arithmetic.c(77): error: pointer to incomplete class type is not allowed
exc->retval = 0.0;
icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I.
-I../../src/include -I../../src/include -I/usr/local/include -I../../src/nmath
-DHAVE_CONFIG_H -fopenmp -fpic -g -O3 -wd188 -ip -mp -c flexiblas.c -o
flexiblas.o
icc: command line remark #10148: option '-mp' not supported
compilation aborted for arithmetic.c (code 2)
make[3]: *** [../../Makeconf:129: arithmetic.o] Error 2
make[3]: *** Waiting for unfinished jobs
icc: command line remark #10148: option '-mp' not supported
make[3]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[2]: *** [Makefile:140: R] Error 2
make[2]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src'
make: *** [Makefile:62: R] Error 1
with oneapi-2022.1.0/compiler-rt/2022.1.0; oneapi-2022.1.0/mkl/2022.1.0 while
building R-4.3.1 on redhat 8.4 glibc2.28-189
I followed a workaround proposed:
https://community.intel.com/t5/Intel-C-Compiler/Error-when-compiling-R-from-source-code-ubuntu-18-04/m-p/1176401/thread-id/36575
Deactivate HAVE_MATHERR macro in src/include/config.h
Using this workaroud I get R with:
BLAS/LAPACK:
/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2;
LAPACK version 3.9.0
is correct?
Is these a way to avoid arithmetic issue?
My configure is:
module load intel-2021.6.0/2021.6.0 oneapi-2022.1.0/mkl
MKL="-L${MKLROOT}/lib/intel64 -lmkl_gf_lp64 -lmkl_core -lmkl_gnu_thread -dl
-fopenmp"
export CC="icc -std=c99"
export CFLAGS="-g -O3 -wd188 -ip -mp"
export FC=ifort
export FLAGS="-g -O3 -mp"
export CXX=icpc
export CXXFLAGS="-g -O3 -mp"
SHLIB_CXXLD=icpc
export MKL_INTERFACE_LAYER=GNU,LP64
export MKL_THREADING_LAYER=GNU
./configure --prefix=/opt/intel-2021.6.0/R/4.3.1 --with-blas="$MKL"
--with-lapack --enable-memory-profiling --enable-BLAS-shlib --enable-R-shlib
--enable-R-static-lib --with-pcre2
Thanks a lot,
Giuseppe.
———
Giuseppe Calò
Fondazione CMCC
Centro Euro-Mediterraneo sui Cambiamenti Climatici presso Complesso Ecotekne
Università del Salento - Strada Prov.le Lecce - Monteroni 73100 Lecce IT
http://www.cmcc.it
Re: [R-pkg-devel] Change package name
On 20.06.2023 18:00, Dirk Eddelbuettel wrote: Hi William, On 20 June 2023 at 16:06, William Becker wrote: | I am the maintainer of a package which is unfortunately involved in a complicated dispute regarding its intellectual property (since the package was partly built under a contract with an organisation), but also the "branding" of the package, i.e. the name. | | The story is long and complicated, but suffice to say that the name of the package is apparently creating a misleading connection with the organisation, and this is causing difficulties on both sides. | | I am aware that changing the name of a package is very disruptive, and I am not considering it lightly. However just for information at this stage, I wonder if anyone could tell me whether packages have ever changed names on CRAN, what the rules are in these cases, and if there is any advice for minimising the disruption. | | To reiterate, I am not (yet) planning to do this, but exploring options and looking for advice. You presented the reasoning convincingly and are aware of the general "we would rather not do this" sentiment. Ultimately, this (as so often) is CRAN's call so you have to do that (directly and not via this list). My sense is that you have a case but only CRAN can tell. Yes, CRAN will accept this case. Best, Uwe Ligges Good luck, Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Change package name
I second Dirk's suggestion to address this issue directly to CRAN. I had one of my packages changed once from "Reot" to "remote" (which enables calculation of empirical orthogonal teleconnections as introduced by van den Dool 2000) and had to present some convincing arguments to do so (in quite a long email conversation). The point that finally convinced CRAN in my case was that a reviewer of the complementing publication about the package in jss requested that name change as Reot could easily be misinterpreted as rotated eot, analogous to EOF and rotated EOF. And jss apparently has the policy to only publish papers about packages available from CRAN. So, as Dirk said, it is possible to convince CRAN, but you need good arguments. Best Tim On Tue, Jun 20, 2023, 18:00 Dirk Eddelbuettel wrote: > > Hi William, > > On 20 June 2023 at 16:06, William Becker wrote: > | I am the maintainer of a package which is unfortunately involved in a > complicated dispute regarding its intellectual property (since the package > was partly built under a contract with an organisation), but also the > "branding" of the package, i.e. the name. > | > | The story is long and complicated, but suffice to say that the name of > the package is apparently creating a misleading connection with the > organisation, and this is causing difficulties on both sides. > | > | I am aware that changing the name of a package is very disruptive, and I > am not considering it lightly. However just for information at this stage, > I wonder if anyone could tell me whether packages have ever changed names > on CRAN, what the rules are in these cases, and if there is any advice for > minimising the disruption. > | > | To reiterate, I am not (yet) planning to do this, but exploring options > and looking for advice. > > You presented the reasoning convincingly and are aware of the general "we > would rather not do this" sentiment. Ultimately, this (as so often) is > CRAN's > call so you have to do that (directly and not via this list). My sense is > that you have a case but only CRAN can tell. > > Good luck, 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] Change package name
Hi William, On 20 June 2023 at 16:06, William Becker wrote: | I am the maintainer of a package which is unfortunately involved in a complicated dispute regarding its intellectual property (since the package was partly built under a contract with an organisation), but also the "branding" of the package, i.e. the name. | | The story is long and complicated, but suffice to say that the name of the package is apparently creating a misleading connection with the organisation, and this is causing difficulties on both sides. | | I am aware that changing the name of a package is very disruptive, and I am not considering it lightly. However just for information at this stage, I wonder if anyone could tell me whether packages have ever changed names on CRAN, what the rules are in these cases, and if there is any advice for minimising the disruption. | | To reiterate, I am not (yet) planning to do this, but exploring options and looking for advice. You presented the reasoning convincingly and are aware of the general "we would rather not do this" sentiment. Ultimately, this (as so often) is CRAN's call so you have to do that (directly and not via this list). My sense is that you have a case but only CRAN can tell. Good luck, 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
[Bioc-devel] Single Package Build Machines Update
Hi, The build machines used for single package submissions will be updated today so they will be temporarily unavailable until 1pm. Thanks for your understanding. Jennifer Wokaty (they/them) Waldron Lab at CUNY SPH Bioconductor Core Team [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[R-pkg-devel] Change package name
Dear All, I am the maintainer of a package which is unfortunately involved in a complicated dispute regarding its intellectual property (since the package was partly built under a contract with an organisation), but also the "branding" of the package, i.e. the name. The story is long and complicated, but suffice to say that the name of the package is apparently creating a misleading connection with the organisation, and this is causing difficulties on both sides. I am aware that changing the name of a package is very disruptive, and I am not considering it lightly. However just for information at this stage, I wonder if anyone could tell me whether packages have ever changed names on CRAN, what the rules are in these cases, and if there is any advice for minimising the disruption. To reiterate, I am not (yet) planning to do this, but exploring options and looking for advice. Thanks for any help, William William Becker PhD willbecker.me https://www.willbecker.me/ [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] Urgent minor deployment of a release?
On Tue, Jun 20, 2023 at 1:34 AM Henrik Bengtsson
wrote:
> On Mon, Jun 19, 2023 at 5:46 PM Vincent Carey
> wrote:
> >
> > Hi Adam, thanks for your note.
> >
> > Changes to release branch sources must be limited to bug fixes or doc
> > improvement. Any new features
> > must be introduced only in the devel branch.
>
> I know about this, but I wanted to find what the document exactly says
> about this. I'm sure it's documented somewhere, but I just spend 10-15
>
I agree with your conclusion here. I don't think this is documented in the
contributions.bioconductor.org. I am sorry about the 15 minutes, I should
have commented when I responded that we need to improve the doc
on this.
> min on the website trying, but I couldn't find it. What I was looking
> specifically for was "new features". For instance, would one be
> allowed to introduce a 100% backward compatible new features to the
> Bioc release branch? For instance, assume you currently have
>
> h <- function(x, ...) {
> sum(x)
> }
>
> in the release branch, would it be okay to add:
>
> h <- function(x, na.rm = FALSE, ...) {
> sum(x, na.rm = na.rm)
> }
>
> ? This is how base-R itself does it in their patch releases, e.g. R
> 4.3.0 -> R 4.3.1.
>
The intent is that the APIs for packages in the release branch be "stable".
Let's discuss how to formalize and document this intent.
>
> /Henrik
>
> > Any features to be removed
> > must be indicated as
> > deprecated for one release and then labeled as defunct. See
> >
> > http://contributions.bioconductor.org/deprecation.html
> >
> > for guidan
> > Changes to release branch sources must be limited to bug fixes or doc
> > improvement.
> > ce on feature removal.
> >
> >
> > On Mon, Jun 19, 2023 at 10:11 AM Park, Adam Keebum
> > wrote:
> >
> > > Hi all,
> > >
> > > I wonder if there is any room for deploying a modification to a
> released
> > > library(retrofit, 3.17), which was released last month.
> > >
> > > We are in a progress of a paper review, so the release schedule (twice
> > > each year) does not perfectly fit our need.
> > >
> > > Or do you think we should have used "devel" for such purposes?
> > >
> > > Sincerely,
> > > Adam.
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >
> >
> > --
> > The information in this e-mail is intended only for the ...{{dropped:18}}
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
--
The information in this e-mail is intended only for the ...{{dropped:18}}
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] https://cran.r-project.org/src/base-prerelease/ is not updating
To be more precise, the thing that happened was that Simon had changed the installation directory for texi2any with the 4.3.0 Mac binaries. The release manager (me) needed to update materials for Mon-Wed oral exams, so upgraded to a recent prerelease. This broke the nightly builds because it would no longer build the FAQ and RESOURCES files. Being busy with exams, I didn't notice until Gábor chimed in. Fortunately, there was still a little time before release so that I could fix up the situation. So, thank you very much to Gábor! To everyone: It is very helpful if you keep an eye on such matters, not only for testing whether we fixed your favourite bug, but also because the whole prerelease regime can be a bit brittle. R Core only has a limited set of (aging!) eyes and we may all become distracted by our regular chores. - Peter D. > On 15 Jun 2023, at 18:23 , peter dalgaard wrote: > > Yes that was not intentional. Unexpected interaction between installed R > version and build tools. Should be OK now. > > -pd > >> On 14 Jun 2023, at 14:57 , Gábor Csárdi wrote: >> >> https://cran.r-project.org/src/base-prerelease/ has not updated for >> about a week now, I guess this is not intentional? >> >> Best, >> Gabor >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
