[30931] in Perl-Users-Digest
Perl-Users Digest, Issue: 2176 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 1 14:09:47 2009
Date: Sun, 1 Feb 2009 11:09:11 -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, 1 Feb 2009 Volume: 11 Number: 2176
Today's topics:
Re: cgi style % decode and utf-8: missing something <hjp-usenet2@hjp.at>
new CPAN modules on Sun Feb 1 2009 (Randal Schwartz)
Re: Perl Peeves <bruce-usenet@noreplybicycle.synonet.comnoreply>
Re: Perl Peeves <hjp-usenet2@hjp.at>
Re: Perl Peeves <bruce-usenet@noreplybicycle.synonet.comnoreply>
Re: Perl Peeves <uri@stemsystems.com>
Re: Perl Peeves <hjp-usenet2@hjp.at>
Re: perl qt with cygwin? <xemoth@gmail.com>
Re: perl qt with cygwin? <zentara@highstream.net>
Regex problem from book, please help with solution <noone@none.net>
Re: Regex problem from book, please help with solution <tim@burlyhost.com>
Re: Regex problem from book, please help with solution (Vicky Conlan)
Re: Regex problem from book, please help with solution sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Jan 2009 22:25:03 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: cgi style % decode and utf-8: missing something
Message-Id: <slrngo9gdf.14u.hjp-usenet2@hrunkner.hjp.at>
On 2009-01-31 13:40, Eric Pozharski <whynot@pozharski.name> wrote:
> On 2009-01-31, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> *SKIP*
>> decode_utf8 (which you mentioned in a later posting) is of course just a
>> (possibly optimized) shorthand for decode('UTF-8', ...).
>
> Yes, no, it depends. It does some black magic, IOW (F<Encode.pm>, line
> 194).
>
> sub decode_utf8($;$) {
> my ( $str, $check ) = @_;
> return $str if is_utf8($str);
This checks if the argument is already a character string and returns it
unmodified in this case. This is undocumented and arguably dangerous.
> if ($check) {
> return decode( "utf8", $str, $check );
A simple wrapper.
> }
> else {
> return decode( "utf8", $str );
Again a simple wrapper, although I don't see why $check is omitted in
this case - decode doesn't check the number of arguments, so
return decode ("utf8", $str, $check);
would have exactly the same effect.
> return $str;
This is line is never reached. I assume that decode_utf8 used to call
utf8::decode (which converts in-place). Since utf8::decode doesn't have
a $check argument, that would also explain the if.
> }
> }
So, in summary, this function can be simplified to:
sub decode_utf8($;$) {
my ( $str, $check ) = @_;
return $str if is_utf8($str);
return decode( "utf8", $str, $check );
}
And if we lose the is_utf8 check (which is IMHO a bug), it becomes:
sub decode_utf8($;$) {
my ( $str, $check ) = @_;
return decode( "utf8", $str, $check );
}
A wrapper can't get much simpler.
However, I was wrong in another, subtle area: It decodes 'utf8', not
'UTF-8'. There are subtle differences on ASCII-based machines and I
think (but I'm not sure - the docs aren't entirely clear, and I can't
test it) is a totally different encoding on EBCDIC-based machines (there
'utf8' is really 'UTF-EBCDIC')
hp
------------------------------
Date: Sun, 1 Feb 2009 05:42:29 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sun Feb 1 2009
Message-Id: <KEDH6t.19vr@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Apache2-ASP-2.20
http://search.cpan.org/~johnd/Apache2-ASP-2.20/
ASP for Perl, reloaded.
----
Apache2-ASP-2.21
http://search.cpan.org/~johnd/Apache2-ASP-2.21/
ASP for Perl, reloaded.
----
App-CPAN2Pkg-0.3.0
http://search.cpan.org/~jquelin/App-CPAN2Pkg-0.3.0/
generating native linux packages from cpan
----
App-Sequence-0.0203
http://search.cpan.org/~kimoto/App-Sequence-0.0203/
pluggable subroutine engine.
----
App-Sequence-0.0205
http://search.cpan.org/~kimoto/App-Sequence-0.0205/
pluggable subroutine engine.
----
CGI-ExceptionManager-0.05
http://search.cpan.org/~tokuhirom/CGI-ExceptionManager-0.05/
DebugScreen with detach!
----
DB_File-1.818
http://search.cpan.org/~pmqs/DB_File-1.818/
Perl5 access to Berkeley DB version 1.x
----
Date-Extract-P800Picture-0.04
http://search.cpan.org/~ipenburg/Date-Extract-P800Picture-0.04/
class for extracting the date and the hour from the filename of pictures taken with a Sony-Ericsson P800 camera phone.
----
Deep-Hash-Utils-0.01
http://search.cpan.org/~clbecker/Deep-Hash-Utils-0.01/
----
Devel-TraceDeps-v0.0.3
http://search.cpan.org/~ewilhelm/Devel-TraceDeps-v0.0.3/
track loaded modules and objects
----
EV-Glib-2.01
http://search.cpan.org/~mlehmann/EV-Glib-2.01/
Embed the glib main loop into EV
----
File-Fu-v0.0.6
http://search.cpan.org/~ewilhelm/File-Fu-v0.0.6/
file and directory objects
----
Finance-Quote-Sberbank-0.03
http://search.cpan.org/~kilork/Finance-Quote-Sberbank-0.03/
Obtain quotes from Sberbank (Savings Bank of the Russian Federation)
----
Geo-Coder-Yahoo-0.44
http://search.cpan.org/~abh/Geo-Coder-Yahoo-0.44/
Geocode addresses with the Yahoo! API
----
Getopt-AsDocumented-v0.0.1
http://search.cpan.org/~ewilhelm/Getopt-AsDocumented-v0.0.1/
declare options as pod documentation
----
Getopt-Base-v0.0.1
http://search.cpan.org/~ewilhelm/Getopt-Base-v0.0.1/
foundation for oo GetOpt support
----
Glib-EV-2.01
http://search.cpan.org/~mlehmann/Glib-EV-2.01/
Coerce Glib into using the EV module as event loop.
----
HTML-Tested-JavaScript-0.14
http://search.cpan.org/~bosu/HTML-Tested-JavaScript-0.14/
JavaScript enabled HTML::Tested widgets.
----
IO-Event-0.603
http://search.cpan.org/~muir/IO-Event-0.603/
Tied Filehandles for Nonblocking IO with Object Callbacks
----
IO-Lambda-1.08
http://search.cpan.org/~karasik/IO-Lambda-1.08/
non-blocking I/O as lambda calculus
----
IO-Moose-0.08
http://search.cpan.org/~dexter/IO-Moose-0.08/
Reimplementation of IO::* with improvements
----
Math-MPFR-2.03
http://search.cpan.org/~sisyphus/Math-MPFR-2.03/
perl interface to the MPFR (floating point) library.
----
Math-NumberBase-0.01
http://search.cpan.org/~yehezkiel/Math-NumberBase-0.01/
Number converter from one base to another base
----
MooseX-GlobRef-Object-0.05
http://search.cpan.org/~dexter/MooseX-GlobRef-Object-0.05/
Store a Moose object in glob reference
----
MooseX-Role-Parameterized-0.04
http://search.cpan.org/~sartak/MooseX-Role-Parameterized-0.04/
parameterized roles
----
Net-DRI-0.92_01
http://search.cpan.org/~pmevzek/Net-DRI-0.92_01/
Interface to Domain Name Registries/Registrars/Resellers
----
NetHack-Monster-Spoiler-0.01
http://search.cpan.org/~sorear/NetHack-Monster-Spoiler-0.01/
information on a type of monster
----
POE-Component-SmokeBox-0.08
http://search.cpan.org/~bingos/POE-Component-SmokeBox-0.08/
POE enabled CPAN smoke testing with added value.
----
POE-Wheel-Run-Win32-0.10
http://search.cpan.org/~bingos/POE-Wheel-Run-Win32-0.10/
event driven fork/exec with added value
----
Parse-Method-Signatures-1.001000
http://search.cpan.org/~ash/Parse-Method-Signatures-1.001000/
Perl6 like method signature parser
----
Pod-Elemental-0.003
http://search.cpan.org/~rjbs/Pod-Elemental-0.003/
work with nestable POD elements
----
Pretty-0.3
http://search.cpan.org/~leiguang/Pretty-0.3/
modules to print something pretty.
----
Socket-GetAddrInfo-0.11
http://search.cpan.org/~pevans/Socket-GetAddrInfo-0.11/
RFC 2553's getaddrinfo and getnameinfo functions.
----
String-Urandom-0.01
http://search.cpan.org/~mbrooks/String-Urandom-0.01/
----
String-Urandom-0.02
http://search.cpan.org/~mbrooks/String-Urandom-0.02/
----
String-Urandom-0.03
http://search.cpan.org/~mbrooks/String-Urandom-0.03/
Generate a truely random string
----
Sys-Mmap-Simple-0.10
http://search.cpan.org/~leont/Sys-Mmap-Simple-0.10/
Memory mapping made simple and safe.
----
Sys-SigAction-0.11
http://search.cpan.org/~lbaxter/Sys-SigAction-0.11/
Perl extension for Consistent Signal Handling
----
Test-Strict-0.13
http://search.cpan.org/~pdenis/Test-Strict-0.13/
Check syntax, presence of use strict; and test coverage
----
Tree-Base-v0.10.1
http://search.cpan.org/~ewilhelm/Tree-Base-v0.10.1/
a base class for trees
----
Unix-Uptime-0.30_02
http://search.cpan.org/~pioto/Unix-Uptime-0.30_02/
Determine the current uptime, in seconds, across different *NIX architectures
----
VCfs-v0.0.1
http://search.cpan.org/~ewilhelm/VCfs-v0.0.1/
Version Control agnostic interface on the local system
----
WWW-Contact-0.20
http://search.cpan.org/~fayland/WWW-Contact-0.20/
Get contacts/addressbook from Web
----
WWW-Wikipedia-TemplateFiller-0.10
http://search.cpan.org/~diberri/WWW-Wikipedia-TemplateFiller-0.10/
Fill Wikipedia templates with your eyes closed
----
Wiki-Toolkit-Formatter-UseMod-0.23
http://search.cpan.org/~dom/Wiki-Toolkit-Formatter-UseMod-0.23/
UseModWiki-style formatting for Wiki::Toolkit
----
Wiki-Toolkit-Plugin-Categoriser-0.06
http://search.cpan.org/~dom/Wiki-Toolkit-Plugin-Categoriser-0.06/
Category management for Wiki::Toolkit.
----
Wiki-Toolkit-Plugin-Ping-0.02
http://search.cpan.org/~dom/Wiki-Toolkit-Plugin-Ping-0.02/
"ping" various services when nodes are written
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Sun, 01 Feb 2009 08:54:36 GMT
From: Bruce Cook <bruce-usenet@noreplybicycle.synonet.comnoreply>
Subject: Re: Perl Peeves
Message-Id: <49856349$1@news.mel.dft.com.au>
Peter J. Holzer wrote:
> On 2009-01-29 22:54, Bruce Cook
> <bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:
>> Peter J. Holzer wrote:
>>> On 2009-01-27 09:08, Eric Pozharski <whynot@pozharski.name> wrote:
>>>> On 2009-01-27, Tim McDaniel <tmcd@panix.com> wrote:
>>>>> (5) That "special false". I was going nuts trying to figure out what
>>>>> was different between
>>>
>>> [ '' in string context, 0 in numeric context ]
>>>
>>>> That special false is evaluated to blah-blah-blah *immediately* since
>>>> the context is known at compile time (am I right?).
>>>
>>> No. Consider:
>>>
>>> #!/usr/bin/perl
>>> use warnings;
>>> use strict;
>>>
>>> my $bool = (1 < 0);
>>>
>>> if (rand() < 0.5) {
>>> print "<$bool>\n";
>>> } else {
>>> print 0 + $bool, "\n";
>>> }
>>
>> Anyone who applies a numeric operator to a logical value and expects
>> consistent results is asking for trouble.
>
> The program above does produce consistent results and is perfectly
> well-defined in Perl. I am not asking for trouble, but demonstrating a
> perfectly well-defined (though somewhat surprising) property of the
> scalar value returned by (1 < 0). (Interestingly, if I change (1 < 0) to
> (0 < 1), then I am asking for trouble).
>
>> In strongly-typed languages you would get a compiler or run-time
>> error/warning, however perl is a scripting language and is built to be
>> flexible, assumes you know what you're doing and will silently oblige
>> even the most horrendous abuses.
>>
>> You actually have the same issue in C: false is defined as 0 and true is
>> !false.
>
> However, in C, !0 is defined as 1.
This is where lots of people make mistakes in C.
if(a) is not the same as
if(a == !0)
Original C compilers had an easy way of doing conditionals; they would
assign a variable to a register and then branch on the Z flag. This worked
because !0 is any value with any bit set.
>
> There is no "boolean" type in C (well, C99 has _bool, but ...) and all
> the "logical" operators in C return a well-defined result (1 or 0) of
> type int.
Yes, there are no bools, but conditionals in C work on zero and non-zero
integers.
>
>> I have seen a discussion recently where someone was using an
>> library "elegantly" and came unstuck on a different platform because he
>> assumed that the true returned from that library was 1 (as it was on his
>> development platform). His usage became really interesting because the
>> new platform was returning -1 (binary all 1s), which is another common
>> value used for true.
>
> This is however a problem with his use of this particular library, not a
> problem with his use of C.
>
> x = (1 > 0) + 5;
>
> is perfectly well-defined in C and will always assign 6 to x.
>
> If a function is defined as "returning a true value on success" of
> course you cannot test this with if (function() == 1), you need to use
> if (function()).
This example would work, however in some C compilers I have used
x=(2>0)+5 would always return 7. This is because the compiler worked with
not 0 being true, and the cheapest comparison on a particular platform is
sub.
This doesn't break comparison operators, but does give an unexpected result
when used as an integer result.
>
>
>> As a programmer you need to understand when you're crossing type
>> boundaries
>
> And you also need to know when you are *not* crossing type boundaries.
> In C (1 > 0) + 5 doesn't cross a type boundary. Both (1 > 0) and 5 are
> expressions of type int.
>
>
>> and make sure at that point you force defined behavior the || 0
>> construct is a good clean way of making sure your falses are actually
>> integer/cleanly printable.
>
> "actually integer" and "cleanly printable" have nothing to do with each
> other. '', 'green', 'false' are all cleanly printable, but none of them
> is an integer. The "special false" value is an integer (the integer
> zero) and it is also printable (it prints as ''), but depending on your
> expectations it may not be "cleanly printable" (a "normal" integer of
> value 0 prints as '0', not '').
Sorry, you're mistaking C semantics for Perl. Perl does not treat scalars
as integers and so it's conditionals are more complex (and yes hacky) than
C. Especially the one you don't like, which is defining the behavior of a
string being used in a condition.
>
>
>> Perl implicitly acknowledges data type differences in the fact that it
>> uses different binary operators for strings vs integers.
[...]
>
> Perl has a very precise definition what will be recogized as true and
> false. It also has a definition what value (the "special false") will be
> returned by the "logical" operators when they return false. For some
> reason it doesn't define what these operators return for the true value.
> I am very sure that this omission has nothing to do with the
> number/string ambivalence of scalars. I tend to think that the omission
> is a simple oversight, but it might be loosely defined as "any true
> value" on purpose.
Perl defines false and any other value is true. This is not an omission.
In this way it does behave exactly the same way C does.
[...]
Bruce
------------------------------
Date: Sun, 1 Feb 2009 13:40:29 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl Peeves
Message-Id: <slrngob61u.e26.hjp-usenet2@hrunkner.hjp.at>
On 2009-02-01 08:54, Bruce Cook <bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:
> Peter J. Holzer wrote:
>
>> On 2009-01-29 22:54, Bruce Cook
>> <bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:
>>> Peter J. Holzer wrote:
>>>> On 2009-01-27 09:08, Eric Pozharski <whynot@pozharski.name> wrote:
>>>>> On 2009-01-27, Tim McDaniel <tmcd@panix.com> wrote:
>>>>>> (5) That "special false". I was going nuts trying to figure out what
>>>>>> was different between
>>>>
>>>> [ '' in string context, 0 in numeric context ]
[...]
>>> Anyone who applies a numeric operator to a logical value and expects
>>> consistent results is asking for trouble.
[...]
>>> In strongly-typed languages you would get a compiler or run-time
>>> error/warning, however perl is a scripting language and is built to be
>>> flexible, assumes you know what you're doing and will silently oblige
>>> even the most horrendous abuses.
>>>
>>> You actually have the same issue in C: false is defined as 0 and true is
>>> !false.
>>
>> However, in C, !0 is defined as 1.
>
> This is where lots of people make mistakes in C.
You seem to be one of them.
> if(a) is not the same as
> if(a == !0)
I didn't say that. I said !0 is the same thing as 1 which means, that
if (a == !0)
is exactly the same as
if (a == 1)
While
if (a)
is the same thing as
if (a != 0)
Obviously (a != 0) and (a == 1) are not the same thing.
> Original C compilers had an easy way of doing conditionals; they would
> assign a variable to a register and then branch on the Z flag.
This may have been true on the PDP-11, although I doubt it. It certainly
wasn't a common feature of CPUs at the time. Most only set the flags as
the result of some computation, not a simple MOV. (There is a special
TST instruction to set the status flags depending on the contents of a
register)
> This worked because !0 is any value with any bit set.
No. !0 is not any non-zero value. !0 is exactly 1. Any non-zero value is
treated as "true".
>> There is no "boolean" type in C (well, C99 has _bool, but ...) and all
>> the "logical" operators in C return a well-defined result (1 or 0) of
>> type int.
>
> Yes, there are no bools, but conditionals in C work on zero and non-zero
> integers.
Your "but" sounds like there is a contradiction. There isn't. C doesn't
have a boolean type and you can use any scalar type (not just
integers) where a true/false decision is needed (I think this is what
you mean by "conditional" - correct me if I'm wrong). The result of the
relational, equality and logical operators is defined as having type
int, thus there is no "crossing a type boundary" when you use them in an
arithmetic expression. Such a type boundary may exist in the mind of a
Pascal programmer, but it doesn't exist in C.
>>
>> x = (1 > 0) + 5;
>>
>> is perfectly well-defined in C and will always assign 6 to x.
>>
>> If a function is defined as "returning a true value on success" of
>> course you cannot test this with if (function() == 1), you need to use
>> if (function()).
>
> This example would work, however in some C compilers I have used
> x=(2>0)+5 would always return 7.
Then they were not C compilers.
Each of the operators < (less than), > (greater than), <= (less than
or equal to), and >= (greater than or equal to) shall yield 1 if the
specified relation is true and 0 if it is false.89) The result has
type int.
(ISO-9899:1999. A similar definition is in Appendix A, section
7.6 of K&R I, German translation (I don't have the original)
> This is because the compiler worked with not 0 being true, and the
> cheapest comparison on a particular platform is sub.
So the result of
(-2 > 0)
would be -2 (i.e., true)? I think you should think about this a bit
more.
> This doesn't break comparison operators,
If (-2 > 0) is true that's pretty broken by any measure. If a compiler
produces a different result than the C specification says it should, it
is still broken.
>>> and make sure at that point you force defined behavior the || 0
>>> construct is a good clean way of making sure your falses are actually
>>> integer/cleanly printable.
>>
>> "actually integer" and "cleanly printable" have nothing to do with each
>> other. '', 'green', 'false' are all cleanly printable, but none of them
>> is an integer. The "special false" value is an integer (the integer
>> zero) and it is also printable (it prints as ''), but depending on your
>> expectations it may not be "cleanly printable" (a "normal" integer of
>> value 0 prints as '0', not '').
>
> Sorry, you're mistaking C semantics for Perl.
No, I'm not. I don't see where you see any C semantics in the paragraph
above. C simply doesn't have scalars which may be an integer and a
string at the same time. This is quite Perl-specific.
> Perl does not treat scalars as integers and so it's conditionals are
> more complex (and yes hacky) than C. Especially the one you don't
> like, which is defining the behavior of a string being used in a
> condition.
Who said I don't like it? I never said such a thing. I don't even think
it is very complex. The number 0, the strings '' and '0' and the undef
value are false, all other scalars are true.
>> Perl has a very precise definition what will be recogized as true and
>> false. It also has a definition what value (the "special false") will be
>> returned by the "logical" operators when they return false. For some
>> reason it doesn't define what these operators return for the true value.
>> I am very sure that this omission has nothing to do with the
>> number/string ambivalence of scalars. I tend to think that the omission
>> is a simple oversight, but it might be loosely defined as "any true
>> value" on purpose.
>
> Perl defines false and any other value is true.
You don't seem to understand the difference between
1) what is recognised as true in a conditional expression and
2) what a comparison or logical operator returns as a true value
These are not the same thing.
> This is not an omission. In this way it does behave exactly the same
> way C does.
No it is not.
C does define that the result of the expression (0 < 1) is 1. If your
compiler produces a different result, it is broken.
Perl only defines that the result of the expression (0 < 1) must be
true. It could be 1, -1, 'true', 42, a reference to a hash, whatever.
However, every version of perl (note: lower case 'p') since at least
perl4 (probably perl1) has always returned 1 as the true value for the
comparison operators (==, !=. <. >. <=, >=, eq, ne, lt, gt, le, ge) and
the logical negation (!, not). It is not clear to me whether this is
undocumented because @Larry want to keep the option of changing it one
day (in this case, why is the false value documented? The ''/0 mixture
is rather bizarre and it seems much more likely that one would like to
change that in some future revision of the language), or whether it is
simply undocumented because it's the same as in C and "people know that
anyway, so we don't have to write it down". (Perl documentation has
become more self-sufficient over the years, but originally it assumed a
lot of general Unix knowledge and there are still spots which are only
comprehensible if you have a background as a Unix/C programmer - this
might be one of them)
hp
------------------------------
Date: Sun, 01 Feb 2009 16:24:08 GMT
From: Bruce Cook <bruce-usenet@noreplybicycle.synonet.comnoreply>
Subject: Re: Perl Peeves
Message-Id: <4985cca8@news.mel.dft.com.au>
Peter J. Holzer wrote:
> On 2009-02-01 08:54, Bruce Cook
> <bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:
>> Peter J. Holzer wrote:
>>
>>> On 2009-01-29 22:54, Bruce Cook
>>> <bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:
>>>> Peter J. Holzer wrote:
>>>>> On 2009-01-27 09:08, Eric Pozharski <whynot@pozharski.name> wrote:
>>>>>> On 2009-01-27, Tim McDaniel <tmcd@panix.com> wrote:
>>>>>>> (5) That "special false". I was going nuts trying to figure out
>>>>>>> what was different between
>>>>>
>>>>> [ '' in string context, 0 in numeric context ]
> [...]
>>>> Anyone who applies a numeric operator to a logical value and expects
>>>> consistent results is asking for trouble.
> [...]
>>>> In strongly-typed languages you would get a compiler or run-time
>>>> error/warning, however perl is a scripting language and is built to be
>>>> flexible, assumes you know what you're doing and will silently oblige
>>>> even the most horrendous abuses.
>>>>
>>>> You actually have the same issue in C: false is defined as 0 and true
>>>> is !false.
>>>
>>> However, in C, !0 is defined as 1.
>>
>> This is where lots of people make mistakes in C.
>
> You seem to be one of them.
>
>
>> if(a) is not the same as
>> if(a == !0)
>
> I didn't say that. I said !0 is the same thing as 1 which means, that
>
> if (a == !0)
>
> is exactly the same as
>
> if (a == 1)
>
> While
>
> if (a)
>
> is the same thing as
>
> if (a != 0)
>
> Obviously (a != 0) and (a == 1) are not the same thing.
Yep, I missed the distinction in your original statement, I don't use the !0
construct as I find it rather pointless, so read it as "not zero".
Apologies
[...]
>>>
>>> x = (1 > 0) + 5;
>>>
>>> is perfectly well-defined in C and will always assign 6 to x.
>>>
>>> If a function is defined as "returning a true value on success" of
>>> course you cannot test this with if (function() == 1), you need to use
>>> if (function()).
>>
>> This example would work, however in some C compilers I have used
>> x=(2>0)+5 would always return 7.
>
> Then they were not C compilers.
>
> Each of the operators < (less than), > (greater than), <= (less than
> or equal to), and >= (greater than or equal to) shall yield 1 if the
> specified relation is true and 0 if it is false.89) The result has
> type int.
>
> (ISO-9899:1999. A similar definition is in Appendix A, section
> 7.6 of K&R I, German translation (I don't have the original)
Certainly the first ISO draft said that, I don't think I remember it in K&R,
unfortunately I can't find my copy so I'll believe you.
>
>> This is because the compiler worked with not 0 being true, and the
>> cheapest comparison on a particular platform is sub.
>
> So the result of
>
> (-2 > 0)
>
> would be -2 (i.e., true)? I think you should think about this a bit
> more.
You're right, I think I was thinking of ==
I am quite sure of this as it was one of the first nasties that bit me when
I first started using C. Functioning code on 1 platform was just being
strange on another (probably astech C or BDS C). The development platform
was VMS and TOPS-10, which had a more modern C compiler (as modern as they
got in '83) and we were back-porting to CP/M and RSX systems.
>> This doesn't break comparison operators,
>
> If (-2 > 0) is true that's pretty broken by any measure. If a compiler
> produces a different result than the C specification says it should, it
> is still broken.
Certainly. I must admit to not being fully familiar with the standards.
When the original drafts were published the whole thing was a bit of a shit-
fight with various large organisations attempting to wedge their own self-
serving bits into the standard. I was interested in the process at the
start however as things got more stupid rapidly lost interest and just got
on with programming. I haven't really revisited since.
The first standard took a long time to appear and a very long time before we
saw any compilers that believed in the standards, much less obeyed them.
[...]
>
> However, every version of perl (note: lower case 'p') since at least
> perl4 (probably perl1) has always returned 1 as the true value for the
> comparison operators (==, !=. <. >. <=, >=, eq, ne, lt, gt, le, ge) and
> the logical negation (!, not). It is not clear to me whether this is
> undocumented because @Larry want to keep the option of changing it one
> day (in this case, why is the false value documented? The ''/0 mixture
> is rather bizarre and it seems much more likely that one would like to
> change that in some future revision of the language), or whether it is
> simply undocumented because it's the same as in C and "people know that
> anyway, so we don't have to write it down". (Perl documentation has
> become more self-sufficient over the years, but originally it assumed a
> lot of general Unix knowledge and there are still spots which are only
> comprehensible if you have a background as a Unix/C programmer - this
> might be one of them)
Yep, I see your point. I personally don't treat the result of a comparison
operator as a useful int so it's not something I irrelevant. Obviously
others like yourself who do program in this manner would find it frustrating
to have a commonly used tool not have an officially defined behavior.
The way perl was put together originally was fairly loose which gave perl
it's flexibility. This created quite a few language "features" the people
discovered and started using which either became official language
constructs or Larry had to break or implement properly/differently in
subsequent versions. There was also a lot of experimental features released
that often were replaced by a better way of doing it in a later revision
(objects anyone ?), all of which meant the documentation suffered quite a
bit.
As you say, more recently the documentation has become quite good, though
even now I find some things I know about that I can't find a good
explanation for in the docs.
Bruce
------------------------------
Date: Sun, 01 Feb 2009 13:32:55 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl Peeves
Message-Id: <x7k58am2i0.fsf@mail.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>> Original C compilers had an easy way of doing conditionals; they would
>> assign a variable to a register and then branch on the Z flag.
PJH> This may have been true on the PDP-11, although I doubt it. It certainly
PJH> wasn't a common feature of CPUs at the time. Most only set the flags as
PJH> the result of some computation, not a simple MOV. (There is a special
PJH> TST instruction to set the status flags depending on the contents of a
PJH> register)
as someone who did tons of pdp-11 assembler work, let me clarify some
things (as well as my faulty ancient ram can do). the 11 had registers
but could directly access any ram location for any major op (of which
there weren't that many :). you didn't have to load into a reg to do a
test/branch (unlike risc designs or old 8 bitters). and yes, it did have
the Z bit so you could test for zero or not zero (along with negative
and overflow). the coolest thing was to do a test (or look at the
results of an op that set the flag bits) and do more than one branch on
the results. such as decrementing towards zero. branch on zero first to
handle a counted down (e.g. a timer) value. then branch on negative to
handle a overcounted value (i would set a timer value to 0 so the next
tick down to a negative would disable it). then fall through to handle
the positive case (not finished counting down).
MOV didn't set the flags since it didn't do any real operation. there
was a TST op just to set the flags based on a single value with no op
being done.
and yes, the ++/-- ops and c's early handling of 0/not-0 were inherited
from the 11. and so perl can claim inheritance from the pdp-11 and dec's
genius in designing its instruction set. still my fave of all time. not
the most powerful, but the most elegant given its goals and
restrictions.
PJH> If (-2 > 0) is true that's pretty broken by any measure. If a
PJH> compiler produces a different result than the C specification
PJH> says it should, it is still broken.
that would be very nasty. it implies using the SUB op for GT/LT
comparisons which is not cool at any level. i know it was done in
assembler but the Z flag was checked for comparisons, not the negative
flag. if some compiler decided to use the actual result for the boolean
value and it was used in an expression, you already said it gets nasty.
>> Perl does not treat scalars as integers and so it's conditionals are
>> more complex (and yes hacky) than C. Especially the one you don't
>> like, which is defining the behavior of a string being used in a
>> condition.
PJH> Who said I don't like it? I never said such a thing. I don't even think
PJH> it is very complex. The number 0, the strings '' and '0' and the undef
PJH> value are false, all other scalars are true.
i agree this is a simple and clear rule. why people fuss over it, i
don't know. let perl be perl. forcing a specific value to be the one
'true' false (sic :) is a waste of time and anal. it is like normalizing
for no reason and it bloats the code. even the concept of using the
result of a boolean test for its numeric or string value bothers me. a
boolean test value (of any kind in any lang) should only be used in a
boolean context. anything else is a slippery shortcut that makes the
code more complex and harder to read. saving a boolean and loading it
again is fine but the serialized format shouldn't matter. we are not
talking config files with a boolean entry here - that is another story.
PJH> day (in this case, why is the false value documented? The ''/0 mixture
PJH> is rather bizarre and it seems much more likely that one would like to
PJH> change that in some future revision of the language), or whether it is
PJH> simply undocumented because it's the same as in C and "people know that
PJH> anyway, so we don't have to write it down". (Perl documentation has
PJH> become more self-sufficient over the years, but originally it assumed a
PJH> lot of general Unix knowledge and there are still spots which are only
PJH> comprehensible if you have a background as a Unix/C programmer - this
PJH> might be one of them)
perl has the magic false of 0 and '' so it will DWIM and coerce as you
would expect given a numeric or string context. it is well defined and
bahaves cleanly. not much more to be said but you two can keep fighting.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sun, 1 Feb 2009 19:42:18 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl Peeves
Message-Id: <slrngobr8a.i66.hjp-usenet2@hrunkner.hjp.at>
On 2009-02-01 18:32, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
> PJH> day (in this case, why is the false value documented? The ''/0 mixture
> PJH> is rather bizarre and it seems much more likely that one would like to
> PJH> change that in some future revision of the language), or whether it is
> PJH> simply undocumented because it's the same as in C and "people know that
> PJH> anyway, so we don't have to write it down". (Perl documentation has
> PJH> become more self-sufficient over the years, but originally it assumed a
> PJH> lot of general Unix knowledge and there are still spots which are only
> PJH> comprehensible if you have a background as a Unix/C programmer - this
> PJH> might be one of them)
>
> perl has the magic false of 0 and '' so it will DWIM and coerce as you
> would expect given a numeric or string context. it is well defined and
> bahaves cleanly.
Yes, magic false is well-defined. But why doesn't perl define the value
returned for true by the comparison operators?
hp
------------------------------
Date: Sat, 31 Jan 2009 23:58:54 -0800 (PST)
From: Owen <xemoth@gmail.com>
Subject: Re: perl qt with cygwin?
Message-Id: <e84cd62c-031f-47f2-9b41-3fb553f0966b@w1g2000prm.googlegroups.com>
On Jan 31, 4:40 pm, rabbits77 <rabbit...@my-deja.com> wrote:
> Owen wrote:
> > On Jan 31, 9:15 am, rabbits77 <rabbit...@my-deja.com> wrote:
> >> I am trying to get perl qt to work under cygwin
> >> and am not having much luck.
> >> I have KDE and QT installed. Everything should just compile and go
> >> but this is not the case.
> >> Googling reveals nothing but very old threads from various sources
> >> that don't help.
> >> Does anyone have any advice on how to get perl qt running under cygwin?
>
> > Are their any error messages?
>
> No matter what I do it always fails with a complaint that it cannot find
> kde-config.
> kde-config is in my PATH. KDE is installed on my machine...
> everything should be ok.
> Looking at the configure script I suspect that the script is
> expecting some output and when I run kde-config manually it just
> silently exits. My next course of action is to fiddle with the
> configure script but I haven't done that yet.
> If I am the only person with these problems I suppose I could
> keep some notes about what I am doing and if I get it
> to work somehow.
> I was hoping though that this was a problem that had already
> been solved. :)
Well I can't offer suggestions. Presumably entering # env|grep PATH
gives /usr/bin as one path? No conflict with kde4 and kde?
What are the actual words of the complaint. Look in the config log
where it fails to see what it was actually doing before the failure.
Might give a clue as to how it was looking for it
Don't fiddle with configure unless you know what you are doing
Owen
------------------------------
Date: Sun, 01 Feb 2009 09:34:56 -0500
From: zentara <zentara@highstream.net>
Subject: Re: perl qt with cygwin?
Message-Id: <ogcbo4580oevoo32rc6r4lau50369p0foh@4ax.com>
On Sat, 31 Jan 2009 23:58:54 -0800 (PST), Owen <xemoth@gmail.com> wrote:
>On Jan 31, 4:40 pm, rabbits77 <rabbit...@my-deja.com> wrote:
>> Owen wrote:
>> > On Jan 31, 9:15 am, rabbits77 <rabbit...@my-deja.com> wrote:
>> >> I am trying to get perl qt to work under cygwin
>> >> and am not having much luck.
>> >> I have KDE and QT installed. Everything should just compile and go
>> >> but this is not the case.
>> >> Googling reveals nothing but very old threads from various sources
>> >> that don't help.
>> >> Does anyone have any advice on how to get perl qt running under cygwin?
>>
>> > Are their any error messages?
>>
>> No matter what I do it always fails with a complaint that it cannot find
>> kde-config.
As far as I know, the Perl Qt module is very old and has not been
keeping up with KDE development.... so unless you have found some new
version of Perl/Qt, just forget about using it, it is obsolete and not
actively maintained. The module on CPAN is version 0.03 and dated 1997.
zentara
--
I'm not really a human, but I play one on earth.
http://www.zentara.net/~zentaran/Remember_How_Lucky_You_Are.html
------------------------------
Date: 01 Feb 2009 17:30:52 GMT
From: noone <noone@none.net>
Subject: Regex problem from book, please help with solution
Message-Id: <4985dc4b$0$4894$9a6e19ea@unlimited.newshosting.com>
I'm reading Sams Teach Yourself Perl in 24 Hours, 2nd edition. In the
chapter about regex, there is an activity:
"See whether you can produce a pattern to match a standard time format.
All the following should be acceptable: 12:00am, 5:00pm, 8:30AM. These
should probably not be accepted: 3:00, 2:60am, 99:00am, 3:0pm."
I did this:
@time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
if (m/^?\d:[0-59]\w?/)
{
print "$_\n";
}
;
and i thought it matched everything but 2:60, but now it doesn't work at
all. regardless, i don't know how to make the appropriate pattern
according to the directions provided. can someone help?
jo
------------------------------
Date: Sun, 01 Feb 2009 09:58:09 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: Regex problem from book, please help with solution
Message-Id: <Solhl.2338$%j5.989@newsfe10.iad>
noone wrote:
> I'm reading Sams Teach Yourself Perl in 24 Hours, 2nd edition. In the
> chapter about regex, there is an activity:
>
> "See whether you can produce a pattern to match a standard time
> format. All the following should be acceptable: 12:00am, 5:00pm,
> 8:30AM. These should probably not be accepted: 3:00, 2:60am, 99:00am,
> 3:0pm."
>
> I did this:
> @time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
> if (m/^?\d:[0-59]\w?/)
> {
> print "$_\n";
> }
> ;
>
> and i thought it matched everything but 2:60, but now it doesn't work
> at all. regardless, i don't know how to make the appropriate pattern
> according to the directions provided. can someone help?
>
> jo
I don't know anything of that book or what code you're using that isn't
shown in your above example, and I fail to understand why you wrote the
above regex the way you did, but going from your requirement off the
top of my head, I'd probably do some matching like:
print "$_\n" if /^(?:[1-9]|1[0-2]):[0-5][0-9][ap]m$/i;
Anyway, I'm pretty sure the code you have typed or pasted above is not
what's in the book. Please type of paste the relevant code, rather
than what you've done... or is that really what the book shows?
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Sun, 1 Feb 2009 18:13:22 +0000 (UTC)
From: comps@riffraff.plig.net (Vicky Conlan)
Subject: Re: Regex problem from book, please help with solution
Message-Id: <gm4oo2$8ud$2@magenta.plig.net>
According to <noone@none.net>:
>I did this:
>@time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
>if (m/^?\d:[0-59]\w?/)
>{
> print "$_\n";
>}
>;
>
>and i thought it matched everything but 2:60, but now it doesn't work at
>all. regardless, i don't know how to make the appropriate pattern
>according to the directions provided. can someone help?
If that's all your code, you don't have anything in $_ by the time you
reach the RE. (I think if you "use warnings" it will show you this)
Put a foreach around it so it loops over the values of @time:
my @time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
foreach (@time) {
if (m/^?\d:[0-59]\w?/) {
print "$_\n";
}
}
Although your next question shuld probably be "why does it print 3:00
and not 2:60", cos I can't see why right now. :-/
--
------------------------------
Date: Sun, 01 Feb 2009 18:27:15 GMT
From: sln@netherlands.com
Subject: Re: Regex problem from book, please help with solution
Message-Id: <78qbo4pnqt5n8m500d615aeqm7fea9quq3@4ax.com>
On Sun, 1 Feb 2009 18:13:22 +0000 (UTC), comps@riffraff.plig.net (Vicky Conlan) wrote:
>According to <noone@none.net>:
>>I did this:
>>@time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
>>if (m/^?\d:[0-59]\w?/)
>>{
>> print "$_\n";
>>}
>>;
>>
>>and i thought it matched everything but 2:60, but now it doesn't work at
>>all. regardless, i don't know how to make the appropriate pattern
>>according to the directions provided. can someone help?
>
>If that's all your code, you don't have anything in $_ by the time you
>reach the RE. (I think if you "use warnings" it will show you this)
>
>Put a foreach around it so it loops over the values of @time:
>
>my @time=qw( 12:00am 5:00pm 3:00 2:60 8:30AM 99:00AM 3:0pm );
>foreach (@time) {
> if (m/^?\d:[0-59]\w?/) {
^^^^
[0123459] ie: 0 through 5 and 9, no 6 in there
> print "$_\n";
> }
>}
>
>Although your next question shuld probably be "why does it print 3:00
>and not 2:60", cos I can't see why right now. :-/
sln
------------------------------
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 V11 Issue 2176
***************************************
