Re: [Bioc-devel] Error with InteractionSet package

[Aaron Lun]

The randomness of the errors is concerning, especially given that none 
of these functions should be calling compiled code yet. Can you produce 
a minimal working example that reproducibly triggers at least one of the 
errors? And post your session information.


-Aaron

On 08/11/16 17:34, Ioannis Vardaxis wrote:

Hi,

I am trying to combine two GRanges from two anchors of same length in to a 
Gitnteractions object and I get the following error:


PairedData=InteractionSet::GInteractions(anchor1=Anchor1,anchor2=Anchor2)

Error in .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = 
regions,  :
  first and second anchor vectors have different lengths

length(Anchor1)

[1] 33705839

length(Anchor2)

[1] 33705839

traceback()

5: stop(msg)
4: .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = regions,
   metadata = metadata, mode = mode)
3: .local(anchor1, anchor2, regions, ...)
2: InteractionSet::GInteractions(anchor1 = Anchor1, anchor2 = Anchor2)
1: InteractionSet::GInteractions(anchor1 = Anchor1, anchor2 = Anchor2)

While they clearly have the same length.

If I then run it again it works fine.

If I then run again one more time I get:
Error in .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = 
regions,  :
  all anchor indices must be finite integers
In addition: Warning message:
In new.pos[o] <- new.pos :
  number of items to replace is not a multiple of replacement length

I run it again and I get the correct results.

It seems like it is quite random if I get en error or not.

--
Ioannis Vardaxis
Stipendiat IMF
NTNU

[[alternative HTML version deleted]]

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



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

Re: [Bioc-devel] download stats

[Kasper Daniel Hansen]

This is a bit embarrassing.  Somehow I was convinced it was December.  All
looks fine.("... you have gained a level in Distracted Professorship").

Kasper

On Tue, Nov 8, 2016 at 11:50 AM, Hervé Pagès  wrote:

> Hi Kasper,
>
> The download stats just got updated:
>
>   http://bioconductor.org/packages/stats/
>
> They are updated twice a week, on Tuesday and Friday between 8
> and 9 AM PST. Note that because of how the download log files are
> generated and propagated to the machine where the stats are computed,
> and because of the time it takes to generate the stats reports for
> all the packages, the current stats don't take into account the
> downloads that happened during the last 24 hours (more or less).
>
> Cheers,
> H.
>
>
> On 11/08/2016 07:50 AM, Kasper Daniel Hansen wrote:
>
>> It was pointed out to me that the (sub) heading on the page tells me that
>> the script for counting downloads was last run Nov 4th, explaining the
>> discrepancy.
>>
>> On Tue, Nov 8, 2016 at 9:24 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> Is there something wrong with the download stats in November.  All the
>>> packages I look at have lost about 85-90% compared to other months of the
>>> year:
>>>   http://bioconductor.org/packages/stats/bioc/GenomicRanges/
>>>
>>> Best,
>>> Kasper
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

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

Re: [Rd] Running package tests and not stop on first fail

[Hervé Pagès]

Thanks Martin.

These changes are great and improve the usefulness of 'R CMD check'.
Especially in the context of the Bioconductor daily builds where
we'll use --no-stop-on-test-error so developers will get a full
picture of all the errors in their package at once.

Cheers,
H.

To provide some context to my special interest for this,

On 11/08/2016 01:34 AM, Martin Maechler wrote:

Hervé Pagès 
on Mon, 7 Nov 2016 14:37:15 -0800 writes:


> On 11/05/2016 01:53 PM, Martin Maechler wrote:
>>> Oliver Keyes 
>>> on Fri, 4 Nov 2016 12:42:54 -0400 writes:
>>
>> > On Friday, 4 November 2016, Martin Maechler
>> >  wrote:
>>
>> >> > Dirk Eddelbuettel >
>> >> > on Fri, 4 Nov 2016 10:36:52 -0500 writes:
>> >>
>> >> > On 4 November 2016 at 16:24, Martin Maechler wrote: |
>> >> My > proposed name '--no-stop-on-error' was a quick shot;
>> >> if | > somebody has a more concise or better "English
>> >> style" > wording | (which is somewhat compatible with all
>> >> the other > options you see | from 'R CMD check --help'),
>> >> | please > speak up.
>> >>
>> >> > Why not keep it simple?  The similar feature this most
>> >> > resembles is 'make -k' and its help page has
>> >>
>> >> > -k, --keep-going
>> >>
>> >> > Continue as much as possible after an > error.  While
>> >> the target that failed, and those that > depend on it,
>> >> cannot be remade, the other dependencies of > these
>> >> targets can be processed all the same.
>> >>
>> >> Yes, that would be quite a bit simpler and nice in my
>> >> view.  One may think it to be too vague,
>>
>> > Mmn, I would agree on vagueness (and it breaks the pattern
>> > set by other flags of human-readability). Deep familiarity
>> > with make is probably not something we should ask of
>> > everyone who needs to test a package, too.
>>
>> > I quite like stop-on-error=true (exactly the same as the
>> > previous suggestion but shaves off some characters by
>> > inverting the Boolean)
>>
>> Thank you, Brian, Dirk and Oliver for these (and some offline)
>> thoughts and suggestions!
>>
>> My current summary:
>>
>> 1) I really don't want a  --=value
>> but rather stay with logical/binary variables that "express
>> themselves"... in the same way I strongly prefer
>>
>> if (A_is_special)   
>> to
>> if (A_special == TRUE)  
>>
>> for a logical variable A_* .   Yes, this is mostly a matter
>> of taste,.. but related to how R style itself "works"
>>
>> 2) Brian mentioned that this is only about ./tests/ tests which
>> are continued, not about the Examples which are treated separately.
>> That's why we had contemplated additionally using 'tests' (because that's
>> the directory name used for unit/regression/.. tests) in the option
>> name.
>>
>> Even though Brian is correct, ideally we *would* want to also influence 
the
>> examples' running to *not* stop on a first error..   However that would
>> need more work, reorganizing how the examples are run and that may not be
>> worth the pain.   However it should be considered a goal in the long run.

> My name is Hervé, and I was not suggesting that what happens with the
> examples should be changed. I was just preaching consistency (again
> sorry) between what happens with the examples and what happens with
> the tests.

Thank you, Hervé and excuse me for not answering more focused on
what you said.
I think I do understand what you say (at least by now :-)) and
agree that consistency is something important and to be strived for,
also with these options.

> Why not simply change the latter?
> Do we really need an option to control this?

Very good questions.  If the change could be made much better,
I'd agree we'd not need a new option because the change could be
considerided uniformly better than the current (R 3.3.2, say) behavior.
However the change as it is currently, is not good enough to be
the only option (see below).

> The behavior was changed for the examples a couple of
> years ago and nobody felt the need to introduce an option
> to control this at the time.

Yes, that change was made very nicely (not by me) and I'd say
the result *was* uniformly better than the previous behavior, so
there did not seem much of a reason to still provide the old behavior.

  >> After all that, I tend to remain with the original proposed name. It 
is at
  >> least easy to pronounce and spell correctly...

> Unless --no-stop-on-error controls both (i.e. examples and tests), and
> both behave the same way by default, this is a misnomer.

Well, if you choose the option, there *is* no stop on errors anymore
... because the 

[Rd] confusing error from model.frame when var name=function name

[Ben Bolker]

  This took me a few minutes of head-scratching:

Normally model.frame() gives an easily interpretable error if a variable
can't be found (in the data frame *or* elsewhere in the environment):

model.frame(~a,data=data.frame(x=1:5))
## Error in eval(predvars, data, env) : object 'a' not found

Now suppose you happen to have a variable name that matches an R
function name:

model.frame(~replicate,data=data.frame(x=1:5))
## Error in model.frame.default(~replicate, data = data.frame(x = 1:5)) :
##  object is not a matrix

   This happens somewhere inside a .External() call:

data <- .External2(C_modelframe, formula, rownames, variables,
varnames, extras, extranames, subset, na.action)

so I haven't had the heart to track it all the way to its source yet.

  FWIW this happens whether the function is built-in or user-created.

  I don't think the possibly forthcoming "well just don't name your
variables that way" advice is entirely reasonable here ('replicate' is a
perfectly respectable variable name, as are many names that happen to
coincide with R function names (like 'c' !)

  I can easily implement my own checking function, at least for the
contents of the data frame (all(all.vars(formula) %in% names(data)):
checking for *non-function variables only* that exist anywhere in the
searchable environment is a bigger task), but this seems to me to be an
infelicity that would be lovely to have corrected ...

  I will post to R-bugs if this is not shot down in flames here.

  cheers
Ben Bolker

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

[Bioc-devel] Error with InteractionSet package

[Ioannis Vardaxis]

Hi,

I am trying to combine two GRanges from two anchors of same length in to a 
Gitnteractions object and I get the following error:

> PairedData=InteractionSet::GInteractions(anchor1=Anchor1,anchor2=Anchor2)
Error in .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = 
regions,  :
  first and second anchor vectors have different lengths
