Standard Lua Library

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

Standard Lua Library

D Burgess-4
Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Luiz Henrique de Figueiredo
> So where are things at with:
> 
> http://lua-users.org/lists/lua-l/2006-10/msg00499.html

On hold right now but still very much alive as a goal. Sorry about that.

Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

D Burgess-4
Is there anything I can do to help progress this?

db

On 1/8/07, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> So where are things at with:
>
> http://lua-users.org/lists/lua-l/2006-10/msg00499.html

On hold right now but still very much alive as a goal. Sorry about that.


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Natanael Copa
On Mon, 2007-01-08 at 23:05 +1100, David Burgess wrote:

> On 1/8/07, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> > > So where are things at with:
> > >
> > > http://lua-users.org/lists/lua-l/2006-10/msg00499.html
> >
> > On hold right now but still very much alive as a goal. Sorry about that.
>
> Is there anything I can do to help progress this?

I agree. I would also like to help if it was possible.

Here are some things I have been thinking:

1. Make a comparison table of all funcions in ex, luafilesystem, lposix
and maybe even their equivalent in apr as reference.

2. Make the API. Decide what functions should be included and what the
names should be

3. Create the lib.

4. remove all the funcs implemented in this lib from lposix and keep
lposix as a posix specific thing for non-windows stuff.

Some points:

* We could borrow a part of the apr API (just strip of the apr_ prefix).
Reimplementing something already working and tested is much easier than
re-engineer from scratch.

* There is no need to stress with implementing both Linux and Windows
from the start. Windows is such a big platform so if we just get the API
there and an initial Linux version, somebody will port it to windows.
Just make sure the API makes it possible (avoid things like fork and
posix specific things)

my $0.02




Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

D Burgess-4
Natanael Copa wrote:
* We could borrow a part of the apr API (just strip of the apr_ prefix).
Reimplementing something already working and tested is much easier than
re-engineer from scratch.
I am not sure the apr license allows this. It is LGPL, no?


* There is no need to stress with implementing both Linux and Windows
from the start. Windows is such a big platform so if we just get the API
there and an initial Linux version, somebody will port it to windows.
Just make sure the API makes it possible (avoid things like fork and
posix specific things)
Yes, the API is all important. But I would vote for developing the two
concurrently.

Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Alex Queiroz
Hallo,

On 1/8/07, David Burgess <[hidden email]> wrote:
Natanael Copa wrote:
> * We could borrow a part of the apr API (just strip of the apr_ prefix).
> Reimplementing something already working and tested is much easier than
> re-engineer from scratch.
I am not sure the apr license allows this. It is LGPL, no?


    APR is the Apache Runtime, so it's Apache licensed.

--
-alex
http://www.ventonegro.org/

Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Natanael Copa
In reply to this post by D Burgess-4
On Tue, 2007-01-09 at 00:37 +1100, David Burgess wrote:
> Natanael Copa wrote:
> > * We could borrow a part of the apr API (just strip of the apr_ prefix).
> > Reimplementing something already working and tested is much easier than
> > re-engineer from scratch.
> I am not sure the apr license allows this. It is LGPL, no?

I was thinking of the API. Just reuse the function names. If that was
illegal winehq would be in big trouble re-implementing win32 API.

natanael


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Wim Couwenberg
In reply to this post by D Burgess-4
Is there anything I can do to help progress this?

I second that.  I would welcome a new *fun* software project right now
(now that the holidays are over...)  :-)  As stated before, I can
contribute for Windows and OS X.

--
Wim

Reply | Threaded
Open this post in threaded view
|

RE: Standard Lua Library

Vijay Aswadhati-2
In reply to this post by Natanael Copa
On Monday, January 08, 2007 5:19 AM, Natanael Copa wrote:
> 
> Some points:
> 
> * We could borrow a part of the apr API (just strip of the apr_ prefix).
> Reimplementing something already working and tested is much easier than
> re-engineer from scratch.
> 

