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]
