PureBasic Forums - English

In other BASICs, there's (usually) a command called "Tron" (which is why the movie was called that) which turns a visual "TRace ON" of your source code. "TRace OFF" turns it off again. What it does, is when your program is running, the IDE moves through your source code in realtime, highlighting the current line that is being executed.

This would be great to have for the IDE, because it means we can do away with adding "Debug" and "CallDebugger" commands where we THINK a bug is occurring, and it enables us to find (some) bugs very quickly. For example, in another of my posts I mention that my program was hanging and I didn't know why for a very long time. Eventually I discovered (by accident) that the PurePOP3_IsMessageHTML() command (of the PurePOP3 library) was going into an infinite loop, and I was only able to see that by putting a "Debug" before and after it. In other words, it was pure luck that I found the bug!

If a command like Tron was available, then the IDE would've shown me that PurePOP3_IsMessageHTML() was currently being executed, and the Tron highlighting of that command would just be sitting there for longer than expected, thus alerting me to the fact that the command was looping endlessly. The problem would've been found in 5 seconds instead of over a week.

(You probably know this but) if you're using PB's debugger, you can press Pause and the current line of code will be highlighted. You can also step through and execute it one line at a time. There are also breakpoints you can add, etc. etc. etc.

If you highlighted the active line of code, in real-time, without pausing, wouldn't the screen just be a blur of scrolling text?

How would you suggest this would work with multiple threads?

With multiple threads the IDE could highlight the lines in different colors. But its too fast for humans afaik.

I really expected something else when I read the title of this topic. A mix of tron and hoff .

@Mistrel: It would work with multiple threads the same way pausing and stepping the code currently works with threads.

@kenmo: Pausing the debugger doesn't always work as expected. In my case, when my program was hanging on the PurePOP3_IsMessageHTML() command, pressing Pause didn't go to it. The debugger was just hung. Even stepping didn't work because it wasn't enabled on the toolbar. That's mainly the reason I made this request, so that I could see the program flow and see where it "locked up".

As for the screen being a blur of scrolling text, what I recall from my C64 days was that when Tron was called, each line was executed after a slight delay (probably 100 ms), so you could see the current line before the next one was executed, and obviously with your program running slower. And it wasn't the screen jumping around the editor; it was just the line displayed at the bottom. And it definitely helped find bugs! The PureBasic debugger could do the same. Sort of like an auto-step but with a slight delay added, and the editor going to the line in question.

[Update] I just saw this on Wikipedia: http://en.wikipedia.org/wiki/TRON_command . Wikipedia mentions the line only was displayed, but the version of BASIC I was using definitely showed the whole line too, at the bottom of the screen. It was some sort of enhanced BASIC editor, I think from Compute! magazine or such.

DarkDragon wrote: I really expected something else when I read the title of this topic. A mix of tron and hoff .

The Hoff in a tron suit? That would be epic!
But it have to be one from the old movie.

C64 wrote: ...
As for the screen being a blur of scrolling text, what I recall from my C64 days was that when Tron was called, each line was executed after a slight delay (probably 100 ms), so you could see the current line before the next one was executed, and obviously with your
...

You want a scroll wheel to speed up or slow down program execution of the sections that are marked 'tron / troff'.

Perhaps. But the idea is not to manually press or scroll anything. The idea is to watch your app step through each command by itself, at a fast rate but slow enough to keep track of the flow. It's so much easier to debug your program when you can see it working at a human-readable speed. You're watching the guts of it as it happens, instead of setting breakpoints where you <i>think</i> (and hope!) a bug might be occurring.

All we need to implement my wish would be for the debugger "Step" command to have an auto-step option, with a user-defined delay after each step. I could then run my program, and have it auto-step at 100 ms intervals. Niiiiiiiiiice!

Ah, I see, that might make sense, yes. An additonal 'Slowmotion' or 'AutoStep' button, where the slow motion speed can be set by the user. For all other purposes it behaves like the regular step function.

In addition, you'd probably want a parameter for CallDebugger so you can selectively start and stop the autostep mode...

CallDebugger Slow (or CallDebugger AutoStep or Tron or whatever)
CallDebugger Continue (or CallDebugger Troff or whatever)

There you have your Tron / Troff function... I like the idea, it would indeed save time looking for logical bugs.

C64 wrote:All we need to implement my wish would be for the debugger "Step" command to have an auto-step option, with a user-defined delay after each step. I could then run my program, and have it auto-step at 100 ms intervals. Niiiiiiiiiice!

+1

+1

OllyDbg has this feature, which it calls Animate (you can modify the Step Into delay, eg 100ms). It looks cool, but looking cool is literally the only use for it I've ever found

I am more interested in the debugger retaining content on STOP.
And better support for threaded app stepping.
Just like autopilot OFF, I want to drive this puppy!

Not related to the step,
I am more interested of being able to change a variable value on a breakpoint to test a special condition.

Not gonna lie, Edit and Continue was a timesaver in Visual Studio.
But, PB compiles fast enough to accomplish rapid prototyping.
Definitely curious how emitting C will impact the debug flow.