[32431] in Perl-Users-Digest
Perl-Users Digest, Issue: 3698 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 22 18:09:22 2012
Date: Tue, 22 May 2012 15:09:07 -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 Tue, 22 May 2012 Volume: 11 Number: 3698
Today's topics:
Re: DBD::Oracle build on aix 6.1 ( host is a 64 bit db <hjp-usenet2@hjp.at>
Re: DBD::Oracle build on aix 6.1 ( host is a 64 bit db <hjp-usenet2@hjp.at>
forcing TCP in Net::DNS? <morty+usenet@frakir.org>
Re: forcing TCP in Net::DNS? <ben@morrow.me.uk>
Re: get local packages symbols with require <ben@morrow.me.uk>
Re: get local packages symbols with require <marc.girod@gmail.com>
Re: get local packages symbols with require <marc.girod@gmail.com>
Re: get local packages symbols with require <ben@morrow.me.uk>
Re: Help with install from CPAN <ben@morrow.me.uk>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <ben@morrow.me.uk>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Objective C (OT) <hjp-usenet2@hjp.at>
OT: How to calculate reputation scores? <mikee@mac.com>
Strawberry Perl 5.16 rocks <dilbert1999@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 22 May 2012 22:21:31 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: DBD::Oracle build on aix 6.1 ( host is a 64 bit db server )
Message-Id: <slrnjrntab.n13.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-20 22:09, Ben Morrow <ben@morrow.me.uk> wrote:
> You may need to make sure ORACLE_HOME and/or other Oracle environment
> variables are set correctly when you run Perl programs: I don't know
> if they are used at runtime as well as at compile time.
Yes, they are.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Tue, 22 May 2012 22:37:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: DBD::Oracle build on aix 6.1 ( host is a 64 bit db server )
Message-Id: <slrnjrnu8l.n13.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-22 08:58, Heinrich Mislik <Heinrich.Mislik@univie.ac.at> wrote:
> In article <pan.2012.05.21.23.14.02@gmail.com>, gogala.mladen@gmail.com says...
>>On Sat, 19 May 2012 13:35:07 -0500, Am Nym wrote:
>>> So should I install the 'Oracle Instant Client' before attempting the
>>> build of DBD::Oracle?
>>
>>Yes, you should install instant client. I did it on linux:
>
> Don't do that. Point ORACLE_HOME to the installed Oracle. Having the
> instantclient installed on an Oracle DB-server may leave you with
> incompatible versions of client libraries on that server. This can
> lead to strange errors (core dumped within Oracle library) during
> connect using ORACLE_SID.
My advice is just the opposite: Even if there is already a server
installation on the machine, install a separate client[1] and let your
users use only this client. That neatly separates the client and server
side and you can upgrade them independently.
Oracle seems to agree with me: Since Oracle 10 (IIRC) the client part of
the server installation (shared libraries, sqlplus, ...) is only
accessible by the "dba" group by default. So you can't just point
ORACLE_HOME there because a normal user doesn't have the necessary
permissions to invoke sqlplus or load libclntsh.so. (There is a script
to change the permissions, but IIRC it isn't included in the normal
distribution, you have download it from metalink)
hp
[1] These days I use instant client, mostly because I can just install
them with yum or apt-get (I really hate the Oracle Java installer
thingy). But you can do a client installation from the full
distribution, too.
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Tue, 22 May 2012 15:29:21 +0000 (UTC)
From: Morty <morty+usenet@frakir.org>
Subject: forcing TCP in Net::DNS?
Message-Id: <jpgbch$t22$1@dont-email.me>
Using Net::DNS, I'd like to be able to force TCP lookups even for
queries that shouldn't need TCP. dig supports this using the +tcp
option. Does Net::DNS have a method to do this? Net::DNS::Resolver
describes how to set TCP persistence and a TCP timeout, but I don't
see a way to force TCP.
Thanks.
- Morty
------------------------------
Date: Tue, 22 May 2012 17:08:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: forcing TCP in Net::DNS?
Message-Id: <58qs89-oj22.ln1@anubis.morrow.me.uk>
Quoth Morty <morty+usenet@frakir.org>:
> Using Net::DNS, I'd like to be able to force TCP lookups even for
> queries that shouldn't need TCP. dig supports this using the +tcp
> option. Does Net::DNS have a method to do this? Net::DNS::Resolver
> describes how to set TCP persistence and a TCP timeout, but I don't
> see a way to force TCP.
You want the 'usevc' flag.
Ben
------------------------------
Date: Tue, 22 May 2012 16:53:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: get local packages symbols with require
Message-Id: <mcps89-oj22.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> Hello,
>
> I am still trying to improve the CPAN ClearCase::Wrapper package:
> http://cpansearch.perl.org/src/DSB/ClearCase-Wrapper-1.16/Wrapper.pm
>
> In particular, somebody brought to my attention the fact that errors
> in sub-modules which Wrapper loads, are ignored.
> I decided that the point to fix was the snippet:
>
> local $^W = 0; # in case a function is redefined
> eval {
> local @INC = ($dir); # make %INC come out right
What is $dir?
> eval "require $pkg";
> };
> warn $@, next if $@;
>
> I restored the warnings, excepting 'redefine'.
How did you do that? If you used 'warnings', it won't do what you
expect. The reason for using $^W is that it propagates into required
modules; 'warnings' does not. OTOH, $^W will only silence warnings in
code not under 'warnings', so that's not terribly useful either.
If you want to do this right, you either need to find a way to avoid
redefining functions, or you need to set up a local __WARN__ handler
which filters out the 'redefined' warnings.
> I moved the 'warn $@' inside the eval block, right after the require.
> This gave me errors for all the modules used.
What errors?
> I removed the @INC restriction, and got to the next problem.
...so, @INC = $dir was completely wrong, and nothing was getting loaded
at all, but you weren't seeing errors because you threw them away? OK.
> Now I got into %{"${pkg}::"} not only the local symbols, but also all
> imported functions (e.g. 'find' from File::Find).
> The problem is that I need this information (the local symbols) for
> the remaining part.
Sub::Identify will tell you where a sub comes from.
Be careful about grubbing around in the symbol tables: there can be
things in there you may not expect. For instance, a constant created
with 'constant' is represented as a scalar ref in the symbol table,
where you would expect a glob to be. If you look up the glob by name
perl will transform it into a real glob for you, but if you try to
follow the ref from the stash you will find it isn't what you expect.
> Most of the symbols are indeed found in the autosplit.ix file which is
> also accessed, but not all:
> (first) some functions might have been excluded from the
> autosplitting, and (second) functions may have been aliased to shorter
> names, not matching any new *.al file (listed in autosplit.ix).
>
> My next move was to try to (optionally) 'require' twice, first in an
> open verbose mode, then as previously.
What did you think that would do?
> In the meanwhile, I restored %{"${pkg}::"} to its initial state.
Be *even* *more* careful about changing the stashes directly. This is an
area where there are still (probably) bugs in perl: here be segfaults.
> This led to the next error: 'use vars', in the sub-modules, was
> evaluated only once, the first time.
If you require the same file twice, without clearing the %INC entry, the
second time will do nothing. This is (pretty-much) the whole point of
require.
> Deep in what looks as a dead end, I ask for critique and help
What is your actual problem? You appear to be thrashing about, trying a
whole lot of things you don't really understand and making a horrible
mess, but you haven't explained what you're trying to do and how it
isn't working.
Ben
------------------------------
Date: Tue, 22 May 2012 12:05:37 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: get local packages symbols with require
Message-Id: <70c049d0-2577-4fb5-86ef-d0c70018a085@w13g2000vbc.googlegroups.com>
Hi Ben,
I start from the bottom.
On May 22, 4:53=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> What is your actual problem? You appear to be thrashing about, trying a
> whole lot of things you don't really understand and making a horrible
> mess, but you haven't explained what you're trying to do and how it
> isn't working.
Sorry. I find this a bit unfair, but I asked for it.
It is absolutely correct that I touch things I don't fully understand.
On another hand, I believe that the guy who wrote this package did
understand what he did.
This doesn't make the result perfect.
What I try to do, I explained in my introduction: the context is to
improve an existing module, which has users, hence respecting its
backwards compatibility.
> > I am still trying to improve the CPAN ClearCase::Wrapper package:
> >http://cpansearch.perl.org/src/DSB/ClearCase-Wrapper-1.16/Wrapper.pm
Now there are precise issues:
> > In particular, somebody brought to my attention the fact that errors
> > in sub-modules which Wrapper loads, are ignored.
Apart for that, this module works satisfactorily and provides a useful
service.
What service? It doesn't really make sense that I copy the doc which I
referred to, on CPAN.
This sets up an infrastructure for developing wrappers around a
proprietary tool, extending or modifying this one's behavior.
I develop myself one such wrapper.
> > =A0 =A0local $^W =3D 0; =A0 =A0# in case a function is redefined
> > =A0 =A0eval {
> > =A0 =A0 =A0 =A0local @INC =3D ($dir); =A0# make %INC come out right
> What is $dir?
This is enclosed in a:
for my $dir (@INC) { ... }
loop. Wrapper modules will be searched under ClearCase/Wrapper
hierarchies below each such $dir.
Setting @INC to ($dir) restricts the number of visible packages.
Most commonly, the wrapper modules will be found under site_perl,
whereas strict or File::Find are located under lib.
Hence this restriction will prevent accessing many useful modules
specifed with 'use'.
> > =A0 =A0 =A0 =A0eval "require $pkg";
> > =A0 =A0};
> > =A0 =A0warn $@, next if $@;
>
> > I restored the warnings, excepting 'redefine'.
> How did you do that? If you used 'warnings', it won't do what you
> expect. The reason for using $^W is that it propagates into required
> modules; 'warnings' does not.
Right. Thanks. I indeeed used 'no warnings q(redefine)'.
Redefining functions is not something generally recommendable.
It has only come necessary for backwards compatibility reasons, while
adding a top level loop to the wrapper infrastructure, hence requiring
to catch existing 'exit' and 'exec' calls.
It may well stay limited to one level.
> OTOH, $^W will only silence warnings in
> code not under 'warnings', so that's not terribly useful either.
> If you want to do this right, you either need to find a way to avoid
> redefining functions, or you need to set up a local __WARN__ handler
> which filters out the 'redefined' warnings.
I had a look at that and couldn't quite figure out how to do it.
But let's leave it for now.
> > I moved the 'warn $@' inside the eval block, right after the require.
> > This gave me errors for all the modules used.
> What errors?
Cannot find File::Find was one.
Sorry, I am home now, without access to my logs or the environment.
> > I removed the @INC restriction, and got to the next problem.
> ...so, @INC =3D $dir was completely wrong, and nothing was getting loaded
> at all, but you weren't seeing errors because you threw them away? OK.
As far as I can tell, no.
It must have done something useful despite the hidden errors.
Or I am understanding even less than you think.
What does 'require' do in presence of errors?
Somehow it must have skipped them in some way...
> > Now I got into %{"${pkg}::"} not only the local symbols, but also all
> > imported functions (e.g. 'find' from File::Find).
> > The problem is that I need this information (the local symbols) for
> > the remaining part.
> Sub::Identify will tell you where a sub comes from.
Thanks... Interesting.
> Be careful about grubbing around in the symbol tables: there can be
> things in there you may not expect. For instance, a constant created
> with 'constant' is represented as a scalar ref in the symbol table,
> where you would expect a glob to be. If you look up the glob by name
> perl will transform it into a real glob for you, but if you try to
> follow the ref from the stash you will find it isn't what you expect.
OK.
> > Most of the symbols are indeed found in the autosplit.ix file which is
> > also accessed, but not all:
> > (first) some functions might have been excluded from the
> > autosplitting, and (second) functions may have been aliased to shorter
> > names, not matching any new *.al file (listed in autosplit.ix).
>
> > My next move was to try to (optionally) 'require' twice, first in an
> > open verbose mode, then as previously.
>
> What did you think that would do?
I thought the first pass would populate the symbol table with
everything useful plus extra symbols I didn't want. It would give me
the useful errors and warnings I was lacking, without spurious extra
ones which obviously didn't affect the behavior.
I would throw away the whole result and the second pass would do as it
had always done, and whatever this is.
Now, as told, I noticed that I failed to 'throw away the whole
result', and that the first pass affected the second.
> > In the meanwhile, I restored %{"${pkg}::"} to its initial state.
> Be *even* *more* careful about changing the stashes directly. This is an
> area where there are still (probably) bugs in perl: here be segfaults.
OK. This was my attempt to clean up the result of the first phase.
Naive maybe.
> > This led to the next error: 'use vars', in the sub-modules, was
> > evaluated only once, the first time.
> If you require the same file twice, without clearing the %INC entry, the
> second time will do nothing. This is (pretty-much) the whole point of
> require.
OK. I could clean up %INC. Thanks.
Er... Was that a recommendation?
> > Deep in what looks as a dead end, I ask for critique and help
I got both.
In summary, you offer me two venues. Either:
- use Sub::Identify to skip some entries in %{"${pkg}::"}, without
needing to touch it after the single pass needed.
- cleaning %INC in addition to what I already did.
Clearly the first one looks preferable, especially as I still don't
understand how the 'use vars' were affected (and probably the 'use
constant' as well).
There obviously remains something unsettled about what actually
happens in the original code, with the require under a restricted
@INC, and throwing errors away.
I would be *very* surprised if nothing at all.
In fact, I don't know where else the modules could be loaded...
And, they are.
Thanks,
Marc
Marc
Thanks.
------------------------------
Date: Tue, 22 May 2012 12:55:31 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: get local packages symbols with require
Message-Id: <423f3e11-6f8b-47b8-b4e7-bfe35bdffa76@w10g2000vbc.googlegroups.com>
Hi again Ben, and of course others,
On May 22, 8:05=A0pm, Marc Girod <marc.gi...@gmail.com> wrote:
> - use Sub::Identify to skip some entries in %{"${pkg}::"}, without
> needing to touch it after the single pass needed.
I decided to give it a try from home, and indeed, this looks
promising:
tmp> perl -MFile::Find -M'Sub::Identify q(:all)' -le \
'for (keys %{"File::Find::"}){ \
my $sn=3Dsub_name(\&$_); \
my $p =3D stash_name(\&$_); \
defined $sn and $p eq q(File::Find) and print "$sn in $p"}'
find in File::Find
finddepth in File::Find
(skipped: 44)
Using B instead trades off only functions which would be loaded from C
libraries, right?
I think this is excluded in my case.
tmp> perl -MFile::Find -MB -le \
'for (keys %{"File::Find::"}){ \
my $coderef=3D\&$_; \
ref $coderef or next; \
my $cv =3D B::svref_2object($coderef); \
$cv->isa('B::CV') or next; \
$cv->GV->isa('B::SPECIAL') and next; \
$p=3D$cv->GV->STASH->NAME; \
if($p eq q(File::Find)){ \
print "$p::",$cv->GV->NAME} \
else{$skip++}} \
print"skipped: $skip"'
find
finddepth
skipped: 44
Thanks,
Marc
------------------------------
Date: Tue, 22 May 2012 22:36:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: get local packages symbols with require
Message-Id: <7gdt89-ph3.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On May 22, 4:53 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > What is your actual problem? You appear to be thrashing about, trying a
> > whole lot of things you don't really understand and making a horrible
> > mess, but you haven't explained what you're trying to do and how it
> > isn't working.
>
> Sorry. I find this a bit unfair, but I asked for it.
Perhaps it was a little unfair. Sorry about that.
> What I try to do, I explained in my introduction: the context is to
> improve an existing module, which has users, hence respecting its
> backwards compatibility.
Yup. That's sensible, obviously.
> I develop myself one such wrapper.
>
> > > local $^W = 0; # in case a function is redefined
> > > eval {
> > > local @INC = ($dir); # make %INC come out right
>
> > What is $dir?
>
> This is enclosed in a:
>
> for my $dir (@INC) { ... }
>
> loop. Wrapper modules will be searched under ClearCase/Wrapper
> hierarchies below each such $dir.
...*why*? That's exactly what perl does when you call 'require' without
messing about with @INC. The only effect this will have is that if the
module you are loading loads more modules in its turn, they will have to
be in the same directory. Is that the desired effect here? ISTM it will
just cause problems, unless there's something funny going on you haven't
posted yet.
(It's not quite clear to me yet how much of this you wrote, and how much
is someone else's code you're trying to improve. If you wrote this: what
were you trying to do? If you didn't, can you see anything elsewhere in
the code to suggest why this was done? Do you have any VCS logs you can
look through?)
> Setting @INC to ($dir) restricts the number of visible packages.
> Most commonly, the wrapper modules will be found under site_perl,
> whereas strict or File::Find are located under lib.
> Hence this restriction will prevent accessing many useful modules
> specifed with 'use'.
...yes, exactly.
> > > eval "require $pkg";
> > > };
> > > warn $@, next if $@;
> >
> > > I restored the warnings, excepting 'redefine'.
>
> > How did you do that? If you used 'warnings', it won't do what you
> > expect. The reason for using $^W is that it propagates into required
> > modules; 'warnings' does not.
>
> Right. Thanks. I indeeed used 'no warnings q(redefine)'.
> Redefining functions is not something generally recommendable.
> It has only come necessary for backwards compatibility reasons, while
> adding a top level loop to the wrapper infrastructure, hence requiring
> to catch existing 'exit' and 'exec' calls.
> It may well stay limited to one level.
There are two points here. The first is that 'no warnings' will have no
effect whatever on the required code: it's lexically scoped, so it only
affects the code lexically following it, in the same file.
The second is that overriding builtins like exit and exec is quite
different from overriding functions. Which are you trying to do, or are
you trying to both?
> > OTOH, $^W will only silence warnings in
> > code not under 'warnings', so that's not terribly useful either.
>
> > If you want to do this right, you either need to find a way to avoid
> > redefining functions, or you need to set up a local __WARN__ handler
> > which filters out the 'redefined' warnings.
>
> I had a look at that and couldn't quite figure out how to do it.
> But let's leave it for now.
OK. Basically, you would want something like
local $SIG{__WARN__} = sub {
my ($msg) = @_;
$msg =~ /redefined/ and return;
warn $msg;
};
eval "require $mod; 1;";
only with a more carefully thought out set of conditions for suppressing
the warning. (I'm not suggesting this is the Right Answer. Almost
certainly, the right answer is either to stop the warnings from
happening in the first place, or to put 'no warnings "redefine"' around
the bit of code that does the actual redefining.)
> > > I moved the 'warn $@' inside the eval block, right after the require.
> > > This gave me errors for all the modules used.
>
> > What errors?
>
> Cannot find File::Find was one.
OK, so these are errors caused by the @INC manipulation. What happens if
you just get rid of that? Forget the loop, and just let perl search @INC
as usual.
> > > I removed the @INC restriction, and got to the next problem.
>
> > ...so, @INC = $dir was completely wrong, and nothing was getting loaded
> > at all, but you weren't seeing errors because you threw them away? OK.
>
> As far as I can tell, no.
> It must have done something useful despite the hidden errors.
> Or I am understanding even less than you think.
> What does 'require' do in presence of errors?
> Somehow it must have skipped them in some way...
If there is a compile-time error, or if the required code dies, require
will throw an exception (as though 'die' had been called). That
exception will be caught by the eval "", and stuffed into $@. If you
don't look at $@ between the end of the eval "" and the end of the
eval {}, any errors from require will be lost.
If a required file fails to load because something like 'use File::Find'
can't find the module it needs, that's a compile time error and nothing
else in that file will be compiled, let alone executed. It won't stop
the whole program, though: that's what the eval is for. If you are doing
this several times is it possible some loaded successfully and some
failed?
> > > My next move was to try to (optionally) 'require' twice, first in an
> > > open verbose mode, then as previously.
> >
> > What did you think that would do?
>
> I thought the first pass would populate the symbol table with
> everything useful plus extra symbols I didn't want. It would give me
> the useful errors and warnings I was lacking, without spurious extra
> ones which obviously didn't affect the behavior.
> I would throw away the whole result and the second pass would do as it
> had always done, and whatever this is.
> Now, as told, I noticed that I failed to 'throw away the whole
> result', and that the first pass affected the second.
Yes. In general it's impossible to (reliably) undo the effects of
requiring a file, except by forking (a thread or a process) beforehand
and performing the load in the child. While you might *guess* that the
file will put some symbols in a particular symbol table, and you know
(well, you do now I've told you :) ) it will put an entry in %INC, it
may well do all sorts of other things. Usually, if you get to the point
of trying to reload a file it means you've done something wrong, and you
need to step back and rethink your approach a bit.
> > > This led to the next error: 'use vars', in the sub-modules, was
> > > evaluated only once, the first time.
>
> > If you require the same file twice, without clearing the %INC entry, the
> > second time will do nothing. This is (pretty-much) the whole point of
> > require.
>
> OK. I could clean up %INC. Thanks.
> Er... Was that a recommendation?
Not exactly, no.
You still haven't explained what you are trying to accomplish here that
a simple
eval "require $mod; 1;" or die "can't load $mod: $@";
won't do for you. You also haven't explained why subs are being
redefined when you load one of these modules. Where does the first
definition come from? Why is it OK to replace it, and why was it there
in the first place?
Ben
------------------------------
Date: Tue, 22 May 2012 17:03:47 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with install from CPAN
Message-Id: <30qs89-oj22.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
>
> t/00compile.t (Wstat: 189 Tests: 0 Failed: 0)
> Non-zero wait status: 189
> Parse errors: No plan found in TAP output
> t/arch_check.t (Wstat: 190 Tests: 0 Failed: 0)
> Non-zero wait status: 190
> Parse errors: No plan found in TAP output
> t/backwards.t (Wstat: 191 Tests: 0 Failed: 0)
> Non-zero wait status: 191
> Parse errors: No plan found in TAP output
> t/basic.t (Wstat: 192 Tests: 0 Failed: 0)
OK, now that's really suspicious. Since (I assume) most of those test
scripts are actually passing, Wstat should be 0 every time; the
incrementing value makes me think something has gone badly wrong with
the process-invocation machinery.
I suspect at this point that either your perl binaries or your EMX (or
whatever it's called) installation are seriously broken. Are you sure
you installed everything right? Are there any environment variables you
need to set? Is perl using the right shell (I don't know what the right
shell is under OS/2, but I understand it isn't cmd.exe)?
If you run
perl -E"say system q!perl -e1! for 1..3"
what do you get? (You should get 3 lines saying '0'.)
Ben
------------------------------
Date: Tue, 22 May 2012 16:46:40 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-8V4UHPyircdW@localhost>
On Tue, 22 May 2012 16:03:47 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> OK, now that's really suspicious. Since (I assume) most of those test
> scripts are actually passing, Wstat should be 0 every time; the
> incrementing value makes me think something has gone badly wrong with
> the process-invocation machinery.
>
> I suspect at this point that either your perl binaries or your EMX (or
> whatever it's called) installation are seriously broken. Are you sure
> you installed everything right? Are there any environment variables you
> need to set? Is perl using the right shell (I don't know what the right
> shell is under OS/2, but I understand it isn't cmd.exe)?
It's not EMX as such anymore even us dinosaur move forward :-) Some of
us do have our suspicions about our current libc though. perl 5.8.2
runs more or less OK in doing CPAN as long as there is no compile
involved it usually works - Compile problems because of mis matched
paths between how the binary was built and what I have. So that
eliminates environment variables. The only difference in the setup is
perl 5.8.2 gets PERLLIB_PREFIX correct whilst 5.14 truncates the
paths. When it does the substitution it truncates the modifed path to
the length of the original. We have not tracked down why as the code
in that area does not appear to have changed from 5.10 which worked.
We suspect the issue is the significant rewrite to S_incpush in
perl.c. Near line 4432 we have
libdir = newSVpvn(PERLLIB_MANGLE(dir, len), len);
If we are reading the code right, this will do the substitution and
create a new string chopping it off at the old length. What I don't
understand is why 5.10.0 and older versions seem to work correctly
since the code is similar.
>
> If you run
>
> perl -E"say system q!perl -e1! for 1..3"
>
> what do you get? (You should get 3 lines saying '0'.)
0
0
0
--
Regards
Dave Saville
------------------------------
Date: Tue, 22 May 2012 18:45:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with install from CPAN
Message-Id: <4vvs89-dfh1.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Tue, 22 May 2012 16:03:47 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > OK, now that's really suspicious. Since (I assume) most of those test
> > scripts are actually passing, Wstat should be 0 every time; the
> > incrementing value makes me think something has gone badly wrong with
> > the process-invocation machinery.
> >
> > I suspect at this point that either your perl binaries or your EMX (or
> > whatever it's called) installation are seriously broken. Are you sure
> > you installed everything right? Are there any environment variables you
> > need to set? Is perl using the right shell (I don't know what the right
> > shell is under OS/2, but I understand it isn't cmd.exe)?
>
> It's not EMX as such anymore even us dinosaur move forward :-) Some of
> us do have our suspicions about our current libc though. perl 5.8.2
> runs more or less OK in doing CPAN as long as there is no compile
> involved it usually works - Compile problems because of mis matched
> paths between how the binary was built and what I have. So that
> eliminates environment variables.
Does it? Are you sure you have PERL_SH_DIR set correctly?
> The only difference in the setup is
> perl 5.8.2 gets PERLLIB_PREFIX correct whilst 5.14 truncates the
> paths. When it does the substitution it truncates the modifed path to
> the length of the original. We have not tracked down why as the code
> in that area does not appear to have changed from 5.10 which worked.
> We suspect the issue is the significant rewrite to S_incpush in
> perl.c. Near line 4432 we have
>
> libdir = newSVpvn(PERLLIB_MANGLE(dir, len), len);
>
> If we are reading the code right, this will do the substitution and
> create a new string chopping it off at the old length. What I don't
> understand is why 5.10.0 and older versions seem to work correctly
> since the code is similar.
In 5.10.0 the code says
if ( usesep && (s = strchr(p, PERLLIB_SEP)) != NULL ) {
sv_setpvn(libdir, PERLLIB_MANGLE(p, (STRLEN)(s - p)),
(STRLEN)(s - p));
p = s + 1;
}
else {
sv_setpv(libdir, PERLLIB_MANGLE(p, 0));
p = NULL; /* break out */
}
whereas in 5.14.2 it omits the 'usesep' condition, and only has
if (len) {
/* I am not convinced that this is valid when PERLLIB_MANGLE is
defined to so something (in os2/os2.c), but the code has been
this way, ignoring any possible changed of length, since
760ac839baf413929cd31cc32ffd6dba6b781a81 (5.003_02) so I'll leave
it be. */
libdir = newSVpvn(PERLLIB_MANGLE(dir, len), len);
} else {
libdir = newSVpv(PERLLIB_MANGLE(dir, 0), 0);
}
I don't know under what circumstances 'usesep' is supposed to be set,
but maybe taking the second branch prevents the truncation? The
implementation of PERLLIB_MANGLE is, um, scary; it appears to keep a
record of the old length in a global, for some reason I can't quite
follow.
This doesn't help unless you can rebuild perl, of course.
> > If you run
> >
> > perl -E"say system q!perl -e1! for 1..3"
> >
> > what do you get? (You should get 3 lines saying '0'.)
>
> 0
> 0
> 0
OK, so *something*'s working right. That's encouraging; but I'm not sure
where to go next...
If you're having problems with compiled-in paths being remapped badly,
is $^X working right?
perl -E'say $^X'
should print a valid path to perl; ideally it would be the full path,
but perl doesn't know how to find that on all OSes. If it's wrong you
should be able to set HARNESS_PERL in the environment to override it
(though other things may well break too).
Ben
------------------------------
Date: Tue, 22 May 2012 19:52:15 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-pDHVCuw0jJfm@localhost>
On Tue, 22 May 2012 17:45:40 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
>Are you sure you have PERL_SH_DIR set correctly?
>
Poking into the build environment I found that sh was actually a copy
of ash. I tried with my own systems sh but it makes no difference.
<snip>
doesn't help unless you can rebuild perl, of course.
Passed to our porter
> > > If you run
> > >
> > > perl -E"say system q!perl -e1! for 1..3"
> > >
> > > what do you get? (You should get 3 lines saying '0'.)
> >
> > 0
> > 0
> > 0
>
> OK, so *something*'s working right. That's encouraging; but I'm not sure
> where to go next...
>
> If you're having problems with compiled-in paths being remapped badly,
> is $^X working right?
>
> perl -E'say $^X'
>
> should print a valid path to perl; ideally it would be the full path,
> but perl doesn't know how to find that on all OSes. If it's wrong you
> should be able to set HARNESS_PERL in the environment to override it
> (though other things may well break too).
>
>
That prints correct full path.
--
Regards
Dave Saville
------------------------------
Date: Tue, 22 May 2012 22:19:42 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Objective C (OT)
Message-Id: <slrnjrnt6v.n13.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-20 02:45, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <slrnjrd2vm.jql.hjp-usenet2@hrunkner.hjp.at>, on 05/18/2012
> at 07:50 PM, "Peter J. Holzer" <hjp-usenet2@hjp.at> said:
>
>>I do think that C is just low-level enough that by comparing the
>>C source code and the generated machine code you can get a
>>"feeling" for common high-level language constructs are
>>translated into machine code.
>
> That will only give you a feel for how a particular compiler
> translates C constructs into machine code.
The context was "learning C". You don't learn C by only observing what a
particular compiler does - C has lots and lots of implementation-
defined, unspecified and undefined behaviour. If you really learn C[1],
you learn that almost any feature can be implemented differently.
So by examining the output from your C compiler you may find that it
evaluates arguments for functions from right to left, pushing each on
the stack immediately. But the C standard (and every textbook worth its
salt) tells you that the order is unspecified[2], so you start thinking
about other ways a compiler could implement this (e.g., evaluate from
left to right but push in reverse order, evaluate from left to right and
pass an argument count, pass the first n arguments in registers, do
it differently for functions with a fixed number of arguments and
functions with a variable number of arguments, ...) and why it was
implemented in this specific way.
Of course it helps if you actually have access to different compilers
and different architectures. As I said, I already knew a bit of 6502 and
Z80 assembler (and machine code - those were the days of PEEK and
POKE). I first learned programming C on an 8086 and at the university I
had access to a VAX. And I discovered comp.lang.c, where lots of very
knowledgeable people (among them Henry Spencer, Doug Gwyn and Chris
Torek) were quick to disabuse you of any superstitions you may have
aquired by lack of experience.
> It won't give you a feel for, e.g., the architecture, translations of
> constructs in other languages,
Yes, it does. "A feel" is not the same as knowledge. But if you have
seen what a C compiler does you do have a feel for what a compiler in a
similar imperative language might do.
> instructions generated only from assembler code.
True, but mostly irrelevant in this context. Very little code today is
hand-crafted in assembler, so "what is actually executed at machine code
level" (as you wrote in an earlier posting) is usually generated by a
compiler. And you don't have to understand every detail to get "a sense"
or "a feel".
>>As an introductory language, "Processing"[1] might be a good choice.
>
> Probably kinder than what they did to us, which was to teach us
> machine language before introducing the concept of an assembler :-(
Helmut Schauer did that in his excellent "Introduction to CS" course at
the TU Vienna in the mid-1980's. And he introduced microcode before
machine code, adders before microcode, nand and nor gates before adders,
transistors before gates, and semiconductors before transistors. The
bottom-up approach makes sense, as does the historical approach (teach
concepts in the order they were invented). At least for a university
course. If you want to teach a bit of programming to a kid, you probably
should take a different approach.
hp
[1] You can't do that in 21 days. See http://www.norvig.com/21-days.html
[2] I think its unspecified, not undefined or implementation-defined.
Too lazy to look it up, and it doesn't make a difference here.
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Tue, 22 May 2012 16:54:17 +0000 (UTC)
From: Mike <mikee@mac.com>
Subject: OT: How to calculate reputation scores?
Message-Id: <jpggbp$tj2$2@dont-email.me>
A general question, not PERL releated:
Many web sites have an article/message/user reputation based on the up or
down votes the article/message/user receives. How is a reputation score
calculated given only up and down votes? (The user is not presented with
a 1 to 5 scale for scoring something.)
Mike
------------------------------
Date: Tue, 22 May 2012 11:52:19 -0700 (PDT)
From: Dilbert <dilbert1999@gmail.com>
Subject: Strawberry Perl 5.16 rocks
Message-Id: <8e304d8e-14f2-46fe-bd73-e5a1262cd66c@em1g2000vbb.googlegroups.com>
> On 24 mai, 17:56, Dilbert <dilbert1...@gmail.com> wrote:
> looking at http://strawberryperl.com/,
> it now displays "Stop Press! Perl 5.14 preview release available now!"
> The wait is over :-)
looking at http://strawberryperl.com/,
it now displays...
Download Strawberry Perl 5.16.0.1 (32bit)
Download Strawberry Perl 5.16.0.1 (64bit)
I didn't even have to wait :-)
------------------------------
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 3698
***************************************
