Re: [PATCH 0/2] gitweb: Add support for running gitweb as FastCGI script

From: Jakub Narebski <jnareb@gmail.com>
Date: May 15, 2010, 13:58 UTC
Message-ID: <201005151558.12191.jnareb@gmail.com>
In-Reply-To: <20100515100615.GA3564@screwed.box>

On Sat, 15 May 2010, Peter Vereshagin wrote:

Show 32 quoted lines

> 2010/05/14 19:58:15 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
> >
> > You don't see the parsing failure because "do <file>;" functions like
> > "eval", which traps exceptions.  You will see consequences of parsing
> > failure (like not defined subroutine).
> > 
> > > But you may see it with "use warnings;" right?
> > 
> > "use warnings;" pragma doesn't help, because of the 'trapping
> > exceptions' part.  That is why "require <file>" is recommended over 
> > "do <file>".
> >
> > Checking $@ after "do <file>" would cover the situation where there were
> > parsing errors, but wouldn't cover situation where file was not found,
> > or there was error in executing code (but parsing was O.K.).
> 
> I just use it like many others, here are the examples of the code
> http://www.jmarshall.com/tools/cgiproxy/ nph-proxy.cgi:
> ===
>     if ($scheme eq 'https') {
>   eval { require Net::SSLeay } ;  # don't check during compilation
>   &no_SSL_warning($URL) if $@ ;
> ===
> http://webgui.org lib/WebGUI/HTML.pm:
> ===
>   } elsif ($type eq "thumb-if-form-thumb") {
>       eval "use Image::Magick;";
>       if ($@){
>         WebGUI::ErrorHandler::warn("Image::Magick not loaded: ".$@);
> ===
> 
> are those lemmings wrong?

No they are not.

But there are two things. First, there is a difference between 'eval EXPR' and 'eval BLOCK' form, in that 'eval EXPR' is parsed (at execution time) and executed (and is slightly slower), while 'eval BLOCK' form is parsed only once, at the time code surrounding eval is parsed (and is slightly faster).

This means that while 'use' in conditional 'eval EXPR' as below

  if (<condition>) {
      eval "use Image::Magick;"
      ...
  }

would work as expected, I think that 'use' in conditional 'eval BLOCK' would not.

  if (<condition>) {
      eval { use Image::Magick; }
      ...
  }

So if you want to use 'eval BLOCK' form, you need to use 'require' and not 'use':

  if (<condition>) {
      eval { require Image::Magick; import Image::Magick; }
      ...
  }

Second, if you are not interested in error condition, and only whether require'ing some module failed or not, then instead of

  eval { require Net::SSLeay };
  no_SSL_warning($URL) if $@;

you can use the 'eval { <sth>; 1 };' idiom, i.e.

  eval { require Net::SSLeay; 1; }
      or no_SSL_warning($URL);

[...]

Show 7 quoted lines

> Whatever, I almost forgot to ask you again about your mysterious 'The
> subroutine was defined, but there was a bug in parsing included file'.
> Does Perl parser has a bug (about 'bug in parsing')?  File was not
> included but the sub from it was successfully defined?  File was about to
> include inside a sub but Perl reported the 'sub undefined' instead of
> 'file has failed to be included by the sub'?  All of those seem just
> incredible to me ;-)

The situation looked like this. The included file (via 'do') had a few subroutines in it, looking roughly like this:

  use strict;
  use warnings;

  sub foo {
     # here was a syntax error
  }

  sub bar {
     # ...
  }

  1; # last statement in file

The main file used 'do $file;' and then tried to use 'bar' subroutine, looking like this:

  use strict;
  use warnings;

  do $file;
  # no checking for $@

...

  bar();

And there Perl gives the following error:

  'Undefined subroutine &bar called'

This is caused by the fact that there was a syntax error before definition of foo(), and Perl didn't make it to defining foo().

When I added checking for $@ in the form of 'die $@ if $@', the error that Perl shown was the syntax error in the foo() subroutine in $file file.

[...]

Show 14 quoted lines

> > This convertion is 
> > a.) compiling CGI file into subroutine (taking care of things like DATA
> >     filehandle) using CGI::Compile
> > b.) converting between CGI interface and PSGI interface, using
> >     CGI::Emulate::PSGI
> 
> Sounds to me like all of that can happen in-memory. Great!
> 
> > Yes, it can.  Depending on request it would run appropriate
> > CGI-converted-to-PSGI application.
> > I am not sure how Plack::App::CGIBin works internally; it migh cimpile
> > all CGI applications upfront; but it might not.
> 
> Will challenge.

I don't know if it would be complete replacement for FCGI::Spawn, but from your description of it, using Plack::App::CGIBin middleware (+ plackup + Plack::Handler::FCGI wrapper) could be a valid alternative to it..

P.S. About Girocco: instead of writing it as set of separate CGI scripts, it could have been instead written as single app, loading its modules ('use lib' would help).

-- 
Jakub Narebski
Poland