Parse java string to Matlab data type

[Ritesh Sood-4]

> On Oct 7, 2009, at 8:23 PM, Ritesh Sood wrote:
>
>> Hi javacc users,
>>
>> I had posted the following message to the Matlab users mailing list
>> but it doesn't look like i'm going to get a response. Brief
>> background: I'm using Matlab Builder JA which compiles Matlab code
>> to java callable classes, methods, etc. A column vector is
>> represented in Matlab as [a; b], a 2x2 matrix as [a b; c d] and the
>> two can be stored together in the "cell" data type as {[a; b], [a b;
>> c d]}
>>
>> Hi all,
>>
>> I'm building a java swing based GUI front-end for my Matlab
>> application. As such, user input is available as text strings, for
>> example "{[0; 0], [3.5 0; 0 2]}" (mean vector and covariance matrix
>> of a 2D Gaussian).
>>
>> The user input will be passed to the compiled matlab method as a
>> MWCellArray. Problem is how do a convert (parse) the above string
>> into a MWCellArray?
>> From its javadoc
>>
>> http://www.mathworks.com/access/helpdesk/help/toolbox/javabuilder/MWArrayAPI/index.html
>> the following method is available:
>> java.lang.String toString()
>> Returns a string representation of this array,
>> but the reverse method is not.
>>
>> Evidently, parsing a string like the one above is a non trivial task
>> and I'm loath to attempt writing one by myself. I would be very
>> thankful if someone can point me to the required parser
>> implementation. Matlab itself is carrying out this task all the
>> time, perhaps it is possible to access Matlab's own parser.
>
> Hi Ritesh -
>
> Hm, that looks very doable with JavaCC.  Here's a sample grammar; this
> is a little less flexible than you'll want, probably, but it'll give
> you the idea and a place to start:
>
> ================
> $ cat matlab.jj && javacc matlab.jj && javac *.java && java Matlab
> "{[0; 0], [3.5 0; 0 2]}"
> PARSER_BEGIN(Matlab)
> import java.io.*;
> public class Matlab {
>      public static void main(String[] args) throws Exception {
>        Matlab p = new Matlab(new StringReader(args[0]));
>        p.Cell();
>        System.out.println("Parsed successfully!");
>      }
> }
> PARSER_END(Matlab)
> SKIP: {
>    " "
> }
> TOKEN : {
>    <LBRACE : "{">
> | <RBRACE : "}">
> | <LBRACKET : "[">
> | <RBRACKET : "]">
> | <SEMICOLON : ";">
> | <COMMA : ",">
> | <DOT : ".">
> | <INTEGER_NUMBER : ["0"-"9"](["0"-"9"])*>
> | <FLOATING_POINT_NUMBER : (["0"-"9"])+ "." (["0"-"9"])+>
> }
> void Cell() : {} {
>    "{" ColumnVector() "," Matrix() "}"
> }
> void ColumnVector() : {} {
>    "[" <INTEGER_NUMBER> ";" <INTEGER_NUMBER> "]"
> }
> void Matrix() : {} {
>    "[" <FLOATING_POINT_NUMBER> <INTEGER_NUMBER> ";" <INTEGER_NUMBER>
> <INTEGER_NUMBER> "]"
> }
>
> Java Compiler Compiler Version 5.0 (Parser Generator)
> (type "javacc" with no arguments for help)
> Reading from file matlab.jj . . .
> File "TokenMgrError.java" is being rebuilt.
> File "ParseException.java" is being rebuilt.
> File "Token.java" is being rebuilt.
> File "SimpleCharStream.java" is being rebuilt.
> Parser generated successfully.
> Parsed successfully!
> ================
>
> You can add syntactic actions to do things when a particular item is
> parsed, or you can use JJTree to generate an abstract syntax tree that
> you can traverse to do whatever you need.  Good stuff!
>
> Yours,
>
> Tom
> http://generatingparserswithjavacc.com/

Hi Tom,

thanks a lot for taking the time to write the code. I tested the code on my machine, and
it gave the same output as you got (yay!). However, since I'm not a CS guy (EE/math,
actually) I only have a laypersons knowledge about lexers, parsers, etc. So while I can
understand what's going on above, I'm totally at loss at extending the code further (I'm
quite familiar with regexps though). For instance, the Cell method is not returning
anything at the moment. Eventually, I want to construct a MWCellArray out of the string.
The following pieces have to be filled in towards that end:

The first thing is to extend the definition of ColumnVector so that it accepts an
arbitrary number of elements (including (+)?inf and -inf), that of Matrix to an arbitrary
number of rows and columns, and finally Cell can be composed of an arbitrary number of
rows and columns (including scalars).

Second, if one sees a ColumnVector or Matrix, then instantiate a native java array with
those values.

Finally, construct a MWCellArray from the scalar/vector/matrix elements. This last part is
relatively straighforward once the native java arrays have been constructed, MWCellArray
class has methods that take java arrays and return a MWCellArray object.

I'm wondering if I can achieve the above with my level of knowledge. I've looked at the
user contributed grammars for javaCC, but there isn't one for Matlab. So I definitely need
all the help that I can get.

Thanks again,
Ritesh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tom Copeland]

On Oct 8, 2009, at 2:11 AM, Ritesh Sood wrote:

> thanks a lot for taking the time to write the code. I tested the  
> code on my machine, and
> it gave the same output as you got (yay!). However, since I'm not a  
> CS guy (EE/math,
> actually) I only have a laypersons knowledge about lexers, parsers,  
> etc. So while I can
> understand what's going on above, I'm totally at loss at extending  
> the code further (I'm
> quite familiar with regexps though). For instance, the Cell method  
> is not returning
> anything at the moment. Eventually, I want to construct a  
> MWCellArray out of the string.
> The following pieces have to be filled in towards that end:
>
> The first thing is to extend the definition of ColumnVector so that  
> it accepts an
> arbitrary number of elements (including (+)?inf and -inf), that of  
> Matrix to an arbitrary
> number of rows and columns, and finally Cell can be composed of an  
> arbitrary number of
> rows and columns (including scalars).
>
> Second, if one sees a ColumnVector or Matrix, then instantiate a  
> native java array with
> those values.
>
> Finally, construct a MWCellArray from the scalar/vector/matrix  
> elements. This last part is
> relatively straighforward once the native java arrays have been  
> constructed, MWCellArray
> class has methods that take java arrays and return a MWCellArray  
> object.
>
> I'm wondering if I can achieve the above with my level of knowledge.  
> I've looked at the
> user contributed grammars for javaCC, but there isn't one for  
> Matlab. So I definitely need
> all the help that I can get.

Hi Ritesh -

That's definitely all doable with JavaCC and JJTree.  I looked around  
a little for a matlab parser as well and came across Ptolemy:

http://ptolemy.eecs.berkeley.edu/~ptII/ptolemyII/

If you download the source release you can find a grammar at  
"ptII7.0.1/ptolemy/data/expr/MatrixParser.jjt" that might do some of  
what you want.

That said, here's another variant on the previous parser.  This one  
uses a syntactic action to call another function when it parses a  
ColumnVector, and I renamed Cell to MWCellArray.

====================
$ cat matlab.jj && javacc matlab.jj && javac *.java && java Matlab  
"{[3; 4], [3.5 0; 0 2]}"
PARSER_BEGIN(Matlab)
import java.io.*;
import java.util.*;
public class Matlab {
  public static void main(String[] args) throws Exception {
    Matlab p = new Matlab(new StringReader(args[0]));
    p.MWCellArray();
    System.out.println("Parsed successfully!");
  }
  private static void addColumnArray(Token t1, Token t2) {
    System.out.println("Creating array with values [" + t1.image + ","  
+ t2.image + "]");
    // other code here
  }
}
PARSER_END(Matlab)
SKIP: {
   " "
}
TOKEN : {
   <LBRACE : "{">
| <RBRACE : "}">
| <LBRACKET : "[">
| <RBRACKET : "]">
| <SEMICOLON : ";">
| <COMMA : ",">
| <DOT : ".">
| <INTEGER_NUMBER : ["0"-"9"](["0"-"9"])*>
| <FLOATING_POINT_NUMBER : (["0"-"9"])+ "." (["0"-"9"])+>
}
void MWCellArray() : {} {
   "{" ColumnVector() "," Matrix() "}"
}
void ColumnVector() : {Token t1; Token t2;} {
   "[" t1=<INTEGER_NUMBER> ";" t2=<INTEGER_NUMBER> "]" { addColumnArray
(t1, t2);}
}
void Matrix() : {} {
   "[" <FLOATING_POINT_NUMBER> <INTEGER_NUMBER> ";" <INTEGER_NUMBER>  
<INTEGER_NUMBER> "]"
}

