Re: [Rd] mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds

[Henrik Bengtsson]

On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley
 wrote:
> From ?NA
>
>  Numerical computations using ‘NA’ will normally result in ‘NA’: a
>  possible exception is where ‘NaN’ is also involved, in which case
>  either might result.
>
> and ?NaN
>
>  Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
>  which of those two is not guaranteed and may depend on the R
>  platform (since compilers may re-order computations).
>
> fortunes::fortune(14) applies (yet again).

Thanks; I'm often happy to have contributed to some of the fortune
counters, but not so sure about this one.   What's even worse is that
one of my own matrixStats NEWS has an entry go a few years back which
mentions "... incorrectly assumed that the value of prod(c(NaN, NA))
is uniquely defined.  However, as documented in help("is.nan"), it may
be NA or NaN depending on R system/platform."  I guess the joke is on
me - it's April 1st after all.

But, technically one could test for ISNA(x) for each element before
calculating the intermediate sum, but since that is a quite expensive
test it is not done and sum += x is performed "as is" on NA and NaN
(and -Inf and +Inf).  Is that correct?

/Henrik

>
>
> On 01/04/2017 04:50, Henrik Bengtsson wrote:
>>
>> In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
>> from source as well as for the sudo apt r-base build):
>>
>>> x <- c(NA, NaN)
>>> mean(x)
>>
>> [1] NA
>>>
>>> mean(rev(x))
>>
>> [1] NaN
>>
>>> rowMeans(matrix(x, nrow = 1, ncol = 2))
>>
>> [1] NA
>>>
>>> rowMeans(matrix(rev(x), nrow = 1, ncol = 2))
>>
>> [1] NaN
>>
>>> .rowMeans(x, m = 1, n = 2)
>>
>> [1] NA
>>>
>>> .rowMeans(rev(x), m = 1, n = 2)
>>
>> [1] NaN
>>
>>> .rowSums(x, m = 1, n = 2)
>>
>> [1] NA
>>>
>>> .rowSums(rev(x), m = 1, n = 2)
>>
>> [1] NaN
>>
>>> rowSums(matrix(x, nrow = 1, ncol = 2))
>>
>> [1] NA
>>>
>>> rowSums(matrix(rev(x), nrow = 1, ncol = 2))
>>
>> [1] NaN
>>
>> I'd expect NA to trump NaN in all cases (with na.rm = FALSE).  sum()
>> does not have this problem and returns NA in both cases (*).
>>
>> For the same R version build from source on RHEL 6.6 system
>> (completely different architecture), I get the expected result (= NA)
>> for all of the above cases, e.g.
>>
>>> x <- c(NA, NaN)
>>> mean(x)
>>
>> [1] NA
>>>
>>> mean(rev(x))
>>
>> [1] NA
>> [...]
>>
>> Before going insane trying to troubleshoot this, I have a vague memory
>> that this, or something related to this, has been discussed
>> previously, but I cannot locate it.
>>
>> Is the above a bug in R, a FAQ, a build error, overzealous compiler
>> optimization, and / or ...?
>>
>> Thanks,
>>
>> Henrik
>
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> __
> 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] mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds

[Prof Brian Ripley]

From ?NA

 Numerical computations using ‘NA’ will normally result in ‘NA’: a
 possible exception is where ‘NaN’ is also involved, in which case
 either might result.

and ?NaN

 Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
 which of those two is not guaranteed and may depend on the R
 platform (since compilers may re-order computations).

fortunes::fortune(14) applies (yet again).

On 01/04/2017 04:50, Henrik Bengtsson wrote:

In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
from source as well as for the sudo apt r-base build):


x <- c(NA, NaN)
mean(x)

[1] NA

mean(rev(x))

[1] NaN


rowMeans(matrix(x, nrow = 1, ncol = 2))

[1] NA

rowMeans(matrix(rev(x), nrow = 1, ncol = 2))

[1] NaN


.rowMeans(x, m = 1, n = 2)

[1] NA

.rowMeans(rev(x), m = 1, n = 2)

[1] NaN


.rowSums(x, m = 1, n = 2)

[1] NA

.rowSums(rev(x), m = 1, n = 2)

[1] NaN


rowSums(matrix(x, nrow = 1, ncol = 2))

[1] NA

rowSums(matrix(rev(x), nrow = 1, ncol = 2))

[1] NaN

I'd expect NA to trump NaN in all cases (with na.rm = FALSE).  sum()
does not have this problem and returns NA in both cases (*).

For the same R version build from source on RHEL 6.6 system
(completely different architecture), I get the expected result (= NA)
for all of the above cases, e.g.


x <- c(NA, NaN)
mean(x)

[1] NA

mean(rev(x))

[1] NA
[...]

Before going insane trying to troubleshoot this, I have a vague memory
that this, or something related to this, has been discussed
previously, but I cannot locate it.

Is the above a bug in R, a FAQ, a build error, overzealous compiler
optimization, and / or ...?

Thanks,

Henrik



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[Rd] mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds

[Henrik Bengtsson]

In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
from source as well as for the sudo apt r-base build):

> x <- c(NA, NaN)
> mean(x)
[1] NA
> mean(rev(x))
[1] NaN

> rowMeans(matrix(x, nrow = 1, ncol = 2))
[1] NA
> rowMeans(matrix(rev(x), nrow = 1, ncol = 2))
[1] NaN

