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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
[EMAIL PROTECTED]
