Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add modules to luac.cross which do not have hardware dependencies #3229

Open
HHHartmann opened this issue Jul 22, 2020 · 6 comments
Open

Add modules to luac.cross which do not have hardware dependencies #3229

HHHartmann opened this issue Jul 22, 2020 · 6 comments
Assignees

Comments

@HHHartmann
Copy link
Member

Missing feature

Use non HW dependent modules in luac.cross

Modules are at least:
struct.c bit.c color_utils.c sjson.c // work without problems
bloom.c crypto.c encoder.c // would need some more work

Justification

help creating tests and allow usage of known functionality on the host.

Workarounds

none

@pjsg
Copy link
Member

pjsg commented Jul 22, 2020

file could be added without much difficulty.

@TerryE
Copy link
Collaborator

TerryE commented Jul 23, 2020

The luac.cross environment already supports os and io. I did look at adding file but decided that given we already support io, I could not see the point of doing this dev work.

struct since this is already implemented in the Lua 5.3 string library (see String pack and unpack), so it is really redundant in a 5.3 world.

Ditto for deprecating bit as these bitwise operations are natively supported in Lua 5.3.

sjson and possibly crypto.c encoder.c might make sense, but I see the main potential advantage if we have some form of LFS object so that we can use the -e option to generate Protos for saving in a multi-TLF compiled file. This way developers could create resource functions. But let me get on-ESP LFS update and two LFS regions working first, eh? Because this is going to rework luac.cross quite a lot.

@HHHartmann
Copy link
Member Author

file could be added without much difficulty.

Hmm file depends on vfs which operates on SPIFFS or FAT. SPIFFS uses platform_flash_read/write to access the storage. So some work to add another blockdevice would be necessary.

@TerryE
Copy link
Collaborator

TerryE commented Jul 24, 2020

@HHHartmann Gregor, as I said: we already have io for host filesystem I/O. The one potential use for file that could be of benefit is as a wrapper around SPIFFS the same way that spiffsimg does. This way you could use Lua scripts to provision a SPIFFS on host. A well-scoped and entirely doable little project: use io to access the host FS and file to access a host-based SPIFFS image.

@HHHartmann HHHartmann self-assigned this Jan 22, 2021
@stale
Copy link

stale bot commented Apr 16, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 16, 2022
@stale stale bot closed this as completed Apr 30, 2022
@HHHartmann
Copy link
Member Author

Still would like the associated PR to get in.
Is anybody willing to back this?

@HHHartmann HHHartmann reopened this May 1, 2022
@stale stale bot removed the stale label May 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants