Seq.pm - new version

[Georg Fuellen]

Thanks again to Chris for his efforts! Chris wrote,
>  Hi folks,
> 
>  The new Seq.pm can be found at http://www.ayf.org/~c_raffi/bioperl/
> 
>  The HTML version of the pod docs is at:
>  http://www.ayf.org/~c_raffi/bioperl/Seq.pod-docs.html
> 
>  I was able to implement most of Georg's suggestions, however:
> 
>  - I've given up on trying to use ReadSeq via bidirectional piping.
>    perhaps someone with stronger perl skills can integrate readseq
>    into this module with a litle more elegance :)

I really hope we can find a solution here !
Steve, what do you think ? (I've appended the only comment Chris got at 
c.l.p.m about the matter.) I think integrating ReadSeq is very important b/c 
it also gives users a way for input+output in case the Perl routines fail
(and we shouldn't exclude this possiblity until we look at the formal
definitions of the formats involved, and ``prove'' that our routines
work etc., or at least test them very stringently.)

>  - I was not able to fix/play with the dup() method which is still
>    broken at this time.

Chris: Did you ever look into Data::Dumper ? It seems like a possible workaround.

>  - I've added methods for out_pir(), out_genbank() and out_primer(),
> changed the POD and moved quite a bit of stuff around. I've left other
> notes scattered throughout Seq.pm

Chris/Steve: What do you think still needs to be done before we do a first release
(to those approx. 15 ppl who responded to my recent call for beta-testers) ?
At laest we still need to expand/clean up the POD. 
Chris: Can you wrap things up, try to get as much as possible done from your
to-do list, and then let's have one last detailed look before a first 
release in mid-January ? Does that sound ok?

best wishes + happy new year!
georg

>  Happy holidays.
> 
>  Regards,
>  Chris Dagdigian
>  cdagdigian@genetics.com
> 
> [I will be away at a meeting in NYC from Dec 26 - Jan 1. ]
> ------------------------------------------------------------------------------
> 
>   Manifest of /bioperl/
>   ---------------------------------------------------------
>   Seq.pm                  current module code
>   Seq.pm.old              previous module code
>   Seq.pod-docs.html       the pod2html translation of Seq.pm
> 
>   testSeq.pl              module test script
>   testSeq_layout.pl       test script for output methods
> 
>   testSeq.out             STDOUT from running testSeq.pl
>   testSeq.err             STDERR from running testSeq.pl
> 
>   testSeq_layout.out      STDOUT from runing testSeq_layout.pl
> 
>   sample.tfa              Sequence files used by test code
>   sample.gcg
>   Igfrag.fasta
>   Ifgrag.raw
>   P01703.fasta
>   P01702.fasta
>   P01702.raw
>   bovgh.seq
>   ---------------------------------------------------------
> 
> 



Subject:      Re: bi-directional piping (help!)
From:         aml@world.std.com (Andrew M. Langmead)
Date:         1996/12/19
Message-Id:   <E2oGv4.DKu@world.std.com>
References:   <851014377.26769@dejanews.com>
Organization: The World @ Software Tool & Die
Newsgroups:   comp.lang.perl.misc


cdagdigian@genetics.com writes:


>Following the suggestions in 2nd. ed. Programming Perl, I began trying to 
>use IPC::Open2::open2() to accomplish the same task, unfortunatly I was 
>not able to get any code to work properly-- either the STDOUT and STDERR 
>went to the terminal screen (not the perl code) or the program just 
>generally hung.

The reason that perl disallows open(FH, "|prog|") is because it is
difficult to make work in many cases. the default stdio buffering
often gets inthe way.

The first problem that you mention you had, output still being
directed toward the screen, would be the STDERR output stream. Open2
just leaves the standard error stream in the same place as the current
process. If you want to control it separately, you need the Open3
module (and have to put up with the additional difficulty that it
entails.) or redirect the stanadard error stream in the shell that
perl will spawn to start your program. Either:

  open2(*READ, *WRITE, 'prog 2>&1') || die;

or if you dont' really care about, change the "2>&1" to "2>/dev/null".

Then you start finding you have bigger troubles.

By default, stdio defaults to line buffering if the standard output of
a process is a terminal, otherwise it makes it fully buffered. If the
spawned program does nothing to change these default buffering
characteristics, it will send data to standard output that will never
reach the read filehandle of the calling program. If your calling
program never sees the output, it will probably not send any
additional data and things will be deadlocked.

Comm.pl circumvents this by giving the spawned process a pty to
communicate through. This way if it suses the default buffering
characteristics, the output will be line buffered. If you have control
on how the child process is written, you can change the buffering
yourself, too.
-- 
Andrew Langmead