[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [SUGGESTION] Some lfs functionality in os library, please!
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Thu, 8 Sep 2016 00:25:01 +0100
2016-09-07 16:23 GMT+01:00 Paul Moore <p.f.moore@gmail.com>:
> Looking at the OP's first suggestion, does lfs.dir correctly handle a
> directory containing a filename that's not encodable in the current
> codepage on Windows? Sure it's (to an extent) a specialist case, but
> it matters a lot to some applications.
No, but the same problem applies to io.open. That's why I patch both
Lua [1] and LFS [2] in my Windows builds [3].
[1] https://bitbucket.org/doub/canopywater/src/tip/srcweb/lua-5.3.1/patches/
[2] https://bitbucket.org/doub/canopywater/src/tip/srcweb/luafilesystem-1.6.3/patches/
[3] http://piratery.net/lua/downloads/
Shameless plugs aside, I don't think Lua needs more stuff in the base
libs. Lua is maintained by a few guys on their spare time. Seeing how
releases are already quite infrequent, I don't think burdening them
with more stuff to maintain instead of improving and evolving the core
would benefit anyone.
The standard libs are already quite sufficient for a very common set
of use cases (manipulation of text files), and serve as an example of
good practices for people that want to expand that. I personnally do
everything in Lua, from MCU firmware to 3D rendering to build
scripting (and more). It takes a bit of effort, but all you really
need is to know C, and it gets easier and easier as your toolbox
expands.