Stas Bekman wrote:
modperl/t/hooks/trans.t - does module2path, config, then hostport. No
module, but does custom urls towards the end.
You mean t/hooks/trans.t?
sure it does:
Apache::TestRequest::module($module);
or are you talking about a different test?
ANd so it does. On that note, I'm going t
Christopher H. Laco wrote:
Understood. What led me to contimplating those thoughts was the fact
that some tests use hostport, and config, and a custom path, but just
don't set A::TR::module. If it weren't for that, those test could be
slimmed as well.
That's when they use the default port. But
Understood. What led me to contimplating those thoughts was the fact
that some tests use hostport, and config, and a custom path, but just
don't set A::TR::module. If it weren't for that, those test could be
slimmed as well.
That's when they use the default port. But that doesn't sound right,
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this.
I'm going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl,
Stas Bekman wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this.
I'm going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
sepera
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists,
Christopher H. Laco wrote:
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one l
Christopher H. Laco wrote:
Stas Bekman wrote:
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
if they include modperl and a-t send them to the modperl dev list. if
only a-t post them here. thanks :)
Anothe
Christopher H. Laco wrote:
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one l
Christopher H. Laco wrote:
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
-=Chris
Stas Bekman wrote:
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
if they include modperl and a-t send them to the modperl dev list. if
only a-t post them here. thanks :)
Another opinion question amungst
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
if they include modperl and a-t send them to the modperl dev list. if only
a-t post them here. thanks :)
--
___
Christopher H. Laco wrote:
Christopher H. Laco wrote:
> On that note, what else can I work on?
> Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Stas Bekman wrote:
Still someone needs to do the work and verify that things are working.
That will fun in and of itself. Right now, the only thing close to
meeting the requirements of running the overall tests is my 5.6.1
install on my XP la
Christopher H. Laco wrote:
Stas Bekman wrote:
Still someone needs to do the work and verify that things are working.
That will fun in and of itself. Right now, the only thing close to
meeting the requirements of running the overall tests is my 5.6.1
install on my XP lappy. Both of my FreeBSD box
Christopher H. Laco wrote:
Stas Bekman wrote:
> Of course it should take the necessary precautions for when / is and
> isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apach
Stas Bekman wrote:
> Of course it should take the necessary precautions for when / is and
> isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apache::TestRequest::module($mod
Christopher H. Laco wrote:
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted
to do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apache::TestRequest::m
Of of course, I meant t/modperl/merge.t and module2url
Got perl on the brain.
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apache::TestRequest::module($module);
my $co
Stas Bekman wrote:
Still someone needs to do the work and verify that things are working.
That will fun in and of itself. Right now, the only thing close to
meeting the requirements of running the overall tests is my 5.6.1
install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03.
It'l
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing
Stas Bekman wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to
Stas Bekman wrote:
No, no, the root of A-T. An example will be more useful:
--- lib/Apache/Test.pm(revision 109410)
+++ lib/Apache/Test.pm(working copy)
I can chdir into the root of the project and apply your patch immediately.
Understood. Makes sense.
Agreed, but dups are evil from the mai
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional
headers via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* exampl
Stas Bekman wrote:
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; whic
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \&
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \& and &. The bare versions s
29 matches
Mail list logo