I looked into APR and NSPR a long time ago.

NSPR is clean but sports a non-conventional design (i.e departs from
posix/c-runtime style) for IO and sockets. The license is a bit confusing as
well.

APR is clean, rich and has a conventional API flavor to it. 

Back then (and I still do) I had trouble understanding and in managing the
apr_pool_t needed for most of API. At that time Lua was transitioning from
5.0 to 5.1 and I told myself then was not a good time. Now I can see a way
of managing the apr_pool_t using udata environment.

APR license uses the same as Apache web server and I think poses no hard
restrictions for commercial use.

The documentation has also improved lately; it still leaves much to be
desired.

My point however is that choosing APR and providing a binding to it would be
an excellent choice. Let us please not re-invent the wheel.

Cheers
Vijay Aswadhati




Reply | Threaded
Open this post in threaded view
|

RE: Standard Lua Library

Natanael Copa
On Mon, 2007-01-08 at 10:20 -0800, Vijay Aswadhati wrote:
> On Monday, January 08, 2007 5:19 AM, Natanael Copa wrote:
> > 
> > Some points:
> > 
> > * We could borrow a part of the apr API (just strip of the apr_ prefix).
> > Reimplementing something already working and tested is much easier than
> > re-engineer from scratch.
> > 

> My point however is that choosing APR and providing a binding to it would be
> an excellent choice. Let us please not re-invent the wheel.

apr is kind of big. I was thinking of reuse the code in ex,
luafilesystem and lposix but use (or learn from) the apr *API*.

natanael


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Asko Kauppi
In reply to this post by Natanael Copa

Don't forget the GnuSTEP Foundation classes binding I'm currently working on. :)

Help in making test cases for it would be needed.


Natanael Copa kirjoitti 8.1.2007 kello 15.18:

On Mon, 2007-01-08 at 23:05 +1100, David Burgess wrote:

On 1/8/07, Luiz Henrique de Figueiredo <[hidden email]> wrote:
So where are things at with:

http://lua-users.org/lists/lua-l/2006-10/msg00499.html

On hold right now but still very much alive as a goal. Sorry about that.

Is there anything I can do to help progress this?

I agree. I would also like to help if it was possible.

Here are some things I have been thinking:

1. Make a comparison table of all funcions in ex, luafilesystem, lposix
and maybe even their equivalent in apr as reference.

2. Make the API. Decide what functions should be included and what the
names should be

3. Create the lib.

4. remove all the funcs implemented in this lib from lposix and keep
lposix as a posix specific thing for non-windows stuff.

Some points:

* We could borrow a part of the apr API (just strip of the apr_ prefix). Reimplementing something already working and tested is much easier than
re-engineer from scratch.

* There is no need to stress with implementing both Linux and Windows
from the start. Windows is such a big platform so if we just get the API
there and an initial Linux version, somebody will port it to windows.
Just make sure the API makes it possible (avoid things like fork and
posix specific things)

my $0.02





Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Mark Edgar
In reply to this post by Natanael Copa
Natanael Copa wrote:
I agree. I would also like to help if it was possible.

Here are some things I have been thinking:

1. Make a comparison table of all funcions in ex, luafilesystem, lposix
and maybe even their equivalent in apr as reference.

http://lua-users.org/wiki/ExtendedApi

Please feel free to add APR into the comparison mix. I don't know much about it.

2. Make the API. Decide what functions should be included and what the
names should be

The "ex" API was and is intended to be a proposal for an such an API. It provides "standard" O/S facilities beyond what standard C (and thus Lua core) provides.

3. Create the lib.

"ex" already has two implementations one each for POSIX and Windows. They are not terribly clean, have no included build process, and could stand a review.

4. remove all the funcs implemented in this lib from lposix and keep
lposix as a posix specific thing for non-windows stuff.

Why remove functionality from lposix? It stands by itself as a perfectly good POSIX binding for Lua. If your program is not intended for Windows and will never target it, instead targeting POSIX directly, it makes perfect sense to use lposix.


