You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kee Hinckley <na...@somewhere.com> on 2001/03/17 16:39:49 UTC
Debugging perl modules used by Embperl page
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Quite) a while back I complained about the problems of debugging a
module that's in use by an Embperl page.
[- use mylib; -]
...
The problem is that Embperl cashes mylib the first time it loads it,
and then you start getting really random results as you change mylib.
Some processes have new versions, some have old versions....
Maybe there's a better workaround, but I think I have a solution.
In the embperl file, or even in the library, add the following:
[- $req_rec->child_terminate(); -]
That will cause the current apache process to terminate after
processing this request, thus ensuring that the next time you execute
a request you'll get a different process that will (assuming it never
loaded this page before you added that line) have to load the library
again. That way you can keep editing the library and see the changes
without having to repeatedly reinitialize the Apache server.
Obviously you should take it out when you're done debugging--the
effect on performance is noticeable.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOrOFUyZsPfdw+r2CEQKw2wCg0PhsF1KTJldGk7eKtgxhgazhWQgAn2Ca
zXWKntPDdzbmXBBtZ8jFaLdd
=/waQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Gerald Richter <ri...@ecos.de>.
>
> Well, my goal was to keep the changes to the server config to a
> minimum. And to have different library paths for different sites.
>
Since @INC is global for the whole server, I prefer to keep it at one place,
but that's a matter of taste. At least you avoid the problem as you
described below.
>
> Now I'm dealing with a different problem. For some reason, once a
> process does a Reload, EmbperlObject stops working. It logs that
> it's unable to find the template file and the server returns a 404.
> And this happens in a site which doesn't use any reloaded libraries
> (that I know of). Very strange.
>
Could you send me a logfile from such a page with dbgObjectSearch set.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Kee Hinckley <na...@somewhere.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 8:05 PM +0100 3/18/01, Gerald Richter wrote:
>You should move the
>
> use lib "$ENV{DOCUMENT_ROOT}/libs";
>
>into your startup.pl file which is executed at server startup, then the lib
>path should be correctly set in all situations. But you have to replace
>$ENV{DOCUMENT_ROOT} with the real path, because it's not set inside
>startup.pl. I use this often without problems
Well, my goal was to keep the changes to the server config to a
minimum. And to have different library paths for different sites.
However, I've taken two steps forward and two back.
The problem with Apache::Reload was that the @INC variable may have
one value at the time of registration, and another at the time of the
reload. I'm talking to the author about that, but I came up with a
patch that caches the @INC contents at registration time and then
uses them in a local context at the reload time. That seems to work
fine.
Now I'm dealing with a different problem. For some reason, once a
process does a Reload, EmbperlObject stops working. It logs that
it's unable to find the template file and the server returns a 404.
And this happens in a site which doesn't use any reloaded libraries
(that I know of). Very strange.
Also, one usage note on Reload. Don't do anything like:
BEGIN {
$foo = $ENV{DOCUMENT_ROOT};
}
In your code, because when that library is reloaded the value of
DOCUMENT_ROOT maybe completely different, or even undefined. (That
would have been stupid code anywhere if it weren't a site-specific
library.)
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOrZAxCZsPfdw+r2CEQL53ACfbrbvGoiH/N05DxLVKWe5PHMlOQsAoP1p
1zMHsQ78U4xc3farvTDnfG91
=X+qZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Gerald Richter <ri...@ecos.de>.
>
> I tried that today and ran into a problem. Sometimes it doesn't seem
> to figure out the path to the file, and if it's not in @INC in at
> Apache loadtime, the apache process will die with an error when it
> tries to reload the file. My code looks like this:
>
> [-
> use lib "$ENV{DOCUMENT_ROOT}/libs";
> use XXX;
> -]
>
> Sometimes it does seem to work, but not always. I'm not sure what's
> going on, and I'm a little tired to try debugging it right now.
You should move the
use lib "$ENV{DOCUMENT_ROOT}/libs";
into your startup.pl file which is executed at server startup, then the lib
path should be correctly set in all situations. But you have to replace
$ENV{DOCUMENT_ROOT} with the real path, because it's not set inside
startup.pl. I use this often without problems
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Kee Hinckley <na...@somewhere.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 7:26 PM +0100 3/17/01, Gerald Richter wrote:
>Hi Kee,
>
>thanks for sharing this. I most cases you can use Apache::Reload. This
>modules checks on every request which Perl modules have changed and only
>reload the changed ones. You could also tell it, at which modules it should
>look. This works not in all cases like your solution (e.g. it doesn't work
>when you use pseudo hashs), but normaly it's a great tool.
I tried that today and ran into a problem. Sometimes it doesn't seem
to figure out the path to the file, and if it's not in @INC in at
Apache loadtime, the apache process will die with an error when it
tries to reload the file. My code looks like this:
[-
use lib "$ENV{DOCUMENT_ROOT}/libs";
use XXX;
-]
Sometimes it does seem to work, but not always. I'm not sure what's
going on, and I'm a little tired to try debugging it right now.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOrTaKiZsPfdw+r2CEQLfYQCghSKQBdIRLaKM4Xikpl66nLqPA/oAn2HF
OsquHI+itdYjXX3YKSoQg39r
=2joc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Gerald Richter <ri...@ecos.de>.
Hi Kee,
thanks for sharing this. I most cases you can use Apache::Reload. This
modules checks on every request which Perl modules have changed and only
reload the changed ones. You could also tell it, at which modules it should
look. This works not in all cases like your solution (e.g. it doesn't work
when you use pseudo hashs), but normaly it's a great tool.
Gerald
>
> (Quite) a while back I complained about the problems of debugging a
> module that's in use by an Embperl page.
>
> [- use mylib; -]
> ...
> The problem is that Embperl cashes mylib the first time it loads it,
> and then you start getting really random results as you change mylib.
> Some processes have new versions, some have old versions....
>
> Maybe there's a better workaround, but I think I have a solution.
>
> In the embperl file, or even in the library, add the following:
> [- $req_rec->child_terminate(); -]
> That will cause the current apache process to terminate after
> processing this request, thus ensuring that the next time you execute
> a request you'll get a different process that will (assuming it never
> loaded this page before you added that line) have to load the library
> again. That way you can keep editing the library and see the changes
> without having to repeatedly reinitialize the Apache server.
>
> Obviously you should take it out when you're done debugging--the
> effect on performance is noticeable.
>
>
>
> - --
>
> Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
> Now Playing - Folk, Rock, odd stuff -
http://www.somewhere.com/playlist.cgi
>
> I'm not sure which upsets me more: that people are so unwilling to accept
> responsibility for their own actions, or that they are so eager to
regulate
> everyone else's.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOrOFUyZsPfdw+r2CEQKw2wCg0PhsF1KTJldGk7eKtgxhgazhWQgAn2Ca
> zXWKntPDdzbmXBBtZ8jFaLdd
> =/waQ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
>
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: use <-> do (was: Debugging perl modules used by Embperl page)
Posted by Gerald Richter <ri...@ecos.de>.
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
----- Original Message -----
From: "Kee Hinckley" <na...@somewhere.com>
To: "goEbusiness.com Mail Lists" <ma...@goebusiness.com>
Cc: <em...@perl.apache.org>
Sent: Sunday, March 18, 2001 5:05 PM
Subject: Re: Debugging perl modules used by Embperl page
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> At 11:51 AM -0500 3/17/01, goEbusiness.com Mail Lists wrote:
> >You could just use "do" instead of "use".
>
> No, the semantics are different from "use". I haven't looked at the
> specifics, but it definitely doesn't work to use replace use with do.
I have written some words about use, require and do in the FAQs (see
http://perl.apache.org/embperl/Faq.pod.2.html#When_I_use_a_module_inside_a_E
mb)
Basicly do executes a script at runtime, while use loads a modules and
optionaly imports globals vars at compile time. Also use only searchs the
@INC paths, while do requires a filename
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by Kee Hinckley <na...@somewhere.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 11:51 AM -0500 3/17/01, goEbusiness.com Mail Lists wrote:
>You could just use "do" instead of "use".
No, the semantics are different from "use". I haven't looked at the
specifics, but it definitely doesn't work to use replace use with do.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOrTgXiZsPfdw+r2CEQKL/gCcCH8lG4i538wraij0BrTx4w7hbQkAoLhb
KPjKfh45RmJdjpxjrj1tOgt7
=/esR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Debugging perl modules used by Embperl page
Posted by "goEbusiness.com Mail Lists" <ma...@goebusiness.com>.
You could just use "do" instead of "use".
Bill
On Sat, 17 Mar 2001, Kee Hinckley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> (Quite) a while back I complained about the problems of debugging a
> module that's in use by an Embperl page.
>
> [- use mylib; -]
> ...
> The problem is that Embperl cashes mylib the first time it loads it,
> and then you start getting really random results as you change mylib.
> Some processes have new versions, some have old versions....
>
> Maybe there's a better workaround, but I think I have a solution.
>
> In the embperl file, or even in the library, add the following:
> [- $req_rec->child_terminate(); -]
> That will cause the current apache process to terminate after
> processing this request, thus ensuring that the next time you execute
> a request you'll get a different process that will (assuming it never
> loaded this page before you added that line) have to load the library
> again. That way you can keep editing the library and see the changes
> without having to repeatedly reinitialize the Apache server.
>
> Obviously you should take it out when you're done debugging--the
> effect on performance is noticeable.
>
>
>
> - --
>
> Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
> Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
>
> I'm not sure which upsets me more: that people are so unwilling to accept
> responsibility for their own actions, or that they are so eager to regulate
> everyone else's.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOrOFUyZsPfdw+r2CEQKw2wCg0PhsF1KTJldGk7eKtgxhgazhWQgAn2Ca
> zXWKntPDdzbmXBBtZ8jFaLdd
> =/waQ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org