[Laszlo-dev] compilation properties, options, and environment

[Benjamin Shine]

On Jan 15, 2007, at 4:54 AM, P T Withington wrote:

> This is definitely a fragile area of the system that could be made  
> better.  It is in the state that it is because:
>
> a) It evolved over time to meet different needs
> b) The script and tag compiler were written as separate projects  
> but need to share some info
Really? Fascinating. Can you tell me more of this history?

> c) The options are created in python and passed to java
Right, that's exactly where I'm getting confused, replacing that  
python with java. It's done in a very dynamic-language way, but then  
when we get into java we would like to be able to just check boolean  
and (basically) enums explicitly. If we stayed in a dynamic language  
the whole time, this structure would be less onerous.

It would be interesting to grep the code for "kludge" and "bleck" and  
"argh" [1]  and see where those emotion-words point to a coding  
decision that can be improved in the light of changing requirements.

[1] See also http://osteele.com/archives/2005/12/aarg

>
> It would be great to see a proposal on how to straighten this out.

I will think about it in the background. Seems like it will need a  
standalone figure-out-some-of-java-1.5's-language-features little  
project first.

>
> Note that compile-time constants are extra special because they are  
> used by the compiler to evaluate if statements at compile-time (its  
> how our conditional compilation works) _and_ they get inserted into  
> the output executable (for cases that could not be evaluated at  
> compile time).  Sometimes a compiler option exists solely for the  
> convenience of setting several compile-time constants at once  
> (e.g., --debug for LZX programs), while those constants may also be  
> set individually (e.g., the debug LFC has only some of the  
> constants that --debug would imply set).
Ah. What compile-time constants must be set?

>
> One of the messier aspects of the compile-time constants is the way  
> we add a new runtime.  There are too many places in the system that  
> need to be touched to add a new runtime.  Just cleaning up this  
> would be a major accomplishment.

Oh good -- a business case for cleaning this up. :)


>
> On 2007-01-14, at 23:47 EST, Benjamin Shine wrote:
>
>>
>>
>>
>> The script compiler has two different collections-of-configuration- 
>> data:
>> org.openlaszlo.sc.Compiler.options (compilerOptions)
>> and
>> constants (org.openlaszlo.sc.Compiler.COMPILE_TIME_CONSTANTS).
>> The map containing the constants is pushed into a single slot in  
>> the options data structure, then pulled out when needed, and cast  
>> to be a Map again. That is goofy.
>>
>> A same-same-but-different data structure is  
>> CompilationEnvironment.properties, but that has to do with the tag  
>> compiler, not the script compiler. Confusingly, these all  
>> represent some of the same information and some different  
>> information: whether to debug/profile and which runtime are  
>> specified in all three of these data structures. This looks  
>> confusing to me, and fragile.
>>
>> I can refactor this cleanly using java 1.5-dependent language  
>> features -- collections, autoboxing, the for/in loop, type-safe  
>> enums.
>>
>> Tucker, Jim, what do you think?
>> a) Not now
>> b) Let's see a more detailed proposal first
>> c) a & b
>>
>>
>>
>> Benjamin Shine
>> Software Engineer, Open Laszlo / Laszlo Systems
>> ben at laszlosystems.com
>>
>>
>>
>

Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
ben at laszlosystems.com