From:  Brian Slesinsky <skybrian@google.com>
Date:  29 Aug 2015 00:52:24 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: Proposal for encoding source-level environment information

NNTP-Posting-Host:  63.245.214.181

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 
wrote:

> 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 
> wrote:
>
>> 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 > > wrote:
>>
>>> 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
>>> _______________________________________________
>>> dev-js-sourcemap mailing list
>>> dev-js-sourcemap@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>>>
>>
>>
>