we don't have big static datasets, so we can definitely live without that. On Feb 7, P T Withington 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] >
