I think it's already ripped out in trunk, for dynamic dataset loading, it's just the compile time datasets still use it, if I recall correctly. So most of the code is there, I don't think it would be difficult (famous last word) to back port the code to emit LzInstantiateView of LzDataset, instead of inlining the datasets.
On 2/7/07, P T Withington <[EMAIL PROTECTED]> wrote:
I already backported the string fix "by accident". We'd need a readout from the 'ad hoc binary library design committee' (cc-ed) to know if ripping out the data compiler from trunk is acceptable. On 2007-02-07, at 13:45 EST, Henry Minsky wrote: > I might be able to do some hack with backporting the legals code for > initializing datasets from XML strings. We'd have to backport the > compiler > fix for strings longer than 64K if they have static datasets that > large... > > > > > On 2/7/07, P T Withington <[EMAIL PROTECTED]> wrote: >> >> Yeah, I think I punted on datasets. Now I have to look harder. >> Actually, if you want to pitch in here, it would be great. The 3.4 >> dataset way just can't work in binary libraries as currently spec- >> ed. We'd have to treat them more like resources -- just save the LZX >> to the binary so that it can be compiled correctly when the binary is >> linked in. >> >> On 2007-02-07, at 12:36 EST, Henry Minsky wrote: >> >> > We had a big change about how top level datasets are compiled into >> > apps >> > between 3.4 and legals; in 3.4 they are inlined as swf byte code to >> > build >> > the dataset, whereas in >> > legals they are compiled in as XML strings that get passed as init >> > arg to a >> > LzDataset to get parsed and instantiated at runtime. I thought I >> saw >> > something in ptw's changeset that was special casing datasets to >> > not be put >> > into in libraries? I need to look again... >> > >> > On 2/7/07, P T Withington <[EMAIL PROTECTED]> wrote: >> >> >> >> On 2007-02-07, at 11:16 EST, Jim Grandy wrote: >> >> >> >> > On Feb 7, 2007, at 8:06 AM, Adam Wolff wrote: >> >> >> diamond relies on the behavior where if I don't specify a file >> >> name >> >> >> for a directory in an include, it looks for the library.lzx >> file >> >> >> in that >> >> >> directory. e.g. >> >> >> >> >> >> <include href="foo/bar"/> >> >> >> >> >> >> Actually includes >> >> >> foo/bar/library.lzx >> >> >> >> >> > >> >> > Is this documented behavior? The comments at the top of lps/ >> >> > components/library.lzx &co. suggest these files are only used by >> >> > the documentation generator. Assuming that is true, I've been >> >> > modifying the library.lzx files in the components to suit the >> >> > refguide. >> >> >> >> I don't know where it is documented, but the compiler will >> definitely >> >> implicitly add library.lzx to a directory in an include (and >> has done >> >> so for as long as I can remember). >> >> >> >> The binary library changes make the compiler search for >> library.lzo >> >> before loading library.lzx. >> >> >> >> It is _supposed_ to be the case that if your library contains >> auto- >> >> includes, and you binary compile your library, the auto- >> includes will >> >> _not_ be included in the binary, but will be auto-loaded when you >> >> load your library (trying to mimic as much as possible the normal >> >> library behavior). >> >> >> >> Pablo's test reveals another screw-case that is not handled: You >> >> include a library and elsewhere in your program also a sub- >> library >> >> of that library. Then you binary-compile the library. The binary >> >> library gets loaded, but the compiler does not realize that that >> >> implies the sub-library is also loaded, so it tries to re-load the >> >> sub-library and creates duplicate definition warnings. I will >> have >> >> to add some annotation to binary libraries to note all the sub- >> >> libraries that comprise the library. [er, Mr. Strunk, did I use >> that >> >> word correctly? I've always wanted to find a use for it.] >> >> >> > >> > >> > >> > -- >> > Henry Minsky >> > Software Architect >> > [EMAIL PROTECTED] >> >> > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
