Tempting, but I don't want to make the debugger rely on _too_ many of the 
higher level mechanisms.  You really want the debugger to operate even when 
other things are broken.  Even making it depend on presentation types seems 
risky.

Also, it's the age-old problem that the debugger service is in the LFC and we 
have no support there for simply declaring styled/typed attributes.  I could 
move the whole preferences thing into the component debugger window to take 
advantage of LZX, but then I'd have to duplicate the mechanism for other 
consoles.

I am going to make as simple an interface as possible and implement it in the 
debug service class.  That way any console _and_ the debug compiler can 
directly inject preferences.  The whole point of this exercise was to allow me 
to default the debug recursion limit to the value set in the canvas 
scriptlimits attribute, so I need a simple path for the tag compiler to pass 
that on to the debug service, independent of the particular console window.

On 2010-09-01, at 16:05, Max Carlson wrote:

> Hrm.  In that case, why not add style declarations to the attributes and 
> apply the preferences using the new style attribute?
> 
> Regards,
> Max Carlson
> OpenLaszlo.org
> 
> On 9/1/10 10:49 AM, P T Withington wrote:
>> Unfortunately, they're already documented:
>> 
>> http://labs.openlaszlo.org/trunk-nightly/docs/reference/lz.DebugService+debug.html
>> 
>> but I guess they are little known...
>> 
>> On 2010-09-01, at 13:19, Max Carlson wrote:
>> 
>>> Yeah, I think it's okay to change these APIs.  Were they documented?  If 
>>> not, they're completely free game...
>>> 
>>> Regards,
>>> Max Carlson
>>> OpenLaszlo.org
>>> 
>>> On 9/1/10 9:50 AM, Henry Minsky wrote:
>>>> I don't know think that too many people are actually using the exising
>>>> <debug>  tag attributes, except for width and height and x, y on the 
>>>> view...
>>>> 
>>>> 
>>>> On Wed, Sep 1, 2010 at 9:45 AM, P T Withington<[email protected]
>>>> <mailto:[email protected]>>  wrote:
>>>> 
>>>>    So, should the preferences object become the way you control the
>>>>    debugger and the individual preferences be deprecated?  I'm leery of
>>>>    having multiple interfaces.  But, the only way I can think of to
>>>>    document the combined preferences then is to make a separate
>>>>    debugprefs class...  Ugh.
>>>> 
>>>>    On the 3rd hand, I guess I need something like that so I can get
>>>>    their types right and correctly accept values out of the preferences
>>>>    object into them.
>>>> 
>>>>    Kind of a bigger can of worms than I wanted just now...
>>>> 
>>>>    On 2010-08-31, at 13:25, Max Carlson wrote:
>>>> 
>>>>     >  Sounds good!
>>>>     >
>>>>     >  Regards,
>>>>     >  Max Carlson
>>>>     >  OpenLaszlo.org
>>>>     >
>>>>     >  On 8/31/10 9:26 AM, P T Withington wrote:
>>>>     >>  I'm working on
>>>>     >>
>>>>     >>  LPP-9311 flash halts in backtrace mode but not in debug mode
>>>>    when dealing with deeply nested views
>>>>     >>
>>>>     >>  and one piece of the puzzle (I think) is to ensure that the
>>>>    debugger's notion of maximum stack depth is within the underlying
>>>>    runtime's limit.  In the case of SWF, we have a canvas property
>>>>    `scriptlimits` that lets you specify the maximum recursion and
>>>>    timeout values for the player.  (See LPP-6132
>>>>    debug.backtraceStack.maxDepth attribute should be copied form
>>>>    scriptlimits recursion depth).
>>>>     >>
>>>>     >>  To do this, I plan to pass a debugger `preferences` object
>>>>    through the console window (as embodied by the<debug>   tag).  Since
>>>>    I'm in there, I figure I might as well surface this in the tag, so
>>>>    you will be able to say things like:
>>>>     >>
>>>>     >>  <debug ... preferences="print-length: 256, print-depth:32,
>>>>    show-internal-properties: true" />
>>>>     >>
>>>>     >>  My thought is to compile the preferences as a CSS properties
>>>>    list and use the normal CSS mapping of hyphens to camel case, e.g.:
>>>>     >>
>>>>     >>    camel-case ->   camelCase
>>>>     >>
>>>>     >>  to translate CSS properties to debugger attributes.
>>>>     >>
>>>>     >>  Comments?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> [email protected]<mailto:[email protected]>
>>>> 
>>>> 
>> 


Reply via email to