> .rowMeans(x, m = 1, n = 2)
[1] NA
> .rowMeans(rev(x), m = 1, n = 2)
[1] NaN

> .rowSums(x, m = 1, n = 2)
[1] NA
> .rowSums(rev(x), m = 1, n = 2)
[1] NaN

> rowSums(matrix(x, nrow = 1, ncol = 2))
[1] NA
> rowSums(matrix(rev(x), nrow = 1, ncol = 2))
[1] NaN

I'd expect NA to trump NaN in all cases (with na.rm = FALSE).  sum()
does not have this problem and returns NA in both cases (*).

For the same R version build from source on RHEL 6.6 system
(completely different architecture), I get the expected result (= NA)
for all of the above cases, e.g.

> x <- c(NA, NaN)
> mean(x)
[1] NA
> mean(rev(x))
[1] NA
[...]

Before going insane trying to troubleshoot this, I have a vague memory
that this, or something related to this, has been discussed
previously, but I cannot locate it.

Is the above a bug in R, a FAQ, a build error, overzealous compiler
optimization, and / or ...?

Thanks,

Henrik

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

Re: [Bioc-devel] Using LaTeX packages in vignettes

[Obenchain, Valerie]

Hi,

On 03/30/2017 03:20 AM, Janssen-10, R.R.E. wrote:
> Hello all,
>
> We wrote our vignette in Sweave/LaTeX, and I am running into a problem with 
> citing to other papers.
> I would like to use the APA style of citing which looks like: "Determine the 
> optimal factorization rank using the NMF package (Gaujoux and Seoighe, 2010). 
> ..."
>
> Now, to achieve that, I could use the package "apacite", but I wonder whether 
> it's available on the build nodes of Bioconductor, and whether it's desired 
> to choose our own citation style.  Can we choose our own citation style in 
> vignettes? And if so, is "apacite" available on the build infrastructure of 
> Bioconductor?
apacite is included in TeXLive which is on the build machines.

Valerie

>
> Thanks!
>
> Kind regards,
> Roel Janssen
>
> --
>
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
> te informeren door het bericht te retourneren. Het Universitair Medisch
> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de 
> W.H.W.
> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
> de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
>
> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
>
> --
>
> This message may contain confidential information and ...{{dropped:18}}

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

Re: [Bioc-devel] condition tests on vectors with length greater than 1

[Kevin RUE]

Hi Martin,

My apologies to Tomas Kalibera. I read too fast and missed the part where
you gave him credit for the report.

As I wrote in my previous email, I have started a significant clean-up of
the GOexpress package to improve both the coding standards and the user
experience. I haven't reached the overlap_GO function yet (that uses the
VennDiagram package); however, this is not a core function (I used it for
diagnostic mostly during package development), and I will most likely
drop it altogether before the next release.

Have a great weekend.

Kind regards,
Kevin


On Fri, Mar 31, 2017 at 5:00 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 03/31/2017 08:21 AM, Kevin RUE wrote:
>
>> Hi Martin,
>>
>> Thanks a lot for systematically identifying the issue.
>>
>> Looking at the issue for GOexpress now, I realise that the issue is not
>> in GOexpress itself, but actually within the VennDiagram package that
>> GOexpress imports. You actually captured that in your report:
>>
>> "GOexpress","_VennDiagram_","GOexpress.Rcheck/GOexpress-Ex.R
>> out","VennDiagram::adjust.venn","VennDiagram/R/adjust.venn.R#42 "
>>
>> In your report, GOexpress is the only Bioconductor in this situation.
>> I can (and will) attempt to contact the maintainer of VennDiagram, but
>> it just makes me wonder if you have another suggestion to deal with this
>> kind of issue (/i.e./, imported packages not conforming to BioC
>> guidelines). Is this going to raise Warnings or Errors in BiocCheck ? If
>> so, should we ignore such packages altogether, as long as those packages
>> raise check issues?
>>
>
> Actually, the report was generated by an R-core member, Tomas Kalibera and
> the more extensive version includes all CRAN and Bioc packages. It reflects
> a general effort to address these and then make them errors, rather than
> warnings -- R CMD check would then fail.
>
> Package dependencies are interesting. They are obviously hugely important
> to reduce redundant code, and to fix bugs once in a single place. But they
> also carry with them an additional maintenance cost. If VennDiagram is
> central to your package, especially if it implements complicated
> functionality, then definitely the balance is in favor of depending on it,
> and working with the maintainer to address problems that you discover.
>
> The Bioc requirements are really about your package, especially enforcing
> adequate documentation.
>
> Martin
>
>
>> As a side note, I have actually already been going through GOexpress to
>> prepare a new major version of GOexpress (2.x.x) that will introduce S4
>> where relevant, and break down large functions into more sensibly-sized
>> steps. However, most likely that won't be ready for the next BioC release.
>>
>> Best,
>> Kevin
>>
>>
>> On Wed, Mar 29, 2017 at 10:44 PM, Martin Morgan
>> >
>>
>> wrote:
>>
>> On 03/29/2017 05:37 PM, Martin Morgan wrote:
>>
>> Bioc developers,
>>
>> R emits a warning when a condition test has length > 1
>>
>> $ R --vanilla
>>
>> if (letters == "a") TRUE
>>
>> [1] TRUE
>> Warning message:
>> In if (letters == "a") TRUE :
>>   the condition has length > 1 and only the first element will
>> be used
>>
>> These are almost always programming errors.
>>
>> R-3-4-branch and R-devel can be configured to report such errors,
>> as
>> described on the help page for, e.g., `?"if"`
>>
>> $ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla
>>
>> if (letters=="a") TRUE
>>
>> Error in if (letters == "a") TRUE : the condition has length > 1
>>
>> The attached file (thanks to Tomas Kalibera) summarizes
>> Bioconductor
>> code that triggers this type of error.
>>
>>
>> Second try on the attachment
>>
>> r = read.csv("long-conditional-bioc.txt")
>>
>>
>>
>> If you maintain one of these packages (appearing in either
>> column),
>> please address the error. And of course as a developer, please
>> avoid
>> making the error in the future!
>>
>> r = read.csv("long-conditional-bioc.csv")
>> r[, c("FailedPackage", "Srcref")]
>>
>>FailedPackage  Srcref
>> 1 biovizBase   biovizBase/R/crunch-method.R#295
>> 2  branchpointer   branchpointer/R/makeRegions.R#41
>> 3   CardinalCardinal/R/spatial.R#57
>> 4  debrowser   debrowser/R/heatmap.R#38
>> 5DMRcateDMRcate/R/DMR.plot.R#13
>> 6  exomePeak  exomePeak/R/RMT.R#119
>> 7  fabia   fabia/R/fabia.R#1504
>> 8   GenomeInfoDb GenomicFeatures/R/TxDb-class.R#377
>> 9 Glimma   

