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.

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.)

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.

a little bit of yiddish

A friend of mine commented to me recently that he is "culturally Jewish." The discussion moved on to cynicism, genX, and my friend's refusal to engage in the former despite being a member of the latter. Later though I reflected, "Am I culturally Jewish?"
I more commonly identify as a "New York Jew" than (just) as jewish; my membership in this sub-sect is mainly signified by my sunday morning ritual, involving lox, bagels, and the New York Times. That is certainly the jewish tradition in which I most consistently participate. I also often think about attending friday night services; ambivalence about participation in religion seems to also be part of being a New York Jew. (I don't think my dabbling in Unitarian Universalism (very cool) or TM (sigh) particularly excludes me from the Tribe.)
My most Jewish daily behavior, though, is invoked as a habit when someone else sneezes. I say gesundheit when all around me everyone else says bless you or god bless you. "Gesundheit" means "be healthy!" in Yiddish. "Gesundheit" is pragmatic; why invoke the blessing of a god that neither I nor the sneezer are sure exists and cannot characterize as a being capable of nor interested in issuing a "blessing"? [In my various lives as an east coast academic or a silicon valley salariman, I assume that most of my contacts are agnostic, atheist, or unitarian universalist.]
So to all of you I say, unprompted by a sneeze, cough, or elevated low-density lipids in your blood work, gesundheit! Because no matter which god you or I do (or don't) believe in, no matter which god we were raised to identify as the One and Only God, no matter whether we cynically or sincerly identify as a member of a particular religion, I do sincerely want you to be healthy and happy. So far as that goes, I'm willing to be a New York Jew, and I claim my heritage with this daily invocation. Gesundheit!

cognitive-behavioral therapy for controlling anxiety (about terrorism)

As has been said many times before, the "war on terror" makes no sense; terror is an emotion, and attacking an emotion or defending againstan emotion is best left to cognitive-behavioral therapy. In the parlance of CBT, we challenge a possibly irrational emotion (say, "terror") with rational thoughts. "The city where I live has never been a target for terrorrism. The city where I live is not an icon of american expansionism. Most people bring harmless beverages onto planes. Most people wear harmless shoes on planes."
The "homeland security" efforts, the boots-on-the-ground in Iraq and Afghanistan, the reactionary travel policies, the color=fear scale, reinforce the (questionably rational) fear of "terrorism." It actually would be pretty rational to infer a real risk of danger from huge efforts by the government to "protect" us -- if we stipulate that "the government" will behave rationally. Which, sadly, it does not.