[ANN] LuaFileSystem 1.7.0

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

[ANN] LuaFileSystem 1.7.0

Hisham
Hi list,

I am happy to announce a long-overdue new release of LuaFileSystem.
It supports Lua 5.1, 5.2 and 5.3.

LuaFileSystem is a Lua library developed to complement the set of
functions related to file systems offered by the standard Lua
distribution. LuaFileSystem offers a portable way to access the
underlying directory structure and file attributes.

https://keplerproject.github.io/luafilesystem/

The easiest way to install LuaFileSystem is to use LuaRocks:

luarocks install luafilesystem

This release contains contributions by Alex, Alexey Melnichuk, Antonin
Décimo, Hisham Muhammad, Hugh Perkins, Ignacio Burgueño, Jin Qing,
NiteHawk, Peter Melnichenko, Philipp Janda, Thijs Schreijer. A special
shout-out for Peter Melnichenko, for making this release happen!

Cheers,

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Italo Maia
Amazing news!

Em 15 de set de 2017 7:54 PM, "Hisham" <[hidden email]> escreveu:
Hi list,

I am happy to announce a long-overdue new release of LuaFileSystem.
It supports Lua 5.1, 5.2 and 5.3.

LuaFileSystem is a Lua library developed to complement the set of
functions related to file systems offered by the standard Lua
distribution. LuaFileSystem offers a portable way to access the
underlying directory structure and file attributes.

https://keplerproject.github.io/luafilesystem/

The easiest way to install LuaFileSystem is to use LuaRocks:

luarocks install luafilesystem

This release contains contributions by Alex, Alexey Melnichuk, Antonin
Décimo, Hisham Muhammad, Hugh Perkins, Ignacio Burgueño, Jin Qing,
NiteHawk, Peter Melnichenko, Philipp Janda, Thijs Schreijer. A special
shout-out for Peter Melnichenko, for making this release happen!

Cheers,

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

aryajur
Thanks for the update. The LFS_VERSION needs to be updated though in the lfs.c file. lfs._VERSION still prints LuaFileSystem 1.6.3

Milind

On Fri, Sep 15, 2017 at 3:57 PM, Italo Maia <[hidden email]> wrote:
Amazing news!

Em 15 de set de 2017 7:54 PM, "Hisham" <[hidden email]> escreveu:
Hi list,

I am happy to announce a long-overdue new release of LuaFileSystem.
It supports Lua 5.1, 5.2 and 5.3.

LuaFileSystem is a Lua library developed to complement the set of
functions related to file systems offered by the standard Lua
distribution. LuaFileSystem offers a portable way to access the
underlying directory structure and file attributes.

https://keplerproject.github.io/luafilesystem/

The easiest way to install LuaFileSystem is to use LuaRocks:

luarocks install luafilesystem

This release contains contributions by Alex, Alexey Melnichuk, Antonin
Décimo, Hisham Muhammad, Hugh Perkins, Ignacio Burgueño, Jin Qing,
NiteHawk, Peter Melnichenko, Philipp Janda, Thijs Schreijer. A special
shout-out for Peter Melnichenko, for making this release happen!

Cheers,

-- Hisham


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Hisham
On 15 September 2017 at 20:01, Milind Gupta <[hidden email]> wrote:
> Thanks for the update. The LFS_VERSION needs to be updated though in the
> lfs.c file. lfs._VERSION still prints LuaFileSystem 1.6.3

Oops! Pushed a hotfix. Thanks for the heads up!

-- Hisham

> On Fri, Sep 15, 2017 at 3:57 PM, Italo Maia <[hidden email]> wrote:
>>
>> Amazing news!
>>
>> Em 15 de set de 2017 7:54 PM, "Hisham" <[hidden email]> escreveu:
>>>
>>> Hi list,
>>>
>>> I am happy to announce a long-overdue new release of LuaFileSystem.
>>> It supports Lua 5.1, 5.2 and 5.3.
>>>
>>> LuaFileSystem is a Lua library developed to complement the set of
>>> functions related to file systems offered by the standard Lua
>>> distribution. LuaFileSystem offers a portable way to access the
>>> underlying directory structure and file attributes.
>>>
>>> https://keplerproject.github.io/luafilesystem/
>>>
>>> The easiest way to install LuaFileSystem is to use LuaRocks:
>>>
>>> luarocks install luafilesystem
>>>
>>> This release contains contributions by Alex, Alexey Melnichuk, Antonin
>>> Décimo, Hisham Muhammad, Hugh Perkins, Ignacio Burgueño, Jin Qing,
>>> NiteHawk, Peter Melnichenko, Philipp Janda, Thijs Schreijer. A special
>>> shout-out for Peter Melnichenko, for making this release happen!
>>>
>>> Cheers,
>>>
>>> -- Hisham
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Dirk Laurie-2
In reply to this post by Hisham
2017-09-16 0:53 GMT+02:00 Hisham <[hidden email]>:

> I am happy to announce a long-overdue new release of LuaFileSystem.
> It supports Lua 5.1, 5.2 and 5.3.
>
> LuaFileSystem is a Lua library developed to complement the set of
> functions related to file systems offered by the standard Lua
> distribution. LuaFileSystem offers a portable way to access the
> underlying directory structure and file attributes.

Of all the many excellent Lua modules available on LuaRocks, this is the
one whose capabilities are most urgently needed in Lua 5.4. If it would
need a caveat about system dependence, so be it: we already have that
for two existing routines in the io library.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

KHMan
On 9/16/2017 12:47 PM, Dirk Laurie wrote:

> 2017-09-16 0:53 GMT+02:00 Hisham <[hidden email]>:
>
>> I am happy to announce a long-overdue new release of LuaFileSystem.
>> It supports Lua 5.1, 5.2 and 5.3.
>>
>> LuaFileSystem is a Lua library developed to complement the set of
>> functions related to file systems offered by the standard Lua
>> distribution. LuaFileSystem offers a portable way to access the
>> underlying directory structure and file attributes.
>
> Of all the many excellent Lua modules available on LuaRocks, this is the
> one whose capabilities are most urgently needed in Lua 5.4. If it would
> need a caveat about system dependence, so be it: we already have that
> for two existing routines in the io library.

I think we should throw more code portability out of the window
for Windows. Most of the rest can use some sort of modern Unix or
POSIX standard.

On the one hand, there is a desire for this sort of full featured
filesystem library capability. On the other hand, a desire to
continue sticking to portable code will leave LuaFileSystem or any
sort of file I/O library with the usual limitations on Windows.

Bypassing legacy library calls will get us a proper feature set.
UTF-8 filenames. Bypass the MAX_PATH limitation. Those sort of things.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Russell Haley
In reply to this post by Dirk Laurie-2
Sorry for the top post.  LuaRocks is awesome and Lfs suites my needs so it makes little difference but it leaves me with questions. 

Could someone please *name* a filesystem that they use Lua on that is *not* windows or posix compliant? 

Also, I have trouble thinking that filesystem access can't be generalized enough to make it extensible. Please, educate me otherwise.

Russ
Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Dirk Laurie
Sent: Friday, September 15, 2017 11:07 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: [ANN] LuaFileSystem 1.7.0

2017-09-16 0:53 GMT+02:00 Hisham <[hidden email]>:

> I am happy to announce a long-overdue new release of LuaFileSystem.
> It supports Lua 5.1, 5.2 and 5.3.
>
> LuaFileSystem is a Lua library developed to complement the set of
> functions related to file systems offered by the standard Lua
> distribution. LuaFileSystem offers a portable way to access the
> underlying directory structure and file attributes.

Of all the many excellent Lua modules available on LuaRocks, this is the
one whose capabilities are most urgently needed in Lua 5.4. If it would
need a caveat about system dependence, so be it: we already have that
for two existing routines in the io library.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

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

> Sorry for the top post.  LuaRocks is awesome and Lfs suites my needs so it
> makes little difference but it leaves me with questions. 
>
> Could someone please *name* a filesystem that they use Lua on that is
> *not* windows or posix compliant? 

  I can name several---VMS, AmigaOS, MS-DOS 1.0, CP/M.  But ones that are
still in use?  I don't know.  I want to say that iOS and Android file access
is different, but I don't program those (I just hear the complaints at
work).  But in general, you are right, POSIX and Windows file systems cover
probably 99.44% of all computer use today.

> Also, I have trouble thinking that filesystem access can't be generalized
> enough to make it extensible. Please, educate me otherwise.

  There are semantic differences between the two that would make this ...
