You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Guenter Knauf <fu...@apache.org> on 2013/04/20 02:01:37 UTC
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Daniel,
On 19.04.2013 16:31, humbedooh@apache.org wrote:
> Author: humbedooh
> Date: Fri Apr 19 14:31:51 2013
> New Revision: 1469852
>
> URL: http://svn.apache.org/r1469852
> Log:
> s/r:/r./
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
>
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_lua.xml?rev=1469852&r1=1469851&r2=1469852&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/docs/manual/mod/mod_lua.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Fri Apr 19 14:31:51 2013
> @@ -843,9 +843,9 @@ r:custom_response(404, "Baleted!")
> </highlight>
>
> <highlight language="lua">
> -r:exists_config_define(string) -- Checks whether a configuration definition exists or not:
> +r.exists_config_define(string) -- Checks whether a configuration definition exists or not:
>
> -if r:exists_config_define("FOO") then
> +if r.exists_config_define("FOO") then
> r:puts("httpd was probably run with -DFOO, or it was defined in the configuration")
> end
> </highlight>
that was only 1st half; r:strcmp_match() fix is missing ...
BTW. whats about r:started()?
Is this needed to be a function, or can we change that too into a var
like r.banner? Its still double listed:
as var in the request_rec block, and as function below 'Built in
functions' ...
Gün.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/25/2013 02:46 AM, Guenter Knauf wrote:
> On 24.04.2013 00:18, Guenter Knauf wrote:
>> and two more things:
>> 1) I found with my script that there is also a table apr_table created
>> with methods get and set but its not yet documented
>> 2) I wonder why we do export some functions from mod_lua, and what could
>> make use of these?
> Gregg kindly just tested without those exports, and it still works fine;
> so seems that Windows doesnt need them either ...
>
> another thing I came over:
> 3) it would be nice if we would do a changedir to the location of the
> calling script so that its easily possible to use other files in the
> same dir - I've not yet checked if that should happen, but at least on
> NetWare where I was testing it does not chdir to the script's dir ...
>
> Gün.
>
>
>
Reading these emails consecutively, so apologies if I reply to something
that others have answered ;)
Okay, I'll look at not exporting those things, I guess.
Yes, I agree that we should probably chdir to the directory we're
calling a script from. This would also make it easier to do fx:
io.open("./foo.txt") and have it open foo.txt in the calling directory.
I'll look into that :)
With regards,
Daniel.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Guenter Knauf <fu...@apache.org>.
On 24.04.2013 00:18, Guenter Knauf wrote:
> and two more things:
> 1) I found with my script that there is also a table apr_table created
> with methods get and set but its not yet documented
> 2) I wonder why we do export some functions from mod_lua, and what could
> make use of these?
Gregg kindly just tested without those exports, and it still works fine;
so seems that Windows doesnt need them either ...
another thing I came over:
3) it would be nice if we would do a changedir to the location of the
calling script so that its easily possible to use other files in the
same dir - I've not yet checked if that should happen, but at least on
NetWare where I was testing it does not chdir to the script's dir ...
Gün.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/25/2013 11:54 AM, Daniel Gruno wrote:
> On 04/24/2013 12:18 AM, Guenter Knauf wrote:
>> On 23.04.2013 23:49, Guenter Knauf wrote:
>>> Hi Daniel,
>>> On 20.04.2013 08:58, Daniel Gruno wrote:
>>>> Thanks for the invaluable help, it's really good knowing there's someone
>>>> else taking such an interest in this project! :) I hope that someday we
>>>> can shed mod_lua of its experimental status and people won't think me a
>>>> crazy person for recommending it left and right ;)
>>> naa, I find the module useful too for all sorts of smaller tasks as well
>>> as special httpd things which otherwise can only be done with a C module
>>> I believe ...
>>> now since I looked a bit at the code here and there I think there are
>>> some things which we should fix over the next months ...
>>>
>>> 1) the code formatting is not yet at our standard
>>> 2) the 'apache2' module does pollute the global table, and at 1st glance
>>> with my limited Lua experience I dont see why this happens; I've tested
>>> with other dynamically loaded modules like geoip, socket and apr (yeah,
>>> there exists a *very* *great* APR binding! [1]), and they all only
>>> create their own table and nothing global; it would be nice if we could
>>> either teach the apache2 module to behave same, or at least make it
>>> prelinked/preloaded and let it only plug in when enabled via 'require'.
>>> See attached script which shows what I mean ...
>>> 3) Since there exists a well done and well functioning APR binding we
>>> should probably consider to add some code to mod_lua so that its
>>> possible to prelink/preload this APR binding once at module start
>>> instead of loading it from every script again and again ...
>>> if we would agree on that we could even ditch a bunch of the recent APR
>>> adds, thus making mod_lua itself cleaner / smaller again + we would get
>>> almost the full power of APR into mod_lua ...
>>>
>>> Gün.
>>>
>>> [1] http://peterodding.com/code/lua/apr/
>>
>> and two more things:
>> 1) I found with my script that there is also a table apr_table created
>> with methods get and set but its not yet documented
>> 2) I wonder why we do export some functions from mod_lua, and what could
>> make use of these?
>> But then again this is only a Lua newbie question, and I dont know
>> enough about the load process of mod_lua specially on Windows with its
>> external dependency to the Lua DLL and how this exactly works, probably
>> these exports are needed for Windows?
>>
>> Gün.
>>
>>
>>
> Windows has a ton of crap requirements for mod_lua to work properly.
> Enough said :(
>
> I'll look into that apr_table thing, I can't remember what it does off
> the top of my head.
>
> With regards,
> Daniel.
>
Okay, it seems that the apr_table thing is some leftover from old code -
I'll see if I can safely remove the thing (lua_apr.c could probably be
removed entirely) and do so when I have the cycles.
With regards,
Daniel.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/24/2013 12:18 AM, Guenter Knauf wrote:
> On 23.04.2013 23:49, Guenter Knauf wrote:
>> Hi Daniel,
>> On 20.04.2013 08:58, Daniel Gruno wrote:
>>> Thanks for the invaluable help, it's really good knowing there's someone
>>> else taking such an interest in this project! :) I hope that someday we
>>> can shed mod_lua of its experimental status and people won't think me a
>>> crazy person for recommending it left and right ;)
>> naa, I find the module useful too for all sorts of smaller tasks as well
>> as special httpd things which otherwise can only be done with a C module
>> I believe ...
>> now since I looked a bit at the code here and there I think there are
>> some things which we should fix over the next months ...
>>
>> 1) the code formatting is not yet at our standard
>> 2) the 'apache2' module does pollute the global table, and at 1st glance
>> with my limited Lua experience I dont see why this happens; I've tested
>> with other dynamically loaded modules like geoip, socket and apr (yeah,
>> there exists a *very* *great* APR binding! [1]), and they all only
>> create their own table and nothing global; it would be nice if we could
>> either teach the apache2 module to behave same, or at least make it
>> prelinked/preloaded and let it only plug in when enabled via 'require'.
>> See attached script which shows what I mean ...
>> 3) Since there exists a well done and well functioning APR binding we
>> should probably consider to add some code to mod_lua so that its
>> possible to prelink/preload this APR binding once at module start
>> instead of loading it from every script again and again ...
>> if we would agree on that we could even ditch a bunch of the recent APR
>> adds, thus making mod_lua itself cleaner / smaller again + we would get
>> almost the full power of APR into mod_lua ...
>>
>> Gün.
>>
>> [1] http://peterodding.com/code/lua/apr/
>
> and two more things:
> 1) I found with my script that there is also a table apr_table created
> with methods get and set but its not yet documented
> 2) I wonder why we do export some functions from mod_lua, and what could
> make use of these?
> But then again this is only a Lua newbie question, and I dont know
> enough about the load process of mod_lua specially on Windows with its
> external dependency to the Lua DLL and how this exactly works, probably
> these exports are needed for Windows?
>
> Gün.
>
>
>
Windows has a ton of crap requirements for mod_lua to work properly.
Enough said :(
I'll look into that apr_table thing, I can't remember what it does off
the top of my head.
With regards,
Daniel.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Guenter Knauf <fu...@apache.org>.
On 23.04.2013 23:49, Guenter Knauf wrote:
> Hi Daniel,
> On 20.04.2013 08:58, Daniel Gruno wrote:
>> Thanks for the invaluable help, it's really good knowing there's someone
>> else taking such an interest in this project! :) I hope that someday we
>> can shed mod_lua of its experimental status and people won't think me a
>> crazy person for recommending it left and right ;)
> naa, I find the module useful too for all sorts of smaller tasks as well
> as special httpd things which otherwise can only be done with a C module
> I believe ...
> now since I looked a bit at the code here and there I think there are
> some things which we should fix over the next months ...
>
> 1) the code formatting is not yet at our standard
> 2) the 'apache2' module does pollute the global table, and at 1st glance
> with my limited Lua experience I dont see why this happens; I've tested
> with other dynamically loaded modules like geoip, socket and apr (yeah,
> there exists a *very* *great* APR binding! [1]), and they all only
> create their own table and nothing global; it would be nice if we could
> either teach the apache2 module to behave same, or at least make it
> prelinked/preloaded and let it only plug in when enabled via 'require'.
> See attached script which shows what I mean ...
> 3) Since there exists a well done and well functioning APR binding we
> should probably consider to add some code to mod_lua so that its
> possible to prelink/preload this APR binding once at module start
> instead of loading it from every script again and again ...
> if we would agree on that we could even ditch a bunch of the recent APR
> adds, thus making mod_lua itself cleaner / smaller again + we would get
> almost the full power of APR into mod_lua ...
>
> Gün.
>
> [1] http://peterodding.com/code/lua/apr/
and two more things:
1) I found with my script that there is also a table apr_table created
with methods get and set but its not yet documented
2) I wonder why we do export some functions from mod_lua, and what could
make use of these?
But then again this is only a Lua newbie question, and I dont know
enough about the load process of mod_lua specially on Windows with its
external dependency to the Lua DLL and how this exactly works, probably
these exports are needed for Windows?
Gün.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/23/2013 11:49 PM, Guenter Knauf wrote:
> Hi Daniel,
> On 20.04.2013 08:58, Daniel Gruno wrote:
>> Thanks for the invaluable help, it's really good knowing there's someone
>> else taking such an interest in this project! :) I hope that someday we
>> can shed mod_lua of its experimental status and people won't think me a
>> crazy person for recommending it left and right ;)
> naa, I find the module useful too for all sorts of smaller tasks as well
> as special httpd things which otherwise can only be done with a C module
> I believe ...
> now since I looked a bit at the code here and there I think there are
> some things which we should fix over the next months ...
>
> 1) the code formatting is not yet at our standard
> 2) the 'apache2' module does pollute the global table, and at 1st glance
> with my limited Lua experience I dont see why this happens; I've tested
> with other dynamically loaded modules like geoip, socket and apr (yeah,
> there exists a *very* *great* APR binding! [1]), and they all only
> create their own table and nothing global; it would be nice if we could
> either teach the apache2 module to behave same, or at least make it
> prelinked/preloaded and let it only plug in when enabled via 'require'.
> See attached script which shows what I mean ...
> 3) Since there exists a well done and well functioning APR binding we
> should probably consider to add some code to mod_lua so that its
> possible to prelink/preload this APR binding once at module start
> instead of loading it from every script again and again ...
> if we would agree on that we could even ditch a bunch of the recent APR
> adds, thus making mod_lua itself cleaner / smaller again + we would get
> almost the full power of APR into mod_lua ...
>
> Gün.
>
> [1] http://peterodding.com/code/lua/apr/
Firstly, You can already pre-load and keep libraries persistent by doing
a simple check: if not apr then apr = require "apr" end
Let's not reinvent the wheel ;)
Secondly, I think the APR bindings Peter made are great for standalone
applications, but not for mod_lua. The reason for this is that the APR
bindings allocate memory from a self-created global pool that is not
tied into the request_rec structure, and thus NOT freed when the request
is done, or when the VM is destroyed for that matter (it was like this
the last time I checked), so if you use it, you'll most likely end up
with a very large memory leak at some point, which is the reason why I
discourage people from using it for mod_lua. It might be that it's
changed from the last time I checked the source code, and if so, do
correct me :)
Thirdly, this would require users to download, compile and install the
module (some may not even trust a third party provider), which goes
against what I've been trying to achive; That users can pick up mod_lua,
use it, and not have to worry about basic functionality missing. People
want basic file handling, database access and some string manipulations
from the get go, and don't wanna worry about having to install
additional third party ibraries in order to make it work. I appreciate
your thought on making mod_lua leaner, but I respectfully disagree that
we should cut out these functions from it. I also have my own APR
library called lua_apr, but I don't use it, as it doesn't tie into the
memory pool that we use. As to performance, the addition of these
functions into the request_rec structure has no significant impact on
that. If you use a per-thread VM (which I recommend), the memory and cpu
overhead is to tiny, it won't even register in a stress test.
If you can point to anywhere that needs a formatting change, please do
so, and I'll see to it that it's properly formatted. I did a major
overhaul of my own contributions a while back, but there may still be
some old code that needs changing ;)
Yes, the apache2 table 'pollutes' the global table, but that has its
advantages, and it's really not a big deal in my view. IF we want it to
be leaner, we could tuck it into the request_rec object, so it'd be fx:
function handle(r)
do_stuff()
return r.OK
end
With regards,
Daniel.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Guenter Knauf <fu...@apache.org>.
Hi Daniel,
On 20.04.2013 08:58, Daniel Gruno wrote:
> Thanks for the invaluable help, it's really good knowing there's someone
> else taking such an interest in this project! :) I hope that someday we
> can shed mod_lua of its experimental status and people won't think me a
> crazy person for recommending it left and right ;)
naa, I find the module useful too for all sorts of smaller tasks as well
as special httpd things which otherwise can only be done with a C module
I believe ...
now since I looked a bit at the code here and there I think there are
some things which we should fix over the next months ...
1) the code formatting is not yet at our standard
2) the 'apache2' module does pollute the global table, and at 1st glance
with my limited Lua experience I dont see why this happens; I've tested
with other dynamically loaded modules like geoip, socket and apr (yeah,
there exists a *very* *great* APR binding! [1]), and they all only
create their own table and nothing global; it would be nice if we could
either teach the apache2 module to behave same, or at least make it
prelinked/preloaded and let it only plug in when enabled via 'require'.
See attached script which shows what I mean ...
3) Since there exists a well done and well functioning APR binding we
should probably consider to add some code to mod_lua so that its
possible to prelink/preload this APR binding once at module start
instead of loading it from every script again and again ...
if we would agree on that we could even ditch a bunch of the recent APR
adds, thus making mod_lua itself cleaner / smaller again + we would get
almost the full power of APR into mod_lua ...
Gün.
[1] http://peterodding.com/code/lua/apr/
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/20/2013 02:01 AM, Guenter Knauf wrote:
> Daniel,
> On 19.04.2013 16:31, humbedooh@apache.org wrote:
>> Author: humbedooh
>> Date: Fri Apr 19 14:31:51 2013
>> New Revision: 1469852
>>
>> URL: http://svn.apache.org/r1469852
>> Log:
>> s/r:/r./
>>
>> Modified:
>> httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
>>
>> Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_lua.xml?rev=1469852&r1=1469851&r2=1469852&view=diff
>>
>> ==============================================================================
>>
>> --- httpd/httpd/trunk/docs/manual/mod/mod_lua.xml (original)
>> +++ httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Fri Apr 19 14:31:51
>> 2013
>> @@ -843,9 +843,9 @@ r:custom_response(404, "Baleted!")
>> </highlight>
>>
>> <highlight language="lua">
>> -r:exists_config_define(string) -- Checks whether a configuration
>> definition exists or not:
>> +r.exists_config_define(string) -- Checks whether a configuration
>> definition exists or not:
>>
>> -if r:exists_config_define("FOO") then
>> +if r.exists_config_define("FOO") then
>> r:puts("httpd was probably run with -DFOO, or it was defined in
>> the configuration")
>> end
>> </highlight>
> that was only 1st half; r:strcmp_match() fix is missing ...
> BTW. whats about r:started()?
> Is this needed to be a function, or can we change that too into a var
> like r.banner? Its still double listed:
> as var in the request_rec block, and as function below 'Built in
> functions' ...
>
> Gün.
>
>
>
I'll get on that asap :)
Thanks for the invaluable help, it's really good knowing there's someone
else taking such an interest in this project! :) I hope that someday we
can shed mod_lua of its experimental status and people won't think me a
crazy person for recommending it left and right ;)
With regards,
Daniel.