> Hmm, I don't think this is true. You just need to enable `system()` in configuration
Well... Yes and no... system() requires NSH, which is part of the apps package. So, technically, the NuttX kernel does not support it directly. In my case, there is no NSH, so os.execute had to be removed. But of course if someone needs this, it is very possible to have it. Στις Πέμ, 10 Ιουν 2021 στις 10:38 μ.μ., ο/η Maciej Wójcik <w8j...@gmail.com> έγραψε: > > as NuttX does not support the function system() > > Hmm, I don't think this is true. You just need to enable `system()` in > configuration > > http://nuttx-config.nxtlabs.pl/#/?current=SYSTEM_SYSTEM > > > Am Do., 10. Juni 2021 um 17:52 Uhr schrieb Fotis Panagiotopoulos < > f.j.pa...@gmail.com>: > > > Regarding Lua. > > > > I have been using Lua in MCU environment for many years now. > > This is the first time to use it along with NuttX. > > > > I am using Lua 5.2.4, for which I have ported the LTR patch, as described > > here: > > http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html > > > > The way I am using it, is to enable the end user to provide their own > logic > > to the system. > > Essentially they provide the end application that runs on my hardware. > > Custom Lua libraries allow the Lua scripts to interface the board. > > > > "Porting" Lua to NuttX was a piece of cake*. > > I just downloaded the source code, configured luaconf.h and built it. > > The only modification that I did to the source code was to comment out > the > > os.execute function, as NuttX does not support the function system(). > > I am not sure if this can be easily fixed in NuttX or Lua, or whether > this > > functionality is generally required in an MCU environment. > > > > (*Note however that this is a WIP for me, so it is not properly tested > yet. > > Issues may arise, but for the moment I don't see any reason for .) > > > > Στις Πέμ, 10 Ιουν 2021 στις 2:57 μ.μ., ο/η Xiang Xiao < > > xiaoxiang781...@gmail.com> έγραψε: > > > > > It would be great to put NuttX special build files to apps/interpreters > > > folder after you finish the port, so other people can benefit from your > > > work and improve it in the future. For the code change, I would > > > suggest that: > > > 1. If the api called by 3rd party is very common in other Unix variants > > but > > > NuttX is not implemented or the implementation is wrong, it's better to > > > improve NuttX instead of hacking the 3rd party code. > > > 2. If the api is hard to implement in NuttX(e.g. fork), but there is a > > more > > > portable way to write the same functionality(e.g. > > > posix_spawn/pthread_create), it's better to make a common change not > > > specific to NuttX.(e.g. > > > https://gitlab.com/libssh/libssh-mirror/-/merge_requests/174). > > > 3.The last resort is to add __NuttX__ around the broken code. > > > Last, it's better to upstream your change to NuttX and 3rd party > > community, > > > so both sides can maintain and improve your change in the long term. > > > > > > On Thu, Jun 10, 2021 at 5:58 PM Flavio Castro Alves Filho < > > > flavio.al...@gmail.com> wrote: > > > > > > > > > > > > > We really ought to talk to the Lua team and see if we can upstream > > the > > > > > changes. Unsupported ports in NuttX don't have good shelf life. > > > > > > > > > > > > > I believe that one of the reasons is that Lua's major use case is to > > > > be embedded inside applications, isn't it? > > > > > > > > I don't know if Lua is used so much as a replacement for bash, perl > or > > > > python .. > > > > > > > > In this case, maybe a document explaining how to add on a project > > > > could be enough :-| > > > > > > > > Best regards, > > > > > > > > Flavio > > > > > > > > > >
