[25920] in Perl-Users-Digest
Perl-Users Digest, Issue: 8143 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 2 14:05:31 2005
Date: Thu, 2 Jun 2005 11:05:05 -0700 (PDT)
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, 2 Jun 2005 Volume: 10 Number: 8143
Today's topics:
Re: (Ilya?) cperl-mode.el and strings like ||""$foo""|| (David Combs)
Re: Perl: Win-32 vs. linux <flavell@ph.gla.ac.uk>
Re: Suppression of error messages if a regex does not m <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 2 Jun 2005 17:46:29 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: (Ilya?) cperl-mode.el and strings like ||""$foo""|| *within a string*?
Message-Id: <d7ngll$i18$1@reader1.panix.com>
In article <d7hfdm$2fj3$1@agate.berkeley.edu>,
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>[A complimentary Cc of this posting was sent to
>David Combs
><dkcombs@panix.com>], who wrote in article <d7bar7$kko$1@panix3.panix.com>:
>>
>> subject: (Ilya?) cperl-mode.el and strings like ||"\"$foo\""|| *within a string*?
>>
>>
>>
>> The following lines, to me, seem absolutely identical.
>>
>> But stick them into a file foo.pl, with cperl-mode, and I find
>> here on my computer that although when you put the cursor
>> on the right-paren just before the semicolon, it will
>> (a) (properly) turn both it and the matching left-paren green,
>> (b) except not on the sixth one (and beyond).
>
>What happens if you explicitly do M-C-b? [I do not have auto-match
>set on, so I can't check your symptoms; I do not see anything strange
>here, with 21.2.1 and my CPerl.]
>
>> PS: Anyone knonw how to find out what version of eg cperl-mode
>> a buffer is using? Or where the .el-file was actually found?
>
>Look in the CPerl menu (but I'm not sure that Emacs maintainers bother
>to change it). locate-library.
>
>The first thing to check is whether the errors persist with my version
>of cperl-mode ($CPAN/emacs or some such).
>
>Hope this helps,
>Ilya
Well, that program-piece I posted was full of syntax (and semantic!) errors.
Anyway, I do tend to find that "\" within strings sometimes confuse
cperl-mode.
Ditto for within qq!...! strings.
But then sometimes it works fine!
Maybe totally *my* fault, or maybe some once-in-a-while glitches
in cperl-mode.
Here's something from my .emacs:
(if (y-or-n-p "Load in /dkcjunk/cperl-mode.el?")
(progn
(load-file "/dkcjunk/cperl-mode.el")
(setq have-returned-from-loading-file-dkcjunk--cperl-mode-el 1)))
I just checked (C-h v) on that "have-returned..." variable, shows "1").
Again, would be nice if your (well, all!) versions of cperl-mode had
a setq-variable that showed the version-number (and last-modified-date?)
for the version.
Nifty function you mentioned: locate-library.
Unfortunately, it's independent of how the various libraries
were *actually* loaded.
What would be nice would be a (optional?) feature that,
for *every* library loaded-in, would remember *the actual
command that read it in*. (And it'd have to be a list for
each one, since a *later* load-library (or whatever other
mechanism) *overrode* that prior one!)
---
<rant on need for macros>
For debugging something I'm writing (perl), I often have
lots of statements like:
print("value of \$myVar1 is \"$myVar1\".\n");
print("value of \$myVar2 is \"$myVar2\".\n");
print("value of \$myVar3 is \"$myVar1\".\n");
...
...
God!, if we had macros (built-into perl), doing that
would be *so* simple -- via eg showval($myVar1), etc,
with all the backslashes and quotes etc generated by
the MACRO!
Why the perl-honchos so *hate* macros is a real puzzle
to me!
Alas!
</rant on need for macros>
Thanks for the reply, Ilya!
David
------------------------------
Date: Thu, 2 Jun 2005 11:43:07 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl: Win-32 vs. linux
Message-Id: <Pine.LNX.4.62.0506021058330.20513@ppepc56.ph.gla.ac.uk>
On Thu, 2 Jun 2005, John Bokma wrote:
> By best guess: decode maps to the internal encoding used by Perl,
> and I guess on Windows this is Win-something, and on Linux
> ISO-something.
I don't know why you think it's appropriate to "guess" this. The Perl
documentation is pretty clear about how characters are stored
internally (perldoc perlunicode), and if there *was* a difference, one
would expect to find it in the appropriate platform-specific perl
documentation.
The only thing that comes to mind is if the code calls Win32 *system*
functions, it may be necessary to run it with "wide system calls"
enabled. But that doesn't appear to be happening here.
If this was my problem, I'd be inclined to prepare a small test
document which I /knew/ contained these actual characters (as opposed
to containing character entity references, I mean), rather than
relying on some massive web document from elsewhere; and print out in
detail what's going on internally. But that's only for diagnosis
purposes: Perl's unicode implementation works best when you just use
it, not mess around with internals.
(I really can't be bothered to wade through the whole mess of HTML and
javascript contained at the cited URL to get further with this,
sorry.)
> Why not remove the utf-8 encoded non-breakable spaces before the
> decoding step?
It worries me that the questioner writes:
| The tr/// operation successfully removes UTF-8 encoded
| characters from the string in linux, but not Win-32
I see that the source contains quite a number of character
entitity references. So the question is, are we really talking about
no-break space *characters*, or are we talking about their character
entity references?
If we're really talking about *characters*, then note the "Caveat" in
the documentation for decode() in Encode:
When you run $string = decode("utf8", $octets), then $string may not
be equal to $octets. Though they both contain the same data, the utf8
flag for $string is on unless $octets entirely consists of ASCII data
(or EBCDIC on EBCDIC machines). See The UTF-8 flag below.
There's too much fiddling with internals going on here, IMHO. Perl's
unicode implementation usually works best when you just use it. The
web document in question is sent as utf-8 from its server, by the way.
------------------------------
Date: Thu, 02 Jun 2005 16:17:02 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Suppression of error messages if a regex does not match
Message-Id: <d7n7u3$gg7$1@slavica.ukpost.com>
Alan J. Flavell wrote:
> On Wed, 1 Jun 2005, brian d foy wrote:
>
>
>>Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:
>>
>>
>>>Anyone who advises turning warnings off to hide the warning may be
>>>technically accurate about what Perl does or can do - but
>>>operationally it's a disaster.
>>
>>When we know what it is doing and accept that in some cases
>>we know better than perl, turning off warnings is not a disaster.
>
>
> Accepted - but first we *do* need to "know what it is doing", and be
> sure that we really *do* know better than perl.
In the case of the 'numeric' and 'uninitialized' there can be _many_
times when we do know better. I would not suggest turning them off
globally but I think one should have absoultely no quarms at all about
conciously using the fact that undef behaves as a null string or that a
null string behaves as a zero where this makes for concise readable code.
>>I generally advise people to turn off warnings in production scripts.
>
> Fair enough, but only after the development is complete;
I don't favour turning off warnings any more than I'd favour turning off
strictures.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8143
***************************************
