LuaDEAL - Lua DEad Alive Libraries

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

LuaDEAL - Lua DEad Alive Libraries

Rodrigo Azevedo
Motivated by recent discussions about standard libraries and codes, I have the following considerations:

The main problem to be addressed is not a set of 'blessed' libraries by Lua Team, but instead one repository of codes that the COMMUNITY TRUST, USE, IMPROVE and HELP to increase.  It means, when someone on this list asks about a library, everybody must agree on a first default answer. Public libraries are blessed by the community, not a specific restricted set of people.

Reasoning. Lua community, at least on this list, is obviously well versed in programming/IT/CS which naturally leads to "I can write my 'best' library myself that do what I want in my way", and that's exactly the main problem. We can do it, but public libraries are useful exactly for ones that can't or don't want to write their own 'best' whatever. The ego of 'I can do it better' must be superimposed by 'it is enough for most of them'. "THEM", not "me".

Then, I propose the following project:

LuaDEAL - Lua DEad Alive Libraries
Lua Modules

They're not aimed to be "the best," most powerful codes, but something useful enough for someone doesn't need to reimplement the wheel again. They must have a well defined and stable "Lua-ish" API. Documentation is mandatory.

A) Composed mainly of categories:
  Tomb1 - Lua-only libraries and codes
  Tomb2 - Wrapper from well-established C libraries.
  Tomb3 - Lua-only C libraries

B) The design must follow the philosophy of minimalist, modular software:
  0) Open, community-based, development. MIT license whenever possible.
  1) Lua's "mechanisms instead of policies," whenever possible.
  2) They must do only one thing and do it well. The aim is to do a trivial job.
  3) They must be as independent as possible but work very well together.
  If you are wondering about examples, think about Lua itself and its standard library as well as lhf libraries.

C) Code Standards
   1) Follow semantic versioning.
   2) No use of globals, never, anywhere.
   3) Standard headers for different modules.
   3.1) Name of the module
   3.2) Date of module creation
   3.3) Author of the module
   3.4) Modification history
   3.5) Synopsis of the module about what the module does
   3.6) Different functions supported in the module along with their input-output parameters
   4) Exported API must follow the existing Lua names and design conventions.
   5) Must work flawlessly on recent versions of Linux/Mac/Windows if the underlying necessary libraries are present.

If only a subset of the readers of the list really commits to public libraries, it means, codes for other ones use, I'm sure that a set of standard modules could be available for the community still this year. It obviously will require the rework os many wheels, fortunately to they R.I.P. on the repository for a long time. Public libraries are an exercise of detachment.

Best,
Rodrigo


Reply | Threaded
Open this post in threaded view
|

Re: LuaDEAL - Lua DEad Alive Libraries

Pierre Chapuis
There have been a lot of attempts to solve that issue in the past.

The "blessed subset of libraries" never worked for many reasons.

Kepler Project worked for a while, but died for lack of funding.

At some point I created Lua Toolbox [1] to at least have some kind
of ranking of the most used gems in the community. The main feature
was the ability to explicitly endorse some rocks, so that you could
find out the most endorsed rock for a given category. It was kind of
merged into LuaRocks but I feel like it isn't really usable anymore.

There was also a plan to create a Lua Foundation to deal with those
issues, but it went nowhere...

Eventually I think what proved to work best so far is the Lua
distributions approach, where someone curates a list of libraries
and maintains a coherent whole, separate from upstream projects
like Linux distributions do.


-- 
Pierre Chapuis


On Mon, Jan 20, 2020, at 10:41, Rodrigo Azevedo wrote:
Motivated by recent discussions about standard libraries and codes, I have the following considerations:

The main problem to be addressed is not a set of 'blessed' libraries by Lua Team, but instead one repository of codes that the COMMUNITY TRUST, USE, IMPROVE and HELP to increase.  It means, when someone on this list asks about a library, everybody must agree on a first default answer. Public libraries are blessed by the community, not a specific restricted set of people.

Reasoning. Lua community, at least on this list, is obviously well versed in programming/IT/CS which naturally leads to "I can write my 'best' library myself that do what I want in my way", and that's exactly the main problem. We can do it, but public libraries are useful exactly for ones that can't or don't want to write their own 'best' whatever. The ego of 'I can do it better' must be superimposed by 'it is enough for most of them'. "THEM", not "me".

Then, I propose the following project:

LuaDEAL - Lua DEad Alive Libraries
Lua Modules

They're not aimed to be "the best," most powerful codes, but something useful enough for someone doesn't need to reimplement the wheel again. They must have a well defined and stable "Lua-ish" API. Documentation is mandatory.

A) Composed mainly of categories:
  Tomb1 - Lua-only libraries and codes
  Tomb2 - Wrapper from well-established C libraries.
  Tomb3 - Lua-only C libraries


B) The design must follow the philosophy of minimalist, modular software:
  0) Open, community-based, development. MIT license whenever possible.
  1) Lua's "mechanisms instead of policies," whenever possible.
  2) They must do only one thing and do it well. The aim is to do a trivial job.
  3) They must be as independent as possible but work very well together.
  If you are wondering about examples, think about Lua itself and its standard library as well as lhf libraries.

C) Code Standards
   1) Follow semantic versioning.
   2) No use of globals, never, anywhere.
   3) Standard headers for different modules.
   3.1) Name of the module
   3.2) Date of module creation
   3.3) Author of the module
   3.4) Modification history
   3.5) Synopsis of the module about what the module does
   3.6) Different functions supported in the module along with their input-output parameters
   4) Exported API must follow the existing Lua names and design conventions.
   5) Must work flawlessly on recent versions of Linux/Mac/Windows if the underlying necessary libraries are present.

If only a subset of the readers of the list really commits to public libraries, it means, codes for other ones use, I'm sure that a set of standard modules could be available for the community still this year. It obviously will require the rework os many wheels, fortunately to they R.I.P. on the repository for a long time. Public libraries are an exercise of detachment.

Best,
Rodrigo



Reply | Threaded
Open this post in threaded view
|

Re: LuaDEAL - Lua DEad Alive Libraries

Dibyendu Majumdar


