[Bioperl-l] results problem with StandAloneBlast

[Chris Fields]

> 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.

...

> 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)?

The main thing you should avoid is major API changes or issues which break
this module on other OS's.  I'm not sure that StandAloneBlast is 'broken' by
using a tempfile as the location of the BLAST report.  

Any way you go about it, you'll have to capture the BLAST output as a stream
and get it to persist in a SearchIO object somehow.  It's can be a pretty
decent memory hit to keep that report hanging around, esp. if it is larger.

...

> 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);

That should work, yes.  Didn't see that one your previous response.  I can
get it work w/o problems with SearchIO directly but I haven't tried it with
StandAloneBlast.  Below is my script.  Commenting the seek line below
doesn't move the file pointer so the second round of parsing won't happen.

my $parser = Bio::SearchIO->new(  -file => shift,
                                  -format => 'blast');

my $fh = $parser->_fh;

while (<$fh>) {
     print;
}

seek($fh, 0,0);

$fh = $parser->fh;

print "Second round:\n";
while (<$fh>) {
    while (my $hit = $_->next_hit) {
        print $hit->accession,"\n";
    }
}


Chris