> length(Anchor1)
[1] 33705839
> length(Anchor2)
[1] 33705839
> traceback()
5: stop(msg)
4: .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = regions,
   metadata = metadata, mode = mode)
3: .local(anchor1, anchor2, regions, ...)
2: InteractionSet::GInteractions(anchor1 = Anchor1, anchor2 = Anchor2)
1: InteractionSet::GInteractions(anchor1 = Anchor1, anchor2 = Anchor2)

While they clearly have the same length.

If I then run it again it works fine.

If I then run again one more time I get:
Error in .new_GInteractions(anchor1 = anchor1, anchor2 = anchor2, regions = 
regions,  :
  all anchor indices must be finite integers
In addition: Warning message:
In new.pos[o] <- new.pos :
  number of items to replace is not a multiple of replacement length

I run it again and I get the correct results.

It seems like it is quite random if I get en error or not.

--
Ioannis Vardaxis
Stipendiat IMF
NTNU

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] download stats

[Hervé Pagès]

Hi Kasper,

The download stats just got updated:

  http://bioconductor.org/packages/stats/

They are updated twice a week, on Tuesday and Friday between 8
and 9 AM PST. Note that because of how the download log files are
generated and propagated to the machine where the stats are computed,
and because of the time it takes to generate the stats reports for
all the packages, the current stats don't take into account the
downloads that happened during the last 24 hours (more or less).

Cheers,
H.


On 11/08/2016 07:50 AM, Kasper Daniel Hansen wrote:

It was pointed out to me that the (sub) heading on the page tells me that
the script for counting downloads was last run Nov 4th, explaining the
discrepancy.

On Tue, Nov 8, 2016 at 9:24 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:


Is there something wrong with the download stats in November.  All the
packages I look at have lost about 85-90% compared to other months of the
year:
  http://bioconductor.org/packages/stats/bioc/GenomicRanges/

Best,
Kasper



[[alternative HTML version deleted]]

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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] download stats

[Kasper Daniel Hansen]

It was pointed out to me that the (sub) heading on the page tells me that
the script for counting downloads was last run Nov 4th, explaining the
discrepancy.

On Tue, Nov 8, 2016 at 9:24 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> Is there something wrong with the download stats in November.  All the
> packages I look at have lost about 85-90% compared to other months of the
> year:
>   http://bioconductor.org/packages/stats/bioc/GenomicRanges/
>
> Best,
> Kasper
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Availability shield URLs

[Leonardo Collado Torres]

Awesome, thanks Dan!

On Tue, Nov 8, 2016 at 9:40 AM, Martin Morgan  wrote:

> On 11/02/2016 11:54 AM, Leonardo Collado Torres wrote:
>
>> Hi,
>>
>> I'm just curious why
>> http://www.bioconductor.org/shields/availability/release/derfinder.svg
>> works but http://www.bioconductor.org/shields/availability/release/rec
>> ount.svg
>> doesn't (http://www.bioconductor.org/shields/availability/3.4/recount.svg
>> does work). The same is true for devel.
>>
>> derfinder has been around longer than recount, so that might be it. I
>> don't think that it's an alphabetical issue since
>> http://www.bioconductor.org/shields/availability/release/regionReport.svg
>> does work.
>>
>> This is a very minor thing. It's just easier to simply use
>> release/devel instead of 3.4/3.5 and changing it every cycle.
>>
>
> These are back to functioning now, thanks to some detective work from Dan.
> Thanks for the report. Martin
>
>
>> Best,
>> Leo
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Availability shield URLs

[Martin Morgan]

On 11/02/2016 11:54 AM, Leonardo Collado Torres wrote:

Hi,

I'm just curious why
http://www.bioconductor.org/shields/availability/release/derfinder.svg
works but http://www.bioconductor.org/shields/availability/release/recount.svg
doesn't (http://www.bioconductor.org/shields/availability/3.4/recount.svg
does work). The same is true for devel.

derfinder has been around longer than recount, so that might be it. I
don't think that it's an alphabetical issue since
http://www.bioconductor.org/shields/availability/release/regionReport.svg
does work.

This is a very minor thing. It's just easier to simply use
release/devel instead of 3.4/3.5 and changing it every cycle.


These are back to functioning now, thanks to some detective work from 
Dan. Thanks for the report. Martin




Best,
Leo

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




This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [Bioc-devel] Question about sumbition process and biocviews

[Ioannis Vardaxis]

Create a folder \inst and place the REFERENCES.bib in it. (see attached)
Then in the R function add: #’ @references \insertRef{ENCODE_1}{PkgA}.
You have to have the Rdpack installed.


-- 
Ioannis Vardaxis

Stipendiat IMF
NTNU



