Ember.js discussion notes

[Dave Camp]

A few of the SF-based and SF-visiting devtoolers (anton, harth, fitzgen,
and I) had lunch with some ember.js developers (Yehuda Katz, Tom Dale, and
Erik Bryn). I took very sparse notes, but here's what I remember of the
discussion. Please chime in if you were there and I got something wrong or
missed something.

If one of these things falls in your area, could you please file the
appropriate bugs and followup to the list?

= Object Display/Remote Protocol Extension =

The ember.js folks have a chrome devtools extension to customize display of
ember.js objects for developers using the framework. We haven't gone down
the road of SDK/API support yet, although it's one of the topics for the
March 11th work week.

Yehuda said he could give us a writeup about the kinds of things they want
to be able to do to customize the tools to their framework, but we can also
just look at their chrome addon for ideas.

= Memory Tools =

In addition to the traditional problems of leaking/retaining excessive
memory (which has a reasonable amount of tool support in chrome, and
planned support in our tools), they've also run in to problems with
generating excessive garbage, leading to gc churn. So in addition to plans
we have for tools to help understand the object graph that is being
retained, we need tools for understanding what *isn't* retained, what's
being collected. This isn't a new problem - early versions of Firefox Sync
had fairly serious problems with excess garbage. Diagnosing this can be
tough, we should help out here.

= Native Code in the Profiler =

Confirming what we've already mostly agreed on: they want to be able to
look at a profile that contains native stacks. Limiting solely to js makes
it tougher to blame slow platform code, and slow platform code means slow
application code.

= Closure Optimization =

JS VMs optimize closures if they can prove that the closed-over code won't
access some members of the environment. This leads to a terrible debugging
experience:

var a = 1, b = 2;
executeSoon(function() {
console.log(a);
debugger; // b won't be visible in the environment when this debugger
statement is hit.
});

At the very minimum, we need to warn that b was optimized out, rather than
just confusing developers that think they should be able to access b in
that scope (this is filed as bug 841622). Ideally these optimizations
wouldn't happen in debug mode, although there's a performance penalty
there. This is filed as bug 841625.

= Filtered Stacks =

We talked about marking a library (ember.js, jquery, whatever) as a black
box. Once marked as a black box, code from those libraries would be
squished to a single stack frame, and step into/step out would skip frames
in that library, etc.

I think this would be pretty easy to do in the debug server, the trickiest
part would probably be identifying which sources should get this
treatment. Thoughts?

= Async Stacks =

We've wanted this for awhile, hopefully there's a bug on file already that
I can't find: Tracing asynchronous code sucks. When you call setTimeout
or addEventListener, the debugger should note your current stack alongside
that call. When you hit a breakpoint in that function, the debugger should
be able to display the stack trace that led to the
setTimeout/addEventListener/XHR/whatever being called.

We should also let content scripts tag a given call point as worth
capturing a stack for.

[wyc...@gmail.com]

On Tuesday, February 19, 2013 5:07:34 PM UTC-8, Dave Camp wrote:

> A few of the SF-based and SF-visiting devtoolers (anton, harth, fitzgen,
> and I) had lunch with some ember.js developers (Yehuda Katz, Tom Dale, and
> Erik Bryn). I took very sparse notes, but here's what I remember of the
> discussion. Please chime in if you were there and I got something wrong or
> missed something.
>
> If one of these things falls in your area, could you please file the
> appropriate bugs and followup to the list?
>
> = Object Display/Remote Protocol Extension =
>
> The ember.js folks have a chrome devtools extension to customize display of
> ember.js objects for developers using the framework. We haven't gone down
> the road of SDK/API support yet, although it's one of the topics for the
> March 11th work week.
>
> Yehuda said he could give us a writeup about the kinds of things they want
> to be able to do to customize the tools to their framework, but we can also
> just look at their chrome addon for ideas.

The most important customization points are:

* Ability to filter out properties that reflect internals (in many libraries, this will amount to filtering properties beginning with _)
* Ability for getters and setters to be lazily computed and presented
* Ability to supply a property descriptor for a property that is used to present data. This would allow Ember (and Backbone, and Knockout, etc.) to present properties that are designed to be used with `get` as getters and use the getter UI that I described above.
* Ability to supply additional metadata that should be presented together with the properties. For example, Ember Data may want the ability to show model attributes and relationships, regardless of how they are actually represented in the object structure.
* Ability to represent an alternative object hierarchy. For example, Ember supports a mixin system (and other libraries support trait-like systems) that are flattened into the prototype hierarchy. Some hook that would allow the display of the prototype hierarchy to be controlled by code.

If there is interest, I could provide some straw-man APIs that would satisfy some of these requirements.

> = Memory Tools =
>
> In addition to the traditional problems of leaking/retaining excessive
> memory (which has a reasonable amount of tool support in chrome, and
> planned support in our tools), they've also run in to problems with
> generating excessive garbage, leading to gc churn. So in addition to plans
> we have for tools to help understand the object graph that is being
> retained, we need tools for understanding what *isn't* retained, what's
> being collected. This isn't a new problem - early versions of Firefox Sync
> had fairly serious problems with excess garbage. Diagnosing this can be
> tough, we should help out here.

Erik Bryn and Kris Selden, who do a lot of our performance work, are desperate for this feature :)

> = Native Code in the Profiler =
>
> Confirming what we've already mostly agreed on: they want to be able to
> look at a profile that contains native stacks. Limiting solely to js makes
> it tougher to blame slow platform code, and slow platform code means slow
> application code.

We mentioned that it may be nice for the native code to be representable as a single frame, so we can see that, for example, our code is calling indexOf and costing 10ms, but not have to worry exactly how indexOf is implemented.

> = Closure Optimization =
>
> JS VMs optimize closures if they can prove that the closed-over code won't
> access some members of the environment. This leads to a terrible debugging
> experience:
>
> var a = 1, b = 2;
> executeSoon(function() {
> console.log(a);
> debugger; // b won't be visible in the environment when this debugger
> statement is hit.
> });
>
> At the very minimum, we need to warn that b was optimized out, rather than
> just confusing developers that think they should be able to access b in
> that scope (this is filed as bug 841622). Ideally these optimizations
> wouldn't happen in debug mode, although there's a performance penalty
> there. This is filed as bug 841625.

We also mentioned that the same issue happens when `arguments` is optimized out.

I'm no VM guy, but one approach might be to treat every frame as though it contained
an explicit call to `eval` when the debugger is open (or perhaps for a whitelisted list
of domains including localhost).

> = Filtered Stacks =
>
> We talked about marking a library (ember.js, jquery, whatever) as a black
> box. Once marked as a black box, code from those libraries would be
> squished to a single stack frame, and step into/step out would skip frames
> in that library, etc.
>
> I think this would be pretty easy to do in the debug server, the trickiest
> part would probably be identifying which sources should get this
> treatment. Thoughts?

We would love this feature. In the future, it could also be nice to be able to
tag the filtered stacks with a particular name, and filter out only Ember but
not other internal details. This is not important for initial implementation.

> = Async Stacks =
>
> We've wanted this for awhile, hopefully there's a bug on file already that
> I can't find: Tracing asynchronous code sucks. When you call setTimeout
> or addEventListener, the debugger should note your current stack alongside
> that call. When you hit a breakpoint in that function, the debugger should
> be able to display the stack trace that led to the
> setTimeout/addEventListener/XHR/whatever being called.
>
> We should also let content scripts tag a given call point as worth
> capturing a stack for.

Straw man proposal:

function later() {
console.log("hi");
}

later.tagStack();

// this defers this code until after the remaining application code is called,
// but does not use the browser's async mechanisms, so built-in support
// for setTimeout, etc. would not be sufficient
Ember.run.once(later);

[wyc...@gmail.com]

On Tuesday, February 19, 2013 5:07:34 PM UTC-8, Dave Camp wrote:

> A few of the SF-based and SF-visiting devtoolers (anton, harth, fitzgen,
> and I) had lunch with some ember.js developers (Yehuda Katz, Tom Dale, and
> Erik Bryn). I took very sparse notes, but here's what I remember of the
> discussion. Please chime in if you were there and I got something wrong or
> missed something.
>
> If one of these things falls in your area, could you please file the
> appropriate bugs and followup to the list?
>
> = Object Display/Remote Protocol Extension =
>
> The ember.js folks have a chrome devtools extension to customize display of
> ember.js objects for developers using the framework. We haven't gone down
> the road of SDK/API support yet, although it's one of the topics for the
> March 11th work week.
>
> Yehuda said he could give us a writeup about the kinds of things they want
> to be able to do to customize the tools to their framework, but we can also
> just look at their chrome addon for ideas.

The most important customization points are:

* Ability to filter out properties that reflect internals (in many libraries, this will amount to filtering properties beginning with _)
* Ability for getters and setters to be lazily computed and presented
* Ability to supply a property descriptor for a property that is used to present data. This would allow Ember (and Backbone, and Knockout, etc.) to present properties that are designed to be used with `get` as getters and use the getter UI that I described above.
* Ability to supply additional metadata that should be presented together with the properties. For example, Ember Data may want the ability to show model attributes and relationships, regardless of how they are actually represented in the object structure.
* Ability to represent an alternative object hierarchy. For example, Ember supports a mixin system (and other libraries support trait-like systems) that are flattened into the prototype hierarchy. Some hook that would allow the display of the prototype hierarchy to be controlled by code.

If there is interest, I could provide some straw-man APIs that would satisfy some of these requirements.

> = Memory Tools =
>
> In addition to the traditional problems of leaking/retaining excessive
> memory (which has a reasonable amount of tool support in chrome, and
> planned support in our tools), they've also run in to problems with
> generating excessive garbage, leading to gc churn. So in addition to plans
> we have for tools to help understand the object graph that is being
> retained, we need tools for understanding what *isn't* retained, what's
> being collected. This isn't a new problem - early versions of Firefox Sync
> had fairly serious problems with excess garbage. Diagnosing this can be
> tough, we should help out here.

Erik Bryn and Kris Selden, who do a lot of our performance work, are desperate for this feature :)

> = Native Code in the Profiler =
>
> Confirming what we've already mostly agreed on: they want to be able to
> look at a profile that contains native stacks. Limiting solely to js makes
> it tougher to blame slow platform code, and slow platform code means slow
> application code.

We mentioned that it may be nice for the native code to be representable as a single frame, so we can see that, for example, our code is calling indexOf and costing 10ms, but not have to worry exactly how indexOf is implemented.

> = Closure Optimization =
>
> JS VMs optimize closures if they can prove that the closed-over code won't
> access some members of the environment. This leads to a terrible debugging
> experience:
>
> var a = 1, b = 2;
> executeSoon(function() {
> console.log(a);
> debugger; // b won't be visible in the environment when this debugger
> statement is hit.
> });
>
> At the very minimum, we need to warn that b was optimized out, rather than
> just confusing developers that think they should be able to access b in
> that scope (this is filed as bug 841622). Ideally these optimizations
> wouldn't happen in debug mode, although there's a performance penalty
> there. This is filed as bug 841625.

We also mentioned that the same issue happens when `arguments` is optimized out.

I'm no VM guy, but one approach might be to treat every frame as though it contained
an explicit call to `eval` when the debugger is open (or perhaps for a whitelisted list
of domains including localhost).

> = Filtered Stacks =
>
> We talked about marking a library (ember.js, jquery, whatever) as a black
> box. Once marked as a black box, code from those libraries would be
> squished to a single stack frame, and step into/step out would skip frames
> in that library, etc.
>
> I think this would be pretty easy to do in the debug server, the trickiest
> part would probably be identifying which sources should get this
> treatment. Thoughts?

We would love this feature. In the future, it could also be nice to be able to
tag the filtered stacks with a particular name, and filter out only Ember but
not other internal details. This is not important for initial implementation.

> = Async Stacks =
>
> We've wanted this for awhile, hopefully there's a bug on file already that
> I can't find: Tracing asynchronous code sucks. When you call setTimeout
> or addEventListener, the debugger should note your current stack alongside
> that call. When you hit a breakpoint in that function, the debugger should
> be able to display the stack trace that led to the
> setTimeout/addEventListener/XHR/whatever being called.
>
> We should also let content scripts tag a given call point as worth
> capturing a stack for.

