Since we are appreciating... let me add my appreciation. At work (A major Financial Institution) we are using XML-Xerces (where before we had used expat), because we wanted a _validating_ parser, for a particular project. It worked great. It was only a minor annoyance that the current version is 'old' (2.3).
At home, I created and submitted a Gentoo Linux portage ebuild for XML-Xerces, but by the time they got around to looking at it, their standard Xerces (had moved on to 2.4), and it would nolonger build without a downgrade, so they rejected it with the note I that I could reopen the bugzilla ticket, if I had an ebuild that would work against 2.4. or 2.5. I had to hack my system to keep portage from upgrading Xerces (and breaking XML-Xerces). So I would love to see a version built against a more recent xerces-c. I promise that I will upgrade the ebuild, and resubmit, if an new version is made available. What is left to do? On Tue, 2004-06-15 at 21:51, Jason E. Stewart wrote: > Chris Cheung <[EMAIL PROTECTED]> writes: > > > Also, just want to let you know that I appreciate your voluntary work. > > We are actual using Xerces-Perl in a commercial project, which will be put > > into production in 1 or 2 months. > > Hi Chris! > > Thanks for the note of appreciation, it helps emmensely. I started > working on this project because I needed a good XML parser for Perl, > and I've continued working on it, mostly alone, for that same reason. > > Having a user community is something that really inspires me, so > thanks again for the note. > > > Xerces-Perl is good as it enables Perl applications directly access the > > Xerces-C ability to perform validation against schema, apart from parsing > > and serialization. (It seems that libxml2, which also has a Perl wrapper, > > does not do validation so well.) However, the memory leak problem (during > > parsing even if validation is turned off, and during serialization) is > > hindering the project to use Xerces in a more large-scale way. > > I agree. I debugged this as much as I was able and came up with a big > zero. It is *not* a Xerces-C problem, so it is a XML-Xerces problem - > but given the code we are executing I am not able to figure out where > the problem lies. > > I could really use some help here. > > If anyone has some time to run a test program through purify or > valgrind and identify exactly where the leaks are happening I'll be > happy to fix it. > > Cheers, > jas. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