It seems that the biggest strike against the "ex" API is the fact that it integrates into the Lua io and os namespaces. It seems many people feel that this may cause too much confusion for new Lua users.

However, I feel that in order for such an API to be useful, it must integrate strongly with the core libraries. The "ex" API currently integrates with the core libraries in the following ways:

Augmenting the io namespace (io.pipe)
Augmenting the os namespace (many functions)
Augmenting the file metatable with lock() and unlock() methods
Reimplementing os.getenv()
Redefining os.remove() to remove directories
Returning actual file objects from io.pipe()

The proper way to write a portable, stand-alone Lua program with the "ex" API is to always require "ex" in your program, documenting the fact that it will use extensions to the Lua core. Alternatively, one can document the use of extension APIs individually:

assert(os.sleep, "This program requires os.sleep")

					-Mark


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Asko Kauppi

You could use a trick that I uncovered lately, to allow for variants of the "ex" loading procedure:

local ex= require "ex" -- load to user's own table (not os, io)

require "ex" (_G)          -- into global namespace

require "ex" "tie-in"      -- into os.*, io.*

require "ex" { "os.pipe" } -- if you want to be really picky

The trick is, having a __call() metamethod in the table that your module returns. Then having that function do the loading in a customized way. I prefer this method hugely over providing a specific initialization function that needs to be separately called.

-asko


On Mon, 08 Jan 2007 18:06:51 -0700
 Mark Edgar <[hidden email]> wrote:
Natanael Copa wrote:
I agree. I would also like to help if it was possible.

Here are some things I have been thinking:

1. Make a comparison table of all funcions in ex, luafilesystem, lposix
and maybe even their equivalent in apr as reference.

http://lua-users.org/wiki/ExtendedApi

Please feel free to add APR into the comparison mix. I don't know much about it.

2. Make the API. Decide what functions should be included and what the
names should be

The "ex" API was and is intended to be a proposal for an such an API. It provides "standard" O/S facilities beyond what standard C (and thus Lua core) provides.

3. Create the lib.

"ex" already has two implementations one each for POSIX and Windows. They are not terribly clean, have no included build process, and could stand a review.

4. remove all the funcs implemented in this lib from lposix and keep
lposix as a posix specific thing for non-windows stuff.

Why remove functionality from lposix? It stands by itself as a perfectly good POSIX binding for Lua. If your program is not intended for Windows and will never target it, instead targeting POSIX directly, it makes perfect sense to use lposix.


It seems that the biggest strike against the "ex" API is the fact that it integrates into the Lua io and os namespaces. It seems many people feel that this may cause too much confusion for new Lua users.

However, I feel that in order for such an API to be useful, it must integrate strongly with the core libraries. The "ex" API currently integrates with the core libraries in the following ways:

Augmenting the io namespace (io.pipe)
Augmenting the os namespace (many functions)
Augmenting the file metatable with lock() and unlock() methods
Reimplementing os.getenv()
Redefining os.remove() to remove directories
Returning actual file objects from io.pipe()

The proper way to write a portable, stand-alone Lua program with the "ex" API is to always require "ex" in your program, documenting the fact that it will use extensions to the Lua core. Alternatively, one can document the use of extension APIs individually:

assert(os.sleep, "This program requires os.sleep")

					-Mark



Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Adrian Sietsma
In reply to this post by Mark Edgar
Mark Edgar wrote:
[...]

However, I feel that in order for such an API to be useful, it must integrate strongly with the core libraries. The "ex" API currently integrates with the core libraries in the following ways:

Augmenting the io namespace (io.pipe)
Augmenting the os namespace (many functions)
Augmenting the file metatable with lock() and unlock() methods
Reimplementing os.getenv()
Redefining os.remove() to remove directories
Returning actual file objects from io.pipe()

