Agree with Max. Making a .lzo is a batch operation that will (usually) be
carried out on a server-class (build) machine. I don't think this needs the
level of memory optimization that is desirable for incremental
compile-edit-debug cycles.
On 2010-05-11, at 23:10, Henry Minsky wrote:
> I wanted to ask an architectural question about how to handle generating
> .lzo's vs generating DHTML js1 output.
>
> I've been working on making the same 'chunking' API for DHTML as I did for
> swf10, where each call to
> the ObjectWriter's "addScript()" method runs a piece of lzs code through the
> backend compiler and writes it
> to an output file, so we don't have to buffer the whole lzs and output AST
> tree in memory.
>
> If I want to use this 'chunking' API for lzo's should I have addScript()
> write the script chunks out to a temp file? There's a method
> in LibraryWriter which wants to run the whole lzs file through the js
> parser, and then unparse it with the javascript compressor:
>
> void exportScript() {
> out.println("<script when='immediate' type='LZBinary'>\n<![CDATA[\n");
> // Write 'compressed' output
> org.openlaszlo.sc.parser.SimpleNode program =
> (new
> org.openlaszlo.sc.Compiler.Parser()).parse(scriptBuffer.toString());
> // Cf., ScriptCompiler _compileToByteArray
> JavascriptCompressor compressor = new JavascriptCompressor(mProperties);
> compressor.compress(program, out);
> out.println("\n]]>\n</script>");
> }
>
> I'm wondering if I should modify this to run the chunks of script through
> this path incrementally, on each call to addScript(), and stick it into a
> temp file, or just say for the case of compiling an lzo that we use the
> existing code in LIbraryWriter which buffers everything into a giant string.
>
>
> --
> Henry Minsky
> Software Architect
> [email protected]
