On 04/19/2013 06:25 PM, Guenter Knauf wrote:
> Daniel,
> On 19.04.2013 18:19, Guenter Knauf wrote:
>> On 19.04.2013 16:29, Daniel Gruno wrote:
>>> See r1469844
>> yeah, thought as much when I printed the result which showed 0 or 1;
>> but I had to leave so couldnt self dig into the code ATM ...
> w
Daniel,
On 19.04.2013 18:19, Guenter Knauf wrote:
On 19.04.2013 16:29, Daniel Gruno wrote:
See r1469844
yeah, thought as much when I printed the result which showed 0 or 1;
but I had to leave so couldnt self dig into the code ATM ...
wouldnt it be even more uselful to have instead a
r.get_conf
Hi Daniel,
On 19.04.2013 16:29, Daniel Gruno wrote:
See r1469844
yeah, thought as much when I printed the result which showed 0 or 1;
but I had to leave so couldnt self dig into the code ATM ...
Gün.
On 04/19/2013 04:01 PM, Guenter Knauf wrote:
> Hi Daniel,
> On 19.04.2013 14:53, Daniel Gruno wrote:
>> Yeah, that should be r.exists_config_define.
> ok, new test:
>
> function call_exists_config_define(r, text)
> if r.exists_config_define(text) then
> r:puts("httpd was probably run with -D
Hi Daniel,
On 19.04.2013 14:53, Daniel Gruno wrote:
Yeah, that should be r.exists_config_define.
ok, new test:
function call_exists_config_define(r, text)
if r.exists_config_define(text) then
r:puts("httpd was probably run with -D" .. text .. ", or it was
defined in the configuration.\n"
On 19.04.2013 14:53, Daniel Gruno wrote:
Do you want me to just fix the docs, or should we turn it into
r:exists_config_define for the sake of consistency?
ok, the other one was r.module_info(module_name);
so for now since we dont have yet consistency I'd say fix the docs ;-)
But would be great
On 04/19/2013 03:02 PM, Guenter Knauf wrote:
> On 10.04.2013 23:21, Guenter Knauf wrote:
>> On 10.04.2013 23:01, fua...@apache.org wrote:
>>> Author: fuankg
>>> Date: Wed Apr 10 21:01:51 2013
>>> New Revision: 149
>>>
>>> URL: http://svn.apache.org/r149
>>> Log:
>>> Put this backport for no
On 10.04.2013 23:21, Guenter Knauf wrote:
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, onward with some mo
On 04/19/2013 02:48 PM, Guenter Knauf wrote:
> On 10.04.2013 23:21, Guenter Knauf wrote:
>> On 10.04.2013 23:01, fua...@apache.org wrote:
>>> Author: fuankg
>>> Date: Wed Apr 10 21:01:51 2013
>>> New Revision: 149
>>>
>>> URL: http://svn.apache.org/r149
>>> Log:
>>> Put this backport for no
On 10.04.2013 23:21, Guenter Knauf wrote:
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, onward with some mo
On 14.04.2013 08:35, Guenter Knauf wrote:
On 14.04.2013 07:28, Daniel Gruno wrote:
ah yes, I made a rookie mistake there ;)
I'll fix up the docs accordingly.
thanks; while on that can you perhaps also mention the default of 25
regex matches, and my change for optional flags?
matches, err = r:re
On 14.04.2013 07:28, Daniel Gruno wrote:
ah yes, I made a rookie mistake there ;)
I'll fix up the docs accordingly.
thanks; while on that can you perhaps also mention the default of 25
regex matches, and my change for optional flags?
matches, err = r:regex(string, pattern [,flags])
where flags
On 04/14/2013 07:17 AM, Guenter Knauf wrote:
> HI Daniel,
> On 13.04.2013 08:47, Daniel Gruno wrote:
>> I think the reason for limiting it to 10 is legacy stuff, so that's what
>> I've complied with.
> but thats way to less for doing something useful; therefore I've
> decoupled mod_lua from AP_MAX_
HI Daniel,
On 13.04.2013 08:47, Daniel Gruno wrote:
I think the reason for limiting it to 10 is legacy stuff, so that's what
I've complied with.
but thats way to less for doing something useful; therefore I've
decoupled mod_lua from AP_MAX_REG_MATCH, added an own macro
MODLUA_MAX_REG_MATCH, mad
On 04/12/2013 10:01 PM, Gregg Smith wrote:
> On 4/12/2013 10:43 AM, Guenter Knauf wrote:
>> I know; but I dont know if Gregg did a release or debug build;
>> I've heard a couple of times in the past that folks were not able to
>> re-create crash with debug builds but which happen with release build
On 04/12/2013 10:42 PM, Guenter Knauf wrote:
> On 10.04.2013 23:21, Guenter Knauf wrote:
>> On 10.04.2013 23:01, fua...@apache.org wrote:
>>> Author: fuankg
>>> Date: Wed Apr 10 21:01:51 2013
>>> New Revision: 149
>>>
>>> URL: http://svn.apache.org/r149
>>> Log:
>>> Put this backport for no
On 10.04.2013 23:21, Guenter Knauf wrote:
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, onward with some mo
On 4/12/2013 10:43 AM, Guenter Knauf wrote:
I know; but I dont know if Gregg did a release or debug build;
I've heard a couple of times in the past that folks were not able to
re-create crash with debug builds but which happen with release builds;
that could f.e. explain why Daniel doesnt see th
On 11.04.2013 12:25, Guenter Knauf wrote:
well, another possible fix would be this one:
Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c(revision 1466743)
+++ modules/lua/lua_request.c(working copy)
@@ -120
On 4/12/2013 10:43 AM, Guenter Knauf wrote:
Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
On 11.04.2013 15:06, Daniel Gruno wrote:
On 04/11/2013 02:36 PM, Guenter Knauf wrote:
oh, and some more questions:
whats the benefit of having banner(), port() and started() as functions
(or methods)?
isnt it fine accessing these like f.e. r.filename?
r:put(r.banner) would be even shorter than r
Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
NetWare crashes the Windows httpd ...
Back
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
> I've now tested on Windows, and I can see all previously mentioned
> issues there too; in addition the attached script which works fine on
> NetWare crashes the Windows httpd ...
Backtrace, please?
A strange idea, but did you happen to
On 04/11/2013 11:24 PM, Gregg Smith wrote:
> On 4/11/2013 9:05 AM, Daniel Gruno wrote:
>> I just tried the script you attached on my Windows box, as well as the
>> original LuaRoot + LuaMapHandler problem, and I can't find anything
>> wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua fr
Hi Daniel,
On 11.04.2013 18:05, Daniel Gruno wrote:
I just tried the script you attached on my Windows box, as well as the
original LuaRoot + LuaMapHandler problem, and I can't find anything
wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
(using Lua 5.1.4). There appears
On 4/11/2013 9:05 AM, Daniel Gruno wrote:
I just tried the script you attached on my Windows box, as well as the
original LuaRoot + LuaMapHandler problem, and I can't find anything
wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
(using Lua 5.1.4). There appears to be noth
On 04/11/2013 01:55 AM, Guenter Knauf wrote:
> On 10.04.2013 23:34, Guenter Knauf wrote:
>>> but here's what I found so far:
>>> - banner(), port() and started() are functions (or methods), and listed
>>> as such below 'Built in functions'; but they are also listed as members
>>> of request_rec (se
On 04/11/2013 02:36 PM, Guenter Knauf wrote:
> On 11.04.2013 12:44, Daniel Gruno wrote:
>> it's a userdata object, so you can't iterate over the key/value pairs,
>> you can only access the values directly if you know the key.
> I was hoping that its possible to create a table from the userdata with
On 11.04.2013 12:44, Daniel Gruno wrote:
it's a userdata object, so you can't iterate over the key/value pairs,
you can only access the values directly if you know the key.
I was hoping that its possible to create a table from the userdata with
some Lua magic, and then iterate over the table ...
On 04/11/2013 12:33 PM, Guenter Knauf wrote:
> On 11.04.2013 12:05, Daniel Gruno wrote:
>> As for the env variables, I had at one point thought about making a
>> binding for that, but possibly the already existing env table and
>> os.getenv will be enough - I'll investigate that.
> as I said I'm a
On 11.04.2013 12:05, Daniel Gruno wrote:
As for the env variables, I had at one point thought about making a
binding for that, but possibly the already existing env table and
os.getenv will be enough - I'll investigate that.
as I said I'm a Lua newbie - can you perhaps give me an example how I
c
On 11.04.2013 12:10, Daniel Gruno wrote:
On 04/10/2013 11:21 PM, Guenter Knauf wrote:
- r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me
This function does work perfectly, on Linux/FreeBSD at least ;)
it uses ap_expr, so whatever that function supports, this should as
wel
Daniel,
On 11.04.2013 12:05, Daniel Gruno wrote:
Thanks for fixing the stat function
well, another possible fix would be this one:
Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c (revision 1466743)
+++ modules/
On 04/10/2013 11:21 PM, Guenter Knauf wrote:
>
> - r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me
This function does work perfectly, on Linux/FreeBSD at least ;)
it uses ap_expr, so whatever that function supports, this should as
well. What I tried on www.humbedooh.com was:
On 04/10/2013 11:21 PM, Guenter Knauf wrote:
> On 10.04.2013 23:01, fua...@apache.org wrote:
>> Author: fuankg
>> Date: Wed Apr 10 21:01:51 2013
>> New Revision: 149
>>
>> URL: http://svn.apache.org/r149
>> Log:
>> Put this backport for now on hold to get some more
>> time for testing ...
>
On 10.04.2013 23:34, Guenter Knauf wrote:
one more issue I saw:
- r.module_info() returns directives where the closing tag is missing,
f.e.:
ok, this one sorted out - looked at the code, and its because the
directives available from command_rec come without closing tag; I was
expecting same ou
On 10.04.2013 23:34, Guenter Knauf wrote:
but here's what I found so far:
- banner(), port() and started() are functions (or methods), and listed
as such below 'Built in functions'; but they are also listed as members
of request_rec (see the big table); in addition started() gives
certainly not s
On 10.04.2013 23:21, Guenter Knauf wrote:
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, sorry for this - I'm
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, sorry for this - I'm all for the backport, but since I found fe
39 matches
Mail list logo