could the "ex" (or whatever) library have a parameter to "require" to
control whether it loads into "ex" and/or updates io,os etc ?

Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Mildred Ki'Lya
In reply to this post by Asko Kauppi
Le mar 09/01/2007 Ã 06:17 [hidden email] Ã Ãcrit:
> local ex= require "ex"   -- load to user's own table (not 
> os, io)
> 
> require "ex" (_G)          -- into global namespace
> 
> require "ex" "tie-in"      -- into os.*, io.*
> 
> require "ex" { "os.pipe" }    -- if you want to be really 
> picky


Personally I prefer to always call functions with ().
So for my modules, there is an install method. For example:

local ex = require("ex").install(_G)

If we choose a somution like that, maybe we could provide the two
possibilities.


-- 
Mildred       <xmpp:[hidden email]> <http://mildred632.free.fr/>
Clef GPG :    <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Natanael Copa
In reply to this post by Mark Edgar
On Mon, 2007-01-08 at 18:06 -0700, Mark Edgar wrote:
> Natanael Copa wrote:
> > I agree. I would also like to help if it was possible.
> > 
> > Here are some things I have been thinking:
> > 
> > 1. Make a comparison table of all funcions in ex, luafilesystem, lposix
> > and maybe even their equivalent in apr as reference.
> 
> http://lua-users.org/wiki/ExtendedApi
>
> Please feel free to add APR into the comparison mix.  

I did. Might be good as reference.

> I don't know much about it.

Not me either. But I found some stuff here:
http://apr.apache.org/docs/apr/1.2/globals_func.html

>
> > 2. Make the API. Decide what functions should be included and what the
> > names should be
> 
> The "ex" API was and is intended to be a proposal for an such an API. It 
> provides "standard" O/S facilities beyond what standard C (and thus Lua 
> core) provides.
> 
> > 3. Create the lib.
> 
> "ex" already has two implementations one each for POSIX and Windows. 
> They are not terribly clean, have no included build process, and could 
> stand a review.

At least they have for both windows and posix. Other people (like me)
only talk and don't do anything.

> > 4. remove all the funcs implemented in this lib from lposix and keep
> > lposix as a posix specific thing for non-windows stuff.
> 
> Why remove functionality from lposix?  

To avoid having 3 different modules to chose between for simple
operations. It might be you need some funcs from both the standard lib
(that maybe is not included in lposix) and lposix. I use Lua in the
first place to avoid bloat.

> It stands by itself as a perfectly good POSIX binding for Lua.  If
> your program is not intended 
> for Windows and will never target it, instead targeting POSIX directly, 
> it makes perfect sense to use lposix.

Yes, and of course should there be a lposix library for those who do
posix only (like me). But I would prefer having the functions that can
be ported in one single standard library. The lposix would remain and
contain POSIX only things like fork, getuid, setuid etc. But having
funcs for parsing, making and removing dirs would be better to keep in
the standard lib.

> It seems that the biggest strike against the "ex" API is the fact that 
> it integrates into the Lua io and os namespaces.  It seems many people 
> feel that this may cause too much confusion for new Lua users.

Yes. Exactly. If i want file system function, then i'd like to load the
file system module. If I want process handling, then load the process
module. I know where my funcs come from, I know where to look for
documentation.

Can you give any examples of other programming languages that does
something similar? inject functions into other namespaces?

If thats the Lua-way of doing things, then fine, lets try get the lua
developers blessing (reference in official lua documentaion such as PiL)

Then also please lets write some docs saying that the "lua way" of
doingthings is to inject stuff in existing namespaces. "This is how you
inject your own funcs that you feel missing in office os module and ex:

...
os.myownfunc()
...


> However, I feel that in order for such an API to be useful, it must 
> integrate strongly with the core libraries.  

I strongly disagree. If the core libs are too thin or not good enough,
then fix the core libs. I think that the core libs should be as they
are: thin. Add new name spaces to the optional stuff you might want.

