Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Test-Simple CPAN distribution.

Report information
The Basics
Id: 67538
Status: resolved
Priority: 0/
Queue: Test-Simple

People
Owner: Nobody in particular
Requestors: sprout [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [PATCH] Make use_ok work with lexical pragmata
Date: Sun, 17 Apr 2011 12:56:17 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
Since you already know about it, I needn’t say much. But for posterity’s sake, I ought to mention that http://rt.perl.org/rt3/Ticket/Display.html?id=87064 brought this up. The attachment is a git-am-compatible patch.

Message body is not shown because sender requested not to inline it.

Oh boy. Given the scope of change, I'm of half a mind to say the hell with it. use_ok() is marginally useful at best. How much saner would it be if it didn't try to support C<< use_ok("constant 1.03") >>? That's a clear violation of the documentation and I have no sympathy. I presume that big block of module and version parsing would go away? That's the bit and most likely to break in the future.
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Sun, 23 Oct 2011 16:42:43 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
On Oct 23, 2011, at 4:08 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > Oh boy. Given the scope of change, I'm of half a mind to say the hell > with it. use_ok() is marginally useful at best. > > How much saner would it be if it didn't try to support C<< > use_ok("constant 1.03") >>? That's a clear violation of the > documentation and I have no sympathy. I presume that big block of > module and version parsing would go away?
Yes, it could. (Also, it didn’t support the esoteric ‘use 5.57 Exporter’ syntax.) Show quoted text
> That's the bit and most > likely to break in the future.
Attached is a revised patch.

Message body is not shown because sender requested not to inline it.

That's much better, thank you. It's in. https://github.com/schwern/test-more/commit/5ed8f11cb1ac4468c26c657d4399f0cff2375078 I cleaned it up some. I don't expect you to do all of that, I'd rather have the patch and clean it up than no patch. https://github.com/schwern/test-more/commit/40f26cf9076aec7c64609ca73faa2b6be719536c One thing which puzzles me is why does setting $^H and %^H inside use_ok() effect the caller and not it's own scope? Is that just how they work? Or is it that whatever $^H and %^H are set to at the end of the BEGIN block applies to the caller?
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Sun, 23 Oct 2011 18:24:17 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
On Oct 23, 2011, at 5:49 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > That's much better, thank you. It's in. > https://github.com/schwern/test-more/commit/5ed8f11cb1ac4468c26c657d4399f0cff2375078 > > I cleaned it up some. I don't expect you to do all of that, I'd rather > have the patch and clean it up than no patch. > https://github.com/schwern/test-more/commit/40f26cf9076aec7c64609ca73faa2b6be719536c > > One thing which puzzles me is why does setting $^H and %^H inside > use_ok() effect the caller and not it's own scope? Is that just how > they work? Or is it that whatever $^H and %^H are set to at the end of > the BEGIN block applies to the caller?
It’s the latter. $^H and %^H affect the code that is currently being compiled. It also means that Moose, etc., can do: sub import { ... strict->import; warnings->import ... }
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Sun, 23 Oct 2011 21:08:32 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
On Oct 23, 2011, at 5:49 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > That's much better, thank you. It's in. > https://github.com/schwern/test-more/commit/5ed8f11cb1ac4468c26c657d4399f0cff2375078 > > I cleaned it up some. I don't expect you to do all of that, I'd rather > have the patch and clean it up than no patch. > https://github.com/schwern/test-more/commit/40f26cf9076aec7c64609ca73faa2b6be719536c
I’ve just noticed a couple of things: This really has nothing to do with 5.13.7. 5.13.7 disabled some weird source filter behaviour (in that the filter enabled within a string eval would apply to whatever outer dynamic scope was being compiled). Either making use_ok work with pragmata *or* reenabling the source filter would fix the 20 or so modules affected. The latter is what happened, so 5.14.0 is no different from 5.12.0 in that regard. So mentioning 5.13.7 at all in the changelog is misleading. use_ok has, as far as I know, never worked with pragmata. +Lexical effects will occur as usual. For example, this will turn on strictures. + + use_ok "strict"; This would be better written as BEGIN { use_ok "strict"; }, because a simple use_ok "strict" won’t enable it for the current scope. You don’t like my coding style, but have you seen the perl source. :-) Also, I actually find more compact code easier to read, because I don’t have to look so far to understand it. Show quoted text
> > One thing which puzzles me is why does setting $^H and %^H inside > use_ok() effect the caller and not it's own scope? Is that just how > they work? Or is it that whatever $^H and %^H are set to at the end of > the BEGIN block applies to the caller?
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Mon, 24 Oct 2011 14:57:46 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2011.10.23 9:08 PM, Father Chrysostomos via RT wrote: Show quoted text
> This really has nothing to do with 5.13.7. 5.13.7 disabled some weird source > filter behaviour (in that the filter enabled within a string eval would apply > to whatever outer dynamic scope was being compiled). Either making use_ok work > with pragmata *or* reenabling the source filter would fix the 20 or so modules > affected. The latter is what happened, so 5.14.0 is no different from 5.12.0 > in that regard. So mentioning 5.13.7 at all in the changelog is misleading.
Filters seem to work with an unpatched Test::More and 5.14.1. use warnings; use Test::More; BEGIN { use_ok "Semi::Semicolons"; } pass()Peterbilt done_testing; Did that filter behavior change make it out of 5.13? Show quoted text
> use_ok has, as far as I know, never worked with pragmata.
D'oh! You're right! I wonder if it's worth starting now. Well, work's done. I'll fix the change log. Show quoted text
> +Lexical effects will occur as usual. For example, this will turn on strictures. > + > + use_ok "strict"; > > This would be better written as BEGIN { use_ok "strict"; }, because a simple > use_ok "strict" won’t enable it for the current scope.
Got it. Done. Show quoted text
> You don’t like my coding style, but have you seen the perl source. :-)
Bonitas non est pessimis esse meliorem. Show quoted text
> I actually find more compact code easier to read, because I don’t have to
look so Show quoted text
> far to understand it.
Greatthenletsgetridoftheinterstitialspaceandparagraphs! I presume you mean scrolling rather than physically turning your head and eyeballs? Less tongue in cheek... a large project cannot be fully understood at one time. It is more important to find the piece you care about, and its scope of effect, than to study code in detail. This is why code should be optimized for skimming with the scope and structure laid bare. This is also why any given scope should remain short. A narrow scope forgives many sins. The blocks I've been using lately in my tests are a great example. I have a talk on this, unfortunately there's no video, but here's the slides with notes: http://schwern.net/talks/Skimmable%20Code%20-%20OSCON%202008%20w:notes.pdf That said, vertical whitespace is valuable. But rather than conserve it I expand my store. I've got my editor spanning the full height of the screen and using the smallest most compact font my poor eyes can easily deal with. Helps to have a high resolution, widescreen laptop. :-) BTW Inconsolata is a fantastic fixed width font. Gave me a lot more space and clarity. http://www.levien.com/type/myfonts/inconsolata.html -- s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm." and it's a perl script that turns dog crap into gold.
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Mon, 24 Oct 2011 15:41:12 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
On Oct 24, 2011, at 2:58 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > On 2011.10.23 9:08 PM, Father Chrysostomos via RT wrote:
>> This really has nothing to do with 5.13.7. 5.13.7 disabled some weird source >> filter behaviour (in that the filter enabled within a string eval would apply >> to whatever outer dynamic scope was being compiled). Either making use_ok work >> with pragmata *or* reenabling the source filter would fix the 20 or so modules >> affected. The latter is what happened, so 5.14.0 is no different from 5.12.0 >> in that regard. So mentioning 5.13.7 at all in the changelog is misleading.
> > Filters seem to work with an unpatched Test::More and 5.14.1. > > use warnings; > use Test::More; > > BEGIN { use_ok "Semi::Semicolons"; } > > pass()Peterbilt > > done_testing; > > Did that filter behavior change make it out of 5.13?
No. It was reverted at the last minute, due to CPAN breakage. Show quoted text
> >
>> use_ok has, as far as I know, never worked with pragmata.
> > D'oh! You're right! I wonder if it's worth starting now. Well, work's done. > I'll fix the change log. > >
>> +Lexical effects will occur as usual. For example, this will turn on strictures. >> + >> + use_ok "strict"; >> >> This would be better written as BEGIN { use_ok "strict"; }, because a simple >> use_ok "strict" won’t enable it for the current scope.
> > Got it. Done. > >
>> You don’t like my coding style, but have you seen the perl source. :-)
> > Bonitas non est pessimis esse meliorem. > >
>> I actually find more compact code easier to read, because I don’t have to
> look so
>> far to understand it.
> > Greatthenletsgetridoftheinterstitialspaceandparagraphs! > > I presume you mean scrolling rather than physically turning your head and > eyeballs? > > Less tongue in cheek... a large project cannot be fully understood at one > time. It is more important to find the piece you care about, and its scope of > effect, than to study code in detail. This is why code should be optimized > for skimming with the scope and structure laid bare. This is also why any > given scope should remain short. A narrow scope forgives many sins. The > blocks I've been using lately in my tests are a great example. > > I have a talk on this, unfortunately there's no video, but here's the slides > with notes: > http://schwern.net/talks/Skimmable%20Code%20-%20OSCON%202008%20w:notes.pdf > > That said, vertical whitespace is valuable. But rather than conserve it I > expand my store. I've got my editor spanning the full height of the screen
I can’t stand that. I like to have at least ten windows open at once. Show quoted text
> and using the smallest most compact font my poor eyes can easily deal with. > Helps to have a high resolution, widescreen laptop. :-) > > BTW Inconsolata is a fantastic fixed width font. Gave me a lot more space > and clarity. > http://www.levien.com/type/myfonts/inconsolata.html > > > -- > s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm." > and it's a perl script that turns dog crap into gold. >
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Mon, 24 Oct 2011 18:11:27 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2011.10.24 3:41 PM, Father Chrysostomos via RT wrote: Show quoted text
> I can’t stand that. I like to have at least ten windows open at once.
Ahh. Programmers seem to split across those lines: those who can juggle 12 things at a time and those who can't. I can't. Thing is, code written with the assumption you can juggle is nigh unmaintainable by those who can't. The reverse does not have so bad an effect. That said, the jugglers can fix things I can't. :-) Thank you for the work, Father. (Is that what you prefer?) If there's any other of your patches I've dropped on the floor please let me know. I'm going to close this up. -- ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up after eating a junior mint. -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest by Tami Farmer
Unfortunately there's a problem with the new use_ok(). It seems pragmas are leaking out. no strict; # This is deliberate use Test::More; BEGIN { use_ok "Symbol"; } $str = "hello"; # deliberately don't declare the variable is $str, "hello"; done_testing; That'll die with "Global symbol "$str" requires explicit package name". Any thoughts on this, FC?
A test case I've just written as I isolated this bug: use utf8; use Test::More 'no_plan'; BEGIN { use_ok 'Carp' } sub parser { use utf8; return 'fünky'; } is parser(), 'fünky'; Breaks `use utf8` I guess. Thanks, David
Subject: Re: [rt.cpan.org #67538] [PATCH] Make use_ok work with lexical pragmata
Date: Tue, 22 Nov 2011 22:14:31 -0800
To: bug-Test-Simple [...] rt.cpan.org
From: Father Chrysostomos <sprout [...] cpan.org>
On Nov 22, 2011, at 1:46 AM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > Unfortunately there's a problem with the new use_ok(). It seems pragmas > are leaking out. > > no strict; # This is deliberate > use Test::More; > > BEGIN { use_ok "Symbol"; } > > $str = "hello"; # deliberately don't declare the variable > is $str, "hello"; > > done_testing; > > That'll die with "Global symbol "$str" requires explicit package name". > > Any thoughts on this, FC?
My workaround for perl bug #70151 was not good enough. It ended up resetting the caller’s hints to what Test::More itself was using. Here’s a small patch to fix it (with an s/// -> y/// change as a bonus, as y is more than twice the speed). I haven’t got to writing tests, but can I leave that to you? You could incorporate David Wheeler’s test case.

Message body is not shown because sender requested not to inline it.

On Wed Nov 23 01:14:42 2011, sprout@cpan.org wrote: Show quoted text
> > On Nov 22, 2011, at 1:46 AM, Michael G Schwern via RT wrote: >
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=67538 > > > > > Unfortunately there's a problem with the new use_ok(). It seems
> pragmas
> > are leaking out. > > > > no strict; # This is deliberate > > use Test::More; > > > > BEGIN { use_ok "Symbol"; } > > > > $str = "hello"; # deliberately don't declare the variable > > is $str, "hello"; > > > > done_testing; > > > > That'll die with "Global symbol "$str" requires explicit package
> name".
> > > > Any thoughts on this, FC?
> > My workaround for perl bug #70151 was not good enough. It ended up > resetting the caller’s hints to what Test::More itself was using. > Here’s a small patch to fix it (with an s/// -> y/// change as a > bonus, as y is more than twice the speed). I haven’t got to writing > tests, but can I leave that to you? You could incorporate David > Wheeler’s test case.
Oops. I made a mistake. Try this attachment.
Subject: better-70151-workaround.text
diff -rup schwern-test-more-f5f962a-orig/lib/Test/More.pm schwern-test-more-f5f962a/lib/Test/More.pm --- schwern-test-more-f5f962a-orig/lib/Test/More.pm 2011-11-22 00:47:36.000000000 -0800 +++ schwern-test-more-f5f962a/lib/Test/More.pm 2011-11-22 08:28:04.000000000 -0800 @@ -851,7 +851,7 @@ sub use_ok ($;@) { my( $pack, $filename, $line ) = caller; my $f = $filename; - $f =~ s/[\n\r]/_/g; # so it doesn't run off the "#line $line $f" line + $f =~ y/\n\r/_/; # so it doesn't run off the "#line $line $f" line my $version; if( @imports == 1 and $imports[0] =~ /^\d+(?:\.\d+)?$/ ) { @@ -862,16 +862,20 @@ sub use_ok ($;@) { my $version_check = defined $version ? qq{$module->VERSION($version)} : ""; my $code = <<"USE"; package $pack; +# Work around [perl #70151] +\$^H = \${\$args[1]}; +%^H = %{\$args[2]}; #line $line $f require $module; $version_check; $module->import(\@{\$args[0]}); -# Work around [perl #70151] \${\$args[1]} = \$^H; %{\$args[2]} = %^H; 1; USE + my $hints = $^H; + my %hints = %^H; my( $eval_result, $eval_error ) - = _eval( $code, \@imports, \my($hints, %hints) ); + = _eval( $code, \(@imports, $hints, %hints) ); my $ok = $tb->ok( $eval_result, "use $module;" ); if( $ok ) {
Thanks, I've patched that in and 0.98_02 went out last night.