On Mon, 20 Jan 2020, 10:20 Pierre Chapuis, <[hidden email]> wrote:
There have been a lot of attempts to solve that issue in the past.

The "blessed subset of libraries" never worked for many reasons.

Kepler Project worked for a while, but died for lack of funding.

At some point I created Lua Toolbox [1] to at least have some kind
of ranking of the most used gems in the community. The main feature
was the ability to explicitly endorse some rocks, so that you could
find out the most endorsed rock for a given category. It was kind of
merged into LuaRocks but I feel like it isn't really usable anymore.

There was also a plan to create a Lua Foundation to deal with those
issues, but it went nowhere...

Eventually I think what proved to work best so far is the Lua
distributions approach, where someone curates a list of libraries
and maintains a coherent whole, separate from upstream projects
like Linux distributions do.

I agree that this may be the only workable solution. But Lua presents some challenges for the would be distributor mainly because of the incompatibilities between various Lua versions. I find maintaining even a single Lua version is a lot of work especially if there are issues you need to fix in upstream projects. 
Reply | Threaded
Open this post in threaded view
|

Re: LuaDEAL - Lua DEad Alive Libraries

Lorenzo Donati-3
In reply to this post by Pierre Chapuis
On 20/01/2020 11:19, Pierre Chapuis wrote:
> There have been a lot of attempts to solve that issue in the past.
>

Yep! And yet sadly none really worked out.

> The "blessed subset of libraries" never worked for many reasons.
>
> Kepler Project worked for a while, but died for lack of funding.
>

Was there ever a project officially "blessed" by Lua Team? Was Kepler
project actually "blessed"? I think it was already dead when I joined
lua-l so I can't remember.


> At some point I created Lua Toolbox [1] to at least have some kind
> of ranking of the most used gems in the community. The main feature
> was the ability to explicitly endorse some rocks, so that you could
> find out the most endorsed rock for a given category. It was kind of
> merged into LuaRocks but I feel like it isn't really usable anymore.
>
> There was also a plan to create a Lua Foundation to deal with those
> issues, but it went nowhere...
>

I missed that attempt on lua-l (was it before Kepler went down?).

Anyway that would be the right thing to do, if Lua team agreed and
participated with their blessing and initial guidance.

BTW, a well organized foundation, with formal endorsement, could have
some advantage at collecting funds to foster the projects and guarantee
their long term support.

The complete lack of policy, which is a stake of Lua development,
doesn't really sit well when projects becomes huge and global.

> Eventually I think what proved to work best so far is the Lua
> distributions approach, where someone curates a list of libraries
> and maintains a coherent whole, separate from upstream projects
> like Linux distributions do.

Sadly this won't solve the basic problem: an unified, cross-platform
(Windows included) set of libraries whose behavior is the same on all
systems (bar system-specific subsets).

For that some kind of "mandated/blessed" API specifications would be needed.

I'm not proposing some sort of "design by committee" approach, but there
is some middle ground between that and "everyone rolls their own"
current approach.

But again, with no formal endorsement from Lua team, every effort will
die off quickly. As it has done at least an half dozen times in the past.

>
> [1] https://lua-toolbox.com
>


Reply | Threaded
Open this post in threaded view
|

Re: LuaDEAL - Lua DEad Alive Libraries

Dennis Fischer
In reply to this post by Rodrigo Azevedo
In general I agree with the idea, but I see a big problem:

Lua simply lacks a unified community mindset as many other languages
have. From what I've seen, I see a few large groups that most Lua users
can broadly be categorized into:

1. Uninterested scripters: That is, people who don't care about Lua or
its more complex features. Usually there are either Developers that have
found their language and are happy with it, and only use Lua to script
certain programs and therefore don't care much for the state of the
language, and users that are new to programming that have to use Lua
because some application (in most cases games or game engines) happen to
be scripted in it. This second subgroup seems to have a strong tendency
towards cargo cult programming and many would rather have code written
for them and want to get by with the absolute minimum of understanding.

    1.1 Python scripters. This group can safely be ignored without side
effects. /s

2. Hermit programmers who use Lua, but otherwise don't really interact
much with the community. I don't think anybody really interacts with the
entire Lua commumnity, considering how spread out it is, but some people
just have a particularly small interest in it.

3. Lua enthusiasts that see something special in the language and prefer
using it to many if not all of the alternatives and who enjoy exchanging
thoughts on the language. This probably applies to most people in this list.

4. Developers that have chosen Lua for one or several projects, not
necessarily because they particularly like it, but because they've
considered the options and Lua was just the best suited option for the
given project. I would assume most people in the previous group have
gone through (or are still part of) this group.

So to me the main problem seems to be that it's mostly the third group
that is most likely to contribute code to the community, as they're the
only users that have any sort of personal interest in the growth of the
Lua ecosystem as a whole. And going by reddit, discord and
stackoverflow, they're the smallest but most active part of the
community. It doesn't happen often that someone who always just wanted
to build something in roblox ends up helping newcomers with problems
that they've also faced in the past; usually it's the same few users,
who've never touched roblox even once, who end up trying their best to
get the problem solved.

So, with that being the problem, how could it be solved?

In a perfect world, we'd just win over more people into the third group
by showing the everyone how nice Lua is and why it's better than
whatever they're using, but that's just not very realistic. If we want
more of the third group, we first need more of the fourth group, but
what we're getting is mostly the first group.

So the alternative would be to somehow capture more of the users that
really only pick up Lua for some very specific task. The problem with
this is that, sadly, many Lua APIs are just trash. There's a world of
globals, ad-hoc code and poorly translated pythonisms out there, and not
many examples of idiomatic, well-designed APIs to offset it all.

This leaves us with one very sad conclusion: No help is coming. There
won't be any reinforcements.

So then the question is, are there enough of us with enough know-how,
time and motivation to really build a broad set of libraries that cover
about as much ground as the ruby STL *and* at least a few unique
features so Lua isn't just on the same level, but actually goes beyond
its alternatives, at least in one domain, but ideally in quite a few?

Those are my thoughts anyway. I've tried organizing it a bit, but it's
still somewhat /stream of consciousness-/esque.

On 20/01/2020 10:41, Rodrigo Azevedo wrote:

> Motivated by recent discussions about standard libraries and codes, I
> have the following considerations:
>
> The main problem to be addressed is not a set of 'blessed' libraries
> by Lua Team, but instead one repository of codes that the COMMUNITY
> TRUST, USE, IMPROVE and HELP to increase.  It means, when someone on
> this list asks about a library, everybody must agree on a first
> default answer. Public libraries are blessed by the community, not a
> specific restricted set of people.
>
> Reasoning. Lua community, at least on this list, is obviously well
> versed in programming/IT/CS which naturally leads to "I can write my
> 'best' library myself that do what I want in my way", and that's
> exactly the main problem. We can do it, but public libraries are
> useful exactly for ones that can't or don't want to write their own
> 'best' whatever. The ego of 'I can do it better' must be superimposed
> by 'it is enough for most of them'. "THEM", not "me".
>
> Then, I propose the following project:
>
> LuaDEAL - Lua DEad Alive Libraries
> Lua Modules
>
> They're not aimed to be "the best," most powerful codes, but something
> useful enough for someone doesn't need to reimplement the wheel again.
> They must have a well defined and stable "Lua-ish" API. Documentation
> is mandatory.
>
> A) Composed mainly of categories:
>   Tomb1 - Lua-only libraries and codes
>   Tomb2 - Wrapper from well-established C libraries.
>   Tomb3 - Lua-only C libraries
>
> B) The design must follow the philosophy of minimalist, modular software:
>   0) Open, community-based, development. MIT license whenever possible.
>   1) Lua's "mechanisms instead of policies," whenever possible.
>   2) They must do only one thing and do it well. The aim is to do a
> trivial job.
>   3) They must be as independent as possible but work very well together.
>   If you are wondering about examples, think about Lua itself and its
> standard library as well as lhf libraries.
>
> C) Code Standards
>    1) Follow semantic versioning.
>    2) No use of globals, never, anywhere.
>    3) Standard headers for different modules.
>    3.1) Name of the module
>    3.2) Date of module creation
>    3.3) Author of the module
>    3.4) Modification history
>    3.5) Synopsis of the module about what the module does
>    3.6) Different functions supported in the module along with their
> input-output parameters
>    4) Exported API must follow the existing Lua names and design
> conventions.
>    5) Must work flawlessly on recent versions of Linux/Mac/Windows if
> the underlying necessary libraries are present.
>
> If only a subset of the readers of the list really commits to public
> libraries, it means, codes for other ones use, I'm sure that a set of
> standard modules could be available for the community still this year.
> It obviously will require the rework os many wheels, fortunately to
> they R.I.P. on the repository for a long time. Public libraries are an
> exercise of detachment.
>
> Best,
> Rodrigo
>
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LuaDEAL - Lua DEad Alive Libraries

Sean Conner
In reply to this post by Rodrigo Azevedo
It was thus said that the Great Rodrigo Azevedo once stated:
> Then, I propose the following project:
>
> LuaDEAL - Lua DEad Alive Libraries

  Horrible name for naming a project to keep Lua alive.  I could possibly
get behind a project for a Lua Unified API (LUA).  

> If only a subset of the readers of the list really commits to public
> libraries, it means, codes for other ones use,

  But the question is---isn't this already provided by LuaRocks?  There's
already roughly 2,500 modules listed there.

> I'm sure that a set of
> standard modules could be available for the community still this year. It
> obviously will require the rework os many wheels, fortunately to they
> R.I.P. on the repository for a long time. Public libraries are an exercise
> of detachment.

  So ... any ideas for a standard API for a particular module?

  -spc

Reply | Threaded
Open this post in threaded view
|

A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
In reply to this post by Lorenzo Donati-3
It was thus said that the Great Lorenzo Donati once stated:
>
> Sadly this won't solve the basic problem: an unified, cross-platform
> (Windows included) set of libraries whose behavior is the same on all
> systems (bar system-specific subsets).
>
> For that some kind of "mandated/blessed" API specifications would be needed.

  Okay, let's see if the community can just come together to define the
minimum viable module for directory functions.  I'm looking at three
different modules that implement such functionality, LuaFileSystem, luaposix
and my own org.conman.fsys module.

  LuaFileSystem and luaposix are largely compatible---for instance, both
have rmdir(), and they both return the same information:

        happy path: 0
        sad path: nil,"error string",err_integer

  This mimics the Lua file API.  I'm not happy with that, so when I wrote my
own, I did:

        happy path: true,0
        sad path: false,err_integer

  My thoughts for returning an error number instead of a string is that the
number is easier for error handling and if I want to print out a string, I
can use a wrapper for strerror() at that point.  But aside from error
reporting, all three APIs are similar enough to get a feel for what might
make the minimum library.  Here's what I have so far (excluding the error
reporting):

        okay = mkdir(name)

                Make Directory, name is a string, okay is non nil on
                success, nil on error, with additional error reporting TBD.

                NOTE: luaposix is missing this function

        okay = rmdir(name)
               
                Remove Directory, name is a string, okay is non nil on
                success, nil on error, with additional error reporting TBD.

        okay = getcwd()

                Get Current Working Directory, returns the current working
                directory, nil on error, other error reporting TBD.

        okay = setcwd(name)

                Set Current Working Directory, takes a directory name, and
                tries to set it as the current directory.  Returns non-nil
                on success, nil on error, other error reporting TBD.

        cat = list([name])

                Obtain a list of files in the given directory; if not given,
                use the current working directory.  Return an array of
                names, or nil on error (error reporting TBD).

                NOTE: The ordering of entries is unspecified.
                        None of modules I've listed have this specific
                        functionality.

        cat = expand(glob)

                Obtain a list of files per the passed in file glob
                (for example, "*.c").  Return an array of names, or nil
                on error (error reporting TBD).

                NOTE: The ordering of entries is unspecified.
                        LuaFilesystem is missing this function.

        fun,state,var = glist([name])

                Returns an interator (function, state, var) for use in a for
                statement.  Each time the function is called, a new filename
                is returned.

                NOTE: The ordering of entries is unspecified.
                        All three modules have this function, although
                        it's called files() under luaposix.

        fun,state,var = gexpand(glob)

                Returns an interator (function, state, var) for use in a for
                statement.  Each time the function is called, a new filename
                matching the file glob is returned.

                NOTE: The ordering of entries is unspecified.
                        Only org.conman.org has this functionaltiy.

        file = filename(name)

                Return a base filename.  name is a string of a filename, and
                upon return, all directory information is removed.

                Example: foo/bar/baz.x
                return baz.x

                NOTE: Only org.conman.fsys has this function.

        dir = dirname(name)

                Return the directory part of a filename.  name is a string
                of a filename, and upon return, the filename portion is
                removed.

                Example: foo/bar/baz.x
                return foo/bar

                Note: Only org.conman.fsys has this function.

                        The semantics of filename() and dirname() here
                        differ from the POSIX functions basename() and
                        dirname().

                        dirname() and filename() can work in
                        conjuction with each other:

                        path        = "c:\sample\path\to\file"
                        dir         = dirname(path)
                        file        = filename(path)
                        constructed = dir .. "/" .. file
                        assert(constructed == path)

  And that's it.  Additional information about files (like timestamps, size,
