On Tue, May 25, 2010 at 9:33 AM, P T Withington <[email protected]> wrote: > It seems like each .swc library needs a top level class, like the app class, > that the app class needs to link to and run?Or is there some feature of flex > Luba we don't know about that does this for you? > > There is the issue that the lzo gloms a lot of individual files together and > linking against it may only want some of that. How do we track which > toplevel expressions go with which piece? Perhaps the top level exprs of > each include in an lzo must be in their own class and the main app must > instantiate that top level class for every include it uses.
Well the semantics of doing an <include> are that if the file you're including instantiates any views, they should get instantiated in the main app. So if you are using an lzo made out of files that instantiate views, then I think they all must get instantiated in the main app. Any class declarations in lzo .swc files just work as expected. The flex linker is smart enough to only pull out the class files it needs from the .swc libraries when it's compiling the main app. So the only thing I think we need to worry about are other top level statements, which would in practice are all calls to LzInstantiateView. I don't *think* the LZX compiler outputs any other kinds of statements, except for a couple related to app init and startup (i.e., canvas.initDone(), and some debugger setup), and those are emitted by the main app compiler, they shouldn't be in the lzo libraries. So maybe we can special case this to collecting calls that do view instantiation ? > > Seems like a fair amount of additinal bookkeeping, but I think we gotta do > it. > > On May 25, 2010, at 1:41, Henry Minsky <[email protected]> wrote: > >> oh crud, I think I see what's happening, in an lzo library, any top >> level script that's emitted by the lzx compiler, to instantiate a view >> for example (generates a call to canvas.LzInstantiateView), is just >> getting discarded when I build the .swc library. The library only >> gets class declarations and global variable definitions, because they >> each have their own .as files. >> >> When compiling an actual application, any top level statements the >> swf9 backend finds get stuffed into the >> LzApplication.runTopLevelDefinitions() method, which is invoked during >> app startup. But when building an lzo library, they aren't getting >> put anywhere. There's no 'main' class to define a method on. >> >> I'm not sure how to solve this. Maybe an lzo needs to contain a >> special <script> block which contains only >> the view instantiations, (or all top level statements, i.e., any >> statement except for a class declaration?) encountered while compiling >> the library source. Then at application compile time the LZX compiler >> appends all those blocks from the lzo's it's opened into the main >> app's runTopLevelDefinitions() method? >> >> >> >> >> >> >> >> >> >> On Mon, May 24, 2010 at 8:19 PM, Henry Minsky <[email protected]> >> wrote: >>> >>> hmm , lemme check that, I I could have sworn that was working. >>> >>> On Mon, May 24, 2010 at 7:17 PM, Max Carlson <[email protected]> >>> wrote: >>>> >>>> Not approved. I don't see the red box around 'vanilla' when I go >>>> through >>>> all the steps and run in non-debug mode on the server, e.g. >>>> trunk-clean/test/testlzo/main.lzx?lzr=swf10 >>>> >>>> On 5/23/10 9:58 PM, Henry Minsky wrote: >>>>> >>>>> fixed bug with listing of includes files in the lzo, modified test case >>>>> to >>>>> cover it >>>>> >>>>> >>>>> >>>>> Change 20100520-hqm-Q by [email protected] on 2010-05-20 01:30:13 EDT >>>>> in /Users/hqm/openlaszlo/trunk >>>>> for http://svn.openlaszlo.org/openlaszlo/trunk >>>>> >>>>> Summary: make lzo files include platform-specific library object code >>>>> >>>>> New Features: >>>>> >>>>> Bugs Fixed: >>>>> >>>>> Technical Reviewer: ptw >>>>> QA Reviewer: max >>>>> Doc Reviewer: (pending) >>>>> >>>>> Documentation: >>>>> >>>>> Release Notes: >>>>> >>>>> Overview: >>>>> >>>>> + lzo files are now implemented as zip archives, and contain optional >>>>> .swc (flash 10) and .js (dhtml) object code files >>>>> >>>>> When targeting swf10 and dhtml, the if the compiler sees the >>>>> platform-specific entry in the lzo file, it will link >>>>> against it directly, rather than compiling the lzs script code block >>>>> from >>>>> the lzo. >>>>> >>>>> + new comand line arg added to lzc, "--lzolibs". Takes a comma >>>>> separated list of external lzo files to link against when building >>>>> your own lzo library. This will be needed by the swf10 backend when >>>>> resolving externals from other swf-10-binary-compiled lzo libs (like >>>>> maybe >>>>> the lz components library someday). >>>>> >>>>> Details: >>>>> >>>>> *** utils/FileUtils.java: >>>>> >>>>> makeXMLReaderForFile() needs to understand new zipfile format for lzo >>>>> files. This scans through and returns the generic LZX file portion of >>>>> the lib (as opposed to the optional binary-runtime-specific entries) >>>>> >>>>> >>>>> *** /sc/JavascriptGenerator.java: >>>>> >>>>> Add a ';' to the end of a block of javascript output, if it does not >>>>> already have one >>>>> >>>>> >>>>> *** sc/SWF10Compiler.java: >>>>> >>>>> Don't generate application framework boilerplate code if we're just >>>>> building a library. >>>>> >>>>> *** sc/SWF9External.java (revision 16441) >>>>> >>>>> Make compileTranslationUnits() accept optional list of external swc >>>>> libs >>>>> to link against >>>>> >>>>> *** sc/DHTMLCompiler.java (revision 16441) >>>>> >>>>> Add hook to allow copying raw byte stream to output, so we can insert >>>>> DHTML-specific precompiled javascript from lzo lib if available. >>>>> >>>>> *** compiler/ObjectWriter.java (working copy) >>>>> >>>>> added schemaDone() API, called by compiler when the schema has been >>>>> computed (all classes >>>>> have been entered into class map) >>>>> >>>>> *** compiler/DHTMLWriter.java (working copy) >>>>> >>>>> If an lzo is being used and is contains a fully-compiled DHTML object >>>>> file, append that to >>>>> the compiler output verbatim. >>>>> >>>>> *** compiler/CanvasCompiler.java (working copy) >>>>> moved code that adds Flash8 LFC to the SWFWriter >>>>> >>>>> *** compiler/LibraryWriter.java (working copy) >>>>> Write out zipfile format archives for lzo libraries. >>>>> >>>>> If runtime targets are specified (e.g., "lzc -c >>>>> --runtimes=swf10,dhtml"), >>>>> we create ObjectWriters for SWF10 and/or >>>>> DHTML, so that we compile runtime-specific object code and store it in >>>>> entries in the lzo. This will speed up compiling/linking lzo's for >>>>> DHTML and SWF10. >>>>> >>>>> Calls to addScript are forwarded to the runtime-specific ObjectWriters >>>>> if they are present. >>>>> >>>>> >>>>> Tests: >>>>> >>>>> ant lztest >>>>> smokecheck swf10/dhtml >>>>> amazon in dhtml/swf10 >>>>> >>>>> test case in test/lzotest: compile the libraries below with these flags >>>>> >>>>> lzc -c --runtime=swf10,dhtml extclass.lzx >>>>> lzc -c --runtime=swf10,dhtml libdir/lib1.lzx >>>>> >>>>> ## test compiling a swf10 lzo which subclasses something from an >>>>> external lzo library >>>>> lzc -c --runtime=swf10,dhtml --lzolibs extclass.lzo libdir/lib2.lzx >>>>> >>>>> then compile main app for all runtimes >>>>> lzc --runtime=swf8 main.lzx >>>>> lzc --runtime=swf10 main.lzx >>>>> lzc --runtime=dhtml main.lzx >>>>> >>>>> also compile via the LPS server >>>>> http://127.0.0.1:8080/trunk/test/testlzo/main.lzx?lzr=swf10&debug=true >>>>> http://127.0.0.1:8080/trunk/test/testlzo/main.lzx?lzr=swf10 >>>>> >>>>> >>>>> >>>>> >>>>> Files: >>>>> A test/testlzo >>>>> A test/testlzo/main.lzx >>>>> A test/testlzo/extclass.lzx >>>>> A test/testlzo/libdir >>>>> A test/testlzo/libdir/lib1.lzx >>>>> A test/testlzo/libdir/lib2.lzx >>>>> A test/testlzo/libdir/myinc.lzx >>>>> M WEB-INF/lps/server/src/org/openlaszlo/utils/FileUtils.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/sc/JavascriptGenerator.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/SWF10Compiler.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/SWF9External.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/SWF9Generator.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/DHTMLCompiler.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/Compiler.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/ObjectWriter.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/DHTMLWriter.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/CanvasCompiler.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/ResourceCompiler.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/SWFWriter.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/LibraryWriter.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/FileResolver.java >>>>> M >>>>> >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/CompilationEnvironment.java >>>>> M >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/IntermediateWriter.java >>>>> M >>>>> >>>>> WEB-INF/lps/server/src/org/openlaszlo/compiler/ScriptElementCompiler.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/Compiler.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/Main.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/SWF9Writer.java >>>>> M WEB-INF/lps/server/src/org/openlaszlo/compiler/Parser.java >>>>> >>>>> Changeset: >>>>> http://svn.openlaszlo.org/openlaszlo/patches/20100520-hqm-Q.tar >>>> >>>> -- >>>> Regards, >>>> Max Carlson >>>> OpenLaszlo.org >>>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >>> >> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] > -- Henry Minsky Software Architect [email protected]
