BioPerl

Matthew, What's an easy way for me to reproduce this performance problem, making the *ptt file? Brian O. On Sep 16, 2014, at 5:16 PM, Matthew Laird <lairdm< at >sfu.ca> wrote:

Mathew, That’s particularly odd; the problem pops up after that commit was added? Would it be possible for you to post a bug report on GitHub issues about this? https://github.com/bioperl/bioperl-live/issues If this is involving anything ... [More] other that a simple next_seq/write_seq loop (e.g. if you are doing any additional data manipulation) it would also help to see example code so we can replicate this; once that is in place we can work on bisecting down the problematic commit. chris On Sep 16, 2014, at 4:16 PM, Matthew Laird <lairdm< at >sfu.ca> wrote: [Less]

It *might* be possible to set this up on Travis-CI independently on Bio::FeatureIO, which would be beneficial from a testing viewpoint (as we need to track what works w/ refactored FeatureIO vs what doesn’t). I suppose what we need to check with a ... [More] refactor (master branch) is: 1) Maintaining a sane amount of compat. with Chado. ‘Sane' meaning Bio::SF::Annotated will need to be chucked or completely reimplemented from scratch, as it is much less than sane now 2) If needed having a concurrently developed version of Chado to make it work. It may not require much on #2 if Chado isn’t reliant on some of the less API-friendly parts of Bio::SF::Annotated (namely the heavy annotation associated with it). chris On Sep 16, 2014, at 4:53 PM, George Hartzell <hartzell.george< at >gene.com<mailto:hartzell.george< at >gene.com>> wrote: < at >scott, do you have test setup for the GMOD stuff? g. ​ On Tue, Sep 16, 2014 at 1:41 PM, Fields, Christopher J <cjfields< at >illinois.edu<mailto:cjfields< at >illinois.ed [Less]

Good afternoon, I wanted to report what I think is an issue but I'm not positive yet. I found this old mailing list posting from May (http://lists.open-bio.org/pipermail/bioperl-l/2014-May/071583.html) about the changes to NCBI's genbank files ... [More] , and I just grabbed the latest bioperl live with August's patch to hopefully solve it. That part worked great, instead of spewing a few GB of warns and the whole sequence multiple times it read the genbank file and wrote out an embl file perfectly fine. However the current bioperl live created a new issue. I have a mirror of NCBI's bacterial genomes directory (yes, I know, I need to move to the new directory structure in the next 6 months) and this pipeline takes the genbank file and makes the embl, ptt, faa, and fna as needed. This usually takes seconds. Whatever changed in bioperl live compared to BioPerl 1.6.922 causes the script to spin doing something very intensely for tens of minutes, slowly writing out the ptt file. Simply copying genbank. [Less]

Cool! I guess I could probably announce this as being released at some point now :) chris PS - I may have a decent test environment set up for longer-term evaluation, but it would be nice to see if we can get something working with travis-ci or a ... [More] smoker setup, just so I can check whether the main branch refactoring is clobbering chado (as I suspect it is). On Sep 16, 2014, at 1:50 PM, George Hartzell <hartzell.george< at >gene.com<mailto:hartzell.george< at >gene.com>> wrote: Hi All, It took a while, but I was finally able to run my little litmus test and the good news is that it appears to pass. I modified my ansible playbook that implements the steps described in INSTALL.Chado<https://svn.code.sf.net/p/gmod/svn/schema/trunk/chado/INSTALL.Chado> so that it uses the version of Bio::FeatureIO that is now on CPAN instead of pulling the github master. The resulting installation ran to completion and then was able to load the yeast gff3 file: cp /vagrant/saccharomyces_cerevisiae.gff . gmod_gff3 [Less]

_______________________________________________ Bioperl-l mailing list Bioperl-l< at >mailman.open-bio.org http://mailman.open-bio.org/mailman/listinfo/bioperl-l

_______________________________________________ Bioperl-l mailing list Bioperl-l< at >mailman.open-bio.org http://mailman.open-bio.org/mailman/listinfo/bioperl-l

Dear all, I've hit a memory leak issue that OOMs our daemons once in a while, and what is worse, I don't have the BioPerl expertise to fix it (I would send a patch otherwise ). The problem is that Bio::Species and/or the modules it uses forms cyclic ... [More] references, which are never killed by perl automatically. I guess either some internal data structure has to be reworked, or there should be some strategic placing of Scalar::Util::weaken, but I have no idea where (or rather, I could devise a hack that hammers weaken() instantly, but I don't think this is the right approach). It's very simple to reproduce, f.ex. by this: use Devel::Cycle; use Bio::Species; find_cycle(Bio::Species->new(-classification => ['A'])); which outputs Cycle (1): $Bio::Species::A->{'taxon'} => \%Bio::Taxon::B $Bio::Taxon::B->{'_ancestor'} => \%Bio::Taxon::C $Bio::Taxon::C->{'_desc'} => \%D $D->{'1'} => \%Bio::Taxo [Less]

There was an AWS security maintenance upgrade that took the site down for a short period. It’s back up now. chris On Sep 12, 2014, at 12:10 PM, D. Joe <bioperl< at >etrumeus.com> wrote:

Went to look for the web site for the first time in a while, seemed down. Checked isitdownforeveryoneorjustme and it's down for them, too. Tried both bioperl.org (as advertized for the project at Github, which is still up) and www.bioperl.org. ... [More] DNS doesnt' look set to expire until December 2014, so that doesn't seem to be it. www.bioperl.org resolves for me to 54.243.166.98, as does www.open-bio.org (which is also down, so it's not, for instance, just a problem with the bioperl-specific web server settings) mailman.open-bio.org resolves to 54.243.246.167 and seems to be up, so I expect this message will go through at least (since the MX for bioperl.org points to lists.open-bio.org which resolves to the same as mailman.open-bio.org). Not sure if this is the best place to report it, but there it is. Hope that helps, [Less]