type) is not in the scope for this module---this is just about directory
manipulation.  Now imaging having to go through all this for other possible
batteries, like additional file operations, network API, events, etc.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Albert Krewinkel
Sean Conner writes:

> It was thus said that the Great Lorenzo Donati once stated:
>>
>> Sadly this won't solve the basic problem: an unified, cross-platform
>> (Windows included) set of libraries whose behavior is the same on all
>> systems (bar system-specific subsets).
>>
>> For that some kind of "mandated/blessed" API specifications would be needed.

I'd like to add another dimension to that. We are using Lua in pandoc,
a document converter written in Haskell, and the experience made me
really appreciate Lua's beauty and elegance. I

A lot of interesting functionality, like file system access, is already
included in pandoc via some Haskell library. So we expose those library
functions to Lua instead of adding additional libraries. Filesystem
example: <https://github.com/hslua/hslua-module-system>. A standardized
API, as proposed above, would be a great. It would leave us with the
freedom to implement APIs in our own, Haskell-focused way, while
allowing users to swap-out compatible libraries.

>   Okay, let's see if the community can just come together to define the
> minimum viable module for directory functions.  I'm looking at three
> different modules that implement such functionality, LuaFileSystem, luaposix
> and my own org.conman.fsys module.

I agree, that's awfully hard. Taking inspiration from other language
communitites: The Haskell community has a [Core Library Committee] which
decides about changes to the "base" package. The process may not be
perfect, but seems to work remarkably well.

Maybe something similar could be done for Lua?

Cheers,
 Albert

[Core Library Committee]: https://wiki.haskell.org/Core_Libraries_Committee


>   LuaFileSystem and luaposix are largely compatible---for instance, both
> have rmdir(), and they both return the same information:
>
> happy path: 0
> sad path: nil,"error string",err_integer
>
>   This mimics the Lua file API.  I'm not happy with that, so when I wrote my
> own, I did:
>
> happy path: true,0
> sad path: false,err_integer
>
>   My thoughts for returning an error number instead of a string is that the
> number is easier for error handling and if I want to print out a string, I
> can use a wrapper for strerror() at that point.  But aside from error
> reporting, all three APIs are similar enough to get a feel for what might
> make the minimum library.  Here's what I have so far (excluding the error
> reporting):
>
> okay = mkdir(name)
>
> Make Directory, name is a string, okay is non nil on
> success, nil on error, with additional error reporting TBD.
>
> NOTE: luaposix is missing this function
>
> okay = rmdir(name)
>
> Remove Directory, name is a string, okay is non nil on
> success, nil on error, with additional error reporting TBD.
>
> okay = getcwd()
>
> Get Current Working Directory, returns the current working
> directory, nil on error, other error reporting TBD.
>
> okay = setcwd(name)
>
> Set Current Working Directory, takes a directory name, and
> tries to set it as the current directory.  Returns non-nil
> on success, nil on error, other error reporting TBD.
>
> cat = list([name])
>
> Obtain a list of files in the given directory; if not given,
> use the current working directory.  Return an array of
> names, or nil on error (error reporting TBD).
>
> NOTE: The ordering of entries is unspecified.
> None of modules I've listed have this specific
> functionality.
>
> cat = expand(glob)
>
> Obtain a list of files per the passed in file glob
> (for example, "*.c").  Return an array of names, or nil
> on error (error reporting TBD).
>
> NOTE: The ordering of entries is unspecified.
> LuaFilesystem is missing this function.
>
> fun,state,var = glist([name])
>
> Returns an interator (function, state, var) for use in a for
> statement.  Each time the function is called, a new filename
> is returned.
>
> NOTE: The ordering of entries is unspecified.
> All three modules have this function, although
> it's called files() under luaposix.
>
> fun,state,var = gexpand(glob)
>
> Returns an interator (function, state, var) for use in a for
> statement.  Each time the function is called, a new filename
> matching the file glob is returned.
>
> NOTE: The ordering of entries is unspecified.
> Only org.conman.org has this functionaltiy.
>
> file = filename(name)
>
> Return a base filename.  name is a string of a filename, and
> upon return, all directory information is removed.
>
> Example: foo/bar/baz.x
> return baz.x
>
> NOTE: Only org.conman.fsys has this function.
>
> dir = dirname(name)
>
> Return the directory part of a filename.  name is a string
> of a filename, and upon return, the filename portion is
> removed.
>
> Example: foo/bar/baz.x
> return foo/bar
>
> Note: Only org.conman.fsys has this function.
>
> The semantics of filename() and dirname() here
> differ from the POSIX functions basename() and
> dirname().
>
> dirname() and filename() can work in
> conjuction with each other:
>
> path        = "c:\sample\path\to\file"
> dir         = dirname(path)
> file        = filename(path)
> constructed = dir .. "/" .. file
> assert(constructed == path)
>
>   And that's it.  Additional information about files (like timestamps, size,
> type) is not in the scope for this module---this is just about directory
> manipulation.  Now imaging having to go through all this for other possible
> batteries, like additional file operations, network API, events, etc.
>
>   -spc


