Re: libgtop gone?

[Stephen Clouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jan 29, 2003 at 12:44:37AM -0500, Perrin Harkins wrote:
> This guy was on HPUX, and he just wanted source to this one library.  It 
> used to be available separately.  I guess it's not a simple thing to do 
> at this point if you don't want gnome and aren't on Red Hat.

http://ftp.gnome.org/pub/GNOME/desktop/2.0/2.0.3/sources/libgtop-2.0.0.tar.gz

I haven't checked this myself (it may want some other GNOME component) but it's
a good start.

- -- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+N3paA4aoazQ9p2cRAmvzAKDprrKc2Ixv+zDwER0reJ4L7pKjJQCfeaop
9aurfdiQJ1/VEitgkvCK2WY=
=CClG
-END PGP SIGNATURE-

Re: libgtop gone?

[Stas Bekman]

Perrin Harkins wrote:

Stas Bekman wrote:


It's integrated into the gnome project and doesn't really exist as a 
standalone thing. At least I couldn't find it. When you install the 
gnome desktop, you get libgtop as well. So if you are on linux, simply 
check your distro for this package. e.g. use:

http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop

in the worst case use the above resource to grap the src.rpm and then 
extract tar.gz from there.


This guy was on HPUX, and he just wanted source to this one library.  It 
used to be available separately.  I guess it's not a simple thing to do 
at this point if you don't want gnome and aren't on Red Hat.

As I've mentioned, you can extract the source from the source rpm( either via 
'rpm -i ...src.rpm' or using rpm2cpio). I've browsed the headers and it seems 
from libgtop-1.0/glibtop/global.h, that the gnome support is optional. Though 
you probably will have problems building on non-linux/bsd systems. I remember 
it was reported to work on certain Solaris systems. In any case they can 
always give it a try and in the worst case try to port it.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: libgtop gone?

[Perrin Harkins]

Stas Bekman wrote:

It's integrated into the gnome project and doesn't really exist as a 
standalone thing. At least I couldn't find it. When you install the 
gnome desktop, you get libgtop as well. So if you are on linux, simply 
check your distro for this package. e.g. use:

http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop

in the worst case use the above resource to grap the src.rpm and then 
extract tar.gz from there.

This guy was on HPUX, and he just wanted source to this one library.  It 
used to be available separately.  I guess it's not a simple thing to do 
at this point if you don't want gnome and aren't on Red Hat.

- Perrin

Re: libgtop gone?

[Stas Bekman]

Perrin Harkins wrote:

I pointed someone at some mod_perl documentation that suggested 
installing GTop to measure shared memory, but he was unable to find 
libgtop for download at the URL in that module.  I investigated and I 
don't see it anywhere!  Is libgtop gone?  Did it get replaced with 
something else?  Any Gnome followers here who can shed some light on this?

It's integrated into the gnome project and doesn't really exist as a 
standalone thing. At least I couldn't find it. When you install the gnome 
desktop, you get libgtop as well. So if you are on linux, simply check your 
distro for this package. e.g. use:

http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop

in the worst case use the above resource to grap the src.rpm and then extract 
tar.gz from there.

If somebody here is involved deeper with gnome, please share some light with us.

While we are at this topic, I've patched GTop-0.10 to support libgtop-2.0 and 
libgtop-1.0 automatically (attached).

I've also backported it to 5.005_03 by including ppport.h in it. Hopefully 
Doug will release the new version soonish.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
--- GTop-0.10/Makefile.PL   2000-01-26 11:25:02.0 +1100
+++ GTop-0.10-dev/Makefile.PL   2002-12-27 11:36:26.0 +1100
@@ -231,12 +231,14 @@
 );
 }
 