interesting.  Just iterating over files in a directory.  Windows (which is
based off MS-DOS---I have no Windows development experience so I'm falling
back on my MS-DOS arcana here so if the details have changed, forgive me)
has FindFirst() and FindNext().  They work on the current working directory
and it takes a pattern to look for---"*.c" or "foo.*" for example).

  POSIX has opendir() and readdir().  It will work for any directory, but it
takes no pattern---it just returns all the files in a directory in an
unspecified order.  POSIX also has a function to return all files matching a
pattern ("*.c" or "foo.*" for example) but I've found it has ... quirks
(namely, if *no* files match, it returns the original pattern!).

  The other major difference is the patterns themselves.  Yes, there are
some patterns that cross ("*.c" or "foo.*") but the pattern for "all files"
is different ("*" for POSIX, "*.*" for Windows).  Also, under Windows, the
matching is case-insesitive ("foo.*" will match "FOO.ASM" and "foo.o") while
they aren't for POSIX (but they *might* for Mac OS-X---that's a weird
system).  So there's that to watch out for.

  Then there's the path separator ("\" for Windows, "/" for POSIX, although
Windows *does* support "/" for the separator as well).  

  Okay, for a simple job of listing files in a directory, we have:

        Windows:

                directory needs to be the current working directory
                pattern matches case-insensitive
                people will use '\' out of habit
                OH!  Also, Windows returns metainformation about each file

        POSIX:
                can do any directory
                pattern matches case-sensative (maybe except for OS-X)
                people will use '/' because that's the only path separator
                OH!  POSIX only returns the name, no metainformation

  And that metainformation?  Again, some differences between the two.

  Your job, should you choose to accept it, is to figure out the semantics
of a Lua directory iterator.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Martin
On 09/16/2017 10:16 PM, Sean Conner wrote:
>   Your job, should you choose to accept it, is to figure out the semantics
> of a Lua directory iterator.
>
>   -spc
>

I'm not affiliated with LuaFileSystem project but have implemented something
similar for my own needs.
(https://github.com/martin-eden/workshop/blob/master/mechs/file_lister/get_files_list.lua)

This is two functions with same interface. Given directory name, one returns
sequence with file names, other - sequence with directory names.

They are implemented as running command like "find <dir_name> -maxdepth 1 -type
f" and processing output. So touching OS APIs may be avoided.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Russell Haley
In reply to this post by Sean Conner
On Sat, Sep 16, 2017 at 2:16 PM, Sean Conner <[hidden email]> wrote:
> It was thus said that the Great Russell Haley once stated:
>
>> Sorry for the top post.  LuaRocks is awesome and Lfs suites my needs so it
>> makes little difference but it leaves me with questions.
>>
>> Could someone please *name* a filesystem that they use Lua on that is
>> *not* windows or posix compliant?
>
>   I can name several---VMS, AmigaOS, MS-DOS 1.0, CP/M.  But ones that are
ooh, VMS, good one! Still in use and someone uses lua though?

> still in use?  I don't know.  I want to say that iOS and Android file access
> is different, but I don't program those (I just hear the complaints at
> work).  But in general, you are right, POSIX and Windows file systems cover
> probably 99.44% of all computer use today.
>
>> Also, I have trouble thinking that filesystem access can't be generalized
>> enough to make it extensible. Please, educate me otherwise.
>
>   There are semantic differences between the two that would make this ...
> interesting.  Just iterating over files in a directory.  Windows (which is
> based off MS-DOS---I have no Windows development experience so I'm falling
> back on my MS-DOS arcana here so if the details have changed, forgive me)
> has FindFirst() and FindNext().  They work on the current working directory
> and it takes a pattern to look for---"*.c" or "foo.*" for example).
>
>   POSIX has opendir() and readdir().  It will work for any directory, but it
> takes no pattern---it just returns all the files in a directory in an
> unspecified order.  POSIX also has a function to return all files matching a
> pattern ("*.c" or "foo.*" for example) but I've found it has ... quirks
> (namely, if *no* files match, it returns the original pattern!).
>
>   The other major difference is the patterns themselves.  Yes, there are
> some patterns that cross ("*.c" or "foo.*") but the pattern for "all files"
> is different ("*" for POSIX, "*.*" for Windows).  Also, under Windows, the
> matching is case-insesitive ("foo.*" will match "FOO.ASM" and "foo.o") while
> they aren't for POSIX (but they *might* for Mac OS-X---that's a weird
> system).  So there's that to watch out for.
>
>   Then there's the path separator ("\" for Windows, "/" for POSIX, although
> Windows *does* support "/" for the separator as well).
>
>   Okay, for a simple job of listing files in a directory, we have:
>
>         Windows:
>
>                 directory needs to be the current working directory
>                 pattern matches case-insensitive
>                 people will use '\' out of habit
>                 OH!  Also, Windows returns metainformation about each file
>
>         POSIX:
>                 can do any directory
>                 pattern matches case-sensative (maybe except for OS-X)
>                 people will use '/' because that's the only path separator
>                 OH!  POSIX only returns the name, no metainformation