On 07/11/16 13:49, "Ioannis Vardaxis" 
wrote:

>
>
>
>
>
>On 07/11/16 13:43, "Martin Morgan"  wrote:
>
>>On 11/07/2016 07:35 AM, Ioannis Vardaxis wrote:
>>> Ok,
>>>
>>> Consider an R.script with a function and roxygen entries above the
>>> function out the author etc. One of the entries there is the following:
>>>#'
>>> @references \insertRef{key}{pkg}.
>>> This macro is given by the Rdpack R package for using references in the
>>> help pages. Where I have created a REFERENCES.bib file placed in the
>>>/inst
>>> folder containing the references I want to use.
>>> ³key² is the references key from the bib file and ³pkg² is my package
>>>name.
>>
>>what minimal changes do I need to make to this package to be able to
>>reproduce the warnings below?
>>
>>https://github.com/mtmorgan/PkgA/tree/parse-Rd-insertRef
>>
>>Martin
>>
>>>
>>> Roxygen produces the expected output when I use the above macro.
>>>
>>> Now when I run:
>>> system("R CMD build pkg²)#runs ok
>>> system("R CMD BiocCheck pkg_0.99.0.tar.gz²)# gives the following :
>>>
>>> * This is BiocCheck, version 1.11.0.
>>> * BiocCheck is a work in progress. Output and severity of issues may
>>>   change.
>>> * Installing package...
>>> * Checking for version number mismatch...
>>> * Checking vignette directory...
>>> * This is a software package, checking vignette directories...
>>>   # of chunks: 40, # of eval=FALSE: 0 (0%)
>>> * Checking version number...
>>> * Checking version number validity...
>>> * Checking R Version dependency...
>>> * Checking biocViews...
>>> * Checking that biocViews are present...
>>> * Checking for non-trivial biocViews...
>>> * Checking that biocViews come from the same category...
>>> * Checking biocViews validity...
>>> * Checking for recommended biocViews...
>>> * Checking build system compatibility...
>>> * Checking for blank lines in DESCRIPTION...
>>> * Checking for whitespace in DESCRIPTION field names...
>>> * Checking that Package field matches dir/tarball name...
>>> * Checking for Version field...
>>> * Checking for valid maintainer...
>>> * Checking unit tests...
>>> * NOTE: Consider adding unit tests. We strongly encourage them. See
>>>   
>>>http://bioconductor.org/developers/how-to/unitTesting-guidelines/.
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>A
>>>na
>>> lysisStatistics.Rd:106: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>e
>>>xp
>>> ortBS.Rd:77: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>I
>>>nt
>>> erPETs-class.Rd:23: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>I
>>>nt
>>> raPETs-class.Rd:23: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>M
>>>AC
>>> PET.Rd:53: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ea
>>> kCallerUlt.Rd:186: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ea
>>> kCallerUlt.Rd:188: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ea
>>> kFinder.Rd:97: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ea
>>> ksToGRanges.Rd:68: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ET
>>> Classification.Rd:138: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>P
>>>ET
>>> sToGRanges.Rd:73: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>p
>>>lo
>>> t.Rd:168: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>R
>>>eg
>>> ionSegmentation.Rd:80: unknown macro '\insertRef'
>>> Warning in parse_Rd(infile) :
>>>
>>> 
>>>/var/folders/6n/6y8cjthx4sb0hk5k5w8q3lw4gn/T//RtmpNOtV3V/MACPET/man/
>>>S
>>>am

Re: [Bioc-devel] Question about sumbition process and biocviews

[Martin Morgan]

On 11/08/2016 08:26 AM, Ioannis Vardaxis wrote:


Create a folder \inst and place the REFERENCES.bib in it. (see attached)
Then in the R function add: #’ @references \insertRef{ENCODE_1}{PkgA}.
You have to have the Rdpack installed.


when I do that (see 
https://github.com/mtmorgan/PkgA/tree/parse-Rd-insertRef) and run R CMD 
build I see


$ R CMD build PkgA
* checking for file 'PkgA/DESCRIPTION' ... OK
* preparing 'PkgA':
* checking DESCRIPTION meta-information ... OK
Warning: /tmp/RtmpFDYMzj/Rbuild2deb22881ea6/PkgA/man/fun.Rd:13: unknown 
macro '\insertRef'

* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'PkgA_0.0.1.tar.gz'

so the problem reported by BiocCheck is already visible in R CMD build.

Consulting the vignette for Rdpack

https://cran.r-project.org/web/packages/Rdpack/vignettes/Inserting_bibtex_references.pdf

I see that the solution is to add the line

RdMacros: Rdpack

to the DESCRIPTION file. I disagree with the package author that the 
Rdpack package does not need to be in the Suggests: field; if it were 
not there then how would something like the Bioconductor build system 
know that it needed to have the Rdpack available when the package is built?


I updated the github repo with correct package.

Martin








This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [Rd] Running package tests and not stop on first fail

[Martin Maechler]

> Hervé Pagès 
> on Mon, 7 Nov 2016 14:37:15 -0800 writes:

> On 11/05/2016 01:53 PM, Martin Maechler wrote:
>>> Oliver Keyes 
>>> on Fri, 4 Nov 2016 12:42:54 -0400 writes:
>> 
>> > On Friday, 4 November 2016, Martin Maechler
>> >  wrote:
>> 
>> >> > Dirk Eddelbuettel >
>> >> > on Fri, 4 Nov 2016 10:36:52 -0500 writes:
>> >>
>> >> > On 4 November 2016 at 16:24, Martin Maechler wrote: |
>> >> My > proposed name '--no-stop-on-error' was a quick shot;
>> >> if | > somebody has a more concise or better "English
>> >> style" > wording | (which is somewhat compatible with all
>> >> the other > options you see | from 'R CMD check --help'),
>> >> | please > speak up.
>> >>
>> >> > Why not keep it simple?  The similar feature this most
>> >> > resembles is 'make -k' and its help page has
>> >>
>> >> > -k, --keep-going
>> >>
>> >> > Continue as much as possible after an > error.  While
>> >> the target that failed, and those that > depend on it,
>> >> cannot be remade, the other dependencies of > these
>> >> targets can be processed all the same.
>> >>
>> >> Yes, that would be quite a bit simpler and nice in my
>> >> view.  One may think it to be too vague,
>> 
>> > Mmn, I would agree on vagueness (and it breaks the pattern
>> > set by other flags of human-readability). Deep familiarity
>> > with make is probably not something we should ask of
>> > everyone who needs to test a package, too.
>> 
>> > I quite like stop-on-error=true (exactly the same as the
>> > previous suggestion but shaves off some characters by
>> > inverting the Boolean)
>> 
>> Thank you, Brian, Dirk and Oliver for these (and some offline)
>> thoughts and suggestions!
>> 
>> My current summary:
>> 
>> 1) I really don't want a  --=value
>> but rather stay with logical/binary variables that "express
>> themselves"... in the same way I strongly prefer
>> 
>> if (A_is_special)   
>> to
>> if (A_special == TRUE)  
>> 
>> for a logical variable A_* .   Yes, this is mostly a matter
>> of taste,.. but related to how R style itself "works"
>> 
>> 2) Brian mentioned that this is only about ./tests/ tests which
>> are continued, not about the Examples which are treated separately.
>> That's why we had contemplated additionally using 'tests' (because that's
>> the directory name used for unit/regression/.. tests) in the option
>> name.
>> 
>> Even though Brian is correct, ideally we *would* want to also influence 
the
>> examples' running to *not* stop on a first error..   However that would
>> need more work, reorganizing how the examples are run and that may not be
>> worth the pain.   However it should be considered a goal in the long run.

