Do break points work right now?
I am using the GitHub version and when I set a breakpoint it still starts at the beginning and ignores any breakpoints.
I’ve just posted a new test release to Github which fixes many bugs. Give it a whirl, it should fix this issue.
Just downloaded the latest version from GitHub and gave it a try. I don’t see any difference. I set a breakpoint on line 10, but when I hit run debugger it always starts at 1 and I have no way to actually go to the specific breakpoints.
It would be nice to have a dialog that pops up “You do not have any breakpoints, single step from the beginning?”. Otherwise, it would only stop on the breakpoints specified rather than single stepping entire code line by line.
Other than that, I love how well the debugger was integrated into Sublime. When I spoke with Walter about it, didn’t think it would be so quick or so perfectly executed.
Oh, now I understand. I’m afraid the “start at line 1” behavior is baked into the underlying debugger implementation so that’s how it will work for now (you’ll have to “continue” once to hit your own breakpoint). I plan to improve the debugger a lot (with things like variable watching, run to cursor, etc) and I’ll bear this in mind when I do that.
I can live with it hitting 1 first, be nice not to but that’s not a huge issue if breakpoints work from next step. I can’t find a way to “continue” if I hit step into or step over it will go to line 2, not my first breakpoint.
Just “Run” again when the Debugger is active and it’ll carry on to the next breakpoint.
So, to hit your own breakpoint: Hit F10 to start the Debugger, wait for it to open and then hit F10 again to continue to the first breakpoint.
I fear that my familiarity with debuggers might have made me assume that this is obvious when clearly it isn’t so I’ll think about how to make it easier to discover.
That worked, thanks!
I’m used to use Step Into/Step over to move forward so I didn’t catch onto that.
Maybe just call it “Step” or “Run - Step”
It didn’t even dawn on me that was the step function. I thought it was just a run, maybe a run toggle.
Just wanna vote for the break on line 1 removal in the debugger. It’s really annoying 
I’d also like the corona simulator window to take focus until a breakpoint fires so there’s minimal manual window switching. (i’m a UX nut, I know)
The debugger is totally useless in bigger projects using scenes. Running the simulator in debug mode brings it straight up too 100%+ CPU usage, and simple things like tapping a button takes 20-40 seconds to respond.
Anyway, we’ve never had any success with the Corona debugger tools, so this is no big surprise, and we can still live without it - print(“FTW”).
Noted. Controlling window focus has it’s own pitfalls but I’ll see what I can do.
Absolutely. It can’t go switching back and forth on a whim. But when it doesn’t stop on line one then i’d like it to at least show the simulator on top from the start and when something breaks you’d probably need to switch yourself or i think everyone would get annoyed.
I’ve just posted a new test release to Github which fixes many bugs. Give it a whirl, it should fix this issue.
Just downloaded the latest version from GitHub and gave it a try. I don’t see any difference. I set a breakpoint on line 10, but when I hit run debugger it always starts at 1 and I have no way to actually go to the specific breakpoints.
It would be nice to have a dialog that pops up “You do not have any breakpoints, single step from the beginning?”. Otherwise, it would only stop on the breakpoints specified rather than single stepping entire code line by line.
Other than that, I love how well the debugger was integrated into Sublime. When I spoke with Walter about it, didn’t think it would be so quick or so perfectly executed.
Oh, now I understand. I’m afraid the “start at line 1” behavior is baked into the underlying debugger implementation so that’s how it will work for now (you’ll have to “continue” once to hit your own breakpoint). I plan to improve the debugger a lot (with things like variable watching, run to cursor, etc) and I’ll bear this in mind when I do that.
I can live with it hitting 1 first, be nice not to but that’s not a huge issue if breakpoints work from next step. I can’t find a way to “continue” if I hit step into or step over it will go to line 2, not my first breakpoint.
Just “Run” again when the Debugger is active and it’ll carry on to the next breakpoint.
So, to hit your own breakpoint: Hit F10 to start the Debugger, wait for it to open and then hit F10 again to continue to the first breakpoint.
I fear that my familiarity with debuggers might have made me assume that this is obvious when clearly it isn’t so I’ll think about how to make it easier to discover.
That worked, thanks!
I’m used to use Step Into/Step over to move forward so I didn’t catch onto that.
Maybe just call it “Step” or “Run - Step”
It didn’t even dawn on me that was the step function. I thought it was just a run, maybe a run toggle.
Just wanna vote for the break on line 1 removal in the debugger. It’s really annoying
I’d also like the corona simulator window to take focus until a breakpoint fires so there’s minimal manual window switching. (i’m a UX nut, I know)