Re: [R-pkg-devel] What counts as an API change?

[Hugh Parsonage]

> The approach I take is a major version increment is required if it
> requires an existing unit test to be changed or if it requires a reverse
> dependency to change a unit test.
>
> (With the exception of tests marked explicitly as unstable.)
>
> In my view the test suite is a good way to advertise exactly what
> developers can rely on in minor version upgrades.
>
> On Wed, 25 Sep 2019 at 11:52 pm, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
>
>> Hi all,
>>
>> Philosophical question. My package follows semantic versioning (
>> https://semver.org). Incompatible API changes should trigger a major
>> version upgrade. OK, but what counts as an incompatible change to an R
>> API?
>> Suppose my current function signature is
>>
>> foo <- function (a, b, c, d)
>>
>> and the new one is
>>
>> foo <- function (a, b, c, d, e)
>>
>> is that compatible? What if I add an argument, but not at the end:
>>
>> foo <- function (a, b, c, e, d)
>>
>> That would be incompatible if people have been calling the arguments by
>> order rather than by name. But sometimes that is unlikely: I doubt if many
>> people write
>>
>> lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE, FALSE)
>>
>> Should I be strict or relaxed about this?
>>
>> Cheers,
>> David
>>
>> [[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 counts as an API change?

[Jeff Newmiller]

No "maybe" about it.

On September 25, 2019 2:28:27 PM PDT, David Hugh-Jones 
 wrote:
>Thanks Jeff. My function is currently:
>
>insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)
>
>and I want to add a `fill` argument:
>
>insert_column <- function (ht, ..., after = 0, fill = NULL,
>copy_cell_props
>= TRUE)
>
>This is definitely the best place for the fill argument - I wouldn't
>like
>to put it after copy_cell_props.
>
>Actually, thinking about it, both after and copy_cell_props have to be
>named arguments, given the position of ... . So maybe this is my get
>out of
>jail free card. If I add "fill", existing function calls won't break,
>and I
>can call this "adding functionality in a backwards-compatible manner".
>
>David
>
>
>On Wed, 25 Sep 2019 at 17:26, Jeff Newmiller 
>wrote:
>
>> "assume default values are provided."
>>
>> Ah, no. Choosing to specify or not specify default values is a
>critical
>> step. As is deciding where any ... argument will be placed (all
>specific
>> arguments after that have to be named when called so positional
>> compatibility cannot come back to bite you).
>>
>> "I wonder if it always matters"
>>
>> That would depend on the relationship you plan to maintain with users
>of
>> your package. Still, sometimes breaking changes are necessary for a
>better
>> future.
>>
>> I think the definition of breaking is pretty clear if you are precise
>in
>> your argument lists. (R CMD check is very helpful in pestering you to
>> document your arguments, so you do have the opportunity to be precise
>in
>> your API definition.) It is really bad to have silent changes in
>behavior,
>> and precision in specification is crucial to avoid that if you
>distribute
>> packages.
>>
>> On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >Hi Jeff,
>> >
>> >You're right. Indeed, assume default values are provided. I should
>have
>> >been more precise.
>> >
>> >I understand that the positional behaviour has changed. But I wonder
>if
>> >it
>> >always matters. OTOH I appreciate the force of the idea that an API
>> >change
>> >is an API change, and should be defined precisely.
>> >
>> >Best,
>> >David
>> >
>> >
>> >On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller
>
>> >wrote:
>> >
>> >> Both of your examples are incompatible.
>> >>
>> >> foo <- function (a, b, c, d, e = NA )
>> >>
>> >> (add with default value) would be compatible.
>> >>
>> >> Your second example cannot be made compatible even with default
>> >values
>> >> because the positional behaviour has changed.
>> >>
>> >> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
>> >> davidhughjo...@gmail.com> wrote:
>> >> >Hi all,
>> >> >
>> >> >Philosophical question. My package follows semantic versioning (
>> >> >https://semver.org). Incompatible API changes should trigger a
>major
>> >> >version upgrade. OK, but what counts as an incompatible change to
>an
>> >R
>> >> >API?
>> >> >Suppose my current function signature is
>> >> >
>> >> >foo <- function (a, b, c, d)
>> >> >
>> >> >and the new one is
>> >> >
>> >> >foo <- function (a, b, c, d, e)
>> >> >
>> >> >is that compatible? What if I add an argument, but not at the
>end:
>> >> >
>> >> >foo <- function (a, b, c, e, d)
>> >> >
>> >> >That would be incompatible if people have been calling the
>arguments
>> >by
>> >> >order rather than by name. But sometimes that is unlikely: I
>doubt
>> >if
>> >> >many
>> >> >people write
>> >> >
>> >> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE,
>TRUE,
>> >> >FALSE)
>> >> >
>> >> >Should I be strict or relaxed about this?
>> >> >
>> >> >Cheers,
>> >> >David
>> >> >
>> >> >   [[alternative HTML version deleted]]
>> >> >
>> >> >__
>> >> >R-package-devel@r-project.org mailing list
>> >> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >>
>> >> --
>> >> Sent from my phone. Please excuse my brevity.
>> >>
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] What counts as an API change?

