[Bioc-devel] differences between petty and perceval (OS X 10.6.8 build machines for release/devel)

[Michael Stadler]

Hi Dan,

I'm cc'ing the list; maybe somebody else has experienced differences
between petty and perceval.

Rbowtie release (1.4.5) is not building under OS X 10.6.8 (petty).

Rbowtie release (1.4.5) and development (1.5.5) are virtually identical
(only DESCRIPTION and NEWS differ).

The development version builds without problems on perceval, but the
release version fails on petty:
http://bioconductor.org/checkResults/devel/bioc-LATEST/Rbowtie/perceval-buildsrc.html
http://bioconductor.org/checkResults/release/bioc-LATEST/Rbowtie/petty-buildsrc.html

The only difference I can make out from the node info pages is that
perceval has an additional section on "C++11 compiler" that is lacking
from petty's NodeInfo page.

Unfortunately, I cannot reproduce the issue, both Rbowtie 1.4.5 and
1.5.5 build successfully under OS X 10.6.8 and 10.7.5 using llvm-gcc-4.2.

Do you have any idea what else could be different between petty and
perceval?

Thank you,
Michael

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

Re: [Bioc-devel] differences between petty and perceval (OS X 10.6.8 build machines for release/devel)

[Kasper Daniel Hansen]

That is pretty weird.  Since this is a segmentation fault in Bowtie,
perhaps there are resource demands which are only satisfied on perceval
(tmp space, #cores).

Presumably this worked when Bioc was released, so what have you changed in
between?

Best,
Kasper


On Fri, Jun 13, 2014 at 3:32 AM, Michael Stadler 
wrote:

> Hi Dan,
>
> I'm cc'ing the list; maybe somebody else has experienced differences
> between petty and perceval.
>
> Rbowtie release (1.4.5) is not building under OS X 10.6.8 (petty).
>
> Rbowtie release (1.4.5) and development (1.5.5) are virtually identical
> (only DESCRIPTION and NEWS differ).
>
> The development version builds without problems on perceval, but the
> release version fails on petty:
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Rbowtie/perceval-buildsrc.html
>
> http://bioconductor.org/checkResults/release/bioc-LATEST/Rbowtie/petty-buildsrc.html
>
> The only difference I can make out from the node info pages is that
> perceval has an additional section on "C++11 compiler" that is lacking
> from petty's NodeInfo page.
>
> Unfortunately, I cannot reproduce the issue, both Rbowtie 1.4.5 and
> 1.5.5 build successfully under OS X 10.6.8 and 10.7.5 using llvm-gcc-4.2.
>
> Do you have any idea what else could be different between petty and
> perceval?
>
> Thank you,
> Michael
>
> ___
> 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] differences between petty and perceval (OS X 10.6.8 build machines for release/devel)

[Michael Stadler]

When BioC 2.14 was released, it did work on OS X 10.6.8, but not on 10.9
and neither on some flavours of 32-bit Linux.

