What I was meaning is: there is no bug until tests confirm it. By
"tests" I really mean a provable test case (you know, as in "make
test"). Without that, with all your approximations (versions, modules,
environment, etc), we're just piling up a "story" :(
OK, I understand better. No official bug declared, which doesn't necessarily
means there are no bug at all.
It's just about using far slower methods (CGI.pm's) rather than those
provided by apreq library/modules. For proper documentation, check:
http://www.masonhq.com/docs/manual/Params.html#args_method
Of course, I saw that doc, and that's thanks to it that I deducted that the
problem was coming from there. Now, I have to confess these explanations are
not enough for me to understand what's going on behinnd the scenes.
Concerning the speed penalty itself, when using "CGI" instead of "mod_perl"
for request args, even if the request processing part is really slower,
because dealt by CGI, the overall application, which is heavily relying on
some dbs, shouldn't suffer much. I suppose that args processing is perhaps
1% of the total time needed, so that should be OK. But of course, I'd far
prefer to use the fastest method avaiable for my arguments., and understand
why this "bug".
No! If you feel better with win32, and have the time and will to help
building a reliable win32 “LAMP” platform, then keep on using it and
please report as many bugs as you may find. :)
Your only problem until now was this inexact enumeration of your
environment.
In fact, even installing all that under Win32 has been a problem. I couldn't
install things manually, because all explaantions I found over the internet
were either out of date, either concerning Linux. So, I found an All in One
installation package containing Apache, Mod_perl, DBI and Mason, and I used
this one (I think I found it somewhere on the winnipeg.ca website, probably
http://theory.uwinnipeg.ca/modperl/download/binaries.html )
At that time, the purpose for me was just installing and trying Mason, and I
was really new to Web Servers. Time to time, I had to add libbraries to the
Perl tree on my hard drive. I think I should start again from scratch and
try to install all this stuff manually (ie download latests version, and
understand what I'm installing, and what components are used).
I globally really feel, hen reading books or even forums that 95% of people
running Apache/mod_perl/Mason are using Linux, and I really feel alone with
my Win32 version. I think the Win32 port has been created just to increase
the number of potential users, but the native OS for all that seems to be
Linux.
Ahaha, some days ago, I read some docs on perl.org about locales, etc... (at
perl.org) and even there, I could really feel that the guy was implicitly
talking about Linux. Things were not working on my computer, and I finally
understood that this was because I was using Windows, and here, locale names
are different. In fact, globally, I feel that, because I'm using Windows, I
have to struggle twice as much to get expected results.
With this thing fixed, then we should move on to really try debugging
that problem of yours, as long as you succeed creating a provable test
case. I'm sure there are some more folks on this list wishing to help,
but without that test case... you're all alone :(
OK. Anyway, I know I'm quite alone here, and even if I could tell exactly
which module versions I am using, there would be no one being able to test
on a similar platform.
If I'm getting experienced enough with that, I'll try to create some test
case, to help future people facing the same kind of problems in the future.
Thanks for your help,
Lionel.
----- Original Message -----
From: "Marius Feraru" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 14, 2006 3:22 PM
Subject: Re: [Mason] When and where, in the Mason source code, is the
$r->args hash generated (Purpose: fix a problem with request args
disappearing)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lionel MARTIN wrote:
There is not bug.
Perhaps not a bug, but the behaviour with request_args => "mod_perl" is
really weird:
http://myserver/test.html?myarg=%E7 => not working
http://myserver/test.html?myarg=%E7%E7 => working
Just changing "mod_perl" into "CGI" makes it perfectly work. Am I
missing something?
Sorry, I rushed without completely answering :(
What I was meaning is: there is no bug until tests confirm it. By
"tests" I really mean a provable test case (you know, as in "make
test"). Without that, with all your approximations (versions, modules,
environment, etc), we're just piling up a "story" :(
I basically know what's the difference between mod_perl (ie precompiled
components) and CGI (ie components run as scripts)
Lost the context: we were talking about args_method (a.k.a. the “Method
to use for unpacking GET and POST arguments”). So, in that context
(still running under mod_perl vXXX):
But here, when specifying args_method => "CGI", I suppose that my
components are still precompiled, aren't they?
Yes, they are.
I don't exactly know what args_method => "CGI" implies?
It's just about using far slower methods (CGI.pm's) rather than those
provided by apreq library/modules. For proper documentation, check:
http://www.masonhq.com/docs/manual/Params.html#args_method
I really feel that I should better move to Linux in a near future, as
really few people seem to be using Win32 for Apache/mod_perl/mason.
No! If you feel better with win32, and have the time and will to help
building a reliable win32 “LAMP” platform, then keep on using it and
please report as many bugs as you may find. :)
Your only problem until now was this inexact enumeration of your
environment.
With this thing fixed, then we should move on to really try debugging
that problem of yours, as long as you succeed creating a provable test
case. I'm sure there are some more folks on this list wishing to help,
but without that test case... you're all alone :(
(And yes, I failed reproducing your problem on Linux/FreeBSD, POSIX/UTF8
locale, perl 5.8.8, apache 1.3.34, html-mason 1.32, libapreq 1.31).
- --
Marius Feraru
-----BEGIN PGP SIGNATURE-----
iD8DBQFEFtGxtZHp/AYZiNkRAnJyAJoC8k20ih1DsdstkSeFRIucrL9YsQCbBYhz
YOxvanheAQNOhJ5WA8wlWaE=
=jqzM
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
