[Bioperl-l] results problem with StandAloneBlast
sb at mrc-dunn.cam.ac.uk
Mon Jun 5 13:23:36 EDT 2006
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);
More information about the Bioperl-l