Re: [LuaCheia] Let it begin.

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] Let it begin.

D Burgess
How about FastCGI support ?




Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] Let it begin.

Martin Spernau
D Burgess wrote:
How about FastCGI support ?

Well, the Aranha project is a FastCGI module based on Lua, maybe we could ask those folks?


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] Let it begin.

Daniel Silverstone
On Tue, Feb 11, 2003 at 10:53:07AM +0100, Martin Spernau wrote:
> >How about FastCGI support ?
> Well, the Aranha project is a FastCGI module based on Lua, maybe we 
> could ask those folks?

The FastCGI support in Aranha is written specifically with web-apps in
mind, and particularly with Aranha's diverted printing in mind. It's not
integrated into the io layer in the least.

You're welcome to crib ideas from it, but I don't recommend it as an
example of a stand-alone FastCGI library (because it isn't one)

D.

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
You will be Told about it Tomorrow.  Go Home and Prepare Thyself.

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] binding libs / dyn loading

Martin Spernau
In reply to this post by Martin Spernau
As to what binding/loading achitecture to use, GluaX ahs one great benefit:
a _binary_ module build for a GluaX host can be loaded with Lua4 AND Lua5 without any changes (binary after all). I think that would be a great benefit.
And it doesn't hinder using other binding techiques like tolua etc.

A drawback of GluaX is that the binding needs to be made completly for GluaX, so there would be no 'reuse' of existing bindings, but maybe Asko can change that and merge some features of loadmodule and his GluaX.

-Martin


Reply | Threaded
Open this post in threaded view
|

[LuaCheia] build system

Martin Spernau
In reply to this post by Martin Spernau
I would vote for the Lua based 'premake' as it can automate the various platform build-files (project files) etc. nicely.

But I would also very much like to favor MinGW over MSVC for the windows parts. For one MinGW is very much closer to the *IX way of doing things, and it's free. I'm not sure if we _need_ to support MSVC directly, as we are mainly trying to provide a binary distro for the various plattforms (?(

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Martin Spernau
Well, as you might have seen on the Wiki page, I'd like to do the design & maintainance for the LuaCheia project.

So I'd like to hear some opinions:
* should the design & layout follow that of lua-users.org? (simple but functional)
* Would you like it more elaborate?
- I would still strongly suggest to keep it 'simple' as to keep in line with the Lua philosophy * Logo... I think we need a logo different from the Lua logo, but it should be derived in some form. A 'Full Moon' comes to mind... any ideas?

* Wiki / Duscussion board or what?
- I would suggest we have a (static) website maintained by admins, and also a Wiki forcolaborative idea-forming. I don't think a discussionboard is needed, as we would rathewr have a mailing list.

-Martin
http://traumwind.de


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Luiz Henrique de Figueiredo
In reply to this post by D Burgess
>* Logo... I think we need a logo different from the Lua logo, but it 
>should be derived in some form. A 'Full Moon' comes to mind... any ideas?

How about one of these?
	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia1.gif
	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia2.gif
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Martin Spernau


How about one of these?
	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia1.gif
	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia2.gif
--lhf

Nice!

I have made a HTML version of the design I had in mind available here:
http://traumwind.de/computer/lua/LuaCheia.html
It's basically the HTML from the Wiki page repackaged with some CSS formating. Please note that the HTML source (do a 'view source') is kept absolutly simple jno-frills HTML. The fancy layout comes excusivcely from CSS styles.

Please also note that the design might look slighly less fany *g* in older browsers like Netscape4, but then due to it's very basic HTML markup it is still functional even in those legacy browsers or even in Lynx.

Comments welcome,
-Martin


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Juergen Fuhrmann
>  Tue, 11 Feb 2003 15:00:02 +0100
>  Martin Spernau <[hidden email]> wrote:
>
>  >
>  >
>  >How about one of these?
>  >	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia1.gif
>  >	http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia2.gif
>  >--lhf
>  >
>  Nice!
>  
>  I have made a HTML version of the design I had in mind available here:
>  http://traumwind.de/computer/lua/LuaCheia.html
>  It's basically the HTML from the Wiki page repackaged with some CSS 
>  formating. Please note that the HTML source (do a 'view source') is kept 
>  absolutly simple jno-frills HTML. The fancy layout comes excusivcely 
>  from CSS styles.
>  
>  Please also note that the design might look slighly less fany *g* in 
>  older browsers like Netscape4, but then due to it's very basic HTML 
>  markup it is still functional even in those legacy browsers or even in Lynx.
>  

>    GluaX: Dynamic loading of libraries. or Loadlib dynamic library support. 
Would be nice to join this with tolua.
>    SDL: Has threading, graphics support, and is useful for gaming applications of Lua. 
>    A GUI LIbrary/ Possibilities include wxWindows, FLTK,... Which one to choose? 
>        If you want to LC to be cross platform then wxWindows is your best bet. I don't think FLTK works on the Mac - see
>        VisLuaImplementation for more info. wxLua exists already. --NDT 
FLTK works now with MacOS. I very much would like to see FLTK here, as it is compact,
portable and without bloat. Compiles well on every UNIX I tried on. Very much like Lua.
>    SQLite: Lightweight SQL without server. 
>    Lua sockets. 
>    Complete regular expressions. (which library?) 
>        I would suppose PCRE, I already have a partial binding to it -- MartinSpernau 
>    Assistance for CGI, web-based programming. (which library?) 
>    Extended math. (which libraries? ) 
>    Directory handling, filesystem manipulation. (which libraries?) 
>    Zlib compression support. Needed for SDL_image/libpng. 
>    Lua script repository that facilitates common tasks such as OOP/inheritance programming. 

Juergen

Reply | Threaded
Open this post in threaded view
|

# comments (proposal)

Szabolcs Szasz
In reply to this post by Martin Spernau
http://www.wraith.u-net.com/lua/ref5/man/manual.html#3.1:

"Comments (...)
For convenience, the first line of a chunk is skipped if it starts with #. This facility allows the use of Lua as a script
interpreter in Unix systems (see Section 7)."

Here the LUA syntax supports a common "UNIX use" specifically.

I'd like to bring attention to missing support for another
very common "UNIX use" case and a simple LUA feature that
could address it "for free".

A very practical and convenient use of embedded LUA is to
parse config files for a host program. Most config files
use a simple format on all UNIXes of var = "something"
syntax, which, luckily (and due to proper design), also
fits LUA syntax seamlessly.

However, those config files (being sh, perl, or other scripts
most of the time) traditionally also allow # comments. NB:
a number of (also embeddable) languages -- e.g. Ruby, PHP
-- adds support for # comments for the very reason of supporting
applications in the system-administration domain (besides
maintaining "cognitive compatibility" with those traditional
tools).

Unfortunately, the "--" LUA commenting syntax currently
prevents sysadmin tools from being developed utilizing the
convenient and powerful LUA 'dofile" technique for supporting
the common UNIX config file syntax.

Developing LUA-powered sysadmin tools could therefore get a
significant boost, as they could understand *tons* of existing
config files immediately, if the # comments would not be
explicitly limited to the first line of a file.

Relaxing that present limitation would:

    1. allow trivial parsing of "unixersal" config files
        from LUA-embedding tools

    2. allow sysadmins to continue using/generating config
        files for new LUA-aware programs the same way they
        have been doing for other common tools

    3. allow LUA-powered config-parsing programs to
        coopearte with existing config-file-parsing tools,
        using a vastly prevalent common syntax.

Best of all, all that would come for free, as there is nothing
special in LUA that would prevent using '#' from a line-comment
token; even to the contrary:

    a) the '#' *IS* already used for comment syntax

    b) LUA could get rid of that not very elegant rule of
        treating the first-line # specially

    c) backward compatibility would also be maintained

