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