Re: [Bioc-devel] Filter classes moved from ensembldb to AnnotationFilter

[Rainer Johannes]

Hi Herve

> On 7 Apr 2017, at 07:42, Hervé Pagès  wrote:
> 
> Hi Johannes,
> 
> Thanks for contacting the developers of the packages affected by this
> change. FWIW Pbase is also affected (didn't see it in your list):
> 

I fixed Pbase - changes have not been committed to Bioc yet (asked Laurent for 
that).
I did also fix wiggleplotr and made a pull request, but the developer did not 
yet react to that.

cheers, jo

> https://bioconductor.org/checkResults/3.5/bioc-LATEST/Pbase/malbec2-buildsrc.html
> 
> H.
> 
> 
> On 04/06/2017 01:07 PM, Rainer Johannes wrote:
>> @Florian: nothing you have to change. I checked all packages and 70 of them 
>> have problems related to the relocation of the filters. For 63 of them 
>> everything should be fine once the updated versions of biovizBase and ggbio 
>> are built. This fixes also Gviz and most of the packages with them.
>> 
>> For the remaining packages I either provided patches, pull requests or am in 
>> contact with the developers. I checked these packages and there is not very 
>> much more to do than importing filters from AnnotationFilter instead of 
>> ensembldb.
>> 
>> Fingers crossed - tomorrow everything could be OK again - and sorry again 
>> for all the havoc
>> 
>> cheers, jo
>> 
>> On 6 Apr 2017, at 21:27, Obenchain, Valerie 
>> mailto:valerie.obench...@roswellpark.org>>
>>  wrote:
>> 
>> We've updated the release schedule and moved the deadline for errors to
>> next Friday, April 14.
>> 
>> Valerie
>> 
>> 
>> On 04/06/2017 10:29 AM, Stian Lågstad wrote:
>> How does the error deadline tomorrow 
>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bioconductor.org_&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=jLQ9KUUm3u9dA66MERqNGNYccQtXR7ieDcLKZZMrSII&s=mdDgNHoW4wRbQFZFJ4a7r2gUE_n6XQspfZvlgjQ94c8&e=
>> developers/release-schedule/) affect packages that are still red because of
>> this change? I don't know what else to do other than to wait for changes in
>> Gviz (which my package is dependent on).
>> 
>> Thanks.
>> 
>> On Tue, Apr 4, 2017 at 10:05 PM, Michael Lawrence 
>> mailto:lawrence.mich...@gene.com>
>> wrote:
>> Sorry I have been traveling. Will get to it soon.
>> 
>> On Apr 4, 2017 12:58 PM, "Rainer Johannes" 
>> mailto:johannes.rai...@eurac.edu>>
>> wrote:
>> 
>> Hi Herve,
>> 
>> sorry for all the reds - actually I provided the patches to biovizBase
>> and
>> ggbio, but it did not work out that smoothly that I hoped. For the other
>> packages that depend on ensembldb there's no problem or only small
>> changes
>> required (did contact the developers).
>> Fingers crossed that Michael can patch biovizBase and ggbio soon.
>> 
>> cheers, jo
>> 
>> On 4 Apr 2017, at 21:34, Hervé Pagès 
>> mailto:hpa...@fredhutch.org>> wrote:
>> 
>> Hi Johannes,
>> 
>> This move is generating a lot of red today on the build report.
>> Hopefully biovizBase and ggbio can be fixed quickly. Note that
>> maybe a smoother path would have been to notify the maintainers
>> of these packages first and wait that they make the required
>> changes (i.e. to import the filters from AnnotationFilter)
>> before modifying ensembldb. Maybe for next time ;-)
>> 
>> Cheers,
>> H.
>> 
>> On 04/04/2017 04:02 AM, Rainer Johannes wrote:
>> 
>> On 4 Apr 2017, at 10:59, Stian Lågstad 
>> mailto:stianlags...@gmail.com>> :
>> stianlags...@gmail.com>> wrote:
>> Hi,
>> 
>> Thanks again for notifying me about the changes needed in chimeraviz.
>> Right now I'm having problems installing Gviz - I get these errors:
>> """
>> No methods found in "GenomicAlignments" for requests:
>> pmapFromTranscripts
>> Error : object 'GRangesFilter' is not exported by
>> 'namespace:ensembldb'
>> ERROR: lazy loading failed for package 'Gviz'
>> """
>> 
>> Are these errors caused by the change in ensembldb? If so: Do you know
>> how I can keep developing without having to wait for Gviz?
>> 
>> These come from biovizBase which Gviz imports. I've sent Micheal the
>> fixes for biovizBase and ggbio that should fix this.
>> We need to wait for the changes to be propagated, since also for
>> ensembldb I get today still version 1.99.12 but not the new 1.99.13.
>> On Mon, Apr 3, 2017 at 8:59 AM, Rainer Johannes <
>> johannes.rai...@eurac.edu>
>>  wrote:
>> Dear all,
>> 
>> I've just committed a change in ensembldb (version 1.99.13) that
>> removes all filter classes from it and imports them from the
>> AnnotationFilter package. This change will break biovizBase and ggbio
>> (and
>> all packages downstream of them, e.g. Gviz). I've already sent Michael
>> Lawrence patches to fix both packages, but  there might still be some
>> problems in the upcoming build reports I guess.
>> I've also contacted the developers of the TVTB and chimeraviz packages
>> and made them aware of the change. Could be that there are other packages
>> out there possibly affected by the change. If so, let me know 

Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Ramon Diaz-Uriarte]

