shinyblog

Tuesday, September 26, 2006

release excitement

Release excitement is starting again, on the OpenLaszlo front. We're working towards Legals-PR4, which means preview release 4 of the multiple-runtimes platform. We're simultaneously working towards 3.4, which adds video, CSS, and many charting & graphing bug fixes to lps-3.3.3. And I'm playing my favorite role, working on a demo application to show off the technology. Watch this space... in a week or so I'll have some hot stuff to show off. Just imagine it... you write a RIA in lzx, and with the flip of a switch, it runs in DHTML and in the flash player. A real application, I'm talking about, here. I love this part of the project cycle, when people from different efforts come together towards a common goal. I'm working with these masterminds who seem to be able to take any weird thing I throw at them and come back with a workaround in a few hours. It's a good day when I come home from work and can't wait to plug my machine in and start getting back into it. And I know that I will wake to an inbox full of expert discourse on dynamic language and library design. I love working at this company.

Saturday, September 23, 2006

OpenLaszlo debugging tips from Tucker

The OpenLaszlo debugger has many features that I haven't learned about until recently. The classic println in OpenLaszlo is just

Debug.write("My message, hooray.");

This method is variadic and clever. Comma-separated arguments are printed as "live" debugger objects.

<method name="doSomething" args="x">

Debug.write("This is", this, "and x is", x);

</method>

gives you this...

This is #theView and x is 27

See how #theView is blue? That indicates that it is live. Click on the blue text
and the debugger will print (almost) everything it knows about #theView.

lzx> Debug.inspect(#theView)
#theView {
_events:
[LzEvent, LzEvent]
_instanceAttrs: «Object#1#3| {id: theView, bgcolor: 2383748, height: 40, width: 40}»
_instanceChildren: «undefined»
addedToParent: true
bgcolor: 2383748
doSomething:
«Function#4| theView_doSomething»
hassetheight: true
hassetwidth: true
height: 40
id: theView
immediateparent:
«LzCanvas#5| This is the canvas»
isinited: true
mask: null
nodeLevel: 1
onheight:
#theView.onheight
onvisible: #theView.onvisible
parent: «LzCanvas#5| This is the canvas»
width: 40
}
«LzView#0|
#theView»

All of the strings in blue are also clickable; clicking them will print the results of Debug.inspect(it), which may in turn yield more clickalbe, inspectable objects. But this is all kid stuff. Let's get to the power tools. The underscore character is a shortcut for "the last thing the debugger printed," in this case, #theView.

lzx> _
«LzView#0| #theView»

I can call a method on #theView by typing

lzx> _.setAttribute("bgcolor", 0x777777);

and the bgcolor of my view changes immediately.
The last three values the debugger has printed are stored in variables named _, __ and ___.
Up-arrow and down-arrow retrieve this history of commands. Up arrow, return repeats the previous command.

Debug.monitor(who, what) prints out a message each time a particular
property (what) of a particular object (who) changes. Debug.monitor is documented in the developer's guide and is present in 3.1 through 3.4, but not yet present in the DHTML runtime.

And finally, backtracing! Edit the lps.properties file, in $LPS_HOME, to say

compiler.debug.backtrace=true

then you can call Debug.warn('foo'), Debug.info('foo'), or Debug.debug('foo') in your code and it prints a string which you can click on to see the backtrace from that place. If you use
Debug.trace(<object>, <method name>) or Debug.monitor(<object>, <attribute name>) the messages that those output (at function entry/exit or on modification of an attribute) will include a backtrace too.

(Thanks to Tucker for implementing and explaining these tools.)

Wednesday, September 06, 2006

Latest developments at Laszlo Systems

Laszlo Systems just announced a Series C funding round of $8 million. They like us! They really like us!
Meanwhile, I've been working on an implementation of CSS for OpenLaszlo. Adam Wolff and I have been doing the work in a developer branch, coal. Our CSS implementation is planned to be released as part of OpenLaszlo 3.4. Unlike the bone-deep changes to DHTML programming paradigm with the adoption of CSS, the dominant paradigm for writing OpenLaszlo applications will still be to write lzx classes and scripts. OpenLaszlo, unlike DHTML, was designed from the beginning to be a presentation and interaction language, so it has far fewer empty spots to spackle over with an additional syntax layer than did pre-dynamic HTML. CSS will allow for themes, skinning, and a smoother designer/programmer collaboration workflow.
  • We're supporting a big subset of CSS 2.1 selectors: element type, attribute selectors, id selectors, and descendant selectors, while leaving out .class selectors, sibling selectors, pseudo-elements and pseudo-classes.

  • CSS rules are evaluated at construct-time to determine attribute values for any attribute of any node (just about).

  • We have introduced style constraints to specify how to map CSS style properties onto lzx attributes; these are much like the $once, $always, and $path syntaxes already present in OpenLaszlo.

  • There is compiler support for CSS, which feeds the runtime CSS engine.