Re: [mp2] 3rd-party module porting status
On, 04 Dec 2003 12:40:25 -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: Hi, >Nice. I'd grep .pm files too, if changes don't contain the reference to this >change. Sure (waiting for META.yml... :-)) >I haven't used it myself with mp2. Does it work just fine? Me too (not yet). But the Changes reports mp2 notes from 0.90_02 release. >bi-weekly is probably better. OK >We used to have an explicit list, but as with time it was neglected, it was >abandoned: http://perl.apache.org/products/old-modules-categorized.html >If someone decides to fix and maintain it that would be great. I can do it. >If this is done >it can have a status column telling whether it's mp2 or mp1 complient. And >then you only need to poll for unknown modules or those who weren't mp2 compiled. I've already set up a simpe DB table containing this info about Apache::* modules. So, I must populate manually remaining mod_perl modules which doesn't live under Apache::* namespace. >> 3. The report is strictly tied to description in Changes distribution files >True. But this can be polished with time. [...] >That's where META.yml kicks in. I'm not sure which tag can we use though. >http://module-build.sourceforge.net/META-spec.html >but eventually that's what we are going to use. Using META.yml is a good thing, but we know when this will be a standard in CPAN distributions? In the meantime, we could be update the docs in order to encourage use of META.yml (as you suggested) or to report mp2 compatibility status in Changes file. >> 2) Apache::AuthPerLDAP - Again CPAN reports: >>[...] >> CPAN_VERSION 0.5 >>[...] >>instead of version 2.01 >Shannon, you ported the two, do you co-own the namespace of these modules? If >not this may explain why CPAN.pm doesn't show them. Enrico, search.cpan.org >does show the latest version. Yes, I've seen, even if www.cpan.org doesn't show them. by - Enrico -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
APR::URI->parse question
Hi all, I'm porting to mp2 this mp1 code: use Apache::URI; my $uri = Apache::URI->parse($r); # now I can work with $uri->hostinfo, $uri->scheme, etc In mp2, 'parse' method has moved from Apache::URI to APR::URI. Moreover the method syntax is changed: APR::URI->parse($r->pool,$uri); Because I need 'hostinfo' and 'scheme' methods, I must pass a complete url to APR::UR->parse (in mp1 this wasn't necessary). So I've used APR::URI->parse($r->pool,$r->construct_url) ad docs explains. However I also must require Apache::URI (maybe the doc can be updated?). So, a working code could be: use Apache::URI; require APR::URI if MP2; my $uri = MP2 ? APR::URI->parse($r->pool,$r->construct_url) : Apache::URI->parse($r); I'm missing some things, or there's a better way? Thanks in advance by - Enrico -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: help, problems on migrating to mod_perl
"Randy Kobes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, 5 Dec 2003, SRef wrote:
>
> > Env: Perl5.8 Apache2.0 mod_perl2.0(1.99xx?) PS: I did try
> > to find the solution through mod_perl and apache
> > documents, but in vain. Please help me, thanks.
> >
> > For example, I have a script file named "index.cgi" for my
> > website entrance, and there are some template files in the
> > same directory with it. index.cgi used to run correctly
> > under "use warnings(FATAL => 'all'); use strict."
> >
> > when I try using mod_perl, problems occur:
> > 1. when access my site http://localhost, it shows error"cann't open
> > http://localhost";; I can only use http://localhost/index.cgi, how to
sovle
> > this?
>
> This seems like a problem with your Apache configuration -
> see the docs at http://httpd.apache.org/ for details.
In my httpd.conf, there is this:
###
LoadModule perl_module modules/mod_perl.so
PerlRequire "D:/Program Files/Apache Group/Apache2/conf/start_up.pl"
PerlSwitches -wT
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
DirectoryIndex index.cgi index.html
AddHandler cgi-script .cgi .pl
#others remains the default
...
#==
###content of start_up.pl
use Apache2 ();
use ModPerl::Util ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';
use APR::Table ();
use Apache::compat ();
use ModPerl::Registry ();
use CGI ();
1;
#===
>
> > 2. it shows many error"sub1 redefined.sub2 redefined"when the
second
> > time or more to access the index.cgi.
>
> This might be using modules or subroutines whose names
> coincide - it's hard to know without seeing a simple
> example of your script.
I don't think that's the case. Since if I change the subname, eg,
sub main() , changed to main1()
Then the errorlog will say "main1() redefined." instead of "main()
redefined".
my script example like this:
#===
use strict;
use warnings(FATAL => 'all');
use HTML::Template;
use CGI qw(:all);
use CGI::Carp qw(fatalsToBrowser);
use DBI qw();
use lib './';
require 'env.pl';
#env.pl is under same path with index.cgi
# Global variables
definition==
my $q = new CGI;
.#some globals here
main();
sub main(){
sub1();
sub2();
..
}
sub sub1{
.
}
sub sub2{
.
}
.
#end
>
> > 3. I use relative path in index.cgi, but it seems all goes mad when
> > mod_perl::register reports" can't find file1.tmpl...cann't find
file2.tmpl"
> > I think when mod_perl::register works the current working directory
is
> > somewhere else than where index.cgi is.
> > then i use chdir to change the working directory to where index.cgi
is,
> > I just want to know is there any better way to achieve this since we
nearly
> > always want the current path to be where your script is, rather than
> > mod_perl::register . I also wonder if chdir will cause any problem with
> > mod_perl::register .
>
> There's been discussion of this in the past - search the
> archives of the mod_perl mailing list (links are available
> from http://perl.apache.org/) for a discussion.
>
Thanks. I will try.
> > 4. Another error, mod_perl::register: Unrecognized character \x11 at
> > mark.gif. Anything wrong with the gif?
>
> Does the gif display OK when loaded in a browser? Again,
> a simple example illustrating the problem would help.
>
it's ok when loaded alone in a browser. And actually it's all ok before I
use mod_perl.
Does mod_perl register parse gif files or do any special thing to them?
> > 5. all globle var in index.cgi used to be "my", but it
> > says requires explicity package name? I change it to
> > "local", same proble occurs. When it be"our", no such
> > error any more? I know difference among them in Perl. But
> > can anyone explain them to me for mod_perl? Also, why
> > mod_perl2.0 documents has no info about this? At least, I
> > didn't find.
>
> Try searching at http://perl.apache.org/ for, for example,
> "scoped variable" - this might lead you to what you're
> looking for.
ok, I will try it.
>
> > 6. use lib './' doesn't work when second(maybe third?) time invoke
> > index.cgi.
> > I don't want to put the lib file in perl/lib, nor put the line" use
lib
> > './' " in "start_up.pl". So is there any way to solve this?
>
> As with most of the previous questions, it would help quite
> a bit to see a short snippet of code illustrating the
> problem, what the error logs say, if anything, and the
> relevan
dynamic paths?
is there some easy setup that i can do to allow for a dynamic path in a uri? for example, id like to have the ability to have some configuration file, say uri_path.txt and list multiple paths in the form of: # my.paths /path1 /path2/target /path3/target1 ... and be able to change this or add to it and the site would then resolve to those particular paths. any suggestions? thanks d -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp2] libgd (and freetype) problem with ModPerl::Registry
Hi, I made perl CGI script which makes png files on the fly (using GD.pm). Everything was ok until I wanted to run it with ModPerl::Registry (to get it faster). Here is script (mkpng.cgi): #!/usr/bin/perl use GD; binmode STDOUT; $p = new GD::Image(20,20); $p->colorAllocate(255,255,255); $p->stringFT($p->colorAllocate(0,0,0),'/tmp/verdana.ttf',10,0, 0,12, 'ok'); open F, ">/tmp/testlog"; print F $@; close F; print "Content-Type: image/png\n\n"; print $p->png; undef $p This works ok as CGI (/tmp/testlog is empty after run). I can see image where is "ok". Now I write to .htaccess: DefaultType image/png SetHandler perl-script PerlResponseHandler ModPerl::Registry and remove line print "Content-Type: image/png\n\n"; from mkpng.cgi This produce white image without any text and /tmp/testlog contain: libgd was not built with FreeType font support Where the problem can be? What should I do? help me... Some more information what can be useful: # ldd /usr/lib/libgd.so libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4003b000) libfreetype.so.6 => /usr/X11R6/lib/libfreetype.so.6 (0x4005a000) libpng.so.3 => /usr/lib/libpng.so.3 (0x4009b000) libz.so.1 => /usr/lib/libz.so.1 (0x400c6000) libm.so.6 => /lib/libm.so.6 (0x400d5000) libc.so.6 => /lib/libc.so.6 (0x400f8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) # find /usr/lib/perl5 | grep GD | grep -v GDBM_File /usr/lib/perl5/site_perl/5.8.1/i486-linux/GD /usr/lib/perl5/site_perl/5.8.1/i486-linux/GD/Polyline.pm /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Text /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Text/.packlist /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/GD.bs /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/GD.so /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Graph /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Graph/.packlist /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/autosplit.ix /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Convert /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Convert/.packlist /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/.packlist /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Graph3d /usr/lib/perl5/site_perl/5.8.1/i486-linux/auto/GD/Graph3d/.packlist /usr/lib/perl5/site_perl/5.8.1/i486-linux/GD.pm Linux: Slackware (lot of packages are self-compiled) Apache: Apache/2.0.48 (Unix) mod_perl/1.99_11 Perl/v5.8.1 mod_ssl/2.0.48 OpenSSL/0.9.7c PHP/4.3.4 -- Kaiko Kaur -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: make test errors (modperl 1.99_11 and perl 5.8.2)
On Thu, 04 Dec 2003 12:03:34 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote: >THELLA,RITA (HP-Cupertino,ex3) wrote: >> After installing HP-c patches, make test is working fine. > >Great. What're HP-c patches? On HP-UX for PA-RISC, version 11.00/11.11 you need to install patch PHSS_29484/PHSS_29485 if you use HP C to compile mod_perl 1.99_11. Interestingly enough, Perl 5.8.2 builds and tests fine without the patches. These patches are for the HP ANSI C compiler and are not needed if you use GCC. The patches are for PA-RISC only and not applicable to IPF (Itanium) systems. Cheers, -Jan -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
