Hard crash trying to lock globals

Bugs
1

I took the code below from the Lua.org wiki and pasted it at the bottom of my setup. Codea crashes out to the desktop when I run with it.

It is pretty invasive, but still, might be worth looking at.

For now, I’m saying “don’t do that” is the solution, but it would be nice to be able to lock out creation and access to undefined globals at run time.

    setmetatable(_G, {
        __newindex = function (_, n)
            error("attempt to write to undeclared variable "..n, 2)
        end,
        __index = function (_, n)
            error("attempt to read undeclared variable "..n, 2)
        end,
    })
end
2

This is caused, in part, by repeated references inside Codea to the undefined global collide, as reported back in March. I think there are others that I haven’t found yet.

It would be nice to be able to run elements of strict Lua like this one. Probably not a high priority.

3

I like the idea of locking globals! I’ll give it a try and see where we should be checking in the runtime for the existence of something before using it

4

The code to look for includes, i’d bet,

if collide ...

setting collide (global) to false has stopped most of my crashes, though i did see one.

I’m going to try putting all my highly visible objects into a single global for the application. That does cost another table access, but I think it’s safer, and one can almost always cache the value locally or pass as a param if it’s accessed all that much.

5

I used a simple global checker from lua.org. I haven’t tried anything fancy. There’s even a way to do it that allows you to define a global nil and have it not look like a fresh access next time around.

6

Why would one want to do this?

7 
local foo = x > 0
...
if Foo then ...

simple typos can make things break, and often turn into mistaken global refs.

i’ll also experiment with locking class instances if i can figure out how.

8

So you mean you set up globals in one area, then lock them, and then anywhere else you try to make a global it will cause an error?

9

Right.

Unrelated to that but to another thing. I think you mentioned losing work in a tab that was in Working Copy. I’ve seen something like that, but not quite. What I saw was roughly this:

  1. Create and work on a project for a while
  2. Decide to put it in Working Copy;
  3. Create Repo in WC;
  4. Link it to the project in that weird way WC has for Codea;
  5. Commit it;
  6. Work some more
  7. After a while, it seemed like new stuff wasn’t even showing up in the tests.

When I looked at the code in the tab it was there, when I ran the tests Codea wasn’t seeing it. I even tried the Save Project and Run, and it wasn’t there.

Exited the project and came back: The tab didn’t have any of my new code.

Pasted the code back from the article I was writing (yay, spare backup) and the tests began to see the new code. Working Copy saw the new code for a commit.

Unfortunately I didn’t check WC before I exited or came back to see what it saw.

I’m not sure whether WC has done something or Codea. If it was WC it’s almost be like an automatic revert. That’s almost inconceivable, so I suspect it was Codea but the hookup between the two could be confusing Codea.

I think what I’ll try to do when I create new Working Copy repos is to be exited from the project in Codea, to be sure everything is flushed for WC to look up.

So … no answer, but I’ve seen something like you saw. I’ll look for your report and underline it.