--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Xavier Wang
In reply to this post by Sean Conner
Sean Conner <[hidden email]> 于2020年1月21日周二 下午1:38写道:

>
> It was thus said that the Great Lorenzo Donati once stated:
> >
> > Sadly this won't solve the basic problem: an unified, cross-platform
> > (Windows included) set of libraries whose behavior is the same on all
> > systems (bar system-specific subsets).
> >
> > For that some kind of "mandated/blessed" API specifications would be needed.
>
>   Okay, let's see if the community can just come together to define the
> minimum viable module for directory functions.  I'm looking at three
> different modules that implement such functionality, LuaFileSystem, luaposix
> and my own org.conman.fsys module.
>
>   LuaFileSystem and luaposix are largely compatible---for instance, both
> have rmdir(), and they both return the same information:
>
>         happy path:     0
>         sad path:       nil,"error string",err_integer
>
>   This mimics the Lua file API.  I'm not happy with that, so when I wrote my
> own, I did:
>
>         happy path:     true,0
>         sad path:       false,err_integer
>
>   My thoughts for returning an error number instead of a string is that the
> number is easier for error handling and if I want to print out a string, I
> can use a wrapper for strerror() at that point.  But aside from error
> reporting, all three APIs are similar enough to get a feel for what might
> make the minimum library.  Here's what I have so far (excluding the error
> reporting):
>
I have my own module for directory functions[1], and I found that if
you want cross platform native directory operations, you can not
always get errno. Windows has its own routines and error codes for
that.

I'm planing a new module named lua-pathlib for compatible with the
Python pathlib module, it offers a OO interface for paths. I will try
to implement in my Chinese Festival holiday and release later.

[1]: https://github.com/starwing/lpath

--
regards,
Xavier Wang.

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Jerome Vuarand
In reply to this post by Sean Conner
On Tue, 21 Jan 2020 at 05:38, Sean Conner <[hidden email]> wrote:

>   Okay, let's see if the community can just come together to define the
> minimum viable module for directory functions.  I'm looking at three
> different modules that implement such functionality, LuaFileSystem, luaposix
> and my own org.conman.fsys module.
>
> [...]
>
>         okay = mkdir(name)
>         okay = rmdir(name)
>         okay = getcwd()
>         okay = setcwd(name)
>         cat = list([name])
>         cat = expand(glob)
>         fun,state,var = glist([name])
>         fun,state,var = gexpand(glob)
>         file = filename(name)
>         dir = dirname(name)
>
>   And that's it.  Additional information about files (like timestamps, size,
> type) is not in the scope for this module---this is just about directory
> manipulation.  Now imaging having to go through all this for other possible
> batteries, like additional file operations, network API, events, etc.

A couple obvious omissions (to me) are a way to test if a
file/directory exists (io.open might work on files, does it work
portably on directories?), and a way to tell if a filename is a
regular file, a directory (or something else). It could be a combined
fs.type that says nil (doesn't exist), "file", "directory", or
"other". I usually use lfs.attributes(path, 'mode') for these.

And on the other hand expand, gexpand, filename and dirname feel
redundant. I can see how they can be useful (I'd probably use them),
but that's basic string manipulation which Lua already excels at.

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
In reply to this post by Xavier Wang
It was thus said that the Great Xavier Wang once stated:

> Sean Conner <[hidden email]> 于2020年1月21日周二 下午1:38写道:
> >
> >   My thoughts for returning an error number instead of a string is that the
> > number is easier for error handling and if I want to print out a string, I
> > can use a wrapper for strerror() at that point.  But aside from error
> > reporting, all three APIs are similar enough to get a feel for what might
> > make the minimum library.  Here's what I have so far (excluding the error
> > reporting):
>
> I have my own module for directory functions[1], and I found that if
> you want cross platform native directory operations, you can not
> always get errno. Windows has its own routines and error codes for
> that.

  The intent was to provide a API (and/or library) for the minimal
"batteries included" for Lua, but I can see this might be an uphill battle
(nothing terribly surprising there).

  As for Windows, I'm not specifically looking to return errno (it *is*
defined for C, and there are a few C functions that do set it) but some
error number for error handling.  The string is handy if all you want to do
is just print a message but if you want to do something based upon the type
of error, some numeric value is the best way to handle that.  In fact, I
don't think I even mentioned errno at all.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
In reply to this post by Jerome Vuarand
It was thus said that the Great Jerome Vuarand once stated:

> On Tue, 21 Jan 2020 at 05:38, Sean Conner <[hidden email]> wrote:
> >   Okay, let's see if the community can just come together to define the
> > minimum viable module for directory functions.  I'm looking at three
> > different modules that implement such functionality, LuaFileSystem, luaposix
> > and my own org.conman.fsys module.
> >
> > [...]
> >
> >         okay = mkdir(name)
> >         okay = rmdir(name)
> >         okay = getcwd()
> >         okay = setcwd(name)
> >         cat = list([name])
> >         cat = expand(glob)
> >         fun,state,var = glist([name])
> >         fun,state,var = gexpand(glob)
> >         file = filename(name)
> >         dir = dirname(name)
> >
> >   And that's it.  Additional information about files (like timestamps, size,
> > type) is not in the scope for this module---this is just about directory
> > manipulation.  Now imaging having to go through all this for other possible
> > batteries, like additional file operations, network API, events, etc.
>
> A couple obvious omissions (to me) are a way to test if a
> file/directory exists (io.open might work on files, does it work
> portably on directories?), and a way to tell if a filename is a
> regular file, a directory (or something else). It could be a combined
> fs.type that says nil (doesn't exist), "file", "directory", or
> "other". I usually use lfs.attributes(path, 'mode') for these.

  I was thinking about that, and I initially had a function like that, but
as I was writing it, I felt that was more a "file" type operation.
Afterwards, I realized I needed such a function.  My proposal is:

        info = status(name)

                Returns a table (or nil on error) with the following fields:

                        * name - name of file (not really needed, but nice to have)
                        * type - string
                                        'file'
                                        'directory'
                                        some other system specific type
                        * size - integer, size of file
                        * time - timestamp on file

> And on the other hand expand, gexpand, filename and dirname feel
> redundant.

  Yes, you really only need one of expand (returns a table) or gexpand
(returns an interator).  The same with list and glist.  I included both but
if I were to remove one, I'd remove the ones that return a table.  You can
construct a table from the interator (both of which don't create Lua
tables).

> I can see how they can be useful (I'd probably use them),
> but that's basic string manipulation which Lua already excels at.

  filename() and dirname() do complimentary things---if you want a filename
from a path, filename() provides a way to do it without having to know
details; same with getting a directory name from a pathname.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

nobody
In reply to this post by Sean Conner
On 21/01/2020 06.38, Sean Conner wrote:

> Okay, let's see if the community can just come together to define the
> minimum viable module for directory functions. […]
>
> cat = list([name])
>
> Obtain a list of files in the given directory; if not given,
> use the current working directory.  Return an array of
> names, or nil on error (error reporting TBD).
>
> NOTE: The ordering of entries is unspecified.
> None of modules I've listed have this specific
> functionality.
>
> fun,state,var = glist([name])
>
> Returns an interator (function, state, var) for use in a for
> statement.  Each time the function is called, a new filename
> is returned.
>
> NOTE: The ordering of entries is unspecified.
> All three modules have this function, although
> it's called files() under luaposix.

What should happen with '.' and '..'?

Should they be excluded?  This would potentially (extremely rarely)
cause confusion on file systems which lack one and/or(?) the other when
someone blindly assumes that they exist.

Or should they be included, leading to fun for/if layers everywhere
(>99.999…%) (or custom ad-hoc wrapper functions) because you don't want
them when doing… practically everything?  (I guess that's also a fun
learning experience for beginners of all proficiencies everywhere, when
they're first trying to do a recursive traversal…)

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
It was thus said that the Great nobody once stated:

> On 21/01/2020 06.38, Sean Conner wrote:
> >Okay, let's see if the community can just come together to define the
> >minimum viable module for directory functions. […]
> >
> > cat = list([name])
> >
> > Obtain a list of files in the given directory; if not given,
> > use the current working directory.  Return an array of
> > names, or nil on error (error reporting TBD).
> >
> > NOTE: The ordering of entries is unspecified.
> > None of modules I've listed have this specific
> > functionality.
> >
> > fun,state,var = glist([name])
> >
> > Returns an interator (function, state, var) for use in a for
> > statement.  Each time the function is called, a new filename
> > is returned.
> >
> > NOTE: The ordering of entries is unspecified.
> > All three modules have this function, although
> > it's called files() under luaposix.
>
> What should happen with '.' and '..'?

  Ooh, I forgot to mention that.  The parent and current directory markers
("." and ".." on POSIX systems; I think they're the same on Windows?) should
be removed.

> Should they be excluded?  

  If the concept exists for the system, yes.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Frank Kastenholz-2
In reply to this post by Sean Conner



With regard to file system finagling, path name munging, and directory foozling, I’ve found that penlight has a bunch of the functions people have been asking about and seems to be a good complement to LFS.  Off the top of my head I can’t recall ever saying “I wish they had X”

YMMV

Frank





Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
It was thus said that the Great Frank Kastenholz once stated:
>
> With regard to file system finagling, path name munging, and directory
> foozling, I’ve found that penlight has a bunch of the functions people
> have been asking about and seems to be a good complement to LFS.  Off the
> top of my head I can’t recall ever saying “I wish they had X”

  I'm looking at PenLight right now, and it uses LFS internally, plus other
functions (some of which shell out to OS commands).  The goal I'm going for
is a minimal set of useful functions that are common across as many
operating systems as possible [1].

  -spc

[1] Okay, POSIX and Windows in reality.

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
In reply to this post by Sean Conner
It was thus said that the Great Sean Conner once stated:
> It was thus said that the Great Lorenzo Donati once stated:
> >
> > For that some kind of "mandated/blessed" API specifications would be needed.
>
>   Okay, let's see if the community can just come together to define the
> minimum viable module for directory functions.

  Okay, second take.  I've looked at LuaFileSystem, LuaPosix, PenLight and
my own org.conman.fsys modules and I've come up with a set of minimal
directory functions.  I've gone ahead and decided to use the method of error
reporting that the existing Lua functions (like io.open()) use---namely,
return a falsey value, a string with the error message, and an integer
representing the error as a value.  I don't like it, but I'm going with the
majority view point here.

  Anyway, before the functions are some data fields:

        _implementation string, informational "POSIX", "Windows", etc.
        tmp             string, temporary directory name
        null            string, NULL device name
        current         string representing current directory
        parent          string representing parent directory
        pathsep         string, $PATH separator character

  For a POSIX implementation, these would be:

        _implementation = "POSIX"
        tmp             = "/tmp" -- unles $TMPDIR defined
        null            = "/dev/null"
        current       = "."
        parent          = ".."
        pathsep         = ":"

  and for Windows:

        _implementation = "Windows"
        tmp             = os.getenv("TMP") -- or $TEMP or $USERPROFILE
        null            = "NULL"
        current         = "."
        parent          = ".."
        pathsep         = ";"

  There are (some older, possibly no longer relevant) operating systems that
use different conventions for "current" and "parent" directories, thus the
decision to add those two fields.  The temp directory also changes location
from operating system to operating system, thus the addition of that field;
the same for the null device.  I decided to throw in the path separator for
$PATH as well.  The default directory separator is available as
package.config:sub(1,1) thus it is not included here.  The _implementation
field is informational only.

  And now the functions.  Items in [] are optional, and on the left side of
the '=', represents data returned in the error path.  On the right side of
the '=' it represents optional parameters.

Usage:        okay[,errs,erri] = mkdir(name)
Desc:         Make a directory
Input:        name (string) name of directory
Return:       okay (boolean) true if success, false if error
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

        ---

Usage:        okay[,errs,erri] = rmdir(name)
Desc:         Remove a directory
Input:        name (string) name of directory
Return:       okay (boolean) true if success, false if error
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

        ---

Usage:        path[,errs,erri] = getwd()
Desc:         Return the current directory
Return:       path (string) path of current working diirectory
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

        ---

Usage:        okay[,errs,erri] = setwd(name)
Desc:         Set the working directory
Input:        name (string) name of directory
Return:       okay (boolean) true if success, false if error
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

        ---

Usage:        list[,errs,erri] = list([name])
Desc:         Return a list of entries in a directory.  If no directory
              is given, return the entries in the current directory.
Input:        name (string/optional) name of directory, defaults to current diretory
Return:       list (array of string) list of filename in directory, nil on error.
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

Note:         The order of filenames is unspecified.

              The current and parent entries (if defined for a system)
              will NOT appear in the list.

        ---

Usage:        for entry in glist([name]) do ... end
Desc:         Return an iterator for traversing a directory; if not given,
              traverse the current directory.
Input:        name (string/optional) name of directory, defaults to current directory
Return:       (iterator function)
              (iterator state)
              (iterator var) (string) filename

Note:         The ordering of filenames is unspecified.

              The current and parent entries (if defined for a system)
              will NOT appear in the list.

        ---

Usage:        list[,errs,erri] = expand(pattern)
Desc:         Expand a list of filenames from a file globbing pattern
Input:        pattern (string) an operating system dependent globbing pattern
Return:       list (array) list of filename matching pattern, nil on error
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

Note:         The ordering of filenames is unspecified.

        ---

Usage:        for entry in gexpand(pattern) do ... end
Desc:         Return an iterator for traversing a file glob
Input:        pattern (string) an operating system dependent globbing pattern
Return:       (iterator function)
              (iterator state)
              (iterator var) (string) filename

Note:         The ordering of filenames is unspecified.

        ---

Usage:        file = filename(name)
Desc:         Return the file portion of a path specifier
Input:        name (string) path specifier
Return:       file (string) file portion---if none, return ""

Note:         The following sequence will produce an equivalent path:

                      dirname(path) .. DIRSEP .. filename(path)

        ---

Usage:        dir = dirname(name)
Desc:         Return the directory portion of a path specifier
Input:        name (string) path specifier
Return:       dir (string) directory portion---if none, return "" (if root) or "." (if none exists in name).

Note:         The following sequence will produce an equivilent path:

                      dirname(path) .. DIRSEP .. filename(path)

        ---

Usage:        info[,errs,erri] = status(name)
Desc:         Return information about a file or directory
Input:        name (string) name of file
Return:       info (table) info of file, nil on error
                      * name (string) filename
                      * size (integer) size of file
                      * timestamp (number) timestamp of file
                      * type (enum)
                              + 'file'
                              + 'directory'
                              + other system dependent type
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

Note:         The size field may not have meaning for directories
              the time field can be passed to os.date().

        ---

Usage:        okay[,errs,erri] = timestamp(name[,time])
Desc:         Set the timestamp on a file.
Input:        name (string) name of file
              time (number) timestamp, if not given, use current time
Return:       okay (boolean) true if okay, false if error
              errs (string/optional) error message on failure
              erri (integer/optional) error number on failure

        ---

  I've included both a 'return array' and 'iterator' version for listing the
contents of a directory and listing files per a file pattern more for
completeness than anything else---if I had to pick one version, it would be
the iterator one (think huge directories) as being more useful.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Jeff Pohlmeyer
On Jan 22, 2020 5:47 PM Sean Conner wrote:
>   Okay, second take.  I've looked at LuaFileSystem, LuaPosix, PenLight and
> my own org.conman.fsys modules and I've come up with a set of minimal
> directory functions.

Looks like a good start. A few questions...

Why call it "setwd" instead of the more conventional "chdir" ?

If info() is called on a symlink, does it return info about the link
itself, or the file the link points to?
(Maybe that could be a separate function or perhaps an optional
"aslink" boolean parameter.)

If timestamp() is called on a nonexistent file, will it attempt create
the file? (a la "touch")

It would also be nice to have a small subset of permission functions,
maybe just whether a file can be read, written, or created.

 - Jeff

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Sean Conner
It was thus said that the Great Jeff Pohlmeyer once stated:
> On Jan 22, 2020 5:47 PM Sean Conner wrote:
> >   Okay, second take.  I've looked at LuaFileSystem, LuaPosix, PenLight and
> > my own org.conman.fsys modules and I've come up with a set of minimal
> > directory functions.
>
> Looks like a good start. A few questions...
>
> Why call it "setwd" instead of the more conventional "chdir" ?

  To make it consistent with getwd().

> If info() is called on a symlink, does it return info about the link
> itself, or the file the link points to?

  What's this "symlink" you speak of?

  Okay, I know what they are, but this is meant to be a minimum support. But
to answer your question, the file it points to (POSIX supports lstat() to
return the information about the link).  I know Windows has *some* hacked
version of symlinks, but I'm not sure of the extend (MS-DOS for instance,
doesn't have symlinks, and I've seen Lua ompiled for MS-DOS).

> (Maybe that could be a separate function or perhaps an optional
> "aslink" boolean parameter.)

  What happens when a system doesn't support it?  POSIX has hardlinks (which
are different from symlinks) but Windows doesn't have that support.  What
then?

> If timestamp() is called on a nonexistent file, will it attempt create
> the file? (a la "touch")

  No.  The underlying POSIX call, utime(), does not create the file.

> It would also be nice to have a small subset of permission functions,
> maybe just whether a file can be read, written, or created.

  If you can't read a file, you can't read a file.  I know there are times
when checking first is preferred, but just the act of trying to open a file
will tell you what you need to know (and there's a race between time of
check and time of use (TOCTOU).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

Eretnek Hippi Messiás
In reply to this post by Sean Conner
hi there! :)

tldr: read the 1st and the last paragraphs only, but i labelled all of them to know what they are about.

not that much strictly related (cuz isnt about the api, but the things behind), but at least a short one:
my idea for such libs that require c, is to make an isolated groundwork, and then utilize it via both the c api and ffi, and that way both lua and luajit can use it happily.

not so important (as maybe obvious) additional thoughts to the previous stuff:
luaffi is slowly bleeding out, its not even supported in ravi anymore (ive never checked out its sauce), luajit doesnt play nicely with the c api, and i think lua would still work better with the c api, even if luaffi would be polished... on the contrary, heavy use of the c preprocessor can make the game harder for luajit, while the absence of it can probably make suboptimal codes; and also, the jit would probably like the least possible c behind more lua, so i dunno how much beneficial this could be, but basically i think that c cant really much harm the performance. the most obvious benefit is to keep the two worlds nearer, while it doesnt require to write everything twice. other than that, loaders can be hacked easily to decide between coexistent variants, as its basically a matter of modifying the search paths.

my considerations (cuz maybe im not alone with such, and i think the topic is for finding the common fund of the masses around), that are maybe just waste of ur time, and also probably destructive for the success of the ongoing topic:
i wanna support as much lua engines as possible, cuz if i wanna try something instead of just reading the sauce, when i find something cool that requires a newer lua feature, that isnt supported in luajit (my basic engine), or that is actually an another engine, then im able to use my gadgets during the observation.
(the things below may sound like a rant, but i actually had fun and laughed much while wrote them, read in that spirit!!! (just as basically always when i write anything, i already forgot how to be angry, and i forgot how to cry (thats maybe sad...) basically im just happy and cheerful on somewhat different levels :) ))
i wanted to leave myself out from this topic, as im a radical madscientist alien whatever, who would support templeos before w*ndows; just as well as i like to add weird features to very basic stuffs, in case if they are cheap and useful. like my `table.getKeys()` and `fs.listDir()` have a 2nd param, `sort`, that can be falsy, and then wont do nothing, but basically costs only a check, `true` for my basic algo, a table for changing the order of different types in my basic algo (just a matter of `type(sort)=='table' and sort or {.....}`, so its cheap), or a function to change my basic algo; and they also have `filter` and `swap` parameters, that make two tables as a result, where `swap` will swap them, and `filter` can be either a regexp for a key, a table for a set of keys, and a function to make more nasty stuffs. cuz a matter of 2 extra checks if i dont want them, cuz i could merge things that are mostly use together, and in those cases, i think they are faster, and cuz it became more simple to write and use them... this way, i have a different api (more parameters, and more return values) than probably everyone else, but i think im not alone, and this is the very reason why that common api doesnt exists. i think its a matter of making something without questions, that others will feel like they will be served well with it. (<- my best answer for the topic!!) actually such thing is required to be able to divide by zero, play music, print a car, hack nsa, do my homework, feed my cat, and also the things that others wish for. it must be an enslaved "god", that can live my life instead of me, but must be only mine, cuz otherwise others will give me back the hard times i just left behind with such power. maybe its enough to leave all these possibilities open. (bloatwares that could serve all those purposes probably cant serve them, cuz they are bloatwares, and i need to be ready for yesterday... u know... so the solution must be fast without that bloat.)
i wouldnt use penlight (just for an example of its type, and no offense, its not about its quality, but my personal needs only!), cuz it has too much very simple stuffs included, that i would exchange for 1-2 somewhat longer lines here and there, and that will be faster. with such a habit, i could include a whole bunch of overlapping, and maybe incompatible libs just to satisfy one more necessity. (thats why i laugh on those who started to mess with jquery only for getting an xhr ... have u ever seen the code base of it? i think its a mess, that can make more trouble than what it can actually pay back. (sometimesireadminifiedcodes without much pain, but im not talking about that currently, just that jq is a tangled mess in itself...)) with live-coding, im governed by the necessities and possibilities, not by covering a whole topic with everything that i "aint gonna need", while they are too much general purpose, as they wont even cover my corner cases, that will require some workaround all the time. no average person exists, just like no average necessity, and thats why the less is better to use as a fund if someone wanna express their inner chaos. :D (some ppl start a new os and a new arch out of the same feeling :D ) but yes, its still a valid thing to wish for an std lib, it really is the thing that made python, c, php, js, java, whatever successful ... cuz ppl r lazy. (pun intended :D )
uhm... lets continue the destruction some more! (sorry) u, folks, are about to find the set of functions and their io, and then u come up with things like posix stuffs, that made me think... u didnt even start to argue about naming, not to mention the camel vs snake battle, thats as sharp as the black vs white ide, just harder to switch between (dont forget to think about concatenated names here and there...) so pwd? whats that? password? fork? i know that! the thing to pick up my food with! :) https://cdn.notonthehighstreet.com/fs/59/64/abb9-74ce-432d-ac2b-1167dcaa6481/original_sneeboer-garden-fork.jpg (who cares, when i eat cakes with knife.) Szoszi? what the hell is even that? g**gle translate dont even know its real meaning... the reason was that no descriptive name can cover my aims with it, and very much general words are totally overused, while just as meaningless... but thats why its only once in my code base, and the rest has general, self-descriptive names. i hate to be puzzled on abbreviations, and when i use them (inside functions), they must be either derived from their full form (`for f in pairs(files)`) or get a comment if they are not straightforward. have u ever crouched in a dark corner and swing urself to find the perfect name for a variable? ahh, thats sad.... ever left a comment, like "find a better name"? never mind. u can also think about the overmined planetary words around lua, that mostly tells nothing about themselves, or kde, gnome, enlightenment whatever naming conventions... not to mention std lib..... (i hope its more about cures than diseases, if u know what i mean - actually related to the code base. btw, i think c++ folks get much subliminal "infection" that way.) if i were in ur shoes, i would try to align that with lua and/or try to find clear, meaningful names, but actually posix is settled and well-known, and programmers are already damned to learn infinity, even if covering different platforms could serve as a good reason to hide their wording behind just an another one, that can be either one more to learn on top of them, or one that can bring instant understanding, while experts will know by hearth whats behind them, but one more pro behind it is that u can really do anything behind ur very own names. :)

after all, my answer is to collect a bunch of talented ppl who want to make it happen, and then care only about their opinions, or make it alone (nothing personal here, but read it as a general option), enjoy the freedom, and make it useful (either even for those who wanna print a car (being able to print it, or only to make a printer can be both fine here), or just those lucky selected ones that goes to the same direction as u), and if it is useful, then ppl will pick it up. i think ppl want a stable fund of a handful of ppl behind a project to pick it up, except if it can be carried on without the original author, or if it is good as is.

bests! :)


Sent with ProtonMail Secure Email.

1234