Jacques Chester | 1 Oct 2009 01:11
Picon
Gravatar

HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)


On 30/09/2009, at 12:28 AM, Petite Abeille wrote:

> And nginx is even faster, simpler, leaner, meaner than lighttpd :)

So the cool Ruby kids say! Personally Lighty has been a
winner for the sites I manage. I also like that you can
embed Lua scripts in the server.

> I do realize that this argument is going against nearly 15 years of  
> Common Gateway Interface indoctrination :D

I've argued similar things before in other forums (that
apps in future might embed their own HTTP handling). But
I didn't see it being a case of using a pure Lua, pure
Ruby, pure Python etc solution. Rather I expected folk
would settle on some fast, easily wrapped C library.
One that looks nice is Libebb[1].

But as I pointed out, (F|S)CGI isn't a performance tool.
Its purpose is to abstract the web server away from the
application. For a lot of people, that matters.

I am happy in this case to agree to (partly) disagree.

Cheers,

JC.

[1] http://tinyclouds.org/libebb/
(Continue reading)

Picon

Re: HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)

> Rather I expected folk would settle on some fast, easily wrapped C library.
> One that looks nice is Libebb[1].

See http://lists.luaforge.net/pipermail/kepler-project/2008-October/003004.html

David Given | 1 Oct 2009 01:47

Re: Lua for large apps

Alexander Gladysh wrote:
[...]
> At first it was quite hard to write code in Lua — without compile time
> validation, without static types, it felt as if I try to stand on a
> blob of wobbly jelly instead of a good solid rock.

I like dynamic languages. I also like static languages. They're good at 
different things --- some problems that are hard in static languages are 
very easy in dynamic languages, while some problems that are hard in 
dynamic languages are very easy in static languages.

So I was fascinated to discover this recently:

http://www.strongtalk.org/

It's a Smalltalk with optional strong typing.

What this means is that if you want it to behave like a dynamic language 
with duck typing ('if it quacks like a duck, let's just assume it is 
one'), you can --- and if you want strong typing ('only DNA checked 
ducks are allowed in the bulding') you can.

You can write code like:

| o |
    o := self getSomeObjectOfUnknownType.
    o callMethodOnObject

...and it will work, regardless of what class o is. OTOH, if you know in 
advance that o is going to conform to a particular interface, you can say:
(Continue reading)

steve donovan | 1 Oct 2009 08:13
Picon

Re: GSL Shell software announcement

>> On Wed, Sep 30, 2009 at 10:48 AM, Francesco Abbate
> Talking about the graphical interface to plot function, yes it
> is definitely the missing feature. I'm planning to implement it but I'm
> lacking cruelly of time. My hope is that by publishing GSL shell in the web
> someone will be motivated to help me in this project.

It does not have to be complicated, nor does it require a full GUI
shell.  For instance, here's a pure Lua wrapper for GnuPlot:

http://luaforge.net/projects/gnuplot/

(I believe there are others, with various levels of abstraction)

So the point is that you would hardly have to write any code, and
definitely won't have to write any C !

'lacking cruelly of time'  is unfortunately so true for all of us!

steve d.

Jorge | 1 Oct 2009 18:09
Picon

Re: Tracking number of pairs in a dictionary

On Wed, 2009-09-30 at 23:34 +0200, Michal Kolodziejczyk wrote:
> Or you could keep a counter within the table (so you will not iterate
> the table at all). Here is an example implementation (you can overide
> removeOne() to what you need):
> 
> MT={
>   add=function(self, key, value)

Wow... Never seen metatables used like that. Had to look it twice to get
why it works :)

Is there a way for keeping _n and _limit out of the table? With some
upvalue magic or something? Otherwise you have to explicitly skip them
while iterating (as the RemoveOne as is does not :) )

Jorge

Fabio Mascarenhas | 1 Oct 2009 18:22
Picon
Favicon
Gravatar

Re: HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)