Java Compiler Compiler Version 5.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file matlab.jj . . .
File "TokenMgrError.java" is being rebuilt.
File "ParseException.java" is being rebuilt.
File "Token.java" is being rebuilt.
File "SimpleCharStream.java" is being rebuilt.
Parser generated successfully.
Creating array with values [3,4]
Parsed successfully!
====================

This example doesn't use JJTree, but that might be the next logical  
step to keep things organized.

Yours,

Tom
http://generatingparserswithjavacc.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ritesh Sood]

On Oct 8, 2009, at 11:32 AM, Tom Copeland wrote:

>
> Hi Ritesh -
>
> That's definitely all doable with JavaCC and JJTree.  I looked  
> around a little for a matlab parser as well and came across Ptolemy:
>
> http://ptolemy.eecs.berkeley.edu/~ptII/ptolemyII/
>
> If you download the source release you can find a grammar at  
> "ptII7.0.1/ptolemy/data/expr/MatrixParser.jjt" that might do some of  
> what you want.
>
> That said, here's another variant on the previous parser.  This one  
> uses a syntactic action to call another function when it parses a  
> ColumnVector, and I renamed Cell to MWCellArray.
>
> ====================
> $ cat matlab.jj && javacc matlab.jj && javac *.java && java Matlab  
> "{[3; 4], [3.5 0; 0 2]}"
> PARSER_BEGIN(Matlab)
> import java.io.*;
> import java.util.*;
> public class Matlab {
> public static void main(String[] args) throws Exception {
>   Matlab p = new Matlab(new StringReader(args[0]));
>   p.MWCellArray();
>   System.out.println("Parsed successfully!");
> }
> private static void addColumnArray(Token t1, Token t2) {
>   System.out.println("Creating array with values [" + t1.image + ","  
> + t2.image + "]");
>   // other code here
> }
> }
> PARSER_END(Matlab)
> SKIP: {
>  " "
> }
> TOKEN : {
>  <LBRACE : "{">
> | <RBRACE : "}">
> | <LBRACKET : "[">
> | <RBRACKET : "]">
> | <SEMICOLON : ";">
> | <COMMA : ",">
> | <DOT : ".">
> | <INTEGER_NUMBER : ["0"-"9"](["0"-"9"])*>
> | <FLOATING_POINT_NUMBER : (["0"-"9"])+ "." (["0"-"9"])+>
> }
> void MWCellArray() : {} {
>  "{" ColumnVector() "," Matrix() "}"
> }
> void ColumnVector() : {Token t1; Token t2;} {
>  "[" t1=<INTEGER_NUMBER> ";" t2=<INTEGER_NUMBER>  
> "]" { addColumnArray(t1, t2);}
> }
> void Matrix() : {} {
>  "[" <FLOATING_POINT_NUMBER> <INTEGER_NUMBER> ";" <INTEGER_NUMBER>  
> <INTEGER_NUMBER> "]"
> }
>
> Java Compiler Compiler Version 5.0 (Parser Generator)
> (type "javacc" with no arguments for help)
> Reading from file matlab.jj . . .
> File "TokenMgrError.java" is being rebuilt.
> File "ParseException.java" is being rebuilt.
> File "Token.java" is being rebuilt.
> File "SimpleCharStream.java" is being rebuilt.
> Parser generated successfully.
> Creating array with values [3,4]
> Parsed successfully!
> ====================
>
> This example doesn't use JJTree, but that might be the next logical  
> step to keep things organized.
>
> Yours,
>
> Tom
> http://generatingparserswithjavacc.com/
>
>

