[Bioperl-l] Bio::Tools::Glimmer

[Mark Johnson]

    I think it's going to be at least two modules, one for the
prokaryotic stuff and one for the eukaryotic.  And really, the
prokaryotic stuff is different enough to warrant two modules. So three
different parsers.  Could do it in one, but it would be ugly and
nasty.  However, this does not preclude three parsers and one abstract
interface, which is your excellent suggestion.
    Oh, and excuse me, but I have a bit of a rant here, after dealing
with parsers and pipelines for the last few months.  Parsers should
not load the whole input file into RAM to parse it.  And Pipelines
using the parsers (Ensembl / biopipe) should not stuff the whole
result set from the parser into a single array.  When you're trying to
annotate assemblies, it sucks to have to split up contigs/supercontigs
because the whole result set won't fit into RAM on a 12 gig blade.
Sheesh.  Though this doesn't matter for bacterial genomes, as they're
tiny (by comparison to vertebrates).  There, sorry, been saving up
that frustration for a while.  No offense meant, hope I didn't tick
anybody off.  8)
    Torsten:  You sound like you know what you're doing with respect
to Bioperl more than I do, and I know I don't have CVS access, so I'll
defer to you.  I'd be happy to help out, though.


On 9/20/06, Hilmar Lapp <hlapp at gmx.net> wrote:
>
> On Sep 19, 2006, at 9:13 PM, Torsten Seemann wrote:
>
> > I'm not sure whether to
> >
> > 1. parse them all under the same module, perhaps with a
> > -format=>'glimmerXXX' parameter
> >
> > 2. create a single new module  Glimmer2 and Glimmer3
> >
> > 3. create two new modules, one for Glimmer2 and one for Glimmer3,
> > given
> > they are different outputs both in syntax and number of output files
> >
> > Any advice from Bioperl 'old timers' appreciated ;-)
> >
>
> If at all possible I'd favor 1), with e.g. Bio::Tools::GFF being an
> example for how this can work.
>
> If this would amount to basically 4 modules stringed together into
> one file (because the parsing code can't share much if anything
> between the flavors), it'd still be advantageous to have a single
> frontend module that would then dispatch.
>
>         -hilmar
>
> --
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
>
>
>