+my %config = get_glibtop_config();
+
 WriteMakefile(
@insure,
NAME => 'GTop',
VERSION_FROM => 'GTop.pm',
-   INC => $GTOP_INCLUDE . $ginc,
-   LIBS => [$GTOP_LIB . "-lgtop -lgtop_sysdeps -lgtop_common -lglib $xlibs"],
+   INC => join(" ", $GTOP_INCLUDE, $ginc, $config{incs}),
+   LIBS => [join(" ", $GTOP_LIB, $config{libs})],
TYPEMAPS => [qw(typemap.gtop typemap)],
clean   => {
FILES => "@{[<*.boot>, <*.gtop>]}",
@@ -255,3 +257,27 @@
 EOF
 } 
 
+# get libgtop CFLAGS/LIBS across 1.x-2.x versions
+sub get_glibtop_config {
+my %c = ();
+
+if (system('pkg-config --exists libgtop-2.0') == 0) {
+# 2.x
+chomp($c{incs} = qx|pkg-config --cflags libgtop-2.0|);
+chomp($c{libs} = qx|pkg-config --libs   libgtop-2.0|);
+
+# 2.0.0 bugfix
+chomp(my $libdir = qx|pkg-config --variable=libdir libgtop-2.0|);
+$c{libs} =~ s|\$\(libdir\)|$libdir|;
+}
+elsif (system('gnome-config --libs libgtop') == 0) {
+chomp($c{incs} = qx|gnome-config --cflags libgtop|);
+chomp($c{libs} = qx|gnome-config --libs   libgtop|);
+
+# buggy ( < 1.0.9?) versions fixup
+$c{incs} =~ s|^/|-I/|;
+$c{libs} =~ s|^/|-L/|;
+}
+
+return %c;
+}
--- GTop-0.10/Server/Makefile.PL2000-02-01 09:05:49.0 +1100
+++ GTop-0.10-dev/Server/Makefile.PL2002-12-27 11:36:26.0 +1100
@@ -36,13 +36,41 @@
 close FH;
 close CONST;
 
+my %config = get_glibtop_config();
+
 WriteMakefile(
 NAME => "GTop::Server",
 VERSION_FROM => "Server.pm",
-INC => $GTOP_INCLUDE . $ginc,
-LIBS => [$GTOP_LIB . "-lgtop -lgtop_sysdeps -lgtop_common -lglib"],
+INC => join(" ", $GTOP_INCLUDE, $ginc, $config{incs}),
+LIBS => [join(" ", $GTOP_LIB, $config{libs})],
 OBJECT => 'io.o main.o gnuserv.o version.o access.o Server.o',
 clean   => {
FILES => "server_config_flags.h constants.c",
 },
 );
+
+
+# get libgtop CFLAGS/LIBS across 1.x-2.x versions
+sub get_glibtop_config {
+my %c = ();
+
+if (system('pkg-config --exists libgtop-2.0') == 0) {
+# 2.x
+chomp($c{incs} = qx|pkg-config --cflags libgtop-2.0|);
+chomp($c{libs} = qx|pkg-config --libs   libgtop-2.0|);
+
+# 2.0.0 bugfix
+chomp(my $libdir = qx|pkg-config --variable=libdir libgtop-2.0|);
+$c{libs} =~ s|\$\(libdir\)|$libdir|;
+}
+elsif (system('gnome-config --libs libgtop') == 0) {
+chomp($c{incs} = qx|gnome-config --cflags libgtop|);
+chomp($c{libs} = qx|gnome-config --libs   libgtop|);
+
+# buggy ( < 1.0.9?) versions fixup
+$c{incs} =~ s|^/|-I/|;
+$c{libs} =~ s|^/|-L/|;
+}
+
+return %c;
+}

Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

  works with mod_include Got a [an error 
occurred while processing this directive] (well actually the errmsg that 
I had set) with CGI::SSI. As I said I didn't really follow-up to see if 
this is a prob.

Oh, sorry, I missed the part about CGI::SSI.  That will work with 
mod_include (and thus with Apache::Include).

It does not implement SSI, it just integrates an extra tag (#perl) 
into mod_include.  Everything that works in your current mod_include 
pages should continue to work.

Oh kinda like embedding perl code in an shtml?


It lets you run any Perl subroutine in the middle of a page.  It also 
lets you include files (a "virtual include") from within a Perl script 
by calling the Apache::Include module.

Actually I haven't got this to work. I'm yet trying to figure how to 
load the module (PerlModule Apache::SSI) in the .htaccess with it 
actuall residing in the "/perl/" directory rather than the standard lib 
directories.

Why?  It's a module, not a CGI script.

If you don't want to put it in your standard @INC paths, you can put it 
under /lib/perl/ which is automatically added to @INC by 
mod_perl.

- Perrin

libgtop gone?

[Perrin Harkins]

I pointed someone at some mod_perl documentation that suggested 
installing GTop to measure shared memory, but he was unable to find 
libgtop for download at the URL in that module.  I investigated and I 
don't see it anywhere!  Is libgtop gone?  Did it get replaced with 
something else?  Any Gnome followers here who can shed some light on this?

- Perrin

Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)

[perl]

At 06:54 PM 1/28/2003, Perrin Harkins wrote:

[EMAIL PROTECTED] wrote:

Tks that way worked except for the #config sizefmt of mod_include


That should work fine.  What's broken with it?


(Frankly I'm so eagar to not just get my feet wet in mod_perl (just started 
on it today), but drown in it I didn't follow up on this prob.)

  works with mod_include Got a [an error 
occurred while processing this directive] (well actually the errmsg that I 
had set) with CGI::SSI. As I said I didn't really follow-up to see if this 
is a prob.

From the documentation of the Apache::Include I couldn't make out 
whether it handled other features like set which I am using.

It does not implement SSI, it just integrates an extra tag (#perl) into 
mod_include.  Everything that works in your current mod_include pages 
should continue to work.

Oh kinda like embedding perl code in an shtml?


But your siggestion led me to search on CPAN and found Apache::SSI.


Apache::SSI is good too.  It will use more RAM, but it is slightly faster 
than mod_include.

Actually I haven't got this to work. I'm yet trying to figure how to load 
the module (PerlModule Apache::SSI) in the .htaccess with it actuall 
residing in the "/perl/" directory rather than the standard lib directories.

Tks
Dr 

Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

Tks that way worked except for the #config sizefmt of mod_include


That should work fine.  What's broken with it?


 From the documentation of the Apache::Include I couldn't make out 
whether it handled other features like set which I am using.

It does not implement SSI, it just integrates an extra tag (#perl) into 
mod_include.  Everything that works in your current mod_include pages 
should continue to work.

But your 
siggestion led me to search on CPAN and found Apache::SSI.

Apache::SSI is good too.  It will use more RAM, but it is slightly 
faster than mod_include.

- Perrin

Re: glitched install of mod_perl (1.99.08)

[Stas Bekman]

Stephen Clouse wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jan 27, 2003 at 06:25:26PM +1100, Stas Bekman wrote:


Hmm, you have perl 5.8.0. How is it possible that you don't have CGI.pm, 
which is a part of the core?


It's probably a perl installed from a vendor-supplied package.  You'd be amazed
at the shreds the standard Perl distribution can get ripped to.

Redhat I know splits a standard Perl installation into no less than 20 packages. 
CGI,pm and friends get shoved off off into their own RPM (perl-CGI).  Other
Linux distros I can't speak for but they tend to be similar.

In short, don't assume that their kit is complete.  Their vendor may have done
them a "favor" via package management.

I wonder what would be the best way to handle that, require CGI.pm for 
installing mod_perl or simply adjust the tests to skip, if it's not available.
It's just silly that we rely on the knowledge that certain modules are a part 
of the core, and the vendors break that assumption :(

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod_perl and current directory (was Re: Newbie Q on Apache::Include)

[Stas Bekman]

[...]

> Is it true what was said in one of the other

threads -with mod_perl (Apache 1.3.27) the current working directory is 
different from the dir where the script lies?

[...]

As I've followed up (because I knew that that particular post will create 
confusion), it *is* the script's dir for mod_perl 1.x. (Apache::Registry and 
friends)

It's *currently* not the case with mod_perl 2.0 (ModPerl::Registry and 
friends), but this should change to be the same as 1.x by the time 2.0 is 
released.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Stacked Handlers Execution Chain

[Stas Bekman]

Geoffrey Young wrote:




First of all let's clear up the 1.0 side:

Quoting the eagle book:

  The exception to this rule [all handlers will run] is if one of
  the handlers in the series returns an error code (anything other than
  OK, DECLINED, or DONE)

Though the code does *not* check for DONE:

mod_perl.c:1375
if((status != OK) && (status != DECLINED)) {
...
return status;
}

so where is the bug? In the book or the code?



well, OK, DECLINED, and DONE are all success codes - everything else is 
an error and goes to the error document cycle.


however, DONE is special - it indicates that all content has been sent 
 and the request cycle should proceed straight to the logging phase. 
 from a handler perspective, DONE behaves the same as an error code - it 
terminates the request cycle.

But the book doesn't say that DONE does break the chain, though it does.


I suspect that 1.0 logic handled DONE automatically - DONE was captured 
and passed back to Apache, which took appropriate action. and I suspect 
this is what you found in 2.0, since you test for DONE but didn't handle 
it explicitly.

It works exactly the same in 2.0 as in 1.0 (using the current cvs ;), the 
chain is aborted on !(OK || DECLINED). Any return codes are passed further to 
Apache.

kudos, stas, for always taking care of all the 2.0 stuff.


;)

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Stacked Handlers Execution Chain