[Rd] iconv documentation error

[Therneau, Terry M., Ph.D.]

This caught us yesterday when a string that we assumed to be in UTF-8 was actually using 
CP1252.  (This came from an internal web based service, so the root cause is not R's 
fault.)  The help page for iconv states that the result of an invalid conversion is NA 
only when the toRaw argument is TRUE, but this appears to be true in general.


Example:

test1 <- "Ménière's disease"# the offending string (it was buried in a 13000 
character result string)
test2 <- iconv(test1, to="CP1252")  # create a version of the string that is in 
Window-1252 coding

iconv(test2, from="UTF-8")  # reprise our error
[1] NA

Note that Encoding(test2) returns "latin-1", which is also not quite in alignment with the 
help page.


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

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

[Avraham Adler]

On Wed, Mar 15, 2017 at 12:19 PM, William Dunlap  wrote:
> I don't know about the current Sparc Fortran compilers, but over the
> years have learned not to try to pass logicals and character strings
> between C and Fortran.  I have seen Fortran compilers that treated
> integer -1 (all bits 1) as .true. and anything else as .false. and I
> have see ones that looked only at bit 7, counting from the right, to
> determine the value.
>
> I recommend changing your Fortran code to accept an integer instead of
> a logical for boolean inputs and outputs.

Posting for posterity's and future similar questions' sakes [1], I am
relieved to find that removing reliance on the Fortran 2003
ISO_C_binding of c_bool, casting logicals explicitly as integers of 0
or 1, and testing for those integers in Fortran, seems to have finally
sated the SPARCmonster's appetite. [2]

Thank you very much!

Avi

[1] https://xkcd.com/979/
[2] https://cran.r-project.org/web/checks/check_results_Delaporte.html
- Version 6.0.0

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

Re: [Bioc-devel] condition tests on vectors with length greater than 1

[Martin Morgan]

On 03/31/2017 08:21 AM, Kevin RUE wrote:

Hi Martin,

Thanks a lot for systematically identifying the issue.

Looking at the issue for GOexpress now, I realise that the issue is not
in GOexpress itself, but actually within the VennDiagram package that
GOexpress imports. You actually captured that in your report:

"GOexpress","_VennDiagram_","GOexpress.Rcheck/GOexpress-Ex.Rout","VennDiagram::adjust.venn","VennDiagram/R/adjust.venn.R#42
 "

In your report, GOexpress is the only Bioconductor in this situation.
I can (and will) attempt to contact the maintainer of VennDiagram, but
it just makes me wonder if you have another suggestion to deal with this
kind of issue (/i.e./, imported packages not conforming to BioC
guidelines). Is this going to raise Warnings or Errors in BiocCheck ? If
so, should we ignore such packages altogether, as long as those packages
raise check issues?


Actually, the report was generated by an R-core member, Tomas Kalibera 
and the more extensive version includes all CRAN and Bioc packages. It 
reflects a general effort to address these and then make them errors, 
rather than warnings -- R CMD check would then fail.


Package dependencies are interesting. They are obviously hugely 
important to reduce redundant code, and to fix bugs once in a single 
place. But they also carry with them an additional maintenance cost. If 
VennDiagram is central to your package, especially if it implements 
complicated functionality, then definitely the balance is in favor of 
depending on it, and working with the maintainer to address problems 
that you discover.


The Bioc requirements are really about your package, especially 
enforcing adequate documentation.


Martin



As a side note, I have actually already been going through GOexpress to
prepare a new major version of GOexpress (2.x.x) that will introduce S4
where relevant, and break down large functions into more sensibly-sized
steps. However, most likely that won't be ready for the next BioC release.

Best,
Kevin


On Wed, Mar 29, 2017 at 10:44 PM, Martin Morgan
>
wrote:

On 03/29/2017 05:37 PM, Martin Morgan wrote:

Bioc developers,

R emits a warning when a condition test has length > 1

$ R --vanilla

if (letters == "a") TRUE

[1] TRUE
Warning message:
In if (letters == "a") TRUE :
  the condition has length > 1 and only the first element will
be used

These are almost always programming errors.

R-3-4-branch and R-devel can be configured to report such errors, as
described on the help page for, e.g., `?"if"`

$ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla

if (letters=="a") TRUE

Error in if (letters == "a") TRUE : the condition has length > 1

The attached file (thanks to Tomas Kalibera) summarizes Bioconductor
code that triggers this type of error.


Second try on the attachment

r = read.csv("long-conditional-bioc.txt")



If you maintain one of these packages (appearing in either column),
please address the error. And of course as a developer, please avoid
making the error in the future!

r = read.csv("long-conditional-bioc.csv")
r[, c("FailedPackage", "Srcref")]

   FailedPackage  Srcref
1 biovizBase   biovizBase/R/crunch-method.R#295
2  branchpointer   branchpointer/R/makeRegions.R#41
3   CardinalCardinal/R/spatial.R#57
4  debrowser   debrowser/R/heatmap.R#38
5DMRcateDMRcate/R/DMR.plot.R#13
6  exomePeak  exomePeak/R/RMT.R#119
7  fabia   fabia/R/fabia.R#1504
8   GenomeInfoDb GenomicFeatures/R/TxDb-class.R#377
9 Glimma   Glimma/R/hexcol.R#32
10 GOexpress VennDiagram/R/adjust.venn.R#42
11  GUIDEseq GUIDEseq/R/offTargetAnalysisOfPeakRegions.R#95
12  hapFabia  hapFabia/R/methods-IBDsegmentList-class.R#110
13 MassArray   MassArray/R/convControl.R#26
14methylPipemethylPipe/R/Allfunctions.R#635
15NOISeq   NOISeq/R/biodetection.plot.R#157
16  pathview  pathview/R/geneannot.map.R#31
17  phyloseq  phyloseq/R/multtest-wrapper.R#101
18 rHVDM  rHVDM/R/measurementerrorHVDM.R#23
19  SEPA  SEPA/R/truetimevisualize.R#28
20  SPLINTER SPLINTER/R/main_splinter.R#817

As an example the GenomeInfoDb package (row 8) has this complete
record

FailedPackage 

[Bioc-devel] Bioconductor 3.5 release: March 31 deadlines

[Obenchain, Valerie]

Hi all,

Reminder that today (March 31) is the last day for new package
submissions. I've run into a few problems generating the db0 annotation
packages so unfortunately they won't be ready today - I'm hoping Monday
at the latest.

  http://www.bioconductor.org/developers/release-schedule/

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] masking functions

[Zimmermann, Michael T., Ph.D.]

That took care of it. Thank you, Vincent.

From: Vincent Carey [mailto:st...@channing.harvard.edu]
Sent: Friday, March 31, 2017 5:37 AM
To: Zimmermann, Michael T., Ph.D.
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] masking functions

in the NAMESPACE file


import(gplots)

import(plotrix, except=plotCI)



can help avoid the warning you mention.  If this is not a solution for you you 
will have to provide more details.

On Fri, Mar 31, 2017 at 1:07 AM, Zimmermann, Michael T., Ph.D. 
> wrote:
Dear BioConductor Devs,

I am working on submitting a package and have run into a warning from masking 
functions. The buildreport says:

Warning: replacing previous import gplots::plotCI by plotrix::plotCI when 
loading RITAN

I don't call plotCI. I assume that the other plotting methods I use call them 
internally. So, I'm not sure how to address this warning. Any advice you can 
provide would be appreciated.

Sincerely,

Michael T. Zimmermann
Ph. D. in Bioinformatics | Health Sciences Research | Division of Biomedical 
Statistics and Informatics
Mayo Clinic | 200 First Street SW | Rochester, MN 55905 | 
mayoclinic.org


[[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] Error in veracruz2: object 'R_svmtrain' not found

[Obenchain, Valerie]

Hi,

Looks like this was a glitch in rtracklayer and has been fixed:


r127902 | m.lawrence | 2017-03-31 04:37:23 -0700 (Fri, 31 Mar 2017) | 2
lines

do not try to import pmapFromTranscripts from GenomicAlignments

My guess is that R_svmtrain could not be created because of the
rtracklayer error. I'm not sure why we only saw this in veracruz2 ...
given the date of the fix we should see this clear up on Saturday's
build report.

Valerie



On 03/31/2017 01:55 AM, Mattia Chiesa wrote:
> Hi,
>
> My package DaMiRseq fails to build in veracruz2 server with this error:
>
> Quitting from lines 424-428 (DaMiRseq.Rnw)
> Error: processing vignette 'DaMiRseq.Rnw' failed with diagnostics:
> object 'R_svmtrain' not found
>
> Moreover, this message appeared in latest nightly builds:
>
> No methods found in "GenomicAlignments" for requests: pmapFromTranscripts
>
> I got 'ERROR' only in veracruz2 while the status in malbec2, tokay2 and 
> toluka2 is 'OK'.
>
>
> Here the details:
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/DaMiRseq/
>
>
> How to handle this?
>
> Thanks in advance,
>
> Mattia.
>
>
>
>
>
>
> Dr Mattia Chiesa,
> Biomedical Engineer, PhD in Bioengineering and Bioinformatics
>
> Immunology and Functional Genomics Unit
> Via Parea, 4 - 20138 Milano, Italy
> T +39 02 58002.852 F +39 02 58002.750
> E mchi...@ccfm.it
> W www.cardiologicomonzino.it
>
> Centro Cardiologico Monzino
>
>   [[alternative HTML version deleted]]
>
> ___
> 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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] RIOT 2017