Dear Martin and Valerie,


I am not sure how to proceed here since the 14th is approaching and I still
see this error (in both my package and at least one other package
---arrayQualityMetrics).


I could comment out the plotting code for the vignette and examples when
running on El Capitan. Is this a possible workaround that I should
implement? If this is reasonable, what is the recommended way to find out
the code is running in El Capitan and not Mavericks? (For instance, can I
tell from Sys.info()["sysname"]? --I do not have access to a Mac).


Martin mentioned that the Cairo package requires a binary installation that
is not yet available.  Should I continue to wait? There is not a lot of
margin for changing the code, uploading to BioC, waiting for the build, and
making sure it works.  What if it continues to fail on El Capitan by the
14th?



Best,


R.




On Mon, 03-04-2017, at 18:34:26, Martin Morgan  
wrote:
> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear All,
>>
>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>> segfault that seems to happen when plotting (in a call to plotting that
>> happens inside a mclapply)
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
>>
>>
>> these are some of the lines of the traceback:
>>
>> Traceback:
>>  1: dev.hold()
>>  2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 
>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 
>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 
>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 
>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 
>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 
>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), 
>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 
>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, 
>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, 
>> -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, 
>> -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = 
>> quote("Chromosomal location"), col = c("orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>  "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = 
>> FALSE, main = quote("Chr4@L.1"), pch = 20)
>>  3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 
>> 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 
>> 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 
>> 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 
>> 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 
>> 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 
>> 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 
>> 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172, 
>> -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 
>> 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, 
>> -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, 
>> -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal 
>> location"), col = c("orange", "orange", "orange", "orange", "orange",
>>  "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange"), cex = 1, axes = FALSE, main = 
>> quote("Chr4@L.1"), pch = 20)
>>  4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))
>>
>>
>>
>> It seems that what triggers the problem is an innocuous plot.default
>> followed by dev.hold? (none of which I call explicitly in my code)
>
> I was able to reproduce this with
>
> $ cat segfault-test.R
> xx <- parallel::mclapply(1:2, function(i) {
>  Cairo::CairoPNG(filename = paste("plt", i, ".png", sep=''))
>  dev.hold()
> })
>
> $ R -f segfault-test.R
>
> The El-Capitain builds are still in a great deal of flux, and in
> particular the Cairo package requires a binary installation that is not
> yet available (the Cairo package is used is a

Re: [Bioc-devel] PROTECT errors in Bioconductor packages

[Hervé Pagès]

On 04/06/2017 03:29 AM, Michael Lawrence wrote:

On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
 wrote:

On 04/06/2017 05:33 AM, Aaron Lun wrote:


The tool is not perfect, so assess each report carefully.


I get a lot of warnings because the tool seems to consider that
extracting an attribute (with getAttrib(x, ...)) or extracting the
slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
returns an SEXP that needs protection. I always assumed that it
didn't because my understanding is that the returned SEXP is pointing
to a part of a pre-existing object ('x') and not to a newly created
one. So I decided I could treat it like the SEXP returned by
VECTOR_ELT(), which, AFAIK, doesn't need protection.

So I suspect these warnings are false positives but I'm not 100% sure.




I also get a warning on almost every C++ function I've written, because
I use the following code to handle exceptions:

 SEXP output=PROTECT(allocVector(...));
 try {
 // do something that might raise an exception
 } catch (std::exception& e) {
 UNPROTECT(1);
 throw; // break out of this part of the function
 }
 UNPROTECT(1);
 return output;

Presumably the check doesn't account for transfer of control to the
catch block. I find that R itself is pretty good at complaining about
stack imbalances during execution of tests, examples, etc.


'My' packages
(Rsamtools, DirichletMultinomial) had several false positives (all
associated with use of an attribute of a protected SEXP), one subtle
problem (a symbol from a PROTECT'ed package name space; the symbol could
in theory be an active binding and the value obtained not PROTECTed by
the name space), and a genuine bug

tag = NEW_CHARACTER(n);
for (int j = 0; j < n; ++j)
SET_STRING_ELT(tag, j, NA_STRING);
if ('A' == aux[0]) {
buf_A = R_alloc(2, sizeof(char));  # <<- bug
buf_A[1] = '\0';
}
...
SET_VECTOR_ELT(tags, i, tag); # PROTECT tag, too late!



I assume the bug refers to the un-PROTECT'd NEW_CHARACTER here - the
R_alloc call looks okay to me...



yes, tag needs protection.

I attributed the bug to R_alloc because I failed to reason that R_alloc
(obviously) allocates and hence can trigger a garbage collection.

Somehow it reflects my approach to PROTECTion, probably not shared by
everyone. I like to PROTECT only when necessary, rather than
indiscriminately. Probably this has no practical consequence in terms of
performance, making the code a little easier to read at the expense of
exposing me to bugs like this.



I guess it's a tradeoff between syntactic complexity and logical
complexity. You have to think pretty hard to minimize use of the
protect stack.


I prefer to call it logical obscurity ;-)

