>>> I don't plan to add much more then header io, puts/gets/parse and the >>> misc >>> housekeeping related stuff (flush/watchdog/exit).
>> I must be missing something here, but why do you need a separate >> parser? What's wrong with gmatch or LPeg? >> Is this because of string interning? > Nothing is wrong with custom Lua solutions. > I encourage them and use them > myself. I have my own Lua x-www-form-urlencoded string parser, along with a > small bag'o'tricks that I require() in many web scripts. Well, that is your decision, of course, but, if I were you, unless I'd have a good performance reasons, I'd avoid reinventing the wheel here. It may harm Lua users adoption. > I just wanted to include few basic "batteries" to help when writing quick and > dirty scripts > or for those moving over from PHP. Why not include them right into your distribution then? Like Lua for Windows does? > The built-in parser is only intended for > HTML spec form processing (like those posted from a web browser). But it > does make sample scripts beautifully simple to help entice more victims into > the Lua webapp world. Can't the same be done with, say LPeg, and pre-packaged with your scripts? You may even do require() for the user by default. > As for string interning, the parser is written for pure speed with a nod > toward safety (only valid hex % encodes, all others ignored - etc.). Since > it makes a local temp copy of the string, it isn't really any more or less > memory efficient then using a Lua parser. If the parser has the same cost as Lua, then why is it here? > On a side note and to throughly beat a dead horse; persistent states mean > that require() only hits the disk and compiler once for the lifetime of the > state, which amortizes any overhead of using multiple Lua modules across > thousands of requests (or more). And I use lots of C/Lua modules personally. > I mean LOTS. A couple dozen at times. Hence the obsession with tightly > managed persistent Lua states. Not sure I quite follow you here, sorry. You say that you do not afraid the cost of modules, but instead of using existing modules, you prefer to write your own. Right? >>> A remote telnet debugger >>> interface ala gdb might be nice, but that is currently on the >>> far-off-fairyland part of the schedule. >> You mean remdebug-like functionality? > Yup, just without the dependencies. I was planning on simply doing a C port > of remdebug if possible. In pure C, without any external modules, "simple" > being a tremendous understatement of course. Hence the far-off-fairyland > scheduling. Why? > In the meantime (which could be forever), I would highly recommend people > using remdebug with luafcgid. I myself have a bad case of "not invented here" syndrome. But when one writes a public project, especially one that is undermanned, it is important to be focused on the main goal. You just can't rewrite everything out there. * * * I'm sorry for the rant above. Again, this is your project and your way to do things. I hope I did not hurt your feelings or your motivation. Alexander. _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
