You're face to face with man who sold the world, Jakub! 2010/05/14 19:58:15 +0200 Jakub Narebski <jnareb@xxxxxxxxx> => To Peter Vereshagin : JN> You don't see the parsing failure because "do <file>;" functions like JN> "eval", which traps exceptions. You will see consequences of parsing JN> failure (like not defined subroutine). JN> JN> > But you may see it with "use warnings;" right? JN> JN> "use warnings;" pragma doesn't help, because of the 'trapping JN> exceptions' part. That is why "require <file>" is recommended over JN> "do <file>". JN> Checking $@ after "do <file>" would cover the situation where there were JN> parsing errors, but wouldn't cover situation where file was not found, JN> 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? By far, people don't use to want the application should be trapped as inclusion fails and they are just sure to deal with the consequences. This is where the php is successful to offer include/include_once as well as its require* counterparters to offer such a choice to a developer. Are those consequences any danger anyway for applications like a gitweb? 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 ;-) JN> >> Second, "use Module <LIST>;" is equivalent to JN> >> BEGIN { require Module; import Module <LIST>; } JN> >> and therefore it doesn't make sense to use it for conditional inclusion. JN> > JN> > eval() is used there. JN> JN> It's the fact that "use Module" uses BEGIN block that is incompatibile JN> with *conditional* using it from eval. it works conditionally on those excerpts above. At the moment of the compilation, Perl doesn't know in general case what code should be eval()'d as its argument may vary at the runtime. Therefore Perl do not parse eval() string argument even if it is a constant. And thus it doesn't appear at the BEGIN{} execution moment. This is e.g., how the FCGI::Spawn works with CGI::Fast that defines the socket in its BEGIN{}. You may define your socket communications preference, the FCGI_SOCKET_PATH, on a shell before to start perl, or in the perl, before to eval "use CGI::Fast;" or eval "use FCGI::Spawn"; Both work just fine. JN> This convertion is JN> a.) compiling CGI file into subroutine (taking care of things like DATA JN> filehandle) using CGI::Compile JN> b.) converting between CGI interface and PSGI interface, using JN> CGI::Emulate::PSGI Sounds to me like all of that can happen in-memory. Great! JN> Yes, it can. Depending on request it would run appropriate JN> CGI-converted-to-PSGI application. JN> I am not sure how Plack::App::CGIBin works internally; it migh cimpile JN> all CGI applications upfront; but it might not. Will challenge. 73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627) -- http://vereshagin.org -- 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