[Laszlo-dev] For Review: Change 20080827-ptw-k Summary:

[André Bargull]

new dhtml-differences:
- write into the debugger 'null' (not as a string), it prints now: 
"«object| null»", but was "null"
- write into the debugger 'void(0)' (not as a string), it doesn't print 
a new prompt (same as for "" ?)

LzDebugService#isObjectLike() does not return a Boolean for falsy 
arguments, try e.g. Debug.isObjectLike(null).


On 8/31/2008 10:17 PM, André Bargull wrote:
> Last one is easy to fix:
> In LzDHTMLDebugService#__StringDescription(), first if-clause:
> t == 'object'    =>    typeof thing == 'object'
>
> On 8/31/2008 10:13 PM, André Bargull wrote:
>> Dhtml, IE-only: HTML-elements are no longer printed pretty, e.g. try 
>> "Debug.write(canvas.sprite.__LZdiv)".
>> expected:
>>> «object#0| #document/html/body/div#lzappContainer[1]/div#sprite_0[1]»
>> actual:
>>> «object#75| {…, scrollHeight: 19, isTextEdit: false, currentStyle: 
>>> [object], document: [object], ............... 
>>> <javascript:window.parent.$modules.lz.Debug.displayObj(75)>
>>
>>
>> On 8/31/2008 9:58 PM, André Bargull wrote:
>>> 'Debug.write("")' does not print a new prompt (regression for dhtml, 
>>> swf was also broken before the change).
>>>
>>> On 8/31/2008 9:52 PM, André Bargull wrote:
>>>> And "canvas.sprite" prints a "SyntaxError" (also dhtml-only):
>>>>> «Error «object| SyntaxError:…» computing __typeof#44| {owner: This 
>>>>> is th [...]
>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(44)>
>>>>
>>>>
>>>> On 8/31/2008 9:46 PM, André Bargull wrote:
>>>>> Functions are displayed differently in dhtml, for instance type 
>>>>> "Class" into the debugger and inspect the object:
>>>>>
>>>>> new:
>>>>>> «Object#8| Class» {
>>>>>> _dbg_name: 'Class'
>>>>>> addProperty: «Class static function(2)» 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(5)>
>>>>>> addStaticProperty: addStaticProperty($1_name, $2_value) {
>>>>>> this[$1_name] = $2_value;
>>>>>> if <javascript:window.parent.$modules.lz.Debug.displayObj(6)>
>>>>>> allClasses: {…} 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(15)>
>>>>>> make: make($1_classname, $2_traitsAndSuperclass, 
>>>>>> $3_instanceProperties, $4_staticProperties) {
>>>>>> var nc = function constructor() {this.constructor = 
>>>>>> arguments.callee;this.validateClassStructure();if 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(16)>
>>>>>> prototype: {…} 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(18)>
>>>>>> }
>>>>>
>>>>> old:
>>>>>> «Object#87| Class» {
>>>>>> _dbg_name: 'Class'
>>>>>> addProperty: addProperty 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(83)>
>>>>>> addStaticProperty: addStaticProperty 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(84)>
>>>>>> allClasses: {...} 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(95)>
>>>>>> make: make 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(96)>
>>>>>> prototype: {...} 
>>>>>> <javascript:window.parent.$modules.lz.Debug.displayObj(97)>
>>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> On 8/30/2008 8:11 PM, André Bargull wrote:
>>>>>> Great stuff, that will make live easier for everyone who needs to 
>>>>>> touch the debugger.
>>>>>> Right now I'm going through the files, until now just 
>>>>>> (mini-)source changes:
>>>>>>
>>>>>> LzRuntime.lzs, encodeURIComponent: why not decodeURIComponent?,
>>>>>> LzBootstrapDebugConsole#addText(..): string coercion looks odd, 
>>>>>> belongs into the catch-clause?
>>>>>> LzBootstrapDebugLogger#log(..): loadVariables() should be 
>>>>>> loadVariablesNum(), right?
>>>>>> LzBootstrapDebugService: _dbg_log_all_writes, why a global?
>>>>>> LzBootstrapDebugService#xmlEscape(): we really ought to 
>>>>>> consolidate all our different xml-escape routines...
>>>>>> LzBootstrapDebugService, "var Debug": you've left out the 
>>>>>> "var"-declaration for the generic and runtime-specific debuggers, 
>>>>>> why not here? (as the first "var Debug" is declared in 
>>>>>> LzRuntime.lzs)
>>>>>> LzBootstrapDebugService, $reportNotFunction and 
>>>>>> $reportUndefinedMethod: message concatenation looks odd
>>>>>> LzCompiler, $reportSourceWarning: "if (LzWarning)" is (now) 
>>>>>> always true, so the else-clause can be removed
>>>>>> LzBootstrapMessage#indexOf(..args) vs 
>>>>>> LzDebugMessage#indexOf(key): not a compatible override
>>>>>> LzBootstrapMessage#toString(), #toHTML(): timestamp is off by 
>>>>>> three years ;-)
>>>>>> LzBootstrapMessage: String.prototype.toHTML() uses 
>>>>>> "Debug.xmlEscape", which is only available in debug-mode
>>>>>> LzSourceMessage: missing declaration of "message" in class
>>>>>> LzSourceMessage: constructor typing wrong, "message" is either 
>>>>>> String or LzMessage
>>>>>> LzDebugService.internalPropertyPrefixes: use an Object instead of 
>>>>>> an Array (it's used as an Object in 
>>>>>> LzDebugService#internalProperty())
>>>>>> debugger-component: update the comment at file-beginning and mark 
>>>>>> the methods which implement the LzBootstrapDebugConsole-interface
>>>>>> LzDHTMLDebugConsole declares "doEval" as overriden, but there is 
>>>>>> no "doEval" in LzBootstrapDebugConsole, missing?
>>>>>>
>>>>>> Does it make sense to replace these lines (occur several times in 
>>>>>> the debugger-files):
>>>>>>> var color = '#0000ff';
>>>>>>> if (attrs && attrs.color) { color = attrs.color };
>>>>>> with a shorter replacement (for LPP-6892): var color = (attrs && 
>>>>>> attrs.color) || '#0000ff';
>>>>>>
>>>>>> As you see, that's merely me being nit-picking. And I haven't yet 
>>>>>> tried the new debugger, I'll do that tomorrow.
>>>>>>
>>>>>> On 8/28/2008 10:14 PM, P T Withington wrote:
>>>>>>> Change 20080827-ptw-k by ptw at dueling-banjos.home on 2008-08-27 
>>>>>>> 14:46:24 EDT
>>>>>>> in /Users/ptw/OpenLaszlo/krispy-kreme
>>>>>>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>>>>>>
>>>>>>> Summary: Classify the debugger
>>>>>>>
>>>>>>> Bugs Fixed:
>>>>>>> LPP-6226 'make the compiler debug flag work with swf9' (step 0)
>>>>>>>
>>>>>>> Technical Reviewer: hminsky (pending)
>>>>>>> QA Reviewer: a.bargull at intensis.de (pending)
>>>>>>>
>>>>>>> Summary:
>>>>>>> This is a pretty massive change, not easy to review from the
>>>>>>> diffs. I propose checking it in so we can just get some usage on
>>>>>>> it.
>>>>>>>
>>>>>>> [...]
>>>>>>
>>>>>
>>>>
>>>
>>
>