On Fri, 14 May 2010, Peter Vereshagin wrote:
> 2010/05/14 12:53:42 +0200 Jakub Narebski <jnareb@xxxxxxxxx> => To Peter Vereshagin :
>> legitimate uses of 'goto' that make the program simpler to understand,
>> and not harder,... among those is handling exceptions.
>
> so did you change the exception-related exit()s on your patch to the
> "last" ?
Yes, die_error(), which had "exit" that got replaced by non-local "goto"
is exception-related subroutine.
>> The problem is that "do <file>;" is similar to "eval `cat <file>`;"
>> (except that it's more efficient and concise), it that it silences
>> parsing errors. From `perldoc -f do`:
>>
>> If "do" cannot read the file, it returns undef and sets $! to the error.
>> If "do" can read the file but cannot compile it, it returns undef and sets
>> an error message in $@. If the file is successfully compiled, "do"
>> returns the value of the last expression evaluated.
>>
>>> And yes, since it's about development but not production use, die is just fine
>>> in the inclusion code like this:
>>>
>>> eval( 'use Module;' ); die $@ if $@;
>>
>> Wrong!
>
> The problem was you can't see the reason of the inclusion-via-do()
> parsing failure.
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>".
>>> as always, require() can do the trick, not to mention usual
>>>
>>> use Module;
>>>
>>> This all will cause die() when it's necessary as only the application developer
>>> knows how strict is the dependence on the Module. In some cases, application
>>> can work without some Module but it's just better with it.
>>
>> First, both "use Module;" and "require Module;" (and "require '<file>';")
>> do automatic error checking and raise an exception if there is problem.
>
> for web applications, half of exceptions or more are generated when the user
> isn't the develioper.
> Notifications() via the logs are just enough and more than it: should be the
> prefered way of exceptions' notifications in a production.
> Why worry about return code then?
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.).
>> Second, "use Module <LIST>;" is equivalent to
>> BEGIN { require Module; import Module <LIST>; }
>> and therefore it doesn't make sense to use it for conditional inclusion.
>
> eval() is used there.
It's the fact that "use Module" uses BEGIN block that is incompatibile
with *conditional* using it from eval.
>>>> PSGI is interface, Plack is reference implementation. You can run PSGI
>>>> app on any supported web server; this includes running PSGI apps on
>>>> FastCGI.
>>>
>>> Existing problem FCGI::Spawn for is not the PSGI applications to be run as a
>>> FastCGI, but the bunch of existing CGI.pm applications (even gitorious) need
>>> to be more effective with the widest-spread protocol FastCGI. Best without any
>>> patching of the application, deployed the same simple way as with apache's cgi
>>> implementation.
>>
>> Gitorious is in Ruby, therefore is not a CGI.pm application, as it is
>> not even in Perl.
>
> It was Girocco you mentioned earlier
Girocco is shell scripts, not Perl either, see
http://repo.or.cz/w/girocco.git/tree
>> By using Plack::App::CGIBin you can load CGI scripts from a directory
>> and convert them into a <persistent> PSGI application. You can use
>
> Such a conversion is more than a compilation? Does it mean converted CGI app
> should be stored before to become a persistent application?
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
CGI::Compile manpage includes this example:
use CGI::Emulate::PSGI;
use CGI::Compile;
my $cgi_script = "/path/to/foo.cgi";
my $sub = CGI::Compile->compile($cgi_script);
my $app = CGI::Emulate::PSGI->handler($sub);
# $app is a PSGI application
>> Plack::App::WrapCGI to convert single CGI script into PSGI application.
>> You can use Plack::Buuilder's domain specific language to join (map)
>> together a bunch of PSGI applications (in different paths) in a single
>> app (via Plack::App::URLMap).
>
> And can the same process of that application server run for the several
> applications depending on the FastCGI request?
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.
>> You can then run PSGI application (for example the PSGI app which loads
>> CGI apps via Plack::App::CGIBin) on any supported web server, which
>> includes FCGI (FastCGI).
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html