Re: xmls 0.2 released

On Thu, 2003-06-12 at 23:05, Miles Egan wrote:
> CL-XML seems
> very complete and full-featured, but pretty dependent on details of CLOS
> that make also make it hard to run in SBCL.

The latest release of CL-XML works fine with SBCL 0.8.0. There is only
one minor issue left - CL-XML has a (require 'gray-streams) somewhere,
which is not necessary (or meaningful) for SBCL, but if you just
(provide 'gray-streams) or delete the offending form, you are done.

> > > I've noticed you're using the same xml tag as keyword approach that
> > > Franz' parser uses.  I like this approach overall.  Does it create any
> > > gc issues?  If a long-running parser parses a wide variety of documents
> > > with different tags will it eventually exhaust memory with all the new
> > > keyword symbols?
> > 
> > The ultimate solution would be to make this a selectable option ;-)
> > Symbols are faster and more efficient all the way. And doesn't an 
> > unbound, unused symbol get GC-ed ?
> > I think the symbol table implementation should use weak references.
> 
> I'm not sure.  I suppose it's probably implementation dependent.  If the
> runtime does clean up the symbols then keywords do seem like a win all
> around.

Is this really an issue? How much space does a symbol take? I just
checked, Docbook 4.2 seems to have slightly under 400 element types
(counted with "grep '<!ELEMENT' | wc -l", TEI P4 about 450. Those are
the biggest DTDs I have lying around here. I don't really expect to
encounter that many different element types in a single application,
but even if I would, interning 850 keywords is not something I
would worry about too much until it shows to be a problem in practice.

And if it is, one could always intern them in some distinct package
that can be safely deleted, or not intern them at all.