[Joe Walker]

Thanks Yehuda,

On 20 Feb 2013, at 03:05, wyc...@gmail.com wrote:
>> = Memory Tools =
>>
>> In addition to the traditional problems of leaking/retaining excessive
>> memory (which has a reasonable amount of tool support in chrome, and
>> planned support in our tools), they've also run in to problems with
>> generating excessive garbage, leading to gc churn. So in addition to plans
>> we have for tools to help understand the object graph that is being
>> retained, we need tools for understanding what *isn't* retained, what's
>> being collected. This isn't a new problem - early versions of Firefox Sync
>> had fairly serious problems with excess garbage. Diagnosing this can be
>> tough, we should help out here.
>
> Erik Bryn and Kris Selden, who do a lot of our performance work, are desperate for this feature :)

And just to chime in on how important this is, we've had internal problems with unit tests that can out-run the GC, causing test failures through timeouts.
Which leads me to wonder if the solution to this problem isn't to look at what's collected in each GC pause, and for cases where there is more than X objects/space cleared, we alert to the user what we cleared in some way.

>> = Async Stacks =
>>
>> We've wanted this for awhile, hopefully there's a bug on file already that
>> I can't find: Tracing asynchronous code sucks. When you call setTimeout
>> or addEventListener, the debugger should note your current stack alongside
>> that call. When you hit a breakpoint in that function, the debugger should
>> be able to display the stack trace that led to the
>> setTimeout/addEventListener/XHR/whatever being called.
>>
>> We should also let content scripts tag a given call point as worth
>> capturing a stack for.
>
> Straw man proposal:
>
> function later() {
> console.log("hi");
> }
>
> later.tagStack();
>
> // this defers this code until after the remaining application code is called,
> // but does not use the browser's async mechanisms, so built-in support
> // for setTimeout, etc. would not be sufficient
> Ember.run.once(later);

I wrote a promise implementation a while back that had basic support for this, but clearly it makes sense to do it at a system level. We'd have an interesting problem that each addEventListener/setTimeout/XHR/etc was itself caused by an event which was caused by another addEventListener/setTimeout/XHR/etc. So everything would eventually lead back to a few root causes: onLoad/onDomReady/etc I don't think that's a problem, but we'd need to understand how this would scale both from a memory POV and a UX POV.

Joe.

[Fitzgerald, Nick]

On 2/22/13 2:20 AM, Joe Walker wrote:
>>> >>= Async Stacks =
>>> >>
>>> >>We've wanted this for awhile, hopefully there's a bug on file already that
>>> >>I can't find: Tracing asynchronous code sucks. When you call setTimeout
>>> >>or addEventListener, the debugger should note your current stack alongside
>>> >>that call. When you hit a breakpoint in that function, the debugger should
>>> >>be able to display the stack trace that led to the
>>> >>setTimeout/addEventListener/XHR/whatever being called.
>>> >>
>>> >>We should also let content scripts tag a given call point as worth
>>> >>capturing a stack for.
>> >
>> >Straw man proposal:
>> >
>> > function later() {
>> > console.log("hi");
>> > }
>> >
>> > later.tagStack();
>> >
>> > // this defers this code until after the remaining application code is called,
>> > // but does not use the browser's async mechanisms, so built-in support
>> > // for setTimeout, etc. would not be sufficient
>> > Ember.run.once(later);

> I wrote a promise implementation a while back that had basic support for this, but clearly it makes sense to do it at a system level. We'd have an interesting problem that each addEventListener/setTimeout/XHR/etc was itself caused by an event which was caused by another addEventListener/setTimeout/XHR/etc. So everything would eventually lead back to a few root causes: onLoad/onDomReady/etc I don't think that's a problem, but we'd need to understand how this would scale both from a memory POV and a UX POV.

I think it would be best to avoid modifying prototypes, especially when
our tools shouldn't really be modifying the environment that the code is
running in if we can avoid it.

Better IMO to add |console.tagStack|, which takes a function and returns
a new function, and we can do all the bookkeeping of stacks internally,
possibly using weak maps.

Nick

[Dave Camp]