[Geoffrey Young]

First of all let's clear up the 1.0 side:

Quoting the eagle book:

  The exception to this rule [all handlers will run] is if one of
  the handlers in the series returns an error code (anything other than
  OK, DECLINED, or DONE)

Though the code does *not* check for DONE:

mod_perl.c:1375
if((status != OK) && (status != DECLINED)) {
...
return status;
}

so where is the bug? In the book or the code?


well, OK, DECLINED, and DONE are all success codes - everything else 
is an error and goes to the error document cycle.

however, DONE is special - it indicates that all content has been sent 
 and the request cycle should proceed straight to the logging phase. 
 from a handler perspective, DONE behaves the same as an error code - 
it terminates the request cycle.

I suspect that 1.0 logic handled DONE automatically - DONE was 
captured and passed back to Apache, which took appropriate action. 
and I suspect this is what you found in 2.0, since you test for DONE 
but didn't handle it explicitly.

kudos, stas, for always taking care of all the 2.0 stuff.

--Geoff

mod_perl and current directory (was Re: Newbie Q on Apache::Include)

[perl]

You can do this.  Technically I think you can POST to a file, but you 
don't need to.

You can do this lots of ways, including post-processing the output of a 
CGI script with a module like CGI::SSI.  What I

Tks that way worked except for the #config sizefmt of mod_include


