ZeroBraneStudio
ZeroBraneStudio copied to clipboard
pkulchenko
Bitwise operators not recognized during compilation with Lua 5.3 interpreter selected
Problem with recognizing bitwise operators (Lua 5.3). Using bitwise operators is reported as an error on compilation.
The internal compiler doesn't support Lua 5.3. The current workaround is to use static analyzer (Shift-F7) or to run the project instead of compiling it as the errors will be reported in the same way as during the compilation.
The static analyzer and running the project are somewhat workarounds, yes, though the other "warnings" they produce, that are not problematic make it really cumbersome for reading for pinpointing an exact problem if there is one. Do you plan on updating the internal compiler soon? It really is very useful for fast checking code without interrupting the flow of coding. Thank you.
Do you plan on updating the internal compiler soon?
No. It's the same interpreter that ZBS itself is using and I don't plan to move away from LuaJIT any time soon. I've considered embedding multiple Lua interpreters to support internal compilation with different engine versions, but so far has not found a practical way to do this.
It really is very useful for fast checking code without interrupting the flow of coding.
Agree; I'm considering running an external process to produce compilation results (essentially loadstring([[code]], "@filename")), but this has its own challenges. I'll need to try a couple of things to see if this is a viable path. I don't see any other options at the moment.
I hope you manage to do something with it. It's quite unfortunate you have decided to stick firmly with LuaJIT for internal compilation though, as seeing Mike is determined to not support versions above 5.1 (partly 5.2) which looks like LuaJIT forks away even more from Lua and that means ZBS will become kind of a dedicated to that fork in the context of Lua. I hope you find some way to integrate multiple Lua interpreters to support internal compilation, otherwise ZBS will become more and more a no go, at least for me, and i suppose for people that want to stick with Lua moving forward.
I think we can all agree 5.3 support would be nice for zerobrane. It's more about not being entirely sure how to go about it code-wise. He is assigned to this issue after all.
It's quite unfortunate you have decided to stick firmly with LuaJIT for internal compilation though, as seeing Mike is determined to not support versions above 5.1 (partly 5.2) which looks like LuaJIT forks away even more from Lua and that means ZBS will become kind of a dedicated to that fork in the context of Lua.
It's not about moving to 5.3. As soon as you upgrade the internal engine to 5.3, it will produce incorrect results on 5.2 and 5.1 code, so it's not a panacea.
I hope you find some way to integrate multiple Lua interpreters to support internal compilation, otherwise ZBS will become more and more a no go, at least for me, and i suppose for people that want to stick with Lua moving forward.
ZBS does support all those versions; keep in mind that we are talking about internal compilation and local console, which most editors don't provide and those that do still limit to one specific version. As @CapsAdmin said, I'm looking at the options, but I see some other items as being a bit higher on the priority list. #490 is a related ticket for the console work, which may enable support for multiple interpreters.
I'd like to request support for external compilers.
Something like
path.lua53 = [[C:\Projects\lua-5.3.1\bin\Release\lua.exe]]
path.lua53c = [[C:\Projects\ua-5.3.1\bin\Release\luac.exe]]
in user.lua could activate this
Reason: We have modified Lua5.3 with some more syntactical sugar. (e.g NAME#LIT for NAME"LIT") We can run and debug this with zbstudio, but compile failes. Why dont use a configured luac to compile instead of using loadstring?
Regards Jørgen
