[Bioperl-l] updates, new code, invitation to contribute
jason.stajich at duke.edu
Tue Apr 26 16:11:06 EDT 2005
Some updates and requests.
I'd appreciate if people could start to report in more summaries of
what changes they have committed in addition to what we see in the
bioperl-guts commit list it is useful to have a summary of what's going
on from the authors. In the interest of making the next release easy,
please try and add something to the Changes file to describe any major
additions to the API, squashed bug, or more than formatting changes. I
think we are probably going to need to do at least one or two more dev
releases under the 1.5 series before we can think about a 1.6 so this
log of changes will help us determine what will actually be new in a
Some updates from me.
I just added RST parsing so one can parse ancestral sequences in as
well as per site ancestral codon probabilities at each node in the
tree. Last month I also added parsing of branch-specific parameters
when those constraint models are applied in codeml/baseml. You can get
these values by walking up the tree and getting the tag/values
associated with each internal node. I've updated the SYNOPSIS to have
more examples of these things and as well most things are also shown in
the t/PAML.t tests. I'm working on including these examples in the
Hierarchical parsing works even for joins of joins now. This is using
a regexp solution which seems to be suitably fast but has the problem
of not working on perls < 5.6.1.
I fixed a bug in fastam9_to_table which allows it to parse TFASTX m9
output properly now.
I've tried to expand the cmd-line options that several tools support -
Bio::Tools::Run::HMMER. Better default option handling in
Bug fixing help!
There are a lot of bugs sitting in the bugzilla queue. I realize it
may not seem easy for someone to jump in and work on, but that is how
you learn the toolkit (it's how I learned to do things on this
project). Even if you simply try out to see if the bug is reproducible
that is helpful. Right now feels like me and a few other folks
against this massive wall of things to do and so we're probably only
going to fix the things we are feeling particularly excited about.
So we need more volunteers to do things like take a look at these bugs.
We also need people to help read the documentation, synopsis, etc and
report if it is inconsistent and (preferably) help us fix it. I have
encountered several new converts to Bioperl who are constantly stymied
by not being able to get the Synopsis to work as they expected. Of
course these folks also feel to shy to email the list and tell us
something is wrong, and then it never gets fixed.... So really, help
out, let us know when something is wrong. If you want to help out (and
get your name in shiny ASCII code in the AUTHORS file) contribute a
couple of fixes through bugzilla, if you are doing it right we'll give
you an account and you start helping even faster.
Lots of people, and I mean, lots of people cannot seem to get bioperl
installed. Sometimes this is all I hear from newbies when I meet folks
or teach a class. I think this is really due mostly to the
dependancies, and probably because people don't know how to use UNIX
and/or understand where perl modules go. But people building RPMs
complain, the new OSX users, and of course windows users always seem to
have a lot of trouble getting things working. I think this is more due
to the dependancies than Bioperl itsself.
I think it may be worth considering moving stuff that has lots of
dependancies out of the main core code and into separate installable
packages. IO::String is not a large dependancy, but LWP starts to be
add any of the XML modules, Graph, etc and it seems to be too large of
a hurdle for many new folks. Maybe anything which depends on code
linked to an external C library would be a candidate. I think more
discussion is warranted for sure, this would not be an easy thing for
us to undertake. But in the end it would produce a slimmed down core
set of pure-perl modules that would be easy to use out of the box. The
other alternative is to make a slimmed down bioperl-lite which is just
and export and subset of bioperl modules which are pure-perl and have
little or no dependancies...
This would make it easier for people who don't need all the extra bells
and whistles. I think it doesn't necessarily split by directory
namespace however, for example SeqIO has some XML dependent modules
which (under this proposal) get moved into a separate package.
At any rate, that is all food for thought and perhaps can be discussed
by folks over the summer at the upcoming meetings and hackathons.
jason.stajich at duke.edu
More information about the Bioperl-l