Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

[Aaron Lun]

well, we can't fix this in old branches of Bioc.


Sure, but one could say that about breaking changes to any CRAN package. 
Nothing particularly special about BH on that point.


My POV is that we need to consider - in some sense - lock down CRAN with 
a Bioc release.


That's probably worth considering. For example, it would be pretty cool 
to just supply a date and BiocManager could figure out the last 
successful release versions of all CRAN/BioC packages at that time.


-A

On Tue, Mar 26, 2019 at 12:45 AM Aaron Lun 
> wrote:


My 2 cents - API-breaking changes to BH are no more of an issue than
breaking changes to any other CRAN package. We just hope that it
doesn't
happen too often and we deal with it when the time comes; that's the
whole point of getting frequent release builds to check for these cases.

If we were discussing a package that distributed a shared library, then
greater concern would be warranted if updates to the library
resulted in
ABI incompatibilities. This could result in very cryptic errors at link
time, load time, or possibly segmentation faults, who knows.

But BH is a header-only library, so breaking changes will most likely
cause compilation errors that are obvious and easy to fix. Well, easy
enough if you were able to write C++ code in the first place.

-A


On 25/03/2019 08:39, Vincent Carey wrote:
 > On Mon, Mar 25, 2019 at 10:57 AM Kasper Daniel Hansen <
 > kasperdanielhan...@gmail.com
> wrote:
 >
 >> There are no issues with depending on CRAN packages.
 >>
 >> But I would advise caution. On one hand it is great that boost gets
 >> updated regularly. On the other hand, it could lead to
incompatibilities
 >> with RBGL and then you have to update that package rapidly. Also
- and this
 >> is something we could consider addressing - the CRAN imports of
Bioc are
 >> not locked down. By which I mean, you release RBGL in
Bioconductor X. After
 >> release (or perhaps even after next Bioc release) BH is updated in a
 >> non-backwards compatible way and now the old code is hosed.
Having said
 >> that, so far we have been ignoring it (I think) and the same
issue arises
 >> with Rcpp.
 >>
 >> Do you have any idea how often Boost breaks compatibility?  I would
 >> strongly advise to download the last couple of BH releases and
test with
 >> RBGL. While kind of irrelevant in some sense, it will give you
an idea of
 >> how fast Boost / BH evolves.
 >>
 >
 > These are good points.  In this particular case I believe that
Boost Graph
 > Library evolves very slowly and
 > backwards compatibility is not endangered.  It is an early
component of
 > Boost.  On the other hand, BH has
 > no obligation to provide the graph (BGL) headers, and I believe
that in
 > early incarnations of BH, some headers
 > needed for RBGL were not there.  So there are maintenance
vulnerabilities
 > to this approach, but I think it is better
 > if we stick with the maintained BH as long as this works.  Should
this
 > approach fail (and your scenario of
 > CRAN package changes breaking bioc must be kept in mind) we can
go back to
 > tarball distribution if necessary.
 >
 >
 >>
 >> On Mon, Mar 25, 2019 at 8:03 AM Martin Morgan
mailto:mtmorgan.b...@gmail.com>>
 >> wrote:
 >>
 >>> ...also Bioconductor knows all about CRAN -- see the repositories
 >>> returned by
 >>>
  BiocManager::repositories()
 >>>                                                 BioCsoft
 >>>             "https://bioconductor.org/packages/3.9/bioc;
 >>>                                                  BioCann
 >>> "https://bioconductor.org/packages/3.9/data/annotation;
 >>>                                                  BioCexp
 >>> "https://bioconductor.org/packages/3.9/data/experiment;
 >>>                                            BioCworkflows
 >>>        "https://bioconductor.org/packages/3.9/workflows;
 >>>                                                     CRAN
 >>>                               "https://cran.rstudio.com;
 
 >>>
 >>> On 3/25/19, 7:42 AM, "Martin Morgan" mailto:mtmorgan.b...@gmail.com>> wrote:
 >>>
 >>>      I think the usual incantation in configure files is
${R_HOME}/bin/R
 >>> ... R_HOME is the path to R set by the command that starts to
build or
 >>> install the package, whereas Rscript is found on the search path.
 >>>
 >>>      Martin
 >>>
 >>>      On 3/25/19, 7:33 AM, "Bioc-devel on behalf of Vincent
Carey" <
 >>> bioc-devel-boun...@r-project.org
 on behalf of

[Bioc-devel] Bioc_check on devel - Checking R Version dependency warning

[Ahmed Mohamed]

Hi all,

I noticed that bioc_check on devel checks for R version dependency, and
produces a warning to change R dependency to 3.6 (currently set as R >=
3.5.0). Just quickly looking at Bioconductor packages, it seems that at
least half of the packages will have this warning, if tested. It also means
that packages will need to change R dependency each release cycle (and
different R versions for release and devel).

To be honest, I am not fully convinced also on the rationale behind it.
Quoting
http://master.bioconductor.org/packages/devel/bioc/vignettes/BiocCheck/inst/doc/BiocCheck.html#version-checks

"BiocCheck checks to make sure that the R version specified matches the
version currently used by *Bioconductor*. This prevents the package from
being used in earlier versions of R, which is not recommended and is a
frequent cause of user confusion (WARNING)."

Currently, I am using TravisCI to Bioc_check my package on both release and
devel modes, so it is not also possible to change the R version as
suggested in the warning. I wonder if there is a possible work around,
other than looking the other way.

Link to build here:
https://travis-ci.org/ahmohamed/lipidr/jobs/511789232#L5673

Cheers.
Ahmed.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[Gabriel Becker]

Abs et al,

Ok, so I have just gone and re-read the docs again. My language was a more
absolute than it should have been; *however*, I was still correct for the
cases under discussion.

>From ?UseMethod (emphasis mine)

An R object is a data object which has a ‘class’ attribute (and

 this can be tested by ‘is.object’).  A class attribute is a

 character vector giving the names of the classes from which the

 object _inherits_.  *If the object does not have a class attribute,*

* it has an implicit class.*  Matrices and arrays have class

 ‘"matrix"’ or‘"array"’ followed by the class of the underlying

 vector.  Most vectors have class the result of ‘mode(x)’, except

 that integer vectors have class ‘c("integer", "numeric")’ and real

 vectors have class ‘c("double", "numeric")’.


So, there are implicit classes, but *only when the data object is NOT an "R
object" (ie when it does NOT have a class attribute).* So, what I said was
not correct for certain built in classes: matrices, arrays, and some
atomic vectors but IS true of any object you assign a class attribute to
(e.g. by doing class<-() ) When your code classes an object, you have to
give the full desired vector of inheritence in its class attribute.
Anything you leave out just won't be there.

This is the case with your "f" classed object, so it *does not have an
implicit class.*  That is how S3 is designed and intended to work.


On Tue, Mar 26, 2019 at 6:42 PM Abs Spurdle  wrote:

> > you had seemed to be presenting it as something new in 3.5.3. I would be
> surprised if the behavior doesn't go all the way back to whenever
> head.function was added.
>
> My bad.
> I'm just surprised I've never noticed these problems before.
>
> > S3 classes have no formal definitions at all
> > I'm not sure what is clear about that, or what class hierarchy you're
> talking about in the S3 case.
>
> That's questionable.
> One, because it depends on how you define formal definitions.
>

I mean, I guess, in the sense that that is true of any argument anyone ever
makes that uses a term.

For the record here, I'm using "Formal class definition" as an explicit
declaration of how valid objects of a particular class are structured, what
data they contain, and how they behave.