would suggest is writing a script that you will run under 
Apache::Registry, and calling Apache::Include->virtual('/uri/of/file') to 
do the includes.

From the documentation of the Apache::Include I couldn't make out whether 
it handled other features like set which I am using. But your siggestion 
led me to search on CPAN and found Apache::SSI. That was reasonably 
well-documented and I was planning on using it except the module couldn't 
be found. Is it true what was said in one of the other threads -with 
mod_perl (Apache 1.3.27) the current working directory is different from 
the dir where the script lies? If so how does one use code organized uder 
one's own directory? (Need to know this as my host does not want to install 
modules for me.)

Rgds
Dr

Re: Stacked Handlers Execution Chain

[Stas Bekman]

Try again with the current cvs. You can look at the test 
t/hooks/TestHooks/stacked_handlers.pm which aborts the execution chain when 
Apache::DONE is returned.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Stacked Handlers Execution Chain

[Stas Bekman]

Geoffrey Young wrote:



Helmut Zeilinger wrote:


Hi,

i am using mod_perl 1.99_08.

I have two mod_perl handlers:

...
PerlResponseHandler Test::handler0 Test::handler1
...

How can i brake the execution chain between handler0 and handler1? 
Whatever i try as handler0 return value (OK, DECLINED, FORBIDDEN, 404)
the handler1 is still executed. The documentation says, that any value
except DECLINED should do that.

The documentation talks about a normal (one per phase) handler, not stacked 
handlers. Which certainly should be covered in the docs as well.

it probably should say that OK, DECLINED, or DONE will allow the chain 
to continue.  anything else ought to immediately terminate the chain - 
if not, it's probably a bug.  you might want to see if there is a 
difference between returning FORBIDDEN, NOT_FOUND, and SERVER_ERROR 
(well, their 2.0 equivalents, anyway), just to help track things down.

First of all let's clear up the 1.0 side:

Quoting the eagle book:

  The exception to this rule [all handlers will run] is if one of
  the handlers in the series returns an error code (anything other than
  OK, DECLINED, or DONE)

Though the code does *not* check for DONE:

mod_perl.c:1375
	if((status != OK) && (status != DECLINED)) {
		...
		return status;
	}

so where is the bug? In the book or the code?

Now the 2.0 side:

Currently it runs all handlers no matter what, I'll fix that soon to do the 
same as in 1.0: i.e. checking for OK and DECLINED but not for 'DONE' to be 
consistent with 1.0.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: "do" as temp solution for "require" problem ?

[Stas Bekman]

Justin Luster wrote:

When a Perl script runs under Mod_Perl the current working directory is
no longer the location of the Perl script (I think it is where
Apache.exe is).  

You are talking about 2.0 here. And it should change to normal by the time its 
released. This issue is irrelevant to the original question.



__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Installation help

[Stas Bekman]

Blankenship, Scott R wrote:

I'm on SunOS 5.6 (Solaris 2.6)

I've installed perl 5.8.0 in own test area (not in /usr/local/...)

Here's a link to the log of my installation efforts:
http://home.earthlink.net/~sblanky/log.html

Basically, I extract mod_perl 1.27, and apache 1.3.1, go through the
mod_perl isntallation, it adds to my perl libraries, but I can't apache
installed. I go to the src directory, do a make, but the make install at the
end says I have to go to the parent directory to install. But, there's no
Makefile in the parent directory... 

What am I doing wrong?

Where have you picked these instructions? Your mistake (as seen from the neat 
log) is that you go and reconfigure Apache after mod_perl has done this for 
you already. See:
http://perl.apache.org/docs/1.0/guide/install.html

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

[ANNOUNCE] libapreq-1.1 is out

[Joe Schaefer]

libapreq-1.1 is now available on CPAN,
and also through the Apache website at

  http://www.apache.org/dist/httpd/libapreq/libapreq-1.1.tar.gz

-- 
Joe Schaefer

RE: Installation help

[Blankenship, Scott R]

I should be more specific:

blankesr@oh01ux02 Tue 28 5:34pm:~/www/apache/bin>httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  mod_perl.c < looks good

(1) blankesr@oh01ux02 Tue 28 5:34pm:~/www/apache/bin>httpd -v
Server version: Apache/1.3.27 (Unix)
Server built:   Jan 28 2003 17:28:27

It appears mod_perl still isn't in the apache server.

-Original Message-
From: Blankenship, Scott R 
Sent: Tuesday, January 28, 2003 5:20 PM
To: 'Ged Haywood'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Installation help


thanks. I downloaded 1.3.27... Still can't get it to install mod_perl into
apache... 

-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 3:39 PM
To: Blankenship, Scott R
Cc: '[EMAIL PROTECTED]'
Subject: Re: Installation help


Hi there,

On Tue, 28 Jan 2003, Blankenship, Scott R wrote:

> Basically, I extract mod_perl 1.27, and apache 1.3.1 [snip]
> What am I doing wrong?

Are you sure you want to use Apache 1.3.1?
I'm using 1.3.27 for new builds...

73,
Ged.

RE: Installation help

[Blankenship, Scott R]

thanks. I downloaded 1.3.27... Still can't get it to install mod_perl into
apache... 

-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 3:39 PM
To: Blankenship, Scott R
Cc: '[EMAIL PROTECTED]'
Subject: Re: Installation help


Hi there,

On Tue, 28 Jan 2003, Blankenship, Scott R wrote:

> Basically, I extract mod_perl 1.27, and apache 1.3.1 [snip]
> What am I doing wrong?

Are you sure you want to use Apache 1.3.1?
I'm using 1.3.27 for new builds...

73,
Ged.

Re: "do" as temp solution for "require" problem ?

[Randal L. Schwartz]

> "Justin" == Justin Luster <[EMAIL PROTECTED]> writes:

Justin> When a Perl script runs under Mod_Perl the current working directory is
Justin> no longer the location of the Perl script (I think it is where
Justin> Apache.exe is).  So when you require an additional file it does not look
Justin> in the same directory as your original script for the file.  One
Justin> alternative that has been mentioned is to place your included file in
Justin> one of the locations of the @INC array.  Another option that I have used
Justin> is to add the path of the original Perl file to the @INC array so that
Justin> included files will be looked for there too.

But that's not the problem here.

See the other postings in this thread.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Installation help

[Ged Haywood]

Hi there,

On Tue, 28 Jan 2003, Blankenship, Scott R wrote:

> Basically, I extract mod_perl 1.27, and apache 1.3.1 [snip]
> What am I doing wrong?

Are you sure you want to use Apache 1.3.1?
I'm using 1.3.27 for new builds...

73,
Ged.

RE: "do" as temp solution for "require" problem ?

[Justin Luster]

When a Perl script runs under Mod_Perl the current working directory is
no longer the location of the Perl script (I think it is where
Apache.exe is).  So when you require an additional file it does not look
in the same directory as your original script for the file.  One
alternative that has been mentioned is to place your included file in
one of the locations of the @INC array.  Another option that I have used
is to add the path of the original Perl file to the @INC array so that
included files will be looked for there too.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, January 28, 2003 11:51 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: "do" as temp solution for "require" problem ?