[Lukas Stadler]

I hope you don’t mind us using this mailing list for a small advertisement, but 
we think it is most relevant for this group:

We'd like to invite you to RIOT 2017 - the 3rd workshop on R Implementation, 
Optimization and Tooling [1].
It will take place co-located with, and during, useR! 2017 in Brussels on July 
5th.
RIOT is an excellent venue for deep technical discussions about R 
implementations, tools, optimizations and extension, and will be very 
interesting for anyone interested in what’s under the hood of R implementations.

Regards,
Lukas Stadler (Oracle), Jan Vitek (Northeastern), Alexander Bertram 
(BeDataDriven)

[1] http://riotworkshop.github.io/ 
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] condition tests on vectors with length greater than 1

[Kevin RUE]

Hi Martin,

Thanks a lot for systematically identifying the issue.

Looking at the issue for GOexpress now, I realise that the issue is not in
GOexpress itself, but actually within the VennDiagram package that
GOexpress imports. You actually captured that in your report:

"GOexpress","*VennDiagram*","GOexpress.Rcheck/GOexpress-Ex.Rout","VennDiagram::adjust.venn","VennDiagram/R/adjust.venn.R#42
"

In your report, GOexpress is the only Bioconductor in this situation.
I can (and will) attempt to contact the maintainer of VennDiagram, but it
just makes me wonder if you have another suggestion to deal with this kind
of issue (*i.e.*, imported packages not conforming to BioC guidelines). Is
this going to raise Warnings or Errors in BiocCheck ? If so, should we
ignore such packages altogether, as long as those packages raise check
issues?

As a side note, I have actually already been going through GOexpress to
prepare a new major version of GOexpress (2.x.x) that will introduce S4
where relevant, and break down large functions into more sensibly-sized
steps. However, most likely that won't be ready for the next BioC release.

Best,
Kevin