S3 does not have that. IT has only *implicit* class structure/content
definitions based on what methods for that class look for in objects passed
to them. There is no where you can look to figure out what it "means to be
a  class object" in the S3 sense, beyond a nebulous set of methods
which look for various things within an object that supposedly is of that
class.

> x = "not a date"

> class(x) = "Date"

> is(x, "Date")

[1] TRUE


> y = Sys.Date()

> y

[1] "2019-03-26"

> attr(y, "class")

[1] "Date"

> is.object(y)

[1] TRUE


> class(y) = "NonDate"

> y

[1] 17981

attr(,"class")

[1] "NonDate"

> is(y, "Date")

[1] FALSE

> inherits(y, "Date")

[1] FALSE



> And two, because class definitions can exist outside the code itself.
> e.g. As part of an object oriented model.
> (Being "Object Oriented" is just as much about models as it is about
> syntax).
>

Again, I suppose? In fact they have to S3, as I just pointed out above.
But, I really don't see how this is relevant. I doesn't matter what you
have written down on paper, or in documentation, or in your head as a model
about how your S3 classes relate to eachother, because the S3 dispatch
machinery can't see into any of those places. It can only go by what you
put in the class vector, and that is all it is going to go by (for objects
with a class attribute, ie for any "classes" your code defines)


>
> Furthermore, when you change the class of a vector, list or function, much
> of the original object's structure and behavior remains.
>

Conjecture here, since I don't know what exact behaviors you're referring
to, but if they are ostensibly S3 based (ie they are invoved via an S3
generic), its probably becuse they hit *.default methods which call down to
code internal C which operates based on SEXP type, ie they "escape S3
dispatch" in a sense.


> So, it has "Inherited" or "Extended", in my opinion.
>
Resulting in a class hierarchy.
>

You're welcome to have that opinion, but simply put that is now how
inheritance *for the purposes of S3 dispatch* is defined in S3.


>
> > Dispatch is ONLY done on the class vector for S3 (AFAIK)
>

> Incorrect.
> We've already mentioned the example of head.function().
> In general, this dispatch occurs without the presence of a class attribute.
>

I said the class vector, as in what is returned by class().


 > class(rnorm)

[1] "function"

> attr(rnorm, "class")

NULL


I apologize for not more carefully delineating those two things.

That IS consistent with head hitting head.function for a function but
head.default for a "classed function", because according to the definition
of how S3 behaves, your "classed function" doesn't have any implicit
classes, and you didn't 

Re: [Rd] bugs in head() and tail()

[Abs Spurdle]

> so instead of hitting utils:::head.function, it hits
utils:::head.default, which uses [ on the argument, causing the error.

I've thought about this some more.
And I still think that this is a bug.

If a generic has a default method, then that default method should be
guaranteed to work.
Or at least, provide a useful error message, that makes it obvious to the
user, what he or she has done wrong.

In the case of head.default(), it assumes that the object is a vector, or
something similar.
This assumption is untrue.

>> Error in x[seq_len(n)] : object of type 'closure' is not subsettable

Resulting in the error above, which fails to recognize that the input was
unsuitable.

[[alternative HTML version deleted]]

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

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[Abs Spurdle]

> you had seemed to be presenting it as something new in 3.5.3. I would be
surprised if the behavior doesn't go all the way back to whenever
head.function was added.

My bad.
I'm just surprised I've never noticed these problems before.

> S3 classes have no formal definitions at all
> I'm not sure what is clear about that, or what class hierarchy you're
talking about in the S3 case.

That's questionable.
One, because it depends on how you define formal definitions.
And two, because class definitions can exist outside the code itself.
e.g. As part of an object oriented model.
(Being "Object Oriented" is just as much about models as it is about
syntax).

Furthermore, when you change the class of a vector, list or function, much
of the original object's structure and behavior remains.
So, it has "Inherited" or "Extended", in my opinion.
Resulting in a class hierarchy.

> Dispatch is ONLY done on the class vector for S3 (AFAIK)

Incorrect.
We've already mentioned the example of head.function().
In general, this dispatch occurs without the presence of a class attribute.

> You seem to be approaching the S3 "class"/dispatch system as something
that it is not: a formal class system

If I can diverge...

Where did this term "Formal Class System" come from?
I've never seen it used anywhere else.
Is is specific to R?

[[alternative HTML version deleted]]

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

[Rd] default for 'signif.stars'

[Lenth, Russell V]

Dear R-Devel,

As I am sure many of you know, a special issue of The American Statistician 
just came out, and its theme is the [mis]use of P values and the many common 
ways in which they are abused. The lead editorial in that issue mentions the 
2014 ASA guidelines on P values, and goes one step further, by now recommending 
that the words "statistically significant" and related simplistic 
interpretations no longer be used. There is much discussion of the problems 
with drawing "bright lines" concerning P values.

This is the position of a US society, but my sense is that the statistical 
community worldwide is pretty much on the same page. 

Meanwhile, functions such as 'print.summary.lm' and 'print.anova' have an 
argument 'signif.stars' that really does involve drawing bright lines when it 
is set to TRUE. And the default setting for the "show.signif.stars" option is 
TRUE. Isn't it time to at least make "show.signif.stars" default to FALSE? And, 
indeed, to consider deprecating those 'signif.stars' options altogether?

Thanks

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science   
The University of Iowa  -  Iowa City, IA 52242  USA   
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

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

Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation

[David Kepplinger]

Thanks, Gábor, for taking the time to investigate the issue and the
detailed elaboration!
I resubmitted to CRAN with a brief explanation and a link to this thread.

Thanks,
David

On Tue, Mar 26, 2019 at 2:55 PM Gábor Csárdi  wrote:

> OK, here is what I think is going on.
>
> There is a bug in the check code, that creates a false positive when
> the package installation is performed with `--merge-multiarch`. In
> this case the x64 architecture uses a non-staged install,
> deliberately, but the check code still picks this up and reports it as
> a NOTE.
>
> Reproducing it is not easy, because of several reasons:
> - win-builder uses package-specific configuration, in this case your
> package is listed in
>
> https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Uwe/make/config/MergeMultiarch
> ,
> so `--merge-multiarch` is added automatically.
> - R CMD check cannot pass --merge-multiarch to R CMD INSTALL because
> --merge-multiarch only works on tarballs, and R CMD check runs INSTALL
> on a directory.
> - However, R CMD check has an undocumented --install=... option, which
> can be used to pick up the installation output from a certain file. I
> am pretty sure that win-builder uses this. I.e. it calls R CMD INSTALL
> first, putting the output to a file, and then calls R CMD check with
> the --install= option pointing to that file as the install output.
>
> In summary, I think this an R CMD check bug, added in this commit:
>
> https://github.com/wch/r-source/commit/44e8faeb1ed30a7603e79988639da7e4e358d497
>
> It can be fixed easily by using a slightly different message for the
> --merge-multiarch case, or maybe even by not specifying
> --no-staged-install here:
>
> https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1913
> and here:
>
> https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1938
> because --libs-only implies --no-staged-install anyway. I am not
> entirely certain, but Tomas and/or Prof Ripley will know for sure.
>
> If you want submit your package before the bug is fixed, I suggest you
> explain this directly to CRAN when you submit your package.
>
> Best,
> Gabor
>
> On Tue, Mar 26, 2019 at 3:18 PM David Kepplinger
>  wrote:
> >
> > Dear Gábor,
> >
> > Oddly, it does emit a NOTE due to the non-staged install, as can be seen
> at https://win-builder.r-project.org/86i67mqTD9YY
> >
> > The package source can be found at
> https://github.com/dakep/pense-rpkg/tree/release/1.2.2
> >
> > Thanks for your help,
> > David
> >
> >
> > On Tue, Mar 26, 2019, 3:28 AM Gábor Csárdi, 
> wrote:
> >>
> >> Hi David,
> >>
> >> if you only see
> >>
> >> install for i386
> >> * installing *source* package 'pense' ...
> >> ** using staged installation
> >> []
> >> install for x64
> >> * installing *source* package 'pense' ...
> >> ** using non-staged installation
> >> [...]
> >>
> >> then everything is fine, there is no NOTE here, AFAICT.
> >>
> >> If you see a NOTE about this, please post 1) a link to your package,
> >> and 2) a link to the win-builder output.
> >>
> >> Thanks,
> >> Gabor
> >>
> >> On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger
> >>  wrote:
> >> >
> >> > Dear Community,
> >> >
> >> > The issue persists and I don't know if it is something I can fix or
> if it's
> >> > a false positive from the CRAN incoming checks. As a result, the
> package is
> >> > archived as the old version has other issues with the new R version.
> >> >
> >> > Does someone have an idea how I can fix the issue? I have asked the
> CRAN
> >> > team last week to flag the issue as a false positive, but I haven't
> heard
> >> > back so I assume it's something I have to fix.
> >> >
> >> > Thanks,
> >> > David
> >> >
> >> > On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger <
> david.kepplin...@gmail.com>
> >> > wrote:
> >> >
> >> > > Thank you, Max, for the clarification.
> >> > > I have added the option "StagedInstall: yes" to the DESCRIPTION
> file, but
> >> > > it doesn't seem to be forcing a staged installation for x64 on
> Windows. I
> >> > > get the same NOTE now from winbuilder, but with more explanation
> which
> >> > > could help isolate the problem:
> >> > >
> >> > > install for i386
> >> > > * installing *source* package 'pense' ...
> >> > > ** using staged installation
> >> > > [...]
> >> > > install for x64
> >> > > * installing *source* package 'pense' ...
> >> > > not using staged install with --libs-only
> >> > > ** using non-staged installation
> >> > > [...]
> >> > >
> >> > >
> >> > > Best,
> >> > > David
> >> > >
> >> > > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon <
> >> > > maxime.turg...@mail.mcgill.ca> wrote:
> >> > >
> >> > >> Hi David,
> >> > >>
> >> > >> Non-staged installation is something new in R-devel:
> >> > >>
> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html
> >> > >>
> >> > >>
> >> > >> Package maintainers can opt out of it (through DESCRIPTION), and

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[William Dunlap via R-devel]

