You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add proper variable scoping support in the DebugService #28
Currently the DebugService only gathers variables from the local scope when the debugger stops. Ideally all available variable scopes should be provided, both the global scope and all dynamic scopes in between that and the local scope. Non-local scopes should not be expanded by default though. The debugger client will ask for a given scope to be expanded when necessary.
I'm starting to look at this. I really want to have Global, Script and Local nodes in the variables window. This would be very similar to the JavaScript debug variables window:
I propose that we do the following:
Local shows the results of Get-Variable -Scope <number> where number is based on which stackframe has been selected in the Callstack debug window with 0 for the topmost, 1 for the next one down in the list, etc.
Script shows the results of Get-Variable -Scope Script
Global shows the results of Get-Variable -Scope Global
I'm considering filtering out AllScope, Constant variables for all of the above scopes which would remove the useless $true/$false "variables" but that would also remove the following variables as well: ExecutionContext, Host, PID, PSHome, PSVersionTable, ShellId. That seems reasonable to me but would appreciate feedback on this.
Note that I'm suggesting changing the current "Locals" to "Local" because "Scripts" doesn't make sense and I think JavaScript has set a good precedent.
Of those, the only one I imagine is routinely useful for debugging is the ExecutionContext (and maybe Host) -- the rest are actually static, right? However, if I were doing it, I'd leave the AllScope variables in Global.
David Wilson (@daviwil) How about we close this issue and I open three new enhancement issues - variables organization/filtering, indicating which variables have changed values since last debug stop and updating variables when user modifies (or adds) a variable in the debug console.
Activity
rkeithhill commentedon Nov 18, 2015
I'm starting to look at this. I really want to have Global, Script and Local nodes in the variables window. This would be very similar to the JavaScript debug variables window:
I propose that we do the following:
Get-Variable -Scope <number>where number is based on which stackframe has been selected in the Callstack debug window with 0 for the topmost, 1 for the next one down in the list, etc.Get-Variable -Scope ScriptGet-Variable -Scope GlobalI'm considering filtering out
AllScope, Constantvariables for all of the above scopes which would remove the useless$true/$false"variables" but that would also remove the following variables as well:ExecutionContext, Host, PID, PSHome, PSVersionTable, ShellId. That seems reasonable to me but would appreciate feedback on this.Note that I'm suggesting changing the current "Locals" to "Local" because "Scripts" doesn't make sense and I think JavaScript has set a good precedent.
daviwil commentedon Dec 1, 2015
👍 All sounds great to me!
Jaykul commentedon Dec 2, 2015
Of those, the only one I imagine is routinely useful for debugging is the ExecutionContext (and maybe Host) -- the rest are actually static, right? However, if I were doing it, I'd leave the
AllScopevariables in Global.rkeithhill commentedon Dec 3, 2015
David Wilson (@daviwil) How about we close this issue and I open three new enhancement issues - variables organization/filtering, indicating which variables have changed values since last debug stop and updating variables when user modifies (or adds) a variable in the debug console.
daviwil commentedon Dec 3, 2015
Sounds great, thanks!