[19777] in Perl-Users-Digest
Perl-Users Digest, Issue: 1972 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 21 03:05:35 2001
Date: Sun, 21 Oct 2001 00:05:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1003647908-v10-i1972@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 21 Oct 2001 Volume: 10 Number: 1972
Today's topics:
Re: $query->param not working. <iltzu@sci.invalid>
Re: Config data not as text file but as module code <goldbb2@earthlink.net>
Re: Filename case... <iltzu@sci.invalid>
Re: Fork messes up parent file handle? <goldbb2@earthlink.net>
Re: Fork messes up parent file handle? <je@brighton.ac.uk>
Re: Fork messes up parent file handle? <krahnj@acm.org>
Re: Good Literature <uri@sysarch.com>
Re: Grep and readdir <goldbb2@earthlink.net>
Re: Help decoding an encoded string from MySql with per <goldbb2@earthlink.net>
Re: How to display text file in cgi-bin? <please@no.spam>
Re: IE6 Error - Perl Output <rob_13@excite.com>
Re: newbie timeout issue <rob_13@excite.com>
Re: newbie timeout issue <glob@cableone.net>
Perl <-> Java <rtrahan@monmouth.com>
Re: Perl <-> Java <goldbb2@earthlink.net>
Re: please check my script <iltzu@sci.invalid>
Re: Scaling a DNA string <dtweed@acm.org>
Re: Scaling a DNA string <goldbb2@earthlink.net>
Re: Tar failure with Pipe Open (BUCK NAKED1)
Re: Vcard (Malcolm Dew-Jones)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 21 Oct 2001 02:56:38 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: $query->param not working.
Message-Id: <1003632757.17135@itz.pp.sci.fi>
In article <slrn9sgaul.30m.efflandt@typhoon.xnet.com>, David Efflandt wrote:
>On Sat, 13 Oct 2001 10:59:16 +0100, Scott Bell <news@scottbell.org> wrote:
>> I have a simple CGI website, but I get this error:
>>
>> Can't call method "param" on an undefined value at
>> /home/sbell/public_html/index.cgi line 52.
>>
>> The code thats causing the error is this:
>>
>> if ($query->param(content) eq home){
>> print "home<br>\n";
>> } else {
>> print "<a href=\"?\">home</a><br>\n";
>> }
>
>Clue, the undefined value it chokes on is the bareword: content. If it
>had gotten past that, it would have errored on the bareword: home.
Actually, it isn't. The error message means $query is undefined. I
agree with you that barewords are bad and should be avoided, but I'd say
the same goes for posting misleading nonsense "answers".
>if ($query->param('content') eq 'home'){
Yes, this is how it should read. But it'll still produce the same error
message, unless the OP assigns a CGI object ref to $query first.
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Sun, 21 Oct 2001 00:17:35 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Config data not as text file but as module code
Message-Id: <3BD24C5F.1663D941@earthlink.net>
Markus Dehmann wrote:
>
> I have several MB of data for a perl script. At first, I stored it in
> a config file and let my script read it into a hash while runtime.
>
> Config File:
> key1;1/2,3/4,4/5 ...
>
> Built hash in script:
> %hash = ( key1=>[[1,2],[3,4],[4,5]], key2=>... );
>
> This works but access to this hash is slow.
Access to the hash, or loading of the hash?
> Now I rewrote my data in the config file directly as a perl hash
> structure.
> I turned my config file directly into a perl module that exports a
> hash with the certain data stored. My config file (now "Data.pm")
> looks like this:
> package Data;
> ... Exporter...
> %hash = ( key1=>[[1,2],[3,4],[4,5]], key2=>... );
> 1;
>
> Using this module the access to data is twice as fast cmopared with
> using the simple config file and building a hash from the data while
> runtime.
I could certainly understand why loading data from this format would be
twice as fast as loading and parsing data, but it doesn't make sense for
accessing to be any different, once the hash was loaded.
> But why? I thought, in the end, the data is stored the same way in
> both methods and uses the same amount of memory...
You're absolutely right. Access should be no different. Only the speed
of loading the data should change.
If your data is really big, as your follow post suggests, you might want
to consider using a database such as DB_File.
First, read it in from your flat file, and store it into the DB:
#!/usr/local/bin/perl -w
use strict;
use DB_File;
use Fcntl qw(O_RDWR O_CREAT);
tie my(%config), "DB_File", "Config.db", O_RDWR|O_CREAT, 0666
or die "Could not open Config.db: $!";
open(CONFIG, "Config.txt")
or die "Could not open config.txt: $!";
while( <CONFIG> ) {
my ($key, $val) = m[([^;]*);(.*)] or next;
$config{$key} = $val;
}
close CONFIG or warn $!;
$! = 0;
untie %config;
die $! if $!;
__END__
Second, use it, remembering to add a fetch filter to turn the strings
into perl data structures.
Here's a sample script, which read from the database and converts the
data back into your original format:
#!/usr/local/bin/perl -w
use strict;
use DB_File;
use Fcntl qw(O_RDONLY);
tie my(%config), "DB_File", "Config.db", O_RDONLY
or die "Could not open Config.db: $!";
tied(%config)->filter_fetch_value(sub {
$_ = [map [split m[/]], split m[,]]
});
while( my ($key, $AoA) = each %config ) {
print $key, ";";
print join(",", map join("/",@$_), @$AoA), "\n";
}
__END__
If you were going to write stuff back into the config file [I assume you
aren't, just based on it's name], youwould need to use
filter_store_value, as follows:
tied(%config)->filter_fetch_value(sub {
$_ = join(",", map join("/",@$_), @$_);
});
NB: This code is untested. Depending on the vaguaries of perl, you
might need to do the "map" part like this:
$_ = join(",", map { join("/",@$_) } @$_);
Which imho, is less pretty.
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: 21 Oct 2001 01:11:56 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Filename case...
Message-Id: <1003624911.13478@itz.pp.sci.fi>
In article <slrn9t43qt.cnu.mgjv@martien.heliotrope.home>, Martien Verbruggen wrote:
>On 20 Oct 2001 17:47:09 GMT,
> Ilmari Karonen <iltzu@sci.invalid> wrote:
>> In article <slrn9scel9.l88.mgjv@verbruggen.comdyn.com.au>, Martien Verbruggen wrote:
>>>
>>>locales. I believe Finnish has some letters that could fall outside of
>>>the A-Z range. A more equivalent, and locale-safe version would be
>>
>> Yes, just like German, French, Swedish, Danish, Norwegian, etc. -- in
>
>Yes, most of these languages have letters that are not one of A-Z
>(interpreted in english). However, AFAIK, thiose languages all collate
>those extra letters between A and Z. I seem to recall in some way that
>Finnish actually collates some extra letters after the Z, letters that
>were imported from Swedish? Something like that. I don't know Finnish,
Yes, the letters Å, Ä and Ö, in that order, are sorted after Z both in
Finnish and Swedish. (Only the last two of them are actually used in
native Finnish words. Their pronunciation more or less matches that of
the corresponding umlauted wovels in German.)
>>>PS. According to perlre, [A-Z] is always a character class of 26
>>>letters. Is this really true? Even if the collation of the characters
>>>is someting like: A a B b C c D ..? perllocale is silent on this.
>>
>> It may or may not be explictly documented for the general case, but at
>> least the EBCDIC ports are documented to treat purely alphabetic ranges
>> as special cases. (Hmmm.. is that behavior locale-aware? I have no
>> idea.) So I'd say yes.
>
>Heh, that's funny. You have no idea, but you're still perfectly willing
>to answer positively? :)
The reason I'd answer positively is that I definitely would not expect
LC_COLLATE to affect character ranges, which are rather more low-level
things than locales. On most systems where Perl runs, they are directly
based on the numeric character codes. The sole reason for the exception
on EBCDIC platforms is the demonstrated utility of being able to treat
the letters A-Z as if they were consecutive, even if they're really not.
And the fact that not doing so would break a lot of existing scripts...
(Just to confuse things further, the range operator ".." and magic
string increment behave in yet another way, neither like character
classes nor like sort(). But that behavior is well documented.)
What I was wondering is if locale might affect the definition of what
constitutes an alphabetic character, and thereby whether a given range
gets the special treatment or not. Thinking about it a bit more,
though, I'd find that highly unlikely and rather pointless.
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Sat, 20 Oct 2001 21:09:36 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Fork messes up parent file handle?
Message-Id: <3BD22050.9EABA578@earthlink.net>
John English wrote:
>
> I have a script which reads lines from a config file and forks off
> a seaparate child process for each line:
[snip]
> What happens is that when a child processes is forked off, the
> parent goes round the loop again and reads the next line from the
> file, except that the file handle has magically been reset to the
> beginning of the file (or a few bytes from the beginning), and
> instead of forking off about a dozen processes I end up forking
> about two thousand of them! (FWIW, this is using Perl 5.6.1 on
> Solaris 8 on a Sun machine.)
I haven't a clue as to why it's happening, but perhaps you could fix or
work around it with seek/tell?
$pos = tell IN;
while(1) {
seek IN, $pos, 0 or die "horribly";
defined($_ = <IN>) or last;
$pos = tell IN or die "horribly";
defined($pid = fork) or die "horribly";
if( $pid ) {
do_parent_stuff();
} else {
do_child_stuff();
last;
}
}
close IN;
NB: This code is untested.
PS: Using foo(); instead of &foo; is generally preferred, unless you
*want* to pass the current argument list, @_, to the subroutine.
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: Sat, 20 Oct 2001 23:54:38 +0100
From: John English <je@brighton.ac.uk>
Subject: Re: Fork messes up parent file handle?
Message-Id: <3BD200AE.950DC0B5@brighton.ac.uk>
Chris Fedde wrote:
>
> In article <3BD18499.47A5308D@brighton.ac.uk>,
> John English <je@brighton.ac.uk> wrote:
> >Chris Fedde wrote:
> >>
> >> You probably want the child to exit(0) after the do_child_stuff rather than
> >> last.
> >
> >When it falls out of the loop there's some common cleanup for both
> >parent and child (close IN; a few other details; then exit), so I
> >was trying to avoid code duplication. However, I did try putting all
> >the cleanup stuff (and exit) inside do_child_stuff, and it makes no
> >difference at all.
> >
>
> You might create the smallest reasonable bit of code that exhibits
> the problem you are seeing and try posting that. The problem is likely to
> be in the details.
OK, watch this space...
-----------------------------------------------------------------
John English | mailto:je@brighton.ac.uk
Senior Lecturer | http://www.comp.it.bton.ac.uk/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
------------------------------
Date: Sun, 21 Oct 2001 02:46:50 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Fork messes up parent file handle?
Message-Id: <3BD237A2.F1C226D6@acm.org>
John English wrote:
>
> Chris Fedde wrote:
> >
> > You might create the smallest reasonable bit of code that exhibits
> > the problem you are seeing and try posting that. The problem is likely to
> > be in the details.
>
> OK, watch this space...
>
OK, but how long? I want to move on to the next message. Please hurry!
John
--
use Perl;
program
fulfillment
------------------------------
Date: Sun, 21 Oct 2001 03:18:53 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Good Literature
Message-Id: <x7d73h4r3u.fsf@home.sysarch.com>
>>>>> "TC" == Tony Curtis <tony_curtis32@yahoo.com> writes:
>>> On Sat, 20 Oct 2001 22:49:11 GMT,
>>> Uri Guttman <uri@sysarch.com> said:
>>>> www.cgi101.com Great place to begin.
TC> "telnet" (telnet? There's a problem before we even start
TC> on CGI) screenshot, introduction chapter. The login name
TC> says it all.
<cowering in fright>
it is probably not the same <deleted> name as we know. i sure hope so.
TC> The entire thing is appalling.
$lowerc =~ tr/[A-Z]/[a-z]/;
This results in $lowerc being translated to all lowercase
letters. The brackets around [A-Z] denote a class of characters
to match.
another moron who can't tell tr from a regex.
and of course the usual broken cargo cult cgi parser where duplicate
params overwrite one another.
funny, how it mentions using CGI fatals to browser but not cgi.pm
itself.
if ($name eq "cities") {
push(@cities, $value);
} else {
$FORM{$name} = $value;
}
}
oh, that is lovely code. to fix the stupid overwrite bug, they now show
you to explicitly test for each multiple value param. watch this grow
and blow up to symbolic references. i can't wait.
i am amazed, she keeps showing customizations to the cgi parser! so for
every form you must write new code. even the cargo culters cust and
paste the same crap each time. she write NEW crap for each form.
here is a fun one:
$value =~ s/\r//g; # remove hard returns
$value =~ s/\cM//g; # delete ^M's
DUH!! those are the same characters. at least on non-mac boxes. and on
those, this will delete all \r and \n.
more stupidity:
# This locks the file so no other CGI can write to it at the
# same time...
flock(OUTF,2);
# Reset the file pointer to the end of the file, in case
# someone wrote to it while we waited for the lock...
seek(OUTF,0,2);
hard coded FLOCK codes.
and the seek makes no sense as seek only affects handles in the current
process. another process can't make this one write to a different spot
(unless the processes shared handles via fork which isn't happening
here).
she is just another clueless moron who thinks they understand cgi and
perl and really doesn't know either one.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 21 Oct 2001 00:31:18 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Grep and readdir
Message-Id: <3BD24F96.5172873D@earthlink.net>
Jürgen Exner wrote:
>
> <NOSPAM@mail.spb.ru> wrote in message
> news:4pi2ttc58aeqf99vp6sguql91iritqsl71@4ax.com...
> > I want to select in a table, all files that begin with for example
> > "abc" (like abc_test.dat, abcdef.txt, etc).
> >
> > The following seemed me correct, but it fails:
> > (the $path IS correct :)
> >
> >
> > opendir (DIR,"$path");
> > @filelist=grep(/abc/,readdir(DIR));
> > close(DIR);
>
> No need to mess around with opendir, why not use simple globbing:
> @filelist=<abc*>;
Eww. Angle quotes for globbing are ugly, and can lead to confusion,
especially if you store your pattern in a variable, and then want to
glob on it -- perl can mistake this for reading from a filehandle.
@filelist = glob("abc*");
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: Sat, 20 Oct 2001 21:20:49 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Help decoding an encoded string from MySql with perl???
Message-Id: <3BD222F1.7FF6C4C4@earthlink.net>
Ryan wrote:
>
> I need to know how to decode a string that I have encoded with MySql.
>
> for example:
> #encode
> $sql = "INSERT INTO users (Name, Password) VALUES('$username',
> (encode('$pass1','rT')))";
> $rc = $DBH->do($sql);
>
> output from encoding:
> ¼-|:l±r
>
> What is the code for decoding??
Most forms of password encoding are one-way, not two-way.
You seem to be assuming that to verify a password, you do:
fetch password from database,
compare [decoded] password with what the user just entered.
The proper way to verify a password is:
fetch the [encoded] password from the database.
encode what the user just entered.
compare the [encoded] password to the [encoded] thing just entered.
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: Sun, 21 Oct 2001 05:12:22 GMT
From: Andrew Cady <please@no.spam>
Subject: Re: How to display text file in cgi-bin?
Message-Id: <87k7xpbmu0.fsf@homer.cghm>
Jerry McEwen <mail@mail.com> writes:
> On Sat, 20 Oct 2001 05:07:51 GMT, Andrew Cady <please@no.spam>
> wrote:
>
> > Jerry McEwen <mail@mail.com> writes:
> >
> > > I have a shopping cart several levels deep in my cgi-bin
> > > directory and orders get written to a file in a sub-folder. We
> > > have SSL and I want my client to be able to access orders.txt
> > > via https, but Perl (or maybe the server's config?) prevents the
> > > file from being displayed.
> > >
> > > My host tells me that I will have to get a script to display it,
> > > but I can't find one. Any thoughts? Thanks!
> >
> > You can use this one, which I haven't tested:
[...]
Ignoring the looming danger of off-topicality...
> Gee, I can't get this to work.
What's it do instead of working? Please be precise, don't make me
guess.
> I understand the difference between full and local path, but do I
> need the actual local path on the server, or is it more like this?
>
> domainname.com/cgi-bin/shop/protected/orders.txt
You want the local path to the file. It should start with a "/".
Perhaps something like /var/www/cgi-bin/... or
/home/yourname/cgi-bin/... Make sure the permissions on the script
are correct. Are you getting the Content-type header? If not, then
this isn't a perl problem, and you should ask your web host for help.
BTW please don't post upside-down (put the quoting first).
------------------------------
Date: Sun, 21 Oct 2001 05:15:25 GMT
From: "Rob - Rock13.com" <rob_13@excite.com>
Subject: Re: IE6 Error - Perl Output
Message-Id: <Xns9141CAEC8DDArock13com@64.8.1.226>
Jeff Zucker <news:3BCF0874.4D7E7479@vpservices.com>:
[Trace the thread for what was said, heavy snippage]
[F'up set]
>> My question is very Perl related especially for a MISC
>> newsgroup. The server
FWIW, its not a server issue either. Ironically, as the Subject
indicates it is an IE6 question. IE6, by default at any rate,
displays its own 404 message when the one from the server is too
small.
--
Rob - http://rock13.com/
Web Stuff: http://rock13.com/webhelp/
------------------------------
Date: Sun, 21 Oct 2001 05:18:17 GMT
From: "Rob - Rock13.com" <rob_13@excite.com>
Subject: Re: newbie timeout issue
Message-Id: <Xns9141D2B39F4rock13com@64.8.1.226>
aj <news:TTuz7.812$Qj7.60809@ozemail.com.au>:
> why would I get a cgi-server timeout problem when I try to
> access a perl script? I have set perl.exe as the default
> application to handle perl file extensions on windows 2000 IIS,
> and have checked that perl is installed properly.
Perhaps the script is not sending a response fast enough? Does the
script work from a command prompt.
--
Rob - http://rock13.com/
Web Stuff: http://rock13.com/webhelp/
------------------------------
Date: Sat, 20 Oct 2001 23:56:41 -0700
From: "David Aslanian" <glob@cableone.net>
Subject: Re: newbie timeout issue
Message-Id: <20011020.235640.1987231011.1557@localhost.localdomain>
In article <Xns9141D2B39F4rock13com@64.8.1.226>, "Rob - Rock13.com"
<rob_13@excite.com> wrote:
> aj <news:TTuz7.812$Qj7.60809@ozemail.com.au>:
>> why would I get a cgi-server timeout problem when I try to access a
>> perl script? I have set perl.exe as the default application to handle
>> perl file extensions on windows 2000 IIS, and have checked that perl is
>> installed properly.
> Perhaps the script is not sending a response fast enough? Does the
> script work from a command prompt.
Yes, try to run the script from the command line and see what happens.
CGI.pm also has a nice offline mode where you can enter name=value pairs
on Standard Input.
If it seems to work fine on the command line (and you're still getting
timeouts), any one of these may help:
1. Telnet in to your own system, and try to GET the file- see what
happens. If you can get a jist of what's happening, then maybe you can
get more specific help.
2. Somewhere near the beginning of the perl script, add this:
$|++;
That "autoflushes" standard output. This basically means that data gets
to the client (most likely browser) right when you tell (print) it to.
3. Check your server's timeout settings.
At least one of these may be able to fix your problem, if not give you an
idea of what is happening. If none of these work, then it's probably not
perl's fault (unless you have came across a very likely situation where i
overlooked something).
------------------------------
Date: Sat, 20 Oct 2001 22:20:12 -0700
From: Richard Trahan <rtrahan@monmouth.com>
Subject: Perl <-> Java
Message-Id: <3BD25B0C.33FE1D51@monmouth.com>
I would like to get Perl and Java speaking. What are my options?
I'd like solutions on both Windoze and Linux.
I already know about sockets. I'm interested in some sort of thread-
safe shared object, like .dll or .so files. Has anyone done either of
these successfully?
I'm trying to escape from the M$ stranglehold, so I'd like to use
MinGW or other GCC, especially since these are known to be well-behaved
with Java JNI files, and can produce both dll's and so's. The XSUB
system on Perl is strongly yoked to MS Visual C++ (e.g., Makefile.PL
outputs a file that contains many features readable only by MS nmake),
and the whole XS system in general seems to be in a state of disarray.
SWIG offers more promise, if I can only decipher the documentation. The
once-touted JPL (Java Perl Lingo) tool seems to have been withdrawn
(it was payware in 1997, then open source), and net chat indicates
that this was a very buggy product anyway.
Restated with less babble, I'm trying to find a toolset that will
permit me to glue Perl and Java, sans Gates. Any suggestions will
incur my unending gratitude. (Well, for a while, anyway.)
------------------------------
Date: Sat, 20 Oct 2001 23:01:30 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Perl <-> Java
Message-Id: <3BD23A8A.E0AAE9B9@earthlink.net>
Richard Trahan wrote:
>
> I would like to get Perl and Java speaking. What are my options?
Go to CPAN, do a search for distributions and modules whose names or
documentation contains the word "java" :
Distributions:
Inline-Java-0.23, Java-JVM-Classfile-0.14, Template-Plugin-Java-0.4.
Modules:
B::JVM::Emit, Inline::Java, Java, Java::JVM::Classfile, Jvm,
Template::Plugin::Java, JNI, and a very NICE thing called Tutorial,
which comes with perl5.7.2, describing how to get perl and java to speak
to each other [mostly using JPL, or java-perl-lingo].
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: 21 Oct 2001 01:47:39 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: please check my script
Message-Id: <1003626844.14008b@itz.pp.sci.fi>
In article <e5a5752b.0110111405.75b44175@posting.google.com>, Kimo R. wrote:
>
>I added an if statement to check HTTP_REFERER to make sure the script
>is being called from the right form. I read somewhere that browsers
>don't always send HTTP_REFERER. Am I correct in using it, or is there
>another way to make sure the script is only used from the right form?
I've posted an answer to this in comp.infosystems.www.authoring.cgi,
where it is on topic. Followups there, please.
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Sun, 21 Oct 2001 01:52:26 GMT
From: Dave Tweed <dtweed@acm.org>
Subject: Re: Scaling a DNA string
Message-Id: <3BD228F9.241AE48@acm.org>
Benjamin Goldberg wrote:
> Your code only scales the non-motifs... this is ok if they are very
> sparse, but can produce strangely wrong output with some data.
Well, the motifs are scaled by the fixed ratio of 4:1.
In any case, I did make some assumptions about sparseness based on the
comments so far and the examples given. Furthermore, the output is
supposed to be more qualitative than quantitative, giving a researcher
a quick overview and a relative indication of where to search further.
If the extreme cases you mention occur, obviously the researcher would
switch to other tools to investigate in more detail.
-- Dave Tweed
------------------------------
Date: Sat, 20 Oct 2001 22:49:39 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Scaling a DNA string
Message-Id: <3BD237C3.ADFF7ABE@earthlink.net>
Dave Tweed wrote:
>
> Benjamin Goldberg wrote:
> > Your code only scales the non-motifs... this is ok if they are very
> > sparse, but can produce strangely wrong output with some data.
>
> Well, the motifs are scaled by the fixed ratio of 4:1.
>
> In any case, I did make some assumptions about sparseness based on the
> comments so far and the examples given. Furthermore, the output is
> supposed to be more qualitative than quantitative, giving a researcher
> a quick overview and a relative indication of where to search further.
> If the extreme cases you mention occur, obviously the researcher would
> switch to other tools to investigate in more detail.
But, from looking at the output of the compression program, how is the
reasearch able to tell that it's one of those 'extreme' cases? Aside
from when the output is longer than the expected 50 characters, it
*looks* almost normal.
--
"What does stupid old man mean pidgin talk?
Shampoo does not talk like a bird."
------------------------------
Date: Sat, 20 Oct 2001 22:53:28 -0500 (CDT)
From: dennis100@webtv.net (BUCK NAKED1)
Subject: Re: Tar failure with Pipe Open
Message-Id: <9020-3BD246B8-102@storefull-248.iap.bryant.webtv.net>
> > ... and do I really need that END block?
> Well, if either child process fails for
> some reason or other, you want to kill
> both of them. Otherwise, they might
> continue running after their parent
> process exits. [snip]
Thanks a lot! I should have known you had a good reason for that END
block. Unfortunately, I commented out that END block and ran the script.
I wondered why my webserver locked me out with a message stating "over
process limit" when I'm well under my allowed space and bandwidth usage.
I guess tar is still running.
Regards,
--Dennis
------------------------------
Date: 20 Oct 2001 19:38:05 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Vcard
Message-Id: <3bd2350d@news.victoria.tc.ca>
Sean Cramb (sean@industrial.bc.ca) wrote:
: Has anyone tried to take data from a html form,
CGI.pm
and format it as a 'Vcard'
(no suggested module)
: then attach it to email?
Various email and mime packages, the names of which I can't check right
now. (Mime::Lite (?) )
: I can't find a module for this.
That's because you need a program. However, two out of three aspects of
that program could be handled by existing modules.
: Sean Cramb
--
Want to access the command line of your CGI account? Need to debug your
installed CGI scripts? Transfer and edit files right from your browser?
What you need is "ispy.cgi" - visit http://nisoftware.com/ispy.cgi
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 1972
***************************************
