Bioperl-guts: Re: Bioperl:Bio:Tools:Blast-> parse - failing on the first report in stream
Michael B. Thornton
Thu, 5 Aug 1999 11:17:01 -0700
Hi Bradford (and others), thanks for the reply...... I tried modifying my
process_blast function as you suggested, but I still get the same exception
on the first blast report in the stream.
But I did stumble upon a sort of stupid "work-around" that might help
indicate what's going on.
I have all my blast reports cat'd together in one humongous file. The first
line of the file is:
BLASTX 2.0.9 [07-May-1999]
If you repeat that line at the beginning of the file, the problem goes away.
(I was monkeying with putting a "blank" blast report at the beginning of the
file....I clearly can't pretend to be much of a programmer, I'm just a
humble biologist with millions of blast reports to deal with.....)
From: Bradford Powell <firstname.lastname@example.org>
To: Michael B. Thornton <email@example.com>
Cc: bioperl guts <firstname.lastname@example.org>
Date: Wednesday, August 04, 1999 7:11 PM
Subject: Bioperl-guts: Re: Bioperl:Bio:Tools:Blast-> parse - failing on the
first report in stream
>Michael B. Thornton wrote:
>> Hi All,
>> I have just started to use the bioperl package, in jest for now, but very
>> soon in anger.
>> I would eventually like to take lots of blast reports streaming in on
>> and do things to them. To that
>> end I have a very simple perl script, pretty much lifted from the
>> docs plus stuff
>> reccommended by Steve Chervitz on this board. When I feed a stream of
>> reports to my script (below)
>> I get a fatal exception, *only* for the first blast report. The
>> is as follows:
> <Error removed for space reasons>
>Michael (and list),
>This is actually the same problem as bug #74, which I did not completely
>understand when I submitted it, but I think I have a better grasp on it
>now. It is either a bug in IOManager.pm, or the example blast_seq.pl,
>because they don't get along.
>The problem is that IOManager::read sets $/ (the input record separator)
>to something other than '\n'. In the case of this instance, and in the
>case of blast_seq.pl, it gets set to "\n>" (to delimit fasta records).
>The sticky point is that -exec_func is a callback that gets called from
>within IOManager::read, and thus inheirits the local $/. At least that's
>what I think is happening. It is actually documented, though hard to
>find, by nature of the fact that IOManager is used indirectly. From
> : -REC_SEP => record separator to be used
> : when reading in raw data. If none is
> : the default record separator is used ($/).
> : $/ is localized to this method but be
> : you do any additional file reading in
> : called by this method (see the -FUNC
> : Such methods will use the value of $/ set
> : by read() (if a -REC_SEP is supplied).
>A temporary work-around is to have your process_blast function reset the
>value of $/, possibly by making the first line of the function.
> local $/ = '\n';
>I think this will solve the problem.
>In the longer run, I think this is a confusing issue, and perhaps
>IOManager::read should keep its $/ to itself, perhaps by storing the
>original value in a temp var and reseting it before calling -exec_func,
>then putting it right back to -REC_SEP upon returning. Does this seem
>reasonable? Can anyone think of a cleaner way to do this? At the least I
>think this 'feature' would be documented more clearly in Blast.pm, where
>the -exec_func is defined.
>-- Bradford Powell
>=========== Bioperl Project Mailing List Message Footer =======
>Project URL: http://bio.perl.org
>For info about how to (un)subscribe, where messages are archived, etc:
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org
For info about how to (un)subscribe, where messages are archived, etc: