Subj : Re: wrestling a rhino down to the ground (experiences with 5R5 source)
To   : netscape.public.mozilla.jseng
From : mda@discerning.com (Mark D. Anderson)
Date : Fri Aug 01 2003 12:18 pm

> > 1. org.mozilla.javascript.tools.* is no longer part of the js.jar .
> > This is a change from 5R4_1. There appears to be no target to produce
> > a different jar containing them (say jstools.jar). 
> 
> That is strange, build.xml for ant from
> mozilla/js/rhino includes all the tools into js.jar by default.

I figured it out.
The problem is that the "default" target does not build toolsrc, because
it only depends on compile-src.
You have to do "ant jar", which depends on "compile".

> > To deal with that, I made a small edit in Parser.java:
> >     static int OFFSET = 4; // how much to indent
> >     static int SETBACK = 2; // less how much for case labels
> > 
> >     public static void setDecompileOpts(int offset, int case_setback)
> > {
> >         OFFSET = offset;
> >         SETBACK = case_setback;
> >     }
> > 
> 
> This is a reasonable suggestion, but it should not be done via mutable 
> static variables. Rhino can be used by 2 independent application under 
> the single JVM and static variables that present already cause enough 
> troubles.

A better fix certainly would be to pass around "decompilePrefs" object
around wherever the current "indent" parameter goes. 
But I didn't want to touch all those files.

> 
> > 4. The debug flags in Context.java are final.
> > ...
> The benefit is simple. It allows to shrink Rhino classes size and memory 
> consumption and not to include the code useful only for debugging. In 
> memory constrained Java embeddings (like PDA/cell phones with JVM) this 
> is essential and every kilobyte helps.

Hmm, then why not make a whole new class, such as org.mozilla.javascript.NodePrinter
that has all the methods currently wrapped by Context.printTrees in Node.java 
and TakenStream.java

> 
>  > 5. There appears to be no easy way to retrieve source name and line
>  >    number from NativeScript.
> 
> You can do it currently by using the debugger interface, see 
> org.mozilla.javascript.debug.Debugger.handleCompilationDone and methods 
> in org.mozilla.javascript.debug.DebuggableScript. But if you need a more 
> direct way to get that info, I suggest to file an enhancement report for 
> Rhino at bugzilla.mozilla.org.

hmmm.... at first glance, i don't see how to get from a DebuggableScript
instance to an InterpretedScript instance, or go the other direction.

It looks like maybe i could add a getter to InterpretedScript
   InterpretedData getInterpreterData() {return itsData;}

but neither InterpretedScript nor InterpreterData is public.

> But IMO for pretty printing/source transformation you do not need access 
> to the parser tree. If parser would have an option to include line 
> number information/comments into token character array which is 
> effectively a serialized version of parse tree, then source code 
> transformer can work with that form directly and not depend on details 
> of Parser/TokenStream.

That sounds reasonable. I guess that would mean TokenStream.java would
have new tokens, like
  COMMENT = 143, // encoded like NAME
  LINENO = 144, // encoded like NUMBER

-mda

.