MadMongers

On Thu, 09 Feb 2012 16:29:43 -0600
wrote:

> afbach wrote:
> This is a bit of a mess, but the result is puzzling - somebody was
> testing a change to a require-ed in library script, so they made a
> copy, changed the name and used that.  As it happens, the process
> also, via a complex, Rube Goldberg-ish route, ends up require-ing the
> original library file again, but this ends up failing - in the end I
> found that:
> perl -w -Mstrict -e 'require "../support/CalEvents.pl";'
> or
> perl -w -Mstrict -e 'require "../support/CalEventsBr.pl";'
>
> or even (yes, doesn't do anything):
> perl -w -Mstrict -e 'require "../support/CalEvents.pl; require
> "../support/CalEvents.pl";'
>
> worked but  (there really as only about 3  lines difference - the user
> is a very cautious admin):
> perl -w -Mstrict -e 'require "../support/CalEventsBr.pl"; require
> "../support/CalEvents.pl";'
>
> would fail with
> ...
> Subroutine fields_used_in_the_form redefined at
> ../support/CalEvents.pl line 2109.
> Subroutine display_calendar_time_field redefined at
> ../support/CalEvents.pl line 2129.
> Subroutine is_this_checked redefined at ../support/CalEvents.pl line
> 2139. Too many arguments for main::DisplayPtyAty
> at ../support/CalEvents.pl line 778, near "$caseid)"
>
> Yes, both scripts had:
> sub DisplayPtyAty() {
>      my $caseid = shift @_;
> ...
> DisplayPtyAty($caseid);
>
> So, though both had too many args, it was only with the re-require of
> the different named version that Perl got mad enough to fail.
> Certainly it's a fair cop, but just not sure why.
>
> Any guesses?
>
> a
>
> Andy Bach,
> afbach@gmail.com
> 608 658-1890 cell
> 608 261-5738 wk
>
> View Online
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org

require caches the results of each file it runs, so running require
'myfile.pl' only ever compiles and runs myfile.pl once.  The caching is
done based on the path used, so a symlink to the same file would result
in the wonky behavior you're seeing.

-Rob

On Thu, Feb 9, 2012 at 5:21 PM,   wrote:
> require caches the results of each file it runs, so running require
> 'myfile.pl' only ever compiles and runs myfile.pl once.

Right - I know this (it's the %INC which I just ran into) so:
lib1.pl
sub g
{
    d("hi mom");
}
sub d($)
{
    print "hi d\n";
}

1;

lib2.pl
sub g
{
    d("hi mom");
}
sub d()
{
    print "hi d\n";
}

1;

prg.pl
require "../java/lib1.pl";
require "lib1.pl";
require "../java/lib2.pl";
print "$_ => $INC{$_}\n" foreach keys %INC;


$ perl -w -Mstrict prg.pl
Subroutine g redefined at lib1.pl line 2.
Subroutine d redefined at lib1.pl line 6.
Subroutine g redefined at ../java/lib2.pl line 2.
Prototype mismatch: sub main::d ($) vs () at ../java/lib2.pl line 8.
Subroutine d redefined at ../java/lib2.pl line 6.
strict.pm => /usr/share/perl/5.10/strict.pm
lib1.pl => lib1.pl
../java/lib1.pl => ../java/lib1.pl
../java/lib2.pl => ../java/lib2.pl

doesn't fail though, as the lib2.pl, which triggers the mismatch, has
the wrong proto. But if I make lib1 have the wrong proto too (and to
be clearer, take out that pathless require):
$ cat prg.pl
require "../java/lib1.pl";
require "../java/lib2.pl";
print "$_ => $INC{$_}\n" foreach keys %INC;

$ perl -w -Mstrict prg.pl
Subroutine g redefined at ../java/lib2.pl line 2.
Subroutine d redefined at ../java/lib2.pl line 6.
Too many arguments for main::d at ../java/lib2.pl line 3, near ""hi mom")"
Compilation failed in require at prg.pl line 2.

fails. So, in compile phase, a 2nd view of a line using the wrong
proto is a failure.  It would seem it should be a failure even if
there's just one require:

$ cat prg.pl
require "../java/lib1.pl";
#require "../java/lib2.pl";
print "$_ => $INC{$_}\n" foreach keys %INC;
g();
d();

but no, not a complaint:
$ perl -w -Mstrict prg.pl
strict.pm => /usr/share/perl/5.10/strict.pm
../java/lib1.pl => ../java/lib1.pl
hi d
hi d


--

a

Andy Bach,
afbach@gmail.com
608 658-1890 cell
608 261-5738 wk

Prototypes only effect compile time.  require happens at runtime.

In your first example, lib1 is completely compiled before moving on to
lib2.  When compiling lib2, it sees d("hi mom"); and resolves it to
lib1's d($)  before it sees lib2's d with an empty prototype.  This is
acceptable.  When it compiles d() it notices the conflict, but that is
a warning and doesn't effect the initial call.

In your second example, the incorrect prototype is in effect (because
it completed compiling lib1 first) when it sees the d("hi mom") call
in lib2, so it triggers a compile error.

In your third example, it parses and compiles both d() and g() before
compiling either lib1 or lib2, so it doesn't trigger a compile error.

If possible, perl will try to compile sub() calls at compile time, but
if that isn't possible it will leave them for runtime to resolve.

What is the lesson here?  Never use prototypes.  Always use warnings.
Use packages and .pm files, not .pl files.  And never use prototypes.

On Thu, Feb 9, 2012 at 7:40 PM,   wrote:
> afbach wrote:
>
> On Thu, Feb 9, 2012 at 5:21 PM,   wrote:
>> require caches the results of each file it runs, so running require
>> 'myfile.pl' only ever compiles and runs myfile.pl once.
>
> Right - I know this (it's the %INC which I just ran into) so:
> lib1.pl
> sub g
> {
>     d("hi mom");
> }
> sub d($)
> {
>     print "hi d\n";
> }
>
> 1;
>
> lib2.pl
> sub g
> {
>     d("hi mom");
> }
> sub d()
> {
>     print "hi d\n";
> }
>
> 1;
>
> prg.pl
> require "../java/lib1.pl";
> require "lib1.pl";
> require "../java/lib2.pl";
> print "$_ => $INC{$_}\n" foreach keys %INC;
>
>
> $ perl -w -Mstrict prg.pl
> Subroutine g redefined at lib1.pl line 2.
> Subroutine d redefined at lib1.pl line 6.
> Subroutine g redefined at ../java/lib2.pl line 2.
> Prototype mismatch: sub main::d ($) vs () at ../java/lib2.pl line 8.
> Subroutine d redefined at ../java/lib2.pl line 6.
> strict.pm => /usr/share/perl/5.10/strict.pm
> lib1.pl => lib1.pl
> ../java/lib1.pl => ../java/lib1.pl
> ../java/lib2.pl => ../java/lib2.pl
>
> doesn't fail though, as the lib2.pl, which triggers the mismatch, has
> the wrong proto. But if I make lib1 have the wrong proto too (and to
> be clearer, take out that pathless require):
> $ cat prg.pl
> require "../java/lib1.pl";
> require "../java/lib2.pl";
> print "$_ => $INC{$_}\n" foreach keys %INC;
>
> $ perl -w -Mstrict prg.pl
> Subroutine g redefined at ../java/lib2.pl line 2.
> Subroutine d redefined at ../java/lib2.pl line 6.
> Too many arguments for main::d at ../java/lib2.pl line 3, near ""hi mom")"
> Compilation failed in require at prg.pl line 2.
>
> fails. So, in compile phase, a 2nd view of a line using the wrong
> proto is a failure.  It would seem it should be a failure even if
> there's just one require:
>
> $ cat prg.pl
> require "../java/lib1.pl";
> #require "../java/lib2.pl";
> print "$_ => $INC{$_}\n" foreach keys %INC;
> g();
> d();
>
> but no, not a complaint:
> $ perl -w -Mstrict prg.pl
> strict.pm => /usr/share/perl/5.10/strict.pm
> ../java/lib1.pl => ../java/lib1.pl
> hi d
> hi d
>
>
> --
>
> a
>
> Andy Bach,
> afbach@gmail.com
> 608 658-1890 cell
> 608 261-5738 wk
>
> View Online
>
>
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org

On 2/9/12 10:23 PM, haarg@haarg.org wrote:
> What is the lesson here?  Never use prototypes.  Always use warnings.
> Use packages and .pm files, not .pl files.  And never use prototypes.

Amen.  I would add: "'use' don't 'require'" ..

jon

--
.Jonathan J. Miner----------------------------------------------------.
|  jon@jjminer.org  |      photos - http://photos.jjminer.org/        |
|                   | R.A.W. #1629 - http://www.reggaeambassadors.org |
|                   | LOCS Webmaster - http://www.locs-buffett.org    |
|  jabber/gchat: camrycurbhopper@gmail.com                            |
`---------------------------------------------------------------------'

"We don't have a town drunk...   We all take turns!"

Thanks, Haarg, that makes sense. I was thinking something like that
after boiling it down to examples for this list and seeing the line
numbers being complained about.  The original problem, as given to me,
was that the require was being done inside a (homegrown) HTML template
preprocessing  that included a eval of perl code that didn't report
the $@ msgs.  Because of the sequence, a change to a require to the
new code name in one place would bring up the error in another.  Once
I found the eval and fetched $@, things got a little clearer ;->

> What is the lesson here?  Never use prototypes.  Always use warnings.
> Use packages and .pm files, not .pl files.  And never use prototypes.

Yeah, the original code, I'm pretty sure, wasn't actually using
prototypes (as the next line was
my $caseid = shift @_;

) but thinking javascript or something and so they thought parens were
just part of a sub declaration.

Thanks!

--

a

Andy Bach,
afbach@gmail.com
608 658-1890 cell
608 261-5738 wk

are prototypes really that useless?

Yup, almost completely useless.  It's a convenience for making custom
subs behave like the some builtins.  Like push:

    push @array, @list_to_push;

But you could always fake it by having the caller make the reference
explicit:

    my_push( \@array, @list_to_push );

If you never knew they existed, you wouldn't be missing much.

Thanks,
Timm

On 2/10/2012 12:43 PM, david-delikat@usa.net wrote:
> david-delikat wrote:
>
>
> are prototypes really that useless?
> not that I've ever used them; but
> I've thought about it.
>
> On Feb 10, 2012, at 10:43 AM, >
> > wrote:
>
>> miner wrote:
>>
>> On 2/9/12 10:23 PM, haarg@haarg.org  wrote:
>> > What is the lesson here? Never use prototypes. Always use warnings.
>> > Use packages and .pm files, not .pl files. And never use prototypes.
>>
>> Amen. I would add: "'use' don't 'require'" ..
>>
>> jon
>>
>> --
>> .Jonathan J. Miner----------------------------------------------------.
>> | jon@jjminer.org  | photos -
>> http://photos.jjminer.org/ |
>> | | R.A.W. #1629 - http://www.reggaeambassadors.org |
>> | | LOCS Webmaster - http://www.locs-buffett.org |
>> | jabber/gchat: camrycurbhopper@gmail.com
>>  |
>> `---------------------------------------------------------------------'
>>
>> "We don't have a town drunk... We all take turns!"
>>
>> View Online
>>
>>
>>
>>
>> Madison Area Perl Mongers - MadMongers
>> http://www.madmongers.org
>
> View Online
>
>
>
>
> Madison Area Perl Mongers - MadMongers
> http://www.madmongers.org

And also I must add: Perl::Critic would have flagged some of these offenses. :-)

I assume you're not defining a Package in the require()d file..  

Perl is outsmarting you and knowing it already imported the file when it has exactly the same name (it may be checking the stat() on the file), but when (obviously) it has a different name, it can't tell that, so it imports it again.  (You can require or use the same thing over-and-over and it will only really do it once.  "do", though is a different story.)

No clue, though, on why it's only noticing the incorrectly defined function with the second require.  That is very weird.

jon

On 2/9/12 4:29 PM, afbach@gmail.com wrote:

afbach wrote:

This is a bit of a mess, but the result is puzzling - somebody was
testing a change to a require-ed in library script, so they made a
copy, changed the name and used that.  As it happens, the process
also, via a complex, Rube Goldberg-ish route, ends up require-ing the
original library file again, but this ends up failing - in the end I
found that:
perl -w -Mstrict -e 'require "../support/CalEvents.pl";'
or
perl -w -Mstrict -e 'require "../support/CalEventsBr.pl";'

or even (yes, doesn't do anything):
perl -w -Mstrict -e 'require "../support/CalEvents.pl; require
"../support/CalEvents.pl";'

worked but  (there really as only about 3  lines difference - the user
is a very cautious admin):
perl -w -Mstrict -e 'require "../support/CalEventsBr.pl"; require
"../support/CalEvents.pl";'

would fail with
...
Subroutine fields_used_in_the_form redefined at
../support/CalEvents.pl line 2109.
Subroutine display_calendar_time_field redefined at
../support/CalEvents.pl line 2129.
Subroutine is_this_checked redefined at ../support/CalEvents.pl line 2139.
Too many arguments for main::DisplayPtyAty at ../support/CalEvents.pl
line 778, near "$caseid)"

Yes, both scripts had:
sub DisplayPtyAty() {
     my $caseid = shift @_;
...
DisplayPtyAty($caseid);

So, though both had too many args, it was only with the re-require of
the different named version that Perl got mad enough to fail.
Certainly it's a fair cop, but just not sure why.

Any guesses?

a

Andy Bach,
afbach@gmail.com
608 658-1890 cell
608 261-5738 wk

View Online

Madison Area Perl Mongers - MadMongers
http://www.madmongers.org

-- 
.Jonathan J. Miner----------------------------------------------------.
|  jon@jjminer.org  |      photos - http://photos.jjminer.org/        |
|                   | R.A.W. #1629 - http://www.reggaeambassadors.org |
|                   | LOCS Webmaster - http://www.locs-buffett.org    |
|  jabber/gchat: camrycurbhopper@gmail.com                            |
`---------------------------------------------------------------------'

"We don't have a town drunk...   We all take turns!"