On Wed, Mar 29, 2017 at 10:44 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 03/29/2017 05:37 PM, Martin Morgan wrote:
>
>> Bioc developers,
>>
>> R emits a warning when a condition test has length > 1
>>
>> $ R --vanilla
>>
>>> if (letters == "a") TRUE
>>>
>> [1] TRUE
>> Warning message:
>> In if (letters == "a") TRUE :
>>   the condition has length > 1 and only the first element will be used
>>
>> These are almost always programming errors.
>>
>> R-3-4-branch and R-devel can be configured to report such errors, as
>> described on the help page for, e.g., `?"if"`
>>
>> $ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla
>>
>>> if (letters=="a") TRUE
>>>
>> Error in if (letters == "a") TRUE : the condition has length > 1
>>
>> The attached file (thanks to Tomas Kalibera) summarizes Bioconductor
>> code that triggers this type of error.
>>
>
> Second try on the attachment
>
> r = read.csv("long-conditional-bioc.txt")
>
>
>
>> If you maintain one of these packages (appearing in either column),
>> please address the error. And of course as a developer, please avoid
>> making the error in the future!
>>
>> r = read.csv("long-conditional-bioc.csv")
>>> r[, c("FailedPackage", "Srcref")]
>>>
>>FailedPackage  Srcref
>> 1 biovizBase   biovizBase/R/crunch-method.R#295
>> 2  branchpointer   branchpointer/R/makeRegions.R#41
>> 3   CardinalCardinal/R/spatial.R#57
>> 4  debrowser   debrowser/R/heatmap.R#38
>> 5DMRcateDMRcate/R/DMR.plot.R#13
>> 6  exomePeak  exomePeak/R/RMT.R#119
>> 7  fabia   fabia/R/fabia.R#1504
>> 8   GenomeInfoDb GenomicFeatures/R/TxDb-class.R#377
>> 9 Glimma   Glimma/R/hexcol.R#32
>> 10 GOexpress VennDiagram/R/adjust.venn.R#42
>> 11  GUIDEseq GUIDEseq/R/offTargetAnalysisOfPeakRegions.R#95
>> 12  hapFabia  hapFabia/R/methods-IBDsegmentList-class.R#110
>> 13 MassArray   MassArray/R/convControl.R#26
>> 14methylPipemethylPipe/R/Allfunctions.R#635
>> 15NOISeq   NOISeq/R/biodetection.plot.R#157
>> 16  pathview  pathview/R/geneannot.map.R#31
>> 17  phyloseq  phyloseq/R/multtest-wrapper.R#101
>> 18 rHVDM  rHVDM/R/measurementerrorHVDM.R#23
>> 19  SEPA  SEPA/R/truetimevisualize.R#28
>> 20  SPLINTER SPLINTER/R/main_splinter.R#817
>>
>> As an example the GenomeInfoDb package (row 8) has this complete record
>>
>> FailedPackage "GenomeInfoDb"
>> IfPackage "GenomicFeatures"
>> File  "GenomeInfoDb.Rcheck/GenomeInfoDb-Ex.Rout"
>> Function  "S4 Method seqlevels<-:GenomeInfoDb defined in namespace
>>GenomicFeatures with signature TxDb has this body."
>> Srcref"GenomicFeatures/R/TxDb-class.R#377 "
>>
>> The problem was from
>>
>>   GenomicFeatures/R/TxDb-class.R#377
>>
>> which has
>>
>> mode <- GenomeInfoDb:::getSeqlevelsReplacementMode(value,
>> x_seqlevels0)
>> if (mode == -2L) {
>>
>> I looked at
>>
>> GenomeInfoDb:::getSeqlevelsReplacementMode
>>>
>> function (new_seqlevels, old_seqlevels)
>> {
>> ...
>>
>> and saw that its code returns a vector with length > 1 intentionally
>> under some specific circumstances. Also, all other uses of the return
>> value of this function (in the GenomeInfoDb and GenomicFeatures package)
>> test for identity of the return value via `identical()`, which is always
>> a scalar. This suggests the fix
>>
>> GenomicFeatures$ svn diff R/TxDb-class.R
>> Index: R/TxDb-class.R
>> ===
>> --- 

Re: [Bioc-devel] Question about R functions

[Sean Davis]

And note the existence of the "Internal" keyword for documentation:

http://www.hep.by/gnu/r-patched/r-exts/R-exts_50.html


On Fri, Mar 31, 2017 at 5:35 AM, Wolfgang Huber 
wrote:

>
> Thanks Juan; the .point used to be a way to do this, but since the
> introduction of namespaces to R, it is neither necessary nor sufficient for
> private functions. See e.g. .Hub in the AnnotationHub package, or the .Call
> function in base.
>
> See https://cran.r-project.org/doc/manuals/r-release/R-exts.html
> #Package-namespaces
> http://r-pkgs.had.co.nz/namespace.html
>
> Wolfgang
>
> 30.3.17 22:46, Juan David Henao Sanchez scripsit:
>
>> Hi Wang
>>
>> You can create internal functions calling them as ".function", the point
>> is
>> necessary to declare an internal function. Additionally, you can put all
>> your internal functions in the same R file and is not necessary create the
>> documentation for this functions.
>>
>> Best regards.
>>
>> Juan D. Henao
>>
>> 2017-03-30 15:02 GMT-05:00 Jing Wang :
>>
>> Hi,
>>>
>>>
>>>
>>> I have three functions (FA,FB,FC) in the package and all these functions
>>> need to call another function (FD). But I do not want other users to use
>>> the function FD and thus I do not want to create the document for FD in
>>> the
>>> R package.
>>>
>>>
>>>
>>> Could you please give me some suggestion how to do that?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [[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
>



-- 
Sean Davis, MD, PhD
Center for Cancer Research
National Cancer Institute
National Institutes of Health
Bethesda, MD 20892
https://seandavi.github.io/
https://twitter.com/seandavis12

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] masking functions

[Vincent Carey]

in the NAMESPACE file

import(gplots)

import(plotrix, except=plotCI)


can help avoid the warning you mention.  If this is not a solution for you
you will have to provide more details.

On Fri, Mar 31, 2017 at 1:07 AM, Zimmermann, Michael T., Ph.D. <
zimmermann.mich...@mayo.edu> wrote:

> Dear BioConductor Devs,
>
> I am working on submitting a package and have run into a warning from
> masking functions. The buildreport says:
>
> Warning: replacing previous import gplots::plotCI by plotrix::plotCI when
> loading RITAN
>
> I don't call plotCI. I assume that the other plotting methods I use call
> them internally. So, I'm not sure how to address this warning. Any advice
> you can provide would be appreciated.
>
> Sincerely,
>
> Michael T. Zimmermann
> Ph. D. in Bioinformatics | Health Sciences Research | Division of
> Biomedical Statistics and Informatics
> Mayo Clinic | 200 First Street SW | Rochester, MN 55905 | mayoclinic.org<
> http://www.mayoclinic.org>
>
>
> [[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] Cannot find SummarizedExperiment's function assays()

[Martin Morgan]

On 03/31/2017 05:29 AM, Sokratis Kariotis wrote:

Hey all,

Following your advice, the package now builds successfully! However, I
got this error while checking:

* checking package dependencies ... ERROR
Namespace dependency not required: ‘SummarizedExperiment’

Should I add /Imports ://SummarizedExperiment/ in my DESCRIPTION file?


Your experiment data package doesn't have an R/ directory so no R code 
(this is normal for experiment data packages). There is therefore no 
need to import(SummarizedExperiment) in your NAMESPACE, so remove it 
there. The warning will then go away.


Martin



Regards,

Sokratis


On 30 March 2017 at 12:05, Martin Morgan > wrote:

On 03/30/2017 05:21 AM, Sokratis Kariotis wrote:

Hey all,

Thanks for the input! I followed Marcel's advice and included
the library
in my vignette. Also, I replaced lazyData with a datalist. The
datalist
file includes "compressed_result : result" which is in turn
loaded in the
vignette using "data(compressed_result)". However, I got:

Warning in data(compressed_result) :
  data set ‘compressed_result’ not found

Error: processing vignette 'usingPathprintGEOData.Rnw' failed
with diagnostics:
 chunk 1
Error in assays(result) : object 'result' not found



I Stangle'd the vignette

  cd pathprintGEOData/vignettes
  R CMD Stangle usingPathprintGEOData.Rnw

and then walked through the lines of R code. I got to

> data(compressed_result)
Warning message:
In data(compressed_result) : data set 'compressed_result' not found

The data 'compressed_result' is not found, because it is in the
pathprintGEOData package, and the pathprintGEOData package is not on
the search path.

> search()
 [1] ".GlobalEnv"   "package:SummarizedExperiment"
 [3] "package:DelayedArray" "package:matrixStats"
 [5] "package:Biobase"  "package:GenomicRanges"
 [7] "package:GenomeInfoDb" "package:IRanges"
 [9] "package:S4Vectors""package:BiocGenerics"
[11] "package:parallel" "package:stats4"
[13] "package:pathprint""ESSR"
[15] "package:BiocInstaller""package:stats"
[17] "package:graphics" "package:grDevices"
[19] "package:utils""package:datasets"
[21] "package:methods"  "Autoloads"
[23] "package:base"

It is not on the search path because, originally, pathprint had
Depends: pathprintGEOData, but that was modified, as you know, to
Suggests: pathprintGEOData, to avoid circular dependencies that
thwart our build system. So previously library(pathprint) was enough
to make the data available, but now you must either load the package

  library(pathprintGEOData)
  data(compressed_result)

or tell data() where the data set is

  data(compressed_result, package="pathprintGEOData")

One would still like to use an informative name for the data (first
argument of data) and presumably an identical name for the object
that is loaded.

Martin



So the dataset is still not loaded (again, these errors did not
exist
prior to package acceptance). I have been using devtools to
build/check the package (since the github issue was closed) and
these
warnings/errors dont show up, which imakes it difficult for me
to fix
them. Thanks again for any input!

Regards,

Sokratis


On 27 March 2017 at 19:58, Michael Lawrence
>
wrote:

Actually, I don't see where the package itself is loaded in the
vignette. If it were, this error would not occur.

Unsurprisingly, I get this when trying to run the vignette code:

Warning message:
In data(list = ds) : data set ‘pathprintSummarizedGEOData’
not found

I noticed that pathprintGEOData just provides
compressed_result, not
the "pathprintSummarizedGEOData" so I'm not sure where that
lives now.
You might also consider turning off lazy data and using a
datalist
file for that package since the file is somewhat large.

I also think that the datalist file for pathprint is out of
date.

Michael

On Mon, Mar 27, 2017 at 11:26 AM, Marcel Ramos
> wrote:

Hi Sokratis,

You can resolve this issue by moving
`SummarizedExperiment` to the
Suggests field and

including a 

Re: [Bioc-devel] Question about R functions

[Wolfgang Huber]

Thanks Juan; the .point used to be a way to do this, but since the 
introduction of namespaces to R, it is neither necessary nor sufficient 
for private functions. See e.g. .Hub in the AnnotationHub package, or 
the .Call function in base.


See 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-namespaces

http://r-pkgs.had.co.nz/namespace.html

Wolfgang

30.3.17 22:46, Juan David Henao Sanchez scripsit:

Hi Wang

You can create internal functions calling them as ".function", the point is
necessary to declare an internal function. Additionally, you can put all
your internal functions in the same R file and is not necessary create the
documentation for this functions.

Best regards.

Juan D. Henao

2017-03-30 15:02 GMT-05:00 Jing Wang :


Hi,



I have three functions (FA,FB,FC) in the package and all these functions
need to call another function (FD). But I do not want other users to use
the function FD and thus I do not want to create the document for FD in the
R package.



Could you please give me some suggestion how to do that?



Thanks,








[[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] Cannot find SummarizedExperiment's function assays()

[Sokratis Kariotis]

Hey all,

Following your advice, the package now builds successfully! However, I got
this error while checking:

* checking package dependencies ... ERROR
Namespace dependency not required: ‘SummarizedExperiment’

Should I add *Imports :**SummarizedExperiment* in my DESCRIPTION file?

Regards,

Sokratis


On 30 March 2017 at 12:05, Martin Morgan 
wrote:

> On 03/30/2017 05:21 AM, Sokratis Kariotis wrote:
>
>> Hey all,
>>
>> Thanks for the input! I followed Marcel's advice and included the library
>> in my vignette. Also, I replaced lazyData with a datalist. The datalist
>> file includes "compressed_result : result" which is in turn loaded in the
>> vignette using "data(compressed_result)". However, I got:
>>
>> Warning in data(compressed_result) :
>>   data set ‘compressed_result’ not found
>>
>> Error: processing vignette 'usingPathprintGEOData.Rnw' failed with
>> diagnostics:
>>  chunk 1
>> Error in assays(result) : object 'result' not found
>>
>
>
> I Stangle'd the vignette
>
>   cd pathprintGEOData/vignettes
>   R CMD Stangle usingPathprintGEOData.Rnw
>
> and then walked through the lines of R code. I got to
>
> > data(compressed_result)
> Warning message:
> In data(compressed_result) : data set 'compressed_result' not found
>
> The data 'compressed_result' is not found, because it is in the
> pathprintGEOData package, and the pathprintGEOData package is not on the
> search path.
>
> > search()
>  [1] ".GlobalEnv"   "package:SummarizedExperiment"
>  [3] "package:DelayedArray" "package:matrixStats"
>  [5] "package:Biobase"  "package:GenomicRanges"
>  [7] "package:GenomeInfoDb" "package:IRanges"
>  [9] "package:S4Vectors""package:BiocGenerics"
> [11] "package:parallel" "package:stats4"
> [13] "package:pathprint""ESSR"
> [15] "package:BiocInstaller""package:stats"
> [17] "package:graphics" "package:grDevices"
> [19] "package:utils""package:datasets"
> [21] "package:methods"  "Autoloads"
> [23] "package:base"
>
> It is not on the search path because, originally, pathprint had Depends:
> pathprintGEOData, but that was modified, as you know, to Suggests:
> pathprintGEOData, to avoid circular dependencies that thwart our build
> system. So previously library(pathprint) was enough to make the data
> available, but now you must either load the package
>
>   library(pathprintGEOData)
>   data(compressed_result)
>
> or tell data() where the data set is
>
>   data(compressed_result, package="pathprintGEOData")
>
> One would still like to use an informative name for the data (first
> argument of data) and presumably an identical name for the object that is
> loaded.
>
> Martin
>
>
>
>> So the dataset is still not loaded (again, these errors did not exist
>> prior to package acceptance). I have been using devtools to
>> build/check the package (since the github issue was closed) and these
>> warnings/errors dont show up, which imakes it difficult for me to fix
>> them. Thanks again for any input!
>>
>> Regards,
>>
>> Sokratis
>>
>>
>> On 27 March 2017 at 19:58, Michael Lawrence 
>> wrote:
>>
>> Actually, I don't see where the package itself is loaded in the
>>> vignette. If it were, this error would not occur.
>>>
>>> Unsurprisingly, I get this when trying to run the vignette code:
>>>
>>> Warning message:
>>> In data(list = ds) : data set ‘pathprintSummarizedGEOData’ not found
>>>
>>> I noticed that pathprintGEOData just provides compressed_result, not
>>> the "pathprintSummarizedGEOData" so I'm not sure where that lives now.
>>> You might also consider turning off lazy data and using a datalist
>>> file for that package since the file is somewhat large.
>>>
>>> I also think that the datalist file for pathprint is out of date.
>>>
>>> Michael
>>>
>>> On Mon, Mar 27, 2017 at 11:26 AM, Marcel Ramos
>>>  wrote:
>>>
 Hi Sokratis,

 You can resolve this issue by moving `SummarizedExperiment` to the
 Suggests field and

 including a `library(SummarizedExperiment)` call in your vignette.

 Best regards,

 Marcel


 On Mon, Mar 27, 2017 at 11:09 AM Sokratis Kariotis
 > wrote:

 Hey,

 I have submitted the package pathprintGEOData, which got accepted,
 but the
 build/check report is now producing the following error:



 *Error: processing vignette 'usingPathprintGEOData.Rnw' failed with
 diagnostics:  chunk 1 Error in assays(result) : could not find

>>> function
>>>
 "assays"*

 *assays *is a function from the SummarizedExperiment package which I
 have
 added on my Depends in DESCRIPTION. This error was not present
 during
 building/checking before this package was 

[Bioc-devel] Error in veracruz2: object 'R_svmtrain' not found

[Mattia Chiesa]

Hi,

My package DaMiRseq fails to build in veracruz2 server with this error:

Quitting from lines 424-428 (DaMiRseq.Rnw)
Error: processing vignette 'DaMiRseq.Rnw' failed with diagnostics:
object 'R_svmtrain' not found

Moreover, this message appeared in latest nightly builds:

No methods found in "GenomicAlignments" for requests: pmapFromTranscripts

I got 'ERROR' only in veracruz2 while the status in malbec2, tokay2 and toluka2 
is 'OK'.


Here the details:

http://bioconductor.org/checkResults/devel/bioc-LATEST/DaMiRseq/


How to handle this?

Thanks in advance,

Mattia.






Dr Mattia Chiesa,
Biomedical Engineer, PhD in Bioengineering and Bioinformatics

Immunology and Functional Genomics Unit
Via Parea, 4 - 20138 Milano, Italy
T +39 02 58002.852 F +39 02 58002.750
E mchi...@ccfm.it
W www.cardiologicomonzino.it

Centro Cardiologico Monzino

[[alternative HTML version deleted]]

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

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

[Ramon Diaz-Uriarte]

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)


At least another package, arrayQualityMetrics seems to experience a
somewhat similar problem:

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

where, again, an apparently innocuous plot.default followed by dev.hold
triggers a segfault (and there is no mclapply here)

Traceback:
 1: dev.hold()
 2: plot.default(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = 
range(min(as.vector(mns)) - 1, max(as.vector(mns)) + 1), xlab = "5' 
<-> 3'\n Probe Number ", ylab = ylab, axes = FALSE, main = "RNA 
degradation plot", ...)
 3: plot(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = 
range(min(as.vector(mns)) - 1, max(as.vector(mns)) + 1), xlab = "5' <-> 
3'\n Probe Number ", ylab = ylab, axes = FALSE, main = "RNA degradation 
plot", ...)
 4: plotAffyRNAdeg(AffyRNAdeg(expressionset, log.it = TRUE), lwd = 1, cols 
= x$arrayColors)




I am not sure how to proceed here. Any suggestions?


Thanks,


R.

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

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