a plausible bug, I know several times in the past we were bitten by that very behavior when copying properties lists, and usually we use .clone() method to make a real shallow copy of a property list when we need to. Perhaps it was just overlooked in this case.
On 7/10/06, Jason Stafford <[EMAIL PROTECTED]> wrote:
Henry,
I've haven't seen much action on this bug (http://www.openlaszlo.org/jira/browse/LPP-2074) for a while, so I thought I'd take a look again.
I dove deep, deep, deep into the Java this time, and I found the reason for the behavior we are seeing, and a couple of possible fixes.
I still haven't been approved by my boss to be an OpenLaszlo contributor, and I'd really like this issue fixed, so I'll refrain from showing any of my code that would fix it, but it shouldn't hurt if describe the problem in detail.
In the file ImportCompiler.java, in the method "compileLibrary" there is the following line:
CompilationEnvironment env = new CompilationEnvironment(mEnv);
Looking at this you might think that you would get back a new environment with exactly the same properties as the original mEnv. This is not precisely the case.
Inside the constructor in CompilationEnvironment.java, there is the following line:
this.mProperties = new Properties(srcEnv.getProperties());
You might think that this would create a new Properties object with the same settings as srcEnv. This is not what happens.
If you look at the documentation at http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html, you will see that
Properties(Properties defaults)
Creates an empty property list with the specified defaults.
This is kind of like copying the properties. Back in compileLibrary in ImportCompiler.java if you call either:
mEnv.getProperties().getProperty("debug")
or env.getProperties().getProperty("debug")
both will return true. But in the case of mEnv, it is actually a property that is being checked. In the case of the copy, env, it is failing to find the property (since as per documentation the property list is empty) and is finding it in the defaults section.
This would not cause any problems, except for the way the script complier is written. Instead of using a Properties object, it uses an OptionMap, and when it builds the OptionMap from the Properties, it doesn't take defaults into account. See the method setProperties in the file Compiler.java in the sc folder.
Obviously you could fix this in either the CompilationEnvironment constructor or in the script compiler. I don't know the code well enough to know if the behavior of the Properties object when a CompilationEnvironment is constructed was intentional or accidental, and what the side effects (if any) of any of these changes might be. If at all possible I would like to see the options passed down to the import libraries, ideally in the 3.4 release.
Thanks for your time,
-Jason
Henry Minsky wrote:I will take a look. I'm filing a bug placeholder at http://www.openlaszlo.org/jira/browse/LPP-2074
On 5/18/06, P T Withington <[EMAIL PROTECTED] > wrote:Maybe the debug flag is not passed to the compilation of libraries?
On 2006-05-18, at 18:25 EDT, Jason Stafford wrote:
> We are using OpenLaszlo 3.2 and have broken our application into
> libraries for a variety of reasons (improve download time, improve
> startup speed, lower memory usage, etc.).
>
> Now we are finding that the code in the libraries no longer
> generates the helpful "reference to undefined variable", "reference
> to undefined property", or "undefined object does not have a
> property" messages. I've looked through the JIRA bug database, and
> don't see a bug on this issue.
>
> If at all possible, we would really like to use libraries while
> developing, and still get the useful undefined reference messages.
>
> Looking deep into the OpenLaszlo source in VariableReference.java,
> it seems that the only reasons that these messages would not be
> emitted to the debugger is if Compiler.WARN_UNDEFINED_REFERENCES
> was set to false, which it does not seem to be, or if node.filename
> was null, which also does not seem likely.
> I've gone as deep as I can (or want to) into the java code, and I
> do not understand why this is happening. Can someone out there
> with a deeper understanding of the Java code let me know why this
> is happening, and how to fix it.
>
> Enclosed is a sample program to reproduce the problem.
>
> Thanks for your time.
>
>
> --
> Jason Stafford
> Principal Developer
> Inspiration Software, Inc.
> The leader in visual thinking & learning
>
> Introducing INSPIRATION(r) 8, the essential tool to visualize,
> think, organize and learn. Students use Inspiration to plan,
> research and complete projects successfully. Learn more at
> www.inspiration.com.
> 503-297-3004 Extension 119
> 503-297-4676 (Fax)
> 9400 SW Beaverton-Hillsdale Highway
> Suite 300
> Beaverton, OR 97005-3300
>
> <?xml version='1.0' encoding='UTF-8' ?>
> <canvas width='100%' height='100%' proxied='true' debug='true'>
> <import name='library' stage='late' href=''/>
>
> <handler name='oninit'>
> polly.wog();
> Debug.write("Canvas is inited. Got expected warnings.");
> </handler>
> </canvas>
> <?xml version='1.0' encoding='UTF-8' ?>
> <library>
> <view>
> <handler name='oninit'>
> froggy.frog();
> Debug.write("Library is inited. Didn't see any warnings.");
> </handler>
> </view>
> </library>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Jason Stafford
Principal Developer
Inspiration Software, Inc.
The leader in visual thinking & learning
InspireData(tm), the newest innovative thinking and learning tool from
Inspiration Software(r), extends the proven power of visual learning to
data analysis. Learn more at www.inspiration.com.
503-297-3004 Extension 119
503-297-4676 (Fax)
9400 SW Beaverton-Hillsdale Highway
Suite 300
Beaverton, OR 97005-3300
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
