[32839] in Perl-Users-Digest
Perl-Users Digest, Issue: 4104 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Dec 30 09:09:36 2013
Date: Mon, 30 Dec 2013 06:09:04 -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 Mon, 30 Dec 2013 Volume: 11 Number: 4104
Today's topics:
Re: Extra commas ignored? <ben@morrow.me.uk>
Re: How does the perl debugger find the source lines <rweikusat@mobileactivedefense.com>
Re: How does the perl debugger find the source lines <ben@morrow.me.uk>
Re: How does the perl debugger find the source lines <hjp-usenet3@hjp.at>
Re: PDL Questions - Dec. 21, 2013 <cwilbur@chromatico.net>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <vilain@NOspamcop.net>
Re: Question about language setting - 2nd question <dave@invalid.invalid>
Re: Question about language setting <hjp-usenet3@hjp.at>
Re: Question about language setting <ben@morrow.me.uk>
Re: Question about language setting <dave@invalid.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 30 Dec 2013 00:21:31 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extra commas ignored?
Message-Id: <btq6pa-ovv.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >>
> >> ie, there is something like a list operator and the , is used as purely
> >> syntactical element for separating terms in a list.
> >
> > OK, you can call it that if you like; it's not really any different from
> > the ?: operator, which uses '?' and ':' to separate its three
> > arguments.
>
> If it really wasn't different, you'd refer to 'the question mark
> operator' and 'the colon operator' in this case and this would be as
> inadequate because they're also just syntactical elements of something
> else.
As I said, you can call it what you like. 'The comma operator' is easier
to say than 'the list-of-terms-separated-by-(possibly-multiple)-commas
operator', but if you'd rather call it OP_LIST or 'the list operator'
that's fine by me. (You might get some argument from people who claim
there's no such thing as a list in scalar context, an attitude that is
unfortunately supported by the documentation.)
> > My point was that 'the scalar comma operator' and 'the list context list
> > construction operator' are actually the same operator, whose behaviour
> > is context-dependant.
>
> There is no such thing as 'a comma operator' in the Perl grammar (at
> least, I didn't find anything like that), commas are used as separators
> in a certain kind of compound expression. As Tim McDaniel observed,
> despite comma is documented as binary operator, it doesn't behave like
> one: It has no arity.
Yes. This is, indeed, a (somewhat) important difference between comma
and the true binary operators. (And also a good example of the fact that
the perl documentation is descriptive rather than prescriptive and
frequently slightly inaccurate.)
> >> At least in certain cases, the list is expanded inline, with no 'list
> >> operator' anywhere in sight, eg
[...]
> >
> > That's a slight hack: this is the 'listop' production, which does
> > actually build an OP_LIST, but then, rather than adding an extra op, it
> > converts the OP_LIST into an OP_RETURN. It's easier to see what's
> > happening without -exec:
> >
> > ~/src/perl/perl% perl -MO=Concise,a -e'sub a { $x, $y, $z }'
> > main::a:
> > 7 <1> leavesub[1 ref] K/REFC,1 ->(end)
> > - <@> lineseq KP ->7
> > 1 <;> nextstate(main 1 -e:1) v ->2
> > 6 <@> list K ->7
> > 2 <0> pushmark s ->3
> > - <1> ex-rv2sv sK/1 ->4
> > 3 <$> gvsv(*x) s ->4
> > - <1> ex-rv2sv sK/1 ->5
> > 4 <$> gvsv(*y) s ->5
> > - <1> ex-rv2sv sK/1 ->6
> > 5 <$> gvsv(*z) s ->6
> > -e syntax OK
> > ~/src/perl/perl% perl -MO=Concise,a -e'sub a { return $x, $y, $z }'
> > main::a:
> > 7 <1> leavesub[1 ref] K/REFC,1 ->(end)
> > - <@> lineseq KP ->7
> > 1 <;> nextstate(main 1 -e:1) v ->2
> > 6 <@> return K ->7
> > 2 <0> pushmark s ->3
> > - <1> ex-rv2sv sK/1 ->4
> > 3 <$> gvsv(*x) s ->4
> > - <1> ex-rv2sv sK/1 ->5
> > 4 <$> gvsv(*y) s ->5
> > - <1> ex-rv2sv sK/1 ->6
> > 5 <$> gvsv(*z) s ->6
> > -e syntax OK
> >
> > The only different between these two is that perl has turned the 'list'
> > into a 'return'.
>
> The difference I see here is that there has to be some op (not operator)
> in this place and if no other was provided, a 'list' op is used.
That's a perfectly reasonable alternative way of looking at it: that a
plain list (in any context) implicitly invokes the 'identity list
operator', which in scalar context returns its last argument. As a
matter of fact, the compiler always builds a list headed by a real
OP_LIST before converting the head op, but you can treat that as in
implementation detail.
It's perhaps worth pointing out here that the 'execute multiple
statements sequentially' operator, OP_LINESEQ, is compiled almost
exactly the same way as OP_LIST, but with semicolon as the separator.
This is why all the conveniences of allowing multiple separators and
allowing an optional terminator apply to statements as well as list
terms. In many cases this OP_LINESEQ is then converted into some other
op in the same way as OP_LIST; for instance, most ops with block scope
convert it into an OP_LEAVE, which does the block-exit processing.
> That 'return' happens to be equivalent to that is just an accidental
> property of my example (The same phenomenon can be observed for
> reverse and grep and presumably, for any other list operator returning
> a list).
Yes, the fact those two operators return the same thing is not relevant.
> >> It would be interesting to know if 'the comma operator' in C is actually
> >> treated as an operator or if the historical misnomer actually came from
> >> there.
> >
> > In C the comma really does have two entirely different meanings: the
> > 'comma operator' which behaves like Perl's comma in scalar context, and
> > the comma-as-an-argument-separator in the argument list of a function
> > call, which is not really an operator at all.
>
> The main difference is that , is really a binary operator in C, eg this
>
> ------
> int main(void)
> {
> return 1,, 2;
> }
> ------
>
> doesn't compile because of a missing operand.
And neither
int foo (int a,, int b)
nor
bar(a,, b)
will compile either.
Ben
------------------------------
Date: Sun, 29 Dec 2013 19:38:01 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <87txdrv46e.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
>> I'm currently writing a plugin for qpsmtpd, which means that both the
>> plugin and the tests are read from a file, massaged a bit, compiled via
>> eval() and finally the test framework calls the test methods.
>>
>> This seems to confuse the debugger a bit, because it looks like this:
> [...]
>>
>> The interesting thing is that it shows the correct source file
>> ("t/plugin_tests/no_bcc") and the correct line numbers (9, 11, 12), but
>> not the contents of the lines, which look like this:
>>
>> 9 my ($self) = @_;
>> 10
>> 11 my $qp = $self->qp;
>> 12 $qp->command("rset");
>>
>> So, if the debugger knows the file and the line, why can't it display
>> the content?
>
> I'll see if I can come up with a more intelligent answer later, but to
> start with you might want to read perldoc perl5db.pl (particularly 'DATA
> STRUCTURES MAINTAINED BY CORE'), the entry for $^P in perlvar, and
> perhaps perldoc perldebguts.
The simple answer seems to be 'because the array perl uses to locate
source lines' (assuming the path to the source file was a/b/c.pl, the
corresponding array would be
@_<a/b/c.pl
in package main) doesn't contain the code.
Example showing how to access that:
,----
| [rw@sable]/tmp#perl -d ab/a.pl
|
| Loading DB routines from perl5db.pl version 1.32
| Editor support available.
|
| Enter h or `h h' for help, or `man perldebug' for more help.
|
| main::(ab/a.pl:1): print 1;
| DB<1> $a = *{"_<ab/a.pl"}{ARRAY}
|
| DB<2> p @$a
| BEGIN { require 'perl5db.pl' };
| print 1;
| print 2;
`----
It is possible to load the source code lines into this array (offsetted
by 1) and the debugger then happily uses it.
> Alternatively you might want to find a way to avoid using the debugger.
> IME it causes more problems than it solves; for interactive debugging I
> find Devel::REPL useful.
"Devel::REPL - a modern perl interactive shell"
As usual, modern means "It prints 'Hello, world!'" but it needs six
order of magnitude more infrastructure code than a simple
perl -e 'print "Hello, World!\n"'
would require" ...
------------------------------
Date: Mon, 30 Dec 2013 00:33:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <nkr6pa-ovv.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> |
> | main::(ab/a.pl:1): print 1;
> | DB<1> $a = *{"_<ab/a.pl"}{ARRAY}
There's no need to go that deep into the symbol table; @{"_<ab/a.pl"}
works perfectly well given you've got strict refs off.
> It is possible to load the source code lines into this array (offsetted
> by 1) and the debugger then happily uses it.
Yes. The more interesting question is why they weren't there already; I
don't yet have an answer to that.
> > Alternatively you might want to find a way to avoid using the debugger.
> > IME it causes more problems than it solves; for interactive debugging I
> > find Devel::REPL useful.
>
> "Devel::REPL - a modern perl interactive shell"
>
> As usual, modern means "It prints 'Hello, world!'" but it needs six
> order of magnitude more infrastructure code than a simple
>
> perl -e 'print "Hello, World!\n"'
>
> would require" ...
Yup. It also gets all the hard things right, like running pieces of code
read separately in the same lexical context (or not, as you like).
Ben
------------------------------
Date: Mon, 30 Dec 2013 14:05:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <slrnlc2rss.3rg.hjp-usenet3@hrunkner.hjp.at>
On 2013-12-30 00:33, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> It is possible to load the source code lines into this array (offsetted
>> by 1) and the debugger then happily uses it.
>
> Yes. The more interesting question is why they weren't there already; I
> don't yet have an answer to that.
I played around with it a bit more, but I am just becoming more
confused. It's not like eval never fills in @{"_<$filename"}. In this
simple test script:
#!/usr/bin/perl
use v5.10;
eval ('
#line 1 "3a"
use v5.10;
sub foo {
say "bla";
}
');
foo();
say;
@{"_<3a"} is filled with the correct lines and I can singlestep into foo().
So, sometimes the lines are there and sometimes they aren't.
I'll try to come up with a minimal script which exhibits the faulty
behaviour.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 29 Dec 2013 22:45:32 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <87ha9r3stf.fsf@new.chromatico.net>
>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
EDG> With humor intended, as the caveman said to the
EDG> dinosaurs,
EDG> "Evolve or perish!"
EDG> The dinosaurs are no more.
And yet you remain.
EDG> That also applies to programming languages. If they are not
EDG> easily usable by all interested parties then their days might
EDG> be numbered.
You know what? If you don't want to use Perl, stop using it.
Some years back, a masterful bookseller of my acquaintance said, "You
know, the best thing you can do for your business is to find the 5% of
your customers that take 80% of your time and effort, and convince them
to patronize your competitors instead."
Perl will survive just fine without pandering to the incompetent
crackpot constituency. Perhaps you want Python, PHP, Ruby, or
Javascript instead?
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 29 Dec 2013 23:08:11 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <Neadnf8OsfUzYl3PnZ2dnUVZ_o2dnZ2d@earthlink.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:yoOdnUBR--ONSiDPnZ2dnUVZ_o2dnZ2d@earthlink.com...
Rather than try to respond to recent individual posts I am posting
just this one response. If I missed anyone's question then they can try
posting a response to this note or contact me by E-mail.
As I have stated in many previous posts, I consider Perl to be an
almost ideal language for scientists to work with if they are not doing
something that involves highly specialized applications such as the fastest
possible computations that can be done or something that requires tremendous
amounts of computer memory.
Part of Perl's power is the fact that it is running and available on
so many Internet servers.
However, for general usage by the international scientific community
a programming language also needs to have one or several of the following
three things. And unfortunately, Perl doesn't meet those requirements in my
opinion.
1. It needs to be able to run "out of the box" with no problems. That
means that when it is installed there aren't any additional steps that need
to be done to start using it.
I myself have installed and reinstalled quite a few ActiveState
versions of Perl on quite a few computers. And I can't recall ever having
any problems with any of the original installations.
It is also nice that Perl appears to be "portable." In some cases I
wanted to use Perl on a new computer but did not want to have to go through
the steps of having PPM download and install innumerable modules. So I
installed the original Perl program, deleted all of the files in that Perl
directory, and copied the entire Perl directory from one of my other
computers onto the new computer.
All of the copied modules still worked.
However, there have been some problems with getting new modules to
work. And PDL is the most important of them so far.
PPM did not seem to get the job done by itself though I plan to try
using it again and see if I might have missed something.
Doing everything else possible and following all of the instructions
on the PDL instruction pages got the module installed and running for some
commands but not others.
This means that the PDL module did not run "out of the box" for my
installation. And if people cannot get something to run immediately like
that then the programming language has a major limitation. Individual
scientists don't have time to spend an entire week trying to get a computer
language to work.
2. If additional instructions are needed then they should be available at
some Web site and extremely clear and understandable for people who are not
expert computer programmers.
The PDL module instructions at the PDL Web site were not, in my
opinion, very easy to understand. And if I could not get the module to work
after using those instructions it means that they needed to be clearer or
more complete.
3. If all else fails, there should be some type of support group that can
help people with getting past some type of installation or usage problem.
And this is where, in my and some other people's opinions, the Perl
Newsgroup fails miserably.
It has been my personal experience that instead of help, requests for
assistance here have usually been met with criticism and arguments. And
this isn't only my opinion.
One of my colleagues, a retired professional computer programmer who
still does that type of work as a hobby posted a few notes to the Perl
Newsgroup a while back and found the responses so offensive that he has
since absolutely refused to have anything to do with Perl. In fact, with
humor intended I recently suggested to him that when his days were over, if
he hadn't behaved during this life then his penance would be to write Perl
language programs for all of eternity. He basically responded by saying
that this would be unspeakably cruel.
I have heard virtually exactly the same thing from almost everyone
else I have spoken with. The widespread opinion is that "The Perl Newsgroup
is one of the worst places anyone can visit in order to get help."
So, as valuable and useful as the language is, those three problems
make it unattractive for general use in the international scientific
community in my opinion. That is unfortunate.
In contrast, people posting notes to the Python and Fortran
Newsgroups have been so incredibly helpful with answering questions and even
volunteering to translate programs into other languages that I had to
politely ask them to stop sending me information. I couldn't keep up with
all the help they were offering.
The Julia language people appear to also be quite helpful.
So, we are now considering Fortran and Julia for future work. Python
is attractive but doesn't by itself do extremely high speed calculations.
Julia is being checked. But I get the impression that it is still in some
early stages of development. So far there isn't even a Julia language
Newsgroup. I did suggest to those people that they might create one.
For my purposes, working with Perl to a large degree might have one
last chance.
If my Web site Internet provider tells me that the PDL module is
available on my server for use with Perl then it would probably be worth the
trouble to learn how to get it to work. In fact if it is already installed
on the server then that would mean that any installation problems have
already been solved at that location.
I expect that it would be nice to use PDL for Internet server
applications where png type files etc. needed to be created by Perl programs
running on the server.
Finally,
The following two (indirect) Web pages have now been updated. And I
am planning to start circulating information regarding them to governments,
NGOs, and individual researchers around the world.
http://www.freewebs.com/eq-forecasting/DSAT.html
http://www.freewebs.com/eq-forecasting/Science_Organization.html
If you work with government scientists and agencies long enough the
mental picture you might form is similar to looking up at the night sky.
Individual science groups within a government such as in NASA, the EPA, FDA,
and many others could be viewed as points of light in the sky just like
individual stars. There are few or no connections between them. And
virtually every government scientist I have ever spoken with has stated that
communications and data sharing between government agencies are generally
abysmal or completely nonexistent.
These are personal opinions.
------------------------------
Date: Mon, 30 Dec 2013 01:34:52 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <JJ-dnUZ2ZeWSv1zPnZ2dnUVZ_qudnZ2d@earthlink.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:Neadnf8OsfUzYl3PnZ2dnUVZ_o2dnZ2d@earthlink.com...
Recommendation:
Instead of criticizing people posting notes here, why don't you folks
create a parallel moderated Perl Newsgroup?
There aren't that many posts to this Newsgroup that it would be
overly difficult for a team of a half dozen people to run the moderated
Newsgroup. I don't know exactly how the Newsgroup management structure
works. But perhaps it might be possible create a list of approved posters
who would not need to have each of their posts approved for posting.
That way, the "amateurs" could have a Newsgroup resource where the
language could be discussed. And everyone would be happy.
------------------------------
Date: Mon, 30 Dec 2013 02:04:46 -0800
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <vilain-C9BC15.02044630122013@news.individual.net>
In article <JJ-dnUZ2ZeWSv1zPnZ2dnUVZ_qudnZ2d@earthlink.com>,
"E.D.G." <edgrsprj@ix.netcom.com> wrote:
> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
> news:Neadnf8OsfUzYl3PnZ2dnUVZ_o2dnZ2d@earthlink.com...
>
> Recommendation:
>
> Instead of criticizing people posting notes here, why don't you folks
> create a parallel moderated Perl Newsgroup?
>
> There aren't that many posts to this Newsgroup that it would be
> overly difficult for a team of a half dozen people to run the moderated
> Newsgroup. I don't know exactly how the Newsgroup management structure
> works. But perhaps it might be possible create a list of approved posters
> who would not need to have each of their posts approved for posting.
>
> That way, the "amateurs" could have a Newsgroup resource where the
> language could be discussed. And everyone would be happy.
The perl group seems to be particularly prickly about people doing their
homework before posting. I generally try what I can, get stuck, then
post what I've tried and ask for a pointer to send me in the right
direction.
It's considered bad form to ask for advice and then ignore that advise
or argue with the people offering it. Most usenet news groups will
plonk you pretty fast for that and not just here.
I've only been watching this group for 10 years, but I seem to recall
you pontificating ever so often, being guilty of both these above
points. The fact that people haven't plonked you yet just means they
like poking you with a stick just to see you react. That's probably why
your friend left, too.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Mon, 30 Dec 2013 13:28:36 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Question about language setting - 2nd question
Message-Id: <fV45K0OBJxbE-pn2-bbnyhz5GcX5w@paddington.bear.den>
Now the first problem is solved, see elseehere in this tree, on to the
next :-)
I have two input files the creation of which I have no control over.
One has been written, from C, using whatever codepage the user has.
The other file is encoded utf8.
Both files contain a file name. One of the consistancy checks is to
see if they match. I can read in the second file with open my $FILE2,
'<:encoding(utf8)", .......
So how to open the first?
open my $FILE1, '<', .....
open my $FILE1, <:raw', ....
open my $FILE1, '<', .........
binmode $FILE;
All seem to do exactly the same thing - except for \r\n processing.
or
open my $FILE1, '<:encoding(whatever)', ......
When perl converts to internal utf8 how does it decide to map code
points > 127 when it is not told the cp? It does not default to
current as I run with 850 and opening '<:encoding(cp850)' gives a
different result for points > 127 than does open '<'. It's complicated
by the fact that the field separator on the first file is hex DE that
will get mangled in the former case. But my $sep = decode("cp$cp",
"\xDE"); where $cp is the codepage seems to get around that one.
What I need to be able to do is
if ( $file1name eq $file2name ) where the names have accented
characters.
TIA
--
Regards
Dave Saville
------------------------------
Date: Sun, 29 Dec 2013 15:20:24 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Question about language setting
Message-Id: <slrnlc0bt8.lnp.hjp-usenet3@hrunkner.hjp.at>
On 2013-12-29 13:00, Dave Saville <dave@invalid.invalid> wrote:
> Interestingly:
>
> use strict;
> use warnings;
> use Carp;
>
> printf("%f\n", 2.5);
>
> Using perl 5.16.0
>
> [T:\tmp]try.pl
> Invalid version format (non-numeric data) at
> u:/perl5/lib/5.16.0/Carp.pm line 3.
>
> BEGIN failed--compilation aborted at u:/perl5/lib/5.16.0/Carp.pm line
> 3.
> Compilation failed in require at try.pl line 3.
> BEGIN failed--compilation aborted at try.pl line 3.
>
> Carp line 3 says { use 5.006; }
Yup. I think somebody (Rainer?) had already pointed out this line as the
likely culprit.
> Using perl 5.8.2
>
> [T:\tmp]try.pl
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LC_ALL = (unset),
> LANG = "de_DE_EURO"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> 2.500000
>
> Which is a darn site more useful IMHO.
>
> As the OS/2 setlocale() seems to suffer the same problem as the other
> OS above is there a perlish way around this one?
You could try
BEGIN { $ENV{LANG} = 'C' }
> The problem I have is that I am comparing strings from two sources.
> One where the string is in the local code page and the other in utf8.
> I solved this by using Encode
Yes, Encode contains the necessary functions (But depending on the
source it may be more convenient to use an I/O filter or soemthing
similar instead of calling Encode::decode() explicitely).
> and friends but that introduces the
> requirement for Carp and the above error :-(
I'm not sure why using Encode requires the use of Carp, but in any case
{ use 5.006; }
is valid Perl and must compile successfully, regardless of any locale
settings.
Is OS/2 still officially supported by Perl? It isn't on
http://www.cpan.org/ports/ anymore.
A viable workaround might be to compile perl on OS/2 without locale
support (since it doesn't seem to work correctly anyway). But that would
also mean that your users need to use this locale-less perl binary,
which may break some other scripts they use.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 30 Dec 2013 00:55:03 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question about language setting
Message-Id: <7ss6pa-to01.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
>
[OS/2, broken locales of some kind, and 'use feature' failing because of
that]
>
> Interestingly:
>
> use strict;
> use warnings;
> use Carp;
>
> printf("%f\n", 2.5);
>
> Using perl 5.16.0
>
> [T:\tmp]try.pl
> Invalid version format (non-numeric data) at
> u:/perl5/lib/5.16.0/Carp.pm line 3.
>
> BEGIN failed--compilation aborted at u:/perl5/lib/5.16.0/Carp.pm line
> 3.
> Compilation failed in require at try.pl line 3.
> BEGIN failed--compilation aborted at try.pl line 3.
>
> Carp line 3 says { use 5.006; }
>
> Using perl 5.8.2
>
> [T:\tmp]try.pl
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LC_ALL = (unset),
> LANG = "de_DE_EURO"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> 2.500000
>
> Which is a darn site more useful IMHO.
That's not surprising. In 5.10 a line like
use 5.010;
was changed to additionally imply
use feature ":5.10";
but only if the requested version was greater than 5.9.5. In 5.16 this
was changed again so that all 'use VERSION' requests loaded feature.pm,
with ":default" if the version was lower than 5.9.5. This change was
made because 5.16 introduced the 'array_base' feature, which controls
$[, which needs to be enabled by default but should be disabled if :5.16
or higher is requested.
Since your broken locales are causing feature.pm to fail, you get weird
failures if it gets loaded, but not otherwise. Carp loads feature.pm
(unintentionally) on 5.16 or later, but not on earlier versions.
It might be worth reporting a bug about this: broken locales are Not
Good, but they shouldn't cause perl to fail unless you explicitly try to
invoke locale functions.
Ben
------------------------------
Date: Mon, 30 Dec 2013 10:22:56 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Question about language setting
Message-Id: <fV45K0OBJxbE-pn2-FijwCRZZzjmo@paddington.bear.den>
On Mon, 30 Dec 2013 00:55:03 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
> Since your broken locales are causing feature.pm to fail, you get weird
> failures if it gets loaded, but not otherwise. Carp loads feature.pm
> (unintentionally) on 5.16 or later, but not on earlier versions.
>
A clever man (ie not me) has found the problem.
perl is built with locale.h
libc is built with unidef.h
The definitions of LC_NUMERIC and LC_MONETARY are reversed between
the two. Correcting locale.h to match unidef.h results in the posted C
testcase to work as expected. Our perl porter is rebuilding a version
with this change.
> It might be worth reporting a bug about this: broken locales are Not
> Good, but they shouldn't cause perl to fail unless you explicitly try to
> invoke locale functions.
>
Would you mind doing this please? I am not sure I can write a ticket
that others could act on.
--
Regards
Dave Saville
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4104
***************************************