The hard thinking consists in assessing whether or not the code between
the line where a new SEXP is allocated (line X) and the line where
it's put in a safe place (line Y) can trigger garbage collection.
Hard to figure out in general indeed, but not impossible! Problem
is that the result of this assessment is valid at a certain point
in time but might change in the future, even if your code has not
changed.

So a dangerous game for virtually zero benefits.



One recommendation might be to UNPROTECT() as soon as the pointer on
the top is unneeded, rather than trying to figure out the number to
pop just before returning to R.


If you PROTECT() in a loop, you definitely want to do that. Otherwise,
does it make a big difference?



One thing that got me is that the order in which C evaluates function
call arguments is undefined. I did a lot of R_setAttrib(x,
install("foo"), allocBar()), thinking that the symbol would be
automatically protected, and allocBar() would not need protection,
since it happened last. Unfortunately, it might be evaluated first.


I got hit by this too long time ago but with defineVar() instead of
R_setAttrib():

  https://stat.ethz.ch/pipermail/r-devel/2008-January/048040.html

H.



Btw, I think my package RGtk2 got the record: 1952 errors. Luckily
almost all of them happened inside a few macros and autogenerated
code.


Martin



Cheers,

Aaron
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=su20YzStywMa_pdWblzF0RnK8ATRw-t61lOIOsi0xTU&s=JhBOw1ac5wXfV1BSjFuidxFiBTx43J7iEvZG4G0_0uU&e=




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

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=su20YzStywMa_pdWblzF0RnK8AT

Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Hervé Pagès]

Hi Ramon,

It doesn't seem that this segfault occurs in ADaCGH2 so you can
ignore it. I can't be 100% sure but I actually expect it to go away
when things are sorted out with the new El Capitan binaries.
Unfortunately it's not something we fully control so let's wait
and see...

Cheers,
H.


On 04/07/2017 12:55 AM, Ramon Diaz-Uriarte wrote:


Dear Martin and Valerie,


I am not sure how to proceed here since the 14th is approaching and I still
see this error (in both my package and at least one other package
---arrayQualityMetrics).


I could comment out the plotting code for the vignette and examples when
running on El Capitan. Is this a possible workaround that I should
implement? If this is reasonable, what is the recommended way to find out
the code is running in El Capitan and not Mavericks? (For instance, can I
tell from Sys.info()["sysname"]? --I do not have access to a Mac).


Martin mentioned that the Cairo package requires a binary installation that
is not yet available.  Should I continue to wait? There is not a lot of
margin for changing the code, uploading to BioC, waiting for the build, and
making sure it works.  What if it continues to fail on El Capitan by the
14th?



Best,


R.




On Mon, 03-04-2017, at 18:34:26, Martin Morgan  
wrote:

On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:


Dear All,

A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
segfault that seems to happen when plotting (in a call to plotting that
happens inside a mclapply)

https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ADaCGH2_veracruz2-2Dbuildsrc.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k&s=se3QJrNKC3kMzGsf88z7nuqgS_X7o08nzTQ8K7uvai4&e=


these are some of the lines of the traceback:

Traceback:
 1: dev.hold()
 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, 
-0.611, -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, 
-0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))



It seems that what triggers the problem is an innocuous plot.default
followed by dev.hold? (none of which I call explicitly in my code)


I was able to reproduce this with

$ cat segfault

Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Ramon Diaz-Uriarte]

Dear Hervé,

Thanks for your answer. I'll ignore those segfaults then.

Best,


R.


