ZeroBrane Studio error with MTE

Dyson,

When using ZeroBraneStudio (http://studio.zerobrane.com), and you try to run a game using MTE using either the green “start debugging” toolbar icon or Project->Run menu option, the following error is given:

Compilation error on line 26: [string "/Users/jsmith/Projects/Corona Projects/Tut1/m..."]:26: '\<name\>' expected near 'goto'

Line 26 is:

mte.goto({locX = 1, locY = 15, blockScale = display.viewableContentWidth / 15})

If I use Project->Run as Scratchpad, it does run the game in the simulator and works great. This is just an annoyance.

The same thing happens on the MTE sample projects…

If I create a new Corona project without MTE, all three methods of running the code work within ZeroBraneStudio.

I am not sure if this is a bug in ZeroBraneStudio or with your software. If you don’t mind, could you take a look with one of your sample projects and maybe contact the creators of ZeroBraneStudio and give them a copy of MTE to try to track down the issue?

The first time you run ZeroBraneStudio you should go to Project->Lua Interpreter, and select Corona.

UPDATE:

It looks like this is caused by line 151 of mte.lua

local goto

I believe that ZeroBraneStudio is complaining because it does not recognize this line as a function override and believes it is a syntax error. I think this will have to be resolved by ZeroBraneStudio but they may need a copy of MTE to do testing with.

UPDATE 2:

It appears that ZeroBraneStudio uses Lua 5.2 internally which now has ‘goto’ as a reserved keyword which cannot be overridden.

It is now my recommendation to replace ‘goto’ with a non-reserved keyword just in case Corona were to change in the future.

Right now, it seems that ZeroBraneStudio uses 5.2 so it fails whereas “Run as Scratchpad” appears to skip syntax checking and just shoves the code off to Corona.

http://www.freelists.org/post/zerobrane/ANN-ZeroBrane-Studio-039-now-with-Lua-52-and-LuaJIT-out-of-the-box-support

http://www.corsix.org/lua/5.2-beta-annotated/manual.html

Jerry, Dyson,

This is most likely caused by ZBS using syntax checks that are Lua 5.2 aware (technically, it’s using LuaJIT engine with enabled Lua 5.2 support), which makes “goto” a reserved word. Ideally, MTE would have to rename “goto” to something else. Essentially, according to new rules, “goto” cannot be used as a variable or 

One workaround would be to disable mandatory compilation before running projects by adding

  skipcompile = true,

after “scratchextloop = true,” at the end of interpreters/corona.lua.

Another (simpler) workaround is to create an alias: “mte.goto_ = mte[‘goto’]” and use it instead of the original call, but it still doesn’t help with “local goto”. You will still be able to run the project as long as the current file compiles without errors.

I’ll see if I can make ‘goto’ related compilation errors to not stop Run/Debug execution.

Thanks paulclinger!

Honestly, I believe dyson should also change goto to something else. It seems very plausible this might become an issue in the future if Corona decides to update.

Ok paul,

I duplicated the corona interpreter to “MTE” and added that one line and all works fine.

Dyson, please see if you can do anything else for this issue.

Sorry I didn’t look at this sooner, I had a busy morning.

Changing goto to something else will be easy enough. The question then is this; to what should I change it? The word “goto” is concise and descriptive, its replacement should be equally so. 

Dyson,

I’m still new to your framework as you know, but why not ‘translate’?

My understanding of goto is that it moves (IE, translates) the camera.

Otherwise, might suffice to just rename it to _goto. A little tacky looking but would probably get around the reserved keyword thing.

Or, more verbose but cameraGoto also gets the point across

Hmm, maybe goto isn’t the best function label after all! Goto creates the camera view and sets it to its initial position, it is not meant for moving the camera except for when the camera needs to move to a very distant location instantaneously. Perhaps setCamera would more clearly describe its purpose.

Ahh! If that is indeed the function of ‘goto’ then setCamera is indeed the most apt in my opinion.

The word ‘set’ implies it occurs instantaneously and the word ‘camera’ describes what is occuring.

Maybe change ‘goto’ to setCamera and keep goto in for a few versions as a shortcut to setCamera to keep backwards compatibility with existing code.

Then, you could mark it as deprecated and give everyone until X date or version to stop using it at which point you remove goto entirely.

Jerry, Dyson,

This is most likely caused by ZBS using syntax checks that are Lua 5.2 aware (technically, it’s using LuaJIT engine with enabled Lua 5.2 support), which makes “goto” a reserved word. Ideally, MTE would have to rename “goto” to something else. Essentially, according to new rules, “goto” cannot be used as a variable or 

One workaround would be to disable mandatory compilation before running projects by adding

  skipcompile = true,

after “scratchextloop = true,” at the end of interpreters/corona.lua.

Another (simpler) workaround is to create an alias: “mte.goto_ = mte[‘goto’]” and use it instead of the original call, but it still doesn’t help with “local goto”. You will still be able to run the project as long as the current file compiles without errors.

I’ll see if I can make ‘goto’ related compilation errors to not stop Run/Debug execution.

Thanks paulclinger!

Honestly, I believe dyson should also change goto to something else. It seems very plausible this might become an issue in the future if Corona decides to update.

Ok paul,

I duplicated the corona interpreter to “MTE” and added that one line and all works fine.

Dyson, please see if you can do anything else for this issue.

Sorry I didn’t look at this sooner, I had a busy morning.

Changing goto to something else will be easy enough. The question then is this; to what should I change it? The word “goto” is concise and descriptive, its replacement should be equally so. 

Dyson,

I’m still new to your framework as you know, but why not ‘translate’?

My understanding of goto is that it moves (IE, translates) the camera.

Otherwise, might suffice to just rename it to _goto. A little tacky looking but would probably get around the reserved keyword thing.

Or, more verbose but cameraGoto also gets the point across

Hmm, maybe goto isn’t the best function label after all! Goto creates the camera view and sets it to its initial position, it is not meant for moving the camera except for when the camera needs to move to a very distant location instantaneously. Perhaps setCamera would more clearly describe its purpose.

Ahh! If that is indeed the function of ‘goto’ then setCamera is indeed the most apt in my opinion.

The word ‘set’ implies it occurs instantaneously and the word ‘camera’ describes what is occuring.

Maybe change ‘goto’ to setCamera and keep goto in for a few versions as a shortcut to setCamera to keep backwards compatibility with existing code.

Then, you could mark it as deprecated and give everyone until X date or version to stop using it at which point you remove goto entirely.