Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 38380
Status: resolved
Priority: 0/
Queue: Perl-Critic
People
Owner: Nobody in particular
Requestors: smueller [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 1.090
Fixed in: (no value)

History Show all quoted text
  Sun Aug 10 17:15:48 2008 smueller [...] cpan.org - Ticket created
The perlcritic script cannot be run from inside a PAR context because in such a situation, the run() function in perlcritic isn't executed: in main: sub run {...} exit run() unless caller(); Will not call run() because in a PAR, main isn't the top-most call-frame. The solution, unfortunately, is not for PAR to clear the stack. That's *hard*. The only thing I could think of is to replace the line with: exit run() if not caller() or $ENV{PAR_0}; which allows for not being in the top call-stack if in a PAR packaged executable.
  Sun Aug 10 17:16:46 2008 smueller [...] cpan.org - Subject changed from (no value) to 'perlcritic not PAR-compatible'
  Sun Aug 10 17:38:04 2008 jeff [...] imaginative-software.com - Correspondence added
CC: dev [...] perlcritic.tigris.org
Subject: Re: [rt.cpan.org #38380]
Date: Sun, 10 Aug 2008 14:37:27 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
On Aug 10, 2008, at 2:15 PM, Steffen Mueller via RT wrote: Show quoted text
> The perlcritic script cannot be run from inside a PAR context > because in > such a situation, the run() function in perlcritic isn't executed: > > in main: > > sub run {...} > exit run() unless caller(); > > Will not call run() because in a PAR, main isn't the top-most call- > frame. > > The solution, unfortunately, is not for PAR to clear the stack. That's > *hard*. The only thing I could think of is to replace the line with: > > exit run() if not caller() or $ENV{PAR_0}; > > which allows for not being in the top call-stack if in a PAR packaged > executable.
That's an interesting one. Would caller() return a particular package or sub name when called by PAR? Chris Dolan probably has the most experience with PAR amongst the Perl-Critic team. I'll wait for his input before making any decisions on this. Thanks for reporting it. -Jeff
  Sun Aug 10 17:38:05 2008 The RT System itself - Status changed from 'new' to 'open'
  Sun Aug 10 22:11:19 2008 chris [...] chrisdolan.net - Correspondence added
Subject: Re: [rt.cpan.org #38380]
Date: Sun, 10 Aug 2008 21:10:59 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Chris Dolan <chris [...] chrisdolan.net>
On Aug 10, 2008, at 4:38 PM, Jeffrey Thalhammer via RT wrote: Show quoted text
> Queue: Perl-Critic > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38380 > > > > On Aug 10, 2008, at 2:15 PM, Steffen Mueller via RT wrote: >
>> The perlcritic script cannot be run from inside a PAR context >> because in >> such a situation, the run() function in perlcritic isn't executed: >> >> in main: >> >> sub run {...} >> exit run() unless caller(); >> >> Will not call run() because in a PAR, main isn't the top-most call- >> frame. >> >> The solution, unfortunately, is not for PAR to clear the stack. >> That's >> *hard*. The only thing I could think of is to replace the line with: >> >> exit run() if not caller() or $ENV{PAR_0}; >> >> which allows for not being in the top call-stack if in a PAR packaged >> executable.
> > That's an interesting one. Would caller() return a particular > package or > sub name when called by PAR? Chris Dolan probably has the most > experience with PAR amongst the Perl-Critic team. I'll wait for his > input > before making any decisions on this. Thanks for reporting it. > > -Jeff
The right solution may be to move all of the code from bin/perlcritic to lib/perlcritic.pm and make bin/perlcritic be a tiny file that just says "use perlcritic; perlcritic->run". See the the following for the inspiration for this suggestion: http://search.cpan.org/src/SMUELLER/PAR-Packer-0.982/script/pp http://search.cpan.org/src/SMUELLER/PAR-Packer-0.982/lib/pp.pm With this solution, Steffan can simply replace bin/perlcritic with a trivial, PAR-friendly entry script. Chris
  Mon Aug 11 06:32:28 2008 smueller [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #38380]
Date: Mon, 11 Aug 2008 12:31:54 +0200
To: bug-Perl-Critic [...] rt.cpan.org
From: Steffen Mueller <smueller [...] cpan.org>
Show quoted text
>>> exit run() if not caller() or $ENV{PAR_0};
Chris Dolan via RT wrote: Show quoted text
>> That's an interesting one. Would caller() return a particular >> package or >> sub name when called by PAR?
No, not really. It also depends on how specifically it's run, I think. If you just "pp -o perlcritic.bin perlcritic", it should be ["main", 1, "-e"] or something like that (no promises), but it's the same if you do "perl -e 'do "perlcritic"'". It should be different if you run perlcritic as a script from a .par file as I am trying to. Show quoted text
> The right solution may be to move all of the code from bin/perlcritic > to lib/perlcritic.pm and make bin/perlcritic be a tiny file that just > says "use perlcritic; perlcritic->run". See the the following for > the inspiration for this suggestion: > > http://search.cpan.org/src/SMUELLER/PAR-Packer-0.982/script/pp > http://search.cpan.org/src/SMUELLER/PAR-Packer-0.982/lib/pp.pm > > With this solution, Steffan can simply replace bin/perlcritic with a > trivial, PAR-friendly entry script.
That wouldn't even be necessary. People wouldn't use perlcritic, the script, as a library, so the guard against it wouldn't be necessary. So I could just use the tiny script as it stands. Regardless, checking against $ENV{PAR_0} should be fine. I understand that testing against the environment isn't great. Testing $INC{PAR.pm} whether PAR has been loaded would most probably work as well. It did work in a simple test. Best regards, Steffen
  Tue Sep 02 18:37:08 2008 thaljef [...] cpan.org - Correspondence added
Fixed and released in version 1.092.
  Tue Sep 02 18:37:11 2008 thaljef [...] cpan.org - Status changed from 'open' to 'resolved'