[Laszlo-dev] laszlo as a compiler
steele at laszlosystems.com
Mon Jan 24 15:04:59 PST 2005
On Jan 24, 2005, at 2:12 PM, Chris Lyman wrote:
> Hi Chris,
> In regards to the first question, I’d recommend posting to
> the Wiki at:
There's also page of Developer documentation (docs for people working
on the Laszlo implementation) at
> The other two questions are going to require smarter
> monkeys than I. J
I'm not smarter, but I am a monkey, so I'll try :-)
> -----Original Message-----
> From: laszlo-dev-bounces at openlaszlo.org
> [mailto:laszlo-dev-bounces at openlaszlo.org] On Behalf Of Chris Gallo
> Sent: Monday, January 24, 2005 1:09 PM
> To: laszlo-dev at openlaszlo.org
> Subject: [Laszlo-dev] laszlo as a compiler
> A few questions:
> 1. I've gotten laszlo 3.0b1 to work as a compiler without needing to
> compile the source. Is there a place I could post instructions and
> files on how to do this? ( I don't have a public web presence). I
> basically just modified the compiler.Main class and javac'd it in the
> lib directory of the binary distribution. This enables me to use the
> laszlo compiler within visual studio.net quite easily, which is really
> 2. In the compiler class, I used an ugly hack. In the top of the lzc
> function, I had to add the line:
> LPS.setHome("c:\\Program Files\\Laszlo Presentation Server
> Otherwise the compiler wouldn't compile my .lzx. Is there a better way
> to do this?
Not really. There's a different way to do that, which is to create the
caches directly instead of set the global variable that the caches are
created from. It's documented at
http://www.openlaszlo.com/wiki/Compiler_API, but actually the solution
you figured out is considerably more concise.
> 3. I would like to play with expanding the capabilities of the xpath
> engine so that, for instance, one could use axes in queries, or
> comparison operators.
> I see that modifying the LzDatapoiner.as file in the 'lfc' directory
> may enable me to do this. My question is, is there a way to recompile
> the .as files without recompiling the entire server application? In
> the binary distribution, I see that there are no .as files in the lfc
> directory, only .lzl files, so I assume the .as files are converted to
> .lzl at some point during the build process. I would like to just be
> able to recompile the .lzl files and stick those in the binary
> distribution lfc directory.
There is: Use the build file in WEB-INF/lps/lfc:
> cd WEB-INF/lps/lfc
> ant build
There are actually ten(!) LFC files, and this builds all of them. Five
of these files are used to build swf6 applications:
- LFC6.lzl, used to build hello.lzx
- LFC6-debug.lzl, used to build hello.lzx?debug=true, or any file with
<canvas debug="true">. This contains the debugger nub.
- LFC6-krank.lzl, and LFC5-krank-debug.lzl, used to build the (debug
and non-debug) versions of applications that are then KRANKed. These
contain the krank client, function metadata that is used to reconstruct
the application state, and additional instructions that add metadata to
objects that are created during initialization.
- LFC6-profile.lzl, used to build applications that contain
instrumentation for call profiling
The other five are used to build swf5 applications (if you're running
You will soon discover that 'ant build' takes a long time to recompile
every file ten times after every one-line change that you make. Here's
what we actually do during development:
1. Pick a version to debug against, say swf6 debug. (It's generally
easier to develop against the debug versions.)
2. In a shell terminal window that is open to the lfc directory, invoke
the 'buildlfc' command that builds that version of the LFC library ---
say, 'buildlfcdebug'. It will spin for a while, and create a new build
of that library, but it will stay open so that you can rebuild the
library more quickly. You've already saved time because you're not
building the other library versions.
3. Open your test app with a URL that links against that version (in
this case http://localhost:8080/lps-3.0b2/test.lzx?lzr=swf6&debug=true,
to pick up the +debug swf6 version --- krank and profile default to
4. Edit the LFC source(s).
5. Press Enter in the 'buildlfc' terminal. This will rebuild the LFC
library much faster than the first compilation.
6. Press the browser Reload button, to relink the application and run
Your edit-compile-debug cycle is (4-6), which is reasonably fast.
(It's about the same speed as working on an LZX source file. You've
got one more window to cycle through to rebuild the LFC library, but
the monkeys here who are smarter than me use macros for this.)
The failure mode is to rebuild ONE version of the library, and link
against ANOTHER. My favorite debugging technique if nothing seems to
be having any effect is to introduce some change that you know will
break everything, and see if it actually does.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 7542 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050124/f4351ee0/attachment.bin
More information about the Laszlo-dev