> My name is Hervé, and I was not suggesting that what happens with the
> examples should be changed. I was just preaching consistency (again
> sorry) between what happens with the examples and what happens with
> the tests. 

Thank you, Hervé and excuse me for not answering more focused on
what you said.
I think I do understand what you say (at least by now :-)) and
agree that consistency is something important and to be strived for,
also with these options.

> Why not simply change the latter?
> Do we really need an option to control this? 

Very good questions.  If the change could be made much better,
I'd agree we'd not need a new option because the change could be
considerided uniformly better than the current (R 3.3.2, say) behavior.
However the change as it is currently, is not good enough to be
the only option (see below). 

> The behavior was changed for the examples a couple of
> years ago and nobody felt the need to introduce an option
> to control this at the time.

Yes, that change was made very nicely (not by me) and I'd say
the result *was* uniformly better than the previous behavior, so
there did not seem much of a reason to still provide the old behavior.

  >> After all that, I tend to remain with the original proposed name. It 
is at
  >> least easy to pronounce and spell correctly...

> Unless --no-stop-on-error controls both (i.e. examples and tests), and 
> both behave the same way by default, this is a misnomer.

Well, if you choose the option, there *is* no stop on errors anymore
... because the examples nowadays never stop the (R CMD check Pkg) 
from running on an error as we've mentioned above.

[[--- Digression on  Examples' checking 

  However / on the other hand: Because of the way the examples
  are run --- efficiently from one single R source file --- it
  is not so easy there, to let them run further: The first error
  from all the examples