bRunning = false, but still running...

So I'm writing an IDE and (just to see what would happen) I ran itself in code from itself. After a few tweaks everything works fine. Except exiting. After I exit the 2nd instance, the 1st instance won't exit. The main loop is like so:

function mainLoop()
while bRunning do
  --clear debug info
  sDebugText = ""

  input() --get input and respond

  --debug info
  local x,y = term.getCursorPos()
  sDebugText = sDebugText .. " Running:" ..tostring(bRunning)
  sDebugText = sDebugText .. " File:"..xFile..","..yFile .." Scrn:"..x..","..y

  scroll() --shift screen to show cursor
  draw() --update screen
end
end

and here is the exit routine (which is being called accurately):

function exit()
if bUnsavedChanges and not bConfirmingExit then --if there are unsaved changes, and this warning hasnt displayed yet
  sMessage = "UNSAVED CHANGES - Press F4 to exit"
  bConfirmingExit = true
else
  bRunning = false end
end

The most curious part is that I looked at the value of bRunning while the program was running and it said false after the second program was exited, but kept running the loop as per normal. The bool is also called as a local:

local bRunning = true --false when the program exits

so I'm not sure what's going on.

Edit: Actually it's failing to exit the 2nd instance. Investigating…

So I've done some testing and found that it is indeed the higher level of the program that is running, with the state information of the lower level.

I made a copy of the program (editor) to editor2. then ran editor with editor2 as a file to edit. Then inside the program I ran editor2 with a test file (print("hello")) and tried to exit. It exited as it was supposed to. However the top layer (editor) did not act as it was supposed to. It seems to have absorbed the file information from editor2 and the bRunning variable as well. But for some reason, even though bRunning is false, it's not exiting. Pressing the exit button does nothing.

I'm really at a loss. All the variables in question are local. I did a test to see if I could change local variables within their scope if a local variable was set to the same name:

local text = "1"
function layer2()
local text = "2"
print("layer2: " .. text)
end
print("function defined, not run")
print("layer1: " .. text)
layer2()
print("function run")
print("layer1: " .. text)

It printed 1, 2, 1 for the text variable, as it should have.

I'm at a loss here, I really have no idea what's going on. I have the feeling that it may be some weird bug in CC but I'm unsure.

EDIT: Now it appears that the first instances bRunning wasn't set to false as I said, it was set to "false". It was set to the string value of "false" which would explain why it wasn't exitting the program even though it was false. But this still doesn't explain why the string was passed back and put into the value of the boolean in the first instance. That wouldn't even be something I'd do in the program (passing a string to a boolean).

EDIT 2: I tried the above code with booleans, testing if it was a string or not, and I moved the function to a separate file. The result was still the equivalent of 1, 2, 1. So it looks to be like something in my code, but I can't figure out what. I tried adding an os.sleep(3) at EOF to test if it was the F4 being carried over to the next pullEvent but that wasn't the case either. For anyone willing to take a look, this is the code I'm working with atm: http://pastebin.com/2KDJfZij

EDIT 3: I made a stupid mistake in testing. So the first level is actually getting boolean values from the second level. For example,

if bRunning == true or bRunning == false then
   sDebugText = sDebugText .. " Running:" ..tostring(bRunning) end

will show in the debug that running is false (bool), but it wont exit the main loop, which is while bRunning do end. This is verified by this code which I just tested, that didn't solve the problem:

if bRunning == true then
   bRunning = true
  elseif bRunning == false then
   bRunning = false
  end

EDIT 4: I looked at all the locations of bRunning being used in the program, and they all deal with setting it as a bool or reading its value. The only one that doesn't is the debug string that does tostring(bRunning) so I tested that, but it wasn't the culprit either. I don't think this is something wrong with my program. I think it may be something wrong with CC/Lua…

Tip: If you're not stacking up shell.runs and stuff, Just use the function error() which will exit the program without any error message, as if cc has a os.exit() function.

1lann, on 23 September 2012 - 09:52 AM said:

Tip: If you're not stacking up shell.runs and stuff, Just use the function error() which will exit the program without any error message, as if cc has a os.exit() function.

But that's precisely what I am doing. And the sub-instances of the program are changing the top-instances' variables. Even if I use error() to exit the program instead of my way of doing it, when exiting a lower instance into a higher instance the higher instance now has the file information for the lower instance, instead of, in my case, the editor itself.

I've started using faubiguy's code (http://www.computercraft.info/forums2/index.php?/topic/4270-021-ed-the-in-game-ide/page__view__findpost__p__33765) to run my internal program instead of shell.run(). I no longer have any of the associated problems, and this leads me to believe that either it is an issue with the file being saved over the file already in use (which is required to load from a file, as with shell.run()) or something is fundamentally wrong with shell.run()'s execution. Either way it now runs the file in the editor without saving and is no longer an issue, but it should be noted that the core problem…
was never solved!

TLDR… But, I might suggest some quick information on what happens when you execute programs from within programs:

Imagine that we're sitting on the top level shell, just hanging out. We decide to run a program which pushes that program onto the stack to be executed.
So, our imaginary stack looks like this currently:

TOP_SHELL
  NEW_PROGRAM - Currently executing

Now, from within that program, if we use shell.run() to run a new program our stack will receive yet another program:

TOP_SHELL
  NEW_PROGRAM
    NEW_PROGRAM_1 - Currently executing

When we return from the currently executing program in the stack, we go back to the previous program (assuming there is code following the program call).

TOP_SHELL
  NEW_PROGRAM - Currently executing

Halfway through that explanation I kind of forgot where I was going with it… Hopefully you can make something of it :P/>/>

Grim: in your example,

TOP_SHELL
--NEW_PROGRAM
----NEW_PROGRAM

The last program on the stack is the same as a previous program on the stack.