I think this goes back to SV4 (c. late 1990's).  The is.  functions
are much older (c. mid 1970's) , from before any class system was in S.
is() and inherits() were introduced with the S4 class system and were meant
to escape from the prison made by ancient design choices.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Mar 26, 2019 at 2:11 PM Abs Spurdle  wrote:

> If I can merge this thread with the one I started yesterday...
>
> > "If the object does not have a class attribute, it has an implicit
> class..."
> > which I take to mean that if an object does have a class attribute it
> does not also have an implicit class.
> > I think this is reasonable behavior. Consider the "Date" class, which
> stores values as "numeric":
> > > class(Sys.Date())
> > [1] "Date"
> > > inherits(Sys.Date(),"numeric")
> > [1] FALSE
> > > class(unclass(Sys.Date()))
> > [1] "numeric"
> > > Sys.Date()%%2
> > Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
> > Letting the modulus operator (as one example) inherit the numeric class
> here could create problems.
>
> I disagree.
> A date object should probably extend integers rather than numerics, in the
> first place.
> However, if it extends numeric, then it extends numeric, otherwise it's a
> contradiction.
> So, inherits(Sys.Date(),"numeric") should return true.
>
> Modulo operators should be defined for both dates and numerics.
> However, the application of modulo operators to dates, is perhaps unclear,
> at least in the general case, anyway.
>
> > so instead of hitting utils:::head.function, it hits utils:::head.default
> > I also see this behavior at least as far aback as 3.5.1, so its not new
> to 3.5.3.
>
> These seem like significant design flaws.
> Implicit classes or whatever you want to call them, are clearly part of the
> class hierarchy.
>
> They should be included in inherits(), is() and standard method dispatch,
> regardless of whether they are part of the class vector or not.
>
> Also, is this something that was introduced in R 3.5.1?
> The only thing worse than a design flaw is a design flaw that isn't
> backward compatible.
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[Gabriel Becker]

Hi Abs,

Lets try to remain civil even when disagreeing about major design
philosophies, ok?

On Tue, Mar 26, 2019 at 2:08 PM Abs Spurdle  wrote:

> If I can merge this thread with the one I started yesterday...
>
> > "If the object does not have a class attribute, it has an implicit
> class..."
> > which I take to mean that if an object does have a class attribute it
> does not also have an implicit class.
> > I think this is reasonable behavior. Consider the "Date" class, which
> stores values as "numeric":
> > > class(Sys.Date())
> > [1] "Date"
> > > inherits(Sys.Date(),"numeric")
> > [1] FALSE
> > > class(unclass(Sys.Date()))
> > [1] "numeric"
> > > Sys.Date()%%2
> > Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
> > Letting the modulus operator (as one example) inherit the numeric class
> here could create problems.
>
> I disagree.
> A date object should probably extend integers rather than numerics, in the
> first place.
> However, if it extends numeric, then it extends numeric, otherwise it's a
> contradiction.
> So, inherits(Sys.Date(),"numeric") should return true.
>

You seem to be approaching the S3 "class"/dispatch system as something that
it is not: a formal class system. S3 dispatch is based, essentially, on
labeling, via the class attribute (or, if you like, the value returned by
class(), this is basically the same with some fiddly bits for S4, judging
by a quick glance at src/main/attrib.c:do_class ). If it is not in the set
of class labels, S3 dispatch *will not* treat it as that class. This is by
design. An S3 object's "class" also has no* bearing on the contents of the
object (* this isn't true for some built in atomic vector classes, as I
Recall, but it is for all user defined classes).


> mylist = list("hi", "what?")

> class(mylist) = "Date"

> mylist

[1] NA NA

*Warning messages:*

*1: In as.POSIXlt.Date(x) : NAs introduced by coercion*


*2: In as.POSIXlt.Date(x) : NAs introduced by coercion*


See? the print method looks at the class attribute of mylist, and says "Oh,
this is a Date, I'll use print.Date" and then it craps out (with NAs
instead of errors, but still) because the data contained within the object
isn't really a "Date". But there is no definition of what it means to be an
S3 "Date" object anywhere, other than that it has the Date class attribute.

All of the above is *by design*. You're welcome to not like the design. I
prefer the formalism of S4, myself, and there are various things I don't
love about how S3 works - including some but not all of the things that
have come up here. That said, the behaviors are not bugs, and any of the
changes you seem to be advocating for would not only break lots of code,
but would also represent fundamental changes to the design of a core aspect
of the R language.

As for doing %% on Dates, I seriously doubt anyone who is operating on Date
objects and thinking about times and dates is looking to do a modulo
operation in number of Days since Jan 1st 1970, which is what that
operation would do. Better to have that fail and if that really, for sure
is what the user actually wants to do, they can uncalss it or otherwise
convert it to a numeridc first.



> Modulo operators should be defined for both dates and numerics.
> However, the application of modulo operators to dates, is perhaps unclear,
> at least in the general case, anyway.
>
> > so instead of hitting utils:::head.function, it hits
> utils:::head.default
> > I also see this behavior at least as far aback as 3.5.1, so its not new
> to 3.5.3.
>

> These seem like significant design flaws.
> Implicit classes or whatever you want to call them, are clearly part of
> the class hierarchy.
>

I'm not sure what is clear about that, or what class hierarchy you're
talking about in the S3 case. Remember that S3 classes *have no formal
definitions at all*. Thats why I rarely if ever use them in software that I
write. But it's an important point here. What something would becomes if
you unclass()ed it has no bearing on what S3 dispatch will do.


>
> They should be included in inherits(), is() and standard method dispatch,
> regardless of whether they are part of the class vector or not.
>

Dispatch is ONLY done on the class vector for S3 (AFAIK). Only. That is how
S3 dispatch is defined and designed.

>
> Also, is this something that was introduced in R 3.5.1?
> The only thing worse than a design flaw is a design flaw that isn't
> backward compatible.
>

No that is just the non-devel R I had handy, and you had seemed to be
presenting it as something new in 3.5.3. I would be surprised if the
behavior doesn't go all the way back to whenever head.function was added.
Before that head() on a function (likely) would have failed just like it
still does on your reclassed function. Because, again, this is how S3 is
supposed to behave when you give it the inputs you are. I fyou want your f
class to hit function S3 methods, you need to do

class(myfun) <- c("f", "function")

Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation

[Gábor Csárdi]

OK, here is what I think is going on.

There is a bug in the check code, that creates a false positive when
the package installation is performed with `--merge-multiarch`. In
this case the x64 architecture uses a non-staged install,
deliberately, but the check code still picks this up and reports it as
a NOTE.

Reproducing it is not easy, because of several reasons:
- win-builder uses package-specific configuration, in this case your
package is listed in
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Uwe/make/config/MergeMultiarch,
so `--merge-multiarch` is added automatically.
- R CMD check cannot pass --merge-multiarch to R CMD INSTALL because
--merge-multiarch only works on tarballs, and R CMD check runs INSTALL
on a directory.
- However, R CMD check has an undocumented --install=... option, which
can be used to pick up the installation output from a certain file. I
am pretty sure that win-builder uses this. I.e. it calls R CMD INSTALL
first, putting the output to a file, and then calls R CMD check with
the --install= option pointing to that file as the install output.

In summary, I think this an R CMD check bug, added in this commit:
https://github.com/wch/r-source/commit/44e8faeb1ed30a7603e79988639da7e4e358d497

It can be fixed easily by using a slightly different message for the
--merge-multiarch case, or maybe even by not specifying
--no-staged-install here:
https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1913
and here:
https://github.com/wch/r-source/blob/be469e86046389a0213f22e8b5c7b3227558bb01/src/library/tools/R/install.R#L1938
because --libs-only implies --no-staged-install anyway. I am not
entirely certain, but Tomas and/or Prof Ripley will know for sure.

If you want submit your package before the bug is fixed, I suggest you
explain this directly to CRAN when you submit your package.

Best,
Gabor

On Tue, Mar 26, 2019 at 3:18 PM David Kepplinger
 wrote:
>
> Dear Gábor,
>
> Oddly, it does emit a NOTE due to the non-staged install, as can be seen at 
> https://win-builder.r-project.org/86i67mqTD9YY
>
> The package source can be found at 
> https://github.com/dakep/pense-rpkg/tree/release/1.2.2
>
> Thanks for your help,
> David
>
>
> On Tue, Mar 26, 2019, 3:28 AM Gábor Csárdi,  wrote:
>>
>> Hi David,
>>
>> if you only see
>>
>> install for i386
>> * installing *source* package 'pense' ...
>> ** using staged installation
>> []
>> install for x64
>> * installing *source* package 'pense' ...
>> ** using non-staged installation
>> [...]
>>
>> then everything is fine, there is no NOTE here, AFAICT.
>>
>> If you see a NOTE about this, please post 1) a link to your package,
>> and 2) a link to the win-builder output.
>>
>> Thanks,
>> Gabor
>>
>> On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger
>>  wrote:
>> >
>> > Dear Community,
>> >
>> > The issue persists and I don't know if it is something I can fix or if it's
>> > a false positive from the CRAN incoming checks. As a result, the package is
>> > archived as the old version has other issues with the new R version.
>> >
>> > Does someone have an idea how I can fix the issue? I have asked the CRAN
>> > team last week to flag the issue as a false positive, but I haven't heard
>> > back so I assume it's something I have to fix.
>> >
>> > Thanks,
>> > David
>> >
>> > On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger 
>> > 
>> > wrote:
>> >
>> > > Thank you, Max, for the clarification.
>> > > I have added the option "StagedInstall: yes" to the DESCRIPTION file, but
>> > > it doesn't seem to be forcing a staged installation for x64 on Windows. I
>> > > get the same NOTE now from winbuilder, but with more explanation which
>> > > could help isolate the problem:
>> > >
>> > > install for i386
>> > > * installing *source* package 'pense' ...
>> > > ** using staged installation
>> > > [...]
>> > > install for x64
>> > > * installing *source* package 'pense' ...
>> > > not using staged install with --libs-only
>> > > ** using non-staged installation
>> > > [...]
>> > >
>> > >
>> > > Best,
>> > > David
>> > >
>> > > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon <
>> > > maxime.turg...@mail.mcgill.ca> wrote:
>> > >
>> > >> Hi David,
>> > >>
>> > >> Non-staged installation is something new in R-devel:
>> > >> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html
>> > >>
>> > >>
>> > >> Package maintainers can opt out of it (through DESCRIPTION), and I'm
>> > >> assuming CRAN wants a quick way to know if that was the case when
>> > >> diagnosing a submission.
>> > >>
>> > >> To resolutely opt *in* (which will eventually be the default), you could
>> > >> try adding "StagedInstall: yes" to your DESCRIPTION file.
>> > >>
>> > >> Of course, one question still remains: why was the behaviour different
>> > >> for the two architectures.
>> > >>
>> > >> Max
>> > >> --
>> > >> *From:* R-package-devel  on
>> > >> behalf of David Kepplinger 
>> > >> 