On Fri, 07-04-2017, at 08:36:40, Hervé Pagès  wrote:
> Hi Ramon,
>
> It doesn't seem that this segfault occurs in ADaCGH2 so you can
> ignore it. I can't be 100% sure but I actually expect it to go away
> when things are sorted out with the new El Capitan binaries.
> Unfortunately it's not something we fully control so let's wait
> and see...
>
> Cheers,
> H.
>
>
> On 04/07/2017 12:55 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear Martin and Valerie,
>>
>>
>> I am not sure how to proceed here since the 14th is approaching and I still
>> see this error (in both my package and at least one other package
>> ---arrayQualityMetrics).
>>
>>
>> I could comment out the plotting code for the vignette and examples when
>> running on El Capitan. Is this a possible workaround that I should
>> implement? If this is reasonable, what is the recommended way to find out
>> the code is running in El Capitan and not Mavericks? (For instance, can I
>> tell from Sys.info()["sysname"]? --I do not have access to a Mac).
>>
>>
>> Martin mentioned that the Cairo package requires a binary installation that
>> is not yet available.  Should I continue to wait? There is not a lot of
>> margin for changing the code, uploading to BioC, waiting for the build, and
>> making sure it works.  What if it continues to fail on El Capitan by the
>> 14th?
>>
>>
>>
>> Best,
>>
>>
>> R.
>>
>>
>>
>>
>> On Mon, 03-04-2017, at 18:34:26, Martin Morgan 
>>  wrote:
>>> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:

 Dear All,

 A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
 segfault that seems to happen when plotting (in a call to plotting that
 happens inside a mclapply)

 https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ADaCGH2_veracruz2-2Dbuildsrc.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k&s=se3QJrNKC3kMzGsf88z7nuqgS_X7o08nzTQ8K7uvai4&e=


 these are some of the lines of the traceback:

 Traceback:
  1: dev.hold()
  2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 
 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 
 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 
 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 
 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 
 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 
 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), 
 c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 
 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, 
 -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, 
 -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, 
 -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio",
  xlab = quote("Chromosomal location"), col = c("orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1,  
axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
  3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 
 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 
 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 
 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 
 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 
 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 
 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 
 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172, 
 -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 
 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, 
 -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, 
 -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = 
 quote("Chromosomal location"), col = c("orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "orange", "orange", "orange", "orange", "orange", "orange",  
"orange", "orange", "orange", "orange", "orange", "orange", 
 "orange", "o

Re: [Bioc-devel] PROTECT errors in Bioconductor packages

[luke-tierney]

On Fri, 7 Apr 2017, Hervé Pagès wrote:


On 04/06/2017 03:29 AM, Michael Lawrence wrote:

On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
 wrote:

On 04/06/2017 05:33 AM, Aaron Lun wrote:


The tool is not perfect, so assess each report carefully.


I get a lot of warnings because the tool seems to consider that
extracting an attribute (with getAttrib(x, ...)) or extracting the
slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
returns an SEXP that needs protection. I always assumed that it
didn't because my understanding is that the returned SEXP is pointing
to a part of a pre-existing object ('x') and not to a newly created
one. So I decided I could treat it like the SEXP returned by
VECTOR_ELT(), which, AFAIK, doesn't need protection.

So I suspect these warnings are false positives but I'm not 100% sure.


If you are not 100% sure then you should protect :-)

There are some cases, in particular related to compact row names on
data frames, where getAttrib will allocate.

Best,

luke






I also get a warning on almost every C++ function I've written, because
I use the following code to handle exceptions:

 SEXP output=PROTECT(allocVector(...));
 try {
 // do something that might raise an exception
 } catch (std::exception& e) {
 UNPROTECT(1);
 throw; // break out of this part of the function
 }
 UNPROTECT(1);
 return output;

Presumably the check doesn't account for transfer of control to the
catch block. I find that R itself is pretty good at complaining about
stack imbalances during execution of tests, examples, etc.


'My' packages
(Rsamtools, DirichletMultinomial) had several false positives (all
associated with use of an attribute of a protected SEXP), one subtle
problem (a symbol from a PROTECT'ed package name space; the symbol could
in theory be an active binding and the value obtained not PROTECTed by
the name space), and a genuine bug

tag = NEW_CHARACTER(n);
for (int j = 0; j < n; ++j)
SET_STRING_ELT(tag, j, NA_STRING);
if ('A' == aux[0]) {
buf_A = R_alloc(2, sizeof(char));  # <<- bug
buf_A[1] = '\0';
}
...
SET_VECTOR_ELT(tags, i, tag); # PROTECT tag, too late!



I assume the bug refers to the un-PROTECT'd NEW_CHARACTER here - the
R_alloc call looks okay to me...



yes, tag needs protection.

I attributed the bug to R_alloc because I failed to reason that R_alloc
(obviously) allocates and hence can trigger a garbage collection.

Somehow it reflects my approach to PROTECTion, probably not shared by
everyone. I like to PROTECT only when necessary, rather than
indiscriminately. Probably this has no practical consequence in terms of
performance, making the code a little easier to read at the expense of
exposing me to bugs like this.



I guess it's a tradeoff between syntactic complexity and logical
complexity. You have to think pretty hard to minimize use of the
protect stack.


I prefer to call it logical obscurity ;-)

The hard thinking consists in assessing whether or not the code between
the line where a new SEXP is allocated (line X) and the line where
it's put in a safe place (line Y) can trigger garbage collection.
Hard to figure out in general indeed, but not impossible! Problem
is that the result of this assessment is valid at a certain point
in time but might change in the future, even if your code has not
changed.

So a dangerous game for virtually zero benefits.



One recommendation might be to UNPROTECT() as soon as the pointer on
the top is unneeded, rather than trying to figure out the number to
pop just before returning to R.


If you PROTECT() in a loop, you definitely want to do that. Otherwise,
does it make a big difference?



