> 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 adverti
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 = NU
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 woul
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 add
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 \u4
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 kno
"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
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:
> |
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 precise
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-Jone
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
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" wro
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 v
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 thi
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
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
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
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
> insta
18 matches
Mail list logo