[10092] in Perl-Users-Digest
Perl-Users Digest, Issue: 3686 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 10 19:07:31 1998
Date: Thu, 10 Sep 98 16:03:20 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 10 Sep 1998 Volume: 8 Number: 3686
Today's topics:
Re: Perl & Java - differences and uses (Mike Stok)
Re: Perl & Java - differences and uses <jdporter@min.net>
Re: Perl & Java - differences and uses <jdporter@min.net>
Re: Perl & Java - differences and uses (Matt Knecht)
Re: Perl & Java - differences and uses (Cameron Laird)
Re: Perl & Java - differences and uses <jdporter@min.net>
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl-Cgi-htaccess is this as simple as I think it i (Alastair)
Re: replacing text in a string <mark@satch.markl.com>
socket accept() vs. CGI.pm accept() <sharper@cisco.com>
Re: ssi exec error... <jbattikha@highsynth.com>
Time in milliseconds <curt@vphos.net>
Re: Time in milliseconds (Michael Fuhr)
Re: Tokenizer in Perl... (Craig Berry)
Re: Tokenizer in Perl... <tchrist@mox.perl.com>
Re: Tokenizer in Perl... <vincent@compclass.com>
Re: Where to find CGI.PM for PerlW32 Build 316 (Alastair)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 10 Sep 1998 21:37:49 GMT
From: mike@stok.co.uk (Mike Stok)
Subject: Re: Perl & Java - differences and uses
Message-Id: <6t9grd$e4r@news-central.tiac.net>
In article <6t9bkt$r8o$1@nnrp1.dejanews.com>, <bitnut1@my-dejanews.com> wrote:
>I hate to throw cold water on both Perl and Python camps but there are
>interpreters that are: 1. Intrinsically better (meaning: can accomplish
>similar tasks without the noise and illogical constructs that plague Perl and
>Python); and 2. ANSI standard (or soon to be).
... maybe the "noise and illogical constructs" are why some people like
perl and python. To me the idea that one language or one OS fits all well
enough to relegate all others to the dustbin seems flawed.
>Perl and Python will end up in the dustbin sooner or later and
>no amount of your kicking and screaming is going to save them.
See you there :-)
Mike
--
mike@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ | PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.tiac.net/users/stok/ | 65 F3 3F 1D 27 22 B7 41
stok@colltech.com | Collective Technologies (work)
------------------------------
Date: Wed, 09 Sep 1998 17:57:17 -0400
From: John Porter <jdporter@min.net>
Subject: Re: Perl & Java - differences and uses
Message-Id: <35F6F9BD.B6FA04D@min.net>
bitnut1@my-dejanews.com wrote:
>
> I hate to throw cold water on both Perl and Python camps but there are
>...
> no amount of your kicking and screaming is going to save them.
What do ya say, George, shall we go kick this guy's ass?
--
John Porter
------------------------------
Date: Wed, 09 Sep 1998 17:55:31 -0400
From: John Porter <jdporter@min.net>
Subject: Re: Perl & Java - differences and uses
Message-Id: <35F6F953.4E97F271@min.net>
George Reese wrote:
>
> In comp.lang.java.programmer John Porter <jdporter@min.net> wrote:
> : George Reese wrote:
> :>
> :> In comp.lang.java.programmer John Porter <jdporter@min.net> wrote:
> :> : George Reese wrote:
> :> :>
> :> :> Anything that can be done in Perl can by done in Python more easily.
> :>
> :> : That's not "backing it up", that's another dangling allegation.
> :> : It sounds an awful lot like a religious assertion, which I would
> :> : not have expected from you, based on statements you have made
> :> : elsewhere in this thread.
> :>
> :> Nonsense. It is actually a really easily testable hypothesis.
>
> : O.k., it was a dangling hypothesis, i.e. one provided sans support.
>
> It is not one that requires support.
Fine; but what are we to think when you offer a hypothesis
in answer to a call to "back that up"? It's one idle claim
thrown after another.
> : My use of the term "allegation" was loaded, but not inaccurate.
>
> You said "religious assertion",
Oh, yeah. :-)
> not "allegation".
But I did say that too.
> And that was not inaccurate, it was nonsense.
Hm. Your definition of "nonsense" and mine are different.
Seems we have a semantic problem.
> : (And dare I suggest that your language is straying dangerously
> : close to the ad hominem zone...)
>
> I have made no claims about you; I have not called you any names.
I said "close to", not "into".
> I am certainly open to the possibility something out
> there exists for which Perl is better suited than Python. But I think
> it should be a hollow victory unless you can go beyond my mandate and
> show that Perl is significantly better suited to the task in
> question.
You talk of "better" as if it were based upon universally accepted
principles. But of course different stakeholders (developer,
employer, customer, etc.) have different needs that color their
valuation of language choice. I find Perl "better" for my own use,
generally; but my customer has other ideas...
How can you and I agree what the basis should be, upon which Perl
can be evaluated as possibly better than Python?
> Furthermore, in order for Perl to actually be 'a better
> language' than Python, you would have to show that this (or any other
> potential strengths) override the tremendous downside of the
> design inconsistency, poor maintainability, shoddy object model of
> Perl.
Naturally. In fact, showing that these characterizations of Perl
are mythical would be a fundamental part of my approach.
Where do you live? Let's go have a beer.
> Since that is so difficult to prove,
Impossible, in fact, for one of two reasons:
1. those characterizations are false;
2. they're entirely subjective.
> :> : I *can* read and maintain Perl code.
> :> : It's all a matter of what language(s) one already knows.
>
> Not in the least.
Yes, in the least (at least), as you already said.
Fact is, I know Perl; I can read Perl and I can maintain Perl.
I don't know Python, I can't read Python, and I can't maintain
Python. This is nothing against Python, of course; it is
merely a result of my language repertoire.
> And [OO] is where Perl is incredibly weak.
> Not only was an OO paradigm an afterthought,
> it was a horribly hacked together afterthough.
This demonstrates to me that your understanding of OO perl is
"incredibly weak" -- nothing else.
I'm not saying Perl's OO doesn't have a minor problem or two;
but its design dovetails very neatly into the rest of the
language. It added one keyword, and one other keyword-like
variable (used for declaring the parents of a class).
It's very dynamic in nature, just like the rest of the language.
Maybe that's why some people don't like it. Perl tends to
appeal (in this respect) more to ex-Lisp programmers than to
ex-Fortran programmers.
> Then there is the ability to read code. Perl is the only language I
> know of where an expert has to concentrate to read the code of another
> expert.
You don't get out enough. Every language is like this, to some
degree; only religious fanatics claim otherwise. (Go read comp.lang.
cobol for examples.) This is a straw man, anyway; what's wrong
with concentrating? I don't think a program should read like
a novel, and experience shows that it would be a ridiculous
expectation.
> God forbid you ask a newbie to maintain Perl code.
You're right; that why God sent us Bill Gates: to make
the world safe for newbies.
> You are misunderstanding the role of generalization. The truth value of
> that proposition is completely independent of whether it happens to be
> true of you in particular.
No, I understand it o.k. I understand that your generalization is
false. You're saying that Python is so natural-looking that
people can understand it without learning it, and so the old
paradigm that one must know a language in order to read and maintain
it is obsolete. I'm saying that is a delusion -- and a dangerous
one, too.
But let's be quite frank. Your statement:
> And you can actually read and maintain the Python code.
was not meant so much as a positive statement of Python's
character as a slam against Perl. To wit:
> You can't read nor maintain the Perl code.
But I am a counterexample to this hypothesis.
Whatever may be the truth about Python's readability,
your statement about Perl's is not categorically true.
> I think, however, one look at any perl code
> speaks for itself to the general populace.
*Any* perl code? Get ready for a flood of counterexamples.
> : I don't regard its syntax as horrid; certainly no worse than some
> : of the other score-odd languages I know.
>
> You know worse? I am sorry if I don't find that defense of Perl.
Well it is a defense against that particular accusation,
if the horridness of all languages is taken to be relative,
rather than guaged against some ideal.
Besides, if we allow that Python's is better than Perl's,
that's not saying much for Python's, now, is it.
> "Beauty is in the eye of the beholder" is the mantra of ugly people.
As an ugly person, I take offense at your remark. ;-)
But that's off-topic.
> People defending nasty languages
> often claim that "nasty is in the eye of the beholder".
Hm, not the tack I would have taken against that argument.
I would have said, "o.k, so you have nasty in your eyes;
obviously Perl would appeal to you, then."
But as the creator of Perl has said (and forgive my
brutish paraphrase), Perl was not designed to be beautiful,
it was designed to get things done. It's a mule, not a
Lipizaner.
> But the proof is in the pudding.
> Most people will find python code much more
> readable than Perl code for most applications.
> Not everyone, but a good portion.
Proof by popularity is no proof at all.
Or do you really think MS Windows is a Great Operating System?
--
John Porter
------------------------------
Date: Thu, 10 Sep 1998 21:59:48 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: Re: Perl & Java - differences and uses
Message-Id: <oZXJ1.18$VG5.192279@news2.voicenet.com>
George Reese <borg@imaginary.com> wrote:
Let me start by saying that I've been meaning to learn Python for quite
some time now. Mostly because a lot of Perl authors seem to think it's
a very good language (Sriram Srinivasan and Tom Christiansen to name two
of them). But, I haven't yet had the time to put into it.
>: python -c 'import sys; import string; \
>: print string.atoi(sys.argv[1], 16)' 40
>
>: perl -e 'print hex shift' 40
>
>Actually, I just did a test and showed both to people who know neither
>language (IMHO, the best judges in a case like this). The funny thing
>to mee is that both seem like 6 and 1/2 dozen. Which is why I find it
>funny anyone would even bring this up as an example. But the
>non-experienced in python and perl to whom I showed this seemed to
>have a serious problem with 'hex shift' and found the python version
>more straight forward.
Were you showing these to programmers or non-programmers? If so, did
they understand the meaning of sys.argv? Could they understand what
that 16 is refering to? I can guess that atoi (And a guess it is, as
atoi is a C function to me) is converting the argument to base 16. Why
you need to import anything to deal with arguments is beyond me. Did
the people you showed this to wonder that as well? Did they know what
the sys library was and did?
>I find that interesting. Nevertheless, either way, I think this
>example shows nothing except that the two languages do things
>differently.
Isn't that your whole point? They do things differently, and you think
Python does them 'better'. The same could be said of any language
comparing to any other! At any rate, we'll chalk this one up to
differene of opinion.
>Can't the "I love perl" crowd come up with some meaningful functional
>benefit of perl?
Hrm. I'll ignore the slight intended by the '"I love perl" crowd'
remark.
But, I must wonder at why the onus is on the Perl crowd. This thread
started as a comparison of Java and Perl. It continued on that path
until you posted about Perl being a terrible language (I'm paraphrasing,
but that's how I perceive your posts here). You then said that "Python
is better than Perl at everything" (Again, paraphrasing) and demanded an
example to prove otherwise. I don't understand why you don't take
matters into your own hands, and show the Perl community why Python is
better. In fact, I ask you to do this!
But, you did ask, and I'll give you a non-trivial example. I have a few
"Intro to Python" pages bookmarked. I won't post the Python code,
because it's far too long (And I'm afraid that without a better
knowledge of Python, I'll ruin the indenting and make the code invalid).
Here's the URL to a program that converts tabs to 4 spaces:
http://www.strout.net/python/tidbits.html#tabfix
It's quite a large, and suprisingly complicated program for such a
simple operation. Here's a line from the perl FAQ:
1 while $string =~ s/\t+/' ' x (length($&) * 8 - length($`) % 8)/e;
The literal 8 can be substituted with any number you'd like to convert
your tabs to.
You may claim that this looks like line noise, but I would counter that
claim that the Python code looks like somebody grabbed random words from
a dictionary and strung them together with colons and periods. I'm
relativly new to Perl, but it takes me about 10 seconds to parse that
line. If you don't care for the special variables $& and $`, you can
always use their English names (Although, the only thing they are good
for is letting a very novice user remember things more easily. IMHO
they hamper readability.) "$PREMATCH" and "$POSTMATCH". In contrast it
took me a full minute just to *read* the Python code, let alone trying
to figure out what was going on.
Oh, and there's an even simpler Perl solution to the tab problem. Use a
builtin module:
use Text::Tabs;
@expanded_lines = expand(@lines_with_tabs);
It doesn't get much easier than that. A **LOT** can be trivially
accomplished in Perl with the use of modules. I invite you to check out
your nearest CPAN.
--
Matt Knecht - <hex@voicenet.com>
------------------------------
Date: 10 Sep 1998 17:10:46 -0500
From: claird@Starbase.NeoSoft.COM (Cameron Laird)
Subject: Re: Perl & Java - differences and uses
Message-Id: <6t9ip6$1ns$1@Starbase.NeoSoft.COM>
In article <01bdd923$64cd49a0$4516b3d1@lhodgkiss>,
bjohnsto_usa_net <bjohnsto_usa_net@dejanews.com> wrote:
>Jim,
>
>A number of people have replied to you with the differences between the
>perl language and the Java Language. This is somewhat interesting, but
>another, in my view far more important aspect of the issue is the what is
>the environment for the language.
.
.
.
Perl and Java deserve also to be seen as *complements*,
not just competitors: <URL:http://
www.oreilly.com/catalog/prkunix/info/more_jpl.html>.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com +1 281 996 8546 FAX
------------------------------
Date: Wed, 09 Sep 1998 18:15:30 -0400
From: John Porter <jdporter@min.net>
Subject: Re: Perl & Java - differences and uses
Message-Id: <35F6FE02.3A5C78C3@min.net>
George Reese wrote:
>
> In comp.lang.java.programmer John Porter <jdporter@min.net> wrote:
> : Um, the goal was to show how "Perl accomplishes a task easier".
> : This may or may not be equivalent to "better", in your moral
> : framework; but I'm having a hard time seeing how
> : python -c 'import sys; import string; \
> : print string.atoi(sys.argv[1], 16)' 40
> : accomplishes its task easier than
> : perl -e 'print hex shift' 40
>
> It doesn't. And the perl version is not easier either. Just fewer
> keystrokes.
Well, as a programmer, fewer keystrokes is worth something.
But in my (perhaps biased, admittedly) view, calling three
atomic intrinsic functions seems rather easier than pulling
in two modules (or classes or libraries or whatever they are),
calling methods on/in both of them, plus a call to an intrinsic
function.
> Unless your sole goal is 'coding in the fewest
> keystrokes', I do not see how you can argue one version is
> meaningfully different than the other.
Rather than tax your imagination unnecessarily, let's
formulate a framework for algorithms whose Perl & Python
implementations shed light on the issue.
> : As Mr. Reese's recent posts in comp.lang.perl.misc neatly demonstrate.
>
> Cannot deal with someone attacking your pet language so you resort to
> attacks on my character?
Now you're accusing me of the ad hominem?
No, I was talking about your posts, not you.
Surely you don't think that none of what you said could be taken
as trolling...
Might I also point out that Perl is no more my "pet language" than
Python is yours, and that your saying so was unnecessarily
provocative?
--
John Porter
------------------------------
Date: 10 Sep 1998 22:24:41 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <905466113.40215@thrush.omix.com>
bjohnsto_usa_net@my-dejanews.com wrote:
: In article <905295043.652672@thrush.omix.com>,
: Zenin <zenin@bawdycaste.org> wrote:
: > Sand boxes are only really useful for enterprise apps, as no
: > one else is (or should be) foolish enough to allow them for
: > general web sites.
: Don't understand what you mean. Are you taking about the methods to give
: signed applets extra permissions? Even if they were supported by the popular
: browsers, I think that you should try to remove the need for these from your
: architecture.
For general web sites, I agree with you. For enterprise apps, there
is no reason to ignore such functionality as presumably a company's
employees can trust applications written for and by the company,
regardless of the platform. In such closed systems, the are at
least no less secure then a full local app.
: > I run pretty wide-open, but I do it from an highly restricted
: > login.
: I use Windows95 at work wide open, and Windows 95 will let anyone do anything.
: If I had some choice and did use something decent I would probably still use a
: reasonably powerful login.
Some of us can't put our systems at quite such a risk.
: Yes, the database vendors can't make their products/architecture work with
: many simultaneous users. Pretty pathetic really.
It's not the fault of the database if the application can't scale,
it's the fault of the designer that used the database incorrectly.
As I've mentioned, I've got systems in place that handle 3k to 10k
simultaneous users through as little as 10 Oracle connections. Ford
can't help it if you connect your big block 400 to the drive chain
using a bicycle chain.
: > lacks the basic primitives (select(), non-blocking IO, file
: > descriptor passing, etc) to compete for use in writing servers
: > under Unix (thread all blocking IO my ass...).
:
: Not sure I agree. The servers I have written have all been fairly low volume,
: and Java would have been fine.
That's the key, low volume. One can easily write low volume inetd
servers in shell script. If you're only doing low end server work,
they pretty much any language and/or code design will work.
: Non blocking file IO would be pretty easy to add as a JNI call. I guess
: select is some kind of wait for multiple semaphore/socket wait call but I
: have never done any unix systems stuff so I don't know.
Non-blocking IO is just one of many, many features Java is lacking.
Select() has nothing to do with semaphores, and little to do with
waiting on sockets.
: I guess the Java people just want you to use more threads.
Yes. They are sponsored by the memory and CPU manufactures, I'm
sure of it. Personally, I feel people should be required to test
for a competency license before being allowed to use threads. Of
course, I feel the same way about USENET. :-)
: Maybe now that Sun is looking more towards Java on the server al well as in a
: set top box, you will get more of the what you need.
:
: Maybe in addition to Personel Java we will get Server Java.
The reason Java lacks the needed primitives I listed before is
simply because they are not "portable" in the Java sense. Eg, they
are pretty much impossible to replicate on a Win32 or MacOS
platform, let alone a WindowsCE toy.
: > Even JDBC from
: > Servlets is worthless with 3k-10k simultaneous users, which is
: > common for enterprise level applications.
: Servlets are improving fast.
: I don't see any major long term issues with the architecture.
For the people thinking it will solve there applet to database
connectivity issues, they are in for a big supprise. Web server
cached database connections of any kind scale like mud.
Remember, if you've got 20 httpd children, you've got 20 cached
database connections. Oh, you want to have three different parts
of the web site (or virtual hosts) use three different database
logins? You can kick that up to 60 connections. Have a
"development" "test", and "production" setup? Make that 180 or so.
Oh, you don't plan to put that much traffic through them? Tough,
the connections can't be shared across web server children so even
if you only use the connection once an hour I'm still going to have
to keep a cached connection per child.
Ever see what the common Oracle server does with 200 connections?
Let's just say I hope you've got a huge amount of swap space. :-)
Like I said, the design is inherently flawed, regardless if you're
using Servlets, Apache/DBI cached handles, or Netscape NSAPI
handlers.
So why does it work then? Simply because 90% plus of the web
servers around never have to scale large enough to hit this
problem. I work in the other < 10% that does need to exceed
this bottleneck.
: > To be honest, Java is pretty darn good for client apps, but
: > for servers it bites, and without an extra tier or three it
: > can't scale database access well at all (but then, neither
: > can anything else, really, for the same reasons).
: Databases themselves are the limiting factor.
: They are an order of magnitude slower than any of the web technologies.
How much high end database work have you done? Databases can
more then keep up with the requirements of web and similar
technologies. It's not just a performance issue however, or
everyone would be running MiniSQL over Oracle. It's a feature
issue. If you need the kind of features Oracle, Informix, etc
offer you just can't get it out of web technologies alone. And
if you try, you'd be many orders of magnitude slower then everything
else on the planet, in both raw performance and development time.
Again, it's the total system design that's the real problem. Many
people blame both Perl, Java, Oracle, CORBA, and others for
being slow, but more often then not if you actually look at the
code and systems they are using to base such opinions on you'd
laugh your ass off. It boggles the mind what some people
actually charge money for these days. The same designs in
assembly would still be slow as mud.
If a carpenter can't hammer a nail correctly, it's unlikely
the hammer or the nail is at fault.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: Thu, 10 Sep 1998 21:50:20 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: Perl-Cgi-htaccess is this as simple as I think it is?
Message-Id: <slrn6vgm3l.4h.alastair@calliope.demon.co.uk>
dmorel <dmorel@stny.lrun.com> wrote:
>OK so this is the kind of thing I was worried about.
>In then the opinion of Jeff at least, I am dealing with a relatively
>serious
>security issue here?
You could also ask your question in the news group ;
comp.infosystems.www.authoring.cgi
BTW - your lines are wrapping strangely.
HTH.
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: 10 Sep 1998 16:45:21 -0400
From: Mark Lehrer <mark@satch.markl.com>
To: gebis@fee.ecn.purdue.edu
Subject: Re: replacing text in a string
Message-Id: <m3r9xjhf32.fsf@satch.markl.com>
gebis@fee.ecn.purdue.edu (Michael J Gebis) writes:
> }What is the best way to substitute a few characters in the middle of
> }a string? I am using the slowest possible method:
>
> }$foo="123abc789";
>
> }$newstr=substr($foo,0,3) . "456" . substr($foo,6);
>
> You might mean:
> substr($foo,3,3)='456';
That is a much better way to do it! I wasn't using substr() as an
lvalue - I am now. Thanks!
Mark
------------------------------
Date: Thu, 10 Sep 1998 14:25:17 -0700
From: "Scott Harper" <sharper@cisco.com>
Subject: socket accept() vs. CGI.pm accept()
Message-Id: <6t9g03$11h$1@news-sj-3.cisco.com>
I am having a problem with a CGI program that also has to interface with
sockets. The problem is that CGI.pm has a routine called accept that seems
to be conflicting with the sockets routine by the same name. Has anybody
seen this? Am I doing something wrong? I know that I can just not import the
:cgi function set into my main namespace and avoid the problem, but that
means that I have to explicitly call out the package name for all the
functions in the :cgi function set, which is less than ideal. I was hoping
that someone had a more elegant solution.
You advice is much appreciated,
Scott Harper
------------------------------
Date: Thu, 10 Sep 1998 16:42:17 -0400
From: Jihad Battikha <jbattikha@highsynth.com>
To: CA Aspiras <saints@jps.net>
Subject: Re: ssi exec error...
Message-Id: <35F839A9.EC2E271A@highsynth.com>
[posted and mailed]
Hi,
Since I ran into this same issue, I can offer a tidbit of help.
You didn't mention which platform you're running on (OS, http server) so
I'll assume Unix/Apache. Depending on how Apache is configured, you
probably can't include argument parameters within an SSI exec in the
same way that you can via a URL-base query string. You may need to
format your EXEC like this:
<!--#exec cmd="/full/path/yourdir/cgi-bin/script.pl arg1 arg2 etc"-->
instead of:
<!--#exec cgi="/cgi-bin/script.pl?arg1+arg2+etc"-->
If that doesn't work or you don't know the full path of your home
directory, as the admin of your server for help.
If you're on an NT system, try:
<!--#exec cmd="c:\full\path\yourdir\cgi-bin\script.pl arg1 arg2 etc"-->
~jihad
--
<>>>===========================================================<<<>
Jihad Battikha <jbattikha@highsynth.com> http://www.highsynth.com
-=< graphics . 2d/3d animation . illustration . web authoring >=-
-----------------------------------------------------------------
PGP: http://www.highsynth.com/jihad/pgp.htm
- fingerprint: 9B5E 0484 0D88 6454 380B 964D E9B7 7A58 15C0 CAD7
- expires: 1/1/1999
<>>>===========================================================<<<>
Before sending me commercial e-mail, the sender must first agree
to my LEGAL NOTICE located at: http://www.highsynth.com/sig.html.
<>>>===========================================================<<<>
CA Aspiras wrote:
> was: <!--exec cgi="/cgi-bin/rand_line.pl"-->
> should be: <!--#exec cgi="/cgi-bin/rand_line.pl"-->
> was: <!--exec cgi="/cgi-bin/rand_line.pl?random1.dat"-->
> should be: <!--#exec cgi="/cgi-bin/rand_line.pl?random1.dat"-->
>
> [....]
> [an error occurred while processing this directive]
>
> the problem is my the code on how to get the value of the whole string
> after the ? when using ssi. it works when typed as URL, but not when
> used as ssi tag.
------------------------------
Date: Thu, 10 Sep 1998 15:06:22 -0700
From: Curt Cranfield <curt@vphos.net>
Subject: Time in milliseconds
Message-Id: <35F84D5E.EF7F3BDA@vphos.net>
Hi All,
Having a bit of a problem trying to figure out how I get a time in
milliseconds. Something like 'time' does not have fine enough
granularity. I have also checked out Devel::DProf but it is really not
what I am looking for.
I have checked out the perldocs and reviewed old posts but there doesn't
seem to be any mention of such fine time granularity. Something like
getitimer or setitimer would be ideal.
What I am trying to do is write a little piece of code that will connect
a socket to another machine and see how long it takes for the socket to
be established and a response to be attained. Or in its simplest form I
want to find out how long it takes to call a sub and for it to return
(but in the finest of granularity).
Does anyone have any suggestions or ideas on how I might accomplish
this?
------------------------------
Date: Thu, 10 Sep 1998 22:40:03 GMT
From: mfuhr@dimensional.com (Michael Fuhr)
Subject: Re: Time in milliseconds
Message-Id: <6t9kfp$njb@flatland.dimensional.com>
Curt Cranfield <curt@vphos.net> writes:
> Having a bit of a problem trying to figure out how I get a time in
> milliseconds. Something like 'time' does not have fine enough
> granularity. I have also checked out Devel::DProf but it is really not
> what I am looking for.
Time::HiRes should work if your OS has gettimeofday().
--
Michael Fuhr
http://www.fuhr.net/~mfuhr/
------------------------------
Date: 10 Sep 1998 20:33:20 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Tokenizer in Perl...
Message-Id: <6t9d2h$fb8$1@marina.cinenet.net>
Jian Zhang (jian@cisco.com) wrote:
: Hi,
:
: I am new to Perl and working on a simple parser. I'm looking for a way
: doing tokenization in Perl. For example, given a string:
:
: module my_module(33: 3){
:
: The perl program should parse the string into an array:
:
: @string_array = (" ",
: "module",
: " ",
: "my_module",
: "(",
: "33",
: ":",
: " ",
: "3",
: ")",
: "{");
:
: Please note that I also need all white-spaces preserved and accurately
: parsed.
This replicates your desired output, but may need to be tweaked to handle
cases your demo doesn't mention. The model I implemented is that a token
is one of:
* One or more consecutive word characters
* One or more consecutive whitespace characters
* Exactly one non-word, non-whitespace character
#!/usr/bin/perl -w
# tok - simple tokenizer, demo for clpm.
# Craig Berry (19980910)
use strict;
my $text = ' module my_module(33: 3){';
my @tokens = $text =~ /\w+|\s+|./g;
print join(' / ', @tokens), "\n";
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
Date: 10 Sep 1998 20:56:39 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Tokenizer in Perl...
Message-Id: <6t9ee7$cpf$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
Jian Zhang <jian@cisco.com> writes:
:I am new to Perl and working on a simple parser. I'm looking for a way
:doing tokenization in Perl.
Here's a sample:
sub parse_expr {
local $_ = shift;
my @tokens = ();
my $paren = 0;
my $want_term = 1;
while (length) {
s/^\s*//;
if (s/^\(//) {
return unless $want_term;
push @tokens, '(';
$paren++;
$want_term = 1;
next;
}
if (s/^\)//) {
return if $want_term;
push @tokens, ')';
if ($paren < 1) {
return;
}
--$paren;
$want_term = 0;
next;
}
if (s/^and\b//i || s/^&&?//) {
return if $want_term;
push @tokens, '&';
$want_term = 1;
next;
}
if (s/^or\b//i || s/^\|\|?//) {
return if $want_term;
push @tokens, '|';
$want_term = 1;
next;
}
if (s/^not\b//i || s/^~// || s/^!//) {
return unless $want_term;
push @tokens, '~';
$want_term = 1;
next;
}
if (s/^(\w+)//) {
push @tokens, '&' unless $want_term;
push @tokens, $1 . '()';
$want_term = 0;
next;
}
return;
}
return "@tokens";
}
--tom
--
Perl has grown from being a very good scripting language into something
like a cross between a universal solvent and an open-ended Mandarin
where new ideograms are invented hourly. --Jeffrey Davis
------------------------------
Date: Thu, 10 Sep 1998 14:43:14 -0700
From: Vincent Lowe <vincent@compclass.com>
Subject: Re: Tokenizer in Perl...
Message-Id: <35F847F2.D51E5068@compclass.com>
Mike Stok wrote:
>
> In article <35F814CE.78E233AD@cisco.com>, Jian Zhang <jian@cisco.com> wrote:
> >
> >I am new to Perl and working on a simple parser. I'm looking for a way
> >doing tokenization in Perl. For example, given a string:
> >
> DB<2> @string_array = $s =~ /(\w+|\s+|.)/g
>
...great answer! And the references both to CPAN and the use of the
debugger as a testing platform were particularly relevant "value-added"
extras. This is why clpm works! Thanks.
---v
--
| vincent@compclass.com | "Birds rising in flight is a sign
| | that the enemy is lying in ambush..."
| 248.557.2754 | Sun Tzu
+--------------------------+-----------------------------------------
| Aqueduct Information Services http://www.aquecorp.com/vincent
------------------------------
Date: Thu, 10 Sep 1998 21:23:35 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: Where to find CGI.PM for PerlW32 Build 316
Message-Id: <slrn6vgkhg.4h.alastair@calliope.demon.co.uk>
vdielman@debis.com <vdielman@debis.com> wrote:
>Hello Everyboby,
>
>I'm looking for the Module CGI.PM ready to use with Perl for Win32, build 316.
>Can anybody tell me where to find it or Send it per Mail?
I guess the CGI home page has pointers on that ;
http://stein.cshl.org/~lstein/
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 3686
**************************************