One thing that got me is that the order in which C evaluates function
call arguments is undefined. I did a lot of R_setAttrib(x,
install("foo"), allocBar()), thinking that the symbol would be
automatically protected, and allocBar() would not need protection,
since it happened last. Unfortunately, it might be evaluated first.


I got hit by this too long time ago but with defineVar() instead of
R_setAttrib():

 https://stat.ethz.ch/pipermail/r-devel/2008-January/048040.html

H.



Btw, I think my package RGtk2 got the record: 1952 errors. Luckily
almost all of them happened inside a few macros and autogenerated
code.


Martin



Cheers,

Aaron
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=su20YzStywMa_pdWblzF0RnK8ATRw-t61lOIOsi0xTU&s=JhBOw1ac5wXfV1BSjFuidxFiBTx43J7iEvZG4G0_0uU&e=




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

___
Bioc-devel@r-project

Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Martin Morgan]

On 04/07/2017 03:55 AM, Ramon Diaz-Uriarte wrote:


Dear Martin and Valerie,


I am not sure how to proceed here since the 14th is approaching and I still
see this error (in both my package and at least one other package
---arrayQualityMetrics).


I could comment out the plotting code for the vignette and examples when
running on El Capitan. Is this a possible workaround that I should


In general this is the wrong thing to do, since it enables shipping 
broken code with no possibility of future fixes. Be patient. Martin



implement? If this is reasonable, what is the recommended way to find out
the code is running in El Capitan and not Mavericks? (For instance, can I
tell from Sys.info()["sysname"]? --I do not have access to a Mac).


Martin mentioned that the Cairo package requires a binary installation that
is not yet available.  Should I continue to wait? There is not a lot of
margin for changing the code, uploading to BioC, waiting for the build, and
making sure it works.  What if it continues to fail on El Capitan by the
14th?



Best,


R.




On Mon, 03-04-2017, at 18:34:26, Martin Morgan  
wrote:

On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:


Dear All,

A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
segfault that seems to happen when plotting (in a call to plotting that
happens inside a mclapply)

http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html


these are some of the lines of the traceback:

Traceback:
 1: dev.hold()
 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, 
-0.611, -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, 
-0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))



It seems that what triggers the problem is an innocuous plot.default
followed by dev.hold? (none of which I call explicitly in my code)


I was able to reproduce this with

$ cat segfault-test.R
xx <- parallel::mclapply(1:2, function(i) {
 Cairo::CairoPNG(filename = paste("plt", i, ".png", sep=''))
 dev.hold()
})

$ R -f segfault-test.R

The El-Capitain builds are still in a great deal of flux, and in
particular the Cairo package requires a binary installation that is not
yet available (the Cairo package is used is actually from Mavericks).
The bes

[Bioc-devel] package 'msa' not building on veracruz2, but on toluca2 and other Mac OS systems

[Ulrich Bodenhofer]

Hi,

The devel version of our package 'msa' currently does not compile on 
veracruz2 (R 3.4.0 alpha under OS X 10.11.6 El Capitan), but it seems to 
work on toluca2 (R-devel on OS X 10.9.5 Mavericks). I also checked on my 
Mac at home (R 3.3.3 under macOS 10.12.3 Sierra using the very latest 
version of Xcode), and it also compiles without any problems.


The error stems from a conflicting definition of the math functions 
'log2' and 'log10' in the source code of the ClustalOmega library which 
is integrated into 'msa' (the same error appears for the inline 
definition of 'log10'):


   hhalign/util-C.h:53:14: error: 'log2' is missing exception 
specification 'throw()'
   inline float log2(float x)  {return (x<=0? 
(float)(-10):1.442695041*log(x));}


Any ideas? 'log2' and 'log10' are defined in the standard math library. 
The definitions work well on Linux along with '#include ' , while 
Windows requires '#include '. So far, '#include ' also 
worked on Mac OS, but it seems that now, on veracruz2, neither one nor 
the other works. Any thoughts? Is this something I should care about or 
is there something exotic about veracruz2 such that I can simply ignore 
this issue?


Thanks a lot in advance and best regards,

Ulrich

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

Re: [Bioc-devel] PROTECT errors in Bioconductor packages

[Hervé Pagès]

On 04/07/2017 05:37 AM, luke-tier...@uiowa.edu wrote:

On Fri, 7 Apr 2017, Hervé Pagès wrote:


On 04/06/2017 03:29 AM, Michael Lawrence wrote:

On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
 wrote:

On 04/06/2017 05:33 AM, Aaron Lun wrote:


The tool is not perfect, so assess each report carefully.


I get a lot of warnings because the tool seems to consider that
extracting an attribute (with getAttrib(x, ...)) or extracting the
slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
returns an SEXP that needs protection. I always assumed that it
didn't because my understanding is that the returned SEXP is pointing
to a part of a pre-existing object ('x') and not to a newly created
one. So I decided I could treat it like the SEXP returned by
VECTOR_ELT(), which, AFAIK, doesn't need protection.

So I suspect these warnings are false positives but I'm not 100% sure.


If you are not 100% sure then you should protect :-)

