Ah that probably explains why I was having trouble cutting the components example down to a simpler test case..
On Thu, Dec 3, 2009 at 8:30 AM, P T Withington <[email protected]> wrote: > 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] > > -- Henry Minsky Software Architect [email protected]