Hi,
Yes, I am using Apache::Registry; how did you know that? ;-)
In fact I am trying to change the CGI-Perl pages of 
http://www.deweertsport.be to mod_perl.
As I was used to work with include files in PHP, I sort continued this 
way of making pages in Perl-CGI.
If you look at the previous mentioned site, you can see there is only 
one file, but it contains a lot of includes.
- a random function for the banners on top
- a file for the navigation on the left which includes a file for the 
date and a file for the counter (mysql database)
- the content pages with different files for the forms redirected per 
OS and type of Browser.
The reason why I work that way is to have a sort of frame in which the 
content is included, directed via the variables of the URL.
That gives me a good overview on how the site is built and it makes it 
easy to maintain.
Now, with mod_per this is a whole different story. Probably I need to 
review my strategy as things get more complicated regarding using 
"use", or "require" ... or "do" 
Would using Apache::PerlRun be a better option to deal with this way of 
building a website?
Thanks for your advise!
Bart

On Tuesday, January 28, 2003, at 05:21 PM, Randal L. Schwartz wrote:

>> "mail@adventureforum" == mail@adventureforum net 
>> <[EMAIL PROTECTED]> writes:
>
> mail@adventureforum> I am using: mod_perl/1.26
>
> mail@adventureforum> Now I tried to include subroutines from an 
> external .pl file with
> mail@adventureforum> "require".
>
> This smells a bit like you're using Apache::Registry (you haven't said
> yet) and you've moved some subroutines into a separate file, but not a
> separate package, and you either aren't aware or don't understand the
> significance of the fact that every Apache::Registry script runs in a
> different package.
>
> Could that be the case?
>
> If you're using Apache::Registry, and you're not properly using
> packages, you'll get burned.  Turn your external code into a real
> module, and things will work again.  Use "use", not "require", not
> "do".
>
> print "Just another (mod) Perl hacker,"
>
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777

> 0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl 
> training!
>

Re: Newbie Q on Apache::Include

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

My personal web site has both static and dynamic files. The static files 
have a kind a "look template" maintained by using XSSI. For the dynamic 
files I wanted to somehow be able to do the same thing using the same 
files so that I don't need to maintain 2 sets of files. Of the set of 
scripts there are some that handle forms. I could have the shtml include 
the script and pass on the query_string. But I want these to be of type 
POST. So I can't have the form handler to be an shtml file (having the 
"look") which would call (!--#include ) the cgi script. I need the 
opposite - parsing of the script output.

Then I thought I would check if it was possible with mod_perl and found 
Apache::Include. This seemed promising to achieve what I would like to 
do - use the same files (that maintain the look of my web site) for both 
the static and dynamic pages.

You can do this.  Technically I think you can POST to a file, but you 
don't need to.

You can do this lots of ways, including post-processing the output of a 
CGI script with a module like CGI::SSI.  What I would suggest is writing 
a script that you will run under Apache::Registry, and calling 
Apache::Include->virtual('/uri/of/file') to do the includes.

- Perrin

Re: "do" as temp solution for "require" problem ?

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

If you look at the previous mentioned site, you can see there is only 
one file, but it contains a lot of includes.
- a random function for the banners on top
- a file for the navigation on the left which includes a file for the 
date and a file for the counter (mysql database)
- the content pages with different files for the forms redirected per OS 
and type of Browser.

You seem to be talking about including chunks of the page, like 
server-side includes (SSI).  That's not the same as doing a require/use 
on a module.  Modules are for storing chunks of Perl code, not HTML.

You originally asked about why your subs from required files were not 
working.  That's what Stas and Randal are telling you: you need to make 
them into real modules with "package" declarations.  There are other 
ways to do it (like "do") but they are kludges.

If you're looking for something to help you manage splitting pages up 
into chunks of HTML, you should consider either using SSI () or using HTML::Mason, 
which is based around that idea.

- Perrin

Installation help

[Blankenship, Scott R]

I'm on SunOS 5.6 (Solaris 2.6)

I've installed perl 5.8.0 in own test area (not in /usr/local/...)

Here's a link to the log of my installation efforts:
http://home.earthlink.net/~sblanky/log.html

Basically, I extract mod_perl 1.27, and apache 1.3.1, go through the
mod_perl isntallation, it adds to my perl libraries, but I can't apache
installed. I go to the src directory, do a make, but the make install at the
end says I have to go to the parent directory to install. But, there's no
Makefile in the parent directory... 

What am I doing wrong?

Scott Blankenship
Senior Developer
The Relizon Company
937.630.9813, mail stop 02-10
[EMAIL PROTECTED]
"You can put your boots in the oven, but that doesn't make them biscuits"

Re: Newbie Q on Apache::Include

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

Can someone direct me to a good tutorial for Apache::Include?


What are you trying to do?  All it does is add one extra directive to 
mod_include, allowing you to call a Perl script in-line.  If that script 
is run under Apache::Registry, you don't even need to do that; you can 
use the normal syntax for a virtual include.

- Perrin

Re: "do" as temp solution for "require" problem ?

[[EMAIL PROTECTED]]

Hi,
Yes, I am using Apache::Registry; how did you know that? ;-)
In fact I am trying to change the CGI-Perl pages of 
http://www.deweertsport.be to mod_perl.
As I was used to work with include files in PHP, I sort continued this 
way of making pages in Perl-CGI.
If you look at the previous mentioned site, you can see there is only 
one file, but it contains a lot of includes.
- a random function for the banners on top
- a file for the navigation on the left which includes a file for the 
date and a file for the counter (mysql database)
- the content pages with different files for the forms redirected per 
OS and type of Browser.
The reason why I work that way is to have a sort of frame in which the 
content is included, directed via the variables of the URL.
That gives me a good overview on how the site is built and it makes it 
easy to maintain.
Now, with mod_per this is a whole different story. Probably I need to 
review my strategy as things get more complicated regarding using 
"use", or "require" ... or "do" 
Would using Apache::PerlRun be a better option to deal with this way of 
building a website?
Thanks for your advise!
Bart