Hi Tom,
The grammar file that you found from the Ptolemy project has turned
out to be very helpful. Taking that as a template, and having read a
few tutorials on javaCC, Bison, etc, I'm in the process of writing a
grammar that will parse Matlab cells and matrices with an arbitrary
number of rows and columns.

I will write back when I have put down something for your comments and
suggestions.

Thanks,
Ritesh


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tom Copeland]

On Oct 12, 2009, at 6:25 PM, Ritesh Sood wrote:

> Hi Tom,
> The grammar file that you found from the Ptolemy project has turned
> out to be very helpful. Taking that as a template, and having read a
> few tutorials on javaCC, Bison, etc, I'm in the process of writing a
> grammar that will parse Matlab cells and matrices with an arbitrary
> number of rows and columns.
>
> I will write back when I have put down something for your comments and
> suggestions.

Cool, glad to hear it, best of luck!

Yours,

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ritesh Sood-4]

Tom Copeland wrote:

> Hi Ritesh -
>
> That's definitely all doable with JavaCC and JJTree.  I looked around a
> little for a matlab parser as well and came across Ptolemy:
>
> http://ptolemy.eecs.berkeley.edu/~ptII/ptolemyII/
>
> If you download the source release you can find a grammar at
> "ptII7.0.1/ptolemy/data/expr/MatrixParser.jjt" that might do some of
> what you want.
>
> That said, here's another variant on the previous parser.  This one uses
> a syntactic action to call another function when it parses a
> ColumnVector, and I renamed Cell to MWCellArray.
>
> ====================

*snip*

> ====================
>
> This example doesn't use JJTree, but that might be the next logical step
> to keep things organized.
>
> Yours,
>
> Tom
> http://generatingparserswithjavacc.com/
>

Hi Tom,

I have the parser written down and it's working quite well. Here are two sample runs:

[ritesh@beas: ...metric-est/GUI/inputParser]$ java test/test_parser
Input Cell string: {2.5, [1, 2.5; 3.6, 2], [4.9, 5.8, 4.7], [1; 2.5; 9.0; 2.7], [2.5]}
Parser output:
scalar: 2.5
mat row: [1.0, 2.5]
mat row: [3.6, 2.0]
row vec: [4.9, 5.8, 4.7]
col vec: [1.0, 2.5, 9.0, 2.7]
scalar: 2.5

[ritesh@beas: ...metric-est/GUI/inputParser]$ java test/test_parser
Input Matrix string: [1, 2.5, 5.8; -inf, 2, 7.4; 3.6, 2.9, inf]
Parser output:
mat row: [1.0, 2.5, 5.8]
mat row: [-Infinity, 2.0, 7.4]
mat row: [3.6, 2.9, Infinity]

I will put up the code on Matlab Central File Exchange, but before that I need to troubleshoot the following issue. If I use the parser
twice in the main program, I get the error:

Exception in thread "main" java.lang.Error:
    ERROR: Second call to the constructor of a static SimpleCharStream. You must
        either use ReInit() or set the JavaCC option STATIC to false
        during the generation of this class.
         at matlabparser.SimpleCharStream.<init>(SimpleCharStream.java:273)
         at matlabparser.SimpleCharStream.<init>(SimpleCharStream.java:289)
         at matlabparser.MatrixParser.<init>(MatrixParser.java:279)
         at matlabparser.MatrixParser.<init>(MatrixParser.java:51)
         at test.test_parser.main(test_parser.java:32)


If I do set the option STATIC to false, I get a different error, something like "you can't user a static token manager...". Here's my
class definition:
--------------------------------------
  public class CellParser {

     /** Read the Cell Matlab data type from a String.
         @exception ParseException If an error occurs during parsing.
     */

     public CellParser (String stg) {
    java.io.StringReader stg_rdr = new java.io.StringReader(stg);
        java.io.Reader rdr = new java.io.BufferedReader(stg_rdr);
        CellParser p = new CellParser(rdr);
       
        //CellParser p = new CellParser(new ByteArrayInputStream(stg.getBytes()));
     }

     public List<MatElement> getCell() {
        List<MatElement> cell = new ArrayList<MatElement>();
        try {
            startCell(cell);
        } catch (ParseException e) {
            System.err.println("Caught ParseException: " + e.getMessage());
         }
        return cell;
     }

}
-------------------------------------------
and here's how I'm calling the parser:
-------------------------------------------
class test_parser {

     public static void main(String[] args) {

        MatElement matEl;

        String stg_cell = "{2.5, [1, 2.5; 3.6, 2], [4.9, 5.8, 4.7], [1; 2.5; 9.0; 2.7], [2.5]}";

        CellParser cParser = new CellParser(stg_cell);
        List<MatElement> cell = cParser.getCell();
        Iterator<MatElement> itr = cell.iterator();

        System.out.println("Input Cell string: " + stg_cell);
        System.out.println("Parser output:");
         while(itr.hasNext()) {
            matEl = itr.next();
            printMatEl(matEl);
        }
     }

     *snip*
}
------------------------------------------------
I'm positive that you would've seen this issue before. Searching on newsgroups, etc didn't turn up anything. Maybe you can help.

Thanks,
Ritesh


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tom Copeland]

On Oct 18, 2009, at 9:35 PM, Ritesh Sood wrote:

> I will put up the code on Matlab Central File Exchange, but before  
> that I need to troubleshoot the following issue. If I use the parser  
> twice in the main program, I get the error:
>
> Exception in thread "main" java.lang.Error:
>   ERROR: Second call to the constructor of a static  
> SimpleCharStream. You must
>       either use ReInit() or set the JavaCC option STATIC to false
>       during the generation of this class.

Hi Ritesh -

Cool, yup, you need to change that "new CellParser(stg_cell)" call to  
"CellParser.ReInit(stg_cell)".  Alternatively you can set  
STATIC=false, regenerate everything, and that should work as well.  
There's a performance hit for using a non-static parser, but it might  
not make much of a difference in the overall runtime depending on what  
else you're doing...

Yours,

Tom
http://generatingparserswithjavacc.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sreenivasa Viswanadha]

May be it's time to change the default to STATIC. That's a relic of the
past - when Java for version 1.0. It used to make a HUGE difference when
you did not use virtual methods, But the modern hardware and java
improvements make that options irrelevant.

> On Oct 18, 2009, at 9:35 PM, Ritesh Sood wrote:
>
>> I will put up the code on Matlab Central File Exchange, but before
>> that I need to troubleshoot the following issue. If I use the parser
>> twice in the main program, I get the error:
>>
>> Exception in thread "main" java.lang.Error:
>>   ERROR: Second call to the constructor of a static
>> SimpleCharStream. You must
>>       either use ReInit() or set the JavaCC option STATIC to false
>>       during the generation of this class.
>
> Hi Ritesh -
>
> Cool, yup, you need to change that "new CellParser(stg_cell)" call to
> "CellParser.ReInit(stg_cell)".  Alternatively you can set
> STATIC=false, regenerate everything, and that should work as well.
> There's a performance hit for using a non-static parser, but it might
> not make much of a difference in the overall runtime depending on what
> else you're doing...
>
> Yours,
>
> Tom
> http://generatingparserswithjavacc.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sreenivasa Viswanadha]

Sorry, I meant just get rid of the option and make it a noop for
compatibility and change javacc to only generate non-static parsers.

>
> May be it's time to change the default to STATIC. That's a relic of the
> past - when Java for version 1.0. It used to make a HUGE difference when
> you did not use virtual methods, But the modern hardware and java
> improvements make that options irrelevant.
>
>> On Oct 18, 2009, at 9:35 PM, Ritesh Sood wrote:
>>
>>> I will put up the code on Matlab Central File Exchange, but before
>>> that I need to troubleshoot the following issue. If I use the parser
>>> twice in the main program, I get the error:
>>>
>>> Exception in thread "main" java.lang.Error:
>>>   ERROR: Second call to the constructor of a static
>>> SimpleCharStream. You must
>>>       either use ReInit() or set the JavaCC option STATIC to false
>>>       during the generation of this class.
>>
>> Hi Ritesh -
>>
>> Cool, yup, you need to change that "new CellParser(stg_cell)" call to
>> "CellParser.ReInit(stg_cell)".  Alternatively you can set
>> STATIC=false, regenerate everything, and that should work as well.
>> There's a performance hit for using a non-static parser, but it might
>> not make much of a difference in the overall runtime depending on what
>> else you're doing...
>>
>> Yours,
>>
>> Tom
>> http://generatingparserswithjavacc.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Aliaksandr Radzivanovich]