[David Hugh-Jones]

Thanks Jeff. My function is currently:

insert_column <- function (ht, ..., after = 0, copy_cell_props = TRUE)

and I want to add a `fill` argument:

insert_column <- function (ht, ..., after = 0, fill = NULL, copy_cell_props
= TRUE)

This is definitely the best place for the fill argument - I wouldn't like
to put it after copy_cell_props.

Actually, thinking about it, both after and copy_cell_props have to be
named arguments, given the position of ... . So maybe this is my get out of
jail free card. If I add "fill", existing function calls won't break, and I
can call this "adding functionality in a backwards-compatible manner".

David


On Wed, 25 Sep 2019 at 17:26, Jeff Newmiller 
wrote:

> "assume default values are provided."
>
> Ah, no. Choosing to specify or not specify default values is a critical
> step. As is deciding where any ... argument will be placed (all specific
> arguments after that have to be named when called so positional
> compatibility cannot come back to bite you).
>
> "I wonder if it always matters"
>
> That would depend on the relationship you plan to maintain with users of
> your package. Still, sometimes breaking changes are necessary for a better
> future.
>
> I think the definition of breaking is pretty clear if you are precise in
> your argument lists. (R CMD check is very helpful in pestering you to
> document your arguments, so you do have the opportunity to be precise in
> your API definition.) It is really bad to have silent changes in behavior,
> and precision in specification is crucial to avoid that if you distribute
> packages.
>
> On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >Hi Jeff,
> >
> >You're right. Indeed, assume default values are provided. I should have
> >been more precise.
> >
> >I understand that the positional behaviour has changed. But I wonder if
> >it
> >always matters. OTOH I appreciate the force of the idea that an API
> >change
> >is an API change, and should be defined precisely.
> >
> >Best,
> >David
> >
> >
> >On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller 
> >wrote:
> >
> >> Both of your examples are incompatible.
> >>
> >> foo <- function (a, b, c, d, e = NA )
> >>
> >> (add with default value) would be compatible.
> >>
> >> Your second example cannot be made compatible even with default
> >values
> >> because the positional behaviour has changed.
> >>
> >> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
> >> davidhughjo...@gmail.com> wrote:
> >> >Hi all,
> >> >
> >> >Philosophical question. My package follows semantic versioning (
> >> >https://semver.org). Incompatible API changes should trigger a major
> >> >version upgrade. OK, but what counts as an incompatible change to an
> >R
> >> >API?
> >> >Suppose my current function signature is
> >> >
> >> >foo <- function (a, b, c, d)
> >> >
> >> >and the new one is
> >> >
> >> >foo <- function (a, b, c, d, e)
> >> >
> >> >is that compatible? What if I add an argument, but not at the end:
> >> >
> >> >foo <- function (a, b, c, e, d)
> >> >
> >> >That would be incompatible if people have been calling the arguments
> >by
> >> >order rather than by name. But sometimes that is unlikely: I doubt
> >if
> >> >many
> >> >people write
> >> >
> >> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
> >> >FALSE)
> >> >
> >> >Should I be strict or relaxed about this?
> >> >
> >> >Cheers,
> >> >David
> >> >
> >> >   [[alternative HTML version deleted]]
> >> >
> >> >__
> >> >R-package-devel@r-project.org mailing list
> >> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> Sent from my phone. Please excuse my brevity.
> >>
>
> --
> Sent from my phone. Please excuse my brevity.
>