On Tuesday, January 28, 2003, at 05:21 PM, Randal L. Schwartz wrote:

"mail@adventureforum" == mail@adventureforum net 
<[EMAIL PROTECTED]> writes:

mail@adventureforum> I am using: mod_perl/1.26

mail@adventureforum> Now I tried to include subroutines from an 
external .pl file with
mail@adventureforum> "require".

This smells a bit like you're using Apache::Registry (you haven't said
yet) and you've moved some subroutines into a separate file, but not a
separate package, and you either aren't aware or don't understand the
significance of the fact that every Apache::Registry script runs in a
different package.

Could that be the case?

If you're using Apache::Registry, and you're not properly using
packages, you'll get burned.  Turn your external code into a real
module, and things will work again.  Use "use", not "require", not
"do".

print "Just another (mod) Perl hacker,"

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 
0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl 
training!

Newbie Q on Apache::Include

[perl]

Hi,

Can someone direct me to a good tutorial for Apache::Include?

Rgds

Re: Stacked Handlers Execution Chain

[Geoffrey Young]

Helmut Zeilinger wrote:

Hi,

i am using mod_perl 1.99_08.

I have two mod_perl handlers:

...
PerlResponseHandler Test::handler0 Test::handler1
...

How can i brake the execution chain between handler0 and handler1? 
Whatever i try as handler0 return value (OK, DECLINED, FORBIDDEN, 404)
the 
handler1 is still executed. The documentation says, that any value
except DECLINED should do that.

it probably should say that OK, DECLINED, or DONE will allow the chain to 
continue.  anything else ought to immediately terminate the chain - if not, 
it's probably a bug.  you might want to see if there is a difference between 
returning FORBIDDEN, NOT_FOUND, and SERVER_ERROR (well, their 2.0 
equivalents, anyway), just to help track things down.

--Geoff

Re: "do" as temp solution for "require" problem ?

[Randal L. Schwartz]

> "mail@adventureforum" == mail@adventureforum net <[EMAIL PROTECTED]> 
>writes:

mail@adventureforum> I am using: mod_perl/1.26

mail@adventureforum> Now I tried to include subroutines from an external .pl file with
mail@adventureforum> "require".

This smells a bit like you're using Apache::Registry (you haven't said
yet) and you've moved some subroutines into a separate file, but not a
separate package, and you either aren't aware or don't understand the
significance of the fact that every Apache::Registry script runs in a
different package.

Could that be the case?

