[Bioperl-l] Modifying BPlite

Mark, Terry tmark@amgen.com
Fri, 2 Mar 2001 14:43:20 -0800


OK, because I happen to need the effective database length reported in NCBI
BLASTs as reported in an earlier post, I decided to take the advice of Jason
and Hilmar and took a stab at adding this functionality to BPlite.

What I was going to do was add a parameter to the BPlite constructor
('parse_footer') which, if true, would parse the footer by calling a routine
_parseFooter.  

I originally wanted to tuck this call into _parseHeader, so that after
processing the header, if parse_footer was true, I would save the current
file position with tell, read through the rest of the file more or less
indiscriminately (i.e. skipping over the hit/hsp regions), until I saw
things that look like the statistics I'm interested in.  On return, the
current file position would be restored with fseek so as not to break the
subject/hit parsing.

I figured I would have to do something like this because of the way BPlite
works, i.e. it only reads in hits on calls to nextSbjct, instead of reading
all the hits into memory at once a la Blast.pm (presumably this is one of
the things that makes it 'lite' ?).  I also wanted to be able to get the db
length statistics without having to always invoke nextSbjct to completion.

However, I realized that calling 'tell' would NOT work if a script was
called in a pipe, since these obviously provide no file position and no way
to seek backwards.

So I guess I am not sure what the best approach is, and wondered what the
group thought of the problem.

Any suggestions ?
terry



> -----Original Message-----
> From:	Hilmar Lapp [SMTP:lapp@gnf.org]
> Sent:	Tuesday, February 27, 2001 6:32 PM
> To:	Mark, Terry
> Cc:	bioperl-l@bioperl.org
> Subject:	Re: [Bioperl-l] Modifying Blast.pm problems
> 
> "Mark, Terry" wrote:
> > 
> > Hi all,
> > 
> > I need to be able to determine the effective database length used in
> NCBI
> > Blast reports.
> > 
> > Since Blast.pm does not have this functionality, I happily set about
> writing
> > a few lines at the very end of _set_blast2_stats to parse this
> information
> > and save it in a new property,
> > $self->{_effective_length_db}.  The accessor I wrote failed, however,
> and I
> > cannot understand why.
> > 
> > My property _effective_length_db *is* being set properly in
> > _set_blast2_stats, and it *is* still set and visible in the (calling
> > routine) _parse_footer.
> > 
> > However, it seems that IMMEDIATELY after _parse_footer returns to (its
> own
> > caller) _parse_alignment, _effective_length_db is now undef'd.
> > 
> > I have been driving myself crazy trying to figure this out, and wondered
> > (though I really doubt it) whether my problem is related to some
> chicanery
> > in the code that I might be unaware of.
> > Of course the other possibility is that I am doing something really
> stupid,
> > but what I have done really amounts to a single line of code at the end
> of
> > _set_blast2_stats, limiting what I could have done wrong, and the
> property
> > does seem to be set afterwards...
> > 
> > Does anybody have any insight into what might be happening ?  Has
> anybody
> > had similar problems trying to modify _set_blast2_stats ?
> > 
> 
> I have no idea what might be happening there. Blast.pm somewhere keeps
> a static object, maybe this interferes, but that's only a very vague
> chance.
> 
> If you've got a few minutes more time (well, maybe a few hrs, but
> shouldn't take that long), I'd rather like to encourage you to enhance
> BPlite with this functionality. Our problem with Blast.pm is that it's
> a beast which no-one presently maintains, in contrast to BPlite.
> 
> If you're using Bioperl 0.6.2 you'll need to obtain the present
> development tree from anonymous CVS, because BPlite wasn't part of
> 0.6.2. The development tree is pretty stable at the moment and shaping
> up to become the 0.7 release code.
> 
> Sorry I couldn't help more :)
> 
> 	Hilmar
> -- 
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp@gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------