On Tue, Feb 19, 2013 at 7:05 PM, <wyc...@gmail.com> wrote:

>
> Straw man proposal:
>
> function later() {
> console.log("hi");
> }
>
> later.tagStack();
>
> // this defers this code until after the remaining application code is
> called,
> // but does not use the browser's async mechanisms, so built-in support
> // for setTimeout, etc. would not be sufficient
> Ember.run.once(later);

> ______________________



Do you think this will be error prone/confusion in the following case?

--

function sharedHandler() {
console.log("hi");
}

function firstThing() {
sharedHandler.tagStack();
callLater(sharedHandler);
}

function secondThing() {
sharedHandler.tagStack();
callLater(sharedHandler);
}

firstThing();
secondThing();
---
If the stack is stored on the function, we'll get two secondThing() stacks?

I was imagining something along the lines of F.p.bind() that returns a
tagged wrapper function:

function firstThing() {
callLater(sharedHandler.tagStack());
}

or, as Nick proposed,

callLater(console.tagStack(sharedHandler));

[Schalk Neethling]

NB!!Off-Topic

Possible silly question but, what does the tagStack function do and
where can I find some more info on it? I see it mentioned all over this
topic but, cannot find any useful info on it.

Is it part of devtools, ember.... Thanks!

On 2/26/13 7:07 PM, Dave Camp wrote:
> On Tue, Feb 19, 2013 at 7:05 PM, <wyc...@gmail.com> wrote:
>
>>

>> Straw man proposal:
>>
>> function later() {
>> console.log("hi");
>> }
>>
>> later.tagStack();
>>
>> // this defers this code until after the remaining application code is
>> called,
>> // but does not use the browser's async mechanisms, so built-in support
>> // for setTimeout, etc. would not be sufficient
>> Ember.run.once(later);

>> ______________________
>
>
>
> Do you think this will be error prone/confusion in the following case?
>
> --
>
> function sharedHandler() {
> console.log("hi");
> }
>
> function firstThing() {
> sharedHandler.tagStack();
> callLater(sharedHandler);
> }
>
> function secondThing() {
> sharedHandler.tagStack();
> callLater(sharedHandler);
> }
>
> firstThing();
> secondThing();
> ---
> If the stack is stored on the function, we'll get two secondThing() stacks?
>
> I was imagining something along the lines of F.p.bind() that returns a
> tagged wrapper function:
>
> function firstThing() {
> callLater(sharedHandler.tagStack());
> }
>
> or, as Nick proposed,
>
> callLater(console.tagStack(sharedHandler));

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

--
Kind Regards,
Schalk Neethling
Front-End Engineer
Mozilla

[Panos Astithas]

It's a proposed new method that will let the developer give our tools a
hint that the stack trace at that point should be preserved and combined
later with the current stack at the event handler.

On Wed, Feb 27, 2013 at 5:02 PM, Schalk Neethling <sneet...@mozilla.com>wrote:

> NB!!Off-Topic
>
> Possible silly question but, what does the tagStack function do and where
> can I find some more info on it? I see it mentioned all over this topic
> but, cannot find any useful info on it.
>
> Is it part of devtools, ember.... Thanks!
>
>
> On 2/26/13 7:07 PM, Dave Camp wrote:
>
>> On Tue, Feb 19, 2013 at 7:05 PM, <wyc...@gmail.com> wrote:
>>
>>

>>> Straw man proposal:
>>>
>>> function later() {
>>> console.log("hi");
>>> }
>>>
>>> later.tagStack();
>>>
>>> // this defers this code until after the remaining application code is
>>> called,
>>> // but does not use the browser's async mechanisms, so built-in
>>> support
>>> // for setTimeout, etc. would not be sufficient
>>> Ember.run.once(later);