The bowtie developers have released version 1.0.1 which addresses some
of these issues. For the remaining one that still made it fail on OS X
10.9, I have been in contact with them and they provided a patch (see
http://sourceforge.net/p/bowtie-bio/bugs/312/) which seems to fix it on
the OS X machines that I have access to, but apparently not for petty.

Going back to the version at release is not an option, since I rate
support for OS X 10.9 more important, especially in the long run.

Michael


On 13.06.2014 15:19, Kasper Daniel Hansen wrote:
> That is pretty weird.  Since this is a segmentation fault in Bowtie,
> perhaps there are resource demands which are only satisfied on perceval
> (tmp space, #cores).
> 
> Presumably this worked when Bioc was released, so what have you changed
> in between?
> 
> Best,
> Kasper
> 
> 
> On Fri, Jun 13, 2014 at 3:32 AM, Michael Stadler  > wrote:
> 
> Hi Dan,
> 
> I'm cc'ing the list; maybe somebody else has experienced differences
> between petty and perceval.
> 
> Rbowtie release (1.4.5) is not building under OS X 10.6.8 (petty).
> 
> Rbowtie release (1.4.5) and development (1.5.5) are virtually identical
> (only DESCRIPTION and NEWS differ).
> 
> The development version builds without problems on perceval, but the
> release version fails on petty:
> 
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Rbowtie/perceval-buildsrc.html
> 
> http://bioconductor.org/checkResults/release/bioc-LATEST/Rbowtie/petty-buildsrc.html
> 
> The only difference I can make out from the node info pages is that
> perceval has an additional section on "C++11 compiler" that is lacking
> from petty's NodeInfo page.
> 
> Unfortunately, I cannot reproduce the issue, both Rbowtie 1.4.5 and
> 1.5.5 build successfully under OS X 10.6.8 and 10.7.5 using
> llvm-gcc-4.2.
> 
> Do you have any idea what else could be different between petty and
> perceval?
> 
> Thank you,
> Michael
> 
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> 

-- 

Michael Stadler, PhD
Head of Computational Biology
Friedrich Miescher Institute
Basel (Switzerland)
Phone : +41 61 697 6492
Fax   : +41 61 697 3976
Mail  : michael.stad...@fmi.ch

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

Re: [Bioc-devel] Bug tracker for Bioconductor?

[Robert M. Flight]

In a similar vein to Yihui's suggestion, could we encourage developers to
use the "BugReports" field of the DESCRIPTION file, and pull that URL out
and link it on the main page of a project? This could be a  link if
the developer wants email to go directly to them, or point to the issues
page of a github repo, or any other bug tracker that the developer wants to
use.

My 2 cents.

-Robert

Robert M Flight, PhD
Bioinformatics PostDoctoral Scholar

Twitter: @rmflight 
Web: rmflight.github.io

The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..." - Isaac
Asimov





On Sun, Jun 8, 2014 at 9:37 AM, Keith Hughitt 
wrote:

> I agree that trying to incorporate all bioconductor projects into a
> single bug tracker could be messy. Although Github could handle this
> (e.g. using project-specific issue labels), it might still become
> overwhelming.
>
> Instead, perhaps it would be best just to spend some time to draft
> some "suggested" conventions for dealing with issues, and follow those
> conventions for the core package.
>
> Then, similar to CRAN, a "issues" link could be included on each
> bioconductor project page to direct people to the relevant issue
> tracker, if one has been setup.
>
> This would make it very straight-forward for users to find where to
> report bugs and feature-requests for any given project. By keeping
> things as "guidelines" or "suggestions", people can still choose not
> to maintain a dedicated issue tracker if they are really opposed to
> it, or to choose an alternative bug tracking system aside from the
> recommended one if they have a strong preference -- the link will
> still be in the same place though so the user can at least find it
> just as easily.
>
> Finally, once some conventions have been agreed on, the pages on the
> (1) setting up an issue tracker and (2) reporting a a bug or feature
> request could be fleshed out a bit more to make it very easy for both
> users and devs to orient themselves. For the devs, this could include
> instructions for setting up the recommended issue tracker, and how to
> populate the relevant field on the bioconductor project. For the
> users, this could include a more detailed description of where to
> report bugs, what information to include, etc.
>
> KeithOn Tue,
> May 27, 2014 at 11:25 AM, Cook, Malcolm < href="mailto:m...@stowers.org";
> target="_blank">m...@stowers.org> wrote: class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
> solid;padding-left:1ex">>> Martin,
>  >>
>  >> I'm sure you're watching this thread.
>  >>
>  >> Can we take it as some "feedback from other developers"
> that you requested way back in  href="https://stat.ethz.ch/pipermail/bioc-";
> target="_blank">https://stat.ethz.ch/pipermail/bioc-
>  >devel/2011-October/002854.html when I wished for
> similar
>  >>
>  >
>  >I don't really have anything constructive to add to the
> thread.
> 
> Actually your history lesson is valuable to the discussion.
>  Thanks!
> 
> Honestly, I really don't have a great problem with things as they
> stand.  I get plenty of attention to _my_ questions/observations
> in a timely and informative manner
> 
> I do think that the BioC project hosting a tracking system might
> eliminate a hurdle for some developers, but the trade-off is hard for
> me to assess.
> 
> Cheers,
> Malcolm
> 
>  >
>  > From a project perspective it would be great to have a
> centralized bug tracking
>  >facility; there are many bugs, they are poorly tracked even
> by the most diligent
>  >of us, and it would benefit users and developers alike to
> have a convenient way
>  >to view our laundry.
>  >
>  >Most off-the-shelf bug tracking systems are not designed to
> work under the
>  >'federated' (I guess that's not the right technical
> description) model of
>  >Bioconductor where there are a large number of individual
> projects, so
>  >implementing a workable solution requires quite a lot of
> effort and / or ongoing
>  >management. As we've seen with the rise of github and its
> use by even key
>  >contributors to the project, it is very difficult to impose
> a central system on
>  >our developers, even for such a key aspect as code
> management. Users are
>  >similarly very difficult beasts to train, so their
> structured participation
>  >would be inconsistent. While on the one hand bug tracking
> might seem like a
>  >no-brainer for an experienced developer, it adds another
> hurdle (along with
>  >mastering version control, the R package system, vignettes,
> ...) to potentially
>  >discourage more novice developers who nonetheless are making
> valuable
>  >contributions to the project.
>  >
>  >In response to the earlier thread, the developers in Seattle
> did use an
>  >Atlassian / Jira based internal bug tracking system and
> pursued it for about a
>  >year, with the goal being to make it available generally if
> it seemed lik

Re: [Bioc-devel] BiocCheck

[Dan Tenenbaum]

- Original Message -
> From: "Kasper Daniel Hansen" 
> To: bioc-devel@r-project.org
> Sent: Wednesday, May 28, 2014 7:20:00 AM
> Subject: [Bioc-devel] BiocCheck
> 
> 1) The hash bang in the BiocCheck script currently requires
> intervention at
> install time.
> 
> It would be much more convenient if the script could read of the
> location
> of R, in the same way as (say) the Sweave script can.  In fact, I
> modified
> the BiocCheck script as per the Sweave script but ran into problems
> with
> .BiocCheckFromCommandLine, and figured I better stop.

I've addressed this in BiocCheck 1.1.4. I just missed the build system cutoff 
for tonight's builds so this will be available on Sunday via biocLite().

> 
> 2) Re. the checks for coding style: it would be convenient if there
> was an
> option (perhaps disabled by default, perhaps not) which lists the
> offending
> files for each "issue".