> The "ex" API currently 
> integrates with the core libraries in the following ways:
> 
> Augmenting the io namespace (io.pipe)
> Augmenting the os namespace (many functions)
> Augmenting the file metatable with lock() and unlock() methods
> Reimplementing os.getenv()
> Redefining os.remove() to remove directories
> Returning actual file objects from io.pipe()

I would prefer something like:

require "env"
env.get()
env.set()

require "proc"
proc.sleep()
proc.create()
proc.wait()

require "dir"
dir.getcurrent()
dir.setcurrent()
dir.make()
dir.remove()

for e in dir.iterate() do
   ...
end

lock and unlock could probably go into the Lua core.

> The proper way to write a portable, stand-alone Lua program with the 
> "ex" API is to always require "ex" in your program, documenting the fact 
> that it will use extensions to the Lua core. Alternatively, one can
> document the use of extension APIs individually:
> 
> assert(os.sleep, "This program requires os.sleep")
> 
> 					-Mark

Hackish, IMHO. Better fix the lua core if this really belongs there. If
not, give it a new namespace.

If I'm completely wrong, and this is the "Lua way" of doing things, and
the Lua developers encourage this way of doing things, please let me
know. Then sure, I'm in.

--
Natanael Copa


Reply | Threaded
Open this post in threaded view
|

RE: Standard Lua Library

Jay Carlson
In reply to this post by D Burgess-4
Why not proxy os.* into osx.* ?  You can always do

local os = osx

In all seriousness, consider ripping off Python, especially things named foolib2.  That tends to indicate that hard lessons in design from foolib have been learned.  

-- 
Jay
Sent from a Treo, excuse infelicities

-----Original Message-----
From: "Natanael Copa" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: 1/9/07 4:19 PM
Subject: Re: Standard Lua Library

On Mon, 2007-01-08 at 18:06 -0700, Mark Edgar wrote:
> Natanael Copa wrote:
> > I agree. I would also like to help if it was possible.
> > 
> > Here are some things I have been thinking:
> > 
> > 1. Make a comparison table of all funcions in ex, luafilesystem, lposix
> > and maybe even their equivalent in apr as reference.
> 
> http://lua-users.org/wiki/ExtendedApi
>
> Please feel free to add APR into the comparison mix.  

I did. Might be good as reference.

> I don't know much about it.

Not me either. But I found some stuff here:
http://apr.apache.org/docs/apr/1.2/globals_func.html

>
> > 2. Make the API. Decide what functions should be included and what the
> > names should be
> 
> The "ex" API was and is intended to be a proposal for an such an API. It 
> provides "standard" O/S facilities beyond what standard C (and thus Lua 
> core) provides.
> 
> > 3. Create the lib.
> 
> "ex" already has two implementations one each for POSIX and Windows. 
> They are not terribly clean, have no included build process, and could 
> stand a review.

At least they have for both windows and posix. Other people (like me)
only talk and don't do anything.

> > 4. remove all the funcs implemented in this lib from lposix and keep
> > lposix as a posix specific thing for non-windows stuff.
> 
> Why remove functionality from lposix?  

To avoid having 3 different modules to chose between for simple
operations. It might be you need some funcs from both the standard lib
(that maybe is not included in lposix) and lposix. I use Lua in the
first place to avoid bloat.

> It stands by itself as a perfectly good POSIX binding for Lua.  If
> your program is not intended 
> for Windows and will never target it, instead targeting POSIX directly, 
> it makes perfect sense to use lposix.

Yes, and of course should there be a lposix library for those who do
posix only (like me). But I would prefer having the functions that can
be ported in one single standard library. The lposix would remain and
contain POSIX only things like fork, getuid, setuid etc. But having
funcs for parsing, making and removing dirs would be better to keep in
the standard lib.

> It seems that the biggest strike against the "ex" API is the fact that 
> it integrates into the Lua io and os namespaces.  It seems many people 
> feel that this may cause too much confusion for new Lua users.