Re: [R-pkg-devel] package cartograflow_0.0.0.9000.tar.gz

[Henrik Bengtsson]

FWIW, you should be able to reproduce at least the following NOTEs
with your current R 3.5.2 and R CMD check --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘cartogRaflow ’

New submission

Version contains large components (0.0.0.9000)

Possibly mis-spelled words in DESCRIPTION:
  flowmapping (7:41)

Author field should be Authors@R.  Current value is:
  c(person("Françoise", "Bahoken", email =
"francoise.baho...@ifsttar.fr", role = c("cre","aut")),
 person("Sylvain", "Blondeau", email =
"blondeau.sylv...@yahoo.fr", role = c("aut"))

The Title field should be in title case. Current version is:
‘thematic cartography of flows and movements’
In title case that is:
‘Thematic Cartography of Flows and Movements’

Those are all classical mistakes ("we've all been there").  The
vignette errors may or may not be specific to R devel.

/Henrik

On Tue, Mar 26, 2019 at 2:29 PM cartograf...@gmail.com
 wrote:
>
> Hi,  l've made R CMD check --as-cran on rstudio 3.5.2Why I have to use 
> r-devel?
> I confirm that I didn't received à error message when I've made 
> dev_tool::check.
> How can I solve my problem ?
> Thanks in advance Sylvain
>
>
> nvoyé depuis Yahoo Mail pour Android
>
>   Le lun., mars 25, 2019 à 23:38, Uwe Ligges 
> a écrit :   I cannot beloeve it. But this is certainly not R-devel?
>
> Not sure about devtools which we do not use on CRAN, but simply
>
> R CMD check --as-cran
>
> with a recent R-devel  version on the package tarball should reproduce
> the findings.
>
> Best,
> Uwe Ligges
>
>
> On 25.03.2019 23:12, cartograf...@gmail.com wrote:
> > Hello,
> > I've submitted my package cartograflow and I received an email from your 
> > teeam that it does not pass the incoming checks automatically.Debian: 
> > 
> > Status: 1 ERROR, 2 WARNINGs, 1 NOTE
> >
> > So, I've made the new check on my plateform (linux ubuntu) and the check is 
> > OK.I used : ==> devtools::check(args = c('--no-manual','--as-cran'))Status 
> > is :
> > ── R CMD check results  cartograflow 0.0.0.9000 
> > 
> > Duration: 54.6s
> > 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
> > R CMD check succeeded
> > Can you  help me to fix the problem?
> > Thanks in advance to your replySylvain
> > [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Re :Re: package cartograflow_0.0.0.9000.tar.gz

[cartograf...@gmail.com]

Hi,  l've made R CMD check --as-cran on rstudio 3.5.2Why I have to use r-devel?
I confirm that I didn't received à error message when I've made 
dev_tool::check. 
How can I solve my problem ?
Thanks in advance Sylvain 


nvoyé depuis Yahoo Mail pour Android 
 
  Le lun., mars 25, 2019 à 23:38, Uwe Ligges a 
écrit :   I cannot beloeve it. But this is certainly not R-devel?

Not sure about devtools which we do not use on CRAN, but simply

R CMD check --as-cran

with a recent R-devel  version on the package tarball should reproduce 
the findings.

Best,
Uwe Ligges


On 25.03.2019 23:12, cartograf...@gmail.com wrote:
> Hello,
> I've submitted my package cartograflow and I received an email from your 
> teeam that it does not pass the incoming checks automatically.Debian: 
> 
> Status: 1 ERROR, 2 WARNINGs, 1 NOTE
> 
> So, I've made the new check on my plateform (linux ubuntu) and the check is 
> OK.I used : ==> devtools::check(args = c('--no-manual','--as-cran'))Status is 
> :
> ── R CMD check results  cartograflow 0.0.0.9000 
> 
> Duration: 54.6s
> 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
> R CMD check succeeded
> Can you  help me to fix the problem?
> Thanks in advance to your replySylvain
>     [[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: [Rd] Discrepancy between is.list() and is(x, "list")

[Abs Spurdle]

If I can merge this thread with the one I started yesterday...

> "If the object does not have a class attribute, it has an implicit
class..."
> which I take to mean that if an object does have a class attribute it
does not also have an implicit class.
> I think this is reasonable behavior. Consider the "Date" class, which
stores values as "numeric":
> > class(Sys.Date())
> [1] "Date"
> > inherits(Sys.Date(),"numeric")
> [1] FALSE
> > class(unclass(Sys.Date()))
> [1] "numeric"
> > Sys.Date()%%2
> Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
> Letting the modulus operator (as one example) inherit the numeric class
here could create problems.

I disagree.
A date object should probably extend integers rather than numerics, in the
first place.
However, if it extends numeric, then it extends numeric, otherwise it's a
contradiction.
So, inherits(Sys.Date(),"numeric") should return true.

Modulo operators should be defined for both dates and numerics.
However, the application of modulo operators to dates, is perhaps unclear,
at least in the general case, anyway.

> so instead of hitting utils:::head.function, it hits utils:::head.default
> I also see this behavior at least as far aback as 3.5.1, so its not new
to 3.5.3.

These seem like significant design flaws.
Implicit classes or whatever you want to call them, are clearly part of the
class hierarchy.

They should be included in inherits(), is() and standard method dispatch,
regardless of whether they are part of the class vector or not.

Also, is this something that was introduced in R 3.5.1?
The only thing worse than a design flaw is a design flaw that isn't
backward compatible.

[[alternative HTML version deleted]]

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

Re: [Rd] [PATCH 1/2] readtable: add hook for type conversions per column

[Ben Bolker]

  You need admin assistance, someone will probably see your request here
and fulfill it.

  It might be helpful to read this question/answer on StackOverflow
discussing the context of proposing patches to base R functionality ...

https://stackoverflow.com/questions/8065835/proposing-feature-requests-to-the-r-core-team

  cheers
Ben Bolker


On 2019-03-26 4:20 p.m., Kurt Van Dijck wrote:
> On di, 26 mrt 2019 12:48:12 -0700, Michael Lawrence wrote:
>>Please file a bug on bugzilla so we can discuss this further.
> 
> All fine.
> I didn't find a way to create an account on bugs.r-project.org.
> Did I just not see it? or do I need administrator assistance?
> 
> Kind regards,
> Kurt
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

Re: [Rd] [PATCH 1/2] readtable: add hook for type conversions per column

[Kurt Van Dijck]

On di, 26 mrt 2019 12:48:12 -0700, Michael Lawrence wrote:
>Please file a bug on bugzilla so we can discuss this further.

All fine.
I didn't find a way to create an account on bugs.r-project.org.
Did I just not see it? or do I need administrator assistance?

Kind regards,
Kurt

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

Re: [Bioc-devel] Unclear build failure ‘appending gaps’

[Karl Stamm]

Is there a standard system loadout I should be matching? Something must be
different between my Windows build server and the bioconductor one.
I need to reproduce the error in order to debug it, but everything is
building fine locally.

On Tue, Mar 26, 2019 at 12:21 PM Yue Zhao (Jason)  wrote:

> A new error showed up: logical subscript contains NAs
>
>
> *--*
>
> *Yue (Jason) Zhao*
>
> PhD Candidate, Bioinformatics Program
>
> Boston University
>
> yu...@bu.edu
>
>
> On Sat, Mar 23, 2019 at 11:22 AM Michael Lawrence via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
>> This is due to some buggy changes to the internals of the S4Vectors
>> package. I should be able to fix these today.
>>
>> On Sat, Mar 23, 2019 at 7:41 AM Karl Stamm  wrote:
>>
>> > My package rgsepd has failed build recently.
>> >
>> > I don't understand the error message, and need some guidance. It says
>> Error
>> > building vignette, "appending gaps is not supported"
>> >
>> > I can't find that statement anywhere in Google, so I don't know what
>> it's
>> > referring to.  Unfortunately, my package is an automation pipeline, so
>> > there's one line of code that runs many others, and the line triggering
>> the
>> > error could represent any part of my pipeline.
>> >
>> > I've checked the build on my end before uploading code changes, so I
>> cant
>> > reproduce the error. My build was okay until very recently, I have
>> added a
>> > CITATION file which is rather lengthy, and may be impacting the vignette
>> > build?
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] [PATCH 1/2] readtable: add hook for type conversions per column

[Michael Lawrence via R-devel]

Please file a bug on bugzilla so we can discuss this further.

On Tue, Mar 26, 2019 at 11:53 AM Kurt Van Dijck <
dev.k...@vandijck-laurijssen.be> wrote:

> Hello,
>
> I want to find out if this patch is ok or not, and if not, what should
> change.
>
> Kind regards,
> Kurt
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Version of make on CRAN Windows build machines

[Winston Chang]

On Windows I have a package that builds just fine with any recent version
of Rtools. But on win-builder it fails because the version of GNU make on
that machine does not support if-else syntax. Support for this syntax was
added in GNU make 3.81, which was released in 2006. The version of Rtools
on my computer comes with GNU Make 4.2.1.

I resubmitted the package to win-builder with `make --version` and found
that it is using version 3.79.1. I'm curious -- why does it use such an old
version of make, and one that does not come with Rtools? I've tried to
follow the documentation at
https://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset to
get a build environment as close as possible to what is prescribed. But
since this environment differs from what CRAN actually uses, it makes for a
long and error-prone process when submitting a package to CRAN.

-Winston

[[alternative HTML version deleted]]

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

Re: [Rd] [PATCH 1/2] readtable: add hook for type conversions per column

[Kurt Van Dijck]

Hello,

I want to find out if this patch is ok or not, and if not, what should
change.

Kind regards,
Kurt

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

Re: [Bioc-devel] Unclear build failure ‘logical subscript contains NAs’

[Michael Lawrence via Bioc-devel]

You'll just need to wait for that build error to resolve.

On Tue, Mar 26, 2019 at 10:45 AM Yue Zhao (Jason)  wrote:

> Thanks, Michael. I saw this error in the bioC 3.9 package building step for
> my package, so I'm not sure how to specify the S4Vector version in that.
>
> On Tue, Mar 26, 2019 at 1:35 PM Michael Lawrence <
> lawrence.mich...@gene.com>
> wrote:
>
> > DESeq2 seems to be working with S4Vectors 0.21.19. If you're using an
> > older version, you'll need to update once that version appears in the
> > repository. Sorry for the mess. Trying to clean up the [<- stuff on
> > DataFrame and Vector to make them easier to extend.
> >
> > On Tue, Mar 26, 2019 at 10:19 AM Yue Zhao (Jason)  wrote:
> >
> >> I see this error (logical subscript contains NAs) happened in DESeq2,
> I'm
> >> wondering if anyone knows what happened with the new BioC? Thanks!
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[Rui Barradas]

Hello,

Here is another example.

df1 <- data.frame(a = 1:3, b = 4:6)

inherits(df1, "data.frame")
#[1] TRUE
class(df1)
#[1] "data.frame"

inherits(df1, "list")
#[1] FALSE


This is documented behavior, the help page ?inherits says

The function class prints the vector of names of classes an object 
inherits from.



So far, so good. But now comes the part I don't like.

is.list(df1)
#[1] TRUE


Strictly speaking this is not unexpected behavior (because it's 
documented) but isn't it *inconsistent* behavior?



Rui Barradas

Às 16:30 de 26/03/2019, Berry, Charles escreveu:

In the case of inherits (at least) this seems intended.

The help page says:

"If the object does not have a class attribute, it has an implicit class..."

which I take to mean that if an object does have a class attribute it does not 
also have an implicit class.

The behavior you noted below will apply to other types bearing implicit 
classes. For example:


inherits(1.0, "numeric")

[1] TRUE

inherits(structure(1.0, class="myclass"), "numeric")

[1] FALSE




I think this is reasonable behavior. Consider the "Date" class, which stores values as 
"numeric":


class(Sys.Date())

[1] "Date"

inherits(Sys.Date(),"numeric")

[1] FALSE

class(unclass(Sys.Date()))

[1] "numeric"

Sys.Date()%%2

Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects




Letting the modulus operator (as one example) inherit the numeric class here 
could create problems.

Of course for classes that should inherit the implicit type, it can be 
explicitly added to the end of the class() vector by its constructor.

HTH,

Chuck




On Mar 25, 2019, at 8:27 PM, Abs Spurdle  wrote:


I have noticed a discrepancy between is.list() and is(x, “list”)


There's a similar problem with inherits().

On R 3.5.3:


f = function () 1
class (f) = "f"



is.function (f)

[1] TRUE

inherits (f, "function")

[1] FALSE

I didn't check what happens with:

class (f) = c ("f", "function")


However, they should have the same result, regardless.


Is this discrepancy intentional?


I hope not.

[[alternative HTML version deleted]]



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



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

Re: [Bioc-devel] Unclear build failure ‘logical subscript contains NAs’

[Yue Zhao (Jason)]

Thanks, Michael. I saw this error in the bioC 3.9 package building step for
my package, so I'm not sure how to specify the S4Vector version in that.

On Tue, Mar 26, 2019 at 1:35 PM Michael Lawrence 
wrote:

> DESeq2 seems to be working with S4Vectors 0.21.19. If you're using an
> older version, you'll need to update once that version appears in the
> repository. Sorry for the mess. Trying to clean up the [<- stuff on
> DataFrame and Vector to make them easier to extend.
>
> On Tue, Mar 26, 2019 at 10:19 AM Yue Zhao (Jason)  wrote:
>
>> I see this error (logical subscript contains NAs) happened in DESeq2, I'm
>> wondering if anyone knows what happened with the new BioC? Thanks!
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Unclear build failure ‘logical subscript contains NAs’

[Michael Lawrence via Bioc-devel]

DESeq2 seems to be working with S4Vectors 0.21.19. If you're using an older
version, you'll need to update once that version appears in the repository.
Sorry for the mess. Trying to clean up the [<- stuff on DataFrame and
Vector to make them easier to extend.

On Tue, Mar 26, 2019 at 10:19 AM Yue Zhao (Jason)  wrote:

> I see this error (logical subscript contains NAs) happened in DESeq2, I'm
> wondering if anyone knows what happened with the new BioC? Thanks!
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Unclear build failure ‘appending gaps’

[Yue Zhao (Jason)]

A new error showed up: logical subscript contains NAs


*--*

*Yue (Jason) Zhao*

PhD Candidate, Bioinformatics Program

Boston University

yu...@bu.edu


On Sat, Mar 23, 2019 at 11:22 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> This is due to some buggy changes to the internals of the S4Vectors
> package. I should be able to fix these today.
>
> On Sat, Mar 23, 2019 at 7:41 AM Karl Stamm  wrote:
>
> > My package rgsepd has failed build recently.
> >
> > I don't understand the error message, and need some guidance. It says
> Error
> > building vignette, "appending gaps is not supported"
> >
> > I can't find that statement anywhere in Google, so I don't know what it's
> > referring to.  Unfortunately, my package is an automation pipeline, so
> > there's one line of code that runs many others, and the line triggering
> the
> > error could represent any part of my pipeline.
> >
> > I've checked the build on my end before uploading code changes, so I cant
> > reproduce the error. My build was okay until very recently, I have added
> a
> > CITATION file which is rather lengthy, and may be impacting the vignette
> > build?
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Discrepancy between is.list() and is(x, "list")

[Berry, Charles]

In the case of inherits (at least) this seems intended.

The help page says:

"If the object does not have a class attribute, it has an implicit class..."

which I take to mean that if an object does have a class attribute it does not 
also have an implicit class.

The behavior you noted below will apply to other types bearing implicit 
classes. For example:

> inherits(1.0, "numeric")
[1] TRUE
> inherits(structure(1.0, class="myclass"), "numeric")
[1] FALSE
> 

I think this is reasonable behavior. Consider the "Date" class, which stores 
values as "numeric":

> class(Sys.Date())
[1] "Date"
> inherits(Sys.Date(),"numeric")
[1] FALSE
> class(unclass(Sys.Date()))
[1] "numeric"
> Sys.Date()%%2
Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
> 

Letting the modulus operator (as one example) inherit the numeric class here 
could create problems.

Of course for classes that should inherit the implicit type, it can be 
explicitly added to the end of the class() vector by its constructor.

HTH,

Chuck



> On Mar 25, 2019, at 8:27 PM, Abs Spurdle  wrote:
> 
>> I have noticed a discrepancy between is.list() and is(x, “list”)
> 
> There's a similar problem with inherits().
> 
> On R 3.5.3:
> 
>> f = function () 1
>> class (f) = "f"
> 
>> is.function (f)
> [1] TRUE
>> inherits (f, "function")
> [1] FALSE
> 
> I didn't check what happens with:
>> class (f) = c ("f", "function")
> 
> However, they should have the same result, regardless.
> 
>> Is this discrepancy intentional?
> 
> I hope not.
> 
>   [[alternative HTML version deleted]]
> 

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

[Rd] [Enhancement] New argument for dirname() -- dirname(path, depth = 1L)

[Luke Smith]

The new argument 'depth' would specify the depth to recurse up the file path.  
As in:
> dirname("path/to/some/where", depth = 3L)[1] "path"
The new argument would take on the default value of 1L, since this is the 
current behavior of the function.

 Problems will arise when 'depth' is unusually large (i.e. dirname(path, depth 
= 1e5)).

During execution, a warning could be issued to the user indicating an unusually 
large value for 'depth'.

[[alternative HTML version deleted]]

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

Re: [Rd] R 3.5.3 having trouble spawning a new process on my Windows 10 machine

[Sam Albers]

Hi Joris,

Thanks for trying.

> Is your PATH set on your user environment variables or on the system?

It is set as a system variable

> Did you try to remove the entry for R-3.5.2 ?
For each version iteration in the above example, I only had the path of the
version that I was working with. So yes.

Sam


On Mon, Mar 25, 2019 at 9:11 AM Joris Meys  wrote:

> Hi Sam,
>
> Is your PATH set on your user environment variables or on the system?
> Did you try to remove the entry for R-3.5.2 ?
>
> I have tested with a standard install, and I can't reproduce your error. I
> have the exact same path in my system PATH environment variable for 3.5.3,
> and nothing for other versions.
>
> Sorry I can't be of any more help.
> Cheers
> Joris
>
> On Mon, Mar 25, 2019 at 4:54 PM Sam Albers  wrote:
>
>> Hi all,
>>
>> I am noticing some strange behaviour so I am bringing to this list. In the
>> past when I have submitted bugs to bugzilla, I have come here first for
>> confirmation/advice. Hopefully this is appropriate.
>>
>> Upgrading from R 3.5.2 to R 3.5.3 seems to have elicited some strange
>> behaviour on my Windows machine. R seems to have trouble spawning a new
>> process on my machine. You can noticing with all sort of packages, like
>> devtools, which try to spawn new R processes. Here is the replication of
>> the beahviour:
>>
>>
>>
>> ## On R 3.5.3
>> Open a command prompt:
>>
>> H:\>R
>> '"C:\PROGRA~1\R\R-35~1.3/bin/x64/Rterm.exe"' is not recognized as an
>> internal or external command,
>> operable program or batch file.
>>
>> H:\>Rscript -e "sessionInfo()"
>> R version 3.5.3 (2019-03-11)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 17134)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
>> [3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
>> [5] LC_TIME=English_Canada.1252
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.5.3
>>
>>
>>
>> ## On 3.5.2
>> H:\>R
>>
>> R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
>> Copyright (C) 2018 The R Foundation for Statistical Computing
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>>   Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>> > q()
>> Save workspace image? [y/n/c]: n
>>
>> H:\>Rscript -e "sessionInfo()"
>> R version 3.5.2 (2018-12-20)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 17134)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
>> [3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
>> [5] LC_TIME=English_Canada.1252
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.5.2
>>
>>
>>
>> ## Considerations
>> - I have manually removed both my .Renviron and .Rprofile files just to
>> ensure those weren't muddling up anything.
>> - I have my PATH set like this "C:\Program Files\R\R-3.5.3\bin"  for 3.5.3
>> and "C:\Program Files\R\R-3.5.2\bin" for 3.5.2
>> - R 3.5.3 works final if I just open the default console that ships with
>> R.
>> But then anytime I try to launch a new process I get the above error.
>>
>> A similar issue has been raised up before
>> https://stat.ethz.ch/pipermail/r-devel/2017-September/074921.html
>> https://stat.ethz.ch/pipermail/r-devel/2015-September/071714.html
>>
>> Am I missing something obvious here? Many thanks in advance for taking a
>> look.
>>
>> Regards,
>>
>> Sam
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> 
>
> ---
> Biowiskundedagen 2018-2019
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Unclear build failure ‘appending gaps’

[Karl Stamm]

That first error has resolved, and I have new errors on the build on
Windows and on OSX, while the Linux build goes fine.

I have build and check and test on OSX and Windows on my end and everything
works. There must be something different on the Bioc build servers I am not
matching up with. The OSX errors mention LateX commands, so that's not a
cross platform problem. Might be the build-server configuration.

I'm trying to get that red error sign off my build report, but I can't see
how to work on non-reproducible errors.

On Sat, Mar 23, 2019 at 10:21 AM Michael Lawrence 
wrote:

> This is due to some buggy changes to the internals of the S4Vectors
> package. I should be able to fix these today.
>
> On Sat, Mar 23, 2019 at 7:41 AM Karl Stamm  wrote:
>
>> My package rgsepd has failed build recently.
>>
>> I don't understand the error message, and need some guidance. It says
>> Error
>> building vignette, "appending gaps is not supported"
>>
>> I can't find that statement anywhere in Google, so I don't know what it's
>> referring to.  Unfortunately, my package is an automation pipeline, so
>> there's one line of code that runs many others, and the line triggering
>> the
>> error could represent any part of my pipeline.
>>
>> I've checked the build on my end before uploading code changes, so I cant
>> reproduce the error. My build was okay until very recently, I have added a
>> CITATION file which is rather lengthy, and may be impacting the vignette
>> build?
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] CRAN incoming checks fail due to non-staged installation

[David Kepplinger]

Dear Gábor,

Oddly, it does emit a NOTE due to the non-staged install, as can be seen at
https://win-builder.r-project.org/86i67mqTD9YY

The package source can be found at
https://github.com/dakep/pense-rpkg/tree/release/1.2.2

Thanks for your help,
David


On Tue, Mar 26, 2019, 3:28 AM Gábor Csárdi,  wrote:

> Hi David,
>
> if you only see
>
> install for i386
> * installing *source* package 'pense' ...
> ** using staged installation
> []
> install for x64
> * installing *source* package 'pense' ...
> ** using non-staged installation
> [...]
>
> then everything is fine, there is no NOTE here, AFAICT.
>
> If you see a NOTE about this, please post 1) a link to your package,
> and 2) a link to the win-builder output.
>
> Thanks,
> Gabor
>
> On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger
>  wrote:
> >
> > Dear Community,
> >
> > The issue persists and I don't know if it is something I can fix or if
> it's
> > a false positive from the CRAN incoming checks. As a result, the package
> is
> > archived as the old version has other issues with the new R version.
> >
> > Does someone have an idea how I can fix the issue? I have asked the CRAN
> > team last week to flag the issue as a false positive, but I haven't heard
> > back so I assume it's something I have to fix.
> >
> > Thanks,
> > David
> >
> > On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger <
> david.kepplin...@gmail.com>
> > wrote:
> >
> > > Thank you, Max, for the clarification.
> > > I have added the option "StagedInstall: yes" to the DESCRIPTION file,
> but
> > > it doesn't seem to be forcing a staged installation for x64 on
> Windows. I
> > > get the same NOTE now from winbuilder, but with more explanation which
> > > could help isolate the problem:
> > >
> > > install for i386
> > > * installing *source* package 'pense' ...
> > > ** using staged installation
> > > [...]
> > > install for x64
> > > * installing *source* package 'pense' ...
> > > not using staged install with --libs-only
> > > ** using non-staged installation
> > > [...]
> > >
> > >
> > > Best,
> > > David
> > >
> > > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon <
> > > maxime.turg...@mail.mcgill.ca> wrote:
> > >
> > >> Hi David,
> > >>
> > >> Non-staged installation is something new in R-devel:
> > >>
> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html
> > >>
> > >>
> > >> Package maintainers can opt out of it (through DESCRIPTION), and I'm
> > >> assuming CRAN wants a quick way to know if that was the case when
> > >> diagnosing a submission.
> > >>
> > >> To resolutely opt *in* (which will eventually be the default), you
> could
> > >> try adding "StagedInstall: yes" to your DESCRIPTION file.
> > >>
> > >> Of course, one question still remains: why was the behaviour different
> > >> for the two architectures.
> > >>
> > >> Max
> > >> --
> > >> *From:* R-package-devel  on
> > >> behalf of David Kepplinger 
> > >> *Sent:* March 13, 2019 3:39 PM
> > >> *To:* r-package-devel@r-project.org
> > >> *Subject:* [R-pkg-devel] CRAN incoming checks fail due to non-staged
> > >> installation
> > >>
> > >> Dear Community,
> > >>
> > >> I am trying to update the pense package on CRAN to fix `autoreconf`
> > >> problems, but the incoming checks fail for Windows (r-devel) with 2
> NOTEs.
> > >>
> > >> The first NOTE is a HTTP 403 for a http://doi.org URL which I already
> > >> know
> > >> about and can not change, but the other NOTE is more obscure to me. It
> > >> says
> > >>
> > >> * checking whether package 'pense' can be installed ... NOTE
> > >> Found the following notes/warnings:
> > >>   Non-staged installation was used
> > >>
> > >>
> > >> and when I check the install log, it says
> > >>
> > >> install for i386
> > >> * installing *source* package 'pense' ...
> > >> ** using staged installation
> > >> []
> > >> install for x64
> > >> * installing *source* package 'pense' ...
> > >> ** using non-staged installation
> > >> [...]
> > >>
> > >>
> > >> Is this a false positive or is there something I can do to force
> using a
> > >> staged installation for both architectures on Windows?
> > >>
> > >> Best,
> > >> 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
>

[[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] GDAL which version on CRAN ?

[Roger Bivand]

Apologies for out-of-thread reply.

The only feasible solutions are to maintain an off-CRAN (say drat) 
repository with binary packages you have built yourself, or use the 
existing CRAN infrastructure (rwinlib for Windows, etc., for which the 
rgdal, sf, gdalUtils, and other package maintainers are very grateful). 
Please do provide links to your source repo - it is possible that you are 
wrong about the changes needed to your code - you need to motivate your 
assertions.


Hope this clarifies,

Roger

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J=en

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

Re: [R-pkg-devel] base::assign(".ptime", proc.time(), pos = "CheckExEnv")

[Uwe Ligges]

On 26.03.2019 10:12, Camford Oxbridge wrote:

In my package, the error `base::assign(".ptime", proc.time(), pos =
"CheckExEnv")`  occurred.


Not an error, this is part of the check scripts.

Please report  the full output of the check.

Best,
Uwe Ligges




I cannot understand or fix it.

What should I do ?

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

[R-pkg-devel] base::assign(".ptime", proc.time(), pos = "CheckExEnv")

[Camford Oxbridge]

In my package, the error `base::assign(".ptime", proc.time(), pos =
"CheckExEnv")`  occurred.

I cannot understand or fix it.

What should I do ?

[[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] CRAN incoming checks fail due to non-staged installation

[Gábor Csárdi]

Hi David,

if you only see

install for i386
* installing *source* package 'pense' ...
** using staged installation
[]
install for x64
* installing *source* package 'pense' ...
** using non-staged installation
[...]

then everything is fine, there is no NOTE here, AFAICT.

If you see a NOTE about this, please post 1) a link to your package,
and 2) a link to the win-builder output.

Thanks,
Gabor

On Tue, Mar 26, 2019 at 12:13 AM David Kepplinger
 wrote:
>
> Dear Community,
>
> The issue persists and I don't know if it is something I can fix or if it's
> a false positive from the CRAN incoming checks. As a result, the package is
> archived as the old version has other issues with the new R version.
>
> Does someone have an idea how I can fix the issue? I have asked the CRAN
> team last week to flag the issue as a false positive, but I haven't heard
> back so I assume it's something I have to fix.
>
> Thanks,
> David
>
> On Wed, Mar 13, 2019 at 3:34 PM David Kepplinger 
> wrote:
>
> > Thank you, Max, for the clarification.
> > I have added the option "StagedInstall: yes" to the DESCRIPTION file, but
> > it doesn't seem to be forcing a staged installation for x64 on Windows. I
> > get the same NOTE now from winbuilder, but with more explanation which
> > could help isolate the problem:
> >
> > install for i386
> > * installing *source* package 'pense' ...
> > ** using staged installation
> > [...]
> > install for x64
> > * installing *source* package 'pense' ...
> > not using staged install with --libs-only
> > ** using non-staged installation
> > [...]
> >
> >
> > Best,
> > David
> >
> > On Wed, Mar 13, 2019 at 1:21 PM Maxime Turgeon <
> > maxime.turg...@mail.mcgill.ca> wrote:
> >
> >> Hi David,
> >>
> >> Non-staged installation is something new in R-devel:
> >> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/index.html
> >>
> >>
> >> Package maintainers can opt out of it (through DESCRIPTION), and I'm
> >> assuming CRAN wants a quick way to know if that was the case when
> >> diagnosing a submission.
> >>
> >> To resolutely opt *in* (which will eventually be the default), you could
> >> try adding "StagedInstall: yes" to your DESCRIPTION file.
> >>
> >> Of course, one question still remains: why was the behaviour different
> >> for the two architectures.
> >>
> >> Max
> >> --
> >> *From:* R-package-devel  on
> >> behalf of David Kepplinger 
> >> *Sent:* March 13, 2019 3:39 PM
> >> *To:* r-package-devel@r-project.org
> >> *Subject:* [R-pkg-devel] CRAN incoming checks fail due to non-staged
> >> installation
> >>
> >> Dear Community,
> >>
> >> I am trying to update the pense package on CRAN to fix `autoreconf`
> >> problems, but the incoming checks fail for Windows (r-devel) with 2 NOTEs.
> >>
> >> The first NOTE is a HTTP 403 for a http://doi.org URL which I already
> >> know
> >> about and can not change, but the other NOTE is more obscure to me. It
> >> says
> >>
> >> * checking whether package 'pense' can be installed ... NOTE
> >> Found the following notes/warnings:
> >>   Non-staged installation was used
> >>
> >>
> >> and when I check the install log, it says
> >>
> >> install for i386
> >> * installing *source* package 'pense' ...
> >> ** using staged installation
> >> []
> >> install for x64
> >> * installing *source* package 'pense' ...
> >> ** using non-staged installation
> >> [...]
> >>
> >>
> >> Is this a false positive or is there something I can do to force using a
> >> staged installation for both architectures on Windows?
> >>
> >> Best,
> >> 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

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