So, I would propose allowing # for general use as a line-comment.

5.0 coming out (and the great potential of LuaCheia for
popularizing the language) makes this time a perfect
opportunity for this very simple and very useful change.

Thanks for your attention,
Sab


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] build system

Björn De Meyer
In reply to this post by Martin Spernau
Martin Spernau wrote:
> 
> I would vote for the Lua based 'premake' as it can automate the various
> platform build-files (project files) etc. nicely.
> 
> But I would also very much like to favor MinGW over MSVC for the windows
> parts. For one MinGW is very much closer to the *IX way of doing things,
> and it's free.
> I'm not sure if we _need_ to support MSVC directly, as we are mainly
> trying to provide a binary distro for the various plattforms (?(
> 
> -Martin

Hmmm... I checked out premake today, but I must say
I see some limitations to it. For instance, it lacks a MAC
port. And, I couldn't even get it to compile itself. 
Also we might have to watch out for the "bootstrap problem"

I think a mixed build system which combines automake
with Visual Studio and Metrowerks project files would be 
feasible. Other cross-platform libraries such as SDL or 
FLTK use a similar method. Now the problem is, that 
I don't know automake. Anyone here who could give me 
any pointers?



-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Björn De Meyer
In reply to this post by Martin Spernau
Martin Spernau wrote:
> 
> Well, as you might have seen on the Wiki page, I'd like to do the design
> & maintainance for the LuaCheia project.
> 
> So I'd like to hear some opinions:
> * should the design & layout follow that of lua-users.org? (simple but
> functional)
Yes. Definitely.

> * Would you like it more elaborate?
>     - I would still strongly suggest to keep it 'simple' as to keep in
> line with the Lua philosophy

Simple, but whith a white background. That default gray
gets on my nerves on my old, old home browser.

> * Logo... I think we need a logo different from the Lua logo, but it
> should be derived in some form. A 'Full Moon' comes to mind... any ideas?

Why not the Lua logo, but with the blue background replaced
by a blue full moon? Just a stab in the dark...



> * Wiki / Duscussion board or what?
>     - I would suggest we have a (static) website maintained by admins,
> and also a Wiki forcolaborative idea-forming.   I don't think a
> discussionboard is needed, as we would rathewr have a mailing list.

Sourceforge provides message boards if need be. We'll see...
 

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Martin Spernau
> Simple, but whith a white background. That default gray
> gets on my nerves on my old, old home browser.

What browser are you using, and on what system?

>From watching my logfiles for the demo page at
http://traumwind.de/computer/lua/LuaCheia.html I see almost any browser and
OS in existance, which is a quite different situation from normal websites.
That might be due to the fact that people are throwing every browser they
have at it, or due to the diverse audience of this list...

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Björn De Meyer
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> 
> >* Logo... I think we need a logo different from the Lua logo, but it
> >should be derived in some form. A 'Full Moon' comes to mind... any ideas?
> 
> How about one of these?
>         http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia1.gif
>         http://www.tecgraf.puc-rio.br/~lhf/etc/luacheia2.gif
> --lhf

Thak you! I like nr 1 the most.

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] binding libs / dyn loading, premake

Björn De Meyer
In reply to this post by Martin Spernau
Martin Spernau wrote:
> 
> As to what binding/loading achitecture to use, GluaX ahs one great benefit:
> a _binary_ module build for a GluaX host can be loaded with Lua4 AND
> Lua5 without any changes (binary after all). I think that would be a
> great benefit.
> And it doesn't hinder using other binding techiques like tolua etc.
> 
> A drawback of GluaX is that the binding needs to be made completly for
> GluaX, so there would be no 'reuse' of existing bindings, but maybe Asko
> can change that and merge some features of loadmodule and his GluaX.
> 
> -Martin

GluaX is promising, but I have some reservations about it.
My biggest "problem" with GluaX is simple but important: 
there seems to be no tool to automatically generate wrappers from 
header files. If I was audacious, then I would claim that we will
be able to write all these wrappers manually, but realistically
speaking, 
I think we all lack time to do that. 

I think we will need an automated tool like tolua that will generate
the wrappers for us. It's no fun to wrap 100+ functions by hand! 
If we can somehow combine tolua and Gluax, the nwe might be set.

Oh, and I also have some smaller problems with the security of 
GluaX. I've spotted several possible buffer overruns in there...
Nothing that cannot be solved, of course. 

Oh, and while I'm at it, I also cheked out Premake, but 
that would require a LOT of tweaking before it's ready for 
what we intend to do. Not to mention it hasn't been ported to 
Mac.


-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: # comments (proposal)

Björn De Meyer
In reply to this post by Szabolcs Szasz
Szabolcs Szasz wrote:
> 
/snip

I agree, but I also think it will need to be for 
the version after Lua 5.0. As I understand it, 
Lua 5.0 is in "feature freeze" now.


-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Martin Spernau
In reply to this post by Martin Spernau
OK folks, we'd better get something out soon, the ever watching
GoogleBot(TM) has already found us!!
64.68.82.57 - - [11/Feb/2003:20:48:52 +0100] "GET
/computer/lua/LuaCheia.html HTTP/1.0" 200 4461 "-" "Googlebot/2.1
(+http://www.googlebot.com/bot.html)"

----- Original Message -----
From: "Martin Spernau" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, February 11, 2003 11:03 PM
Subject: Re: [LuaCheia] website


> > Simple, but whith a white background. That default gray
> > gets on my nerves on my old, old home browser.
>
> What browser are you using, and on what system?
>
> >From watching my logfiles for the demo page at
> http://traumwind.de/computer/lua/LuaCheia.html I see almost any browser
and
> OS in existance, which is a quite different situation from normal
websites.
> That might be due to the fact that people are throwing every browser they
> have at it, or due to the diverse audience of this list...
>
> -Martin
>


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] website

Björn De Meyer
In reply to this post by Martin Spernau
Martin Spernau wrote:
> 
> > Simple, but whith a white background. That default gray
> > gets on my nerves on my old, old home browser.
> 
> What browser are you using, and on what system?

An archaic 3.x Netscape. I'll only upgrade when I buy a
new computer (hopefully in March).

> 
> >From watching my logfiles for the demo page at
> http://traumwind.de/computer/lua/LuaCheia.html I see almost any browser and
> OS in existance, which is a quite different situation from normal websites.
> That might be due to the fact that people are throwing every browser they
> have at it, or due to the diverse audience of this list...
> 
> -Martin

Well, I see the source is very clean, so keep it as is, that seems the
best.

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: # comments (proposal)

Luiz Henrique de Figueiredo
In reply to this post by Szabolcs Szasz
>I agree, but I also think it will need to be for 
>the version after Lua 5.0. As I understand it, 
>Lua 5.0 is in "feature freeze" now.

Yes, that's right. Moreover, # comments (and much more) can be implemented by
the host program because Lua 5.0 uses lua_load to load chunks, and lua_load
calls a user function to get bit of text (or bytes). In other words, if you
want to support # comments, then write your lua_load callback so that you read
and return whole lines, skipping those starting with #. I'm not claiming this
is the best/nicest way of doing it (surely, the simplest way is just to add a
couples of lines to llex.c :-), and it will have trouble with long strings
([[...]]) but it definitely works fine and as planned for lua_load. The only
thing is that the standard loadL_loadfile and lua_dofile do not do this, but
that's ok.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: # comments (proposal)

D Burgess
In reply to this post by Szabolcs Szasz
12