# LuaDEAL - Lua DEad Alive Libraries

68 messages
1234
Open this post in threaded view
|

## LuaDEAL - Lua DEad Alive Libraries

Open this post in threaded view
|

## Re: LuaDEAL - Lua DEad Alive Libraries

Open this post in threaded view
|

## Re: LuaDEAL - Lua DEad Alive Libraries

 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 kindof ranking of the most used gems in the community. The main featurewas the ability to explicitly endorse some rocks, so that you couldfind out the most endorsed rock for a given category. It was kind ofmerged 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 thoseissues, but it went nowhere...Eventually I think what proved to work best so far is the Luadistributions approach, where someone curates a list of librariesand maintains a coherent whole, separate from upstream projectslike 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.
Open this post in threaded view
|

## Re: LuaDEAL - Lua DEad Alive Libraries

 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>
Open this post in threaded view
|

## Re: LuaDEAL - Lua DEad Alive Libraries

Open this post in threaded view
|

## Re: LuaDEAL - Lua DEad Alive Libraries

 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
Open this post in threaded view
|

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

Open this post in threaded view
|

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

Open this post in threaded view
|

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

 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.
Open this post in threaded view
|

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

 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.
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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.
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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.