Er, can't we just create a common superclass of all these writers that does chunking?
I know the lzo writer was initially kludged as a subclass of the DHTML writer, but we need to fix that (which is what I thought was the point of the IntermediateWriter class?) or we are liable to let platform-specific stuff leak into the LZO's, which must be platform-neutral. On 2010-05-21, at 09:51, Henry Minsky wrote: > Yeah it's not using the chunking now. I think it's easy to do, if I can just > instantiate a DHTMLWriter and/or a SWF10Writer to compile to those targets, > and forward calls to addScript() from the LibraryWriter to them. > > I'll give that a try. > > On Fri, May 21, 2010 at 9:08 AM, P T Withington <[email protected]>wrote: > >> [Trimming message, adding laszlo-dev] >> >> The lzo compile path will not have any of your recent "chunking" >> improvements, right? And we know that when running on a memory-constrained >> (and virtual) machine making the JVM heap bigger buys you nothing because >> you just trade GC for swap. >> >> If it is easy, maybe you could move the "chunking" writer stuff 'up the >> tree' of writer classes so that the lzo-writing path gets the same benefit? >> I expect right now that the lzo path is still the 'one big string' issue. >> lzo's should not be affected by debug/backtrace except that when you turn >> on debug the code is not obfuscated or compressed and the #file/line info is >> preserved in the lzo. >> >> [... Long email thread about excessive lzo compile times with confidential >> information removed ...] > > > > > -- > Henry Minsky > Software Architect > [email protected]
