Re: about lposix

["Mike Panetta" <panetta.mike@...>]

Will this solve the problems of people that need explicitly the
features that some of the POSIX functions provide?  I don't know
what windows has because I dont write software for it, but I am using
Lua to script the startup process of an 'embedded' Linux system. 
This is why I needed my own versions of waitpid and execvp.  The
ones that were in the posix library didnt have all the functionality of
the C versions (that functionality is there for a reason!) and I could
not tell if my spawned processes were returning the values I wanted or
were being killed by signals or what have you.  Its particularly
important that I have a version of wait (waitpid, whatever) that DOES
NOT BLOCK.  As I wait for my spawned process to finish I am
updating a front panel LCD and placating a watchdog timer.  I need
to keep track of how long the process is running to "do the right thing
(TM)".  If I can't do that with whatever is decided here then I
will just have to write my own library.  Maybe the best thing to
do is to have a windows library, and a POSIX library, and a LUA top
level abstraction for both?  And isn't windows becoming more POSIX
these days with the unix services for windows stuff?

Oh, and we also need to make sure we keep track of input and output
arguments to the functions.  One of the other reasons I wrote my
own exec was because of the way the current lposix exec takes
arguments.  It takes a list of strings, and not a ... type arg
(which is just an array really), so its very difficult if not
impossible to extend the function in LUA.  I think this is bad,
because LUA is a language to extend things, so making it difficult is
kind of counter productive :)

Thanks for all the great work!
Mike

On 10/17/06, Natanael Copa <natanael.copa@gmail.com> wrote:

Luiz,

On Tue, 2006-10-17 at 11:21 -0300, Luiz Henrique de Figueiredo wrote:
> Let me summarize the current state of afairs:

> So, my suggestion, which has already been made recently, is that we join
> efforts and write an extended OS library that works on POSIX and Windows,
> and that can be easily ported to other OS. That requires that we reach
> an agreement about what to include in it and most important what *not* to
> include.
>
> I can try to coordinate this by extracting the relevant parts of lposix and
> the other libraries as needed. But I cannot do anything about Windows...
> Or if someone else wants to takes this over, it's ok, but we'd still like to
> discuss what shall be included and what shall not. We must avoid bloat.
> Again, the point is that it is simple to include any given function, but
> we have to consider the other requirements: natural Lua interface,
> documentation, ease of porting, etc.

This is great! That was exactly what I wanted to hear.

> [1] http://lua-users.org/wiki/ExtensionProposal

The ex module has already done a great work so I think thats a good
starting point. But I'd suggest we have several smalles libs for
different categories. That way you dont need to include process and file
management if you only need to get and set environment.

What do you think about this as a start:

env.getenv(name)
env.setenv(name, value)
env.environ()

fs.attributes -- this is from luafilesystem
fs.chdir(pathname)
fs.mkdir(pathname)
fs.currentdir()
fs.dir(pathname)
fs.dirent(pathname)
fs.lock(file, mode, offset, length)
fs.unlock(file, offset, length)

proc.pipe()
proc.sleep(seconds)
proc.spawn(...)
proc.wait(proc)

It is basicly the ex module but just different prefixes. I believe that
will help it to scale without being bloaty.

I'd like to add "glob" but I don't know how it can be implemented in windows.

Natanael Copa