Ah that probably explains why I was having trouble cutting the components example down to a simpler test case..<br><br><br><div class="gmail_quote">On Thu, Dec 3, 2009 at 8:30 AM, P T Withington <span dir="ltr"><<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Well crap.<br>
<br>
I think you need to write the remote console for DHTML. It seems possible that the debugger console is the perturbing factor. Possibly it causes component classes to be initialized in a different order, and hence changes the application order of constraints within those classes? :(<br>
<br>
FWIW, Max and I are chasing a similar Heisenbug with .lzo's. Your favorite large app fails to initialize with .lzo's, but if we enable debugging, the bug goes away.<br>
<br>
Looks like we need to apply all eyes to how the debugger perturbs constraint application order...<br>
<div><div></div><div class="h5"><br>
On 2009-12-03, at 08:25, Henry Minsky wrote:<br>
<br>
> The bug with layout does not happen when debug=true, can you think of any<br>
> thing off the top of your head in that change that might<br>
> be dependent on the debug flag?<br>
><br>
> I'm going to try to get a minimal test case for the radiobutton drawing bug,<br>
> and then compare the<br>
> debug and non-debug js output code, maybe something obvious will be<br>
> different...<br>
><br>
> On Thu, Dec 3, 2009 at 8:19 AM, P T Withington <<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>> wrote:<br>
><br>
>> You should link the two bugs to LPP-8088, but also note the _long_ history<br>
>> of 8088.<br>
>><br>
>> We _really_ want to keep the set of changes in 8088, because it greatly<br>
>> improves the efficiency of the event system (hugely reduces the number of<br>
>> function calls on startup of your favorite large application).<br>
>><br>
>> Here's the $0.05 summary, which may give you some clues:<br>
>><br>
>> 8088 made it so that events are _not_ sent when you set an attribute to the<br>
>> same value, on the theory if the value does not change, then none of the<br>
>> dependent expressions can change.<br>
>><br>
>> In order to detect when a value is changed, all constrained values start<br>
>> out as `void 0` (undefined), but we know that will propagate as `NaN` in<br>
>> numeric operations, so, before any constraints are applied, all values that<br>
>> will be constrained are set to `null`. Finally, while an object is being<br>
>> initialized, events are _always_ sent, because our constraint system<br>
>> (apparently) relies on a superfluity of events to get circular dependencies<br>
>> to settle. [There is surely a better way to solve this problem, like<br>
>> implement a real constraint-solver, but we've gotten by so far...]<br>
>><br>
>> Bottom line is, you probably need to trace the application of constraints<br>
>> to see where things are going awry... Probably the layout is looking at the<br>
>> views before their dimensions have settled.<br>
>><br>
>> On 2009-12-03, at 07:33, Henry Minsky wrote:<br>
>><br>
>>> Regarding LPP-8639 and LPP-8626, I did a binary search and this change<br>
>> seems<br>
>>> like it is partially responsible.<br>
>>> This change makes the radio buttons render correctly again in the dev<br>
>>> console (you need to explicitly recompile<br>
>>> the dev console to see the change, of course) but doesn't seem to make<br>
>> any<br>
>>> difference to the layout of the<br>
>>> first list component example.<br>
>>><br>
>>> But I'll see if I can see what's happening to the radio button, and maybe<br>
>>> that will give a clue as to what<br>
>>> might be wrong with the list component.<br>
>>><br>
>>><br>
>>><br>
>>> r13837 | ptw | 2009-05-08 15:44:23 -0400 (Fri, 08 May 2009) | 25 lines<br>
>>><br>
>>> Change 20090508-ptw-G by ptw@dueling-banjos.home on 2009-05-08 10:52:53<br>
>> EDT<br>
>>> in /Users/ptw/OpenLaszlo/trunk-2<br>
>>> for <a href="http://svn.openlaszlo.org/openlaszlo/trunk" target="_blank">http://svn.openlaszlo.org/openlaszlo/trunk</a><br>
>>><br>
>>> Summary: Ensure dynamic properties are created in instances<br>
>>><br>
>>> Bugs Fixed: LPP-8088 DHTML: many warnings from applyConstraintMethod()<br>
>>> (partial)<br>
>>><br>
>>> Technical Reviewer: max (Message-ID: <<a href="mailto:4A048949.2060200@laszlosystems.com">4A048949.2060200@laszlosystems.com</a><br>
>>> )<br>
>>> QA Reviewer: hminsky (pending)<br>
>>><br>
>>> Details:<br>
>>> Clean up the code in LzNode that makes sure dynamic properties<br>
>>> exist by using a cross-platform test: if accessing the dynamic<br>
>>> property returns undefined, make sure it exists in the instance by<br>
>>> setting it to undefined.<br>
>>><br>
>>> This does not fix the warning part of the bug, but it does make<br>
>>> swf9 work again.<br>
>>><br>
>>> Tests:<br>
>>> <a href="http://localhost:8080/4.2/test/extensions/html.lzx?lzr=swf9" target="_blank">http://localhost:8080/4.2/test/extensions/html.lzx?lzr=swf9</a> No<br>
>>> longer gets a runtime error.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Henry Minsky<br>
>>> Software Architect<br>
>>> <a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br>
>><br>
>><br>
><br>
><br>
> --<br>
> Henry Minsky<br>
> Software Architect<br>
> <a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br><br><br>