[32513] in Perl-Users-Digest
Perl-Users Digest, Issue: 3778 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 16 14:09:18 2012
Date: Sun, 16 Sep 2012 11:09: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 Sun, 16 Sep 2012 Volume: 11 Number: 3778
Today's topics:
config.h makefile error when installing MakeMaker <sunil@equityoms.com>
Re: config.h makefile error when installing MakeMaker <ben@morrow.me.uk>
Re: config.h makefile error when installing MakeMaker <rweikusat@mssgmbh.com>
Re: config.h makefile error when installing MakeMaker <rweikusat@mssgmbh.com>
Re: config.h makefile error when installing MakeMaker <dave@invalid.invalid>
Re: config.h makefile error when installing MakeMaker <rweikusat@mssgmbh.com>
Finding repositories <bernie@fantasyfarm.com>
Re: Finding repositories <ben@morrow.me.uk>
Re: hash of arrays <jimsgibson@gmail.com>
Iconmask, Icon, Inline dgoodmaniii@gmail.com
Re: Two remarks about the Perl object model <c182driver9@gideon.org>
warning about pipe-to-self opens <rweikusat@mssgmbh.com>
Re: warning about pipe-to-self opens <ben@morrow.me.uk>
wrapper script calling anotherr script <bjlockie@lockie.ca>
Re: wrapper script calling anotherr script <*@eli.users.panix.com>
Re: wrapper script calling anotherr script <bjlockie@lockie.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Sep 2012 05:42:42 -0700 (PDT)
From: technog <sunil@equityoms.com>
Subject: config.h makefile error when installing MakeMaker
Message-Id: <9d10ecad-3eb7-4fa3-9d23-36192dcf7f1c@googlegroups.com>
Using Fedora 17 and perl v5.14.2
Initially trying to install the lwp::Simple package, which brought up dependencies.
Now trying to install MakeMaker but get the following error re. config.h
Please see the last line below.
The path doesnt exist and I dont have config.h in any of the downloaded modules.
If this file is created on the fly, as the error would indicate, then the following line in the makefile has the path not setup correctly ??
CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h
* output of the make command *
# perl Makefile.PL
Using included version of version (0.88) because it is not already installed.
Using included version of JSON::PP (2.27104) because it is not already installed.
Using included version of Parse::CPAN::Meta (1.4401) because it is not already installed.
Using included version of CPAN::Meta (2.112150) because it is not already installed.
Using included version of CPAN::Meta::YAML (0.003) because it is not already installed.
Using included version of ExtUtils::Manifest (1.58) because it is not already installed.
Using included version of ExtUtils::Install (1.52) because it is not already installed.
Using included version of File::Copy::Recursive (0.38) because it is not already installed.
Using included version of JSON::PP::Compat5006 (1.09) because it is not already installed.
Using included version of Version::Requirements (0.101020) because it is not already installed.
Checking if your kit is complete...
Looks good
Writing Makefile for ExtUtils::MakeMaker
Writing MYMETA.yml and MYMETA.json
ExtUtils-MakeMaker-6.62]# make
make: *** No rule to make target `/usr/lib64/perl5/CORE/config.h', needed by `Makefile'. Stop.
------------------------------
Date: Fri, 14 Sep 2012 13:58:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: config.h makefile error when installing MakeMaker
Message-Id: <e8mbi9-dih.ln1@anubis.morrow.me.uk>
Quoth technog <sunil@equityoms.com>:
> Using Fedora 17 and perl v5.14.2
>
> Initially trying to install the lwp::Simple package, which brought up
> dependencies.
> Now trying to install MakeMaker but get the following error re. config.h
> Please see the last line below.
> The path doesnt exist and I dont have config.h in any of the downloaded modules.
> If this file is created on the fly, as the error would indicate, then
> the following line in the makefile has the path not setup correctly ??
> CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h
>
<snip>
> ExtUtils-MakeMaker-6.62]# make
> make: *** No rule to make target `/usr/lib64/perl5/CORE/config.h',
> needed by `Makefile'. Stop.
That file *should* exist: it's part of the core perl installation.
Probably your vendor has split the perl distribution into several
packages in a vain effort to save a minute amount of disk space; you
need to find and install all the packages that get built from the
perl-5.14.2 tarball.
Another thing to bear in mind is that installing CPAN modules by hand
(or with the CPAN client) against a package-managed perl is often a very
bad idea, since you end up stamping on package-managed files. I'm quite
certain your vendor provides a LWP::Simple package, so why aren't you
just installing that?
Ben
------------------------------
Date: Fri, 14 Sep 2012 16:36:21 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: config.h makefile error when installing MakeMaker
Message-Id: <878vccmxai.fsf@sapphire.mobileactivedefense.com>
technog <sunil@equityoms.com> writes:
> Using Fedora 17 and perl v5.14.2
>
> Initially trying to install the lwp::Simple package,
[...]
> make: *** No rule to make target `/usr/lib64/perl5/CORE/config.h',
> needed by `Makefile'. Stop.
According to http://fedoraproject.org/wiki/Perl, including header
files in a 'main' package is 'prohibited'. What this precisely means
and how the 'Perl development package' Fedora probably provides is
named cannot be determined within some at least reasonable time on the
web. You might want to consider switching to distribution focused on
being usable instead marketable ...
------------------------------
Date: Fri, 14 Sep 2012 16:39:02 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: config.h makefile error when installing MakeMaker
Message-Id: <874nn0mx61.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> Another thing to bear in mind is that installing CPAN modules by hand
> (or with the CPAN client) against a package-managed perl is often a very
> bad idea, since you end up stamping on package-managed files.
It shouldn't, at least not at the moment: By default, CPAN modules
install themselves in /usr/local and while this may affect 'the
distribution' insofar as it might cause some distribution-provided
Perl code which tested with version x.y of some Perl module to use a
different module, it won't interfere with the distribution package
management.
------------------------------
Date: Fri, 14 Sep 2012 16:39:50 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: config.h makefile error when installing MakeMaker
Message-Id: <fV45K0OBJxbE-pn2-WhMdRK64fUUy@localhost>
On Fri, 14 Sep 2012 15:36:21 UTC, Rainer Weikusat
<rweikusat@mssgmbh.com> wrote:
> technog <sunil@equityoms.com> writes:
> > Using Fedora 17 and perl v5.14.2
> >
> > Initially trying to install the lwp::Simple package,
>
> [...]
>
> > make: *** No rule to make target `/usr/lib64/perl5/CORE/config.h',
> > needed by `Makefile'. Stop.
>
> According to http://fedoraproject.org/wiki/Perl, including header
> files in a 'main' package is 'prohibited'. What this precisely means
> and how the 'Perl development package' Fedora probably provides is
> named cannot be determined within some at least reasonable time on the
> web. You might want to consider switching to distribution focused on
> being usable instead marketable ...
So you would suggest?
--
Regards
Dave Saville
------------------------------
Date: Fri, 14 Sep 2012 17:58:26 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: config.h makefile error when installing MakeMaker
Message-Id: <87a9wslex9.fsf@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> On Fri, 14 Sep 2012 15:36:21 UTC, Rainer Weikusat
> <rweikusat@mssgmbh.com> wrote:
>
>> technog <sunil@equityoms.com> writes:
>> > Using Fedora 17 and perl v5.14.2
>> >
>> > Initially trying to install the lwp::Simple package,
>>
>> [...]
>>
>> > make: *** No rule to make target `/usr/lib64/perl5/CORE/config.h',
>> > needed by `Makefile'. Stop.
>>
>> According to http://fedoraproject.org/wiki/Perl, including header
>> files in a 'main' package is 'prohibited'. What this precisely means
>> and how the 'Perl development package' Fedora probably provides is
>> named cannot be determined within some at least reasonable time on the
>> web. You might want to consider switching to distribution focused on
>> being usable instead marketable ...
>
> So you would suggest?
Any project which is capable of putting its package database online
with an interface suitable for finding something which actually
works. Eg, you can go to this page
http://www.debian.org/distrib/packages
type 'perl' into the 'Search package directories' input box, select
'Source package names' and search for it which will end on this page
http://packages.debian.org/search?keywords=perl&searchon=sourcenames&suite=stable§ion=all
and clicking on the squeeze link will lead to a page which documents
the Debian packages created from the perl source distribution:
http://packages.debian.org/source/squeeze/perl
Something similar may be available for Fedora but not by clicking on
something obvious (such as 'Debian packages') on the Fedora
homepage. But they have a bunch of 'customer testimonials' and other
'feelgood' stuff :->.
------------------------------
Date: Thu, 13 Sep 2012 17:09:21 -0400
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Finding repositories
Message-Id: <4mi458tq8d0g6nb2n2clm1q753vm5ssfbt@library.airnews.net>
I'm using Activestate perl and is there some general way [via google? via
CPAN?] to locate a repository for a module that the Activestate repository
doesn't have?
Thanks! /bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Thu, 13 Sep 2012 23:17:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Finding repositories
Message-Id: <ll2ai9-vf8.ln1@anubis.morrow.me.uk>
Quoth Bernie Cosell <bernie@fantasyfarm.com>:
> I'm using Activestate perl and is there some general way [via google? via
> CPAN?] to locate a repository for a module that the Activestate repository
> doesn't have?
Not as far as I know, but see
http://win32.perl.org/wiki/index.php?title=PPM_Repositories .
My general advice to Win32 users is to switch to Strawberry Perl and a
real CPAN client.
Ben
------------------------------
Date: Thu, 13 Sep 2012 09:59:06 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: hash of arrays
Message-Id: <130920120959068016%jimsgibson@gmail.com>
In article <a554e6ff-8d52-46ee-b97b-7cb1edaf8ab1@googlegroups.com>,
removeps groups <removeps-groups@yahoo.com> wrote:
> My perl script reads lines of a file, or rows of a database...
> To model this data structure in perl I had to do stuff like the following,
> which works on Strawberry Perl and Linux Perl:
>
> my %data; # map of id to [ Name, ArrayOfInt, ArrayOfInt ]
> my $value = $data{$id};
> my @tmpvalue = ($name, [], []);
> $value = \@tmpvalue;
> $data{$id} = $value;
> push(@{$$value[1]}, $firstInt);
>
> I don't know why the particular combination of $ @ {} \ works, but it does.
> Questions are:
>
> (1) Is this the most efficient way?
The data structure is efficient, but you have some unnecessary
assignment operations in the code above. For example, you assign to the
variable $value twice, without using the first value.
> (2) Why does it work?
Because of Perl's dereferencing and precedence rules. If you want a
more detailed explanation, you need to specify more exactly what "it"
is.
I find the expression @{$$value[1]} somewhat ambiguous and difficult to
parse.
$value is a reference to an array. $value->[0] would be the first
element of that array, as would ${$value}[0].
$$value[1] could be interpreted as either ${$value[1]} or ${$value}[1],
depending upon Perl's precedence rules. The former is dereferencing the
second element of the @value array. The latter is the second element of
the anonymous array referenced by the scalar $value. Since
dereferencing a scalar has highest precedence, Perl will do the latter.
If you don't want to learn Perl's precedence rules, then just use the
arrow notation and explicit braces ({}). That is what I do.
push( @{ $data{$id}->[1] }, $firstInt );
From the inside out:
1. %data is a hash
2. $id is a key for that $hash
3. $data{$id} is the value associated with that key, a reference to an
anonymous array.
4. $data{$id}->[1] is the second element of that array, a reference to
another anonymous array
5. @{$data{$id}->[1]} is that anonymous array
6. push( ${$data{$id}->[1]}, $firstInt ) is pushing the value from
$firstInt onto the end of that array.
>
> The full script is below
>
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my %data; # map of id to [ Name, ArrayOfInt, ArrayOfInt ]
>
> open sqlData, "hash-rows.txt" || die $!;
>
> while (<sqlData>)
> {
> chomp $_;
> my @row = split '\t', $_;
>
> my $id = $row[0];
> my $name = $row[1];
> my $firstInt = $row[2];
> my $secondInt = $row[3];
You can also use:
my( $id, $name, $firstInt, $secondInt ) = split '\t', $_;
or just
my( $id, $name, $firstInt, $secondInt ) = split;
>
> my $value = $data{$id};
> if (not defined $value)
It is better to use the exists function for testing hashes for the
presence of a key,value pair.
> {
> my @tmpvalue = ($name, [], []);
> $value = \@tmpvalue;
> $data{$id} = $value;
You can replace the 3 lines above with:
$data{$id} = [ $name, [], [] ];
> }
> push(@{$$value[1]}, $firstInt);
push( @{$value->[1]}, $firstInt );
> push(@{$$value[2]}, $secondInt);
push( @{$value->[2]}, $secondInt );
> }
>
> foreach my $id (keys %data)
> {
> my $value = $data{$id};
> my $name = $$value[0];
my $name = $value->[0];
etc.
> my @firstInts = @{$$value[1]};
> my @secondInts = @{$$value[2]};
> print "ENTRY\n id=$id\n name=$name\n firstInts=(@firstInts)\n
> secondInts=(@secondInts)\n";
> }
>
>
> ENTRY
> id=1
> name=First
> firstInts=(Id Id)
> secondInts=(2 2)
> ENTRY
> id=2
> name=Second
> firstInts=(Id)
> secondInts=(3)
>
--
Jim Gibson
------------------------------
Date: Sun, 16 Sep 2012 00:19:43 +0000 (UTC)
From: dgoodmaniii@gmail.com
Subject: Iconmask, Icon, Inline
Message-Id: <k335uu$ss1$1@dont-email.me>
I tried posting this on comp.lang.perl.tk, but haven't
gotten an answer for a week or so, so I thought I'd try
here.
I'm developing a perl/tk frontend for a small C application
I wrote (an infix frontend for a command-line postfix
calculator), and I want to distribute the perl/tk as a
standalone file without having to package it with the images
it includes.
So I converted the image to xbm, then read it into the perl
source file, assigning it to a variable like so:
my $icondata = qq(*contents of xbm file*);
my $iconmaskdata = qq(*contents of mask file, also xbm*);
I then attempt to use the icon and iconmask methods, like
so:
my $icon = $mw->Bitmap(-data=>$icondata);
my $iconmask = $mw->Bitmap(-data=>$iconmaskdata);
$mw->iconimage($icon);
$mw->iconmask($iconmask);
The "icon" works; I got the blob of black due to the
transparency not working as expected. But execution fails
with the iconmask statement included; I get the following
error:
bitmap "image1" not defined at /usr/lib/perl5/Tk/Submethods.pm line 37.
Checking line 37 of that file didn't elucidate things for
me. When I print the value of $iconmask, I get
"Tk::Bitmap=HASH(0x943ef58)", which is the same sort of
thing I get for $icon.
Using the file I imported into $iconmaskdata with
"$mw->iconmask('@logo_shapes_mask.xbm');" works perfectly
as expected, even when the icon is still the imported
variable rather than the file.
Can anyone tell me why "$mw->iconimage($icon)" works but
"$mw->iconmask($iconmask)" doesn't, when I'm using the
identical assignments for each?
Also, why does using the mask file directly work, while
using the identical data in a variable not work?
------------------------------
Date: Sat, 15 Sep 2012 22:16:07 GMT
From: Andrew Gideon <c182driver9@gideon.org>
Subject: Re: Two remarks about the Perl object model
Message-Id: <H675s.11000$my2.1976@fe27.iad>
On Wed, 22 Aug 2012 22:30:43 +0100, Rainer Weikusat wrote:
> This implies that, in order to derive a class from some
> other class, knowledge about the implementation of all ancestors of the
> new class is required because a suitable order and mechanism to cause
> superclass destructors to be executed needs to be worked out.
I'm not sure that this implication is correct. The author of a given
class must be sure that that class is correct. He or she can decide
whether or not to propagate the destructor call to the immediate super
classes.
Those class authors, in turn, are responsible for assuring that their
destructors do the proper thing (to propagate or not to propagate; that
is the question {8^).
- Andrew
------------------------------
Date: Fri, 14 Sep 2012 23:25:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: warning about pipe-to-self opens
Message-Id: <87obl82qf6.fsf@sapphire.mobileactivedefense.com>
At least on perl 5.10.1, in contradiction to the documentation which
states
Use "defined($pid)" to determine whether the open was
successful.
when the implicit fork done by open($fh, '|-') or open($fh, '-|')
fails for another reason than EAGAIN, the Perl interpreter executes
Perl_croak with "Can't fork" as argument. Because of this, code which
is supposed to handle 'pipe-to-self' open errors needs to check the
return value and the invocation has to be wrapped in an eval {} so
that the process doesn't die because of this uncaught exception
(problem observed on Linux at a really inconvenient time :-).
------------------------------
Date: Sat, 15 Sep 2012 00:02:28 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: warning about pipe-to-self opens
Message-Id: <4lpci9-p55.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> At least on perl 5.10.1, in contradiction to the documentation which
> states
>
> Use "defined($pid)" to determine whether the open was
> successful.
>
> when the implicit fork done by open($fh, '|-') or open($fh, '-|')
> fails for another reason than EAGAIN, the Perl interpreter executes
> Perl_croak with "Can't fork" as argument. Because of this, code which
> is supposed to handle 'pipe-to-self' open errors needs to check the
> return value and the invocation has to be wrapped in an eval {} so
> that the process doesn't die because of this uncaught exception
> (problem observed on Linux at a really inconvenient time :-).
Wow, that bit of code's been there a long time: since perl 3, 18 Oct
1989. It would probably be helpful if you sent a doc patch to p5p.
For others' benefit: if that fork fails with EAGAIN, perl will warn,
sleep for 5 seconds, and retry. It will keep doing this indefinitely,
until it succeeds or fails with a different error. Since fork(2) fails
with EAGAIN when the current process's NPROC rlimit has been reached, a
robust program should probably also set an alarm, or just handle the
fork/dup/exec manually. Alternatively, making 'pipe' warnings fatal will
allow you to catch the error and implement some alternative retry
strategy.
Ben
------------------------------
Date: Fri, 14 Sep 2012 22:16:13 -0700 (PDT)
From: bjlockie <bjlockie@lockie.ca>
Subject: wrapper script calling anotherr script
Message-Id: <098d3448-cda8-4388-bef3-e57a4395cc64@googlegroups.com>
I want to create a wrapper script (testa.pl) that defines variables (like $b) and can execute another perl program (testb.pl) that can access those variables.
I tried:
$ testa.pl 'testb.pl' but it didn't work.
I don't think eval is what I need but 'use' doesn't work on variables.
::::::::::::::
testa.pl
::::::::::::::
#!/usr/bin/perl -w
#use strict;
use warnings;
my $realScript = $ARGV[0];
(defined($realScript)) or die "Must specify a script\n";
print "This is $0\n";
my $b = 10;
eval $realScript;
print $@;
::::::::::::::
testb.pl
::::::::::::::
#!/usr/bin/perl -w
use strict;
use warnings;
print "This is $0, b=$b (should be 10)\n";
------------------------------
Date: Sat, 15 Sep 2012 05:24:13 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: wrapper script calling anotherr script
Message-Id: <eli$1209150121@qz.little-neck.ny.us>
In comp.lang.perl.misc, bjlockie <bjlockie@lockie.ca> wrote:
> I want to create a wrapper script (testa.pl) that defines variables
> (like $b) and can execute another perl program (testb.pl) that can
> access those variables.
It's a strange thing to want to do, but Perl knows how to do this.
You want to use "do".
:r! cat /tmp/a
use vars qw( $a $b );
$a = 10;
$b = '/tmp/b';
if (-f $b) {
do $b;
}
__END__
:r! cat /tmp/b
print "This is $b where \$a is $a.\n";
__END__
:r! perl /tmp/a
This is /tmp/b where $a is 10.
Elijah
------
has used "do" to instantly hack-in config file support
------------------------------
Date: Sat, 15 Sep 2012 11:27:11 -0700 (PDT)
From: bjlockie <bjlockie@lockie.ca>
Subject: Re: wrapper script calling anotherr script
Message-Id: <5dd05d5a-4df0-4e80-aef1-f7c463d7cb37@googlegroups.com>
On Saturday, September 15, 2012 1:24:13 AM UTC-4, Eli the Bearded wrote:
> In comp.lang.perl.misc, bjlockie <bjlockie@lockie.ca> wrote:
>
> > I want to create a wrapper script (testa.pl) that defines variables
>
> > (like $b) and can execute another perl program (testb.pl) that can
>
> > access those variables.
>
>
>
> It's a strange thing to want to do, but Perl knows how to do this.
>
> You want to use "do".
I am using someone else's scripts that each have config data by using 'use configa'.
There is 'configb', 'configc', etc.
The current way of changing the config is to modifiy each 'use' in all the scripts.
With the wrapper, I can have the 'use configx' in one place and use 'do' to call the other scripts.
------------------------------
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 3778
***************************************
