Has there been any word on moving the underlying Lua support to 5.3?
I *really* want those bitwise operators (no, the bit32 library doesn’t suffice … and has some bugs
(e.g., bit32.extract doesn’t properly coerce first parameter to 32-bits, so you can trap extracting
starting at bit 31)
I also want “goto” 
thanks,
Stan
I think the best way to push this forward is as a feature request.
I too would LOVE to see Corona use 5.3 for the very same reason (bitwise ops) but I fear there may be too many underlying dependencies to make the change feasible. However, we can’t know w/o asking.
I’d love to see this too … or LuaJIT on target’s where it’s available as the FFI is extremely cool for more efficient data structures.
Giving you a “goto” is a great reason to not go to 5.3
On a more serious note, Corona uses a custom version of Lua. It’s a really difficult task to update our Lua version. @roaminggamer’s suggestion to vote up the request is the best thing to do.
Now if you have bugs to report in the bit plugin, by all means, report them. We can’t fix things we don’t know about. It sounds like you have an easily reproducible bug. Create a demo project that shows the plugin failing. The project should have a main.lua, config.lua, and build.settings files along with any other needed assets. Put that in a .zip file and use the Report a Bug link at the top of the page. Our engineers should be able to simply unzip the project, build it for the target device and see the error happen.
Thanks
Rob
My bug reference was to “bit32” as found in the common 5.3 distribution of Lua …
I haven’t had a chance to determine if the same bug is in the bit plugin.
A close reading of the original work on why “goto” might be bad, Edsger Dijkstra’s “GOTO considered harmful”,
which I first read in 1970, reveals that he was complaining about “excessive use” being harmful, and that several sentences in the short paper actually imply the usefulness of gotos
Also, in those days, the concept of a single entry / single exit point for a procedure was probably not a common idea …
a concept often achievable in a readable manner only with a goto.
Stan (you’ll have to my GOTO out of my cold dead hands Sieler
“goto” is evil and should not ever be a coding construct… it is a debugging nightmare.
I seem to recall David Given on the Lua mailing list being one of the major proponents of goto , which I believe he wanted (and has since used) for code that writes code, i.e. loadstring() and friends, for his word processor if I’m not mistaken. This post seems to back that up, though I know it was a recurring topic.
The Lua authors deliberately make no promises about backward compatibility, and act on this, so some things will break. Usually these are minor, but then there will be things many have come to rely on, like say the deprecated arg table for varargs (versus … and APIs) being removed (curiously, it sounds like this will resurface in 5.4).
On the native side, C++ has had some fantastic advances lately, but presents similar difficulties.
Aside from the controversial goto…
Lua 5.3 addresses some significant issues with meta table operations, specifically removing the flawed __ipairs meta operation and supporting the __len meta operation.
Those make proxy tables actually usable in Lua 5.3 in ways which are not possible in Lua 5.1.
So another vote for 5.3 support! Though I understand it’s not trivial :)
I think the best way to push this forward is as a feature request.
I too would LOVE to see Corona use 5.3 for the very same reason (bitwise ops) but I fear there may be too many underlying dependencies to make the change feasible. However, we can’t know w/o asking.
I’d love to see this too … or LuaJIT on target’s where it’s available as the FFI is extremely cool for more efficient data structures.
Giving you a “goto” is a great reason to not go to 5.3
On a more serious note, Corona uses a custom version of Lua. It’s a really difficult task to update our Lua version. @roaminggamer’s suggestion to vote up the request is the best thing to do.
Now if you have bugs to report in the bit plugin, by all means, report them. We can’t fix things we don’t know about. It sounds like you have an easily reproducible bug. Create a demo project that shows the plugin failing. The project should have a main.lua, config.lua, and build.settings files along with any other needed assets. Put that in a .zip file and use the Report a Bug link at the top of the page. Our engineers should be able to simply unzip the project, build it for the target device and see the error happen.
Thanks
Rob
My bug reference was to “bit32” as found in the common 5.3 distribution of Lua …
I haven’t had a chance to determine if the same bug is in the bit plugin.
A close reading of the original work on why “goto” might be bad, Edsger Dijkstra’s “GOTO considered harmful”,
which I first read in 1970, reveals that he was complaining about “excessive use” being harmful, and that several sentences in the short paper actually imply the usefulness of gotos
Also, in those days, the concept of a single entry / single exit point for a procedure was probably not a common idea …
a concept often achievable in a readable manner only with a goto.
Stan (you’ll have to my GOTO out of my cold dead hands Sieler
“goto” is evil and should not ever be a coding construct… it is a debugging nightmare.
I seem to recall David Given on the Lua mailing list being one of the major proponents of goto , which I believe he wanted (and has since used) for code that writes code, i.e. loadstring() and friends, for his word processor if I’m not mistaken. This post seems to back that up, though I know it was a recurring topic.
The Lua authors deliberately make no promises about backward compatibility, and act on this, so some things will break. Usually these are minor, but then there will be things many have come to rely on, like say the deprecated arg table for varargs (versus … and APIs) being removed (curiously, it sounds like this will resurface in 5.4).
On the native side, C++ has had some fantastic advances lately, but presents similar difficulties.
Aside from the controversial goto…
Lua 5.3 addresses some significant issues with meta table operations, specifically removing the flawed __ipairs meta operation and supporting the __len meta operation.
Those make proxy tables actually usable in Lua 5.3 in ways which are not possible in Lua 5.1.
So another vote for 5.3 support! Though I understand it’s not trivial :)