Community
Participate
Working Groups
code from HEAD Currently when we initialize the properties on the RhinoDebugger side of things we do so as a flat list of properties - combining the properties from the current Context with those from the global / prototype Contexts. We should better cache these properties so that we can show them in the variable view more sanely - instead of one huge listing of all properties. We also need to serialize them better for clients to make sense of the scope of the properties.
Agree whole heartedly and this single issue is really holding us back as an efficient debugging tool. I'm totally sick of going through the hundred odd global variables to pick out the local variables I actually care about. To me this one is so important we might even consider back-porting it.
(In reply to comment #1) > To me this one is so important we might even consider back-porting it. Agreed. This makes debugging worthless. I'm on it.
I have been playing around with different ways of doing this, and here are my thoughts: 1. we could have the serialized variables contain more data about the scope they belong to, which would not change the overall layout of the of the lookup packet payload - would go from: {properties: {{ref:#,name:"name"}, etc}} to {properties: {{ref:#,name:"name",scope:[closure | local]}, etc}} The advantage of this is that any consumers using RDWP would not be broken and the variable sorting can be pluggable in the front end. The disadvantage of this is the additional repeated wordage in the packet and possibly any additional logic needed on the front end. 2. we could order the serialized properties differently - would go from : {properties: {{ref:#,name:"name"}, etc}} to {properties: {{closure:{ref:#,name:"name"}, etc}},local:{...}} The advantage of this is less repeated wordage and a rather simple re-grouping The disadvantage is it breaks any existing consumers. 3. we could leave the serialization the way it is and change the lookup request to take an optional parameter that would allow us to ask for only local or closure variables, this way if no-one ever expands the 'this' variable we don't send all that data over the wire. The re-grouping can be completely up to the debugger side of things. Simon, Nitin, anyone, have any thoughts?
Created attachment 177547 [details] temp fix This patch does not make any of the three aforementioned changes, instead it prevents the non-enumerable properties from being sent over the wire and only sends the parental ones is the activation context is the 'this' context.