If you're using Apache::Registry, and you're not properly using
packages, you'll get burned.  Turn your external code into a real
module, and things will work again.  Use "use", not "require", not
"do".

print "Just another (mod) Perl hacker,"

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: "do" as temp solution for "require" problem ?

[Perrin Harkins]

[EMAIL PROTECTED] wrote:

This is working fine although a mysql database connection in a  
subroutine in an external file doesn't always work.

Please explain.  It shouldn't ne a problem to run code that makes a 
database connection in a separate module.

- Perrin

Stacked Handlers Execution Chain

[Helmut Zeilinger]

Hi,

i am using mod_perl 1.99_08.

I have two mod_perl handlers:

...
PerlResponseHandler Test::handler0 Test::handler1
...

How can i brake the execution chain between handler0 and handler1? 
Whatever i try as handler0 return value (OK, DECLINED, FORBIDDEN, 404)
the 
handler1 is still executed. The documentation says, that any value
except DECLINED should do that.

What could i have done worng?

Helmut

Re[2]: ap_unescape_url can't escape %uXXXX

[Lee Goddard]

-BEGIN PGP SIGNED MESSAGE-
Hash: MD5

Hi IKEBE,

On Tuesday, January 28, 2003 at 1:32:43 PM, you wrote:


IT> I have written a little patch for libapreq which unescape
IT> the %u style URI-escaped string.
IT> the unescape algorithm is based on CGI.pm

Any idea if/when that'll be incorporated to the distributions?

I currently have to have a handler check every incoming request
for failure, and then convert with Unicode::String 

- --
Cheers
 Lee "Of course, if everyone used Lynx, this wouldn't be a problem"
 Goddard

-BEGIN PGP SIGNATURE-
Version: 2.6

iQCVAwUAPjaBYadrfekeF/QBAQHDJgP/YnPgGH8c3emGgbwnuvAB3B2jIvnetcD0
2nyE4ODThKoRuITHRX5qa9FvHtz2ouNM+pgDr0wo6TRyJM7sqmpzXVy/0XYw6NUV
j8nxkBiELC4F9JWyf+a91rzvTOA/eXDPizrOC9/OgKKn+ZH86GftoeNd+KvhM4TG
kRmE6bJ5O+4=
=ZPvi
-END PGP SIGNATURE-

Re: ap_unescape_url can't escape %uXXXX

[IKEBE Tomohiro]

I have written a little patch for libapreq which unescape
the %u style URI-escaped string.
the unescape algorithm is based on CGI.pm

At Fri, 29 Nov 2002 06:55:54 +0900,
Tatsuhiko Miyagawa wrote:
> 
> It seems that Apache's ap_unescape_url() can't handle %u style
> URI-escaped Unicode string, hence Apache::Request cannot neighther,
> while CGI.pm can.
> 
> Is this a known issue?
> 
> 
> -- 
> Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
> 

-- 
IKEBE Tomohiro <[EMAIL PROTECTED]>




apache_request_unicode.patch
Description: Binary data

Re: "do" as temp solution for "require" problem ?

[[EMAIL PROTECTED]]

Hi,

I am using: mod_perl/1.26

Now I tried to include subroutines from an external .pl file with  
"require".

This I got from:  
http://perl.apache.org/docs/1.0/guide/porting.html#The_First_Mystery
"For example if we move the code from the script into the subroutine  
run, place the subroutines into the mylib.pl file, save it in the same  
directory as the script itself and require() it, there will be no  
problem at all. (Don't forget the 1; at the end of the library or the  
require() might fail.)"

This is working fine although a mysql database connection in a  
subroutine in an external file doesn't always work.

The "do" solution I got from:  
http://perl.apache.org/docs/1.0/guide/ 
porting.html#Name_collisions_with_Modules_and_libs
-> on the bottom of the page: A hack)

Cheers,

Bart



On Sunday, January 26, 2003, at 05:30 AM, Stas Bekman wrote:

[EMAIL PROTECTED] wrote:

Hi,
I think mod_perl is wonderful but unfortunately enough the "require"  
function does not work as it does in CGI.
Is using the function "do" the only workaround  as temporary solution  
till this problem is fixed in a/the next mod_perl version?

Have you read:
http://perl.apache.org/docs/1.0/guide/ 
porting.html#Name_collisions_with_Modules_and_libs
?

If you are referring to a different problem, what mod_perl version are  
you talking about?

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com