[32787] in Perl-Users-Digest
Perl-Users Digest, Issue: 4051 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Oct 8 16:09:32 2013
Date: Tue, 8 Oct 2013 13:09:04 -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, 8 Oct 2013 Volume: 11 Number: 4051
Today's topics:
Any difference between ref to hash and ref to anonymous <justin.1303@purestblue.com>
Re: Any difference between ref to hash and ref to anony <ben@morrow.me.uk>
Re: Any difference between ref to hash and ref to anony <justin.1303@purestblue.com>
Re: mixed cmp operator for sorting <jwkrahn@example.com>
Re: multiple codepages <rweikusat@mobileactivedefense.com>
Re: multiple codepages <hhr-m@web.de>
Re: multiple codepages <ben@morrow.me.uk>
Re: multiple codepages <rweikusat@mobileactivedefense.com>
Re: multiple codepages <rweikusat@mobileactivedefense.com>
Re: multiple codepages <ben@morrow.me.uk>
Re: multiple codepages <derykus@gmail.com>
Re: multiple codepages <rweikusat@mobileactivedefense.com>
Re: multiple codepages <derykus@gmail.com>
Re: multiple codepages <rweikusat@mobileactivedefense.com>
Re: perl hash utilities <Cal@example.invalid>
Re: perl hash utilities <jwkrahn@example.com>
Re: three computing drawbacks me@at.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 7 Oct 2013 09:50:31 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: Any difference between ref to hash and ref to anonymous hash?
Message-Id: <n79aia-sak.ln1@zem.masonsmusic.co.uk>
Sometimes I do this:
sub foo {
my %h = (
k1 => 1,
k2 => 2,
);
return \%h;
}
Other times I do this:
sub bar {
my $h = {
k1 => 1,
k2 => 2,
};
return $h;
}
Is there any difference between $x and $y if I:
my $x = foo();
my $y = bar();
Using YAML qw/Dump/ says not, but is there anything I should be aware
of when using either form? Is there a "best practice" that says use
one of them over the other?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 7 Oct 2013 12:49:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Any difference between ref to hash and ref to anonymous hash?
Message-Id: <nmjaia-7li.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1303@purestblue.com>:
>
> Sometimes I do this:
> sub foo {
> my %h = (
> k1 => 1,
> k2 => 2,
> );
> return \%h;
> }
>
> Other times I do this:
> sub bar {
> my $h = {
> k1 => 1,
> k2 => 2,
> };
> return $h;
> }
>
> Is there any difference between $x and $y if I:
> my $x = foo();
> my $y = bar();
No.
Ben
------------------------------
Date: Mon, 7 Oct 2013 16:00:43 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: Re: Any difference between ref to hash and ref to anonymous hash?
Message-Id: <rtuaia-opu.ln1@zem.masonsmusic.co.uk>
On 2013-10-07, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1303@purestblue.com>:
[snip]
>>
>> Is there any difference between $x and $y if I:
>> my $x = foo();
>> my $y = bar();
>
> No.
>
> Ben
Nice and concise. Thank you, Ben.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Tue, 08 Oct 2013 12:09:39 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <TLY4u.27011$Y95.16622@fx31.iad>
Willem wrote:
> Marc Girod wrote:
> ) On Monday, 23 September 2013 08:30:46 UTC+1, John W. Krahn wrote:
> )
> )> my @t = $a =~ /\D+|\d+/g;
> )> my @s = $b =~ /\D+|\d+/g;
> )>
> )> Avoids zero length strings.
> )
> ) Indeed, but it implies other changes in the following.
>
> my @t = split /(\d+)/, $a;
> my @s = split /(\d+)/, $a;
>
> Avoids both issues.
$ perl -le'use Data::Dumper; my $a = "12345"; my @t = split /(\d+)/, $a;
print Dumper \@t'
$VAR1 = [
'',
'12345'
];
Not, it appears, zero length strings.
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Sun, 06 Oct 2013 16:12:11 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87siweigc4.fsf@sable.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Sat, 5 Oct 2013, George Mpouras wrote:
>
>> Στις 4/10/2013 11:02, ο/η Helmut Richter έγραψε:
>
>> > I have a tool that translates a mixture of UTF-8 and *one* codepage into
>> > pure UTF-8 (under the assumption that a valid UTF-8 byte sequence is
>> > indeed meant as an UTF-8 character). But if more than one 8-bit code is
>> > involved, you have to do some hand massage before or after.
>
>> I would love to have a look if you can
>
> I have made it available as http://hhr-m.userweb.mwn.de/tmp/repcode.txt
>
> When you call it with option -h, it displays a long help text explaining
> all detail.
>
> (As I learnt perl decades ago, the coding style may be a bit old-fashioned
> but I tried to make it clean.)
The entity_value subroutine uses a my variable named %cache for storing
translations. Unless I'm missing something, this cannot possibly
accomplish anything useful because the hash only exists while the
subroutine is executed. This should probably be moved to an outer scope
or use a 'state' variable.
------------------------------
Date: Sun, 6 Oct 2013 22:13:57 +0200
From: Helmut Richter <hhr-m@web.de>
Subject: Re: multiple codepages
Message-Id: <alpine.LNX.2.00.1310062205180.7771@badwlrz-clhri01.ws.lrz.de>
On Sun, 6 Oct 2013, Rainer Weikusat wrote:
> The entity_value subroutine uses a my variable named %cache for storing
> translations. Unless I'm missing something, this cannot possibly
> accomplish anything useful because the hash only exists while the
> subroutine is executed. This should probably be moved to an outer scope
> or use a 'state' variable.
I am afraid you are right. The program is old enough that "state" may then
not have existed, and at that time I may have misunderstood "my" to have
only a lexical effect: the variable is inaccessible outside its scope but
continues to exist. Now, I reread the perldoc: it does not say much about
the fate of the variable upon exit from its scope but the mere existence
of a "state" keyword allows one to construe that it must serve a purpose.
As it is just a cache, the function of the program ist not affected, only
its efficiency. Well, I should corrected it.
--
Helmut Richter
------------------------------
Date: Sun, 6 Oct 2013 22:53:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: multiple codepages
Message-Id: <co29ia-j0a.ln1@anubis.morrow.me.uk>
Quoth Helmut Richter <hhr-m@web.de>:
> On Sun, 6 Oct 2013, Rainer Weikusat wrote:
>
> > The entity_value subroutine uses a my variable named %cache for storing
> > translations. Unless I'm missing something, this cannot possibly
> > accomplish anything useful because the hash only exists while the
> > subroutine is executed. This should probably be moved to an outer scope
> > or use a 'state' variable.
>
> I am afraid you are right. The program is old enough that "state" may then
> not have existed, and at that time I may have misunderstood "my" to have
> only a lexical effect: the variable is inaccessible outside its scope but
> continues to exist. Now, I reread the perldoc: it does not say much about
> the fate of the variable upon exit from its scope but the mere existence
> of a "state" keyword allows one to construe that it must serve a purpose.
If you speak C, 'my' is like 'auto' (that is, ordinary local variables
like
int foo ()
{
int bar;
}
) in that each entry to the block where they are declared gets a fresh
copy of the variable. 'state' is like C's 'static': there is only one
copy of the variable, but it is only visible in certain parts of the
program. The nearest equivalent to C's 'extern' is 'our' (or
fully-qualified globals), in that these are the only variables that are
visible across files. (C has particular rules about symbols needing to
be declared 'extern' in most places but defined without 'extern' in one
place only; Perl's 'our' variables are more like Unix C's common
variables, in that they can be created in many places and the
definitions will be merged.)
Ben
------------------------------
Date: Mon, 07 Oct 2013 17:11:34 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87hactdps9.fsf@sable.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Sun, 6 Oct 2013, Rainer Weikusat wrote:
>> The entity_value subroutine uses a my variable named %cache for storing
>> translations. Unless I'm missing something, this cannot possibly
>> accomplish anything useful because the hash only exists while the
>> subroutine is executed. This should probably be moved to an outer scope
>> or use a 'state' variable.
>
> I am afraid you are right. The program is old enough that "state" may then
> not have existed,
[...]
The traditional way to create static, stateful subroutines would be by using
code similar to this:
-----------
{
my $accu;
sub add_something
{
return $accu += $_[0];
}
}
print(add_something(4), "\n");
print(add_something(12), "\n");
-----------
Because nothing except the add_something subroutine exists in the
lexical scope of $accu, it's the only thing which can access it and
because Perl supports closures, it will retain a reference to the $accu
object after the scope which established it has ended.
------------------------------
Date: Mon, 07 Oct 2013 17:15:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87d2nhdplz.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[variable lifetimes]
> The nearest equivalent to C's 'extern' is 'our' (or
> fully-qualified globals), in that these are the only variables that are
> visible across files. (C has particular rules about symbols needing to
> be declared 'extern' in most places but defined without 'extern' in one
> place only; Perl's 'our' variables are more like Unix C's common
> variables, in that they can be created in many places and the
> definitions will be merged.)
This isn't really a good analogy because our doesn't create objects, it
just declares them to be 'intentionally used identifiers in the
namespace of the current package' so that strict 'vars' doesn't complain
about them.
------------------------------
Date: Mon, 7 Oct 2013 22:30:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: multiple codepages
Message-Id: <golbia-99l.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [variable lifetimes]
>
> > The nearest equivalent to C's 'extern' is 'our' (or
> > fully-qualified globals), in that these are the only variables that are
> > visible across files. (C has particular rules about symbols needing to
> > be declared 'extern' in most places but defined without 'extern' in one
> > place only; Perl's 'our' variables are more like Unix C's common
> > variables, in that they can be created in many places and the
> > definitions will be merged.)
>
> This isn't really a good analogy because our doesn't create objects, it
> just declares them to be 'intentionally used identifiers in the
> namespace of the current package' so that strict 'vars' doesn't complain
> about them.
It does, actually, if the global doesn't already exist. I did say the
analogy wasn't as close as for my and state.
Ben
------------------------------
Date: Mon, 07 Oct 2013 14:36:36 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: multiple codepages
Message-Id: <l2v9h9$l5d$1@speranza.aioe.org>
l
On 10/7/2013 9:15 AM, Rainer Weikusat wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [variable lifetimes]
>
>> The nearest equivalent to C's 'extern' is 'our' (or
>> fully-qualified globals), in that these are the only variables that are
>> visible across files. (C has particular rules about symbols needing to
>> be declared 'extern' in most places but defined without 'extern' in one
>> place only; Perl's 'our' variables are more like Unix C's common
>> variables, in that they can be created in many places and the
>> definitions will be merged.)
>
> This isn't really a good analogy because our doesn't create objects, it
> just declares them to be 'intentionally used identifiers in the
> namespace of the current package' so that strict 'vars' doesn't complain
> about them.
>
Wouldn't something like this effectively encapsulate $foo and act as a
closure though:
package main; ...
package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
package main; ...
--
Charles DeRykus
------------------------------
Date: Mon, 07 Oct 2013 23:09:19 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87ob70lomo.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 10/7/2013 9:15 AM, Rainer Weikusat wrote:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> [variable lifetimes]
>>
>>> The nearest equivalent to C's 'extern' is 'our' (or
>>> fully-qualified globals), in that these are the only variables that are
>>> visible across files. (C has particular rules about symbols needing to
>>> be declared 'extern' in most places but defined without 'extern' in one
>>> place only; Perl's 'our' variables are more like Unix C's common
>>> variables, in that they can be created in many places and the
>>> definitions will be merged.)
>>
>> This isn't really a good analogy because our doesn't create objects, it
>> just declares them to be 'intentionally used identifiers in the
>> namespace of the current package' so that strict 'vars' doesn't complain
>> about them.
>>
>
> Wouldn't something like this effectively encapsulate $foo and act as a
> closure though:
>
> package main; ...
> package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
> package main; ...
package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
package main;
$MyFoo::foo = -15;
print MyFoo::add_something(3), "\n";
------------------------------
Date: Tue, 08 Oct 2013 01:18:39 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: multiple codepages
Message-Id: <l30f58$agq$1@speranza.aioe.org>
On 10/7/2013 3:09 PM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 10/7/2013 9:15 AM, Rainer Weikusat wrote:
>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>
>>> [variable lifetimes]
>>>
...
>>
>> Wouldn't something like this effectively encapsulate $foo and act as a
>> closure though:
>>
>> package main; ...
>> package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
>> package main; ...
>
> package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
> package main;
>
> $MyFoo::foo = -15;
> print MyFoo::add_something(3), "\n";
>
I overreached with 'effectively' perhaps but didn't intend that it was
unassailable. A $_foo might have helped. But it's a bit of a stretch to
break it accidentally too.
--
Charles DeRykus
------------------------------
Date: Tue, 08 Oct 2013 12:59:11 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87eh7wm0s0.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 10/7/2013 3:09 PM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 10/7/2013 9:15 AM, Rainer Weikusat wrote:
>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>
>>>> [variable lifetimes]
>>>>
> ...
>>>
>>> Wouldn't something like this effectively encapsulate $foo and act as a
>>> closure though:
>>>
>>> package main; ...
>>> package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
>>> package main; ...
>>
>> package MyFoo;sub add_something { our $foo; return $foo += $_[0]; };
>> package main;
>>
>> $MyFoo::foo = -15;
>> print MyFoo::add_something(3), "\n";
>
> I overreached with 'effectively' perhaps but didn't intend that it was
> unassailable. A $_foo might have helped. But it's a bit of a stretch
> to break it accidentally too.
The point was supposed to be that our is genuinely different from my
because it doesn't create a perl-level object (it may do so
accidentally, but that's an implementation detail which can be ignored)
but a short (that is, not fully-qualified) name referring to an object
associated with the symbol-table of the package the our resides in (in
order to prevent "use strict 'vars'" from complaining about such an
object being used without a fully-qualified name): With your
add_something, not the scope of the object referred to by $foo is
restricted but the scope of the short name $foo. This code
-------
use strict;
package MyFoo;
sub add_something { our $foo; return $foo += $_[0]; };
$foo = 5;
package main;
print MyFoo::add_something(3), "\n";
--------
won't compile because the $foo name is used outside of the scope of the
our declaration but this code
--------
use strict;
package MyFoo;
sub add_something { our $foo; return $foo += $_[0]; };
our $foo = 5;
package main;
print MyFoo::add_something(3), "\n";
--------
will because a name referring to the same object is declared in both
scopes.
In contrast to this, both the 'state' feature and the trick with
creating a my-variables in a surrounding scope end up creating an object
which is private to the subroutine in question and will keep its value
between invocations of that.
------------------------------
Date: Sun, 06 Oct 2013 01:25:40 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: perl hash utilities
Message-Id: <Iv2dnZoBbpkZg8zPnZ2dnUVZ_qudnZ2d@supernews.com>
do
On 10/3/2013 2:30 AM, $Bill wrote:
> 6 of these - half dozen of the other - they're equivalent in this case.
> qw is just a space separated bunch of ''s (uninterpolated strings).
ok
>
>> I read a lot of this today but didn't stumble yet on an explanation of
>> what @ISA is. (?)
>
> If you combine all of the base Perl man pages into a single
> text file, you can easily search for something like @ISA.
how?
>
> Stands for 'is a' - defines an inheritance tree for the package
> in question. See perlboot - OO tutorial.
ok
>
> Email me a legit addy and I'll send you a script to combine
> your pods for you.
ok. cool, cool.
>
> [Note: Not all of my posts seem to make it through using these
> flaky free servers - let's hope this does.]
>
I keep on pecking away at this. This was the point where I think I want
to pick up with:
#!/usr/bin/perl -w
use strict;
use lib "template_stuff";
use Net::FTP;
use MySubs1 qw(get_ftp_object get_html_filename
get_content create_html_file);
use File::Basename;
use Cwd;
my $rftp = get_ftp_object;
my $html_file = get_html_filename($rftp);
my $refc = get_content();
# page params
my $dir = cwd;
my $word = basename($dir);
my %vars = (
title => $word,
headline => "A rebus template",
place => 'Oakland',
css_file => "${word}1.css");
my $rvars = \%vars;
create_html_file($rvars, $html_file, $refc);
$rftp->put($html_file) or die "put failed $@\n";
$rftp->cwd("/images")
or die "Cannot change working directory ", $rftp->message;
$rftp->mkdir("${word}")
or warn "Cannot create directory ", $rftp->message;
$rftp->cdup();
# load images
my %hash = %$refc;
while ( (my $key,my $value) = each %hash )
{
my $remote_file = basename($key);
print "remote file is $remote_file\n";
$rftp->put( $key, $remote_file ) or die "put failed $!\n";
#print "key: $key, value: $hash{$key}\n";
};
$rftp->cwd("/css");
$rftp->rename("rad1.css", "${word}1.css") or warn "rename failed $@\n";
Now I'm having problems making small changes to the mod now, but this
was a recently-decent version:
#!/usr/bin/perl -w
package MySubs1;
require Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(get_content print_hash create_html_file
get_ftp_object get_config get_html_filename);
sub get_config {
use strict;
use Config2 qw(%config);
return \%Config2::config;
}
sub get_content{
use strict;
use File::Basename;
use Cwd;
use HTML::FromText;
use File::Slurp;
my $path_to_caps = 'template_stuff/captions/';
my $path_to_images = 'template_stuff/images/';
my $base = getcwd;
my $path = "$base\/$path_to_caps";
my $path2 = "$base\/$path_to_images";
my @files = <$path*>;
my @matching;
my $ref_to_matching = \@matching;
while ($_ = pop @files) {
next if /~$/;
next if -d;
next unless -T;
push(@matching, $_);
}
#important to sort
@matching = sort @matching;
my %hash1 = map {$_ => 1 } @matching;
my $ref_to_caps = \%hash1;
my @filetypes = qw/jpg gif png/;
my @images = <$path2*>;
my $pattern = join '|', map "($_)", @filetypes;
my @matching2;
while ($_ = pop @images) {
if ($_ =~ /($pattern)$/i) {
push(@matching2, $_);
}
}
#important to sort
@matching2 = sort @matching2;
my %hash2 = map {$_ => 1 } @matching2;
while ( (my $key,my $value) = each %hash1 )
{
my $string = read_file($key);
my $kludge = text2html(
$string,
urls => 1,
email => 1,
paras => 1,
);
$hash1{$key} = $kludge;
}
my %rebus;
my @values1 = values %hash1;
my @keys2 = keys %hash2;
@rebus{@keys2} = @values1;
return (\%rebus);
}
sub print_hash{
my $hash_ref = shift;
print "subroutine says this is your hash: \n";
my %hash = %$hash_ref;
while ( (my $key,my $value) = each %hash )
{
print "key: $key, value: $hash{$key}\n";
}
}
sub get_html_filename{
use strict;
use Net::FTP;
use File::Basename;
use Cwd;
use MySubs1 qw(get_config);
my $ftp = shift;
# go to /pages
$ftp->cwd("/pages") or die "Cannot change working directory ",
$ftp->message;
# show working directory
my $dir = cwd;
my $word = basename($dir);
# get files from /pages
my @remote_files = $ftp->ls();
# print "@remote_files\n";
my $rref = \@remote_files;
my $filetype = "html";
my $old_num = highest_number($rref, $filetype, $word);
print "old num is $old_num\n";
my $new_num = $old_num + 1;
my $html_file = $word.$new_num.'.'.$filetype;
#print "file is $html_file\n";
return $html_file;
}
sub highest_number{
use strict;
use File::Basename;
use Cwd;
my ($aref, $filetype, $word) = @_;
my $number;
my @matching;
my $ext = ".".$filetype;
push (@matching, 0); #min returned value
for my $file (@{$aref}) {
#print "file is $file\n";
if ($file =~ /^$word(\d+)$ext$/){
#print "matching is $file\n";
push (@matching, $1);
}
}
@matching = sort @matching;
my $winner = pop @matching;
return $winner
}
sub get_ftp_object{
use strict;
use Net::FTP;
use MySubs1 qw(get_config);
my $hoh = get_config();
my %config = %{ $hoh };
my $sub_hash = "my_ftp";
my $domain = $config{$sub_hash}->{'domain'};
my $username = $config{$sub_hash}->{'username'};
my $password = $config{$sub_hash}->{'password'};
#dial up the server
my $ftp = Net::FTP->new( $domain, Debug => 1, Passive => 1 )
or die "Can't connect: $@\n";
$ftp->login( $username, $password)
or die "Couldn't login\n";
return $ftp;
}
sub create_html_file {
use strict;
use lib "template_stuff";
use Net::FTP;
use MySubs1 qw(get_ftp_object get_html_filename get_content);
use File::Slurp;
use File::Basename;
use Cwd;
use Text::Template;
my ( $rvars, $html_file, $refc ) = @_;
my %vars = %$rvars;
open( my $fh, ">:utf8", $html_file )
or die("Can't open $html_file for writing: $!");
#open templates
my $header = "template_stuff/hc_input2.txt";
open( my $gh, "<:utf8", $header ) or die("Can't open: $!");
# write in the footer
my $footer = "template_stuff/footer_center.txt";
open( my $hh, "<:utf8", $footer ) or die("Can't open: $!");
my $specifier = read_file( "template_stuff/rebus1.tmpl" ) ;
print "specifier is $specifier\n";
my $template2 = Text::Template->new(SOURCE => $header)
or die "Couldn't construct template: $!";
my $template3 = Text::Template->new(SOURCE => $footer)
or die "Couldn't construct template: $!";
my $now_string = localtime;
$vars{date} = $now_string;
my $result2 = $template2->fill_in(HASH => \%vars);
my $result3 = $template3->fill_in(HASH => \%vars);
my %blocks;
if (defined $result2) { $blocks{"header"}=$result2 }
if (defined $result3) { $blocks{"footer"}=$result3 }
# write in the header
while (<$gh>) {
print $fh $_;
}
# middle block
my %content = %$refc;
#main control
foreach my $key (sort keys %content) {
print $content{$key} . "\n";
printf $fh $specifier, $key, $content{$key};
}
# write in the footer
while (<$hh>) {
print $fh $_;
}
close $fh;
}
What I find myself doing is going in and changing the architecture of
this file and getting complaints now that sound like name collisions.
Anyways, I keep plugging away at this without having a specific
question, but I appreciate all comments.
--
Cal
------------------------------
Date: Sun, 06 Oct 2013 01:36:52 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: perl hash utilities
Message-Id: <Fi94u.18937$uS4.4588@fx19.iad>
George Mpouras wrote:
> Στις 3/10/2013 05:34, ο/η Cal Dershowitz έγραψε:
>> On 10/2/2013 2:46 PM, George Mpouras wrote:
>>
>>>
>>>
>>> Config1.pm :
>>>
>>>
>>>
>>> package Config1;
>>> require Exporter;
>>>
>>> our @ISA = qw(Exporter);
>>> our @EXPORT = '%config';
>>
>> Why would you single-quote @EXPORT and not use the qw syntax like @ISA?
>>
>> I read a lot of this today but didn't stumble yet on an explanation of
>> what @ISA is. (?)
>
>
> @array = qw/a b/;
>
> is the same as
>
> @array = 'a' , 'b';
I think you mean:
@array = 'a' .. 'b';
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Sun, 6 Oct 2013 09:27:41 GMT
From: me@at.com
Subject: Re: three computing drawbacks
Message-Id: <h2a4u.6786$Ol4.1922@fx03.iad>
1) Non Binary systems are susceptible to noise.
Making it hard to determine what state a bit is in.
2) Clock are used for a reason. Non synchronous circuits suffer timing
problems.
3) Arbitrary length bytes how do you do that quickly ? - You would need
arbitrary long cpu registers to use them.
p
www.review-pc.com/tutorials/perl
------------------------------
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 4051
***************************************
