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.
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.
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.
4) -D is supposed to set a compile-time constant, not a compiler
option. This is pretty important.
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]