We know at compile time if the system supports windows, posix or none
of the above. Why not provide an extensible layer, provide a Windows
and POSIX libraries that are compiled in via options, and let everyone
else fend for themselves?

I guess it's really just a matter of perspective on what is part of an
operating system. Lua interactivity with the shell is provided, I
assume interaction to system call through C, but nothing else really?
The terminal is only supported through a third party. And yet lua
*almost*[1] requires the user to interact with a filesystem to load
scripts (well, it does "require()", but I mean the literal term). In
interactive mode it *requires* a library to interact with the user. I
think that's why people baulk at the fact these tools are not standard
(myself included).

On this mailing list we can see that there are thousands of opinions
of what should be done with Lua and what options should be included.
Perhaps the next great feature could be an upgrade to the build system
that would allow someone to build in the options they see fit? On the
flip side, I see potential though for much grief caused by compiled in
features.

Russ
[1] dynamic scripts generated in memory and so forth, data passed
through C etc. My details are still fuzzy around possibilities here.

>   And that metainformation?  Again, some differences between the two.
>
>   Your job, should you choose to accept it, is to figure out the semantics
> of a Lua directory iterator.
If I could do that, I promise you I wouldn't be on the mailing list
right now writing emails. ;)

>   -spc
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Sean Conner
It was thus said that the Great Russell Haley once stated:
> On Sat, Sep 16, 2017 at 2:16 PM, Sean Conner <[hidden email]> wrote:
> > It was thus said that the Great Russell Haley once stated:
> >
> >> Could someone please *name* a filesystem that they use Lua on that is
> >> *not* windows or posix compliant?
> >
> >   I can name several---VMS, AmigaOS, MS-DOS 1.0, CP/M.  But ones that are
> ooh, VMS, good one! Still in use and someone uses lua though?

  I would *love it* if Lua was used under VMS.  The directory stuff there is
wild compared to what we are used to today.  But even AmigaOS would be good
as it's just enough different from POSIX/Windows to make it interesting.

> >   Okay, for a simple job of listing files in a directory, we have:
> >
> >         Windows:
> >
> >                 directory needs to be the current working directory
> >                 pattern matches case-insensitive
> >                 people will use '\' out of habit
> >                 OH!  Also, Windows returns metainformation about each file
> >
> >         POSIX:
> >                 can do any directory
> >                 pattern matches case-sensative (maybe except for OS-X)
> >                 people will use '/' because that's the only path separator
> >                 OH!  POSIX only returns the name, no metainformation
>
> We know at compile time if the system supports windows, posix or none
> of the above. Why not provide an extensible layer, provide a Windows
> and POSIX libraries that are compiled in via options, and let everyone
> else fend for themselves?
>
> I guess it's really just a matter of perspective on what is part of an
> operating system. Lua interactivity with the shell is provided, I
> assume interaction to system call through C, but nothing else really?

  Lua uses C89 (with two exceptions) for *everything*.  It's the C runtime
that Lua uses that makes the system calls.  The two exceptions that I can
think of are:

        1) readline (POSIX if it's installed, not sure about Windows) for
        handing interactive input of the standalone executable

        2) the loading of C-based Lua modules using POSIX or Windows
        specific calls to load the shared objects into memory.

> The terminal is only supported through a third party. And yet lua
> *almost*[1] requires the user to interact with a filesystem to load
> scripts (well, it does "require()", but I mean the literal term). In
> interactive mode it *requires* a library to interact with the user. I
> think that's why people baulk at the fact these tools are not standard
> (myself included).

  Ehhhh ... it cheats.  Assuming a module written in Lua, when you do
require() on it, the code goes through package.path:

./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua

splits it apart at each semicolon:

        ./?.lua
        /usr/local/share/lua/5.1/?.lua
        /usr/local/share/lua/5.1/?/init.lua
        /usr/local/lib/lua/5.1/?.lua
        /usr/local/lib/lua/5.1/?/init.lua

