Re: Status of lposix?

[Joshua Jensen <jjensen@...>]

----- Original Message -----
From: steve donovan
Date: 5/28/2009 1:53 AM

On Thu, May 28, 2009 at 9:41 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
  

Is there a precedent for this?  Has an external module been endorsed by the
list and then by the Lua authors?
    

They don't regard it as their job. They do the kernel, we do the userland ;)
  

Nor should it be their job.  I can't imagine tracking/testing/endorsing/etc every module out there.  What a headache.

When luaproc came out, there was one posting
(http://lua-users.org/lists/lua-l/2009-02/msg00404.html) that implied that a
de-facto standard can only come from a Lua author.
    

But the authors themselves would never make such a claim.

It's more a symptom of people wanting there to be standards so that
there is less energy spent on choices.
  

Understood.

What more concerns me is that there's a lot of overlap.  lfs does its
job, but then why must luaex and lposix then duplicate functionality
found in that library? It confuses matters.  Where luaex shines is
process creation and control, it should probably stick to that.
  

That's just it.  lfs works for some people, but I have performance/personal preference issues with it:

* lfs.dir() returns the filename.  If I want stat information, I have to ask for it separately.  It is true this is nice and quick on Linux file systems, but on Windows, it is much slower than using FindFirstFile/FindNextFile directly.  Those APIs provide the stat information as they go.  The Windows Git guys have been working on this exact issue.
* lfs.mkdir() only creates the directory if all parent directories are created first.  I prefer a directory creation function I call to do everything needed to fully create the directory I ask for.
* lfs.rmdir() removes a directory only if there are no more files or directories in it.  I asked for the directory to be removed, and so I expect it to fully remove it.
* lfs is missing various useful functions like access() or chmod().

lua-ex handles some of my needs pretty well, but there has been no further development on it for a while now.  It is these kinds of reasons that forks happen.  I have one fork.  I expect there are others.

What is to be done?  I'm really not sure.  For me, I'll be putting all of LuaPlus and the modules in the distribution up on GitHub soon.  That may make them more accessible to others to clone and patch, making their changes more visible, too.  It doesn't ultimately solve the problem of forking because of reasons A, B, or C, but on a social code networking site like GitHub, perhaps the forks won't get "lost".

Josh