Re: [Boost-build] Debugger for Jam

Subject: Re: [Boost-build] Debugger for Jam
From: Aaron Boman (aaron_at_[hidden])
Date: 2015-03-22 15:07:02

Hello Steven,

I've been playing around with your debugger. One thing I noticed was
that specifying Jamfile<C:\path\to\my\Jamroot.jam>.my-rule won't work
due to the colon in the path. I temporarily circumvented the problem by
specifying Jamroot.jam:<line-number>. Other than that it works really well.

For the interpreter stuff, I've made similar changes to parse.c and
scan.c, so I'll rebase my changes on top of yours and use the existing
functionality you've provided as its more complete than what I have. I
plan on creating a builtin EXEC_STRING function that will do nothing
more than call parse_string.

What are your thoughts on allowing execution of arbitrary snippets of
code? Perhaps default to interpreter functionality if a valid command
isn't provided? For example, being able to alter the running code by
changing a value. Or another example, being able to import some utility
rule.

On 3/21/2015 11:00 PM, Steven Watanabe wrote:
> As a quick-and-dirty hack, for the interpreter,
> you could replace EXIT with a rule that longjmps
> back to the interpreter's main loop.  What we really
> need for this, though, is exception handling.
> I know errors.jam has try and catch rules.  You
> might try those although they only suppress errors.
> They don't actually unwind the stack.
I meant stdlib's exit(). If someone were to type in a rule name that
hasn't been imported or declared, unknown_rule gets called and
eventually exits:

https://github.com/boostorg/build/blob/30d35ce80db419b54f70c1b9937104994d184871/src/engine/builtins.c#L1109

However, I think your answer is still correct in that exception handling
is needed and would solve the problem. Would the errors.try and
errors.except rules be deprecated in favor of upgrading the grammar and
turning it into a language construct?