The last few days involved a lot of cleanup, much of it related to the debugger. I started a more careful review of the user’s guide (with a thought to publishing it via Lulu) and found not only plenty of poor-grade technical writing, but also a few statements that weren’t true, or shouldn’t be.
First and foremost was fixing a problem with the “edge detection” of conditional breakpoints. The BREAK WHEN statement is intended to break at the time that the condition becomes true, but not every statement thereafter when it is still true. This involves tracking both current and new state of each breakpoint on statement boundaries. The problem is that the RESUME statement was clearing the edge condition flags for all breakpoints - this is rarely what the user would want. Now RESUME doesn’t touch the breakpoints, but you can issue RESUME RESET if you really wanted to revisit each breakpoint that is (still) true.
Next was cleaning up the SHOW CALLS command, which not only wasn’t working correctly for code without line numbers but also could benefit from showing the $MODE value for each frame.
Finally, you can call a PROGRAM just like it was a FUNCTION as long as there isn’t a conflicting built-in or user-written function of the same name. This was a side effect of thinking that the CALL..RETURNING sequence was clunky when a function call would do. Along the way, you can now specify RETURNS <type> on the FUNCTION statement if you want to coerce the type of the function result automatically, regardless of the value used in the RETURN statement.
This and ton of cleanup of the first third of the user’s guide gets me closer to the 2.6 release. I think when the user’s guide is complete and I’ve done a little bit more testing with the Java interfaces, I’ll be ready - the 2.6 release will largely focus on the Java interface updates anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The last few days involved a lot of cleanup, much of it related to the debugger. I started a more careful review of the user’s guide (with a thought to publishing it via Lulu) and found not only plenty of poor-grade technical writing, but also a few statements that weren’t true, or shouldn’t be.
First and foremost was fixing a problem with the “edge detection” of conditional breakpoints. The BREAK WHEN statement is intended to break at the time that the condition becomes true, but not every statement thereafter when it is still true. This involves tracking both current and new state of each breakpoint on statement boundaries. The problem is that the RESUME statement was clearing the edge condition flags for all breakpoints - this is rarely what the user would want. Now RESUME doesn’t touch the breakpoints, but you can issue RESUME RESET if you really wanted to revisit each breakpoint that is (still) true.
Next was cleaning up the SHOW CALLS command, which not only wasn’t working correctly for code without line numbers but also could benefit from showing the $MODE value for each frame.
Finally, you can call a PROGRAM just like it was a FUNCTION as long as there isn’t a conflicting built-in or user-written function of the same name. This was a side effect of thinking that the CALL..RETURNING sequence was clunky when a function call would do. Along the way, you can now specify RETURNS <type> on the FUNCTION statement if you want to coerce the type of the function result automatically, regardless of the value used in the RETURN statement.
This and ton of cleanup of the first third of the user’s guide gets me closer to the 2.6 release. I think when the user’s guide is complete and I’ve done a little bit more testing with the Java interfaces, I’ll be ready - the 2.6 release will largely focus on the Java interface updates anyway.