Not if you keep André in the loop, I expect. (How did he get dropped from the cc?)
Actually, A better solution is if you fixed up your IntermediateWriter to work, because that is the output we really want. That would be a general tool that could be used to include arbitrary .lzx files in the LFC (which is what is happening right now for the special case of the DHTML version of the context menu). On 2010-05-20, at 11:27, Henry Minsky wrote: > I've got a change coming up that will make .lzo files into zipfile archives > instead of > simple gzip format files. Will that be a problem? > > On Thu, May 20, 2010 at 11:10 AM, P T Withington > <[email protected]>wrote: > >> Nice! >> >> Quite cool that you can unpack the .lzo with xslt. :) >> >> On 2010-05-19, at 19:26, André Bargull wrote: >> >>> >>> On 5/20/2010 12:52 AM, P T Withington wrote: >>>> On 2010-05-19, at 18:41, André Bargull wrote: >>>> >>>>> 3) validateReferenceDependencies() is only needed in contextmenu.js, >> because it's compiled with the -g option. Is this necessary at all? It seems >> to be more correct to remove the -g option when compiling contextmenu.lzx >>>> >>>> This actually points up a bug in the .lzo compiler: >>>> >>>> The reason I suggested using -g is to preserve the source line numbers >> in the .lzo, so that when you compile a debug LFC you will get accurate >> backtraces (to the LZX source, rather than to the compressed .lzs source). >>>> >>>> The bug is, if the .lzo compiler is inserting code that only applies in >> $debug mode, it must wrap it in a `if ($debug) { ... }` so that it will be >> correctly elided from a non-debug compile. >>>> >>> >>> Sort of related: I've tweaked the build script in WEB-INF/lps/lfc to >> build the contextmenu.js file automatically. I'm going to send a proper >> review in the next days, but just in case it's useful for someone right now >> I've attached it to this mail, too. >>> <build.xml> >> >> >> > > > -- > Henry Minsky > Software Architect > [email protected]