On Wed, Sep 30, 2009 at 8:11 PM, Jacques Chester <jacques <at> chester.id.au> wrote:
> I've argued similar things before in other forums (that
> apps in future might embed their own HTTP handling). But
> I didn't see it being a case of using a pure Lua, pure
> Ruby, pure Python etc solution. Rather I expected folk
> would settle on some fast, easily wrapped C library.
> One that looks nice is Libebb[1].

Libevent, used in memcached, also provides an HTTP library that looks
pretty easy to bind to Lua. But for both libevent and libebb you also
have to put some kind of load balancer in front to distribute the
requests among your cores, as these event-based HTTP libraries are
single-threaded.

Lighty+FCGI is fast enough in practice, though. There was a thread at
the Kepler list a few months ago with benchmarks (startup times only)
of Lighty+FCGI+WSAPI vs Lighty+FCGI+PHP:

http://lists.luaforge.net/pipermail/kepler-project/2009-June/003412.html

--
Fabio Mascarenhas, Lablua
http://www.lua.inf.puc-rio.br

Petite Abeille | 1 Oct 2009 18:27
Picon

Re: HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)


On Oct 1, 2009, at 1:11 AM, Jacques Chester wrote:

>> I do realize that this argument is going against nearly 15 years of  
>> Common Gateway Interface indoctrination :D
>
> I've argued similar things before in other forums (that
> apps in future might embed their own HTTP handling). But
> I didn't see it being a case of using a pure Lua, pure
> Ruby, pure Python etc solution.

HTTP handling is not very resource consuming. It's what you do with it  
which takes time. Irrespectively of implementation details.

> Rather I expected folk
> would settle on some fast, easily wrapped C library.
> One that looks nice is Libebb[1].

I would settle on a simple, battle proof library for MIME handling.  
Not very interested in a full stack network run loop though.

> But as I pointed out, (F|S)CGI isn't a performance tool.
> Its purpose is to abstract the web server away from the
> application. For a lot of people, that matters.

More power to them!

> I am happy in this case to agree to (partly) disagree.

Hmmm... right... ok :))
(Continue reading)

Jacques Chester | 1 Oct 2009 18:50
Picon
Gravatar

Re: HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)


On 02/10/2009, at 12:22 AM, Fabio Mascarenhas wrote:
> Lighty+FCGI is fast enough in practice, though. There was a thread at
> the Kepler list a few months ago with benchmarks (startup times only)
> of Lighty+FCGI+WSAPI vs Lighty+FCGI+PHP:
>
> http://lists.luaforge.net/pipermail/kepler-project/2009-June/003412.html

Hmmm, those look familiar ;)

Cheers,

JC.

Duncan Cross | 1 Oct 2009 19:01
Picon

Re: Tracking number of pairs in a dictionary

On Thu, Oct 1, 2009 at 5:09 PM, Jorge <xxopxe <at> gmail.com> wrote:
> On Wed, 2009-09-30 at 23:34 +0200, Michal Kolodziejczyk wrote:
>> Or you could keep a counter within the table (so you will not iterate
>> the table at all). Here is an example implementation (you can overide
>> removeOne() to what you need):
>>
>> MT={
>>   add=function(self, key, value)
>
> Wow... Never seen metatables used like that. Had to look it twice to get
> why it works :)
>
> Is there a way for keeping _n and _limit out of the table? With some
> upvalue magic or something? Otherwise you have to explicitly skip them
> while iterating (as the RemoveOne as is does not :) )
>
> Jorge
>
>

You could try using weak-valued tables to store the values of _n and
_limit instead of fields.
Modified version of Miko's code follows:

local _ns = setmetatable({}, {__mode = 'k'})
local _limits = setmetatable({}, {__mode = 'k'})

MT={
 add=function(self, key, value)
   if not rawget(self, key) then
(Continue reading)

Petite Abeille | 1 Oct 2009 19:09
Picon

Re: HTTP app architecture (was Re: What would _you_ like in a Lua CMS?)


On Oct 1, 2009, at 6:50 PM, Jacques Chester wrote:

> Hmmm, those look familiar ;)

How are the exams coming along? :D


Gmane