sreeni,

I have customized javacc for myself. My version does not generate static code and has few other improvements.

You can find it in the public github reposotory javaccng: http://github.com/aradzie/javaccng

The page with summary of changes: http://wiki.github.com/aradzie/javaccng

Feel free to backport code from it.

Cheers,

Alex

2009/10/19 <sreeni@...>

Sorry, I meant just get rid of the option and make it a noop for
compatibility and change javacc to only generate non-static parsers.

>
> May be it's time to change the default to STATIC. That's a relic of the
> past - when Java for version 1.0. It used to make a HUGE difference when
> you did not use virtual methods, But the modern hardware and java
> improvements make that options irrelevant.
>
>> On Oct 18, 2009, at 9:35 PM, Ritesh Sood wrote:
>>
>>> I will put up the code on Matlab Central File Exchange, but before
>>> that I need to troubleshoot the following issue. If I use the parser
>>> twice in the main program, I get the error:
>>>
>>> Exception in thread "main" java.lang.Error:
>>>   ERROR: Second call to the constructor of a static
>>> SimpleCharStream. You must
>>>       either use ReInit() or set the JavaCC option STATIC to false
>>>       during the generation of this class.
>>
>> Hi Ritesh -
>>
>> Cool, yup, you need to change that "new CellParser(stg_cell)" call to
>> "CellParser.ReInit(stg_cell)".  Alternatively you can set
>> STATIC=false, regenerate everything, and that should work as well.
>> There's a performance hit for using a non-static parser, but it might
>> not make much of a difference in the overall runtime depending on what
>> else you're doing...
>>
>> Yours,
>>
>> Tom
>> http://generatingparserswithjavacc.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Paul Cager-5]

I really like the idea of getting rid of the STATIC option (and other
anachronisms like the direct access to Token's fields). But I'm a bit
worried about going from STATIC being the default to being unsupported in
one release. A lot of users could be left with parsers that do not work
with the new release (and converting from static to non-static isn't
always trivial).

What about a two stage transition?

This release (5): Change default to non-static, but still support static.
Display warnings for any parsers that explicitly use STATIC.

Next release (6): Remove support for STATIC.

What are your thoughts?

Paul

> Sorry, I meant just get rid of the option and make it a noop for
> compatibility and change javacc to only generate non-static parsers.
>
>>
>> May be it's time to change the default to STATIC. That's a relic of the
>> past - when Java for version 1.0. It used to make a HUGE difference when
>> you did not use virtual methods, But the modern hardware and java
>> improvements make that options irrelevant.
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sreenivasa Viswanadha]

Sounds good.

> I really like the idea of getting rid of the STATIC option (and other
> anachronisms like the direct access to Token's fields). But I'm a bit
> worried about going from STATIC being the default to being unsupported in
> one release. A lot of users could be left with parsers that do not work
> with the new release (and converting from static to non-static isn't
> always trivial).
>
> What about a two stage transition?
>
> This release (5): Change default to non-static, but still support static.
> Display warnings for any parsers that explicitly use STATIC.
>
> Next release (6): Remove support for STATIC.
>
> What are your thoughts?
>
> Paul
>
>> Sorry, I meant just get rid of the option and make it a noop for
>> compatibility and change javacc to only generate non-static parsers.
>>
>>>
>>> May be it's time to change the default to STATIC. That's a relic of the
>>> past - when Java for version 1.0. It used to make a HUGE difference
>>> when
>>> you did not use virtual methods, But the modern hardware and java
>>> improvements make that options irrelevant.
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tom Copeland]

+1 from me as well.

On Oct 19, 2009, at 8:52 PM, sreeni@... wrote:

