[Laszlo-dev] look familiar? Unknown type for PUSH: false

[P T Withington]

I would try less reverse engineering, more DTRT.  I think all you  
need to do is to establish which options (and constants) have Boolean  
values, which have String values, and possibly which options have  
Numeric values.  Each option really only has one type.  In lzsc, your  
task is to parse the command-line options and set them with the  
proper type into the options map.

It is true that in Python the representation of the options is very  
"fluid" and there is some code in the rest of the compiler to try to  
deal with that, but that code should be able to be ripped out once  
you are done.  I think you will find that in the rest of the  
compiler, everywhere an option is expected to be a boolean, it is  
fetched out of the map using getBoolean (or something like that).   
The only place this is not the case, I think, is in the compile-time  
constants.  When the compiler sets those into the runtime, it  
currently has to heuristicate whether those values are strings or  
booleans or numbers.  But that would be solved if the options were  
always of the correct type in the map.

On 2007-01-20, at 02:32 EST, Benjamin Shine wrote:

> Right. So far I've been going for a pure reverse-engineering  
> approach, trying to make exactly the same data structures in  
> lzsc.java that were previously created in lzsc.py. 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. This approach ends up being unwieldy on both  
> ends, both packing data in and pulling it out. We sort of still  
> cope with an interpreted, dynamic *style* of programming while  
> still being constrained by a strictly-typed language. The result is  
> fragile.
>
> 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.
>
> A larger effort, but cleaner, would push pure-java design patterns  
> through the whole options system. This would involve changing  
> everywhere that gets or sets options to use a strongly-typed api.  
> Something like this:
>
>
> Straight-up explicit typing, nothing left to cast or doubt:
> public class CompiliationConstants {
>     public final boolean warnGlobalUndefined;
>     public final String runtime;
>     public final String $debug;
>     public final String $profile; // can java variable names start  
> with '$' ?
>     public final boolean $j2me;
>     public final boolean $dhtml;
>     public final boolean $dhtml;
>     public final boolean $swf7;
>     etc...
>
>     public CompilationConstants(String runtime, boolean debug,  
> boolean profile ... ) {
>        this.runtime = runtime;
>        this.$debug = debug;
>        ...
>     }
>
> }
>
> public class CompilationOptions {
>     public boolean conditionalCompilation = true;
>     public String runtime = "dhtml";
>     public boolean debug = false;
>     etc...
>     CompilationConstants consts;
> }
>
>
> In places where we are used to iterating over all the elements in a  
> map or list, hmm, I have to think about that more. There ought to  
> be a way to treat these collections as objects who know quite a bit  
> about their own structure, rather than as collections who have to  
> let their parts identify themselves, both with semantics (key) and  
> data (value) and metadata (the class or type of the value).
>
>
>
>
> On Jan 19, 2007, at 8:10 PM, P T Withington wrote:
>
>> I think I have a getBoolean and putBoolean method to help in these  
>> situations.  But now that you are not in Python, perhaps you could  
>> just put the appropriate type object?  Like perhaps you arg parser  
>> needs to convert "true" to true or "false" to false?
>>
>> On 2007-01-19, at 22:23 EST, Benjamin Shine wrote:
>>
>>> I figured a lot of this out.
>>> In java, 1 is different from "1" is different from true is  
>>> different from "true" is different from Boolean.TRUE.
>>> In python, some of those are equal-ish.
>>> In javascript, some of those are equal-ish.
>>> Thus, exquisite care must be taken when trying to emit code that  
>>> says
>>> var $debug=1
>>> to not get code that says
>>> var $debug="true"
>>> or
>>> var $debug=true
>>> etc.
>>>
>>> Also, it is not recommended to ever use Properties.put(Object,  
>>> Object) because that introduces potential type mismatches which  
>>> are not detectable until runtime. Anything that can put into a  
>>> properties object can be gotten out with Properties.getProperty 
>>> (String), which returns a String. So if you put something in with  
>>> properties.put("somekey", anObj) where anObj is anything but a  
>>> String, you get kablooey when doing properties.get("somekey").
>>>
>>>
>>> On Jan 19, 2007, at 4:20 PM, Benjamin Shine wrote:
>>>
>>>>
>>>> I'm hung up on this error, while trying to rewrite lzsc in java.  
>>>> Does this look familiar to either of you? It arises later in  
>>>> execution of the script compiler than my parsing of options,  
>>>> inside Compiler.compile. (This is where we hit Tucker's awesome  
>>>> comment FIXME: use a language with dynamic dispatch.)
>>>>
>>>> How can I figure out more about what's causing this?
>>>>
>>>> test-lzsc-v:
>>>>      [java] got arg -v
>>>>      [java] got arg --default=sc/tests/test.js
>>>>      [java] Got --default (which means scriptfile to compile) sc/ 
>>>> tests/test.js
>>>>      [java] got arg -osc/tests/test.out
>>>>      [java] Got -o for outputfilename sc/tests/test.out
>>>>      [java] using outfile sc/tests/test.out
>>>>      [java] init compiler options{scriptfile=sc/tests/test.js,  
>>>> runtime=swf7, flashCompilerCompatability=true,  
>>>> compileTimeConstants={$dhtml=false, $as3=false, $js1=false,  
>>>> $swf9=false, $swf7=true, $profile=false, $swf8=false,  
>>>> $runtime=swf7, $svg=false, $as2=true, $debug=false,  
>>>> $j2me=false}, obfuscate=false, printCompilerOptions=true,  
>>>> cacheCompiles=true, generateFunction2ForLZX=true, progress=true,  
>>>> processIncludes=true, profile=false, outputfile=sc/tests/ 
>>>> test.out, generateFunction2=true, allowRoot=true,  
>>>> createActivationObject=false, conditionalCompilation=true}
>>>>      [java] resolve called with sc/tests/test.js
>>>>      [java] going to open file ./sc/tests/test.js
>>>>      [java] Assembling...
>>>>      [java] Exception compiling scriptfile: Unknown type for  
>>>> PUSH: false
>>>>      [java] Unknown exception compiling in lzsc: Unknown type  
>>>> for PUSH: false
>>>>      [java] org.openlaszlo.sc.CompilerException: Unknown type  
>>>> for PUSH: false
>>>>      [java]     at org.openlaszlo.sc.Instructions 
>>>> $PUSHInstruction.writeArgs(Instructions.java:942)
>>>>      [java]     at org.openlaszlo.sc.Instructions 
>>>> $ConcreteInstruction.writeBytes(Instructions.java:354)
>>>>      [java]     at org.openlaszlo.sc.Assembler.emit 
>>>> (Assembler.java:216)
>>>>      [java]     at org.openlaszlo.sc.Optimizer.flush 
>>>> (Optimizer.java:37)
>>>>      [java]     at org.openlaszlo.sc.Optimizer.emit 
>>>> (Optimizer.java:123)
>>>>      [java]     at org.openlaszlo.sc.Optimizer.assemble 
>>>> (Optimizer.java:50)
>>>>      [java]     at org.openlaszlo.sc.Compiler.compile 
>>>> (Compiler.java:374)
>>>>      [java]     at org.openlaszlo.sc.lzsc.compile(lzsc.java:265)
>>>>      [java]     at org.openlaszlo.sc.lzsc.scriptcompile 
>>>> (lzsc.java:115)
>>>>      [java]     at org.openlaszlo.sc.LFCCompiler.compile 
>>>> (LFCCompiler.java:6)
>>>>      [java]     at org.openlaszlo.sc.Main.main(Main.java:10)
>>>>      [java]     at sun.reflect.NativeMethodAccessorImpl.invoke0 
>>>> (Native Method)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Benjamin Shine
>>>> Software Engineer, Open Laszlo / Laszlo Systems
>>>> ben at laszlosystems.com
>>>>
>>>>
>>>>
>>>
>>
>
> Benjamin Shine
> Software Engineer, Open Laszlo / Laszlo Systems
> ben at laszlosystems.com
>
>
>