[[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 reproduce CRAN check

[Tomas Kalibera]

On 9/17/19 6:17 PM, Cristiane Hayumi Taniguti wrote:

Hello, thanks for all the answers.

I did the new tests with all suggestions.

I included the Rprintf in my script, however it did not show any NaN when
running with my examples (the same that CRAN check pointed the error)


The approach of adding a runtime check looking for NaNs should work. You 
can reproduce the problem (extracted from the vignette for which the 
CRAN checks report NaNs, tested on the CRAN version of the package):


---

library(onemap)
data("onemap_example_f2")
data("vcf_example_f2")
comb_example <- combine_onemap(onemap_example_f2, vcf_example_f2)
twopts_f2 <- rf_2pts(comb_example)
mark_all_f2 <- make_seq(twopts_f2, "all")

CHR_mks <- group_seq(input.2pts = twopts_f2, seqs = "CHROM", unlink.mks 
= mark_all_f2,

  repeated = FALSE)

---

With a smaller example like this, it is easier to iterate using added 
runtime checks. Also it is easier to debug as one can have it in an 
interactive R session.


Now one can check the "geno" vector before passed to the range 
constructor of std::vector, you will see it has "NaNs" as reported 
by UBSAN. One way to check is just add a function to the code that 
searches the vector and prints a message, and call it before the line 
indicated in the UBSAN reports


std::vector k_sub([i*n_ind],[i*n_ind+n_ind]);

It turns out that when there is an NaN in the vector, all values are 
NaN. So it is natural to continue debugging in the surrounding R code. 
It turns out that  est_rf_f2 in cpp_utils.R sometimes gets called with a 
vector of integers (not doubles) and this vector has NAs, which are 
later converted to NaN.


So perhaps you could continue debugging from there using the R debugger 
and in an interactive session, and it might make sense to add some 
diagnostics to the C code to make it easier to debug similar problems 
later if they appear. At least it would be worth checking the type of 
the argument, this is fast and would detect that the type is integer 
instead of double. But perhaps it might make sense to check validity 
even of the individual elements.


Best
Tomas




The check in r-hub Debian Linux, R-devel, GCC ASAN/UBSAN
(linux-x86_64-rocker-gcc-san) did not show the error.

The r-debug seems to be a good tool, but I had problems to build my package
on it. First, the library libglu1-mesa-dev was missing for rgl package
installation, then, I installed it, but I  found the following errors when
trying to install the required MDSMap package:

"Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING."
and
"/usr/bin/ld: cannot find -lgfortran"

I did the modifications in rcpp files (update here<
https://github.com/Cristianetaniguti/onemap/commit/8d90eab994c9c5cc56202c2c15c5eae7c639315b>),
but I still can not test the package with it. Would be a problem if I
submit anyway?

On Fri, Sep 13, 2019 at 12:35 PM Iñaki Ucar  wrote:


On Fri, 13 Sep 2019 at 16:16, Cristiane Hayumi Taniguti
 wrote:

...twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'

Here:
https://github.com/augusto-garcia/onemap/blob/master/src/twopts_f2.cpp#L101
-> k1=segreg_type(i); k2=segreg_type(j);

k1 and k2 are vectors of integers, but segreg_type is a NumericVector
(double), which may contain NaN.

Iñaki


[[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] unicode WARNING on solaris?

[Tomas Kalibera]

On 9/25/19 7:59 PM, Toby Hocking wrote:
> Hi Tomas thanks for the explanation. Does that mean that there is no 
> known fix? i.e. it is OK to re-submit a new version of my package 
> without fixing these WARNINGS?

One way to fix would be to remove non-ASCII characters from the 
examples. I see \u4e8c \u4e09 \U0001F60E.
Tomas

>
> On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 9/24/19 1:57 AM, Toby Hocking wrote:
> > Hi all,
> >
> > is there a known fix for this WARNING which I am getting on
> solaris for my
> > newly submitted nc package?
> >
> 
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
>
> It seems that deparse() came across some non-printable characters.
> Such
> characters would be replaced by \U or \u escapes. This is implemented
> using wide characters in R, but on that platform
> __STDC_ISO_10646__ is
> not defined, so wchar_t has unknown representation (not known to be
> Unicode), hence the warning.
>
> Best
> Tomas
>
> >
> > A quick google search for "it is not known that wchar_t is
> Unicode on this
> > platform cran" shows that many other packages have this WARNING
> as well.
> >
> > I searched r-devel and r-pkg-devel for the warning text but I
> did not find
> > any messages discussing a fix.
> >
> > Thanks for any help
> > Toby
> >
> >       [[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] unicode WARNING on solaris?

[Toby Hocking]

Hi Tomas thanks for the explanation. Does that mean that there is no known
fix? i.e. it is OK to re-submit a new version of my package without fixing
these WARNINGS?

On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera 
wrote:

> On 9/24/19 1:57 AM, Toby Hocking wrote:
> > Hi all,
> >
> > is there a known fix for this WARNING which I am getting on solaris for
> my
> > newly submitted nc package?
> >
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
>
> It seems that deparse() came across some non-printable characters. Such
> characters would be replaced by \U or \u escapes. This is implemented
> using wide characters in R, but on that platform __STDC_ISO_10646__ is
> not defined, so wchar_t has unknown representation (not known to be
> Unicode), hence the warning.
>
> Best
> Tomas
>
> >
> > A quick google search for "it is not known that wchar_t is Unicode on
> this
> > platform cran" shows that many other packages have this WARNING as well.
> >
> > I searched r-devel and r-pkg-devel for the warning text but I did not
> find
> > any messages discussing a fix.
> >
> > Thanks for any help
> > Toby
> >
> >   [[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 counts as an API change?

[Jeff Newmiller]

"assume default values are provided."

Ah, no. Choosing to specify or not specify default values is a critical step. 
As is deciding where any ... argument will be placed (all specific arguments 
after that have to be named when called so positional compatibility cannot come 
back to bite you).

"I wonder if it always matters"

That would depend on the relationship you plan to maintain with users of your 
package. Still, sometimes breaking changes are necessary for a better future.

I think the definition of breaking is pretty clear if you are precise in your 
argument lists. (R CMD check is very helpful in pestering you to document your 
arguments, so you do have the opportunity to be precise in your API 
definition.) It is really bad to have silent changes in behavior, and precision 
in specification is crucial to avoid that if you distribute packages.

On September 25, 2019 7:27:25 AM PDT, David Hugh-Jones 
 wrote:
>Hi Jeff,
>
>You're right. Indeed, assume default values are provided. I should have
>been more precise.
>
>I understand that the positional behaviour has changed. But I wonder if
>it
>always matters. OTOH I appreciate the force of the idea that an API
>change
>is an API change, and should be defined precisely.
>
>Best,
>David
>
>
>On Wed, 25 Sep 2019 at 15:01, Jeff Newmiller 
>wrote:
>
>> Both of your examples are incompatible.
>>
>> foo <- function (a, b, c, d, e = NA )
>>
>> (add with default value) would be compatible.
>>
>> Your second example cannot be made compatible even with default
>values
>> because the positional behaviour has changed.
>>
>> On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones <
>> davidhughjo...@gmail.com> wrote:
>> >Hi all,
>> >
>> >Philosophical question. My package follows semantic versioning (
>> >https://semver.org). Incompatible API changes should trigger a major
>> >version upgrade. OK, but what counts as an incompatible change to an
>R
>> >API?
>> >Suppose my current function signature is
>> >
>> >foo <- function (a, b, c, d)
>> >
>> >and the new one is
>> >
>> >foo <- function (a, b, c, d, e)
>> >
>> >is that compatible? What if I add an argument, but not at the end:
>> >
>> >foo <- function (a, b, c, e, d)
>> >
>> >That would be incompatible if people have been calling the arguments
>by
>> >order rather than by name. But sometimes that is unlikely: I doubt
>if
>> >many
>> >people write
>> >
>> >lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
>> >FALSE)
>> >
>> >Should I be strict or relaxed about this?
>> >
>> >Cheers,
>> >David
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> >__
>> >R-package-devel@r-project.org mailing list
>> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] Resubmitting after a few days

[Roy Mendelssohn - NOAA Federal via R-package-devel]

Thanks all.  I asked because I don't want to unnecessarily overburden the CRAN 
maintainers.  In this case,  it wasn't a minor bug.

-Roy

> On Sep 25, 2019, at 4:36 AM, Dirk Eddelbuettel  wrote:
> 
> 
> On 24 September 2019 at 11:43, Roy Mendelssohn - NOAA Federal via 
> R-package-devel wrote:
> | A few days ago I  had to resubmit because an external URL I was using in my 
> vignette changed and the nightly builds were issuing warnings.  This morning 
> a user reported a bug.  I have the fix and a new version,  but the test 
> machines,  and I suppose it will also be true of CRAN,  are unhappy about the 
> interval since last submit.  Should I just submit the new version anyway with 
> a note in cram-comments that this is a bug fix.
> 
> Yes: AFAICT these are recommendations to not overburden CRAN.
> 
> And I have hit two distinct types:
> 
> - more than six uploads in six months (which happened when an upstream
>   package was hyperactive) which lead me to space uploads out a little more
>   as "one a month should be plenty" indeed
> 
> - less than seven days since the last upload (which lead me to just wait two
>   days on a very recent "better bug fix to a bug fix" upload I made, and
>   then got me the very automated processing)
> 
> You can look in the R sources for what the cutoffs are (which is how I
> confirmed it was 7) and act accordingly.  So yes, in sum, explain what you do
> to CRAN -- and some human will generally do the Right Thing.
> 
> (And big thanks and kudos to CRAN for the increased automation documented in
> the short update at the end of the most recent R Journal issue. Very
> impressive, and very well done.)
> 
> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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

Re: [R-pkg-devel] What counts as an API change?

[Jeff Newmiller]

Both of your examples are incompatible.

foo <- function (a, b, c, d, e = NA )

(add with default value) would be compatible.

Your second example cannot be made compatible even with default values because 
the positional behaviour has changed.

On September 25, 2019 6:51:58 AM PDT, David Hugh-Jones 
 wrote:
>Hi all,
>
>Philosophical question. My package follows semantic versioning (
>https://semver.org). Incompatible API changes should trigger a major
>version upgrade. OK, but what counts as an incompatible change to an R
>API?
>Suppose my current function signature is
>
>foo <- function (a, b, c, d)
>
>and the new one is
>
>foo <- function (a, b, c, d, e)
>
>is that compatible? What if I add an argument, but not at the end:
>
>foo <- function (a, b, c, e, d)
>
>That would be incompatible if people have been calling the arguments by
>order rather than by name. But sometimes that is unlikely: I doubt if
>many
>people write
>
>lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE,
>FALSE)
>
>Should I be strict or relaxed about this?
>
>Cheers,
>David
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

[R-pkg-devel] What counts as an API change?

[David Hugh-Jones]

Hi all,

Philosophical question. My package follows semantic versioning (
https://semver.org). Incompatible API changes should trigger a major
version upgrade. OK, but what counts as an incompatible change to an R API?
Suppose my current function signature is

foo <- function (a, b, c, d)

and the new one is

foo <- function (a, b, c, d, e)

is that compatible? What if I add an argument, but not at the end:

foo <- function (a, b, c, e, d)

That would be incompatible if people have been calling the arguments by
order rather than by name. But sometimes that is unlikely: I doubt if many
people write

lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE, FALSE)

Should I be strict or relaxed about this?

Cheers,
David

[[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] Package or namespace load failed: undefined symbol

[Sameh M. Abdulah]

Dear   Ralf

My package depends on another C-based software that needs LAPACKE to compile. I 
do not know a lot about it. I think adding LAPACKE to my package will be a good 
solution.
Could you please give me more information of how to do this?

--Sameh



On 9/25/19, 2:00 PM, "Ralf Stubner"  wrote:

On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
 wrote:
> I am installing OpenBLAS because I need LAPACKE libraries which I cannot 
find on the current version of OpenBLAS on CRAN.
>
> I add the libraries directory in my package to the PKG_CONFIG_PATH. Is 
this enough for the system to use my OpenBLAS library?

I seem to be missing some context here. I might be able to help you if
provide a higher level description of what you are trying to achieve.
For example, why do you need LAPACKE instead of the C interface to
LAPACK provided by R_ext/Lapack.h? And if you really need LAPACKE, why
not include only that in your package and link with the BLAS/LAPACK
used by R?

cheerio
ralf


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

Re: [R-pkg-devel] Resubmitting after a few days

[Dirk Eddelbuettel]

On 24 September 2019 at 11:43, Roy Mendelssohn - NOAA Federal via 
R-package-devel wrote:
| A few days ago I  had to resubmit because an external URL I was using in my 
vignette changed and the nightly builds were issuing warnings.  This morning a 
user reported a bug.  I have the fix and a new version,  but the test machines, 
 and I suppose it will also be true of CRAN,  are unhappy about the interval 
since last submit.  Should I just submit the new version anyway with a note in 
cram-comments that this is a bug fix.

Yes: AFAICT these are recommendations to not overburden CRAN.

And I have hit two distinct types:

 - more than six uploads in six months (which happened when an upstream
   package was hyperactive) which lead me to space uploads out a little more
   as "one a month should be plenty" indeed

 - less than seven days since the last upload (which lead me to just wait two
   days on a very recent "better bug fix to a bug fix" upload I made, and
   then got me the very automated processing)

You can look in the R sources for what the cutoffs are (which is how I
confirmed it was 7) and act accordingly.  So yes, in sum, explain what you do
to CRAN -- and some human will generally do the Right Thing.

(And big thanks and kudos to CRAN for the increased automation documented in
the short update at the end of the most recent R Journal issue. Very
impressive, and very well done.)

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

Re: [R-pkg-devel] Package or namespace load failed: undefined symbol

[Tomas Kalibera]

On 9/25/19 1:00 PM, Ralf Stubner wrote:

On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
 wrote:

I am installing OpenBLAS because I need LAPACKE libraries which I cannot find 
on the current version of OpenBLAS on CRAN.

I add the libraries directory in my package to the PKG_CONFIG_PATH. Is this 
enough for the system to use my OpenBLAS library?

I seem to be missing some context here. I might be able to help you if
provide a higher level description of what you are trying to achieve.
For example, why do you need LAPACKE instead of the C interface to
LAPACK provided by R_ext/Lapack.h? And if you really need LAPACKE, why
not include only that in your package and link with the BLAS/LAPACK
used by R?


Also with LAPACKE you will have the problem of (in)compatibility in 
calls from C to Fortran with the hidden length arguments for character 
arguments. It would be better to use LAPACK directly, passing the hidden 
length arguments as described in Writing R Extensions (the R-devel 
version of it, section 6.6.1). Or, if you wanted a standards-based 
solution, use iso_c_binding (also described in WRE). You would use the 
LAPACK already provided in the system (either reference from R, or any 
other as selected by administrator/user), not include it with your package.


Best
Tomas



cheerio
ralf

__
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] Package or namespace load failed: undefined symbol

[Ralf Stubner]

On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
 wrote:
> I am installing OpenBLAS because I need LAPACKE libraries which I cannot find 
> on the current version of OpenBLAS on CRAN.
>
> I add the libraries directory in my package to the PKG_CONFIG_PATH. Is this 
> enough for the system to use my OpenBLAS library?

I seem to be missing some context here. I might be able to help you if
provide a higher level description of what you are trying to achieve.
For example, why do you need LAPACKE instead of the C interface to
LAPACK provided by R_ext/Lapack.h? And if you really need LAPACKE, why
not include only that in your package and link with the BLAS/LAPACK
used by R?

cheerio
ralf

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

Re: [R-pkg-devel] Resubmitting after a few days

[Helmut Schütz]

Hi Roy,

Roy Mendelssohn - NOAA Federal via R-package-devel wrote on 2019-09-24 
20:43:
> Hi All:
>
> A few days ago I  had to resubmit because an external URL I was using in my 
> vignette changed and the nightly builds were issuing warnings.  This morning 
> a user reported a bug.  I have the fix and a new version,  but the test 
> machines,  and I suppose it will also be true of CRAN,  are unhappy about the 
> interval since last submit.

They will. ;-)

> Should I just submit the new version anyway with a note in cram-comments that 
> this is a bug fix.

Absolutely. The one-month interval for new versions is a *recommendation*.
If a bug has to be fixed, go for it -- together with an explanation.
Happened to me once as well (new version correcting a bug after two days).
IIRC, Hadley had to submit a new version of one of his packages after 
three days. Murphy's law.

Cheers,
Helmut

-- 
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
1070 Vienna, Austria
W https://bebac.at/
F https://forum.bebac.at/


[[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] Package or namespace load failed: undefined symbol

[Sameh M. Abdulah]

Thanks Ralf

I am installing OpenBLAS because I need LAPACKE libraries which I cannot find 
on the current version of OpenBLAS on CRAN. 

I add the libraries directory in my package to the PKG_CONFIG_PATH. Is this 
enough for the system to use my OpenBLAS library?


Thanks
Sameh

On 9/25/19, 10:23 AM, "Ralf Stubner"  wrote:

On Tue, Sep 24, 2019 at 12:10 PM Sameh M. Abdulah
 wrote:
> I am uploading my R package to CRAN. One of the dynamic libraries the 
package requires depends on LAPACKE library which usually integrated with BLAS 
and CBLAS in the same .so file (as I understand). CRAN has OpenBLAS already 
installed on the system. However, this OpenBLAS library does not maintain 
implementation of LAPACKE library. Thus, I have modified my configure file to 
install a standalone OpenBLAS library to use it.
>
> The problem that my installation has successfully passed, however, CRAN 
fails in loading my package giving me this error:
>
> /srv/hornik/tmp/CRAN/exageostatr.Rcheck/exageostatr/lib/libcoreblas.so: 
undefined symbol: LAPACKE_slarfb_work

This looks as if you are building OpenBLAS as a /dynamic/ library
installed in your package directory. This cannot work since the
run-time linker will not search your package directory for dynamic
libraries. You could build OpenBLAS as a /static/ library instead.
However, I am unsure why you want to build OpenBLAS in the first
place, since any R package can reliably link with the BLAS and LAPACK
versions used by R. See WRE on Makevars, BLAS_LIBS etc. for details.

cheerio
ralf


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

Re: [R-pkg-devel] Package or namespace load failed: undefined symbol

[Ralf Stubner]

On Tue, Sep 24, 2019 at 12:10 PM Sameh M. Abdulah
 wrote:
> I am uploading my R package to CRAN. One of the dynamic libraries the package 
> requires depends on LAPACKE library which usually integrated with BLAS and 
> CBLAS in the same .so file (as I understand). CRAN has OpenBLAS already 
> installed on the system. However, this OpenBLAS library does not maintain 
> implementation of LAPACKE library. Thus, I have modified my configure file to 
> install a standalone OpenBLAS library to use it.
>
> The problem that my installation has successfully passed, however, CRAN fails 
> in loading my package giving me this error:
>
> /srv/hornik/tmp/CRAN/exageostatr.Rcheck/exageostatr/lib/libcoreblas.so: 
> undefined symbol: LAPACKE_slarfb_work

This looks as if you are building OpenBLAS as a /dynamic/ library
installed in your package directory. This cannot work since the
run-time linker will not search your package directory for dynamic
libraries. You could build OpenBLAS as a /static/ library instead.
However, I am unsure why you want to build OpenBLAS in the first
place, since any R package can reliably link with the BLAS and LAPACK
versions used by R. See WRE on Makevars, BLAS_LIBS etc. for details.

cheerio
ralf

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