Still haven't gotten to this yet.

Dan


> 
> Best,
> Kasper
> 
>   [[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] differences between petty and perceval (OS X 10.6.8 build machines for release/devel)

[Dan Tenenbaum]

Hi Michael,



- Original Message -
> From: "Michael Stadler" 
> To: "Dan Tenenbaum" , bioc-devel@r-project.org
> Sent: Friday, June 13, 2014 12:32:52 AM
> Subject: differences between petty and perceval (OS X 10.6.8 build machines 
> for release/devel)
> 
> Hi Dan,
> 
> I'm cc'ing the list; maybe somebody else has experienced differences
> between petty and perceval.
> 
> Rbowtie release (1.4.5) is not building under OS X 10.6.8 (petty).
> 
> Rbowtie release (1.4.5) and development (1.5.5) are virtually
> identical
> (only DESCRIPTION and NEWS differ).
> 
> The development version builds without problems on perceval, but the
> release version fails on petty:
> http://bioconductor.org/checkResults/devel/bioc-LATEST/Rbowtie/perceval-buildsrc.html
> http://bioconductor.org/checkResults/release/bioc-LATEST/Rbowtie/petty-buildsrc.html
> 
> The only difference I can make out from the node info pages is that
> perceval has an additional section on "C++11 compiler" that is
> lacking
> from petty's NodeInfo page.
> 
> Unfortunately, I cannot reproduce the issue, both Rbowtie 1.4.5 and
> 1.5.5 build successfully under OS X 10.6.8 and 10.7.5 using
> llvm-gcc-4.2.
> 
> Do you have any idea what else could be different between petty and
> perceval?

Martin and Nate and I took a look at this. I managed to come up with a bowtie 
command line that would reliably reproduce the segfault on petty.

Then we ran that under gdb (and turned off compiler optimizations) and came up 
with this, which may or may not help you:

petty:vignettes biocbuild$ gdb --args 
'/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rbowtie/bowtie' 
-y -S -k 10 -m 10 -v 2 -r -p 4 --best --strata 'doit/refsIndex/index' 
'doit/SpliceMapTemp_876c378e20ac/25mers.map' 
'doit/SpliceMapTemp_876c378e20ac/25mers.map_unsorted' 
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug 15 16:03:10 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared 
libraries ... done

(gdb) run
Starting program: 
/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rbowtie/bowtie 
-y -S -k 10 -m 10 -v 2 -r -p 4 --best --strata doit/refsIndex/index 
doit/SpliceMapTemp_876c378e20ac/25mers.map 
doit/SpliceMapTemp_876c378e20ac/25mers.map_unsorted
Reading symbols for shared libraries ++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x23d0d92d
[Switching to process 36144 thread 0x20f]
0x000478b1 in Ebwt, 
seqan::Alloc > >::rowL (this=0xbfffda10, l=@0xa300e14) at ebwt.h:1816
1816return unpack_2b_from_8b(l.side(this->_ebwt)[l._by], l._bp);
(gdb) l
1811inline int Ebwt::rowL(const SideLocus& l) const {
1812// Extract and return appropriate bit-pair
1813#ifdef SIXTY4_FORMAT
1814return (((uint64_t*)l.side(this->_ebwt))[l._by >> 3] >> l._by & 
7) << 2) + l._bp) << 1)) & 3;
1815#else
1816return unpack_2b_from_8b(l.side(this->_ebwt)[l._by], l._bp);
1817#endif
1818}
1819
1820/**
(gdb) p this ->_ebwt
$1 = (uint8_t *) 0x4804a00 "\b<2"
(gdb) p *this ->_ebwt
$2 = 8 '\b'
(gdb) p l._by
$3 = 45
(gdb) p l.side 
$4 = &SideLocus::side(unsigned char const*) const
(gdb) p l.side(this->_ebwt)
$5 = (uint8_t *) 0x23d0d900 
(gdb) p l.side(this->_ebwt)[l._by]
Cannot access memory at address 0x23d0d92d
(gdb) p this ->_ebwt
$6 = (uint8_t *) 0x4804a00 "\b<2"
(gdb) 

Running the same command line under valgrind (on a linux box) produces the 
following:

==14916== Memcheck, a memory error detector
==14916== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==14916== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==14916== Command: /home/biocbuild/bbs-2.14-bioc/R/library/Rbowtie/bowtie -y -S 
-k 10 -m 10 -v 2 -r -p 4 --best --strata doit/refsIndex/index 
doit/SpliceMapTemp_876c378e20ac/25mers.map 
doit/SpliceMapTemp_876c378e20ac/25mers.map_unsorted
==14916== 
# reads processed: 24
# reads with at least one reported alignment: 18 (75.00%)
# reads that failed to align: 6 (25.00%)
Reported 18 alignments to 1 output stream(s)
==14916== 
==14916== HEAP SUMMARY:
==14916== in use at exit: 804 bytes in 7 blocks
==14916==   total heap usage: 647 allocs, 640 frees, 278,139,442 bytes allocated
==14916== 
==14916== 4 bytes in 1 blocks are definitely lost in loss record 1 of 3
==14916==at 0x52FB1C7: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14916==by 0x4315DB: HitSink::HitSink(OutFileBuf*, std::string const&, 
std::string const&, std::string const&, bool, bool, RecalTable*, 
std::vector >*) (hit.h:332)
==14916==by 0x41474

Re: [Bioc-devel] BiocCheck

[Dan Tenenbaum]

- Original Message -
> From: "Dan Tenenbaum" 
> To: "Kasper Daniel Hansen" 
> Cc: bioc-devel@r-project.org
> Sent: Friday, June 13, 2014 4:24:27 PM
> Subject: Re: [Bioc-devel] BiocCheck
> 
> 
> 
> - Original Message -
> > From: "Kasper Daniel Hansen" 
> > To: bioc-devel@r-project.org
> > Sent: Wednesday, May 28, 2014 7:20:00 AM
> > Subject: [Bioc-devel] BiocCheck
> > 
> > 1) The hash bang in the BiocCheck script currently requires
> > intervention at
> > install time.
> > 
> > It would be much more convenient if the script could read of the
> > location
> > of R, in the same way as (say) the Sweave script can.  In fact, I
> > modified
> > the BiocCheck script as per the Sweave script but ran into problems
> > with
> > .BiocCheckFromCommandLine, and figured I better stop.
> 
> I've addressed this in BiocCheck 1.1.4. I just missed the build
> system cutoff for tonight's builds so this will be available on
> Sunday via biocLite().

BTW, you'll have to manually delete your BiocCheck script before reinstalling 
BiocCheck in order to get the new one (which does not hardcode any paths).

Dan


> 
> > 
> > 2) Re. the checks for coding style: it would be convenient if there
> > was an
> > option (perhaps disabled by default, perhaps not) which lists the
> > offending
> > files for each "issue".
> 
> Still haven't gotten to this yet.
> 
> Dan
> 
> 
> > 
> > Best,
> > Kasper
> > 
> > [[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
>

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