Then for each of the above, it substitutes the '?' with the module name and
the result is passed to fopen() (the C function):

        ./MODNAME.lua
        /usr/local/share/lua/5.1/MODNAME.lua
        /usr/local/share/lua/5.1/MODNAME/init.lua
        /usr/local/lib/lua/5.1/MODNAME.lua
        /usr/local/lib/lua/5.1/MODNAME/init.lua

As far as Lua is concerned, these are "magic strings" passed to fopen().
It's similar for C-based modules, but that uses package.cpath and a system
specific call to load the shared object.

  But there's nothing preventing loading modules from something other than a
file.  I did work were I loaded Lua based modules directly from a ZIP file;
at work, I have an application that includes all required modules built in
(those in Lua are compressed and part of the executable) and I extended
require() to load said modules.

  -spc

> [1] dynamic scripts generated in memory and so forth, data passed
> through C etc. My details are still fuzzy around possibilities here.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Eric Wing
In reply to this post by Sean Conner
>> Could someone please *name* a filesystem that they use Lua on that is
>> *not* windows or posix compliant?
>
>   I can name several---VMS, AmigaOS, MS-DOS 1.0, CP/M.  But ones that are
> still in use?  I don't know.  I want to say that iOS and Android file
> access
> is different, but I don't program those (I just hear the complaints at
> work).


Yeah, Android sucks. (iOS generally works with the POSIX APIs…most of
its issues are you need additional APIs for things like opting out of
automatic iCloud backups and so forth. Android also begs for
additional APIs too on top of its other problems, like finding the
paths for internal or external storage, availability, and permissions.
Both platforms (and Mac too) benefit from well known directory
locations for things like Preferences, Cache files, Documents,
Downloads, things that ship with your app bundle, etc.)

Quick answer for Android is there are two different file APIs you must
use depending on the situation. The POSIX stuff generally works for
internal and external storage (ignoring the extra hoop jumping about
permissions, availability, and finding out what all the paths to the
different locations are). But there is a different set of APIs for
reading files you ship with your app which are inside the .apk which
is basically a zip file. To complicate matters, the APIs are built
around Java and require a “God object”, a Context class, that comes
from the application and must be passed as a parameter to use these
APIs. There is no standardized way to get this Context “God” object,
which makes authoring libraries a PITA. Additionally, since the
Context object is a Java object, you must deal with Java JNI and you
also have to be able to get the JNIEnv* pointer which is like a second
God object you have to deal with. And like before, there is no
standardized way to get this either. (And the JNIEnv* cannot be shared
across threads and each thread must use a different thread local
instance of it, so you have to be extremely aware of where your
JNIEnv* instance comes from and which thread your Lua runtime exists
in.

That said, you can kind of wrap it in cross-platform wrappers (I’ve
done it before), but you need extra parameters or API for Android to
set/pass the Context object and JNIEnv*, either by passing it
explicitly, or an extra API that can store the Context for the
duration of of your life-cycle so you can pass it in on behalf of the
public API transparently to the caller.


> But in general, you are right, POSIX and Windows file systems cover
> probably 99.44% of all computer use today.

260 million PCs were sold in 2016
1.5 billion smart phones were sold in 2016


> On the other hand, a desire to continue sticking to portable code will leave LuaFileSystem or any sort of file I/O library with the usual limitations on Windows.
> Bypassing legacy library calls will get us a proper feature set. UTF-8 filenames. Bypass the MAX_PATH limitation.


As I understand it, the 260 MAX_PATH limitation on Windows can be
circumvented by doing all the following things:
1) Convert ANSI/UTF8 strings to Window’s native “wide” strings and use
all the variants of the Windows native file APIs (not ANSI/POSIX APIs)
that have the ‘W” suffix (instead of ‘A’)
2) Prefix all paths with \\?\ that you feed to these APIs. Note: This
only works for absolute paths, and not relative paths.
3) Make sure you aren’t limiting any of your own strings to the length
of MAX_PATH

In Windows 10, there now claim to be ways you can skip doing the \\?\
if you are doing (1) and (2) above.
A) Set a registry entry to disable the MAX_PATH
or
B) Set the option in an application manifest you compile into your app.


