[Laszlo-dev] For Review: Change 20070120-ben-f Summary: Convert lzsc.py and LFCCompiler.py to java - NOT READY FOR CHECKIN
P T Withington
ptw at openlaszlo.org
Mon Jan 22 04:50:51 PST 2007
I think it is worth it. I will push this along the ground a little
more.
At the very least you have learned _a_lot_ about the compiler
internals, and that has to be a good thing!
I am stunned that there is no `getopts` in Java. That is half of the
difficulty here. Am I just missing it?
Maybe someone on the laszlo-dev list? Java getopts anyone?
On 2007-01-21, at 21:34 EST, Benjamin Shine wrote:
>
>
> Well, this was supposed to be a few hours' work, and it became a
> few days' work, heading towards two weeks' work. Maybe it's time to
> write it off as a bad job. On the other hand, Tucker's insights
> (thank you!) point out some obvious errors and how to fix them.
> There's no bad bug or missing feature caused by lzsc being jython;
> it was just aesthetically annoying.
>
> On Jan 21, 2007, at 5:51 PM, P T Withington wrote:
>
>> Um, there's a lot going on here that needs more work. I can try
>> my hand at it, but I see a number of things:
>>
>> 1) Compiler options and compile-time constants are not the same
>> thing, you seem to have added a feature where you equate -D$debug
>> with --debug that was not in the original.
>
> Maybe that particular error in my code is the cause of the missing-
> Debug-definition.
>
>>
>> 2) I would not try to emulate python. I would switch over to
>> using true Java types for each of the values you need to
>> represent, so Booleans for true and false, not 1/0, not
>> "true"/"false". You have to use Boolean not boolean because we
>> are still in Java 1.4.
>
> I have been trying not to modify the places that look at options
> for fear of disrupting sensitive code, called from everywhere. If
> we switch over to using true Java types, I think we should go all
> the way and actually use java 1.5 collections and generics to make
> clean, readable, compact code. Updating the code to be python-free
> java 1.4 is a half-measure when java 1.5 offers language features
> that directly address these problems.
>
>>
>> 3) I don't think that the compiler options are Properties in the
>> compiler. By the time they reach the compiler, they have been
>> turned into a HashMap. (I don't know how else you could store the
>> contants map in to a Properties, which only stores strings.
>
> Ah. This would explain a lot of my struggle, then. If I mistakenly
> thought early on that compiler options should be Properties, that
> would screw the pooch on the whole rest of my efforts.
>
>>
>> 4) -D is supposed to set a compile-time constant, not a compiler
>> option. This is pretty important.
>
> That would also explain a lot of my problems.
>
>>
>> 5) I would make the following changes to Instructions, so that
>> they can handle Boolean as an argument to push:
>>
>> Index: Instructions.java
>> ===================================================================
>> --- Instructions.java (revision 3453)
>> +++ Instructions.java (working copy)
>> @@ -800,14 +800,14 @@
>> // Python interfaces
>> public Instruction make(Object arg) {
>> - assert arg instanceof Number || arg instanceof Value || arg
>> instanceof String;
>> + assert arg instanceof Number || arg instanceof Value || arg
>> instanceof String || arg instanceof Boolean;
>> return new PUSHInstruction(Collections.singletonList(arg));
>> }
>> public Instruction make(Object[] args) {
>> for (Iterator i = this.args.iterator(); i.hasNext(); ) {
>> Object arg = i.next();
>> - assert arg instanceof Number || arg instanceof Value ||
>> arg instanceof String;
>> + assert arg instanceof Number || arg instanceof Value ||
>> arg instanceof String || arg instanceof Boolean;
>> }
>> return new PUSHInstruction(Arrays.asList(args));
>> }
>> @@ -921,6 +921,12 @@
>> if (v instanceof ParameterizedValue) {
>> bytes.put(((ParameterizedValue)v).value);
>> }
>> + } else if (o instanceof Boolean) {
>> + Value v = ((Boolean)o).booleanValue() ? Values.True :
>> Values.False;
>> + bytes.put(v.type);
>> + if (v instanceof ParameterizedValue) {
>> + bytes.put(((ParameterizedValue)v).value);
>> + }
>> } else if (o instanceof String) {
>> String s = (String)o;
>> if (constants != null && constants.containsKey(s)) {
>> @@ -939,7 +945,7 @@
>> bytes.put((byte)0);
>> }
>> } else {
>> - throw new CompilerException("Unknown type for PUSH: "
>> + o);
>> + throw new CompilerException("Unknown type for PUSH: "
>> + o + " (in args " + this.args + ")");
>> }
>> }
>>
>> ---
>>
>> We can talk tomorrow if you need more help...
>>
>>
>> On 2007-01-20, at 20:38 EST, Benjamin Shine wrote:
>>
>>> Tucker, I can't quite get the right debugging information to be
>>> emitted. Can you please review this change and see if you can get
>>> debugging working?
>>>
>>> Change 20070120-ben-f by ben at cooper.local on 2007-01-20 17:22:21 PST
>>> in /Users/ben/src/proj/IdeaProjects/legals-unjython/src/src
>>>
>>> Summary: Convert lzsc.py and LFCCompiler.py to java - NOT READY
>>> FOR CHECKIN
>>>
>>> New Features:
>>>
>>> Bugs Fixed:
>>>
>>> Technical Reviewer: ptw (pending)
>>> QA Reviewer: (pending)
>>> Doc Reviewer: (pending)
>>>
>>> Documentation:
>>> This change is NOT YET ENTIRELY CORRECT and is NOT READY FOR
>>> CHECKIN. See "Tests" below for current expected test results.
>>>
>>> Release Notes:
>>>
>>> Details:
>>>
>>> This change rewrites lzsc.py and LFCCompiler.py as lzsc.java and
>>> LFCCompiler.java, respectively.
>>>
>>> This code currently emits debug and non-debug LFC's for swf7,
>>> swf8, and dhtml.
>>> (Profile has not been tested) BUT the debug lfc's are missing
>>> some debugging
>>> information or support code. See
>>> http://localhost:8080/src/test/hello.lzx?lzr=dhtml&debug=true and
>>> http://localhost:8080/src/test/hello.lzx?debug=true
>>> and the output of "ant lztest" for a demonstration of these errors.
>>>
>>> I've been trying to do this without changing the compiler other
>>> than in those
>>> files. (This change adds some debugging information to a few
>>> other files in the
>>> compiler.) The code that handles the values in compiler options and
>>> compile-time constants is carefully written to pull out the
>>> python-created java
>>> object just right. So keeping exactly the same lzsc-to-rest-of-
>>> LPS interface
>>> requires making java structures identical to the python-created
>>> java objects.
>>>
>>> Of the perhaps two dozen options and compileTimeConstants, some
>>> booleans are
>>> represented as 0/1, some as the strings "true" and "false", some
>>> as Boolean
>>> objects, and I think some as little-b booleans true and false. So
>>> it's
>>> relatively easy to get a set of options that is logically correct
>>> (sure, I want
>>> debug=true and runtime=dhtml and $js1=true and $svg=false) but
>>> still have
>>> rather a bear of a tangle to get those semantics represented in
>>> just the
>>> objects expected by the CompilationManager, CompilationEnvironment,
>>> CodeGenerator, etc. It further complicates matters that these
>>> options are
>>> interpreted repeatedly in many different source files --
>>> interpreted, not just
>>> evaluated; there are at least three places that do similar-but-
>>> not-the-same
>>> transformations to go from an Object in a properties object into
>>> a String,
>>> Boolean, or boolean. That degree of untangling is necessary to
>>> get the LFC to
>>> build correctly with lzsc.java, without changing code elsewhere
>>> in LPS.
>>>
>>>
>>> The obvious formulation of
>>> compileTimeConstants.put("$dhtml", true); // wrong, won't
>>> compile
>>> doesn't work because put's second argument must be an Object.
>>>
>>> Changing the second argument to a big-B Boolean causes an
>>> "Unknown type for PUSH: false" exception when emitting the
>>> constant map:
>>> compileTimeConstants.put("$dhtml", Boolean.TRUE); // bad,
>>> causes trouble when emitting constant map
>>>
>>> The formulation that seems to work is
>>> compileTimeConstants.put("$dhtml", Integer.toString
>>> (( runtime.equals("dhtml") ? 1 : 0 ))); // ok, works
>>>
>>> Some options require an Integer object of 0 or 1
>>> compilerOptions.put(Compiler.CONDITIONAL_COMPILATION,
>>> Integer.valueOf(1));
>>> and others want a string "true" or "false":
>>> options.setProperty(Compiler.PROGRESS, "true");
>>>
>>> Tests:
>>> $ cd WEB-INF/lps/server/
>>> $ ant test-lzsc
>>> $ cd $LPS_HOME
>>> $ ant clean build
>>> $ ant lztest (errors)
>>>
>>> http://localhost:8080/src/test/hello.lzx (works)
>>> http://localhost:8080/src/test/hello.lzx?lzr=dhtml (works)
>>> http://localhost:8080/src/test/hello.lzx?lzr=dhtml&debug=true
>>> (firebug errors, "Debug has no properties")
>>> http://localhost:8080/src/test/hello.lzx?debug=true (OL debugger
>>> errors, starting with "reference to undefined property
>>> \'_dbg_typename\'")
>>>
>>> Files:
>>> D WEB-INF/lps/server/sc/LFCCompiler.py
>>> A WEB-INF/lps/server/sc/tests/test-input.js
>>> A WEB-INF/lps/server/sc/tests/test.js
>>> D WEB-INF/lps/server/sc/lzsc.py
>>> A WEB-INF/lps/server/src/org/openlaszlo/sc/LFCCompiler.java
>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/Instructions.java
>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/Compiler.java
>>> A WEB-INF/lps/server/src/org/openlaszlo/sc/lzsc.java
>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/
>>> JavascriptGenerator.java
>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/Assembler.java
>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/CodeGenerator.java
>>> M WEB-INF/lps/server/build.xml
>>>
>>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20070120-
>>> ben-f.tar
>>>
>>>
>>> Benjamin Shine
>>> Software Engineer, Open Laszlo / Laszlo Systems
>>> ben at laszlosystems.com
>>>
>>>
>>>
>>
>
> Benjamin Shine
> Software Engineer, Open Laszlo / Laszlo Systems
> ben at laszlosystems.com
>
>
>
More information about the Laszlo-dev
mailing list