Closed p5pRT closed 16 years ago
I found an interesting problem with SelfLoader.pm version 1.0904
If there is any leading whitespace before a subroutine declaration\, SelfLoader will die with the messge "Undefined subroutine blah at script line X". However\, if a subroutine without any whitespace is successfully loaded\, any subroutines with leading whitespace that follow the loaded routine will load normally.
There is also no mention in the module docs that leading whitespace may be an issue. A simple warning against leading whitespace may be sufficient to resolve this problem.
Example code and the results of running it follow:
---Example code--- use SelfLoader;
eval { Foo(); # Fails }; print "Foo Error 1: $@\n";
eval { Baz(); # Fails }; print "Baz Error 1: $@\n";
eval { Bar(); # loads normally }; print "Bar Error: $@\n";
eval { Foo(); # Fails }; print "Foo Error 2: $@\n";
eval { Baz(); # loads normally }; print "Baz Error 2: $@\n";
__DATA__
sub Foo { return scalar @_; }
sub Bar { return scalar @_; }
sub Baz { return scalar @_; }
--Example code output-- Foo Error 1: Undefined subroutine main::Foo at C:\Documents and Settings\Mark\test.pl line 4
Baz Error 1: Undefined subroutine main::Baz at C:\Documents and Settings\Mark\test.pl line 9
Bar Error: Foo Error 2: Undefined subroutine main::Foo at C:\Documents and Settings\Mark\test.pl line 19
Baz Error 2:
Hi p5p\,
Mark Swayne wrote: [...]
If there is any leading whitespace before a subroutine declaration\, SelfLoader will die with the messge "Undefined subroutine blah at script line X". However\, if a subroutine without any whitespace is successfully loaded\, any subroutines with leading whitespace that follow the loaded routine will load normally.
There is also no mention in the module docs that leading whitespace may be an issue. A simple warning against leading whitespace may be sufficient to resolve this problem. [...]
This problem is still present in the SelfLoader that is part of blead. The attached patch (add a \s* to the regex) fixes the issue. The second part of the patch adds a test case.
Question: As with other core modules\, should SelfLoader be dual-lived? There is some differences between 5.10/blead and 5.8.8. Some of those are incompatible with pre-5.9.5 because of new regexp features\, but I don't think that's much of a problem to work around. Let me know if you want me to do this.
Best regards\, Steffen
P.S.: There's also an AutoLoader patch of mine waiting for application\, but that certainly shouldn't be applied before 5.10.
The RT System itself - Status changed from 'new' to 'open'
@rgs - Status changed from 'open' to 'resolved'
On 18/12/2007\, Steffen Mueller \l2ot9pa02@​sneakemail\.com wrote:
This problem is still present in the SelfLoader that is part of blead. The attached patch (add a \s* to the regex) fixes the issue. The second part of the patch adds a test case.
Thanks\, applied as #32665\, and $VERSION++.
Question: As with other core modules\, should SelfLoader be dual-lived? There is some differences between 5.10/blead and 5.8.8. Some of those are incompatible with pre-5.9.5 because of new regexp features\, but I don't think that's much of a problem to work around. Let me know if you want me to do this.
I see no reason why it couldn't be dual-lived.
On 20/12/2007\, Steffen Mueller \l2ot9pa02@​sneakemail\.com wrote:
Hi Rafael\,
Rafael Garcia-Suarez wrote:
I see no reason why it couldn't be dual-lived.
there actually are some problems:
- SelfLoader in 5.10 is version 1.11. - SelfLoader in 5.11 is now version 1.12. - SelfLoader in 5.8.8 is 1.09x or so. - SelfLoader > 1.09x contains 5.10 specific regex features.
Hence\, backporting means having a CPAN release which doesn't use 5.10 specific features. It also means having a version number which makes non 5.10 perls upgrade and 5.10 and up no upgrade.
Why so? you could test $] and use different code. (and release 1.13)
Therefore\, Any such dual-lived releases need\, forever\, have versions between 1.09x and probably 1.10 because I think that's where the 5.10 specific changes came in. It also means that when there are changes to the core/blead SelfLoader\, they cannot be backported for 5.10.x because if I release a SelfLoader with a version > 1.12 to CPAN\, all old perls will try (and fail) to update.
Or am I missing something? One might just have two tracks\, one between 1.09 and 1.10 for perl\<5.10 and one with versions following blead which has a glaring "use 5.009;" in the Makefile.PL. Problem is\, old perls won't update at all if the newest version fails.
but the cpan toolchain doesn't support branches. (yet)
Of course\, this is a broader issue than just SelfLoader. It's bound to crop up in different places as we dual-live more modules.
Like\, when we'll have Perl 6 and Perl 5 in production.
On Thu\, Dec 20\, 2007 at 10:55:05AM +0100\, Rafael Garcia-Suarez wrote:
On 18/12/2007\, Steffen Mueller \l2ot9pa02@​sneakemail\.com wrote:
This problem is still present in the SelfLoader that is part of blead. The attached patch (add a \s* to the regex) fixes the issue. The second part of the patch adds a test case.
Thanks\, applied as #32665\, and $VERSION++.
Question: As with other core modules\, should SelfLoader be dual-lived? There is some differences between 5.10/blead and 5.8.8. Some of those are incompatible with pre-5.9.5 because of new regexp features\, but I don't think that's much of a problem to work around. Let me know if you want me to do this.
I see no reason why it couldn't be dual-lived.
I'd find this really useful as then 5.8.9 could have the same version as 5.10 and blead.
Nicholas Clark
Hi Rafael\,
Rafael Garcia-Suarez wrote:
I see no reason why it couldn't be dual-lived.
there actually are some problems:
- SelfLoader in 5.10 is version 1.11. - SelfLoader in 5.11 is now version 1.12. - SelfLoader in 5.8.8 is 1.09x or so. - SelfLoader > 1.09x contains 5.10 specific regex features.
Hence\, backporting means having a CPAN release which doesn't use 5.10 specific features. It also means having a version number which makes non 5.10 perls upgrade and 5.10 and up no upgrade.
Therefore\, Any such dual-lived releases need\, forever\, have versions between 1.09x and probably 1.10 because I think that's where the 5.10 specific changes came in. It also means that when there are changes to the core/blead SelfLoader\, they cannot be backported for 5.10.x because if I release a SelfLoader with a version > 1.12 to CPAN\, all old perls will try (and fail) to update.
Or am I missing something? One might just have two tracks\, one between 1.09 and 1.10 for perl\<5.10 and one with versions following blead which has a glaring "use 5.009;" in the Makefile.PL. Problem is\, old perls won't update at all if the newest version fails.
Of course\, this is a broader issue than just SelfLoader. It's bound to crop up in different places as we dual-live more modules.
Best regards\, Steffen
Hi Rafael\, hi p5p\,
Rafael Garcia-Suarez wrote:
On 20/12/2007\, Steffen Mueller \l2ot9pa02@​sneakemail\.com wrote:
Rafael Garcia-Suarez wrote:
I see no reason why it couldn't be dual-lived. there actually are some problems:
- SelfLoader in 5.10 is version 1.11. - SelfLoader in 5.11 is now version 1.12. - SelfLoader in 5.8.8 is 1.09x or so. - SelfLoader > 1.09x contains 5.10 specific regex features.
Hence\, backporting means having a CPAN release which doesn't use 5.10 specific features. It also means having a version number which makes non 5.10 perls upgrade and 5.10 and up no upgrade.
Why so? you could test $] and use different code. (and release 1.13)
I would think there are 5.10 features which don't even compile on 5.8. So I would have to test $] and then eval code. Is that the way to go?
[...]
but the cpan toolchain doesn't support branches. (yet)
I'm not holding my breath! :)
Best regards\, Steffen
Steffen Mueller wrote:
Rafael Garcia-Suarez wrote:
On 20/12/2007\, Steffen Mueller \l2ot9pa02@​sneakemail\.com wrote:
Rafael Garcia-Suarez wrote:
I see no reason why it couldn't be dual-lived. there actually are some problems:
- SelfLoader in 5.10 is version 1.11. - SelfLoader in 5.11 is now version 1.12. - SelfLoader in 5.8.8 is 1.09x or so. - SelfLoader > 1.09x contains 5.10 specific regex features.
Hence\, backporting means having a CPAN release which doesn't use 5.10 specific features. It also means having a version number which makes non 5.10 perls upgrade and 5.10 and up no upgrade.
Why so? you could test $] and use different code. (and release 1.13)
I would think there are 5.10 features which don't even compile on 5.8. So I would have to test $] and then eval code. Is that the way to go?
Alternatively\, one could test $] during Makefile.PL and install the correct implementation.
I guess both approaches come with their own set of problems. The aforementioned route would mean that there are actually two modules of the same name and version which contain different code. Slightly scary.
Steffen
Migrated from rt.perl.org#48769 (status was 'resolved')
Searchable as RT48769$