-Eric

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Eric Wing
> In Windows 10, there now claim to be ways you can skip doing the \\?\
> if you are doing (1) and (2) above.

Meant (1) and (3).

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Javier Guerra Giraldez
In reply to this post by Russell Haley
On 16 September 2017 at 17:58, Russell Haley <[hidden email]> wrote:
> Could someone please *name* a filesystem that they use Lua on that is *not* windows or posix compliant?

easy, embedded systems, like NodeMCU.  Terrible name, but it's a
really popular platform, introducing Lua to a new group of people.
while there's something like a filesystem, it's _very_ far from POSIX!

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Dirk Laurie-2
2017-09-18 2:35 GMT+02:00 Javier Guerra Giraldez <[hidden email]>:
> On 16 September 2017 at 17:58, Russell Haley <[hidden email]> wrote:
>> Could someone please *name* a filesystem that they use Lua on that is *not* windows or posix compliant?
>
> easy, embedded systems, like NodeMCU.  Terrible name, but it's a
> really popular platform, introducing Lua to a new group of people.
> while there's something like a filesystem, it's _very_ far from POSIX!

Well, LuaFileSystem is much less than POSIX. As long as the filesystem
has filenames, we are in business. The most pressing need is directories.
Links and locks can wait.

On filesystems that don't have directories, the concept can be replaced
by a name prefix.

Something like this:

The current prefix is kept in the registry. New functions in the IO library
do what lfs currently does on systems that can, otherwise:

io.currentdir Return the prefix.
io.chdir  Modify the prefix.
io.dir      Iterate over the tails of filenames that start with that prefix.
io.touch, io.mkdir, io.rmdir  Just do as much as possible.

Existing functions that need to be aware of the prefix:

io.open, io.popen  Concatenate prefix with appropriate separator to
  to the supplied tail.

Would that much be possible in NodeMCU?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

KHMan
On 9/18/2017 1:24 PM, Dirk Laurie wrote:

> 2017-09-18 2:35 GMT+02:00 Javier Guerra Giraldez <[hidden email]>:
>> On 16 September 2017 at 17:58, Russell Haley <[hidden email]> wrote:
>>> Could someone please *name* a filesystem that they use Lua on that is *not* windows or posix compliant?
>>
>> easy, embedded systems, like NodeMCU.  Terrible name, but it's a
>> really popular platform, introducing Lua to a new group of people.
>> while there's something like a filesystem, it's _very_ far from POSIX!
>
> Well, LuaFileSystem is much less than POSIX. As long as the filesystem
> has filenames, we are in business. The most pressing need is directories.
> Links and locks can wait.

NodeMCU uses SPIFFS (last time I checked anyway):

   https://github.com/pellepl/spiffs

It tries to be like stdio calls. NodeMCU (ESP8266) probably has
NAND FLASH for primary program memory (denser than NOR), but with
shorter bit strings vs NAND chips used in mainstream Flash storage.

It's not for heavy duty file management apps. But say for data
logging, SPIFFS will save you loads of time by not having to
design and code wear leveling etc.

> Would that much be possible in NodeMCU?
>[snipped all]

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Luiz Henrique de Figueiredo
In reply to this post by Russell Haley
> Perhaps the next great feature could be an upgrade to the build system
> that would allow someone to build in the options they see fit?

Editing luaconf.h provides this but of course it's not a "build system".

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

steve donovan
On Mon, Sep 18, 2017 at 12:46 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Editing luaconf.h provides this but of course it's not a "build system".

This is the kind of thing possible with luabuild - can ask for lfs to
be linked in statically, can ask for standard library modules to be
removed, etc.  Relevance to discussion: extended functionality does
not have to be part of the Lua core, since it is straightforward to
make it part of the Lua you use for your own purposes.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaFileSystem 1.7.0

Russell Haley
On Mon, Sep 18, 2017 at 4:54 AM, steve donovan
<[hidden email]> wrote:

> On Mon, Sep 18, 2017 at 12:46 PM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>> Editing luaconf.h provides this but of course it's not a "build system".
>
> This is the kind of thing possible with luabuild - can ask for lfs to
> be linked in statically, can ask for standard library modules to be
> removed, etc.  Relevance to discussion: extended functionality does
> not have to be part of the Lua core, since it is straightforward to
> make it part of the Lua you use for your own purposes.
>
Awesome Steve. Could you just speed this whole thing up for me and
tell me the solution to my next problem? ;)

Russ