There are some cases, in particular related to compact row names on
data frames, where getAttrib will allocate.


Seriously? So setAttrib(x, ..., getAttrib) is not going to be a no-op
anymore? Should I worry that VECTOR_ELT() will also expand some sort
of compact list element? Why not keep these things low-level
getters/setters that return whatever the real thing is and use
higher-level accessors for returning the expanded version of the thing?

Thanks,
H.



Best,

luke






I also get a warning on almost every C++ function I've written,
because
I use the following code to handle exceptions:

 SEXP output=PROTECT(allocVector(...));
 try {
 // do something that might raise an exception
 } catch (std::exception& e) {
 UNPROTECT(1);
 throw; // break out of this part of the function
 }
 UNPROTECT(1);
 return output;

Presumably the check doesn't account for transfer of control to the
catch block. I find that R itself is pretty good at complaining about
stack imbalances during execution of tests, examples, etc.


'My' packages
(Rsamtools, DirichletMultinomial) had several false positives (all
associated with use of an attribute of a protected SEXP), one subtle
problem (a symbol from a PROTECT'ed package name space; the symbol
could
in theory be an active binding and the value obtained not
PROTECTed by
the name space), and a genuine bug

tag = NEW_CHARACTER(n);
for (int j = 0; j < n; ++j)
SET_STRING_ELT(tag, j, NA_STRING);
if ('A' == aux[0]) {
buf_A = R_alloc(2, sizeof(char));  # <<- bug
buf_A[1] = '\0';
}
...
SET_VECTOR_ELT(tags, i, tag); # PROTECT tag, too
late!



I assume the bug refers to the un-PROTECT'd NEW_CHARACTER here - the
R_alloc call looks okay to me...



yes, tag needs protection.

I attributed the bug to R_alloc because I failed to reason that R_alloc
(obviously) allocates and hence can trigger a garbage collection.

Somehow it reflects my approach to PROTECTion, probably not shared by
everyone. I like to PROTECT only when necessary, rather than
indiscriminately. Probably this has no practical consequence in
terms of
performance, making the code a little easier to read at the expense of
exposing me to bugs like this.



I guess it's a tradeoff between syntactic complexity and logical
complexity. You have to think pretty hard to minimize use of the
protect stack.


I prefer to call it logical obscurity ;-)

The hard thinking consists in assessing whether or not the code between
the line where a new SEXP is allocated (line X) and the line where
it's put in a safe place (line Y) can trigger garbage collection.
Hard to figure out in general indeed, but not impossible! Problem
is that the result of this assessment is valid at a certain point
in time but might change in the future, even if your code has not
changed.

So a dangerous game for virtually zero benefits.



One recommendation might be to UNPROTECT() as soon as the pointer on
the top is unneeded, rather than trying to figure out the number to
pop just before returning to R.


If you PROTECT() in a loop, you definitely want to do that. Otherwise,
does it make a big difference?



One thing that got me is that the order in which C evaluates function
call arguments is undefined. I did a lot of R_setAttrib(x,
install("foo"), allocBar()), thinking that the symbol would be
automatically protected, and allocBar() would not need protection,
since it happened last. Unfortunately, it might be evaluated first.


I got hit by this too long time ago but with defineVar() instead of
R_setAttrib():

 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_r-2Ddevel_2008-2DJanuary_048040.html&d=DwID-g&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=FscW1HcPCwUqtMwKVFDfd1NyW0oHh0tJOPdFb3C1IWk&s=O3CcB-Z_OkVKaC1aV0aIc5SCDNqGQrkvGSmPf0TRAsw&e=

H.



Btw, I think my package RGtk2 got the 

[Bioc-devel] Bioconductor 3.5 release: stop commits to 3.4 release branch

[Obenchain, Valerie]

Today we'll stop commits to the 3.4 release branch at COB EST. Please
commit any last changes before that time. We'll wait one more day to get
a final build report and then stop the release builds all together.

Thanks.

Valerie



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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Bioconductor 3.5 release: update NEWS

[Obenchain, Valerie]

Reminder to please update your NEWS files. These files are collated and
included in the release announcement so it's worth polishing them up.

Thanks.

Valerie



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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] PROTECT errors in Bioconductor packages

[luke-tierney]

On Fri, 7 Apr 2017, Hervé Pagès wrote:


On 04/07/2017 05:37 AM, luke-tier...@uiowa.edu wrote:

 On Fri, 7 Apr 2017, Hervé Pagès wrote:

>  On 04/06/2017 03:29 AM, Michael Lawrence wrote:
> >  On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
> >   wrote:
> > >  On 04/06/2017 05:33 AM, Aaron Lun wrote:
> > > > > 
> > > > >  The tool is not perfect, so assess each report carefully.
> 
>  I get a lot of warnings because the tool seems to consider that

