[Laszlo-dev] backtrace/lzbacktrace clarification...?

[P T Withington]

On 2008-12-12, at 06:47EST, Donald Anderson wrote:

> cm/CompilationManager.java has in getInfoXML() a set of lines:
>
>        boolean isDebug = "true".equals(props.getProperty("debug"));
>        boolean isProfile =  
> "true".equals(props.getProperty("profile"));
>        boolean isBacktrace =  
> "true".equals(props.getProperty("backtrace"));
>
>        String lfc = LPS.getLFCname( runtime, isDebug, isProfile,  
> isBacktrace);
>
> While CompilationEnvironment agrees with the names for "debug" and  
> "profile",
> it lists BACKTRACE_PROPERTY as "debugBacktrace".  Furthermore,
> servlets/responders/ResponderCompile.java is looking for  
> "lzbacktrace".
>
> I take this to mean that that "debugBacktrace" is used as the  
> internal name in CompilationEnvironment,
> and is also the property to set with lzc if you want this.  Whereas  
> "lzbacktrace" is used in URL arguments.
> But the props in getInfoXML() come from ResponderAPP_CONSOLE and  
> ResponderINFO_XML,
> so I would think this would also need to be "lzbacktrace" and not  
> merely "backtrace"?
> Is there another option namespace out there?

Your guess is as good as mine here.  That there are too many ways and  
too many paths to discover the compile options is a long-standing  
issue.  We have slowly reduced the number of paths as the number of  
options has grown, but not always successfully.

Historically, the URL options started out as simple names like `debug`  
and `profile`, but we realized that polluted the query-args namespace,  
so more recent additions are prefixed with `lz` (and there is http://jira.openlaszlo.org/jira/browse/LPP-3479) 
.  These query args are translated into internal properties, which are  
defined in CompilationEnvironment.java, but also note the TODO on line  
448 of sc/Compiler.java, where many of these names a duplicated only  
because the guy writing this code did not know how to share the  
constants table (using some whacky define the shared constants on an  
interface and then declare an implementation to get at them trick that  
he later discovered).  The command-line interface used normal command  
flags which it translates into the internal environment names, but  
also has the escape hatch of you being able to use -D and the internal  
name (if you can figure out what the internal name is -- obviously  
this is not meant to be a public interface).

As to the getInfoXML mystery, that just plain looks broken.  Why it is  
querying props with strings rather than the constant prop names seems  
bogus.  Luckily nothing really uses the output of that... or so it  
would appear.  The app_console responder is presumably providing the  
xml so that xslt can customize the wrapper based on what options were  
called for, but I bet it doesn't do anything special with  
backtracing.  The info_xlm responder is only for human consumption, so  
it could be wrong and no one notice; but, it sure would be a lot  
better if it were correct; in particular, if it told you the LFC  
flavor that was being used accurately.  (I had to look at the Firebug  
net pane to figure out which LFC was actually being loaded.)