[Laszlo-dev] For Review: Change 20070120-ben-f Summary: Convert lzsc.py and LFCCompiler.py to java - NOT READY FOR CHECKIN
Benjamin Shine
ben at laszlosystems.com
Sun Jan 21 18:34:55 PST 2007
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