Comments on: Want a Debug Hook?
This article is for those REBOLers who want more control over debugging, for IDEs, etc. Do you want a debug hook into the error throw mechanism?
What is it? In R2, when an error happens, the stack is thrown immediately back to a prior predetermined interpreter state and all the state between the error and the catch are discarded. So, there's no way to examine the arguments of the current function, see a backtrace list of functions, etc.
In R3 we can add a debug hook that lets you trap the internal error handler, delaying the throw, and allowing special code to access the interpreter's stack. (Note that this is nothing unusual in most interpreters. In fact, what is unusual is that we've gone this far with REBOL not providing it.)
The stack holds the function context, function arg frame, function word reference (for named functions or pathed functions), the prior frame reference (for unwinding), and computation temporaries. These are all valid REBOL datatypes, so you could in theory access the stack like a block itself. So, a debugging IDE could display all the relevant info, as most programmers would want to see during debug sessions.
Of course, we must also be careful to keep access to this information well abstracted to avoid future compatibility issues, should we want to extend the stack format. That is a big concern we need to address. In addition, we will want to be careful in error cases that put the stack into a questionable state, such as "not enough memory" or "corruption" types of errors ("should not happen").
Note: I should add that there could be some run-time security issues related to such debug hooks (such as searching back the stack for encryption keys, etc.), so this feature may require that the secure function specify that debugging is enabled for debugging sessions. It is too early to know the precise details here, but security is of high priority.
I definitely think the debug hook is a good idea. Personally, I find it hard to debug more complicated REBOL scripts and a stack trace usually helps a lot in other languages. I currently work with debug hooks and debugger backends for an RTOS, so maybe I'm biased, but I think that debugging is a very important issue when it comes to improving REBOL.|
YES! We definitely need better debugging tools, and this would help a lot. Equally important, or maybe even *moreso*, would be thoughts and ideas from Carl, RT in general, or gurus-in-the-know about how best to go about building debugging tools to integrate into REBOL.
For example, look at Henrik's recent test tool; should we look at just logging information to be traced, or can we set watchpoints, break and resume, or build live, reflective monitoring tools.
Also, consider how test tools and engines will interact with these hooks.
I see instrumentation and profiling as closely related, and not for development-time use only.
YES! This is a must to perhaps sometimes get a real REBOL IDE. I think for larger projects this is absolutely necessary!|
Sounds great! We've had to get used to debugging by print statements in REBOL, and it would be nice to have more info available.|
Not sure if it is needed. One of the tricks I use most of the time is using a 'contract replacement of 'func that adds post- and preconditions to the body.
That has turned out to be a major step forward to get my code more robust and it is a quick way to narrow down bugs (and unexpected state).
So I'd vote for a native
contract spec body precondtions postconditions
that throws an error on violating the conditions, much more than a debug hook.
Sounds great. With the stackframes in place, could we have single-step too? Great for learning, we could build a customized 'trace. And how far from saving/loading a whole process to disk would that be? Wenn we can trace the stack, we can find all values. I guess Maarten would like that :)|
Will this debug hook include a debug mode? Then Maarten's contract could check for it and skip the pre/postcondition blocks unless in that mode, or the same with assert, or debug printing. We could leave our test code in then and enable it when required. Of course we can do this now ad-hoc but a global setting would be nice, particularly a standard that could be shared by third-party debugging tools.|
being in the midst of IDE development... I want this big time! :)
if rebol wants to move to "Programming in the Large" then this is required IMHO.
Debugging large, multi-file apps is hard, especially when bugs are thrown within a native or mezzanine... we are currently at a loss!
I've had to implement my own calling stack for post inspection... and it has obvious limitations.
Something this plays into is the concept of AOP (Aspect Oriented Programming). I've read quite a lot about it, but haven't seen the light beyond the hype. Still, the concept of execution flags is appealing. e.g. you have flags that are either set, or not, and blocks that are tagged to execute, or not, in the presence or absence of specific flags. Again, this is something that we have to do manually today.|
And that also ties in to the other thread about constraints and Maarten's contract stuff (at least as it is done in Eiffel).|
Yes, so far I have lived without it ... and missed it now and again. Especially with multiple source files current debug output after in error is far from being helpful.
One other thing I'd really like is better debugging facilities in 'parse. An idea I had just now: make it possible to return the position in the input and in the rule series where the rule didn't match.
I also would like to have debug hooks - some kind of debugging possibilities are better than none and if somebody uses them one day to create a nice debugger - it would be cool.
Also to state here again: Even if Rebol is a scripting language, I think as Maarten pointed out (and somehow proved with his comment) assertions and in particular post- and preconditions (what about object (as we don't have classes) or prototype invariants then to complete it) would be nice to support natively.
Yes, this is definitely something I've been waiting for. Building an effective debugger will be a lot more viable with with hooks into the error throw mechanism. Making it a feature that requires you enable it via the Secure function will also be very helpful.|
a debugging facility only for 'parse in itself would already be a great help|
A week passes and no posts.
Some suggestions: :)
Update rebol.com once a month.
Update Viva La Rebolution blog several times a week, even if to say "here's a link to something cool about growing grapes."
Update Front Line blog at least once a day (Mon- Fri), even if just to say "I'm busy working a tough problem about UTF-8 char handling... wish me luck."
"But if you come at just any time,
I shall never know at what hour
my heart is ready to greet you..."
- The Little Prince
Resolve bug in my rebol code is sometimes a long process if the program is a bit complex. Usually the error happens in a specific case. I've to had some probe, prints, ... and rerun the program and make again all the operations that make the program crash. Sometimes, with a complex GUI interface, it takes minutes and not seconds.
More debug informations when it crash is welcome. But we have to focus on what usefull tools we need to make things that are available with somes IDEs.
- Make breakpoints
- Execute the code steps by step
- View the content of some variables
- View a graphical memory map (Damn, what's take so many space in memory).
We have already some tools (like anamonitor) but maybe, it's easy to enhance them with some modifications of Rebol itself. Ability to get some debug informations but also to dynamicaly control execution of the program and the execution status (I want to trace network right ... now!)
I think the "debug hook" can be a good tool for developpers.
Post a Comment:
You can post a comment here. Keep it on-topic.