>  extracting an attribute (with getAttrib(x, ...)) or extracting the
>  slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
>  returns an SEXP that needs protection. I always assumed that it
>  didn't because my understanding is that the returned SEXP is pointing
>  to a part of a pre-existing object ('x') and not to a newly created
>  one. So I decided I could treat it like the SEXP returned by
>  VECTOR_ELT(), which, AFAIK, doesn't need protection.
> 
>  So I suspect these warnings are false positives but I'm not 100% sure.


 If you are not 100% sure then you should protect :-)

 There are some cases, in particular related to compact row names on
 data frames, where getAttrib will allocate.


Seriously? So setAttrib(x, ..., getAttrib) is not going to be a no-op
anymore? Should I worry that VECTOR_ELT() will also expand some sort
of compact list element? Why not keep these things low-level
getters/setters that return whatever the real thing is and use
higher-level accessors for returning the expanded version of the thing?


Seriously: it's been that way since r37807 in 2006.

If you want to read about some related future directions you can look at
https://svn.r-project.org/R/branches/ALTREP/ALTREP.html.

luke




Thanks,
H.



 Best,

 luke

> 
> > > > 
> > > > 
> > > >  I also get a warning on almost every C++ function I've written,

> > > >  because
> > > >  I use the following code to handle exceptions:
> > > > 
> > > >   SEXP output=PROTECT(allocVector(...));

> > > >   try {
> > > >   // do something that might raise an exception
> > > >   } catch (std::exception& e) {
> > > >   UNPROTECT(1);
> > > >   throw; // break out of this part of the function
> > > >   }
> > > >   UNPROTECT(1);
> > > >   return output;
> > > > 
> > > >  Presumably the check doesn't account for transfer of control to 
> > > >  the
> > > >  catch block. I find that R itself is pretty good at complaining 
> > > >  about

> > > >  stack imbalances during execution of tests, examples, etc.
> > > > 
> > > > >  'My' packages
> > > > >  (Rsamtools, DirichletMultinomial) had several false positives 
> > > > >  (all
> > > > >  associated with use of an attribute of a protected SEXP), one 
> > > > >  subtle
> > > > >  problem (a symbol from a PROTECT'ed package name space; the 
> > > > >  symbol

> > > > >  could
> > > > >  in theory be an active binding and the value obtained not
> > > > >  PROTECTed by
> > > > >  the name space), and a genuine bug
> > > > > 
> > > > >  tag = NEW_CHARACTER(n);

> > > > >  for (int j = 0; j < n; ++j)
> > > > >  SET_STRING_ELT(tag, j, NA_STRING);
> > > > >  if ('A' == aux[0]) {
> > > > >  buf_A = R_alloc(2, sizeof(char));  # <<- bug
> > > > >  buf_A[1] = '\0';
> > > > >  }
> > > > >  ...
> > > > >  SET_VECTOR_ELT(tags, i, tag); # PROTECT tag, too
> > > > >  late!
> > > > 
> > > > 
> > > >  I assume the bug refers to the un-PROTECT'd NEW_CHARACTER here - 
> > > >  the

> > > >  R_alloc call looks okay to me...
> > > 
> > > 
> > >  yes, tag needs protection.
> > > 
> > >  I attributed the bug to R_alloc because I failed to reason that 
> > >  R_alloc

> > >  (obviously) allocates and hence can trigger a garbage collection.
> > > 
> > >  Somehow it reflects my approach to PROTECTion, probably not shared 
> > >  by

> > >  everyone. I like to PROTECT only when necessary, rather than
> > >  indiscriminately. Probably this has no practical consequence in
> > >  terms of
> > >  performance, making the code a little easier to read at the expense 
> > >  of

> > >  exposing me to bugs like this.
> > > 
> > 
> >  I guess it's a tradeoff between syntactic complexity and logical

> >  complexity. You have to think pretty hard to minimize use of the
> >  protect stack.
> 
>  I prefer to call it logical obscurity ;-)
> 
>  The hard thinking consists in assessing whether or not the code between

>  the line where a new SEXP is allocated (line X) and the line where
>  it's put in a safe place (line Y) can trigger garbage collection.
>  Hard to figure out in general indeed, but not impossible! Problem
>  is that the result of this assessment is valid at a certain point
>  in time but might change in the future, even if your code has not
>  changed.
> 
>  So a dangerous game for virtually zero benefits.
> 
> > 
> >  One recommendation might be to UNPROTECT() as s

Re: [Bioc-devel] PROTECT errors in Bioconductor packages

[Gabe Becker]

On Fri, Apr 7, 2017 at 12:46 PM,  wrote:

