Re: running xs generator
On Sun, 24 Jun 2001, Stas Bekman wrote: Running a stand-alone: $ make xs_generate yeah, that isn't meant be used at the moment. unfortunately 'make source_scan' shocks with: Expecting parenth after identifier in `apr_sms_t **sms' after `apr_sms_t ' at /home/stas/perl-bleed/lib/5.7.1/C/Scan.pm line 851. with the Scan.pm from your site Doug. But you've mentioned this already. it works fine for me with the current sources. there is one difference in my local copy (patch from gerald), however source_scan.pl runs fine either way for me. --- /home/dougm/tar/Scan.pm Mon Jun 25 16:38:02 2001 +++ /home/dougm/perl/C-Scan-0.75/Scan.pmWed May 2 20:57:45 2001 @@ -914,7 +914,7 @@ } my $stream = $class-new(@_); my $oh = select $stream; - $/ = undef; + local $/ = undef; select $oh; $stream; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestServer.pm
On Tue, 26 Jun 2001, Stas Bekman wrote: let's try to go with the inlines first, if we see that it's not good. we extract all the inlines into the separate .pod files. This is something that we can do much easier than the reverse operation, assuming that we want the snippets of pod to be scattered around the code. The good thing about inlines is that there is a better chance that the inline docs will be updated on code updates. For distributions we can have all docs in .pod files. We'll make sure that we have .pod, .html, .ps, .pdf, (.xml?) and other formats available on demand. oh yeah, that's another reason i was thinking of having module docs be in their own .pod file, for the docs distribution. if the pod is inlined in the .pm, will you extract that into a Module.pod for the docs dist? and then, if you install a doc kit that's new than the code, does 'perldoc Module' pickup the new Module.pod or pod inside Module.pm? Also Doug you were talking about self-documenting code, I don't remember I saw any details about this thingy in the docs. Can you elaborate on this? by that i literally meant 'self-documenting code'. like you can get a good understanding of the modperl C code just by reading the code. granted docs for the C api would be nice, hopefully attempting to write 'self-documenting code' will make that easier. Oh, I see :) From your original conference paper doc I understood that you plan to autogenerate docs from the API code. I thought that would be cool, but now I know that it was an illusion :) that was not an illusion, i did say API docs can be generated, and they still can be. 'autogenerated docs' and 'self-documenting code' are two very different things. i mentioned 'self-documenting code' in a recent offlist message when you asked about documentation for understanding the core code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: test order
On Tue, 26 Jun 2001, Stas Bekman wrote: what do you think about this para about default sorting? I understand. Another option would be to always sort the tests unless you have specified their order on the command line. o if you specify none -- everything is sorted. o if you specify only dirs -- evething within dirs is sorted, dirs order is preserved o if you specify file names they aren't sorted. o if you specify random, you get it random. I like this option even better. You? sounds good to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running xs generator
On Tue, 26 Jun 2001, Stas Bekman wrote: it still doesn't work, even with this patch. What's is the difference in your dev environment? I have all cvs versions perl/apache/mod_perl on linux. Scan.pm from your site with this patch. The only thing I had to install was Data::Flow, and my version is: likely the differences is in our system header files. $ perl-bleed/bin/perl -MData::Flow -le 'print $Data::Flow::VERSION' 0.05 same here. is it possible that Scan.pm online is not the same as you use? I'm talking about the one at apache.org/~dougm/Scan.pm. i just checked yesterday, only difference was the diff i posted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestServer.pm
On Wed, 27 Jun 2001, Stas Bekman wrote: As usual, I mess things up :( sorry about that. I meant 'autogenerated docs'. no problem :) Currently we don't have autogenerated docs, right? I was just thinking how 'make docs' should invoke other utils to create these autogenerated docs, before it can proceed to generate other formats. right. when we do have them, these would get generated at the same time as util/xs_generate.pl is run. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running xs generator
On Wed, 27 Jun 2001, Stas Bekman wrote: yours? % uname -a Linux mako.covalent.net 2.2.16-22 #7 Wed Mar 28 15:39:46 PST 2001 i686 unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Test patch
patch looks good stas, but for some reason it now tries to run modules/cgi a bunch of times, which doesn't happen with any other tests: modules/cgi..ok 2/6Confused test output: test 2 answered after test 2 modules/cgi..ok 2/6Confused test output: test 2 answered after test 2 modules/cgi..NOK 5Use of uninitialized value in string eq at modules/cgi.t line 28. modules/cgi..dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 3-6 Failed 4/6 tests, 33.33% okay modules/cgiuploadFAILED tests 1-2 Failed 2/2 tests, 0.00% okay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patches
for those who don't have mailers that will mangle inline patches, please send patches inline rather than as attachments, makes it much easier to comment on the patch. thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: printf/fprintf in mod_perl sources
On Thu, 28 Jun 2001, Stas Bekman wrote: I've a C question :) Why cannot I use: printf(%s\n, IT WORKS); and have to use: fprintf(stderr, %s\n, IT WORKS); in the mod_perl sources? something todo with PerlIO, turns printf, fprintf, etc. into macros. i always use fprintf(stderr, ...) so i've never seen the problem, but might be a but in PerlIO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestSort.pmTestHarness.pm
On Thu, 28 Jun 2001, Stas Bekman wrote:
what happens if $args-{order} is defined, but is none of
rotate|random|repeat when somebody mistypes the value or --order? This
code will die. My original code was just silently ignoring this option if
it's an unknown one.
i don't think an unknown option should be silently ignored.
it doesn't die if given an unknown option, it does this:
error unknown order '$order';
which you can see:
% t/TEST -order blah
...
unknown order 'blah'
apache/cgihandlerok
...
i wouldn't mind if it died when given an unknown order option though.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: .cvsignore in ./t
i have a script to automate that (below). i left the generated .t's out
for the moment, wondering if some might become non-autogenerated and
checked in, not that it would hurt if that happened and they were also in
.cvsignore
#!/usr/bin/perl -w
#handy to generate .cvsignore entries
#e.g.
# cvs diff -u diff.txt
# cvsignore diff.txt
use strict;
use Cwd ();
my %files = ();
while () {
next unless s/^\? //;
chomp;
next unless m:(.*)/([^/]+)$:;
push @{ $files{$1} }, $2;
}
my $pwd = Cwd::fastcwd();
print PWD = $pwd\n;
while (my($k,$v) = each %files) {
chdir $pwd or die chdir `$pwd' failed: $!;
unless (-d $k) {
die `$k' is not a directory
}
chdir $k;
my $cvs_add = -e .cvsignore ? 0 : 1;
open FH, .cvsignore or die $!;
print FH join \n, @$v, ;
close FH;
if ($cvs_add) {
system cvs add .cvsignore;
}
print $k: @$v\n;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: make source_scan
On Thu, 28 Jun 2001, Stas Bekman wrote: So if I add a new feature and want to add it via source_scan, only you can do that if don't want to overwrite each others version of xs/tables/current/Apache/FunctionTable.pm. Do you think we should make sourcescan produce an identical code, no matter what machine it's running on ( I suppose this is just an issue of sorting the keys before dumping the datastructures). if you can make that happen, that would be cool. but i think it depends on Data::Dumper, which doesn't have a sort option that i know of. in the meantime, if you want to add a new feature to source_scan.pl you can do that without checking in the changed xs/tables - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: .cvsignore in ./t
On Thu, 28 Jun 2001, Stas Bekman wrote: so may be: system cvs add .cvsignore; system cvs ci -m 'ignore these' .cvsignore; i just do the commit by hand, after doing another diff to make sure i the script didn't break something. Will you make it a part of the rep or do you plan to manage all the new tests by yourself? Of course there is no hurry for anything like that, I was just wondering how do I get rid of ? when I produce a patch via 'cvs diff' :) i always end up with ? files no matter if .cvsignore is up-to-date. i just do: % cvs diff foo.pat open foo.pat in xemacs, review the patch, repeat until happy with patch, cut out the ?'s from foo.pat, save foo.pat, post foo.pat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] source_scan improvements
way cool!! i committed your patch, with one change being a reverse sort
of hashes so we end up with something very nice:
{
'return_type' = 'int',
'name' = 'ap_allow_options',
'args' = [
{
'type' = 'request_rec *',
'name' = 'r'
}
]
},
which is the same order of things we see in the function prototype:
int allow_options(request_rec *r);
and similar for structures:
{
'type' = 'process_rec',
'elts' = [
{
'type' = 'apr_pool_t *',
'name' = 'pool'
},
...
good work stas!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: lib/Apache/ParseSource.pm @INC problem
On Fri, 29 Jun 2001, Stas Bekman wrote: Doug, after your recent patch, 'make source_scan' doesn't work anymore unless you have Apache-Test installed in @INC. i had modified util/source_scan.pl but had not committed, done now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a couple of random questions
On Fri, 29 Jun 2001, Stas Bekman wrote:
I'm going through the files in pod, doing some add-ons from what
I've learned so far and some minor cleanups. I've a few questions though:
modperl_design.pod:
---
=head1 Interpreter Management
=item PerlInterpMax
How fast mod_perl responds to the peaks loads when there is a sudden
demand for a bigger interpreters pool, assuming that
PerlInterpMaxSpare is set to a low number.
'how fast' will depend on how much code you have compiled in the parent,
and how powerful your machine is. i've not done any measurements.
BuildOptions::parse_file:
---
my @files = map { $_ . 'makepl_args.mod_perl2' }
qw(./ ../ ./. ../.), $ENV{HOME}/.;
I think to be really consistent we should do:
my @files = map { $_ . 'makepl_args.mod_perl2' }
map { ($_/,$_/.) } qw(. ..), $ENV{HOME};
so we have 6 different locations. it also reads easier :) I know that
it's probably a bad idea to have makepl_args.mod_perl2 without leading
'.' under your ~, but just to be consistent. Or may be we should have
only the files starting with '.'? Just wondering.
i guess ~/makepl_args.mod_perl2 would be ok, but i think that's what i was
trying to avoid originally.
modperl_dev.pod:
---
=head2 PerlOptions Directive
Is the option called 'Enabled' or 'Enable'? the item says 'Enabled'
but the example following it uses 'PerlOptions -Enable'
Enabled, i think, try it and see :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: another ParseSource issue
On Fri, 29 Jun 2001, Stas Bekman wrote: Doug, if you look at your last commit of xs/tables/current/Apache/FunctionTable.pm it has a bunch of hardcoded dirs like this: -'type' = '# 281 /home/dougm/ap/threaded/include/http_log.h - const request_rec *r', -'name' = 'arg5' of course if I do 'make source_scan' I get a diff with the one in cvs :) never saw that before, there's not a bunch, just 3, all in the same function, ap_run_error_log. i guess that macro is confusing C::Scan somehow. Another interesting thing is that I've a big part of xs/tables/current/ModPerl/FunctionTable.pm removed (compared to the cvs version) after I run the scanner. what exactly is missing? no need to post the whole diff, but if you can give the function 'name' = 's - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheUpload_size defined multiple times?
looks like ApacheUpload_size was recently added to apache_request.h, i've removed it from Request.xs On Fri, 29 Jun 2001, Jens-Uwe Mager wrote: If I compile the latest version from CVS I get: xlc -c -I../c -I/usr/local/lib/perl5/site_perl/5.005/aix/auto/Apache/include -I/usr/local/lib/perl5/site_perl/5.005/aix/auto/Apache/include/modules/perl -I/usr/local/lib/perl5/site_perl/5.005/aix/auto/Apache/include/include -I/usr/local/lib/perl5/site_perl/5.005/aix/auto/Apache/include/regex -I/usr/local/lib/perl5/site_perl/5.005/aix/auto/Apache/include/os/unix -I/usr/local/apache/include -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=8192 -I/usr/local/include -O -DVERSION=\0.3301\ -DXS_VERSION=\0.3301\ -I/usr/local/lib/perl5/5.00503/aix/CORE Request.c Request.xs, line 106.9: 1506-213 (S) Macro name ApacheUpload_size cannot be redefined. Request.xs, line 106.9: 1506-358 (I) ApacheUpload_size is defined on line 110 of ../c/apache_request.h. Is there a reason why this is in defined in Request.xs? Simply removing the define made it work for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portability: catfile vs ../..
On Sat, 30 Jun 2001, Stas Bekman wrote: I'm looking at the Build.pm in 2.0 and I see that it uses both File::Spec::catfile() and unix '/' hardcoded paths. I know that catfile() is used to make the code portable, but I want to understand when this should be used an not '/'. Thanks! should probably always use catfile and friends. /'s were in there before i started that habit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: Apache::SizeLimit patches
On Tue, 3 Jul 2001, Perrin Harkins wrote: Here's a patch I submitted for Apache::SizeLimit, presented for your general amusement and critique. thanks perrin, this is in cvs now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some info missing from $r-finfo
On Tue, 3 Jul 2001, Geoffrey Young wrote:
hi guys...
I tried using the -T and -B file tests against $r-finfo and found they
didn't work. I'm guessing this is because -T and -B are special perl tests
that have to read in the file, and that Apache's stat() doesn't glean this
information on its own.
i think those tests will work with this (untested) patch..
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.123
diff -u -r1.123 Apache.xs
--- src/modules/perl/Apache.xs 2001/06/14 05:26:28 1.123
+++ src/modules/perl/Apache.xs 2001/07/06 13:58:47
@@ -1956,9 +1956,11 @@
statcache = r-finfo;
if (r-finfo.st_mode) {
laststatval = 0;
+sv_setpv(statname, r-filename);
}
else {
laststatval = -1;
+sv_setpv(statname, );
}
if(GIMME_V == G_VOID) XSRETURN_UNDEF;
RETVAL = newRV_noinc((SV*)gv_fetchpv(_, TRUE, SVt_PVIO));
Index: src/modules/perl/perl_PL.h
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_PL.h,v
retrieving revision 1.7
diff -u -r1.7 perl_PL.h
--- src/modules/perl/perl_PL.h 1999/01/18 03:26:19 1.7
+++ src/modules/perl/perl_PL.h 2001/07/06 13:58:47
@@ -19,6 +19,9 @@
#ifndef laststatval
#define laststatval PL_laststatval
#endif
+#ifndef statname
+#define statname PL_statname
+#endif
#ifndef rs
#define rs PL_rs
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DIR_CREATE woes
patch below fixes, you can see the problem excercised with this little
test too:
use POSIX ();
for (1,2) {
undef POSIX::isalnum;
}
Index: op.c
===
RCS file: /usr/local/cvs_repository/perl-current-mirror/op.c,v
retrieving revision 1.1.1.45
diff -u -r1.1.1.45 op.c
--- op.c2001/07/06 16:37:22 1.1.1.45
+++ op.c2001/07/06 16:39:38
@@ -4161,8 +4161,8 @@
#ifdef USE_ITHREADS
if (CvFILE(cv) !CvXSUB(cv)) {
Safefree(CvFILE(cv));
- CvFILE(cv) = 0;
}
+CvFILE(cv) = 0;
#endif
if (!CvXSUB(cv) CvROOT(cv)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
directive handlers + php segv
i'm revisiting this problem and am unable to reproduce with:
mod_perl-1.25_01-dev (current cvs)
apache-1.3.21-dev (current cvs)
perl 5.7.2-dev (current perforce)
Apache::Storage-1.1
php-4.0.6
using the mod_perl-1.25_01-dev/t test setup, at the bottom of
t/conf/httpd.conf, i added:
LoadModule php4_module /home/dougm/httpd/libexec/libphp4.so
AddType application/x-httpd-php .php
Perl
use blib qw(/home/dougm/build/Apache-Storage-1.1);
/Perln
PerlModule Apache::Storage
ApacheStore foo [qw(skdjf slkdjf lskdjf)]
this perl script runs fine:
use Apache::Storage;
use Data::Dumper;
my $r = shift;
$r-send_http_header;
print Dumper get_storage('foo');
as does this php script:
? echo hi ?
i can even lookup the perl config from php:
?
$perl = new Perl;
$foo = $perl-call(Apache::Storage::get_storage, foo);
$dump = $perl-call(Data::Dumper::Dumper, $foo);
echo $dump;
?
is anybody still having this problem? if so, can you provide a simple
test case to reproduce?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding perl_call_handler for Win32?
On Fri, 6 Jul 2001, Jens-Uwe Mager wrote: AIX needs all the same symbols. I just did not notice the additional symbols needed by AxKit as I have not used it (yet). ok, these are in now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ModuleConfig on Win32
On Mon, 9 Jul 2001, Randy Kobes wrote: Hi, I've attached a diff for Win32 against the current cvs mod_perl that does three things cool, thanks randy, applied to cvs. I was looking at these because, first of all, wanting to see if ModuleConfig works on Win32, and also because in building mod_perl-2.0 for Win32 it seems better not to have so many if ($Is_Win32) exceptions - the above is closer in spirit to the Unix build. For these I guess it would be nice to get some experience and work out the bugs in a stable environment ... should be much easier to port the 2.0 build system to win32 and easier to maintain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestServer::start_gdb
On Sun, 8 Jul 2001, Stas Bekman wrote:
Doug, how do we want to change the start_gdb with a more generic code and
decide which debugger is to be used via the command line option and/or env
var?
I suggest that we have 'debug:s' option, where:
--debug
(no value) uses $ENV{MP_DEBUGGER} || 'gdb'. And:
--debug=db_foo
uses 'db_foo' if supported and quits with an error if not.
that would be great.
Anyway, ddd coupled with gdb should be invoked as:
my $command = qq{ddd --gdb --debugger gdb -command $file $config-{vars}-{httpd}};
I use ddd since it's a fantastic tool when you need to debug/learn
complicated data structures. Its 'Data' window is very helpful.
i'll have to try ddd one of these days.
Probably another useful key would be -debug-jump-init or similar which
will take you right into the modperl_hook_init() via the breakpoint. I'm
adding your trick notes to modperl_dev.pod, but I think it'd be nice to
have the feature in core. I can also think of having a set of jump points
to various frequently used breakpoints selected via the debug options, but
this can be added later if found useful.
that would be cool too.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestConfigPerl.pm
On Mon, 9 Jul 2001, Geoffrey Young wrote:
die in modperl_startup.pl if modperl_{inc,extra}.pl die
anyway, I thought modperl_extra.pl was supposed to be optional?
it is still optional, but if it exists and dies, then mod_perl should
propagate that. although, the $@ !~ /^Can.t locate/ is bogus, because it
might be that modperl_extra.pl was located, but a module it requires was
not.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: modperl-2.0/Apache-Test/lib/Apache TestConfigPerl .pm
On Mon, 9 Jul 2001, Geoffrey Young wrote:
except that my test was dying because modperl_extra.pl didn't exist... I had
to put an (almost) empty file there to get around this warning...
weird. well the pattern was bogus anyhow, i think this will hold up
better for the moment..
Index: Apache-Test/lib/Apache/TestConfigPerl.pm
===
RCS file: /home/cvs/modperl-2.0/Apache-Test/lib/Apache/TestConfigPerl.pm,v
retrieving revision 1.13
diff -u -r1.13 TestConfigPerl.pm
--- Apache-Test/lib/Apache/TestConfigPerl.pm2001/06/26 17:09:46
1.13
+++ Apache-Test/lib/Apache/TestConfigPerl.pm2001/07/09 16:01:21
@@ -83,7 +83,7 @@
use lib '$serverroot';
for my \$file (qw(modperl_inc.pl modperl_extra.pl)) {
eval { require conf/\$file } or
-die if \$@ !~ /^Can.t locate/;
+die if grep { -e \$_/conf/\$file } \@INC;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ModuleConfig on Win32
On Tue, 10 Jul 2001, Randy Kobes wrote: thanks ... could I bother you for a couple more small changes? In enabling the Apache::src test, I didn't check properly that it would be skipped if mod_perl.so was built thru Visual Studio - this diff: sure thing, that's in, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directive handlers + php segv
On Mon, 9 Jul 2001, Brian Aker wrote: The problem is, the best test case is to install slash, i'd be willing todo that with more specific steps of exactly how to reproduce. what to download, how to build, what to configure, etc., i can't take the time to guess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: test harness for Apache
On Wed, 11 Jul 2001, Geoffrey Young wrote: so, does this mean that Apache::Test is officially an httpd project and will be removed from the modperl-2.0 CVS tree? Apache-Test will be used in the project, but not sure if it'll move there yet. in any case, Apache-Test will still be distributed with modperl-2.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestServer::start_gdb
On Wed, 11 Jul 2001, Stas Bekman wrote: % ./t/TEST -debug -debugger=ddd how about reusing the current -debug: t/TEST -d ddd ? --debug-hook_init : bring the debugger to the 'modperl_hook_init' function via the breakpoint (internally it first loads the mod_perl DSO module via 'apr_dso_load' breakpoint. e.g.: % ./t/TEST -debug -debug-hook_init i'd rather not have a special case for this, but instead always set breakpoints after apr_dso_load, or better yet at ap_init_modules which will work for both dso and static (i think) -- --breakpoint : set as many breakpoint as needed via repeating the key nice! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: env MOD_PERL_TRACE doesn't take an effect and other trace issues
On Sat, 30 Jun 2001, Stas Bekman wrote:
modperl_trace_level_set gets called from modperl_cmd.c only if you have
PerlTrace in httpd.conf. Of course this case ignores the env var, but
there is no other place in the code that calls this func to check for the
env setting of MOD_PERL_TRACE.
right, because we have PerlTrace now. not that we can't support
MOD_PERL_TRACE too.
On the related note the following would be very useful when debugging
configuration sections and possibly from the code as well, if we provide a
hook to change the trace level from code as well:
$s-trace_level('d');
that would be useful. though at runtime with threaded mpm, it is not
threadsafe. but we could make a per-request trace level that overrides
the per-server.
Now what would be nice to have is to allow the negation of the level, so
in httpd.conf one can do:
PerlTrace d
PerlModule CGI
PerlTrace !d
Here I want to have a 'd' trace only for a section between two PerlTrace
directives.
'PerlTrace !d' looks like it should remove 'd' tracing. if you only want
'd', then use 'PerlTrace d'
I think also that this can be improved as well: Currently
PerlTrace d
followed by
PerlTrace g
turns off 'd' and turns on 'g' instead of appending 'g'.
why not just use 'PerlTrace dg' then?
To summarize I suggest to have:
PerlTrace [!]all | [!]d[!]f[!]g[!]h[!]i[!]m[!]s | off
all turn all on
off turn all off
d directive processing
f filters
g Perl runtime interaction
h handlers
i interpreter pool management
m memory allocations
s perl sections
!, before the letter, turns off the setting for this level, so one can
have:
PerlTrace dh #level = dh
PerlTrace !dg!h#level = g
i'm not seeing how this is useful, why wouldn't you just say 'PerlTrace g'?
well if we have !, we can also do: !all (instead of adding 'off' level).
why not just stick with 'off' ?
(but if we have off would be nice to replace all with on (or alias) but I
understand that it'll break the convention with normal Perl tracing)
an alias would be fine i guess.
and of course being able to turn levels on and off via $server.
how about something similar to Perl's $^D?
then you can do:
local $ModPerl::Trace = 1|4; #dg
or
local $ModPerl::Trace = ~4; #remove 'g'
or
local $ModPerl::Trace |= 4; #append 'g'
there could be constants for the numbers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing PerlModule take 1
On Tue, 10 Jul 2001, Stas Bekman wrote:
OK I've finally wrapped my head around how things work at the server
startup.
This [the patch at the bottom] is a crude proof of concept code for
PerlModule. Before I wrap it all nicely, please tell me if that's more or
less how things should be done. This is my first take on adding a new
feature for 2.0 at the C side :)
looks good, a few comments..
Should I provide a test for things like PerlModule/PerlRequire or these
are core features and they are supposed to work? If the test is a good
thing, I suppose i should write some unique module and require it and not
some widely available module. since it's possible that I pick some module
that will be loaded from a different place in the startup code and then
the test wouldn't prove that the functionality works properly (e.g.
assuming that PerlRequire startup.pl loads some module via 'use' and then
the test is not testing anything.
if you can put a test case together, that's always good.
- In case of the module/file require failure, should only the warning be
printed or should the process abort its execution?
abort.
Another question is about a definition of how do we want PerlModule to
work:
- load modules in the parent interpreter and let all children inherit from
it.
- allow each vhost to have its own preloaded modules.
- allow each interpteter pool have its own preloaded modules (which is
probably the same as the prev item, right?)
yeah, Perl{Module,Require} should be per-server.
May be we need to have normal PerlModule, which loads into the base
interpretor and have a second directive PerlLocalModule which allows to
load the module only in the parent of the tipool?
no, PerlModule should just do the right thing. outside of VirtualHosts,
they are loaded by the parent interpreter, inside VirtualHosts they are
loaded by that server's interpreter.
also after I finish to clean up the PerlModule and move onto PerlRequire:
- shouldn't PerlRequire be just an alias for PerlModule? since apparently
its implementation seem to be identical to PerlModule.
PerlRequire puts quotes around the value, since PerlRequire is a file,
whereas PerlModule is a bareword.
{
MP_dSCFG(s);
PerlInterpreter *perl;
-int status;
-char **argv;
+int status, i;
+char **argv, **entries;
int argc;
#ifndef USE_ITHREADS
modperl_cleanup_data_t *cdata;
@@ -80,6 +80,14 @@
modperl_shutdown, apr_pool_cleanup_null);
#endif
+{
+dTHXa(perl);
+entries = (char **)scfg-PerlModule-elts;
+for(i = 0; i scfg-PerlModule-nelts; i++)
+if (modperl_require_module(aTHX_ entries[i], TRUE) == FALSE)
+exit(1);
+}
+
this stuff should be in its own function, probably in
modperl_config.c. you're missing some braces and whitespace:
for (...) {
if (...) {
}
}
+MP_TRACE_d(MP_FUNC, %s\n, arg);
+MP_TRACE_d(MP_FUNC, %s\n, arg);
should be more that %s\n here.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how does mod_perl handle apachectl restart?
(already answered thies offlist, but just for the record...) modperl doesn't do anything special for non-graceful restarts. as far as i know most people either do a graceful restart or full shutdown/start. i can't recall any reports of problems with non-graceful restarts, though i wouldn't be surprised if there are similar troubles as php has. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestServer::start_gdb
On Sat, 14 Jul 2001, Stas Bekman wrote: doable. I know you don't want to lose -d shortcut :) yeah :) I'm not sure what's the definition of 'always'. There are cases where you run -d to debug the segfault and you want the debugger to 'run' till the segfault without any breakpoints. Whereas in other cases you want to debug during the development and that's when the use of apr_dso_load becomes useful. by 'always' i meant whenever there is a -breakpoint, it should get set at ap_init_modules. rather than have a special case -debug-hook_init, you would just say -breakpoint modperl_hook_init What I'm trying to tell is that by default the -d behavior should probably just run the server, and some other flag to turn on the development mode. remind me what is development mode again, just turning up the trace level or more stuff? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/Apache/Filter Apache__Filter.h
On Sun, 15 Jul 2001, barries wrote:
+if (*name == 'M' strEQ(name, name)) {
strEQ(name, name)?
whoops, good catch, fixed.
That sounds better to me now, FW little IW.
cool.
-sub handler : InputFilterBody {
+sub handler : FilterRequestHandler {
What differentiates input vs. output now? Or is that yet to come...
the Perl{Input,Output}FilterHandler configuration directives. the
attributes are currently just used as a way to specify when the filter
should be registered (pre_connection or request).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: env MOD_PERL_TRACE doesn't take an effect and other trace issues
On Mon, 16 Jul 2001, Stas Bekman wrote: you can end up with a long file with various PerlTrace settings. Instead of scrolling back and forth and remembering what bits very set before, why not just switching off the unwanted bits? i guess this is what i'm having trouble seeing. personally i never had the need to set it more than once and would just set it based on what i was debugging at that moment. the volume of modperl trace info isn't that high, unlike, say, perl -Dmx. but if you really see the need, it should be implemented using the existing modperl_options.c stuff, like: PerlTrace +d -f rather than a new !df syntax. if you want to allow per-dir configuration, MP_debug_level will need to live in tls (thread local storage) for threaded mpms (see modperl_global.c) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing PerlModule take 1
On Mon, 16 Jul 2001, Stas Bekman wrote: So is modperl_require_module() is used only for CORE::require()? If so at the moment, yes. - do we need modperl_use_module() to implement CORE::use into what namespace would things be imported? - should it be based on modperl_require_module() and convert the bareword into a filename before calling modperl_require_module() or implemented from scratch s|::|/|; s|$|.pm|; they're both so small (see 1.xx's version), i wouldn't worry about it much for now. they can be optimized later, like using Perl_load_module() for modperl_require_module(). Sure, will fix. I thought I could actually take a benefit of using one statement/no_braces_required C feature here :) i've learned to like how Perl forces the braces, easier to read and less error-prone :) +MP_TRACE_d(MP_FUNC, %s\n, arg); +MP_TRACE_d(MP_FUNC, %s\n, arg); should be more that %s\n here. But you actually have only a single arg. Or are you talking about flagging whether we are in parent process or vh scope? I've copied it from MP_CMD_SRV_DECLARE(options) which traces only the options passed. the options command tells you a bit more: MP_TRACE_d(MP_FUNC, arg = %s\n, arg); that's all i was looking for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directive handlers in 2.0
On 16 Jul 2001, Matt Sergeant wrote: However you still need PerlModule AxKit, to load the .so (actually even that's slightly incorrect - I have it working so you can do LoadModule /path/to/AxKit.so). eek, why would you want to use 'LoadModule /path/to/AxKit.so' rather than 'PerlModule AxKit' ? the latter seems much more user-friendly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: directive handlers in 2.0
On Mon, 16 Jul 2001, Geoffrey Young wrote: My thought was that, since you are already implementing directive handlers, register it with the fixup phase when you generate the XS (or whatever, as you pointed out in the other reply). This way the only change to httpd.conf is a single PerlModule Foo and XBitHack works as it always did, merges and all, only with our improved version - and you don't have to remember to put the PerlFixupHandler everywhere you put XBitHack. yeah, that's the sort of thing REGISTER_HOOKS would be used for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TPC/mod_perl non-informal technical meeting
On Tue, 17 Jul 2001, Stas Bekman wrote: While we are all at TPC: I was thinking that it'd be really cool to have the core- and wanna-be-core-developers get together and discuss the plans for 2.0, may be have some details kindly explained by Doug. I'd love to have code overview to get me started. I believe others will be interested as well. If there is an interest, should we get a room or can we just do it over someones hotel room? Of course this is only relevant if Doug will be kind to cut some of his margarittas quality time to do some work instead. Doug, considering that each of the attendees buys you say a few beers, would you consider that? sure, but i don't drink margarittas, i like beer, gin+tonic or scotch though :) if we could arrange to borrow an overhead from o'reilly that would be good, rather than everybuddy huddled around my tiny laptop screen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directive handlers in 2.0
On 17 Jul 2001, Matt Sergeant wrote: I don't. It's not documented, it was just an experiment. I wanted to see if it would work :-) oh, ok. when you said that's slightly incorrect, i thought you meant LoadModule should be used instead of PerlModule. Actually I also wanted to see if it would change the way AxKit reacted with PHP, rather than relying on mod_perl's code to do all the reloading. But it didn't change anything :-) does the current version of axkit still had problems with php loaded? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TPC/mod_perl non-informal technical meeting
On Wed, 18 Jul 2001, Stas Bekman wrote: Would you mind someone who is a wanna-be-wanna-be core developer come and listen (in a corner if I have to)? I would try to stay out of the way and not cause any problems but I would like to get a jump start on learning the mod_perl 2.0 internals. I feel like an agent :) Sure, come, but nothing comes for free. As Doug said if you want to get in you have to bring a bottle of a good scotch. hey, i never said anybody has to bring a bottle to attend, i just said i don't drink fruity drinks like matt :) there are exceptions when i'll sip fruity drinks, but a code party isn't one of them. besides, spilling scotch would just clean the keyboard real good, fruity drinks would be a disaster. You only have to show it when you enter, but Doug will not be allowed to claim the bottles before the meeting is over :) i don't want to collect bottles, would rather see everybody polish off whatever bottles there are! Doug are you sure you won't have to stay over the weekend in order to finish all the alcohol you are going to get? i was planning plenty of time for consumption in dublin, shame its canceled. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestServer::start_gdb
On Thu, 19 Jul 2001, Stas Bekman wrote:
now -debug will always set the apr_dso_load and modperl_hook_init bp and
run after these.
i think you misunderstood my comment before. no breakpoints should
be set by default, only when -breakpoint is specified. and rather than
using apr_dso_load to wait until modperl is loaded, you should use
ap_run_pre_config since there might be more dso's besides modperl being
loaded. after applying your patch, i get:
Global symbol $debugger requires explicit package name at
Apache-Test/lib/Apache/TestServer.pm line 133.
needs to be $opts-{debugger} instead. otherwise works great, this is a
really cool feature!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestServer::start_gdb
looks great stas, feel free to commit.
there's just one style nit
if () {
} else {
}
which should be:
if () {
else {
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[patch] ithreads + refto bug (fwd)
fyi, this was the cause of modules/cgi #3 test failure..
-- Forwarded message --
Date: Wed, 1 Aug 2001 09:47:28 -0700 (PDT)
From: Doug MacEachern [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [patch] ithreads + refto bug
strange bug, happens in both 5.6.x and bleedperl, the following script:
package Foo;
use strict;
sub TIEHANDLE { bless {} }
my $cnt = 'a';
sub READ {
$_[1] = $cnt++;
1;
}
sub do_read {
my $fh = shift;
read $fh, my $buff, 1;
print -$buff-\n;
}
$|=1;
tie *STDIN, 'Foo';
read STDIN, my $buff, 1;
print =$buff=\n;
do_read(\*STDIN);
untie *STDIN;
prints:
=a=
then in the call to do_read(\*STDIN), $fh is no longer tied.
with vanilla (non-ithreads) Perl, it prints the expected:
=a=
-b-
the bug seems to be S_refto (called by pp_srefgen), which the patch below
fixes, all tests pass.
Index: pp.c
===
RCS file: /usr/local/cvs_repository/perl-current-mirror/pp.c,v
retrieving revision 1.1.1.33
diff -u -r1.1.1.33 pp.c
--- pp.c2001/07/31 15:56:35 1.1.1.33
+++ pp.c2001/08/01 16:37:16
@@ -467,7 +467,7 @@
SvTEMP_off(sv);
(void)SvREFCNT_inc(sv);
}
-else if (SvPADTMP(sv))
+else if (SvPADTMP(sv) !(isGV(sv) GvIN_PAD(sv)))
sv = newSVsv(sv);
else {
SvTEMP_off(sv);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache-Test dir moved
On Wed, 1 Aug 2001, Geoffrey Young wrote: I've noticed that Apache-Test dir has been silently moved from modperl-2.0 and linked from somewhere else. I guess that Ryan moved it to the httpd-test project. the idea is to have it live there and have a mod_perl 2.0 checkout get the files from the httpd-test repository as perl-framework/Apache-Test/ yup, he didn't nofify the lists about the change. a fresh 'cvs co modperl-2.0' looks the same as always, just that Apache-Test now lives in the httpd-test/perl_framework/Apache-Test repository. well, I think that dev@ is still the place for Apache-Test development (at least that's where the commits seem to be going :) but the generic httpd-test mailing list is [EMAIL PROTECTED] yeah, we can keep discussion/patching here for now at least. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Makefile.PL problem
On Wed, 1 Aug 2001, Tom Lancaster wrote: Hi, I'm using cvs latest httpd-2.0, modperl-2.0 and although apache compiles and installs fine I've not been able to get through perl Makefile.PL in modperl-2.0. The root of the error appears to be Apache::Build-httpd_version, which is not returning a good value. If I hard code '2.0' into Makefile.PL I get some of the way through, but the perl modules starting with WrapXS/Apache/Access/Access.pm complain '/usr/bin/apxs -q INCLUDEDIR' failed: apxs:Error: 0 0prefix)/bin/httpd not found or not executable looks like your apxs is broken. post the output of 'perl util/config.pl' (run from the modperl-2.0 directory) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestApache cgihandler.pm
On Thu, 2 Aug 2001, Stas Bekman wrote: On 1 Aug 2001 [EMAIL PROTECTED] wrote: dougm 01/08/01 10:03:19 Modified:t/response/TestApache cgihandler.pm Log: workaround for modules/cgi #3 failure it seems to work :) cool. that was a needle in the haystack bug. Now, if I load CGI.pm via the newly crafted PerlModule I've a different problem with modules/cgi #5 [Thu Aug 02 09:46:17 2001] [error] [client 127.0.0.1] CGI.pm does not think this is mod_perl at /home/stas/apache.org/modperl-2.0-perlmodule/t/response/TestModules/cgi.pm line 17. probably because Apache::compat needs to be loaded first. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestApache cgihandler.pm
On Thu, 2 Aug 2001, Stas Bekman wrote: so why would this test(s) fail, then? because you moved the require of CGI to happen before the t/response/TestModules/cgi.pm test required Apache::compat. I don't think it was exercising 1.x compat, or was it? anything that uses CGI.pm is excercising 1.x compat. it just 'use Apache::compat ();' and then tests for $CGI::MOD_PERL. We could make sure that CGI.pm is reloaded via do()? we know Apache::compat has to be loaded before CGI.pm, so we just do that in the test setup. Why TestModules/cgi.pm need the Apache::compat part? I thought TestApache/compat was exercising it. because CGI.pm needs Apache::compat. What's the conclusion then? - Put this issue on hold, resolve later - provide MP_APACHE_COMPAT option - merely document it I suppose that it's possible that someone will want to enable Apache::compat for some specific vhs and not the whole server. just document for now, add a todo for MP_APACHE_COMPAT option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestApache cgihandler.pm
On Thu, 2 Aug 2001, Stas Bekman wrote: Is it because the current version of CGI.pm doesn't support mod_perl 2.x yes. and will have to a special handling of mod_perl 2.x? umm, no, it just needs Apache::compat loaded. but really, see the comment in Apache::compat: #1.xx compat layer #some of this will stay as-is #some will be implemented proper later on anyhow, CGI.pm shouldn't need any special casing for mod_perl. maybe something that folks interested can help fix for CGI.pm 3.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Makefile.PL problem
hmm, can you run httpd -V from the command line? what configure arguments did you build apache with? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: www.apache.org/dist/perl/
On Thu, 2 Aug 2001, Ask Bjoern Hansen wrote: I just did a cp /www/perl.apache.org/dist/mod_perl-1.26.tar.gz /www/www.apache.org/dist/perl/ so 1.26 will be available on the apache.org mirrors. can we just make that a symlink to perl.apache.org/dist ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sorting the usage items
On Thu, 2 Aug 2001, Stas Bekman wrote: was it: +1 for sorting? yep. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Makefile.PL problem
On Fri, 3 Aug 2001, Stas Bekman wrote: I was thinking that it'd be a more user friendly interface to provide something like: PerlINC /home/dev1/lib/perl of course this is not an urgent thing. right, lets save this stuff till the end. if there's a way to do something now, let's use it and add more user-friendly ideas to the todo, noting the existing mechanism. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ./t/TEST to trigger make
On Fri, 3 Aug 2001, Stas Bekman wrote:
Doug,
I find it very incovenient to run 'make' everytime I change
Apache/TestConfig.pm or similar files. Of course I could run 'make test'
but then it runs all tests, whereas I want to run only one test to
exercise something that I work on.
Basically I want:
./t/TEST protocol/echo
to detect whether some src files were modified and update them for me (so
./t/TEST will act like 'make').
Alternatively I'd like to use the source dir Apache-Test/lib, while I
develop, so I don't have to copy the files over (or run 'make').
the tests already point to Apache-Test/lib:
% grep Apache-Test/lib t/TEST
use lib map { $_/Apache-Test/lib } qw(. ..);
the server side might not, but adding Apache-Test/lib to modperl_inc.pl
would fix that.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: clones and parent opts
On Fri, 3 Aug 2001, Stas Bekman wrote: Again, the question is how to add two different paths to vh and main Perl (or two vhs), while inheriting everything from the main Perl. you must use +Parent to have 2 different versions of the same module. if you want each vhost to have the same perl code preloaded, pass the same -M switches and or the same startup script. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: automatically generated files improvement
On Sun, 5 Aug 2001, Stas Bekman wrote:
in fact I've realized that you cannot ahead what frame the actual
filegeneration has been called from. Sometimes it's 2 and sometimes it's
more:
that looks great, feel free to commit.
just remember whitespace style:
+return #WARNING: this file is generated, do not edit\n.calls_trace();
... . calls_trace()
+sub calls_trace{
sub calls_trace {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: clones and parent opts
On Thu, 9 Aug 2001, Stas Bekman wrote: ok, cool, I was mainly just trying to see whether it works, not to make a real patch yet. ok. Oh, yeah, I see now that it's only mentioned in the docs, not tests available. What would be a nice to test to write. Will the require of identical file names in different servers will be sufficient? (something similar that I've posted with this hardcoded example) sure. what do you mean? That's the point of my question :) If I put +Parent I don't have these inhereted, that's why I had to manually add each of these. PerlSwitches is inherited, unless your vhost declares a PerlSwitches. Since I've spent so much time on these already, I'd rather finish them. I just wasn't sure whether we needed these. more tests the better. todo ? sure. so we can probably can postpone this until somebody asks :) and todo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: filter/input_body fails
On Fri, 10 Aug 2001, Stas Bekman wrote: the following test fails: % ./t/TEST -v filter/input_body filter/input_body1..2 yeah, i fixed it but hadn't committed, its in now. see new-httpd discussion if you're interested in why. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: filter/input_body fails
On Fri, 10 Aug 2001, Stas Bekman wrote: that's from the output of ./t/TEST -times=5 -order=random yeah, i have seen this test breakage from when you pointed it out before, haven't gotten to debugging it yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PerlRequire test + PerlConfigPerl patch
On Mon, 13 Aug 2001, Stas Bekman wrote:
I've this:
t/modules/PerlRequire.t
t/response/TestModules/PerlRequire.pm
if you do 'find t/ -name *.pm' you'll see every .pm is lowercase, as are
all .t files. the lowercase is also forced as part of the naming
convention, you know how i like lowercase :)
can we add a capability for .pm in t/response to generate things?
For example, rather having real parent/PerlRequireTest.pm and
vh/PerlRequireTest.pm, I think it'd be much clearer to have them all in
.pm file and somehow generated on the fly.
sure. to make it super generic, how about if a test .pm could have a
'sub CONFIGURE {}', which is passed the Apache::TestConfig object when
configuration is generated? then you have access to all the directory
info, gendir(), genfile() and things like that. the trick would be that
most .pm tests will currently only run inside the server so for the
moment you'd need to open the .pm, read in just the CONFIGURE part and
eval it.
My perfect vision of a test is having everything in one file: .t, .pm and
any other parts, which makes it super easy to write new tests,
perception-wise. But of course harder to debug, so probably it's not an
option.
i very much like having one .t and one .pm too. hopefully in the long run
will make things easier to debug, once we get all this auto-generated-
do-exactly-what-i-want stuff right.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TAKE13 error
On Mon, 13 Aug 2001, Geoffrey Young wrote: hi... on the 1.3 front, I had to add this patch to get TAKE13 to work. I couldn't think of a prototype to match it, so users of will have to set TAKE13 explicitly in the Makefile.PL. thanks, that's in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help wanted: Apache-Test cpan bundle
On Tue, 14 Aug 2001, Stas Bekman wrote: You've already uploaded something on your site, does it do everything you've described above? Or is it just a hardcoded copy of everything that you've retrieved manually? nah, i just did it by hand. I was thinking about implementing this, but I didn't know you needed it yesterday. it would still be very nice to have in the future, for updates, adding new modules, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: filter/lc segv
On Mon, 20 Aug 2001, Stas Bekman wrote: Philippe and I are back from Bangkok to find tens of Apache-Test commits from doug, wow! :) oh, so that's why you've been so quiet ;) Just a quick 'cvs up' (httpd-2.0/modperl-2.0), rebuild, 'make test' reveals: make test won't start the server, with lots of segv's in error_log, though if I run './t/TEST -d' the server starts, but segv's on filter/lc: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2051 (LWP 13905)] 0x0809b2c0 in find_entry (ht=0x0, key=0x8afc1b4, klen=-1, val=0x0) at apr_hash.c:270 i've been using the prefork mpm since threaded had been unstablized and there's talk of making the new 'worker' mpm the default. i don't see this problem with prefork. there have been changes to mod_mime (where this is happening), i guess not all the problems have been sorted out yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] adjusting for API changes
On Sun, 26 Aug 2001, Stas Bekman wrote: this patch is needed to build mod_perl with the latest httpd-2.0 please go ahead and commit, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pushing method handlers by reference
On Wed, 15 Aug 2001, Geoffrey Young wrote:
hi all...
I just got around to fixing something that has been a splinter in my mind
for a while now...
it all started with Andrew Ford documenting that push_handlers() didn't
work for method handlers. it turns out they work just fine so long as you
use the (undocumented?) string literal form
$r-push_handlers(PerlInitHandler = 'My::Class-handler');
instead of the code reference form. While this makes sense, it bugged me.
anyway, I set to work on it this morning and was able to get method handlers
to work for the code reference form as well, but it required a patch to
UNIVERSAL::can().
the below patches allow the following formats, in addition to what is
already currently supported
$r-push_handlers(PerlFixupHandler = My::Class-can('foo'));
$r-set_handlers(PerlFixupHandler = [My::Class-can('foo')]);
cool! i don't understand why universal.c needs a patch, the :method
attribute should have already set that flag. could you make it so there's
a new function that checks CvFLAGS and the $$ prototype, so both
perl_handler_ismethod and your new function call that?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] adding more checks
On Sun, 26 Aug 2001, Stas Bekman wrote:
+# $thaw wasn't blessed
+if (ref $thaw eq 'HASH') {
+die couldn't find apache_test_config.pm;
+}
+
this isn't right, it will die whenever things are clean.
maybe you meant to do that only if $args-{thaw} ?
sub find_apache_module {
my($self, $module) = @_;
+
+warn module is not defined,
+return undef unless $module;
don't you want colored warning? :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] adding more checks
On Sun, 26 Aug 2001, Stas Bekman wrote: please try this patch. it exposes the problem with messed up setup. i think your mailer is wrapping: patching file Apache-Test/lib/Apache/TestConfigPerl.pm patching file t/directive/perlrequire.t patch: malformed patch at line 79: || ''; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] adding more checks
On Sun, 26 Aug 2001, Stas Bekman wrote: I've to checkout the whole tree from scratch. yikes. i have seen apache_test_config.pm get into a messed up state before. you should be able to: cd t/conf rm *.* cvs up to get unstuck. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] adding more checks (fwd)
i didn't try the patch, but i think i just hit the same problem. can you test if its fixed now? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pushing method handlers by reference
On Mon, 27 Aug 2001, Geoffrey Young wrote:
ok, here is my first go - I'm not sure if it is sylistically what you were
after, but I will rework it some to suit now that the proof-of-concept is
over...
just out of curiosity, I tried to get the method name from the gv returned
from sv_2cv using GvNAME and kept segfaulting, then I noticed you never used
that gv in similar calls... is that gv unreliable?
not sure, but CvGV(cv) should be reliable.
+is_method = perl_cv_ismethod(cv);
+
if (!is_method (cv SvPOK(cv))) {
is_method = strnEQ(SvPVX(cv), $$, 2);
}
perl_cv_ismethod should also include this $$ prototype check, no?
otherwise looks good.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] Makefile.PL prerequisites
On Sun, 26 Aug 2001, Stas Bekman wrote: of course they can ;) should I cook a new patch for it? Since mod_perl will be always distributed with Apache-Test, I suppose that all the things that can be used in Apache-Test and ModPerl:: should live in Apache::Test* namespace. Am I right? So this functionality should go into Apache::TestMM? right, then Apache-Test can use the same code. but, would this not be duplicating what PREREQ_PM already does? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pushing method handlers by reference
On Mon, 27 Aug 2001, Geoffrey Young wrote: do I need some sort of check on cv before calling perl_cv_ismethod(cv) here? if cv is returned from sv_2cv() just checking that its not NULL should be fine. I guess the last thing is - how do I check my refcounts to make sure I got all the dec and inc stuff right? in general, anything you _inc needs to be _dec'd. however if the _dec needs to happen after your return from the function, sv_2mortal() can be used to arrange for that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pushing method handlers by reference
one problem, i think there's a leak here: + pclass = newSVpv(HvNAME(stash),0); since pclass was already set to newSVsv(sv) at the beginning. can you test changing to: sv_setpv(pclass, HvNAME(stash)); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scan's diff
On Wed, 29 Aug 2001, Stas Bekman wrote: it's still not working perfectly, since it has to fish $dump out of the file, and I see that it doesn't work for all current files. you could change the warning header to include: # __END_OF_HEADER__ or something to make it easier to parse/compare. and those files don't actually need the extra 1; at the end since $Apache::FunctionTable = ... will result in true value return. I think a much better solution will be to write the $file.dump.md5 and compare Digest::MD5::md5($dump) with the contents of this file. that would be slick, but that's another cpan dependency (for those using 5.6.1). if it makes it easier to leave the date out of the .pm, you could do that and maybe generate a FunctionTable.datestamp with the generation date. actually, something like FunctionTable.info that includes datestamp, module magic number, and whatever else might be useful down the road. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scan's diff
On Wed, 29 Aug 2001, Stas Bekman wrote: What's the problem with having new dependencies on CPAN? Digest::MD5 seems to be a core module. Remember that everybody talks about SDKs, so we will end up with dependencies anyways. If we do PREREQ_PM, CPAN will automatically install all the requirements, so will Bundle::Apache2. Digest::MD5 is not a core module in 5.6.1. we should not be creating dependencies on cpan modules when they are not needed. File::Compare is a core module, use that instead. having cpan dependencies for building mod_perl is a pita, no matter how hard CPAN.pm tries to make things easy, it is not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [patch] ithreads + refto bug (fwd)
On Wed, 29 Aug 2001, Geoffrey Young wrote:
hi...
the following registry script only prints foo for me using bleedperl...
my $r = shift;
$r-send_http_header('text/plain');
$r-print('foo');
print 'bar';
I think it started around the time Doug sent this message along, but I can't
be sure - it's definitely been a while, though. sorry it took me so long to
report it, but got caught up in other things...
I tried the original version and Doug's patch (since bleedperl looks
different already) but none seem to solve the problem.
maybe something needs to be fixed at the Apache::PRINT level? my bleedperl
seems rather broken these days (none of the tests pass) even after rsync'ing
from scratch, so it may be just me but I thought I'd bring it up anyway...
have you tied STDOUT ? it is only done for you if you SetHandler
perl-script, SetHandler modperl does not tie STDOUT.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Request fails on Mac OS X (Darwin)
On Tue, 28 Aug 2001, Ken Williams wrote: dyld: ../apache_1.3.20/src/httpd multiple definitions of symbol _ApacheRequest___parse /Library/Perl/darwin/auto/Apache/Request/Request.bundle definition of _ApacheRequest___parse /Library/Perl/darwin/auto/Apache/Cookie/Cookie.bundle definition of _ApacheRequest___parse guessing that libapreq has been linked static with both Request.so and Cookie.so (or whatever the osx .so extension is). and guessing osx doesn't like that. no idea how to force them to link against a shared libapreq though, depends on if its even getting built. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PerlSetEnv/PerlPassEnv questions
On Tue, 4 Sep 2001, Stas Bekman wrote: I'm working on implementing PerlSetEnv/PerlPassEnv right now. 1. I see that SetEnv elem is missing from modperl_config_srv_t struct? I can see it only in modperl_config_dir_t struct. Does that mean that we cannot have a PerlSetEnv in httpd.conf's main level? that's how it is in 1.x, we can change for 2.0. 2. Regarding PerlPassEnv. It seems that currently *all* the enviroment vars from shell are available at request time. At least that's what I see when I run a test. they are not 'passed' so much as they are not yet 'cleared' from %ENV. 3. I still have problem with automatic configuration generation from within test's __DATA__ section. Consider that I want this to be autogenerated from the test response file: PerlPassEnv HOME Location /TestDirective::perlpassenv SetHandler modperl PerlResponseHandler TestDirective::perlpassenv /Location needs to be added to Apache::TestConfigPerl::outside_container. Is there a chance we can make things less magically DWIM and more explicit DWIM? yeah, but rather than new syntax, i'd rather change it to how config is included from test.c modules. the 'magic' in .pms was pretty much just to auto-add the Location ... for you. i would be fine with backing out the current magic and just add support for: Location or Location __PACKAGE__ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] implementing PerlPassEnv + PerlSetEnv directives
On Tue, 4 Sep 2001, Stas Bekman wrote: I also have a question regarding apr_table_t. When creating the table with apr_table_make one has to specify nelts. But then it grows automatically as required (right?), so what's the point of nelts then? pre-alloc? In any case what netls should I use for env vars table? I've used 2. yes, purpose of nelts is to pre-alloc. your patch looks good, but i want to hold off for the moment. for the same reason i've not gone forward with implementing this yet. we need to change things to env stuff does not modify the underlying C environ array until an actual fork happens that will need to have environ modified. this is for both performance and i'm pretty sure it isn't thread safe to modify environ in concurrent threads. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Registry design
On Tue, 4 Sep 2001, Stas Bekman wrote: I think Doug has planned to have it as a standalone project, which is fine with me, but it's absolutely a must to have it in the core distribution, rather than in Bundle. Most of the people use mod_perl because Apache::Registry and PerlRun, so having it in a bundle seems very wrong to me. So how do we host it? by 'standalone' i just meant similar to Apache-Test, self-contained in its own subdirectory with Makefile.PL, MANIFEST, etc. this way 2.0's new-improved version should be able to replace 1.x's, since the Perl apis are compatible. it will still be distributed with modperl-2.0, just as Apache-Test is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Registry design
On Tue, 4 Sep 2001, Geoffrey Young wrote: I wonder how many people actually take advantage of NameWithVirtualHost=1. seems that the PerlRun methodology (filenames) is a much cleaner solution that invites less problems/confusion. using filenames makes for long packages names == lengthy lookups and more memory than we need. at least the way it is currently implemented where each '/' turns into '::'. could be that s,/,_,g is good enough, but haven't thought about this for a while. in any case, we should get rid of the NameWithVirtualHost stuff, its caused too many problems in the past. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] enabling tainting mode
On Wed, 5 Sep 2001, Stas Bekman wrote: I've noticed that currently we don't run the tests under -T, this patch enables -T mode and fixes one taint problem. oh good, go ahead and apply. BTW, Doug, try to comment out the untaint patch in the second file. apache/post dumps core then, when run with other tests '.t/TEST apache'. But works fine standalone. ok, i'll take a look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] pre-run core scan
On Wed, 5 Sep 2001, Stas Bekman wrote:
The new scanning for the core file is nice, but many times I get a false
alarm when I get an old core file alert. This patch warns the user when a
core file is found before tests have started.
good idea.
but how to break this habit of yours? ;-)
+sub warn_core{
+sub warn_core {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] a new silly protocol test
On Wed, 5 Sep 2001, Stas Bekman wrote:
I've mungled protocol/echo to do something fancier. Dunno whether it's
worth adding or not. It's only fun if you run it with -v, and we can
supply our own knowledge base to talk our way :)
way cool!
+use constant HAS_ELIZA = eval { require Chatbot::Eliza;};
...
+
+plan tests = 1 + @test_strings, ['eliza'] \HAS_ELIZA;
but this should just be:
plan tests = 1 + @test_strings, test_module 'Chatbot::Eliza';
assuming TestProtocol::eliza only depends on Chatbot::Eliza.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: help wanted: Apache-Test cpan bundle
On Thu, 6 Sep 2001, Stas Bekman wrote: does it work for you? Should it go to CPAN, or do we want to keep it for us? :) If CPAN, is the name OK or should I announce it first on modules newsgroup? i haven't actually tried it yet. but its up to you if it should go on cpan, i would vote yes. name is fine i think, or something like CPAN::BundleDist, up to you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Registry design
On Thu, 6 Sep 2001, Stas Bekman wrote: what's the replacement of NameWithVirtualHost? Obviously we need something to distinguish between vhs. well, if possible we should distinguish between the uri and requested resource instead. in otherwords, we have the: r-uri = r-filename translation, just need to figure out if r-filename is the actual filename or a symlink (readlink can be used to get the real filename). then create a package based on the filename, but with as few package:: levels as possible (hopefully none beyond Apache::RegistryROOT::filename) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trapping SEGV from perl?
On Thu, 6 Sep 2001, Stas Bekman wrote: so there is no way to trap such SEGV? I wanted to work on automatic SEGV trapping and automatically producing the trace, I thought that was a good example to work with. not with a Perl signal handler. however, you can install a C signal handler and print out PL_curcop-cop_line, PL_curcop-cop_file to report the linenumber:file in the Perl core where the segv happened. should be possible to write a C version of caller() too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scan's diff
On Thu, 6 Sep 2001, Stas Bekman wrote: something like that. We need to disregard: 'Sun Aug 19 10:32:24 2001' that would be fine. as i suggested eariler, feel free to change the format of that header which includes the date to make it easier to rip this stuff out. i'd rather see this than a .info file and the .tmp mv-if-diff stuff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] Build system
On Sat, 8 Sep 2001, Stas Bekman wrote: That's what I've done a few weeks ago, after Doug suggested to do so as the threaded mpp wasn't stable anymore. 'worker' is probably going to replace 'threaded' and seems pretty stable. the bug philippe is seeing is clearly a bug in Perl (not the threaded mpm), but i still have yet to update perl-current. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] Build System relative path to apxs (revisited)
On Sat, 8 Sep 2001, Philippe M . Chiasson wrote: Sadly, there doesn't seem to be a good way to figure out of something is a path in the first place. Don't want to put `pwd` in front of every single argument that doesn't start with '/' So, this just attempts to clean MP_APXS. thanks. one request, can you change your editor mode to match the current style? that is no tabs, indent level 4 spaces. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] Top Level MANIFEST MANIFEST.SKIP
On Sat, 8 Sep 2001, Philippe M . Chiasson wrote: With these 2 top level MANIFEST files, make clean make distclean is a lot less noisy. that MANIFEST contains a bunch of stuff that will never be distributed, e.g. .cvsignore, Apache-Test/lib/Apache/.#TestConfig.pm.1.50, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: make install for libmodperl.so?
On Sat, 8 Sep 2001, Stas Bekman wrote: I've tried to use Apache-Test outside of modperl, but the server won't find libmodperl.so, since it wasn't installed on my system on 'make install'. Is this on purpose? I see ModPerl::MM::install is supposed to do that, but it doesn't end up in Makefile. Or do I miss something? ModPerl::MM::install does not try to install libmodperl.so the *.so references in there are for the *.xs modules. patch welcome of course. I've manually copied libmodperl.so to httpd-2.0/modules/. that's what i've been doing. actually, i do: ln -s ~/ap/modperl-2.0/src/modules/perl/libmodperl.so ~/ap/prefork/modules/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] Build system
On Sun, 9 Sep 2001, Stas Bekman wrote: On Sat, 8 Sep 2001, Doug MacEachern wrote: mpm), but i still have yet to update perl-current. does perl-current pass all the tests for you Doug? hard to tell since i am not using perl-current current. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl vs PerlConf
On Sun, 9 Sep 2001, Stas Bekman wrote: but as you said we have this already, and it doesn't take the problem away. You have to remember to declare the package when you just want to run some code and switch back to Apache::ReadConfig when you want to do the configuration. To me it makes sense to let Perl run in the package main, unless specified differently and have PerlConf or whatever which explicitly declares the Apache::ReadConfig package for you. I'm just trying to make things less error-prone for users. you think it will be less error-prone to change the behavior of how Perl worked from 1.x? if you want something to run in package main, say so with 'package main' or use PerlRequire. changing the behavior of what Perl currently does and adding a new directive just to be in a different package does not make any sense to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl vs PerlConf
On Sun, 9 Sep 2001, Stas Bekman wrote: users don't read the documentation thoroughly, and even if they do, chances are that the only thing they will rememember after reading the docs is that Perl can run any code. right, docs won't be read, so Perl should behave as it did in 1.x, code is run in package Apache::ReadConfig. At least I'd suggest not to define the Apache::ReadConfig by default, let the user define it, than it will make Perl sections, as a plain Perl scratch place, and if you will have to specify package Apache::ReadConfig; before changing configuration, then things will be more explicit. no, this changes the 1.x behavior. Perl was designed to generate configuration, so Apache::ReadConfig is the default. if somebody wants to use it for something else, then they can declare 'package foo;' or use PerlRequire instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PerlIO?
On Sun, 9 Sep 2001, Stas Bekman wrote: There is an issue with r-print that isn't implemented yet. I guess I cannot really move on with Registry, if print() is not available, unless I do a temporary overload with write($buf, length $buf). Which means that we have to implement PerlIO first. is that correct? If so how do we approach this issue, Can you please give us a few hints how to start? $r-print does not depend on PerlIO. it will be like the current puts(), but check the value of $| and flush if non-zero. for the moment you can 'use Apache::compat ()', notice the comment in there: #there's enough here to get simple registry scripts working #add to startup.pl: #use Apache::compat (); #use lib ...; #or something to find 1.xx Apache::Registry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] $r-no_cache() Take 1
On Sun, 9 Sep 2001, Philippe M . Chiasson wrote: I guess it's been a while since I actively contributed to anything, so I gotta get my dicipline back. Sorry 'bout that. no problemo, just been super strict about style, hoping we can maintain a consistent style throughout modperl-2.0. unlike, say, apache-2.0 and perl-5.7.2-dev, are just too far along with mish-mash of styles. it can be a real pain to read/patch code that is all mixed up like that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
