Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Proposal for encoding source-level environment information
303 views
Skip to first unread message
Nick Fitzgerald
Aug 25, 2015, 7:37:51 PM8/25/15
to dev-js-sourcemap (dev-js-sourcemap@lists.mozilla.org)
Hi folks,
I'd like to embed some information about the source-level lexical
environment within the source map format, so that it can take its first
baby steps towards being a Real Debugging Format(tm).
This will enable:
1. Debuggers to rematerialize the source-level environment
,
scopes
,
and their bindings (regardless if there are corresponding scopes and
bindings in the generated JS).
2. Debuggers to locate a binding's current value. This includes situations
where:
* The binding was renamed in the compiled JS. For example, the binding is
named
`
atom?
`
in the original source and renamed to
`
atom_question
`
in the compiled JavaScript. Or a minifier renames
`
getLatestFooWidget
`
to
`
aF
`
.
* The binding does not have a corresponding binding in the compiled
JavaScript. For example, the compiler inlined the binding's value after
recognizing that the binding was never mutated.
Here is the proposal, for your consideration:
https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bindings/proposals/env.md
Feel free to discuss it on this list or on the source-map-rfc pull request:
https://github.com/source-map/source-map-rfc/pull/4
Cheers,
Nick
I'd like to embed some information about the source-level lexical
environment within the source map format, so that it can take its first
baby steps towards being a Real Debugging Format(tm).
This will enable:
1. Debuggers to rematerialize the source-level environment
,
scopes
,
and their bindings (regardless if there are corresponding scopes and
bindings in the generated JS).
2. Debuggers to locate a binding's current value. This includes situations
where:
* The binding was renamed in the compiled JS. For example, the binding is
named
`
atom?
`
in the original source and renamed to
`
atom_question
`
in the compiled JavaScript. Or a minifier renames
`
getLatestFooWidget
`
to
`
aF
`
.
* The binding does not have a corresponding binding in the compiled
JavaScript. For example, the compiler inlined the binding's value after
recognizing that the binding was never mutated.
Here is the proposal, for your consideration:
https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bindings/proposals/env.md
Feel free to discuss it on this list or on the source-map-rfc pull request:
https://github.com/source-map/source-map-rfc/pull/4
Cheers,
Nick
Brian Slesinsky
Aug 25, 2015, 8:12:46 PM8/25/15
to Nick Fitzgerald, dev-js-sourcemap (dev-js-sourcemap@lists.mozilla.org)
I skimmed but I'm not really following in detail. I wonder if it would make
sense to define a mapping between the compressed "env" data structure and
a JSON format, and give a few examples? Then we can discuss what data goes
into it separately from how it gets compressed.
- Brian
On Tue, Aug 25, 2015 at 4:37 PM, Nick Fitzgerald <nfitz...@mozilla.com>
wrote:
> _______________________________________________
> dev-js-sourcemap mailing list
> dev-js-s...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>
sense to define a mapping between the compressed "env" data structure and
a JSON format, and give a few examples? Then we can discuss what data goes
into it separately from how it gets compressed.
- Brian
On Tue, Aug 25, 2015 at 4:37 PM, Nick Fitzgerald <nfitz...@mozilla.com>
wrote:
> dev-js-sourcemap mailing list
> dev-js-s...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>
Nick Fitzgerald
Aug 28, 2015, 12:40:02 PM8/28/15
to Brian Slesinsky, dev-js-sourcemap (dev-js-sourcemap@lists.mozilla.org)
Hi Brian,
The data encoded in the "env" string is the source-language's lexical scope
tree. Each scope has a start and end location, a type (function or block),
and a set of bindings. Each binding has a name, type (local, parameter, or
constant), and its value's location (expressed as a snippet of JS that can
be evaluated to retrieve the value).
Care has been taken to ensure that the format is future-extensible so that
we can add new scope types / binding properties / etc in the future. I just
started with what I saw as the basics.
On Tue, Aug 25, 2015 at 5:12 PM, Brian Slesinsky <skyb...@google.com>
wrote:
The data encoded in the "env" string is the source-language's lexical scope
tree. Each scope has a start and end location, a type (function or block),
and a set of bindings. Each binding has a name, type (local, parameter, or
constant), and its value's location (expressed as a snippet of JS that can
be evaluated to retrieve the value).
Care has been taken to ensure that the format is future-extensible so that
we can add new scope types / binding properties / etc in the future. I just
started with what I saw as the basics.
On Tue, Aug 25, 2015 at 5:12 PM, Brian Slesinsky <skyb...@google.com>
wrote:
Brian Slesinsky
Aug 28, 2015, 12:52:49 PM8/28/15
to Nick Fitzgerald, dev-js-sourcemap (dev-js-sourcemap@lists.mozilla.org)
It seems important to specify how the JavaScript should be evaluated. (What
needs to be in the environment?)
What would the scope types be used for? If we left them out entirely, what
wouldn't the debugger be able to do?
On Fri, Aug 28, 2015 at 9:39 AM, Nick Fitzgerald <nfitz...@mozilla.com>
needs to be in the environment?)
What would the scope types be used for? If we left them out entirely, what
wouldn't the debugger be able to do?
On Fri, Aug 28, 2015 at 9:39 AM, Nick Fitzgerald <nfitz...@mozilla.com>
Ron Buckton
Aug 28, 2015, 6:54:58 PM8/28/15
to Nick Fitzgerald, Brian Slesinsky, dev-js-sourcemap (dev-js-sourcemap@lists.mozilla.org)
Nick,
I'm just now looking at your proposal. Can you take a look at https://gist.github.com/asterland/edf028ed7947c8c258d1, which we have discussed previously on this list, to see whether this proposal has any similarities or differences that would make it an improvement over the proposal that Andy Sterland and I put together? Our original proposal stalled due to the fact it did not solve mapping renamed or minified properties of an object.
Ron
________________________________________
From: dev-js-sourcemap <dev-js-sourcemap-bounces+rbuckton=micros...@lists.mozilla.org> on behalf of Nick Fitzgerald <nfitz...@mozilla.com>
Sent: Friday, August 28, 2015 9:39 AM
To: Brian Slesinsky
Cc: dev-js-sourcemap (dev-js-s...@lists.mozilla.org)
Subject: Re: Proposal for encoding source-level environment information
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ffitzgen%2fsource-map-rfc%2fblob%2fscopes-and-bindings%2fproposals%2fenv.md&data=01%7c01%7cRon.Buckton%40microsoft.com%7cd6c12a5f8b6240828b2908d2afc75269%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bm8O6GXu1JkOPZJRBH3ngnYqM8juOUFmfbcbMJBdf8o%3d
I'm just now looking at your proposal. Can you take a look at https://gist.github.com/asterland/edf028ed7947c8c258d1, which we have discussed previously on this list, to see whether this proposal has any similarities or differences that would make it an improvement over the proposal that Andy Sterland and I put together? Our original proposal stalled due to the fact it did not solve mapping renamed or minified properties of an object.
Ron
________________________________________
From: dev-js-sourcemap <dev-js-sourcemap-bounces+rbuckton=micros...@lists.mozilla.org> on behalf of Nick Fitzgerald <nfitz...@mozilla.com>
Sent: Friday, August 28, 2015 9:39 AM
To: Brian Slesinsky
Cc: dev-js-sourcemap (dev-js-s...@lists.mozilla.org)
Subject: Re: Proposal for encoding source-level environment information
>>
>> Feel free to discuss it on this list or on the source-map-rfc pull
>> request:
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fsource-map%2fsource-map-rfc%2fpull%2f4&data=01%7c01%7cRon.Buckton%40microsoft.com%7cd6c12a5f8b6240828b2908d2afc75269%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Yv7dnsuPiqPlUacEk43NhwXKgL%2bRX73pvi0Wm%2bwbWSI%3d
>> Feel free to discuss it on this list or on the source-map-rfc pull
>> request:
>>
>> Cheers,
>>
>> Nick
>> _______________________________________________
>> dev-js-sourcemap mailing list
>> dev-js-s...@lists.mozilla.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.mozilla.org%2flistinfo%2fdev-js-sourcemap&data=01%7c01%7cRon.Buckton%40microsoft.com%7cd6c12a5f8b6240828b2908d2afc75269%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pROJLYmNaAJXMAi6ZhOKGdiAc25Mrrgh0L6%2fXGd7NYk%3d
>> Cheers,
>>
>> Nick
>> _______________________________________________
>> dev-js-sourcemap mailing list
>> dev-js-s...@lists.mozilla.org
>>
>
>
_______________________________________________
dev-js-sourcemap mailing list
dev-js-s...@lists.mozilla.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.mozilla.org%2flistinfo%2fdev-js-sourcemap%0a&data=01%7c01%7cRon.Buckton%40microsoft.com%7cd6c12a5f8b6240828b2908d2afc75269%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uvY214DUFg0MWjRKQIbwQYKuwieycplTkwrosjRV27U%3d
>
>
_______________________________________________
dev-js-sourcemap mailing list
dev-js-s...@lists.mozilla.org
0 new messages