[Bioperl-l] results problem with StandAloneBlast

[Sendu Bala]

Chris Fields wrote:
> If you want flexibility or added functionality then you can always
> contribute a patch, such as adding an option for filehandles, IO::String,
> pipes/forks, or whatever you wish.

Well, it wouldn't be a new feature per se, but just changing the way the 
modules work under the hood.


> Or you could suggest such to the module
> maintainer, Torsten, and then it's his choice whether he wants to make it a
> priority to implement it.  Simply stating this is 'one of things I don't
> like about the bioperl tool system' isn't productive here.

Yes, I apologise for that. I had thought too much would need to be 
changed and backward compatibility wouldn't be possible, but just 
changing StandAloneBlast should be possible.

I use IPC::Open3 for blasts and have never run into problems, but it 
pretty much falls into the 'apt to cause deadlock' camp. It may pass 
tests on one machine but fail on others... is there any point in working 
up a patch (would something of questionable reliability ever be 
committed into bioperl)?


> As for the seek issue, the file handle you get by using '$blast_report-fh()'
> isn't the raw input file stream but is a tied filehandle of a stream of
> ResultI objects:
> ==================================
> Jason's version:
> # seek called on the >>internal<< filehandle (from Bio::Root::IO)
> # this is the raw data input stream from a file, so should work
> seek($searchio->_fh, 0);
> ==================================
> Your version:
> # seek called on SearchIO object filehandle
> my $blast_report = $factory->blastall($ref_seq_objs);
> # this is a tied filehandle for an output stream of objects from SearchIO,
> # NOT the raw input stream
> my $blast_fh = $blast_report->fh();

For academic interest, how do I get the 'raw input stream'? Wasn't that 
what my second version did?

 > my $fh = $blast_report->_fh;
 > seek($fh, 0, 0);