Mailing List Archive: undefined subs?

undefined subs?

May 13, 2000, 4:37 PM

Post #1 of 4 (1369 views)

Greetings,

Quite simply put - I have a little library of commonly used subs which I
would like to require at the top of each page.. so I have:

[.-
use POSIX qw(ctime);

require "/opt/sage/lib/sagelib.pl";

$rv = selectall_dialin_account( $fdat{directory_id} );
-]

In on a page ( the fdat stuff is defined and all is well) - in sagelib, I
have:

sub selectall_dialin_account {

use DBI;

my ( $directory_id ) = @_;

$sage_dbh = DBI->connect( "DBI:Pg:dbname=sage;host=localhost",
username, password ) or die "Error:" . $DBI::errstr . "\n";

$sth = $sage_dbh->prepare("select
directory_id,username,password,encryptedpassword,account_type,checkattr,replyattr,created_by,record_created,record_modified
from dialin_account_data where directory_id='$directory_id'") or die
"Error:" . $DBI::errstr . "\n";

$numrows = $sth->execute or die "Error:" . $DBI::errstr . "\n";

if ( $numrows > 0 ) {
return $sth;
}
else {
return;
}

1;

In theory this should happily work right? I.e. a non-embperl script from
the command-line - the above happily returns a ref...

Although using a browser etc - it keeps whinging at me:

Error in Perl code: Undefined subroutine
&HTML::Embperl::DOC::_1::selectall_dialin_account called at
/opt/apache/htdocs/admin/services/dialin/select.epl line 14.

Any help would be copiously appreciated. :)

//umar.

Re: undefined subs? [ In reply to ]

solution at gina

May 13, 2000, 7:32 PM

Post #2 of 4 (1329 views)

Permalink

Umar Goldeli wrote:

> Greetings,
>
> Quite simply put - I have a little library of commonly used subs which I
> would like to require at the top of each page.. so I have:
>
> [.-
> use POSIX qw(ctime);
>
> require "/opt/sage/lib/sagelib.pl";
>
> $rv = selectall_dialin_account( $fdat{directory_id} );
> -]
>
> In on a page ( the fdat stuff is defined and all is well) - in sagelib, I
> have:
>
> sub selectall_dialin_account {
>
> use DBI;
>
> my ( $directory_id ) = @_;
>
> $sage_dbh = DBI->connect( "DBI:Pg:dbname=sage;host=localhost",
> username, password ) or die "Error:" . $DBI::errstr . "\n";
>
> $sth = $sage_dbh->prepare("select
> directory_id,username,password,encryptedpassword,account_type,checkattr,replyattr,created_by,record_created,record_modified
> from dialin_account_data where directory_id='$directory_id'") or die
> "Error:" . $DBI::errstr . "\n";
>
> $numrows = $sth->execute or die "Error:" . $DBI::errstr . "\n";
>
> if ( $numrows > 0 ) {
> return $sth;
> }
> else {
> return;
> }
>
> 1;
>
> In theory this should happily work right? I.e. a non-embperl script from
> the command-line - the above happily returns a ref...
>
> Although using a browser etc - it keeps whinging at me:
>
> Error in Perl code: Undefined subroutine
> &HTML::Embperl::DOC::_1::selectall_dialin_account called at
> /opt/apache/htdocs/admin/services/dialin/select.epl line 14.
>
> Any help would be copiously appreciated. :)
>
> //umar.

Umar,

Try 'do' instead of 'require'. Has something to do with the namespace in which Embperl runs required files. Another option
(better?) is to make the file you are requiring into a module (package) and then use 'use' instead 'require'.

[.-
use POSIX qw(ctime);

do "/opt/sage/lib/sagelib.pl";

$rv = selectall_dialin_account( $fdat{directory_id} );
-]

Gerald,

Is my understanding correct in that the required files subs go out of scope as soon as the required file is done compling? I
am not sure if this is how it is supposed to work so I am not sure if it a bug or feature, but I have been using 'do' as a work
around for the last 1.5+ years.

Aaron Johnson

Re: undefined subs? [ In reply to ]

umar at atlas

May 13, 2000, 11:44 PM

Post #3 of 4 (1338 views)

Permalink

Aaron,

Thank you copiously - "do" works beautifully :)

(I shall eventually read the doco on how to make modules - but for now -
"do" is wonderful).

//umar.

> Try 'do' instead of 'require'. Has something to do with the namespace
> in which Embperl runs required files. Another option (better?) is to
> make the file you are requiring into a module (package) and then use
> 'use' instead 'require'.

RE: undefined subs? [ In reply to ]

richter at ecos

May 14, 2000, 5:29 AM

Post #4 of 4 (1334 views)

Permalink

>
> Gerald,
>
> Is my understanding correct in that the required files subs go
> out of scope as soon as the required file is done compling? I
> am not sure if this is how it is supposed to work so I am not
> sure if it a bug or feature, but I have been using 'do' as a work
> around for the last 1.5+ years.
>

I append a mail I send some days ago to the list, which should explain what
happens. This will also become a part of the Faq. Hope this helps, if not
let me know

Gerald

> -----Original Message-----
> From: embperl-return-275-richter=ecos.de@perl.apache.org
> [mailto:embperl-return-275-richter=ecos.de@perl.apache.org]On Behalf Of
> Gerald Richter
> Sent: Friday, April 21, 2000 9:10 PM
> To: Ulrike Schepp; Steven D. Arnold
> Cc: Embperl Mailingliste
> Subject: RE: use module in Embperl (was: problem solved, but still
> weird!)
>
>
> >
> > Standard workaround here is now "apachectl restart" after the change of
> > modules :-/ weird but it really works!
> >
>
> Nothing weird here. Everything is well defined. Just let us try to
> understand how Perl, mod_perl and Embperl works together:
>
> "perldoc -f use" tells us:
>
> Imports some semantics into the current package from the named module,
> generally by aliasing certain subroutine or variable names into your
> package. It is exactly equivalent to
>
> BEGIN { require Module; import Module LIST; }
>
> except that Module must be a bareword.
>
> So what's important here for us is, that use executes a require
> and this is
> always done before any other code is executed.
>
> "perldoc -f require" says (among other things):
>
> ..., demands that a library file be included if it hasn't already
> been included.
>
> and
>
> Note that the file will not be included twice under the same specified
> name.
>
> So now we know (or should know) that mod_perl starts the Perl interpreter
> once when Apache is started and the Perl interpreter is only
> terminated when
> Apache is terminated. Out of these two things follows, that a
> module that is
> loaded via use or require is only loaded once and will never be reloaded,
> regardless if the source changes or not.
>
> So far this is just standard Perl. Things get's a little bit more
> difficult
> when running under mod_perl (only Unix), because Apache forks a
> set of child
> processes as neccessary and from the moment they are forked, they run on
> their own and don't know of each other. So if a module is loaded at server
> startup time (before the fork), it is loaded in all childs (this
> can be used
> to save memory, because the code will actually only reside once
> in memory),
> but when the modul is loaded inside the child and the source changes, it
> could be happen, that one child has loaded an ealier version and another
> child has loaded a later version of that module, depending on the time the
> module is actualy loaded by the child.
>
> That explains, why sometimes it works and sometimes it doesn't, simply
> because different childs has loaded different versions of the same module
> and when you reload your page you hit different childs of Apache!
>
> Now there is one point that is special to Embperl to add. Since Embperl
> compiles every page in a different namespace, a module that
> doesn't contains
> a "package foo" statement is compiled in the namespace of the
> page where it
> is first loaded. Because Perl will not load the module a second
> time, every
> other page will not see subs and vars that are defined in the
> loaded module.
> This could be simply avoided by giving every module that should be loaded
> via use/require an explicit namespace via the package statement.
>
> So what can we do?
> - If a module change, simply restart Apache. That's works always.
> - use Apache::StatInc. This will do a stat on every loaded module and
> compare the modification time. If the source has changed the module is
> reloaded. This works most times (but not all modules can be cleanly
> reloaded) and as the number of loaded modules increase, your
> sever will slow
> down, because of the stat it has to do for every module.
> - Use "do" instead of "require". do will execute your file everytime it is
> used. This also adds overhead, but this may be accpetable for
> small files or
> in a debugging environement. (NOTE: Be sure to check $@ after a
> do, because
> do works like eval)
>
> I hope now it's seem a little bit less weird..
>
> 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 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
>