>
> Sounds good.
>
>> I really like the idea of getting rid of the STATIC option (and other
>> anachronisms like the direct access to Token's fields). But I'm a bit
>> worried about going from STATIC being the default to being  
>> unsupported in
>> one release. A lot of users could be left with parsers that do not  
>> work
>> with the new release (and converting from static to non-static isn't
>> always trivial).
>>
>> What about a two stage transition?
>>
>> This release (5): Change default to non-static, but still support  
>> static.
>> Display warnings for any parsers that explicitly use STATIC.
>>
>> Next release (6): Remove support for STATIC.
>>
>> What are your thoughts?
>>
>> Paul
>>
>>> Sorry, I meant just get rid of the option and make it a noop for
>>> compatibility and change javacc to only generate non-static parsers.
>>>
>>>>
>>>> May be it's time to change the default to STATIC. That's a relic  
>>>> of the
>>>> past - when Java for version 1.0. It used to make a HUGE difference
>>>> when
>>>> you did not use virtual methods, But the modern hardware and java
>>>> improvements make that options irrelevant.
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Sreenivasa Viswanadha]

Actually, after thinking more about it, changing the default to nonstatic
will also break backward compatibility so we might as well just get rid of
it. We will change the header in all the boilerplate to update the version
number so all the right warnings will come thru.

> +1 from me as well.
>
> On Oct 19, 2009, at 8:52 PM, sreeni@... wrote:
>
>>
>> Sounds good.
>>
>>> I really like the idea of getting rid of the STATIC option (and other
>>> anachronisms like the direct access to Token's fields). But I'm a bit
>>> worried about going from STATIC being the default to being
>>> unsupported in
>>> one release. A lot of users could be left with parsers that do not
>>> work
>>> with the new release (and converting from static to non-static isn't
>>> always trivial).
>>>
>>> What about a two stage transition?
>>>
>>> This release (5): Change default to non-static, but still support
>>> static.
>>> Display warnings for any parsers that explicitly use STATIC.
>>>
>>> Next release (6): Remove support for STATIC.
>>>
>>> What are your thoughts?
>>>
>>> Paul
>>>
>>>> Sorry, I meant just get rid of the option and make it a noop for
>>>> compatibility and change javacc to only generate non-static parsers.
>>>>
>>>>>
>>>>> May be it's time to change the default to STATIC. That's a relic
>>>>> of the
>>>>> past - when Java for version 1.0. It used to make a HUGE difference
>>>>> when
>>>>> you did not use virtual methods, But the modern hardware and java
>>>>> improvements make that options irrelevant.
>>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Paul Cager-5]

Changing the default to non-static *will* break existing parsers, but
users can fix it by simply adding STATIC=true to their parser.

Removing it all together means they would have to convert their parser to
non-static, which is potentially a lot more work (especially for people
who just use JavaCC as part of their build system and don't really know
much about it).

By doing it in 2 stages we give the users advance warning of the work
they'll need to do.

> Actually, after thinking more about it, changing the default to nonstatic
> will also break backward compatibility so we might as well just get rid of
> it. We will change the header in all the boilerplate to update the version
> number so all the right warnings will come thru.
>
>> +1 from me as well.
>>
>> On Oct 19, 2009, at 8:52 PM, sreeni@... wrote:
>>
>>>
>>> Sounds good.
>>>
>>>> I really like the idea of getting rid of the STATIC option (and other
>>>> anachronisms like the direct access to Token's fields). But I'm a bit
>>>> worried about going from STATIC being the default to being
>>>> unsupported in
>>>> one release. A lot of users could be left with parsers that do not
>>>> work
>>>> with the new release (and converting from static to non-static isn't
>>>> always trivial).
>>>>
>>>> What about a two stage transition?
>>>>
>>>> This release (5): Change default to non-static, but still support
>>>> static.
>>>> Display warnings for any parsers that explicitly use STATIC.
>>>>
>>>> Next release (6): Remove support for STATIC.
>>>>
>>>> What are your thoughts?
>>>>
>>>> Paul
>>>>
>>>>> Sorry, I meant just get rid of the option and make it a noop for
>>>>> compatibility and change javacc to only generate non-static parsers.
>>>>>
>>>>>>
>>>>>> May be it's time to change the default to STATIC. That's a relic
>>>>>> of the
>>>>>> past - when Java for version 1.0. It used to make a HUGE difference
>>>>>> when
>>>>>> you did not use virtual methods, But the modern hardware and java
>>>>>> improvements make that options irrelevant.
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...