Yes. Exactly. If i want file system function, then i'd like to load the
file system module. If I want process handling, then load the process
module. I know where my funcs come from, I know where to look for
documentation.

Can you give any examples of other programming languages that does
something similar? inject functions into other namespaces?

If thats the Lua-way of doing things, then fine, lets try get the lua
developers blessing (reference in official lua documentaion such as PiL)

Then also please lets write some docs saying that the "lua way" of
doingthings is to inject stuff in existing namespaces. "This is how you
inject your own funcs that you feel missing in office os module and ex:

...
os.myownfunc()
...


> However, I feel that in order for such an API to be useful, it must 
> integrate strongly with the core libraries.  

I strongly disagree. If the core libs are too thin or not good enough,
then fix the core libs. I think that the core libs should be as they
are: thin. Add new name spaces to the optional stuff you might want.

> The "ex" API currently 
> integrates with the core libraries in the following ways:
> 
> Augmenting the io namespace (io.pipe)
> Augmenting the os namespace (many functions)
> Augmenting the file metatable with lock() and unlock() methods
> Reimplementing os.getenv()
> Redefining os.remove() to remove directories
> Returning actual file objects from io.pipe()

I would prefer something like:

require "env"
env.get()
env.set()

require "proc"
proc.sleep()
proc.create()
proc.wait()

require "dir"
dir.getcurrent()
dir.setcurrent()
dir.make()
dir.remove()

for e in dir.iterate() do
   ...
end

lock and unlock could probably go into the Lua core.

> The proper way to write a portable, stand-alone Lua program with the 
> "ex" API is to always require "ex" in your program, documenting the fact 
> that it will use extensions to the Lua core. Alternatively, one can
> document the use of extension APIs individually:
> 
> assert(os.sleep, "This program requires os.sleep")
> 
> 					-Mark

Hackish, IMHO. Better fix the lua core if this really belongs there. If
not, give it a new namespace.

If I'm completely wrong, and this is the "Lua way" of doing things, and
the Lua developers encourage this way of doing things, please let me
know. Then sure, I'm in.

--
Natanael Copa




Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Nodir Temirkhodjaev
In reply to this post by D Burgess-4
Also look at LuaSys:
- file I/O and file system;
- serial communication;
- sockets;
- event notification mechanism (recently added IOCP);
- win32 stuff: registry, event, service;
etc.

--
http://lua-users.org/files/wiki_insecure/users/tnodir/

Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

Philippe Lhoste
In reply to this post by Natanael Copa
Natanael Copa wrote:
At least they have for both windows and posix. Other people (like me)
only talk and don't do anything.

I fear to be in category too... ;-)

It seems that the biggest strike against the "ex" API is the fact that it integrates into the Lua io and os namespaces. It seems many people feel that this may cause too much confusion for new Lua users.

Yes. Exactly. If i want file system function, then i'd like to load the
file system module. If I want process handling, then load the process
module. I know where my funcs come from, I know where to look for
documentation.

Can you give any examples of other programming languages that does
something similar? inject functions into other namespaces?

My understanding is that Lua authors has put most functions in tables (namespaces) precisely to avoid clashes. If two people use the same table name (same namespace), there is a risk of one function hiding another of same name. The risk is higher if the functionalities are similar (which is probable if the namespaces are identical) and even more if using one of the official namespaces!

Using such space should be done only with official blessing, as you stated.

Just my 0.02€...

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


Reply | Threaded
Open this post in threaded view
|

Re: Standard Lua Library

James Hearn-2
In reply to this post by Natanael Copa
Can you give any examples of other programming languages that does
something similar? inject functions into other namespaces?

In Ruby all classes and modules are "open" meaning that other classes
are free to inject, patch, or otherwise modify their class
definitions. As a particular example Ruby on Rails adds functionality
to core classes like strings and numbers (!) It's definitely a
different approach than the standard in most other languages, but the
Ruby camp considers it a strength rather than a drawback.

James

12