> ON thinking about this some more, I don't know if what you want to do
> is possible.
I don't either and I'd like to bounce some ideas off of you before I get too deep into this. But let me start
off by saying that the results I've got so far are quite positive, and that it seems to me my goal is
achievable. Stating the goal, I want to drive the debugging process (almost) entirely from my editor --
ultimately leading to an integrated IDE, but that's another story (and I'm not so interested in going to
far).
I view the ScriptDebug window as a complete debugging facility, because:
- in addition to setting static and dynamic breakpoints
- I can set dynamic expressions with exec.scriptdebugfield, and get them evaluted in the context of the
debugged script (arg(i) too, I think)
- I can retrieve the evaluated values -- with some limitations which, I hope, you will want to smooth out
in the future. For now the attached (unpolished) script can retrieve all the values in the ScriptDebug
window, effectively it transforms that window in a debugging engine for any debugging session.
The most frequest technical hurdles I'm facing are:
- taming focus -- the ScriptDebug window just doesn't cooperate and I'm not experienced enough to
know all the tricks. The focus issue may seem like a minor one, but if I can't get it resolved reliably than
there's no point in controlling the debugger from an editor.
- synchronization, that is knowing when the ScriptDebug window is ready to receive input. Since it may
take any amount of time to evaluate an _expression_, there is (currently) no way to know when it will be
available to take *keys sent to step it. The attached function is a perfect example. It works perfectly
when the ScriptDebug window is idle, but this simple scriplet will easily break the result:
*keys {to ^PowerPro Script Debug}{alt}s ;; step
;; step may take an arbitrary amount of time
[EMAIL PROTECTED](0)
;; dbgInfo returns the contents of the ScriptDebug window
;; trouble is that if the ScriptDebug window is still busy taking
;; the preceeding step, dbgInfo(0) will return a lot of empty fields
If I could figure out how to solve those two, I think my goal should be enabled. I _think_, unless there
are other major issues that I haven't thought of.
FYI, in my current implementation I don't hook into OnScriptDebug. I was using the hook before, but
that lends itself better to controlling the editor from the debugger, which is still very possible, but more
limited in the way of user interaction and editor/IDE integration. Also I think when there is no hook it's
easier to understand what's going on in the overall system.
I've also started to experiment a hybrid system, hook sometimes but don't hook most of the time -- too
early to give you a report.
> For example, you are right that you cannot evaluate arg
> (i) from within another script since it will reference the script
> running, no the context of the debugged script. Also, if you use a
> script to push the step button on the PowerPro dialog, it will start
> debugging the running script that pushed the button.
At the moment what I do is:
- user presses <F12> in vim editor window with powerpro script open - means "start debugging this
powerpro script"
- vim script figures out which @label the user wants to run, builds (actually powerpro does this) a
dbgr_session.powerpro script, turns on ScriptDebug and launches dbgr_session. Press 'step' once and
you're right into debugging the original script
- press <F7> to step through your code. Each step makes editor and ScriptDebug cooperate to update
the display, evaluate expressions, etc.
When I want to debug a hotkey or bar then I use the OnScriptDebug hook:
- press active bar button that turns on hooked ScriptDebug
- press hotkey, or whatever to initiate the debugger target
- ScriptDebug runs automatically and still drives my editor
- in this case I prefer to use [Step] in ScriptDebug window, although ultimately I want to be able to
move freely between <F7> and [Step]. It does work that way already, but the focus and synchronization
issues that I mentioned get in the way.
>
> I don't think it is possible to write a PowerPro debugger in a
> PowerPro script. You'd need to write a plugin.
Plugin! Is it easier or at least easy enough? What's the learning curve? It seems to me that writing
powerpro plugins is not for the faint of heart, and that there are very scarce resources to tap into. That's
one of the reasons why I've stayed away from plugins. Other reasons include, I don't know Windows
internals, and I enjoy programming intrepreted languages more that compiled languages.
Bruce, once again thank you for bearing with me so far. I certainly will understand if you won't find the
time or the interest to continue; and I'll be grateful for anything more you will want to offer, in the way
of technical advice, expanded ScriptDebug features, and even coaching!
--sgp
Attention: PowerPro's Web site has moved: http://www.ppro.org
SPONSORED LINKS
| Computer monitoring software | Power pro | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "power-pro" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
