Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
UglifyJS
Home
+ new post
About this group
Join this group
Source positions, ie line and column numbers
Options
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
   3 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
johnjbarton  
View profile  
 More options Aug 12 2011, 5:50 pm
From: johnjbarton <johnjbar...@johnjbarton.com>
Date: Fri, 12 Aug 2011 14:50:52 -0700 (PDT)
Local: Fri, Aug 12 2011 5:50 pm
Subject: Source positions, ie line and column numbers
Print | Individual message | Show original | Report this message | Find messages by this author
Hi. I need to track the positions of (at least) functions in the
source.

Currently uglify has the embed_tokens option which replaces the syntax
tree node name with a NodeWithToken object. The object has .name
giving the node name, plus .start and .end objects giving the boundary
of the corresponding source token.

This means that code written to work with embed_tokens === true will
not work with code written for the default output. You have to change
every access to ast[0] to be ast[0].name.

On my fork I made a small change to move the NodeWithToken from ast[0]
to ast.loc. That way my parse tree analysis code written with
embed_tokens off works with embed_tokens true.

Of course my test is very minimal. Does any one know whether this
should work or if not what problems it may cause?  Or is there a way
to achieve this goal without changing the parser source? (I guess I
would parse with embed_tokens true and walk the tree to convert from
inline to .loc versions.)

Thanks,
jjb


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Mihai Călin Bazon  
View profile  
 More options Aug 13 2011, 5:03 am
From: Mihai Călin Bazon <mihai.ba...@gmail.com>
Date: Sat, 13 Aug 2011 12:03:44 +0300
Local: Sat, Aug 13 2011 5:03 am
Subject: Re: Source positions, ie line and column numbers
Print | Individual message | Show original | Report this message | Find messages by this author

On Sat, Aug 13, 2011 at 12:50 AM, johnjbarton
<johnjbar...@johnjbarton.com>wrote:

> Hi. I need to track the positions of (at least) functions in the
> source.

> Currently uglify has the embed_tokens option which replaces the syntax
> tree node name with a NodeWithToken object. The object has .name
> giving the node name, plus .start and .end objects giving the boundary
> of the corresponding source token.

... and a toString() method, which means ast[0] == "defun" will work both if
ast[0] is a NodeWithToken or a string.  But this is an ugly hack, of
course.  UglifyJS AST processors used to work with embed_tokens, but I'm not
sure this is the case anymore (using „switch” in some places, and that
involves strict equality).

> On my fork I made a small change to move the NodeWithToken from ast[0]
> to ast.loc. That way my parse tree analysis code written with
> embed_tokens off works with embed_tokens true.

Does this mean that you turned all nodes into objects instead of arrays?
Seems like a comprehensive change...

> Of course my test is very minimal. Does any one know whether this
> should work or if not what problems it may cause?  Or is there a way
> to achieve this goal without changing the parser source? (I guess I
> would parse with embed_tokens true and walk the tree to convert from
> inline to .loc versions.)

I can't be sure about how safe your change is.  But indeed, it would be
rather trivial to write an AST processor that walks the tree and returns
object nodes instead of arrays.  I'd do this rather than modifying the
parser.

Cheers,
--
Mihai Bazon,
http://mihai.bazon.net/blog


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
John J Barton  
View profile  
 More options Aug 14 2011, 12:05 pm
From: John J Barton <johnjbar...@johnjbarton.com>
Date: Sun, 14 Aug 2011 09:05:39 -0700
Local: Sun, Aug 14 2011 12:05 pm
Subject: Re: Source positions, ie line and column numbers
Print | Individual message | Show original | Report this message | Find messages by this author
2011/8/13 Mihai Călin Bazon <mihai.ba...@gmail.com>:

Yes, I guess I have === wired into my fingers now.

>> On my fork I made a small change to move the NodeWithToken from ast[0]
>> to ast.loc. That way my parse tree analysis code written with
>> embed_tokens off works with embed_tokens true.

> Does this mean that you turned all nodes into objects instead of arrays?
> Seems like a comprehensive change...

No,  JavaScript has no array type:

>>> var anArray = ['decl',['name','foo'],undefined];
undefined
>>> typeof(anArray);
"object"
>>> anArray instanceof Array
true
>>> anArray.loc = {line:1, col:4};

Object { line=1, col=4}
>>> typeof(anArray);
"object"
>>> anArray instanceof Array

true

>> Of course my test is very minimal. Does any one know whether this
>> should work or if not what problems it may cause?  Or is there a way
>> to achieve this goal without changing the parser source? (I guess I
>> would parse with embed_tokens true and walk the tree to convert from
>> inline to .loc versions.)

> I can't be sure about how safe your change is.  But indeed, it would be
> rather trivial to write an AST processor that walks the tree and returns
> object nodes instead of arrays.  I'd do this rather than modifying the
> parser.

Seems like the .loc version would be less hacky tho.

jjb


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google