[23893] in Perl-Users-Digest
Perl-Users Digest, Issue: 6095 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 8 18:05:38 2004
Date: Sun, 8 Feb 2004 15:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 8 Feb 2004 Volume: 10 Number: 6095
Today's topics:
Re: DBI::mysql column names as hash keys? (Tony)
Re: DBI::mysql column names as hash keys? <gnari@simnet.is>
Re: DBI::mysql column names as hash keys? <tadmc@augustmail.com>
Re: Difficulty cleaning oddly encoded whitespace (from <Petri_member@newsguy.com>
extract links from pdf <ewilhelm@somethinglike.sbcglobalDOTnet>
Re: Getting CGI to read from a different STDIN source <invalid-email@rochester.rr.com>
Re: Getting CGI to read from a different STDIN source <usenet@morrow.me.uk>
komodo 2.5.2 crack please <learn2drive@tesco.net>
Re: komodo 2.5.2 crack please <uri@stemsystems.com>
Re: komodo 2.5.2 crack please <1usa@llenroc.ude>
Re: komodo 2.5.2 crack please <tadmc@augustmail.com>
Re: Need help passing arrays by reference pls. <usenet@morrow.me.uk>
Re: Novice - help with pattern matching needed <not@home.today>
Re: Novice - help with pattern matching needed <noreply@gunnar.cc>
Re: Novice - help with pattern matching needed <robd69@ntlworld.com>
Re: perl and internt functions <steven.smolinski@sympatico.ca>
Re: perl and internt functions (dana livni)
Re: perl and internt functions <tadmc@augustmail.com>
Re: Perl DBI <devdas@users.sourceforge.net>
Re: perl identifier limits <troc@pobox.com>
Perl project update <edgrsprj@ix.netcom.com>
Re: Perl project update <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Perl script into a Windows Service <kevinsproule@hotmail.com>
Re: Soap-Lite XML parameter error, doc must have top le <djoel@bctel.ca>
Re: Time with Epoch earlier than 1970 question <nospam@bigpond.com>
Re: When to "use strict" when teaching? (Mark Jason Dominus)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 8 Feb 2004 06:16:55 -0800
From: hawkmoon1972@hotmail.com (Tony)
Subject: Re: DBI::mysql column names as hash keys?
Message-Id: <c90e5468.0402080616.1c7cde4e@posting.google.com>
Thanks for Tad / Zoltan, but the question is... how do I populate
%vars with values and keys? (where the key is the table & column name)
So this...
printf $vars{"human.name"};
Will print whatever is in the "name" column, of the "human" table (eg.
"Bob"). And this has to work for each column.
It seems easy enough to get the column names returned. You just do
this:
$sth1 = $dbh->prepare("SELECT * FROM human WHERE name = ?");
$rv = $sth1->execute("Bob");
my @names = @{$sth1->{NAME}};
printf "$names[0],$names[1],$names[2]";
This prints "name,age,sex"
The next step, is to get those values to be keys in the %vars hash,
and assign the correct values.
I've read the dbi docs, but there don't seem to be many examples, so
it's rather hard to follow.
:(
------------------------------
Date: Sun, 8 Feb 2004 14:50:01 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: DBI::mysql column names as hash keys?
Message-Id: <c05i90$mt6$1@news.simnet.is>
"Tony" <hawkmoon1972@hotmail.com> wrote in message
news:c90e5468.0402080616.1c7cde4e@posting.google.com...
> Thanks for Tad / Zoltan, but the question is... how do I populate
> %vars with values and keys? (where the key is the table & column name)
>
> So this...
>
> printf $vars{"human.name"};
>
> Will print whatever is in the "name" column, of the "human" table (eg.
> "Bob"). And this has to work for each column.
>
> It seems easy enough to get the column names returned. You just do
> this:
>
> $sth1 = $dbh->prepare("SELECT * FROM human WHERE name = ?");
> $rv = $sth1->execute("Bob");
> my @names = @{$sth1->{NAME}};
> printf "$names[0],$names[1],$names[2]";
>
> This prints "name,age,sex"
>
> The next step, is to get those values to be keys in the %vars hash,
> and assign the correct values.
it is not clear what your problem is.
my $sth1 = $dbh->prepare("SELECT * FROM human WHERE name = ?");
my $rv = $sth1->execute("Bob");
# assuming only one row returned
if (my $res=$sth1->fetchrow_hashref) {
$vars{"human.$_"} = $res->{$_} for (keys %$res);
} else {
# no row found
}
$sth1->finish();
gnari
------------------------------
Date: Sun, 8 Feb 2004 09:45:03 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: DBI::mysql column names as hash keys?
Message-Id: <slrnc2cmbv.f33.tadmc@magna.augustmail.com>
Tony <hawkmoon1972@hotmail.com> wrote:
> Thanks for Tad / Zoltan, but the question is... how do I populate
> %vars with values and keys? (where the key is the table & column name)
I thought that had already been answered...
> So this...
>
> printf $vars{"human.name"};
>
> Will print whatever is in the "name" column, of the "human" table (eg.
> "Bob"). And this has to work for each column.
$vars{'human.name'} = 'Bob';
> It seems easy enough to get the column names returned.
[ snip]
> my @names = @{$sth1->{NAME}};
> printf "$names[0],$names[1],$names[2]";
> The next step, is to get those values to be keys in the %vars hash,
$vars{"human.$names[0]"} = 'some value';
> and assign the correct values.
Use one of the fetch*() routines to get the values.
Once you get the 3 things that you need into variables, populating
the hash should be really easy:
$vars{"$table.$column"} = $value;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 8 Feb 2004 07:58:48 -0800
From: Petri <Petri_member@newsguy.com>
Subject: Re: Difficulty cleaning oddly encoded whitespace (from MS HTML)
Message-Id: <c05mbo0h38@drn.newsguy.com>
In article <bvufkq$ah$1@yojo.cs.utexas.edu>, David R. Throop says...
>> Which perl are you using? If you're using 5.8, try pushing :utf8
>> or (better) :encoding(utf8) onto your input filehandle.
> Let me beg one more question (cuz my PERL 5 Camel Book won't tell
> me.)
> What's the syntax for opening with :encoding(utf8) ? I've tried
> open($FILEname, :encoding(utf8))
> open("$FILEname :encoding(utf8)")
> and a few other variations and I keep losing.
Try:
perldoc -f open
---8<---
You may use the three-argument form of open to specify IO
"layers" (sometimes also referred to as "disciplines") to be
applied to the handle that affect how the input and output are
processed (see open and PerlIO for more details). For example
open(FH, "<:utf8", "file")
will open the UTF-8 encoded file containing Unicode characters,
see perluniintro. (Note that if layers are specified in the
three-arg form then default layers set by the "open" pragma are
ignored.)
---8<---
Hope this helps!
Petri
------------------------------
Date: Sun, 08 Feb 2004 17:51:45 GMT
From: Eric Wilhelm <ewilhelm@somethinglike.sbcglobalDOTnet>
Subject: extract links from pdf
Message-Id: <pan.2004.02.08.11.54.17.396289.3377@somethinglike.sbcglobalDOTnet>
I'm looking for a way to extract the reference and link content from a
pdf file. Ideally, I'd like to be able to create an html version from
the pdf table-of-contents.
I've looked at the PDF::* modules on cpan, but I don't see anything which
allows you to get the links or hrefs out of the pdf.
Thanks,
Eric
------------------------------
Date: Sun, 08 Feb 2004 19:30:34 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Getting CGI to read from a different STDIN source
Message-Id: <40268E51.2090006@rochester.rr.com>
Bill Gerba wrote:
...
> I've run into a problem with CGI.pm. I want to use my own generic
> code to actually capture the raw POST data from a form submission and
> store the whole thing to a file. After I've caught the entire POST
Check out the CGI docs under the section "CREATING A NEW QUERY OBJECT
FROM AN INPUT FILE". That will let you do what you want, as in the
marked-up code below. BTW, I duplicated your problem with your code
under Windoze 98SE, except it didn't give any error message about STDOUT.
> stream, I then want to load all of the data from the file back into
> STDIN and create a new CGI object that will read the data in there and
> parse it out for me. Attached is the code that I'm using, and I'm
> submitting from a very simple HTML form with a few text boxes and
> select widgets (Perl 5.6.1 and Apache on Linux, if it's important).
>
> #!/usr/bin/perl -w
> use strict;
> use Data::Dumper;
> use CGI;
>
> # First, grab the HTTP POST stream and dump it into a file.
> my ($TMP,$DATA);
> open($TMP,">","posted_data.txt");
----------------------------------^
Missing or die ... clause.
> while (read STDIN, $DATA, 1024) {
> print $TMP $DATA;
> }
> close $TMP;
>
> # Next, open the file into STDIN so CGI.pm can read it
> open(STDIN,"posted_data.txt") or die "can't open temp file: $!";
open(IN, "posted_data.txt") or ...
#I didn't try it using STDIN as a filehandle, but it just
#seems nice not to mess with STDIN.
> $| = 1;
Line not needed.
>
> # Print out the data from the HTTP POST as CGI sees it.
> my $cc = new CGI(\*IN);
------------------^^^^^^
> my %v = $cc->Vars;
> print $cc->header();
> print Dumper(\%v);
>
>
> When I run this, it saves the file correctly (all of the data and
> headers are there), but I get a cryptic error message: "Filehandle
> STDOUT opened only for input at test.cgi line 22."
>
> AFAIK, I'm not doing anything at all to STDOUT, and CGI doesn't seem
> to think that there's anything in STDIN at all. But if I don't make
> the CGI object and just do a while (<STDIN>) { print; } I get all of
> my data out fine. What am I doing wrong, and how can I get CGI to see
> the data in STDIN?
...
> Bill
>
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Sun, 8 Feb 2004 19:58:37 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Getting CGI to read from a different STDIN source
Message-Id: <c064dd$581$1@wisteria.csv.warwick.ac.uk>
see@sig.invalid wrote:
> Bill Gerba wrote:
> open(IN, "posted_data.txt") or ...
open my $IN, "posted_data.txt" or die ...;
> > my $cc = new CGI(\*IN);
> ------------------^^^^^^
my $cc = new CGI($IN);
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit. | ben@morrow.me.uk
Musica vel ipsas arbores et horridas movet feras. |
------------------------------
Date: Sun, 8 Feb 2004 15:44:46 -0000
From: "Simon Hughes" <learn2drive@tesco.net>
Subject: komodo 2.5.2 crack please
Message-Id: <LPsVb.4841$q%6.1210694@newsfep2-win.server.ntli.net>
thanks
------------------------------
Date: Sun, 08 Feb 2004 16:00:41 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: komodo 2.5.2 crack please
Message-Id: <x74qu1muhj.fsf@mail.sysarch.com>
you gonna smoke it?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 8 Feb 2004 16:53:19 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: komodo 2.5.2 crack please
Message-Id: <Xns948978F0444C9asu1cornelledu@132.236.56.8>
Uri Guttman <uri@stemsystems.com> wrote in
news:x74qu1muhj.fsf@mail.sysarch.com:
>
> you gonna smoke it?
I wouldn't recommend the OP. It is made from the feces of the Komodo dragon
and is known to cause bad breath.
;)
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Sun, 8 Feb 2004 11:08:53 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: komodo 2.5.2 crack please
Message-Id: <slrnc2cr95.fkk.tadmc@magna.augustmail.com>
Simon Hughes <learn2drive@tesco.net> wrote:
> Subject: komodo 2.5.2 crack please
Thieves go in the killfile.
So long thief.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 8 Feb 2004 11:32:34 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Need help passing arrays by reference pls.
Message-Id: <c056oi$ge4$1@wisteria.csv.warwick.ac.uk>
ko <kuujinbo@hotmail.com> wrote:
> Have never used any of the B
> modules and tried to play around with B::Graph, but couldn't figure out
> how to get output like yours :( . But there's a link at the bottom of
> the documentation, so I'll look at that and at perlguts.
You need dot from http://www.research.att.com/sw/tools/graphviz/; then
run
perl -MO=Graph,-dot -e'...program...' | dot -Tps > ops.ps
. Then look at ops.ps with a PostScript viewer. If you prefer, you can
use -Tgif for GIF output.
I have found that anything more complex than is reasonable on the
command-line will crash dot :(.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: Sun, 8 Feb 2004 15:47:01 -0000
From: "Robert" <not@home.today>
Subject: Re: Novice - help with pattern matching needed
Message-Id: <VRsVb.4850$q%6.1210931@newsfep2-win.server.ntli.net>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:c03u4u$107mv3$1@ID-184292.news.uni-berlin.de...
>
> As regards the approach I have to ask: If you want to extract
> something, why do you not write code that does just that rather than
> deleting everything that you do not want to keep?
It seemed simpler because there is consistency in the stuff to remove but
the value I want to keep could be one of 70 different values, with a variety
of different formats.
>
> $library =~ s/^\s+\d{2}\s\w{3}\s\d{4}\s+//;
> ----------------------^
> What's your considerations behind beginning the pattern with the ^
> metacharacter?
>
This is a leftover from the way the code worked before the introduction of
entries with the "Enter bookmobile....." line. At that time the dates were
always the leftmost item so always matched the ^ metacharacter.
> You may want to replace those three lines with:
>
> my ($library) = /\d{2} \w{3} \d{4}\s+(.+?)(?:- CAMBOOK)?\s+UV/;
>
Thanks. I'll give it a go (and then try to understand exactly what it is
doing!)
Robert
------------------------------
Date: Sun, 08 Feb 2004 17:10:35 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Novice - help with pattern matching needed
Message-Id: <c05n13$13j4u9$1@ID-184292.news.uni-berlin.de>
Robert wrote:
> "Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
> news:c03u4u$107mv3$1@ID-184292.news.uni-berlin.de...
>> As regards the approach I have to ask: If you want to extract
>> something, why do you not write code that does just that rather
>> than deleting everything that you do not want to keep?
>
> It seemed simpler because there is consistency in the stuff to
> remove but the value I want to keep could be one of 70 different
> values, with a variety of different formats.
Okay. As you can see from both my and gnari's examples, that should
not prevent you from capturing rather than removing stuff.
>> You may want to replace those three lines with:
>>
>> my ($library) = /\d{2} \w{3} \d{4}\s+(.+?)(?:- CAMBOOK)?\s+UV/;
>
> Thanks. I'll give it a go (and then try to understand exactly what
> it is doing!)
It can also be written:
my $library;
if ( /\d{2} \w{3} \d{4}\s+(.+?)(?:- CAMBOOK)?\s+UV/ ) {
$library = $1;
}
Please study perldoc perlre about capturing, the meaning of the $1
variable, etc.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 8 Feb 2004 20:35:33 -0000
From: "R Day" <robd69@ntlworld.com>
Subject: Re: Novice - help with pattern matching needed
Message-Id: <J3xVb.428$6W3.240@newsfep1-gui.server.ntli.net>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:c05n13$13j4u9$1@ID-184292.news.uni-berlin.de...
> It can also be written:
>
> my $library;
> if ( /\d{2} \w{3} \d{4}\s+(.+?)(?:- CAMBOOK)?\s+UV/ ) {
> $library = $1;
> }
Thanks. This works as required.
> Please study perldoc perlre about capturing, the meaning of the $1
> variable, etc.
I will do.
Robert
------------------------------
Date: Sun, 08 Feb 2004 16:10:04 GMT
From: Steven Smolinski <steven.smolinski@sympatico.ca>
Subject: Re: perl and internt functions
Message-Id: <wbtVb.304$sO4.54008@news20.bellglobal.com>
Tad McClellan <tadmc@augustmail.com> wrote:
> dana livni <dana_livni@hotmail.com> wrote:
>> i need to connect a certain url and save his source in a directory on
>> my personal computer.
>>
>> how do i do it?
>
>
> use LWP::Simple; # untested
> get_store 'http://www.perl.org', 'some/dir/perl_org.html';
^
I believe you wanted getstore('url', 'filename');
To the OP: see perldoc LWP::Simple.
Steve
------------------------------
Date: 8 Feb 2004 08:27:05 -0800
From: dana_livni@hotmail.com (dana livni)
Subject: Re: perl and internt functions
Message-Id: <1596f85c.0402080827.367aebfb@posting.google.com>
i tried to do so and i get this error:
Undefined subroutine &main::get called at link_list.pl line 11.
so i add this to my script:
my $content = LWP::simple->get("http://www.perl.com/");
and then i got this error:
Can't locate object method "get" via package "LWP::simple" (perhaps you forgot t
o load "LWP::simple"?) at link_list.pl line 11.
Tad McClellan <tadmc@augustmail.com> wrote in message news:<slrnc2b3c2.49t.tadmc@magna.augustmail.com>...
> dana livni <dana_livni@hotmail.com> wrote:
> > i need to connect a certain url and save his source in a directory on
> > my personal computer.
> >
> > how do i do it?
>
>
> use LWP::Simple; # untested
> get_store 'http://www.perl.org', 'some/dir/perl_org.html';
>
>
> See also this Perl FAQ:
>
> How do I fetch an HTML file?
------------------------------
Date: Sun, 8 Feb 2004 11:06:22 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: perl and internt functions
Message-Id: <slrnc2cr4e.fkk.tadmc@magna.augustmail.com>
dana livni <dana_livni@hotmail.com> wrote:
> i tried to do so and i get this error:
> Undefined subroutine &main::get called at link_list.pl line 11.
Did you load LWP::Simple?
use LWP::Simple;
> so i add this to my script:
> my $content = LWP::simple->get("http://www.perl.com/");
^
^
^
Case matters.
my $content = LWP::Simple->get("http://www.perl.com/");
> and then i got this error:
> Can't locate object method "get" via package "LWP::simple" (perhaps you forgot t
> o load "LWP::simple"?) at link_list.pl line 11.
Did you load LWP::Simple?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 8 Feb 2004 17:41:00 GMT
From: Devdas Bhagat <devdas@users.sourceforge.net>
Subject: Re: Perl DBI
Message-Id: <slrnc2ct53.a5c.devdas@evita.devdas.geek>
On Wed, 07 Jan 2004 19:09:35 GMT, Sherm Pendley <spamtrap@dot-app.org> poured
into the usenet group comp.lang.perl.misc:
> On Wed, 07 Jan 2004 08:56:54 -0800, BigDaDDY wrote:
>
>> Also, I still am not sure how to connect to
>> my access database on /mnt/win. Can anyone help me?
>
> Waitaminnit. You're asking how to make a network connection to a server
> that isn't running...
>
MS Access is just a binary blob. Your SQL is in the Jet drivers, so you need
an emulator for those.
Devdas Bhagat
------------------------------
Date: Sun, 08 Feb 2004 20:06:08 GMT
From: Rocco Caputo <troc@pobox.com>
Subject: Re: perl identifier limits
Message-Id: <slrnc2d5v8.eu.troc@eyrie.homenet>
On 7 Feb 2004 22:31:30 -0800, Alex Shinn wrote:
> Rocco Caputo <troc@pobox.com> wrote in message news:<slrnc29n95.eu.troc@eyrie.homenet>...
>> It says something bad about your program if patching Perl is easier than
>> maintaining it.
>
> Don't be a jerk. You know nothing about my code. The Perl patch, however,
> should be relatively trivial, since Perl itself has no problems reading/hashing
> arbitrary length strings.
Mr. Cranky needs a nap before he starts yelling.
I know nothing about your program's source, but I've looked at Perl's.
Where I sit, it still says something bad about your program if it's
harder to maintain than Perl.
> And it's a BUG!!! Apparently Perl hackers are so insecure about their language
> that you can't ask for help with a workaround for a Perl bug without them
> trying to convince you that YOU are the one in the wrong. Nevermind, I'll
> figure it out on my own and never write to this group again.
There's no need to yell. Of course it's a bug. From perldoc perldiag:
Identifier too long
(F) Perl limits identifiers (names for variables, functions, etc.)
to about 250 characters for simple names, and somewhat more for
compound names (like $A::B). You've exceeded Perl's limits.
Future versions of Perl are likely to eliminate these arbitrary
limitations.
So fix it already. The code you're looking for is in toke.c, wherever
you find the symbol ident_too_long.
I, for one, look forward to seeing your patch on the perl5-porters
mailing list.
--
Rocco Caputo - rcaputo@pobox.com - http://poe.perl.org/
------------------------------
Date: Sun, 08 Feb 2004 19:57:35 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Perl project update
Message-Id: <PwwVb.16460$jH6.1455@newsread1.news.atl.earthlink.net>
In earlier posts I stated that various computer programs that I have been
using are no longer powerful enough. I need to find a better language and
was checking Perl, Python, Ruby and several versions of Basic and others. I
also stated that the program feature I was most interested in was one which
would enable the program to control Windows and DOS screens and programs.
For example, if a Windows Notepad text file window was being displayed the
program would need to be able to read information from and write information
to that screen.
I intend to keep evaluating programs. But it was important to get something
going immediately. And so I created an interface between Perl and one of my
existing programs which does a very good of controlling Windows screens etc.
even though it is quite slow. The new interface works beautifully and is
now making it possible for me to start developing programs. If and when I
make a final decision on the best language to use I can simply convert
whatever programs I have created to that new language.
That entire interface is a little complicated. But within the actual Perl
program itself it involves just two lines of code, a "use" statement or
command, and a subroutine which is just one line long. Calls are then made
to that subroutine in order to get something done with the Windows or DOS
program. For example, if I want to print "Test message" to a Windows
Notepad text file screen the subroutine command that I would use is:
wcontrol('`pTest message');
And the subroutine and the interface that it activates then take care of
everything. As I said, it works great. And although I would prefer not to
have to use that interface and the other program it will take me some time
to learn how to do that. I have gone through the Perl OLE and Tk
documentation and looked at Windows Scripting Host programs but did not seen
anything that would do exactly what I wanted.
The reason that I decided to start using Perl immediately was because of a
test I ran involving sorting my earthquake data. And I was amazed at the
results. Perl was able to read 4000 fairly lengthy lines or records filled
with earthquake data from a disk file, sort them, and then store the results
in another disk file in a fraction of a second. I had to run the check a
number of times because I could not believe that it could do all of those
things so quickly. But it did.
After seeing that I decided to go ahead and create that interface, get my
programming started, and then worry about choosing an ideal programming
language later in time.
------------------------------
Date: Sun, 8 Feb 2004 13:23:51 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Perl project update
Message-Id: <7d960c.k0d.ln@goaway.wombat.san-francisco.ca.us>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
On 2004-02-08, edgrsprj <edgrsprj@ix.netcom.com> wrote:
> For example, if a Windows Notepad text file window was being displayed the
> program would need to be able to read information from and write information
> to that screen.
That's amazingly silly. Why Notepad? Why not just take a filename as
input and output to another file and/or STDOUT? Something like
C:\MYLONG~1\myperlprog C:\MYPATH~1\EARTHQ~1.TXT C:\MYPATH~1\EARTHQ~1.OUT
could read from EARTHQ~1.TXT and write to EARTHQ~1.OUT.
Those on a non-Windows OS can substitute more appropriate filenames. :)
Have you corrected the glaring errors on your website yet?
- --keith
- --
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAJqjdhVcNCxZ5ID8RAooRAKCbAhF+qJcfuXKAIvqK5ZEskLxglQCfU+LQ
9KtaDYeBcRZk6C1JGcYKTLQ=
=9iVR
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 8 Feb 2004 11:12:31 -0700
From: "Kevin Sproule" <kevinsproule@hotmail.com>
Subject: Re: Perl script into a Windows Service
Message-Id: <D_uVb.25464$tP1.18372@fed1read07>
"Cosmic Cruizer" <XXjbhuntxx@white-star.com> wrote in message
news:Xns94878D34DB897ccruizermydejacom@64.164.98.51...
> For the last several months, I have been trying to turn a simple Perl
script
> into a Windows 2000 service. I keep finding a lot of question about doing
> this in newsgroups, but I have yet to find an easy to follow solution. Can
> anybody recommend either a book, web page, article, or something that will
> help me out? It almost sounds like setting up a Perl script to run as a
> service is an urban legend.
>
> Thanks,
Here are some generalized instructions that I use all the time to setup Perl
scripts as services under Windows NT 4.0, 2000, XP, and 2003:
Copy the INSTSRV.EXE and SRVANY.EXE files to C:\WINNT\SYSTEM32.
Run: INSTSRV Service_Name C:\WINNT\SYSTEM32\SRVANY.EXE
(This registers the service.) Service_name
Set the "Logon As" to Local System Account in the service properties.
Run: REGEDIT
Follow the chain:
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
Service_Name
Add the KEY: Parameters
Select (highlight) Parameters
Add the String Value: Application
String: C:\PERL\bin\perl.exe ( your path to the perl.exe program )
Add the String Value: AppParameters
String: C:\some_dir\perl_script.pl ( your path to the perl script to be
run )
Exit the Registry Editor.
Start the Service_Name service.
In the event that you want to remove the Service_Name service, stop the
service and run:
INSTSRV Service_Name REMOVE
I hope this helps.
Kevin Sproule
------------------------------
Date: Sun, 08 Feb 2004 21:12:01 GMT
From: "Doug" <djoel@bctel.ca>
Subject: Re: Soap-Lite XML parameter error, doc must have top level element
Message-Id: <BCxVb.12437$QX4.372@clgrps13>
> Hi, I'm using Soap-lite as a client to talk to a .Net server. It
> works great using one parameter. When I add the second parameter, a
> XML string, it fails. When I load the string that it generated into a
> browser it also fails. It doesn't like the < symbols.
This turned out to be red herring. When enclosing an xml string within xml,
all the <>&" chars are translated going in and converted coming out. That's
working as designed.
The problem I had turned out to be the namespaces on the method call and the
parameters. I've got it working in Java, now to figure out how to do it in
soap-lite.
At least I know where to look as the error messages from .Net are misleading
at best.
------------------------------
Date: Sun, 08 Feb 2004 19:28:46 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: Time with Epoch earlier than 1970 question
Message-Id: <c04vnd$12l2ab$1@ID-202028.news.uni-berlin.de>
Tyler Cruz wrote:
> Hi,
>
> I have a database where a date is entered through a form via a user in the
> format (YYYY-MM-DD) format and then converted to epoch, and stored in a
> MySQL database. The reverse is done when extracting this information from
> the database and posting it to the web.
>
> However, since epoch is measured from January 1, 1970, I cannot enter
> dates earlier than that period. I had wanted to store the dates in epoch
> as it makes for easy parsing with the POSIX module, as well as allowing
> MySQL to sort by date through epoch. This is why I didn't want to simply
> return a string as a date; sorting would be out of the question.
>
> Could somebody please help me?
>
> Thanks,
>
> Tyler Cruz
Mysql does not use epoch dates for storage - it uses at least four digit
year. The "ORDER BY" statement uses 4 digit years.
Mysql also runs on systems that know nothing about epochs ie WIndows.
gtoomey
------------------------------
Date: Sun, 8 Feb 2004 19:40:24 +0000 (UTC)
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: When to "use strict" when teaching?
Message-Id: <c063b8$o2p$1@plover.com>
In article <u965em7ki3.fsf@wcl-l.bham.ac.uk>,
Brian McCauley <nobull@mail.com> wrote:
>I suspect your idea of the logical idea to introduce concepts is
>being influenced by the history of Perl
It isn't.
>You are letting your knowledge the evolutionary history of Perl bias
>you towards seeing "use strict" as adding features.
I am not.
I see that you have promoted your suspicion from the first paragraph
to the status of a fact. In the future, you might want to be careful
that you don't forget which things are factually true and which are
the ones that you invented a few minutes before. I think it makes you
look foolish.
>It is not. For someone looking at Perl5 afresh it is more
>appropriate to see it as switching off rarely useful features
>(implicit quoting, implicit declaration of unqualified package
>variables, symbolic references) that are enabled by default for
>largely historical resons.
I think this is a revisionist point of view. Yes, a lot of the
programs that people wrote in Perl historically are short scripts that
don't need 'strict'. But so are a lot of the programs that people
wrote yesterday afternoon.
Those features were originally enabled by default because they were
useful and convenient. Today, that cannot be changed, for
compatibility reasons. But even if they could be disabled by default,
it is not clear that would be the best thing to do, because they are
still useful and convenient.
>> I don't cover 'strict refs' until the following afternoon, after
>> we've seen references; then I can discuss the serious and
>> untraceable problems that can be caused by accidental use of
>> symbolic references.
>
>In a 3-day class probably would never mention in detail the
>consequences of omitting "use strict".
I have a number of objections to that. Some are practical, and some
are ethical.
Here is a practical objection. On day 4 you have gone home. Your
student is writing a program, and it dies in the middle. So they
spend a couple of hours puzzling over what might be wrong, and perhaps
changing stuff around at random because that's what a lot of
programmers do when they encounter an error message they don't
understand. Then they send mail to the guy in the next cubicle, who
was also in your class, saying
Hey, my program doesn't work; it says:
Can't use string ("ARRAY(0x8113f74)") as an ARRAY ref
while "strict refs" in use
What's wrong?
So you taught them to "always use strict", but it didn't do your
student very much good. They have a real error, and the program died,
and now they don't know what to do because you never showed them the
error message or explained what it was about.
Now what happens next? One thing that often happens in your scenario
is that the guy in the next cubicle writes back:
I got that message too, but getting rid of the "use strict"
made it go away.
which of course is a disaster. And the students are not equipped to
understand why that would be a disaster, or to understand the kinds of
problems that arise as a result, because you never mentioned in detail
the consequences of omitting "use strict".
It would be better if the guy in the next cubicle could say
I think that message means that you used a string as if it was
a reference. That ARRAY(0x8113f74) thing looks the way a
reference does when you print it out. Maybe your reference
turned into a string somehow?
and then maybe the first guy says
That sounded awfully familiar, so I looked in the notes we got
in the class and found it on page 142. Thanks!
This might happen in my class, but it can't happen in yours, because
you never mentioned in detail the consequences of omitting "use
strict".
You started out the post by suggesting that I was motivated by an
obsolete historical view of the development of Perl. But that's not
it. I'm motivated by a philosophy that says, in part:
* Programming can't be done by rote.
* More understanding is always better; less is always worse.
* Don't leave out anything important. But if something is
important, you should be able to explain why it is important.
'strict' is important, which is why I put it in, and why I want to
explain *why* it is important. ("Here's what could happen if you
don't put it in.") I don't think that it works to try to put it in
without including the reason why, and I think it's disrespectful to
the students to try to do that anyway. They're adults, they're
professionals, and we should suppose they can be trusted to make the
right professional decisions when provided with the facts.
>That's not my theory. Teaching them to follow good practice is
>separate. Given that we're doing that anyhow "use strict; use
>warnings;" just makes life easier for them.
I think this may be the basis of our disagreement. I think you are
completely wrong here. Good programming practice does not exist in a
vacuum. It was not handed down by God from Mount Sinai. Good
programming practice is precisely the set of practices that make life
easier for programmers. How can making life easier be separate from
following good practice?
There is no such thing as a good programming practice that does not
make life easier, or a bad programming practice that does not make
life harder. If something makes life easier, it is good programming
practice; if it makes life more difficult, it is bad programming
practice. How could it be otherwise?
It is good programming practice for functions to use only lexical
variables. Why? Not because all the books say so. It is because
functions that use global variables are hard to maintain and reuse,
and make life more difficult. Life is easier when functions use only
lexical variables. And that is *why* all the books say so.
It is almost always good programming practice to have 'strict refs'
declarations active in your Perl program. Why? Not because all the
books say so. Not even because Brian McCauley says so. It is because
'strict refs' helps catch certain kinds of run-time errors that would
otherwise make life difficult. Life is easier when 'strict refs' is
on. And that is *why* all the books say so and why you say so too.
Sometimes, in peculiar circumstances, life is easier when a function
uses a global variable for something or other. In these peculiar
circumstances, using the global variable is good programming practice.
Sometimes, in peculiar circumstances, life is easier when 'strict
refs' is off. In these peculiar circumstances, using turning off
'strict refs' is good programming practice.
Many times I have seen people following completely blockheaded
programming practices that are promulgated because they were
supposedly 'good programming practices'. Many real programs are
tremendously complicated because some ass got stuck on some theory of
'good programming practice' and forgot that 'good programming
practice' should be grounded in the reality of what makes real
programs easier to write and maintain.
One common pattern, for example, is the 100-line script whose first 40
lines are
my (%index_hash,
$dev_type,
$ref_label
... (35 more omitted)
$read_dir_def,
$write_dir_def);
So you ask "Why does your program start off with 40 lines of
declarations?" and the answer is "Because otherwise it doesn't work
under 'strict'." This is a fine answer as long as there is more to
it, like "...and I decided that the cost of maintaining the
declaration was worth paying for the benefit of getting spelling
errors diagnosed in variable names."
But if the rest of the answer is "I don't know but someone told me
that everyone should always use strict all the time," it's a lousy
answer. That is exactly cargo-cult programming. There are two
problems with cargo-cult programming. The two problems support each
other.
The first problem is that cargo-cult programming promulgates
ineffective or destructive programming practices by elevating them to
that status of 'good programming practice'. Then people use the bad
practices just because they are labeled 'good'. Even when a practice
are generally good, there is usually some circumstance in which it
should be avoided, because hardly any practice is always good. But
cargo-cult programming promulgates the use of the 'good' practices
even in circumstances for which they are unsuitable.
The second problem of cargo-cult programming is that the labeling
process discourages critical thought about the meaning of the labels.
People are encouraged to adhere to certain practices because they are
'good', and to avoid others because they are 'bad'. The goodness and
badness have become divorced from anything in reality; people
habitually select practices based on the labels, and not based on
reality. They forget that there *is* an underlying reality, as the
labels become the end goal, rather than a means to achieve an end goal
of making life easier. As people lose track of the end goal of making
life easier, life becomes more difficult. Programmers adopt bad
practices because some yahoo has labeled them 'good' and because they
have lost the ability to look at the end result of the practices and
judge for themselves.
Telling people to do stuff that they don't understand often appears to
make things easier for them, but it only does so in the very short
run.
In the medium term, you are just setting up a bigger, nastier
programming surprise for them, when they get the error message (that
you told them to enable) and they don't understand what it means or
how to diagnose or repair the problem that it represents.
In the long term, you are failing in your duty as a teacher, by
encouraging ineffective patterns of thought. Instead of encouraging
"this is what 'use strict' does and this is when and why I would want
to use it", you are encouraging "Brian says to do this, so I will."
In the short term, that might work, but it will not help the student
become a better programmer.
>> But this theory somehow manages to forget that
>> putting stuff into your program when you don't know what it does is
>> the very worst of all possible programming practices.
>
>When I say "use MODULE" I only need to know what it does upto some
>level. The whole point about modularisation is that I don't need a
>full understanding of the internals.
You are confused about what I said. (Or else you are twisting my
words, but I'll give you the benefit of the doubt.) I did not say
"when you don't know how it works". I said "what you don't know WHAT
IT DOES".
We are not talking about the internals here. I am not advocating that
people should understand that behavior of the $^H variable before
using 'strict'. I am advocating that that should know WHAT IT DOES.
> I would tell them the truth:
But not the whole truth. You'll tell them the policy, but not the
technical reality that led to the policy. But that's what I find
disrespectful. These profesionals are supposed to be able to
understand the technical aspects of the policy, but you're not giving
them enough information to do that. If you think that the
programmer's job is to unquestioningly implement the policies laid
down by his supervisor, it's enough. But I don't think that, and I
think it's unethical to promulgate that idea.
>Once I've given them enough information for them to understand why
>omitting "use strict" should be considered a positive action that very
>same argument "putting stuff into your program when you don't know
>what it does is the very worst of all possible programming practices"
>now applies to leaving out strict.
That is a phenomenal display of doubletalk. ("Ignorance is Strength!")
Regardless of the merits of the rest of your post, I feel sorry for
you that you could write this last paragraph without realizing what a
load of bullshit it is.
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 6095
***************************************
