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

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 15 May 2010, Peter Vereshagin wrote:
> 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);

[...]  

> 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.

[...]

> > 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