tilkinsc / luaconsole Goto Github PK

On SSH via Linux, PuTTY doesn't seem to autocomplete, nor any leading android app at least as far as I tested.
Real linux box I've had complaints whether it worked or not, but they couldn't even follow simple build instructions.

Windows 10 does arrow keys do this already.
Windows 7 idk I forget

I don't like writing Makefiles, basically some housekeeping and regulation changed need made. It builds fully, but doesn't copy LuaConsole/dll/* into LuaConsole/Release or LuaConsole/Debug. It also needs to be checked that the dll file import libraries are enumerated and added. Exclusion of dummy files (except in res) is something needing done to with that.

Compiling lua isn't part of LuaConsole, but sure as heck could be.

Although, I have NO IDEA how breaking it would be to compile a lua51 application in a lua53 compiler for a lua51 dll. I haven't gone through any of the files for comparison.

Here are relevant files
lua535 compiler.zip
lua524 compiler.zip
lua515 compiler.zip

License https://github.com/tilkinsc/LuaConsole/blob/master/Lua%20LICENSE

People want auto complete but I don't have a solution. Readline is okay, as debuted in PUC-Lua REPL. I don't like the idea of multiline editing too, which can be easily implemented by reading from stdin until a null character was typed in the REPL function.

Although this is not an IDE this is a great feature, but will be implemented poorly due to need of popup box too. Perhaps. Hmm...

Lua5.1, Lua5.2, and Lua5.3 currently has no way of getting stdin input outside of manual in-console input. No matter what you pipe to luaw or lua, nothing actually gets sent to io.stdin for in-script use. In a recent update, I made it enabled to where you can use | and < to send files and strings to the program via stdin. I don't think I really set it up too good, but it works and I have a patch that I am working out at the time of writing.

The patch comes down to when what runs. ARGS.restore_console exists because I need to flag to re-enable tty for the post-exist flag -p. I will not be able to get stdin into my program and use -p without the hack, as this is due to Windows and Linux. It was a nasty hack that goes against the prettiness of the code I have, but hey. The hack has to do with organizing this process to allow tty to be reenabled and also be able to give scripts their data they want. Without the organization patch, piping and trying to -e a string will not work per trying to io.stdin:read() due to when the hack comes into effect.

More importantly though, Lua's code in liolib.c, if I am not mistaken, opens up 2 new files and treats them as a high level stdin and stdout. Using getc will allow for this ofc... you don't have to use the stdin file handle, in fact echo print('hi') | lua -i breaks in puc-lua the same way it does LuaConsole.... thus the hack I just brought up. Although, the cutesy that the puc-lua console is, it actually just executes whatever you pipe through it aka autodetection. Limiting, I know.

Lua kindly puts the files in the registry. So sweet of them, I think I might as well take the files for myself and fix the pipeline on user switch request. Idk if it will break the io lib. If it does I can use other synthetic ways I am sure. Although, its good to keep in mind that people are definitely now allowed to pipe streams to the program - in that 'stdin' could not be used for processing socket streams of data at varying intervals. I don't want to create an io library lol.

C:\git\LuaConsole\lua-5.3.5\src>echo print('hi') | lua -i
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> hi
>
C:\git\LuaConsole\lua-5.3.5\src>

I am pretty sure an old 4.3 compiler would have trouble parsing the inlines that I do. Some other stuff I might not be aware of too.

Probably need to rework how passing in data works, probably could add piping in.
Wanting to add in better console support in general, not just additional -'s.

I think a good test for LuaConsole would be the total execution time based on multiple factors (calls to the program) outlined in the test from the travis.sh file.

It is based off of a target called, "Collect, Process, Output". The collection happens by the dll loader, which passes the data to the Processor and Output happens from there on. So I would also like test records of the collection process separately from total execution times.

Lua code execution time is irrelevant as it happens on part of the Lua library executing it, rather than the program interpreting it.

Finally, two sets of data would be nice. A debug and release form.

It would be nice to have a build_msvs.bat for use with MSVS.

Hi, thank you for installation instructions for LuaRocks at https://github.com/Hydroque/LuaConsole/wiki/LuaRocks-Support-Windows-MinGW.

I just want to suggest a small optimisation: instead of doing install /F /MW /L and then deleting "all lua51 executables, MSVCRT stuff, manifest, and lua51.dll, and everything in \include" as described at step (5), isn't it easier to skip the /L switch during installation?

lua51 executables/dlls won't be installed in this case at all.

I would like to add Lua-5.0 to the build category listing.

I am not sure which functions I will have to remove (or add :o) in order to include it.

I am working on a Collect Process Output model. This will replace the big giant and ugly switch statement and allow more seamless transfer of data struct, which is never referenced directly.

This will not only add ease of use, but the whole program should flow a little better.

https://travis-ci.org/tilkinsc/LuaConsole/jobs/491369318

It seems the Mac version clang linker doesn't have the -E command. Rightfully so, it tries to build as linux. We are also missing objcopy.

I would like this to be translated to other languages.

Evidently on Linux

Open for debate

#6 Needs completed first.

I'm trying to run a *.lua file using LuaConsole on Windows by doing luaw main.lua but only thing I get every time is :
Couldn't open file lang/english.txt! Failed to load lang file!

• A project file from different versions
• NMake files that MSVS supports

Anything is welcome.

Needs to build fully just like all other scripts in the root.