>>> ______________________
>>>
>>
>>
>>
>> Do you think this will be error prone/confusion in the following case?
>>
>> --
>>
>> function sharedHandler() {
>> console.log("hi");
>> }
>>
>> function firstThing() {
>> sharedHandler.tagStack();
>> callLater(sharedHandler);
>> }
>>
>> function secondThing() {
>> sharedHandler.tagStack();
>> callLater(sharedHandler);
>> }
>>
>> firstThing();
>> secondThing();
>> ---
>> If the stack is stored on the function, we'll get two secondThing()
>> stacks?
>>
>> I was imagining something along the lines of F.p.bind() that returns a
>> tagged wrapper function:
>>
>> function firstThing() {

>> callLater(sharedHandler.**tagStack());
>> }
>>
>> or, as Nick proposed,
>>
>> callLater(console.tagStack(**sharedHandler));
>> ______________________________**_________________
>> dev-developer-tools mailing list
>> dev-developer-tools@lists.**mozilla.org<dev-devel...@lists.mozilla.org>
>> https://lists.mozilla.org/**listinfo/dev-developer-tools<https://lists.mozilla.org/listinfo/dev-developer-tools>

>>
>>
> --
> Kind Regards,
> Schalk Neethling
> Front-End Engineer
> Mozilla
>

> ______________________________**_________________
> dev-developer-tools mailing list
> dev-developer-tools@lists.**mozilla.org<dev-devel...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-developer-tools<https://lists.mozilla.org/listinfo/dev-developer-tools>
>

[Steven Roussey]

On Tuesday, February 19, 2013 7:05:28 PM UTC-8, wyc...@gmail.com wrote:
> The most important customization points are:
>
>
>
> * Ability to filter out properties that reflect internals (in many libraries, this will amount to filtering properties beginning with _)

In Illuminations, I just grey these out. But removing them as an option, is a good idea too.

> * Ability for getters and setters to be lazily computed and presented

Yeah... have ideas on how to show this?

> * Ability to supply additional metadata that should be presented together with the properties. For example, Ember Data may want the ability to show model attributes and relationships, regardless of how they are actually represented in the object structure.

Illuminations does this. Sometimes I have to dereference a level. For Example, ExtJS can have a store of records and internally use a Map to hold them. It is a pain to make the user dig through that, so these are skipped over. I don't know what a built-in tool should do. My personal experience when dealing with a bunch of frameworks is that they they all have completely different idiosyncrasies.

> * Ability to represent an alternative object hierarchy. For example, Ember supports a mixin system (and other libraries support trait-like systems) that are flattened into the prototype hierarchy. Some hook that would allow the display of the prototype hierarchy to be controlled by code.

I break things out my named prototype chains. Is that what you mean? Or am I missing something? To make this work best, you should add properties to the correct prototype even if the value is undefined. I may start altering Ember.JS and others to do this as they load when the page loads. I already have to mangle some things since Backbone is so dumb.

> If there is interest, I could provide some straw-man APIs that would satisfy some of these requirements.

Well, I'm curious on your thoughts. I'm working on v2 today.

> We also mentioned that the same issue happens when `arguments` is optimized out.

Is this something with the built-in tools? This was an issue way back in the day with Firebug, but I thought it was fixed long ago. I remember JSC did not have this issue while V8 did, confusing things on the webkit side.

> > = Filtered Stacks =
>
> >
>
> > We talked about marking a library (ember.js, jquery, whatever) as a black
>
> > box. Once marked as a black box, code from those libraries would be
>
> > squished to a single stack frame, and step into/step out would skip frames
>
> > in that library, etc.
>
> >
>
> > I think this would be pretty easy to do in the debug server, the trickiest
>
> > part would probably be identifying which sources should get this
>
> > treatment. Thoughts?
>
>
>
> We would love this feature. In the future, it could also be nice to be able to
>
> tag the filtered stacks with a particular name, and filter out only Ember but
>
> not other internal details. This is not important for initial implementation.

I had altered Firebug at one point to skip over some things in the stack -- things like "bind" functions, etc. I may add that back into Illuminations, since I can do it for specific functions from specific frameworks.