> On Fri, 7 Apr 2017, Hervé Pagès wrote:
>
> On 04/07/2017 05:37 AM, luke-tier...@uiowa.edu wrote:
>>
>>>  On Fri, 7 Apr 2017, Hervé Pagès wrote:
>>>
>>> >  On 04/06/2017 03:29 AM, Michael Lawrence wrote:
>>> > >  On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
>>> > >   wrote:
>>> > > >  On 04/06/2017 05:33 AM, Aaron Lun wrote:
>>> > > > > > > > > > >  The tool is not perfect, so assess each report
>>> carefully.
>>> > >  I get a lot of warnings because the tool seems to consider that
>>> >  extracting an attribute (with getAttrib(x, ...)) or extracting the
>>> >  slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
>>> >  returns an SEXP that needs protection. I always assumed that it
>>> >  didn't because my understanding is that the returned SEXP is pointing
>>> >  to a part of a pre-existing object ('x') and not to a newly created
>>> >  one. So I decided I could treat it like the SEXP returned by
>>> >  VECTOR_ELT(), which, AFAIK, doesn't need protection.
>>> > >  So I suspect these warnings are false positives but I'm not 100%
>>> sure.
>>>
>>>  If you are not 100% sure then you should protect :-)
>>>
>>>  There are some cases, in particular related to compact row names on
>>>  data frames, where getAttrib will allocate.
>>>
>>
>> Seriously? So setAttrib(x, ..., getAttrib) is not going to be a no-op
>> anymore? Should I worry that VECTOR_ELT() will also expand some sort
>> of compact list element? Why not keep these things low-level
>> getters/setters that return whatever the real thing is and use
>> higher-level accessors for returning the expanded version of the thing?
>>
>
> Seriously: it's been that way since r37807 in 2006.
>
> If you want to read about some related future directions you can look at
> https://svn.r-project.org/R/branches/ALTREP/ALTREP.html.


Indeed. I was wondering whether to bring this up here.

In a (hopefully near future) version of R-devel, doing, e.g., INTEGER(x)
could allocate.  There is a way to ask it to give you NULL instead of
allocating if it would need to, but the point being it's probably going to
get much harder to safely be clever about avoiding PROTECT'ing. (Luke put
in temporary suspension of GC in some places, but I don't recall the exact
details of where that was used).

As a side note to the above, you'll need to do INTEGER(x) less often than
you did before. There will be a new INTEGER_ELT and INTEGER_GET_REGION
macros which (I think) will be guaranteed to not cause SEXP allocation.

In terms of why, at least in the ALTREP case, it's so that these things can
be passed directly to the R internals and be treated like whatever
lowl-level type of thing they are (e.g. numeric vector, string vector,
list, etc). This seamless backwards compatiblity requires that code which
doesn't use the INTEGER_ELT and INTEGER_GET_REGION (or analogues) macros
needs to have INTEGER(X) work and give it the pointer it expects, which
won't necessarily exist before the first time it is required.

Best,
~G


>
> luke
>
>
>
>
>> Thanks,
>> H.
>>
>>
>>>  Best,
>>>
>>>  luke
>>>
>>> > > > > > > > > > > > > >  I also get a warning on almost every C++
>>> function I've written,
>>> > > > >  because
>>> > > > >  I use the following code to handle exceptions:
>>> > > > > > > > >   SEXP output=PROTECT(allocVector(...));
>>> > > > >   try {
>>> > > > >   // do something that might raise an exception
>>> > > > >   } catch (std::exception& e) {
>>> > > > >   UNPROTECT(1);
>>> > > > >   throw; // break out of this part of the function
>>> > > > >   }
>>> > > > >   UNPROTECT(1);
>>> > > > >   return output;
>>> > > > > > > > >  Presumably the check doesn't account for transfer of
>>> control to > > > >  the
>>> > > > >  catch block. I find that R itself is pretty good at complaining
>>> > > > >  about
>>> > > > >  stack imbalances during execution of tests, examples, etc.
>>> > > > > > > > > >  'My' packages
>>> > > > > >  (Rsamtools, DirichletMultinomial) had several false positives
>>> > > > > >  (all
>>> > > > > >  associated with use of an attribute of a protected SEXP), one
>>> > > > > >  subtle
>>> > > > > >  problem (a symbol from a PROTECT'ed package name space; the >
>>> > > > >  symbol
>>> > > > > >  could
>>> > > > > >  in theory be an active binding and the value obtained not
>>> > > > > >  PROTECTed by
>>> > > > > >  the name space), and a genuine bug
>>> > > > > > > > > > >  tag = NEW_CHARACTER(n);
>>> > > > > >  for (int j = 0; j < n; ++j)
>>> > > > > >  SET_STRING_ELT(tag, j, NA_STRING);
>>> > > > > >  if ('A' == aux[0]) {
>>> > > > > >  buf_A = R_alloc(2, sizeof(char));  # <<-
>>> bug
>>> > > > > >  buf_A[1] = '\0';
>>> > > > > >  }
>>> > > > > >  ...
>>> > > > > >  SET_VECTOR_ELT(tags, i, tag); # PROTECT tag,
>>> too
>>> > > > 

[Bioc-devel] Error in BUILD report (anamiR)

[王棣台]

Hi all,

I got en error when it tries to create vignette in BUILD:
tokay2  Windows Server 2012 R2 Standard / x64

Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics:
could not run statement: Lost connection to MySQL server during query

But for Linux or Mac, it all works.
I have no idea how to solve this problem.

Many thanks,
Ti-Tai

[[alternative HTML version deleted]]

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