[13913] in Perl-Users-Digest
No subject found in mail header
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 10 17:47:52 1999
Date: Mon, 8 Nov 1999 12:33:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <942093188-v9-i1309@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 8 Nov 1999 Volume: 9 Number: 1309
Today's topics:
Re: nmap like script? (Kragen Sitaker)
not(1) && 0 is true! (Michael Stillwell)
Re: not(1) && 0 is true! <jeffp@crusoe.net>
Re: not(1) && 0 is true! <uri@sysarch.com>
Re: not(1) && 0 is true! (Michael Stillwell)
Re: not(1) && 0 is true! <uri@sysarch.com>
Re: not(1) && 0 is true! (Ilya Zakharevich)
Re: not(1) && 0 is true! (Abigail)
Re: not(1) && 0 is true! <gellyfish@gellyfish.com>
Re: not(1) && 0 is true! <uri@sysarch.com>
Re: not(1) && 0 is true! (Ilya Zakharevich)
Re: not(1) && 0 is true! <uri@sysarch.com>
Re: not(1) && 0 is true! (Eric Bohlman)
odd time displaying <florcsk@my-deja.com>
Re: odd time displaying raju_k@iname.com
Re: odd time displaying <uri@sysarch.com>
Re: odd time displaying <lr@hpl.hp.com>
Re: odd time displaying (Craig Berry)
Re: odd time displaying (Martien Verbruggen)
Re: ole - activeperl <bokler_1@hiwaay.net>
Re: ole - activeperl (NotMe@NotMe.org)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 07 Nov 1999 02:37:24 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: nmap like script?
Message-Id: <EB5V3.50022$23.1898245@typ11.nn.bcandid.com>
In article <Pine.LNX.3.96.991104094434.17620D-100000@uboat.berghold.net>,
Peter L. Berghold <peter@berghold.net> wrote:
>Before I go ahead and re-invent the wheel.... is there anybody out there
>who has written or knows of a perl script that "safely" emulates nmap?
>I'd like to use one to collect data on my network at my firm...
There's the Net::Pcap module and a set of NetPacket:: modules that
might be helpful to you in doing this.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 6 Nov 1999 03:50:41 GMT
From: mjs@beebo.org (Michael Stillwell)
Subject: not(1) && 0 is true!
Message-Id: <slrn8279cg.ekt.mjs@fangorn.csse.monash.edu.au>
$ perl -e 'print "True\n" if not(1) && 0'
True
Recently I was bitten by this "feature". Although I eventually
figured out that it was doing not((1) && 0), and that this is what
it's supposed to do, I do find this behaviour extremely
counter-intuitive.
Is there any other situation (in boolean expressions) where "A(B)" and
"(A(B))" do not mean the same thing?
Michael
--
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
------------------------------
Date: Fri, 5 Nov 1999 23:25:22 -0500
From: Jeff Pinyan <jeffp@crusoe.net>
Subject: Re: not(1) && 0 is true!
Message-Id: <Pine.GSO.4.10.9911052323280.4538-100000@crusoe.crusoe.net>
[posted & mailed]
On Nov 6, Michael Stillwell blah blah blah:
> $ perl -e 'print "True\n" if not(1) && 0'
> True
You seem to think 'not' is a function. Wrong. It is an operator, similar
to !, but with lower precedence.
not 1 && 0;
is the same as
! (1 && 0);
Therefore,
not(1) && 0;
# is
not (1) && 0;
# is
not 1 && 0;
# is
not (1 && 0);
# is
not 0;
# is
1
--
MIDN 4/C PINYAN, USNR, NROTCURPI
jeff pinyan japhy@pobox.com
perl stuff japhy+perl@pobox.com
CPAN ID: PINYAN http://www.perl.com/CPAN/authors/id/P/PI/PINYAN/
------------------------------
Date: 05 Nov 1999 23:50:21 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: not(1) && 0 is true!
Message-Id: <x7d7to441e.fsf@home.sysarch.com>
>>>>> "MS" == Michael Stillwell <mjs@beebo.org> writes:
MS> $ perl -e 'print "True\n" if not(1) && 0'
MS> True
MS> Recently I was bitten by this "feature". Although I eventually
MS> figured out that it was doing not((1) && 0), and that this is what
MS> it's supposed to do, I do find this behaviour extremely
MS> counter-intuitive.
read perlop about the precedence of not, and, or. they are the lowest of
all ops so the result you get is correct. try it with !(1) instead.
MS> Is there any other situation (in boolean expressions) where "A(B)" and
MS> "(A(B))" do not mean the same thing?
it is not a boolean expression in the sense of the precedence is
different. perl is not boolean algebra, it is perl. learn perl.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 6 Nov 1999 07:42:16 GMT
From: mjs@beebo.org (Michael Stillwell)
Subject: Re: not(1) && 0 is true!
Message-Id: <slrn827mun.h8v.mjs@fangorn.csse.monash.edu.au>
Uri Guttman <uri@sysarch.com> wrote:
: >>>>> "MS" == Michael Stillwell <mjs@beebo.org> writes:
:
: MS> $ perl -e 'print "True\n" if not(1) && 0'
: MS> True
:
: MS> Recently I was bitten by this "feature". Although I eventually
: MS> figured out that it was doing not((1) && 0), and that this is what
: MS> it's supposed to do, I do find this behaviour extremely
: MS> counter-intuitive.
:
: read perlop about the precedence of not, and, or. they are the lowest of
: all ops so the result you get is correct. try it with !(1) instead.
To clarify a little: I think the behaviour is confusing and
unexpected, but not wrong. (I have read the documentation--I thought
this would have been clear from my original post!)
: MS> Is there any other situation (in boolean expressions) where "A(B)" and
: MS> "(A(B))" do not mean the same thing?
:
: it is not a boolean expression in the sense of the precedence is
: different. perl is not boolean algebra, it is perl. learn perl.
But surely it is helpful if Perl's system of boolean algebra is
consistent with other systems? Do you think a programmer who has no
knowledge of Perl (but who does know other languages) would expect
"not(1) && 0" to be true?
But anyway, I think the construct comes uncomfortably close to
violating Perl's own rules. For example, according to the perlop man
page, if any of the "named unary operators" are "followed by a left
parenthesis as the next token, the operator and arguments within
parentheses are taken to be of highest precedence, just like a normal
function call." So "not" is not one of these "named unary operators"?
How are you supposed to know that? Is there any other operator that
behaves like "not" does?
Michael
--
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
:::: mjs@beebo.org ::::::::::::::::::::::::::::: http://beebo.org ::::
------------------------------
Date: 06 Nov 1999 02:53:21 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: not(1) && 0 is true!
Message-Id: <x7vh7g2gzx.fsf@home.sysarch.com>
>>>>> "MS" == Michael Stillwell <mjs@beebo.org> writes:
MS> But anyway, I think the construct comes uncomfortably close to
MS> violating Perl's own rules. For example, according to the perlop man
MS> page, if any of the "named unary operators" are "followed by a left
MS> parenthesis as the next token, the operator and arguments within
MS> parentheses are taken to be of highest precedence, just like a normal
MS> function call." So "not" is not one of these "named unary operators"?
MS> How are you supposed to know that? Is there any other operator that
MS> behaves like "not" does?
'not' isn't a named unary operator. those are covered in perlfunc and the
firat paragraph defines what they are with regards to syntax.
'not' is an operator with very low precedence. it can't take parens
syntactically. the parens are just parens.
it isn't obvious since it has a text name but it is just like ! (but
lower precedence) which can't take parens either.
'not' (IIR) happens to be the only operator with a text name and is
unary.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 6 Nov 1999 10:19:04 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: not(1) && 0 is true!
Message-Id: <800vao$qib$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Uri Guttman
<uri@sysarch.com>],
who wrote in article <x7vh7g2gzx.fsf@home.sysarch.com>:
> 'not' (IIR) happens to be the only operator with a text name and is
> unary.
What about readline? What do you think makes some things operators,
others functions? Is 'not' overridable?
Unary operators without syntactic sugar should behave as functions.
'not' has a minimal syntactic sugar, precedence, and the rule "if it
looks like a function, it is a function" should be applied to 'not' as well.
Ilya
------------------------------
Date: 6 Nov 1999 07:14:36 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: not(1) && 0 is true!
Message-Id: <slrn828akq.dk.abigail@alexandra.delanet.com>
Uri Guttman (uri@sysarch.com) wrote on MMCCLVIII September MCMXCIII in
<URL:news:x7vh7g2gzx.fsf@home.sysarch.com>:
[] >>>>> "MS" == Michael Stillwell <mjs@beebo.org> writes:
[]
[] MS> But anyway, I think the construct comes uncomfortably close to
[] MS> violating Perl's own rules. For example, according to the perlop man
[] MS> page, if any of the "named unary operators" are "followed by a left
[] MS> parenthesis as the next token, the operator and arguments within
[] MS> parentheses are taken to be of highest precedence, just like a normal
[] MS> function call." So "not" is not one of these "named unary operators"?
[] MS> How are you supposed to know that? Is there any other operator that
[] MS> behaves like "not" does?
[]
[] 'not' isn't a named unary operator. those are covered in perlfunc and the
[] firat paragraph defines what they are with regards to syntax.
Don't you think it's strange named unary operators are discussed in
perl_func_?
[] 'not' is an operator with very low precedence. it can't take parens
[] syntactically. the parens are just parens.
[]
[] it isn't obvious since it has a text name but it is just like ! (but
[] lower precedence) which can't take parens either.
[]
[] 'not' (IIR) happens to be the only operator with a text name and is
[] unary.
I hate to think in terms of functions and operators. That suggest a
difference that isn't needed. Operators are just functions with funny
names, fixed number of arguments and they aren't always prefixed.
Unfortunally, Perl does make some difference, which lead to
not ($x) && $y;
being parsed different from
lc ($x) && $y;
And utter weirdness like a warning for:
print ($x);
But there's no difference between an operator and a function in
functionality.
I think that:
not ($x) && $y;
should behave the same as:
(not $x) && $y;
but if Perl can't be changed because of compatability reasons,
not (EXPR) &&
and
not (EXPR) ||
should give warnings.
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 6 Nov 1999 11:44:04 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: not(1) && 0 is true!
Message-Id: <8014a4$a4q$1@gellyfish.btinternet.com>
On 6 Nov 1999 07:42:16 GMT Michael Stillwell wrote:
> Uri Guttman <uri@sysarch.com> wrote:
> : >>>>> "MS" == Michael Stillwell <mjs@beebo.org> writes:
> :
> : MS> $ perl -e 'print "True\n" if not(1) && 0'
> : MS> True
> :
> : MS> Recently I was bitten by this "feature". Although I eventually
> : MS> figured out that it was doing not((1) && 0), and that this is what
> : MS> it's supposed to do, I do find this behaviour extremely
> : MS> counter-intuitive.
> :
> : read perlop about the precedence of not, and, or. they are the lowest of
> : all ops so the result you get is correct. try it with !(1) instead.
>
> To clarify a little: I think the behaviour is confusing and
> unexpected, but not wrong. (I have read the documentation--I thought
> this would have been clear from my original post!)
>
> : MS> Is there any other situation (in boolean expressions) where "A(B)" and
> : MS> "(A(B))" do not mean the same thing?
> :
> : it is not a boolean expression in the sense of the precedence is
> : different. perl is not boolean algebra, it is perl. learn perl.
>
> But surely it is helpful if Perl's system of boolean algebra is
> consistent with other systems? Do you think a programmer who has no
> knowledge of Perl (but who does know other languages) would expect
> "not(1) && 0" to be true?
>
But the 'not' isnt negating the '1' here it is negating the result of
the boolean operation - try for instance not(1) && 1 or whatever. The
parenthesis are irrelevant to the 'not' operator it still doesnt bind
to the next token because the precedence is so low .
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 06 Nov 1999 12:40:39 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: not(1) && 0 is true!
Message-Id: <x7ln8b34dk.fsf@home.sysarch.com>
>>>>> "A" == Abigail <abigail@delanet.com> writes:
A> Don't you think it's strange named unary operators are discussed in
A> perl_func_?
well i look at them more as functions that without () will take only one
arg. the whole blurring of funcs and ops does get annoying at times.
A> difference that isn't needed. Operators are just functions with funny
A> names, fixed number of arguments and they aren't always prefixed.
dyadic (and triadic) ops are very different than funcs and unary
ops. most ops take 2 (or 3) args and have many levels of precedence. all
funcs are the same precedence as are all unary ops (different for funcs
and unary ops). 'not' is in a totally different precedence level so it
doesn't get parse (non-overridden) like a unary op. effectively it can
never take parens (unless ilya says so :-).
A> Unfortunally, Perl does make some difference, which lead to
A> not ($x) && $y;
A> being parsed different from
A> lc ($x) && $y;
different precedence covers that. not ($x) is an low precedence op
followed by a term. lc ($x) is a higher precedence unary op with an
arg. it may be ugly but how would you get this to work:
not ($foo && $bar ) || ($aaa && $bbb)
not can't grab the first parens according to boolean algebra. its low
precedence works here.
you would have to write:
not ( ($foo && $bar ) || ($aaa && $bbb) )
if it were a normal unary op.
! ($foo && $bar ) || ($aaa && $bbb)
does what you would have 'not' do. it negates the first parens since it
binds higher than 'or'
if you converted all the ops to the named ones, then the logic would
work as you expect. the lesson here is either to not mix the named and
symbolic boolean ops (unless you know what you are doing). your example
of
A> not ($x) && $y;
mixes the logical families. change either op to the other style and your
logic is what you want.
A> but if Perl can't be changed because of compatability reasons,
A> not (EXPR) &&
A> and
A> not (EXPR) ||
A> should give warnings.
it is legal and makes sense if you think in terms of low precedence and
boolean algebra. there may be cases where you want to mix the logical
families (see below for a reason).
but most boolean algebra should use the symbolic ones which have more
apropriate precedence (they are the original ones) and won't be confused
with unary ops. no one would ever think:
! ($a || $b) && $c
isn't
(! ($a || $b) ) && $c
since ! binds tighter than &&
larry added the named boolean ops to handle cases like:
open FOO, $file || die "flaming death" ;
that were causing so many problems due to || binding $file to die.
they were not meant to replace the symbolic boolean ops for boolean
algebra with expected bindings. if 'not' were parsed like a unary op, it
would break its purpose of having extremely low binding.
you can't have it both ways. either 'not' is a much lower precedence
version of ! or it is just a named alias with no useful behavior.
so train yourself to use the symbolic boolean ops for close to real
boolean algebra. use the named boolean ops for pretty grouping of code
clauses without parens. that is really their only purpose. i could live
without them as i use parens on my opens with || and rarely need to
prettify my logical expressions. one useful place is in ladder compares
in sort subs.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 6 Nov 1999 20:49:01 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: not(1) && 0 is true!
Message-Id: <80247t$2dr$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Uri Guttman
<uri@sysarch.com>],
who wrote in article <x7ln8b34dk.fsf@home.sysarch.com>:
> different precedence covers that. not ($x) is an low precedence op
> followed by a term. lc ($x) is a higher precedence unary op with an
> arg.
I very much doubt this description. You are missing "if it looks like
a function call, it is a function call" rule (see C<print (1)>
clause). lc has a very low precedence "on the right" as well.
But somehow C<not> got through the cracks of this rule. This is most
probably a bug (so I CC perlbug).
> it may be ugly but how would you get this to work:
>
> not ($foo && $bar ) || ($aaa && $bbb)
>
> not can't grab the first parens according to boolean algebra.
Boolean algebra has no relationship to parens. You are trying to
pretend that Perl is parsed basing on precedences. It is not.
Ilya
------------------------------
Date: 06 Nov 1999 19:37:47 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: not(1) && 0 is true!
Message-Id: <x7yacb16hw.fsf@home.sysarch.com>
>>>>> "IZ" == Ilya Zakharevich <ilya@math.ohio-state.edu> writes:
IZ> [A complimentary Cc of this posting was sent to Uri Guttman
IZ> <uri@sysarch.com>],
IZ> who wrote in article <x7ln8b34dk.fsf@home.sysarch.com>:
>> different precedence covers that. not ($x) is an low precedence op
>> followed by a term. lc ($x) is a higher precedence unary op with an
>> arg.
IZ> I very much doubt this description. You are missing "if it looks like
IZ> a function call, it is a function call" rule (see C<print (1)>
IZ> clause). lc has a very low precedence "on the right" as well.
but 'not' isn't a unary op. it may look like one. it can't be one
because of its precedence which has to be low by its definition..
IZ> But somehow C<not> got through the cracks of this rule. This is most
IZ> probably a bug (so I CC perlbug).
no, it is not a bug.
>> it may be ugly but how would you get this to work:
>>
>> not ($foo && $bar ) || ($aaa && $bbb)
>>
>> not can't grab the first parens according to boolean algebra.
IZ> Boolean algebra has no relationship to parens. You are trying to
IZ> pretend that Perl is parsed basing on precedences. It is not.
this from a mathematician? you shock me ilya. why does * have higher
precedence than + and why does ! higher than && which is higher than
||? those precedences are expected and most languages (apl, lisp being
noted exceptions) use mathematical precedence in their parsing. look at
the precedence on page 76-77 of the camel. the bottom of the table shows
'not', then 'and' followed by 'xor' and 'or'. named unary ops are way up
in the table.
the 'not' problem only arises if you mix the symbolic and named boolean
ops. all the symbolic ones bind higher than the named ones.
not( $foo ) && bar is wrong!
not( $foo ) and bar is right!
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 7 Nov 1999 07:39:24 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: not(1) && 0 is true!
Message-Id: <803abc$4ag$6@nntp8.atl.mindspring.net>
Jonathan Stowe (gellyfish@gellyfish.com) wrote:
: But the 'not' isnt negating the '1' here it is negating the result of
: the boolean operation - try for instance not(1) && 1 or whatever. The
: parenthesis are irrelevant to the 'not' operator it still doesnt bind
: to the next token because the precedence is so low .
The problem here is caused by "psychological set" (in layman's terms,
the tendency to see what we expect to see). Perl's "not" operator is one
of the very few unary operators anyone will ever encounter that does
*not* (hehe) bind tightly to the immediately following token. Thus, it
behaves contrary to a well-established mental model (in the vernacular,
it's "counterintuitive"), and people frequently make errors when using
constructs that behave that way.
Of course, if you need a low-precedence negation operator, there's no way
to implement it without violating people's mental models and people will
just have to put up with it. Another aspect of psychological set is that
if someone tries to use "and" in place of && and "or" in place of ||
merely for "readability," more often then not those operators will still
work the way he wants them to. But if someone substitutes "not" for !,
more often than not the precedence will be wrong.
------------------------------
Date: Fri, 05 Nov 1999 19:17:52 GMT
From: Scott Florcsk <florcsk@my-deja.com>
Subject: odd time displaying
Message-Id: <7vvags$42i$1@nnrp1.deja.com>
Time translations are giving me odd results. I have the following code:
#!/usr/local/bin/perl
@months =
('Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sept','Oct','Nov','Dec
');
@days =
('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday')
;
$start_time = 941754291;
$end_time = 941754303;
$difference = $end_time - $start_time;
($dsec, $dmin, $dhour, $dmday, $dmon, $dyear, $dwday, $dyday, $disdst)
= localtime($start_time);
$dyear += 1900;
($usec, $umin, $uhour, $umday, $umon, $uyear, $uwday, $uyday, $uisdst)
= localtime($end_time);
$uyear += 1900;
print "Start time = $days[$dwday], $months[$dmon] $dmday $dyear,
$dhour:$dmon:$dsec (epoch = $start_time)\n";
print "End time = $days[$uwday], $months[$umon] $umday $uyear,
$uhour:$umon:$usec (epoch = $end_time)\n";
print "Difference = $difference seconds\n";
--- End of code ---
Notice that the ending time ($end_time) is 12 seconds after the
starting time. When I run the program, this is my output:
Start time = Thursday, Nov 4 1999, 15:10:51 (epoch = 941754291)
End time = Thursday, Nov 4 1999, 15:10:3 (epoch = 941754303)
Difference = 12 seconds
--- End of Output ---
I'm sure the $start_time is getting displayed right, but why is the
ending time 15:10:3 ??? If it were 15:11:3 it would add up, but the
calculation (12 seconds difference reported) is correct, so I'm stumped
on the display. Am I incorrectly using the localtime() function?
perldoc -f localtime mentions nothing of note that I can relate to
this. I know there are a couple of time and date modules, but didn't
think I needed them for such a small routine.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 05 Nov 1999 19:30:46 GMT
From: raju_k@iname.com
Subject: Re: odd time displaying
Message-Id: <7vvb92$4jb$1@nnrp1.deja.com>
You are printing out $umon and $dmon instead of $umin and $dmin
--raju
In article <7vvags$42i$1@nnrp1.deja.com>,
Scott Florcsk <florcsk@my-deja.com> wrote:
> Time translations are giving me odd results. I have the following
code:
>
> #!/usr/local/bin/perl
>
> @months =
>
('Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sept','Oct','Nov','Dec
> ');
> @days =
>
('Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday')
> ;
>
> $start_time = 941754291;
> $end_time = 941754303;
> $difference = $end_time - $start_time;
>
> ($dsec, $dmin, $dhour, $dmday, $dmon, $dyear, $dwday, $dyday, $disdst)
> = localtime($start_time);
> $dyear += 1900;
>
> ($usec, $umin, $uhour, $umday, $umon, $uyear, $uwday, $uyday, $uisdst)
> = localtime($end_time);
> $uyear += 1900;
>
> print "Start time = $days[$dwday], $months[$dmon] $dmday $dyear,
> $dhour:$dmon:$dsec (epoch = $start_time)\n";
> print "End time = $days[$uwday], $months[$umon] $umday $uyear,
> $uhour:$umon:$usec (epoch = $end_time)\n";
> print "Difference = $difference seconds\n";
>
> --- End of code ---
>
> Notice that the ending time ($end_time) is 12 seconds after the
> starting time. When I run the program, this is my output:
>
> Start time = Thursday, Nov 4 1999, 15:10:51 (epoch = 941754291)
> End time = Thursday, Nov 4 1999, 15:10:3 (epoch = 941754303)
> Difference = 12 seconds
>
> --- End of Output ---
>
> I'm sure the $start_time is getting displayed right, but why is the
> ending time 15:10:3 ??? If it were 15:11:3 it would add up, but the
> calculation (12 seconds difference reported) is correct, so I'm
stumped
> on the display. Am I incorrectly using the localtime() function?
> perldoc -f localtime mentions nothing of note that I can relate to
> this. I know there are a couple of time and date modules, but didn't
> think I needed them for such a small routine.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 05 Nov 1999 14:42:40 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: odd time displaying
Message-Id: <x7so2k4te7.fsf@home.sysarch.com>
>>>>> "SF" == Scott Florcsk <florcsk@my-deja.com> writes:
SF> ($dsec, $dmin, $dhour, $dmday, $dmon, $dyear, $dwday, $dyday, $disdst)
^^^^^
SF> ($usec, $umin, $uhour, $umday, $umon, $uyear, $uwday, $uyday, $uisdst)
^^^^^
SF> print "Start time = $days[$dwday], $months[$dmon] $dmday $dyear,
SF> $dhour:$dmon:$dsec (epoch = $start_time)\n";
^^^^^
SF> print "End time = $days[$uwday], $months[$umon] $umday $uyear,
SF> $uhour:$umon:$usec (epoch = $end_time)\n";
^^^^^
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Fri, 5 Nov 1999 11:56:13 -0800
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: odd time displaying
Message-Id: <MPG.128cd63781f7e71f98a1c1@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <7vvags$42i$1@nnrp1.deja.com> on Fri, 05 Nov 1999 19:17:52
GMT, Scott Florcsk <florcsk@my-deja.com> says...
...
> ($dsec, $dmin, $dhour, $dmday, $dmon, $dyear, $dwday, $dyday, $disdst)
> = localtime($start_time);
> $dyear += 1900;
>
> ($usec, $umin, $uhour, $umday, $umon, $uyear, $uwday, $uyday, $uisdst)
> = localtime($end_time);
> $uyear += 1900;
>
> print "Start time = $days[$dwday], $months[$dmon] $dmday $dyear,
> $dhour:$dmon:$dsec (epoch = $start_time)\n";
> print "End time = $days[$uwday], $months[$umon] $umday $uyear,
> $uhour:$umon:$usec (epoch = $end_time)\n";
> print "Difference = $difference seconds\n";
Maybe if you used $dmin and $umin in your printout for minutes instead
of using $dmon and $umon, you would get the results you want.
<SNIP> Lod sound of palm slapping forehead and muttered sound of "I'll
name my variables more clearly next time!"
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sat, 06 Nov 1999 01:04:34 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: odd time displaying
Message-Id: <s26vl22rhpc64@corp.supernews.com>
Scott Florcsk (florcsk@my-deja.com) wrote:
: Time translations are giving me odd results. I have the following code:
[snip]
You're going to kick yourself. :) You're using $umon where you mean
$umin.
: print "Start time = $days[$dwday], $months[$dmon] $dmday $dyear,
: $dhour:$dmon:$dsec (epoch = $start_time)\n";
^ should be 'i'
: Start time = Thursday, Nov 4 1999, 15:10:51 (epoch = 941754291)
^^ November a la localtime
--
| Craig Berry - cberry@cinenet.net
--*-- http://www.cinenet.net/users/cberry/home.html
| "They do not preach that their God will rouse them
a little before the nuts work loose." - Kipling
------------------------------
Date: 6 Nov 1999 03:17:26 GMT
From: mgjv@wobbie.heliotrope.home (Martien Verbruggen)
Subject: Re: odd time displaying
Message-Id: <slrn8277gc.5vv.mgjv@wobbie.heliotrope.home>
On Fri, 05 Nov 1999 19:17:52 GMT,
Scott Florcsk <florcsk@my-deja.com> wrote:
> Time translations are giving me odd results. I have the following code:
>
> #!/usr/local/bin/perl
Everybody seems to point out what the problem is, but nobody seems to
tell you that -w would have warned you about this:
Name "main::dmin" used only once: possible typo at - line 12.
^^^^
Name "main::disdst" used only once: possible typo at - line 12.
Name "main::dyday" used only once: possible typo at - line 12.
Name "main::uyday" used only once: possible typo at - line 16.
Name "main::umin" used only once: possible typo at - line 16.
^^^^
Name "main::uisdst" used only once: possible typo at - line 16.
Of course, if you hadn't mistyped the variable names, -w would have
still warned about others, but that's beside the point :). -w would at
least have warned you that you were using variables only once. Normally
that's a sign that you should use them at all.
It is always a good idea to make sure your code runs under -w without
warnings. If you're not going to use the last two elements of the list
that comes back from localtime, just don't capture them.
It is also a good idea to use the strict pragma.
Martien
--
Martien Verbruggen |
Interactive Media Division | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: Sat, 06 Nov 1999 18:45:18 -0600
From: James Moore <bokler_1@hiwaay.net>
Subject: Re: ole - activeperl
Message-Id: <2MokOGZpDiXlacS=B0MLJzH6y6ac@4ax.com>
On Thu, 04 Nov 1999 17:06:18 GMT, rclauer@my-deja.com wrote:
>Anyone know how to call the Kodak imaging OCX
>object from Activeperl?
>
>Thanks,
>
>Rob Lauer
>rlauer@cji.com
I'd start by looking at the Win32::OLE module - it's part of the
libwin32 package available from ActiveState. Last I checked they had
limited support for OCXs; maybe it's better now.
James Moore
------------------------------
Date: Sun, 07 Nov 1999 15:43:32 GMT
From: NotMe@NotMe.org (NotMe@NotMe.org)
Subject: Re: ole - activeperl
Message-Id: <38259d3a.11285920@news.supernews.com>
If you have Active State installed to its default location these links
should take you to your answer(s)...
C:\Perl\html\lib\site\Win32\OLE.html
C:\Perl\html\lib\site\Win32\OLE\Browser.html <-- Pretty darn neat!!
-Tony
On Thu, 04 Nov 1999 17:06:18 GMT, rclauer@my-deja.com wrote:
>Anyone know how to call the Kodak imaging OCX
>object from Activeperl?
>
>Thanks,
>
>Rob Lauer
>rlauer@cji.com
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1309
**************************************
