Geoffrey Young wrote:
- We still don't have Test::More in the 5.6.1 core (it was added in
5.6.2/5.8.0), so we can't rely on it being available.
sure, but you can conditionally skip over those tests for users that don't
have Test::More installed. I know that currently doing that is kind of
ugly,
Am I correct to say that Test::More is in the core for all but 5.6.1 the
required minimum by mp2?
yes, but see below - we would have further version restrictions if we chose
to make T::M the engine for the entire mp2 test suite.
so if we make a dependency on Test::More only
the 5.6.1 users
anyway, in the end I guess I wouldn't suggest moving to T::M entirely
just
yet. but if you want to use it occasionally within certain tests I think
that's fine.
Of course another alternative is to bundle a sufficient version of T::M
under t/.
that's an idea. so long as it's not
Stas Bekman wrote:
Of course another alternative is to bundle a sufficient version of T::M
under t/.
that's an idea. so long as it's not installed with 'make install'. or
indexed by cpan either, I suppose.
anything living under t/ is not installed on 'make install' and not
scanned by PAUSE.
Stas Bekman wrote:
Stas Bekman wrote:
Of course another alternative is to bundle a sufficient version of T::M
under t/.
that's an idea. so long as it's not installed with 'make install'. or
indexed by cpan either, I suppose.
anything living under t/ is not installed on 'make
Christopher H. Laco wrote:
Now that I've gotten a few other module updates out of the way, I want
to get back to the thought of cookies within A-T. Two things were
mentioned that would help the A-T project in some way.
First, possibly add pod doc on how to use cookies within A-T using
Michaels
* [EMAIL PROTECTED] wrote:
+ *) core: Error out on sections that are missing an argument instead of
+ silently consuming the section. PR 25460.
+ [Geoffrey Young, Paul Querna]
:-( Actually, for IfDefine I've sold that that as feature, since it's the
only reliable way to produce
Andr Malo wrote:
* [EMAIL PROTECTED] wrote:
+ *) core: Error out on sections that are missing an argument instead of
+ silently consuming the section. PR 25460.
+ [Geoffrey Young, Paul Querna]
:-( Actually, for IfDefine I've sold that that as feature, since it's the
only reliable way
* Justin Erenkrantz wrote:
--On Monday, November 29, 2004 11:44 AM +0900 Yoshiki Hayashi
[EMAIL PROTECTED] wrote:
More than a year after I proposed web site translation, I
finally sat down for a while and did necessary coding to add
translation support.
BTW, this might need to be
* Paul Querna wrote:
What is wrong with IfDefine 0?
First, that IfDefine is now no longer reliable ;-)
And second -D 0, of course.
I didn't feel it was correct to never allow -D 0 from the command line,
You mean, -D0 is not allowed?
But wait, IfDefine might work...
nd
--
print Just
[EMAIL PROTECTED] wrote:
Log:
Properly export ap_listen_* functions.
* server/listen.c: Add AP_DECLARE as appropriate.
* include/ap_listen.h: Add AP_DECLARE as appropriate.
Hi,
Your patch breaks win32 build.
The reason is that the AP_DECLARE is __stdcall while
cmd_table is __cdecl.
Can you revert
André Malo [EMAIL PROTECTED] writes:
* Justin Erenkrantz wrote:
--On Monday, November 29, 2004 11:44 AM +0900 Yoshiki Hayashi
[EMAIL PROTECTED] wrote:
More than a year after I proposed web site translation, I
finally sat down for a while and did necessary coding to add
translation
On Sun, 28 Nov 2004, Stas Bekman wrote:
Please take a look at DBDI Project.
http://groups.google.com/[EMAIL PROTECTED]
which already targets Perl6 DBI, Python DBI, Ruby DBI, PHP DBI etc.
Hmmm.
Interesting in principle, but there's not sufficient information at that
URL to determine whether
On 29 Nov 2004 10:43:30 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mturk
Date: Mon Nov 29 02:43:28 2004
New Revision: 106902
...
Also log the child pid so that logging
makes sense.
...
--- httpd/httpd/trunk/modules/proxy/proxy_util.c(original)
* [EMAIL PROTECTED] wrote:
Author: mturk
Date: Mon Nov 29 02:09:15 2004
New Revision: 106899
URL: http://svn.apache.org/viewcvs?view=revrev=106899
Log:
Add missing pcreposix.h from vendor/pcre/5.0.
*argh*. Revert this. It isn't missing. If you had followed the recent
commits, you'd have
André Malo wrote:
* [EMAIL PROTECTED] wrote:
Author: mturk
Date: Mon Nov 29 02:09:15 2004
New Revision: 106899
URL: http://svn.apache.org/viewcvs?view=revrev=106899
Log:
Add missing pcreposix.h from vendor/pcre/5.0.
*argh*. Revert this. It isn't missing. If you had followed the recent
commits,
* Mladen Turk [EMAIL PROTECTED] wrote:
Well I'll remove that, but something like that (movig files that were
for years in one location to other) should be put in the dev list
or at least to changelog thought.
It *was* put in the 'PCRE in 2.1/2.2' thread.
nd
André Malo wrote:
* Mladen Turk [EMAIL PROTECTED] wrote:
Well I'll remove that, but something like that (movig files that were
for years in one location to other) should be put in the dev list
or at least to changelog thought.
It *was* put in the 'PCRE in 2.1/2.2' thread.
Perhaps it was, but I
Nick Kew wrote:
On Sun, 28 Nov 2004, Stas Bekman wrote:
Please take a look at DBDI Project.
http://groups.google.com/[EMAIL PROTECTED]
which already targets Perl6 DBI, Python DBI, Ruby DBI, PHP DBI etc.
Hmmm.
Interesting in principle, but there's not sufficient information at that
URL to
Mladen Turk wrote:
Stas Bekman wrote:
So it's not possible that the number of logs relates to the number of
child_init calls. Though I do have 32 vhosts, which matches much
better the number of debug lines (33). So does it print one per vhost?
Yes, they are duplicated for each virtual host and
On 29-Nov-04, at 4:05 AM, André Malo wrote:
* Paul Querna wrote:
What is wrong with IfDefine 0?
It's ugly and non-intuitive.
Just out of curiousity, what do people think is wrong with the
Comment directive implemented by this micro-module:
On Mon, Nov 29, 2004 at 09:44:14AM -0500, Rici Lake wrote:
...
Just out of curiousity, what do people think is wrong with the
Comment directive implemented by this micro-module:
https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49
That module uses a feature of the
On 29-Nov-04, at 10:10 AM, Greg Stein wrote:
So no... I don't like mod_comment. It uses a feature that I dearly
wish to see removed from httpd.
I agree 100% on removing that feature. If it were gone, something
like mod_comment would have to be implemented in the core, I suppose.
However, I was not
* Greg Stein [EMAIL PROTECTED] wrote:
https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49
That module uses a feature of the configuration parser that should be
removed. The capability of code external to the config parser taking
over the reading/parsing of the config file
On Mon, Nov 29, 2004 at 04:20:21PM +0100, Andr? Malo wrote:
* Greg Stein [EMAIL PROTECTED] wrote:
https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49
That module uses a feature of the configuration parser that should be
removed. The capability of code external to the
* Greg Stein [EMAIL PROTECTED] wrote:
Taking over the reading/parsing of the file pointer. We pass the fp to
modules (when they process a directive), allowing them to read from
it. Bad bad bad. Especially when you're trying to read your config
from some place funky.
I seem to miss something
Rephrasing the question slightly:
On 29-Nov-04, at 9:44 AM, Rici Lake wrote:
Just out of curiousity, what do people think is wrong with the
Comment directive implemented by this micro-module:
I meant to ask: What do people think about a Comment
directive, which would simply absorb the
(this likely applies to some other threaded MPMs)
Sometimes the MPM has to create a new child process even though there
are no free scoreboard slots. This can occur when child process
currently consuming scoreboard slots are trying to exit, but still
have at least one thread serving an active
--On Monday, November 29, 2004 10:48 AM +0100 Mladen Turk [EMAIL PROTECTED]
wrote:
Your patch breaks win32 build.
The reason is that the AP_DECLARE is __stdcall while
cmd_table is __cdecl.
Huh? I don't know Win32 at all, so this makes no sense.
Can you revert the patch or use the
Justin Erenkrantz wrote:
--On Monday, November 29, 2004 10:48 AM +0100 Mladen Turk
[EMAIL PROTECTED] wrote:
Your patch breaks win32 build.
The reason is that the AP_DECLARE is __stdcall while
cmd_table is __cdecl.
Huh? I don't know Win32 at all, so this makes no sense.
__stdcall: The callee
On Mon, Nov 29, 2004 at 06:30:35PM +0100, Mladen Turk wrote:
__stdcall: The callee cleans the stack
__cdecl (default): The stack is cleaned up by the caller
So you can not mix that two.
The cmd_table uses __cdecl functions and you are providing
__stdcall function, so the build fails.
You
Justin Erenkrantz wrote:
On Mon, Nov 29, 2004 at 06:30:35PM +0100, Mladen Turk wrote:
__stdcall: The callee cleans the stack
__cdecl (default): The stack is cleaned up by the caller
So you can not mix that two.
The cmd_table uses __cdecl functions and you are providing
__stdcall function, so the
At 09:31 AM 11/29/2004, André Malo wrote:
* Greg Stein [EMAIL PROTECTED] wrote:
Taking over the reading/parsing of the file pointer. We pass the fp to
modules (when they process a directive), allowing them to read from
it. Bad bad bad. Especially when you're trying to read your config
from
Is there some doc explaining the usage of signal handlers under different
mpms? I get SIGALRM working fine under prefork mpm, but not under worker.
I assume that it traps the signal before the user code's handler runs,
simple grepping doesn't come up with anything useful, so if someone who
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
This is the offending code;
endp = ap_strrchr_c(arg, '');
if (endp == NULL) {
return unclosed_directive(cmd);
}
Aah! understood, thanks ;-)
So I'd guess, there's currently no good way for implementing containers?
nd
At 11:51 AM 11/29/2004, Stas Bekman wrote:
Randy Kobes wrote:
I've been testing out some perl scripts to emulate
apxs/apr-config/apu-config on Win32 (under Apache/2.0.x),
and was wondering if there was any interest in developing
them within the appropriate httpd/apr sources. At present
they can be
On Mon, Nov 29, 2004 at 07:33:35PM +0100, Andr? Malo wrote:
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
This is the offending code;
endp = ap_strrchr_c(arg, '');
if (endp == NULL) {
return unclosed_directive(cmd);
}
Aah! understood, thanks ;-)
So I'd
At 10:45 AM 11/29/2004, Justin Erenkrantz wrote:
--On Monday, November 29, 2004 10:48 AM +0100 Mladen Turk [EMAIL PROTECTED]
wrote:
Your patch breaks win32 build.
The reason is that the AP_DECLARE is __stdcall while
cmd_table is __cdecl.
Huh? I don't know Win32 at all, so this makes no sense.
--On Monday, November 29, 2004 10:41 AM -0800 Greg Stein [EMAIL PROTECTED]
wrote:
but we were not allowed to remove features. Removing the fp from the
API would have disabled this feature in mod_perl, among others.
I can't tell you how often I've been bitten personally by mod_perl trying to
--On Monday, November 29, 2004 6:52 PM +0100 Mladen Turk [EMAIL PROTECTED]
wrote:
Sorry its cmd_func not cmd_table.
AP_DECLARE(const char *) ap_set_listenbacklog(...)
evaluates to:
__declspec(dllexport) const char * __stdcall ap_set_listenbacklog(...)
Later on there is:
Justin Erenkrantz wrote:
--On Monday, November 29, 2004 10:41 AM -0800 Greg Stein
[EMAIL PROTECTED] wrote:
but we were not allowed to remove features. Removing the fp from the
API would have disabled this feature in mod_perl, among others.
I can't tell you how often I've been bitten
On Mon, Nov 29, 2004 at 01:54:18PM -0500, Geoffrey Young wrote:
Justin Erenkrantz wrote:
--On Monday, November 29, 2004 10:41 AM -0800 Greg Stein
[EMAIL PROTECTED] wrote:
but we were not allowed to remove features. Removing the fp from the
API would have disabled this feature in
William A. Rowe, Jr. wrote:
The reason this popped up is that the function was not
previously exported, therefore it was in the c convention
as a local function.
In the future, Mladen, please don't assume unix coders know
this distinction and please go ahead, fix things up as necessary.
Have no
but in that
respect, we are no different from any other module that wants to implement a
RAW_ARGS directive...
Hardly. RAW_ARGS takes a single line of text. No file pointer. That
line could come from anywhere.
yeah, ok. I _meant_ create your own Foo container, which I guess is the
typical
Greg Stein wrote:
On Mon, Nov 29, 2004 at 01:54:18PM -0500, Geoffrey Young wrote:
Justin Erenkrantz wrote:
--On Monday, November 29, 2004 10:41 AM -0800 Greg Stein
[EMAIL PROTECTED] wrote:
but we were not allowed to remove features. Removing the fp from the
API would have disabled this feature in
On Mon, Nov 29, 2004 at 02:11:26PM -0500, Geoffrey Young wrote:
...
but what's the alternative to reading directly from the file under the
current, file-based design?
The system could do a container *if* the contents followed the
standard mechanism for defining directives. IOW, the central
Greg Stein wrote:
Yes, we can change the API (that was allowed going from 1.3 to 2.0),
but we were not allowed to remove features. Removing the fp from the
API would have disabled this feature in mod_perl, among others.
When APR v1.0's first release candidate came out, there were loud calls
This is a desired change. In no way is it close to being a
showstopper. Further, I'm not even sure how to provide the feature and
(at the same time) keep the fp private. Some callback nonsense or
something with buffers. Blech...
I'd like to just toss the feature and be done with it :-)
But no...
Greg Stein wrote:
This is a desired change. In no way is it close to being a
showstopper. Further, I'm not even sure how to provide the feature and
(at the same time) keep the fp private. Some callback nonsense or
something with buffers. Blech...
I'd like to just toss the feature and be done with
Greg Stein wrote:
This is a desired change. In no way is it close to being a
showstopper.
+1, exactly my feelings.
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Is there some doc explaining the usage of signal handlers under different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache makes no effort to
* support modules
At 01:03 PM 11/29/2004, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
The reason this popped up is that the function was not
previously exported, therefore it was in the c convention
as a local function.
In the future, Mladen, please don't assume unix coders know
this distinction and please go
Geoffrey Young wrote:
sorry, but I'm not following. can you guys be specific (code wise) about
what is supposed to be forbidden? my only knowledge of mod_perl using that
file pointer is when implementing Foo containers where we (of course) need
to know what is between the opening and closing
I am trying to compile apache 2.1 to include the mod_proxy_ajp module. Here is
my configure line:
./configure --with-ssl=/home/markw/openssl --with-mpm=worker --enable-so
--enable-proxy-ajp --enable-ssl
Here is the compilation error:
/home/markw/code/apache21/httpd-trunk/srclib/apr/libtool
Forgot to say...
Fedora Core 3. gcc 3.4.2.
Also, since the initial posting, I tried:
./configure --prefix=/home/markw/apache
and got the same build error.
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Is there some doc explaining the usage of signal handlers under different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache makes no effort to
*
On Mon, 29 Nov 2004, Stas Bekman wrote:
./include/ap_mpm.h
unix/posix notes:
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
But the preferred method of handling timeouts is to use the
timeouts provided by the BUFF abstraction.
That's an ancient
Stas Bekman wrote:
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Is there some doc explaining the usage of signal handlers under
different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
./include/ap_mpm.h
unix/posix notes:
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
But the preferred method of handling timeouts is to use the
timeouts provided by the BUFF abstraction.
On Mon, 29 Nov 2004, Stas Bekman wrote:
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing. A mod_perl module that's
expected to work on any MPM (which is I'm assuming what you're talking
about)
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing.
Too much rope Cliff, too much rope. :-)
A mod_perl module that's
expected to work on
Bill Stoddard wrote:
Stas Bekman wrote:
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Is there some doc explaining the usage of signal handlers under
different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing.
What do you mean?
A mod_perl module that's
expected to work on any MPM (which is I'm
At 02:36 PM 11/29/2004, Mark wrote:
In file included from unixd.c:18:
/home/markw/code/apache21/httpd-trunk/include/httpd.h:913: error: syntax error
before ap_filter_t
/home/markw/code/apache21/httpd-trunk/include/httpd.h:913: warning: no
semicolon
at end of struct or union
This is a result of
On Mon, 29 Nov 2004 16:16:09 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Is there some doc explaining the usage of signal handlers under different
mpms?
No, although I would suggest the
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction-new(sub { die alarm }))
or die Error setting SIGALRM handler: $!\n;
alarm 2;
Jeff Trawick wrote:
[...]
As soon as the
new child takes over the process slot, the MPM forgets that the old
child existed. If the old child never exits on its own (long-running
or hung request), then when Apache is terminated the old child will
still hang around (parent pid - 1)
On Mon, 29 Nov 2004 18:41:36 -0500, Greg Ames [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
[...]
As soon as the
new child takes over the process slot, the MPM forgets that the old
child existed. If the old child never exits on its own (long-running
or hung request),
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction-new(sub { die alarm }))
or die
[bringing this over from docs@ for a dev@ ping]
Yoshiki Hayashi wrote:
I already stated my opinion so I don't reiterate myself
here. But I do object to the tone of argument from XSLT
camp. My work is just an evolution along the current web
site framework. The developers see no change in how
On Mon, Nov 29, 2004 at 02:56:39PM -0500, Stas Bekman wrote:
...
Not so fast Greg. You can't just cut an arm because *you* decided you
don't like it anymore. The feature was never called experimental and
wasn't scheduled to go away. Now there are multiple users who rely on this
feature,
Jeff Trawick wrote:
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction-new(sub { die alarm }))
or
--On Monday, November 29, 2004 6:33 PM -0700 Paul Querna
[EMAIL PROTECTED] wrote:
Do other developers have objections to moving the website to XSLT (like the
manual) instead of the current Velocity/Anakia?
I would recommend that any initial XSLT source transforms be kept as close to
the Anakia
* Justin Erenkrantz wrote:
--On Monday, November 29, 2004 6:33 PM -0700 Paul Querna
[EMAIL PROTECTED] wrote:
Do other developers have objections to moving the website to XSLT (like
the manual) instead of the current Velocity/Anakia?
I would recommend that any initial XSLT source
Greetings All.
With the recent upgrade of PCRE for Apache 2.1.x, I was curious if zLib
(required for mod_deflate) is mandated at 1.1.4 or could it also be
'updated' to the 1.2.1 release (available since Nov'03). A 2.1 build on
Windows for NetWare shows it glues together without issue; are
--On Tuesday, November 30, 2004 8:25 AM +0100 André Malo [EMAIL PROTECTED]
wrote:
Most developers are bad in writing documentation with either system. The
only thing the current system brought, were inconsistencies. Look at the
site. It's ugly, it's inconsistent, there are a lot of different
--On Tuesday, November 30, 2004 6:53 PM +1100 NormW [EMAIL PROTECTED]
wrote:
With the recent upgrade of PCRE for Apache 2.1.x, I was curious if zLib
(required for mod_deflate) is mandated at 1.1.4 or could it also be
'updated' to the 1.2.1 release (available since Nov'03). A 2.1 build on
Windows
77 matches
Mail list logo