> > = Async Stacks =
>
> >
>
> > We've wanted this for awhile, hopefully there's a bug on file already that
>
> > I can't find: Tracing asynchronous code sucks. When you call setTimeout
>
> > or addEventListener, the debugger should note your current stack alongside
>
> > that call. When you hit a breakpoint in that function, the debugger should
>
> > be able to display the stack trace that led to the
>
> > setTimeout/addEventListener/XHR/whatever being called.
>
> >
>
> > We should also let content scripts tag a given call point as worth
>
> > capturing a stack for.
>
>
>
> Straw man proposal:
>
>
>
> function later() {
>
> console.log("hi");
>
> }
>
>
>
> later.tagStack();
>
>
>
> // this defers this code until after the remaining application code is called,
>
> // but does not use the browser's async mechanisms, so built-in support
>
> // for setTimeout, etc. would not be sufficient
>
> Ember.run.once(later);

For reference:

https://code.google.com/p/fbug/issues/detail?id=3973
https://github.com/tlrobinson/long-stack-traces

-steve--

[Steven Roussey]

On Tuesday, February 19, 2013 7:05:28 PM UTC-8, wyc...@gmail.com wrote:

> The most important customization points are:
>
>
>
> * Ability to filter out properties that reflect internals (in many libraries, this will amount to filtering properties beginning with _)

In Illuminations, I just grey these out. But removing them as an option, is a good idea too.

> * Ability for getters and setters to be lazily computed and presented

Yeah... have ideas on how to show this?

> * Ability to supply additional metadata that should be presented together with the properties. For example, Ember Data may want the ability to show model attributes and relationships, regardless of how they are actually represented in the object structure.

Illuminations does this. Sometimes I have to dereference a level. For Example, ExtJS can have a store of records and internally use a Map to hold them. It is a pain to make the user dig through that, so these are skipped over. I don't know what a built-in tool should do. My personal experience when dealing with a bunch of frameworks is that they they all have completely different idiosyncrasies.

> * Ability to represent an alternative object hierarchy. For example, Ember supports a mixin system (and other libraries support trait-like systems) that are flattened into the prototype hierarchy. Some hook that would allow the display of the prototype hierarchy to be controlled by code.

I break things out my named prototype chains. Is that what you mean? Or am I missing something? To make this work best, you should add properties to the correct prototype even if the value is undefined. I may start altering Ember.JS and others to do this as they load when the page loads. I already have to mangle some things since Backbone is so dumb.

> If there is interest, I could provide some straw-man APIs that would satisfy some of these requirements.

Well, I'm curious on your thoughts. I'm working on v2 today.

> We also mentioned that the same issue happens when `arguments` is optimized out.

Is this something with the built-in tools? This was an issue way back in the day with Firebug, but I thought it was fixed long ago. I remember JSC did not have this issue while V8 did, confusing things on the webkit side.

> > = Filtered Stacks =
>
> >
>
> > We talked about marking a library (ember.js, jquery, whatever) as a black
>
> > box. Once marked as a black box, code from those libraries would be
>
> > squished to a single stack frame, and step into/step out would skip frames
>
> > in that library, etc.
>
> >
>
> > I think this would be pretty easy to do in the debug server, the trickiest
>
> > part would probably be identifying which sources should get this
>
> > treatment. Thoughts?
>
>
>
> We would love this feature. In the future, it could also be nice to be able to
>
> tag the filtered stacks with a particular name, and filter out only Ember but
>
> not other internal details. This is not important for initial implementation.

I had altered Firebug at one point to skip over some things in the stack -- things like "bind" functions, etc. I may add that back into Illuminations, since I can do it for specific functions from specific frameworks.

> > = Async Stacks =
>
> >
>
> > We've wanted this for awhile, hopefully there's a bug on file already that
>
> > I can't find: Tracing asynchronous code sucks. When you call setTimeout
>
> > or addEventListener, the debugger should note your current stack alongside
>
> > that call. When you hit a breakpoint in that function, the debugger should
>
> > be able to display the stack trace that led to the
>
> > setTimeout/addEventListener/XHR/whatever being called.
>
> >
>
> > We should also let content scripts tag a given call point as worth
>
> > capturing a stack for.
>
>
>
> Straw man proposal:
>
>
>
> function later() {
>
> console.log("hi");
>
> }
>
>
>
> later.tagStack();
>
>
>
> // this defers this code until after the remaining application code is called,
>
> // but does not use the browser's async mechanisms, so built-in support
>
> // for setTimeout, etc. would not be sufficient
>
> Ember.run.once(later);