Ok will do. Is stuff checked into trunk enough for me to test it?
On 2/7/07, P T Withington <[EMAIL PROTECTED]> wrote:
That would be great if you could verify (and do). It would take one piece of the binary library puzzle off my plate! On 2007-02-07, at 14:18 EST, Henry Minsky wrote: > 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]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
