GOLUB@PENNDRLS.BITNET (Ellis Golub) (02/09/90)
At the risk of adding even more verbiage to the fire, I would like to endorse those contributors, alas few in number, who have remedied imagined deficiencies in the GCG system by writing supplementary code, command procedures or modifying existing code. It must be clear to all by now that each site has its own unique problems, which require personalized solutions. In fact, different groups on the same system may require separate interfaces for optimum utilization. One of the best features of the GCG system is that it can be customized. Anyone who has suffered under the rigors of a more "integrated" package will certainly applaud the flexibility and access available with GCG. Let's not burden this already good system with a heavy "user friendly" layer of I/O. Expansion and improvement of the algorithms and implementations is a better use of the resources of the GCG group. Let's learn to customize for our own sites, and stop tying to impose a unified architecture in everybody. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Question: Does anybody know enough DCL (or have a better solution) to doing automated multiple file conversions with (for example) FROMIG. I hit upon the idea of putting all the sequences in one file, but this solution, while effective, is not general or elegant. I would appreciate hearing from anyone with an idea or a solution. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Regards to all Ellis Golub Biochemistry Department University of Pennsylvania School of Dental Medicine 4001 Spruce Street Philadelphia, PA 19104-6003 Phone: (215) 898-4629 FAX: (215) 898-3695 GOLUB @ PENNDRLS (Bitnet) GOLUB @ MBIO.MED.UPENN.EDU
clark@MSHRI.UTORONTO.CA (02/10/90)
Ellis Golub (GOLUB @ PENNDRLS (Bitnet)) writes:
/Question: Does anybody know enough DCL (or have a better solution)
/to doing automated multiple file conversions with (for example) FROMIG.
/I hit upon the idea of putting all the sequences in one file, but
/this solution, while effective, is not general or elegant. I would
/appreciate hearing from anyone with an idea or a solution.
I would have replied sooner, but I've been a bit behind with my work and
sleep recently, what with all the activity on info-gcg. Since it's for a
good cause, I don't mind too much.
Here's a small command procedure that will probably do what you want. It's
not very flexible in that it will only work with FROMIG, but you can use it
as a base to hack up and add the features you want. The procedure was made a
bit more difficult than I expected because (don't laugh) FROMIG doesn't take
command line arguments. BTW (By The Way), this is a theoretical program in
that I haven't actually tested it to make sure it will work, but it is
conceptually sound even if there may be some little syntactical errors in it.
$ ! Convert IG format files to GCG format.
$ ! Specify the files to convert on the command line, using regular DCL
$ ! filename wildcards if desired. If no name is specified on the command
$ ! line, convert all files (in the current directory) with
$ ! the specification *.IG.
$
$ if("''p1'" .EQS. "") then p1 := "*.IG" ! If no command line name
$ open/write comfile IGCONVERT.CMD ! Make a temp command procedure
$
$loop_start:
$
$ file = f$search(p1)
$ if(file .EQS. "") then goto outa_loop
$ write comfile "$ FROMIG" ! Start the program
$ write comfile "''file'" ! Give it the file to convert
$
$goto loop_start
$
$outa_loop:
$
$ close comfile ! Close the temporary command procedure
$ @IGCONVERT.CMD ! Execute it
$ delete IGCONVERT.CMD;* ! Clean up the droppings
Hope this is the kind of thing you were looking for.
Stephen Clark
clark@mshri.utoronto.ca (Internet)
sinai@utoroci (Netnorth/Bitnet)
"We should be quite remiss not to emphasize that despite the popularity of
secondary structural prediction schemes, and the almost ritual performance
of these calculations, the information available from this is of limited
reliability. This is true even of the best methods now known, and much more
so of the less successful methods commonly available in sequence analysis
packages. Running a secondary structure prediction on a newly-determined
sequence just because everyone else does so, is to be deplored, and the
fact that the results of such predictions are generally ignored is
insufficient justification for doing and publishing them."
- Arthur Lesk, 1988YABLONSKY@BIOVAX.BITNET (Michael D Yablonsky Dept of Molecular Karma at the Waksman (02/13/90)
Ellis Golub writes:
\At the risk of adding even more verbiage to the fire, I would like
\to endorse those contributors, alas few in number, who have
\remedied imagined deficiencies in the GCG system by writing
\supplementary code, command procedures or modifying existing
\code. It must be clear to all by now that each site has its own
\unique problems, which require personalized solutions. In fact,
\different groups on the same system may require separate interfaces
\for optimum utilization. One of the best features of the GCG system
\is that it can be customized. Anyone who has suffered under the rigors
\of a more "integrated" package will certainly applaud the flexibility
\and access available with GCG.
These are all wonderful points if you are located at a site where
your sysops will do such things for you. Perhaps being at a site
with an apparently "raw" GCG package I have a different perspective.
I don't feel that there are "imagined deficiencies". Personally I
don't find the package horribly unmanagable. I just look back at
the learning process (often inspired by the seemingly nutty
questions of real neophytes) and feel that it could have been
(and can be) made simpler and more pleasant. There is no reason
for an application (which is designed for biologists) to arrive
without any sort of "normal language" tutorial. I've seen several
references here to the fact that you can't get the bench scientists
to read the help etc. I think that the authors could provide
something to explain "life with VMS" or the basics of sequence
assembly or searching in a format designed to avoid putting the
biologist into a deep sleep or computer-ese induced coma (thank
you Lisa). Even a decent font in the manual would be an improvement.
I just want to see more consideration for the semi-computer
literates out there. (I think that working with these macs has
warped my sense of computing.) And I don't like to see attitudes
like this...
\Let's not burden this already good system with a heavy "user friendly"
\layer of I/O. Expansion and improvement of the algorithms and
\implementations is a better use of the resources of the GCG group.
\Let's learn to customize for our own sites, and stop tying to impose
\a unified architecture in everybody.
Hell, why be friendly to users, they just come up to my office to
bother me, take up my time. Now if you personally are "user friendly"
enough to make all the "separate interfaces" and "personalized
solutions" great!!! But how about people who aren't at your site!!!
People who have sysops who don't read this digest, don't understand
sequencing or biology period???? People who don't have access to
special seminars on how to do this or that??? It is for this reason
that the extra layer of I/O should be available. Guaranteed
customization, tutoring and support by local sysops is not included
as part of the package, as far as I know.
Mike Yablonsky
Yablonsky@mbcl.rutgers.edu
PS, Udo, this might be considered a flame.
Who would want these opinions??? Certainly not Rutgers University.