You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Tinny Ng <tn...@ca.ibm.com> on 2001/11/22 16:56:43 UTC
Plan for Xerces-C++ 1.6
Hi all,
We've finished most of the schema features, and are now in testing and
wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
you have any urgent fix or important code wanna to get in, please do so.
Feel free to play with the latest nightly build
(http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
should be sometime early December.
Thanks!
Regards,
Tinny Ng
XML Parsers Development
IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: CVS: RE: Plan for Xerces-C++ 1.6
Posted by Juergen Hermann <jh...@web.de>.
On Thu, 29 Nov 2001 09:41:46 +0530, Renji Panicker wrote:
>I have found that renaming the sub-directory in my cvsroot does the trick. I
>don't kno how safe it is supposed to be, but I've not had a problem with it
>so far.
That is another way to do it, but it has implications. When doing mass renaming
through repo manipulation, a better way is to COPY the directory in the repo,
then "cvs rm -Rf olddir" in your working dir.
Ciao, Jürgen
--
Jürgen Hermann, Developer (jhe@webde-ag.de)
WEB.DE AG, http://webde-ag.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
CVS: RE: Plan for Xerces-C++ 1.6
Posted by Renji Panicker <re...@aliyance.com>.
I have found that renaming the sub-directory in my cvsroot does the trick. I
don't kno how safe it is supposed to be, but I've not had a problem with it
so far.
-----Original Message-----
From: Jason E. Stewart [mailto:jason@openinformatics.com]
Sent: Wednesday, November 28, 2001 1:49 AM
To: xerces-c-dev@xml.apache.org
Subject: Re: Plan for Xerces-C++ 1.6
"Tinny Ng" <tn...@ca.ibm.com> writes:
> > Remember that this will require a cvs change. We need to rename the src
directory
> > to xercesc. Some cvs experts gave some advice about that at the time.
> >
>
> Since CVS cannot rename, the cleanest way is to create everything as new
directory
> and new files, and then delete the old directory "src". And as far as I
know, the
> deleted directory information is still stored in CVS "Attic" and is still
> accessible. Thus we can still access old history log if needed.
As long as you mean 'remove' as in 'cvs remove' then you're
correct. The real advantage to doing it that way is all the old tags
still work, so that you can check out historical copies. The (slight)
disadvantage is that all the history that should be associated with
the file is in two separate places.
It's unfortunate that CVS forces you to remove a file and then re-add
it when it should just have a 'move' command. Luckily it seems that
subversion (subversion.tigris.org) will be ready for general use
pretty soon. I've got a couple of test repositories using the latest
alpha of subversion and I'm pretty happy.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Tinny Ng" <tn...@ca.ibm.com> writes:
> > Remember that this will require a cvs change. We need to rename the src directory
> > to xercesc. Some cvs experts gave some advice about that at the time.
> >
>
> Since CVS cannot rename, the cleanest way is to create everything as new directory
> and new files, and then delete the old directory "src". And as far as I know, the
> deleted directory information is still stored in CVS "Attic" and is still
> accessible. Thus we can still access old history log if needed.
As long as you mean 'remove' as in 'cvs remove' then you're
correct. The real advantage to doing it that way is all the old tags
still work, so that you can check out historical copies. The (slight)
disadvantage is that all the history that should be associated with
the file is in two separate places.
It's unfortunate that CVS forces you to remove a file and then re-add
it when it should just have a 'move' command. Luckily it seems that
subversion (subversion.tigris.org) will be ready for general use
pretty soon. I've got a couple of test repositories using the latest
alpha of subversion and I'm pretty happy.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Tinny Ng <tn...@ca.ibm.com>.
Murray Cumming wrote:
> Remember that this will require a cvs change. We need to rename the src directory
> to xercesc. Some cvs experts gave some advice about that at the time.
>
Since CVS cannot rename, the cleanest way is to create everything as new directory
and new files, and then delete the old directory "src". And as far as I know, the
deleted directory information is still stored in CVS "Attic" and is still
accessible. Thus we can still access old history log if needed.
CVS experts, please correct me if I am wrong....
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-11-27 at 16:45, Tinny Ng wrote:
> Murray / Jason,
>
> Do you have the sane_include patch against the latest code base ready?
No. I'll prepare one for you tomorrow.
> I plan to release Xerces 1.6 sometime early December, i.e. end of next week or
> so. It is appreciated if you can have a patch for your proposal some time
> this week. Please provide migration information as well. Thanks!
Remember that this will require a cvs change. We need to rename the src directory
to xercesc. Some cvs experts gave some advice about that at the time.
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Xerces 1.5.2 for SCO Openserver
Posted by Jorge Pozo Ramirez <j....@externo.mju.es>.
Greetings.
I've just managed to compile a succesfull port of Xerces 1.5.2 on a SCO
OpenServer 5.0.4 machine.
I used a SCO tweaked version of GNU C++ (available as Skunkware at caldera
FTP site), known as gcc-2.95.2pl1
I also have OSRCompat Package for UnixWare 7.1.1 installed.
I attach a diff archive of the changes I made to the source code. Take a
look on it, as I didn't had time to put the code clean and shiny.
Regards.
Jorge
Jorge Pozo Ramírez
Accenture
Technology Consulting Services
Government GMU
email: jorge.pozo.ramirez@accenture.com
**************************************************
Subdirección General de Informática
- Ministerio de Justicia -
Madrid. España.
email: j.pozo@externo.mju.es
tel: 913902646
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by PeiYong Zhang <pe...@ca.ibm.com>.
Murray,
Yes we are working on it and right now in the test building stage, once it is
done, the changes will be put into CVS and the community can help to test,
as well as to port to other existing platforms, such as BCB5, Mac, etc.
Rgds,
PeiYong
Murray Cumming wrote:
> On Fri, 2001-12-14 at 14:00, Tinny Ng wrote:
> > I will be on vacation during x'mas. Unless other committers volunteer to do this,
> > otherwise I plan to do it sometime in
> > January next year.
>
> Could you please give us an update on this? It's been such a long time.
> I received an off-list email from Peiyong Zhang <pe...@ca.ibm.com>
> about this. It seems like he's doing something about it but he hasn't
> replied to my replies.
>
> > Murray Cumming wrote:
> >
> > > On Tue, 2001-12-04 at 18:31, Murray Cumming wrote:
> > > > On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> > > > > I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> > > > > only for UNIX platforms, I think I need more time to integrate the changes to
> > > > > Windows/OS2/BCB/MacOS project files, and update the documentation as well.
> > > >
> > > > I agree. You need to apply the patch, direct people to the cvs or
> > > > appropriate nightly, and only release it when they say it's OK.
> > >
> > > Can you tell us when you expect to apply this?
> > >
> > > --
> > > Murray Cumming
> > > murrayc@usa.net
> > > www.murrayc.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> --
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Murray Cumming <mu...@t-online.de>.
On Fri, 2001-12-14 at 14:00, Tinny Ng wrote:
> I will be on vacation during x'mas. Unless other committers volunteer to do this,
> otherwise I plan to do it sometime in
> January next year.
Could you please give us an update on this? It's been such a long time.
I received an off-list email from Peiyong Zhang <pe...@ca.ibm.com>
about this. It seems like he's doing something about it but he hasn't
replied to my replies.
> Murray Cumming wrote:
>
> > On Tue, 2001-12-04 at 18:31, Murray Cumming wrote:
> > > On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> > > > I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> > > > only for UNIX platforms, I think I need more time to integrate the changes to
> > > > Windows/OS2/BCB/MacOS project files, and update the documentation as well.
> > >
> > > I agree. You need to apply the patch, direct people to the cvs or
> > > appropriate nightly, and only release it when they say it's OK.
> >
> > Can you tell us when you expect to apply this?
> >
> > --
> > Murray Cumming
> > murrayc@usa.net
> > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Tinny Ng <tn...@ca.ibm.com>.
I will be on vacation during x'mas. Unless other committers volunteer to do this,
otherwise I plan to do it sometime in
January next year.
Tinny
Murray Cumming wrote:
> On Tue, 2001-12-04 at 18:31, Murray Cumming wrote:
> > On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> > > I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> > > only for UNIX platforms, I think I need more time to integrate the changes to
> > > Windows/OS2/BCB/MacOS project files, and update the documentation as well.
> >
> > I agree. You need to apply the patch, direct people to the cvs or
> > appropriate nightly, and only release it when they say it's OK.
>
> Can you tell us when you expect to apply this?
>
> --
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-12-04 at 18:31, Murray Cumming wrote:
> On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> > I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> > only for UNIX platforms, I think I need more time to integrate the changes to
> > Windows/OS2/BCB/MacOS project files, and update the documentation as well.
>
> I agree. You need to apply the patch, direct people to the cvs or
> appropriate nightly, and only release it when they say it's OK.
Can you tell us when you expect to apply this?
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-12-04 at 18:31, Murray Cumming wrote:
> On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> > I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> > only for UNIX platforms, I think I need more time to integrate the changes to
> > Windows/OS2/BCB/MacOS project files, and update the documentation as well.
>
> I agree. You need to apply the patch, direct people to the cvs or
> appropriate nightly, and only release it when they say it's OK.
I mean by this also that you should ask other people to make the changes
for other platforms.
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-12-04 at 18:06, Tinny Ng wrote:
> I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
> only for UNIX platforms, I think I need more time to integrate the changes to
> Windows/OS2/BCB/MacOS project files, and update the documentation as well.
I agree. You need to apply the patch, direct people to the cvs or
appropriate nightly, and only release it when they say it's OK.
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / sane_include patch
Posted by Tinny Ng <tn...@ca.ibm.com>.
I've reviewed Murray's patch for sane_include, it looks ok. But since the patch is
only for UNIX platforms, I think I need more time to integrate the changes to
Windows/OS2/BCB/MacOS project files, and update the documentation as well.
I agreed with Jason that we shouldn't stop the users from getting full Schema
support, because of this patch delay. So I am going to release Xerces-C++ 1.6
within the next two days as planned, without this sane_include changes but has full
schema support. And then take my time to integrate the Murray's patch to the CVS.
So this sane_include change will be there for Xerces-C++ 1.7 next year.
Unless I hear otherwise, the Xerces-C++ 1.6 should be ready by Thursday or so.
Thanks!
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Tinny Ng" <tn...@ca.ibm.com> writes:
> Do you have the sane_include patch against the latest code base
> ready?
>
> I plan to release Xerces 1.6 sometime early December, i.e. end of next week or
> so. It is appreciated if you can have a patch for your proposal some time
> this week. Please provide migration information as well. Thanks!
Hey Tinny,
I will have exactly ZERO time for xerces for the next two weeks,
sorry.
My feeling is that because the sane_includes patch affects use apps, I
wouldn't want to stop them from getting full Schema support, because
of that patch. So I would be happy to see the patch go in immediately
after the 1.6 release.
Because its a reorganization of a bunch of files, there was an issue
of how it would be implemented in CVS. So I think we should take our
time with this one.
It's not my baby, however, it's really up to Murray.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <mu...@t-online.de> writes:
> On Tue, 2001-11-27 at 16:45, Tinny Ng wrote:
> > Murray / Jason,
> >
> > Do you have the sane_include patch against the latest code base ready?
>
> In the previous sane_includes package I seem to have edited
> generated files. I'm trying to do it right this time, but I can't
> figure out how the Xerces-C++ build system works.
>
> src/Makefile.in seems to be generated from src/Makefile.incl, but
> also includes stuff from scripts/packageBinaries.pl. How would I
> regenerate Makefile.in? Or, in other words, what's the
> strange-Xercesc-C++-build-system equivalent of autogen.sh (aka
> aclocal, autoconf, automake, etc.)
Hey Murry,
Anything labeled '.in' is hand generated, namely:
* configure.in - used by autoconf to create configure
* Makefile.in - used by configure to create Makefile
run autoconf to create configure, and run configure to create
Makefile. The only odd part of the Xerces build system (and it is odd
enough) is that you need runConfigure.pl.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-11-27 at 16:45, Tinny Ng wrote:
> Murray / Jason,
>
> Do you have the sane_include patch against the latest code base ready?
In the previous sane_includes package I seem to have edited generated files.
I'm trying to do it right this time, but I can't figure out how the Xerces-C++
build system works.
src/Makefile.in seems to be generated from src/Makefile.incl,
but also includes stuff from scripts/packageBinaries.pl.
How would I regenerate Makefile.in? Or, in other words, what's the
strange-Xercesc-C++-build-system equivalent of autogen.sh (aka aclocal,
autoconf, automake, etc.)
>
> I plan to release Xerces 1.6 sometime early December, i.e. end of next week or
> so. It is appreciated if you can have a patch for your proposal some time
> this week. Please provide migration information as well. Thanks!
>
> Tinny
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Tinny Ng <tn...@ca.ibm.com>.
Murray / Jason,
Do you have the sane_include patch against the latest code base ready?
I plan to release Xerces 1.6 sometime early December, i.e. end of next week or
so. It is appreciated if you can have a patch for your proposal some time
this week. Please provide migration information as well. Thanks!
Tinny
"D. Stimits" wrote:
> Tinny Ng wrote:
> >
> > Hi all,
> >
> > We've finished most of the schema features, and are now in testing and
> > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > you have any urgent fix or important code wanna to get in, please do so.
> >
> > Feel free to play with the latest nightly build
> > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> >
> > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > should be sometime early December.
>
> I believe fixes for the install and directory layout have already been
> put in, based on problems with install configuration for the include
> directory (and also trying to get the source tree include structure to
> match the intended install tree of the includes). I just wanted to be
> sure the packaging issues haven't been lost.
>
> D. Stimits, stimits@idcomm.com
>
> >
> > Thanks!
> >
> > Regards,
> >
> > Tinny Ng
> > XML Parsers Development
> > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by "D. Stimits" <st...@idcomm.com>.
Tinny Ng wrote:
>
> Hi all,
>
> We've finished most of the schema features, and are now in testing and
> wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> you have any urgent fix or important code wanna to get in, please do so.
>
> Feel free to play with the latest nightly build
> (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
>
> Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> should be sometime early December.
I believe fixes for the install and directory layout have already been
put in, based on problems with install configuration for the include
directory (and also trying to get the source tree include structure to
match the intended install tree of the includes). I just wanted to be
sure the packaging issues haven't been lost.
D. Stimits, stimits@idcomm.com
>
> Thanks!
>
> Regards,
>
> Tinny Ng
> XML Parsers Development
> IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Question about public id
Posted by Lihong Pei <Li...@xilinx.com>.
Hi,
I have a question about public id.
>From the web, it mentioned that public id has to be in certain format like:
prefix//owner-identifier//text-class text-description//language//display-version.
However, W3C does not mention it and implied it could be in any format what the allowed
PubidChar.
I'm wondering if I write a Xml file with
<!DOCTYPE TypeLib PUBLIC "$XILINX/data/xml/Ldm/Ldm_TypeLib.dtd"
"http://web/randd/software/xfndry/rtf/data/xml/Ldm/Ldm_TypeLib.dtd" > , in which
$XILINX will be resolved by my own EntityResolver, will it be OK?
Will <!DOCTYPE TypeLib SYSTEM "$XILINX/data/xml/Ldm/Ldm_TypeLib.dtd"> be acceptable? The
concern is that SYSTEM id has to be a URI, while "$XILINX/data/xml/Ldm/Ldm_TypeLib.dtd"
could only be resolved my parse with my own EntityResolver.
Thanks a lot in advance!
Lihong Pei
Re: FreeBsd Patch (was Re: Plan for Xerces-C++ 1.6)
Posted by Tinny Ng <tn...@ca.ibm.com>.
Max,
I've put the latest nightly packages to
http://xml.apache.org/dist/xerces-c/nightly/2001-11-30/ which has Michael's patch in it.
Please use that as your patch's code-base. If you can send me your patch early next week, I
think I can still incorporate it into Xerces-C++ 1.6.
Thanks for your contribution.
Tinny
Max Gotlib wrote:
> Tinny,
>
> As the co-author of "freebsd-iconv" patch i can state, that i'm able to
> create separate freebsd-specific iconv module. BTW, freebsd 4.4-release
> does not fix the problem - still incomplete implementation of wcs in
> libc (the same is for -current as far as i know).
>
> In such a context, i've got a question: should i wait for xerces-c-1.6
> with ICU-only freebsd support and reincarnate the patch ? Or should it be
> possible to incorporate that staff into 1.6 (i have to spend two ore three
> days "wrestling" with the code) ?
>
> --
> Max.
>
> On Thu, 29 Nov 2001, Tinny Ng wrote:
>
> > Michael,
> >
> > Your patch is now in. If FreeBSD 4.4 may fix the problem, I will leave Iconv as is and
> > update FAQ. Thanks for you input.
> >
> > Tinny
> >
> > Michael Huedepohl wrote:
> >
> > > Tinny Ng wrote:
> > > >
> > > > Michael,
> > > >
> > > > The compilation error should have been fixed by Pei Yong yesterday, and I have just
> > > > posted the newer version of latest nightly build
> > > > (http://xml.apache.org/dist/xerces-c/nightly/2001-11-29/). Please try again.
> > >
> > > Well, our emails just crossed each other at the same time.
> > > Indeed, this problem is done.
> > > >
> > > > Regarding the patch, to make my life easier, it is appreciated if you can use the
> > > > latest code base.
> > >
> > > Well, I've done this meanwhile, as written in the last message.
> > > >
> > > > And about the IconvTransService.cpp changes, just #define wint_t XMLCh in
> > > > IconvTransService.cpp, but not in the header, will that lead to any link error?? I
> > >
> > > It IS in IconvTransService.cpp, has never been in the header!
> > > There's no change at all from my side to IconvTransService.hpp!
> > >
> > > > would prefer an ICU-only port patch with FAQ updated for Iconv problem to avoid OS
> > > > specific changes in IconvTransService.cpp. Or may be you can do something similar
> > > > to 390 (Iconv390TransService) and 400 (Iconv400TransService) => create a FreeBsd
> > > > specific Iconv service. This approach also sounds better.
> > >
> > > Unfortunately, for the rest of the year I'm very short on time,
> > > so I think it's not realistic to make this change now.
> > > I think it would be annoying not to have Iconv, but I leave it up to you
> > > just to omit the IconvTransService.cpp changes and add some words to the FAQ.
> > >
> > > Michael
> > > >
> > > > Tinny
> > > >
> > > > Michael Huedepohl wrote:
> > > >
> > > > > Tinny Ng wrote:
> > > > > >
> > > > > > Michael,
> > > > > >
> > > > > > Just checked the mail archive, and I think you have submitted two patches.
> > > > > > One on Sept 27, and one on Oct 1 ....
> > > > >
> > > > > The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> > > > > The second patch included a patch from Max Gotlib for the Iconv transcoder,
> > > > > in addition. Both are based on Xerces 1.5.1 release.
> > > > >
> > > > > > To avoid grepping the wrong patch, can you zip all your patches (better use
> > > > > > the latest code base) and resend the zip file again? Thanks!!
> > > > >
> > > > > I tried to use the nightly build from yesterday
> > > > > (xml-xerces_20011128111840.tar.gz)
> > > > > for forming a new patch, but this version produced compilation errors with gcc
> > > > > (see below). I checked it on Solaris with the original sources, and got the
> > > > > same errors - so it's independent from the FreeBSD port.
> > > > >
> > > > > >
> > > > > > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > > > > > Normally this should coded in those compiler specific header
> > > > > > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > > > > > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > > > > > IconvTransService.cpp directly.
> > > > >
> > > > > I understand your intention, but I'm afraid this will be hard or impossible,
> > > > > because my ICU version uses the original XMLCh definition, and only the IConv
> > > > > version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> > > > > take
> > > > > place in IconvTransService.cpp where also some FreeBSD replacements for the
> > > > > wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> > > > > not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> > > > > <wchar.h> and <wctype.h>.
> > > > >
> > > > > So, what do you think - can you use my patch from Sept 27 and merge the
> > > > > changes and bug fixes which appeared after 1.5.1 into it, or would you
> > > > > like to get a new patch based on the nightly build although I cannot test it
> > > > > because of the compilation errors caused by some other bug?
> > > > > And in the latter case, do you prefer the ICU-only port without OS specific
> > > > > changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> > > > > compromise in code structure?
> > > > >
> > > > > Here are the compiler messages:
> > > > >
> > > > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> > > > > XMLAbstractDoubleFloat.cpp
> > > > > In file included from XMLAbstractDoubleFloat.cpp:72:
> > > > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > > > declaration `operator =' with no type
> > > > > gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> > > > > gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
> > > > >
> > > > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> > > > > DatatypeValidatorFactory.cpp
> > > > > In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> > > > > from
> > > > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > > > from DatatypeValidatorFactory.cpp:165:
> > > > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > > > declaration `operator =' with no type
> > > > > In file included from
> > > > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > > > from DatatypeValidatorFactory.cpp:165:
> > > > > /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> > > > > `operator =' with no type
> > > > > In file included from
> > > > > /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> > > > > from DatatypeValidatorFactory.cpp:166:
> > > > > /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> > > > > `operator =' with no type
> > > > > gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> > > > > gmake[2]: Leaving directory
> > > > > `/home/michael/xerces_20011128111840/src/validators/datatype'
> > > > >
> > > > > Regards, Michael
> > > > >
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Tinny
> > > > > >
> > > > > > Michael Huedepohl wrote:
> > > > > >
> > > > > > > Is it possible to integrate the FreeBSD support supplied by me
> > > > > > > some weeks ago?
> > > > > > >
> > > > > > > --
> > > > > > > Michael Huedepohl, Mozquito Technologies
> > > > > > >
> > > > > > > Tinny Ng wrote:
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > We've finished most of the schema features, and are now in testing and
> > > > > > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > > > > > you have any urgent fix or important code wanna to get in, please do so.
> > > > > > > >
> > > > > > > > Feel free to play with the latest nightly build
> > > > > > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > > > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > > > > > >
> > > > > > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > > > > > should be sometime early December.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Tinny Ng
> > > > > > > > XML Parsers Development
> > > > > > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FreeBsd Patch (was Re: Plan for Xerces-C++ 1.6)
Posted by Max Gotlib <ma...@cca.usart.ru>.
Tinny,
As the co-author of "freebsd-iconv" patch i can state, that i'm able to
create separate freebsd-specific iconv module. BTW, freebsd 4.4-release
does not fix the problem - still incomplete implementation of wcs in
libc (the same is for -current as far as i know).
In such a context, i've got a question: should i wait for xerces-c-1.6
with ICU-only freebsd support and reincarnate the patch ? Or should it be
possible to incorporate that staff into 1.6 (i have to spend two ore three
days "wrestling" with the code) ?
--
Max.
On Thu, 29 Nov 2001, Tinny Ng wrote:
> Michael,
>
> Your patch is now in. If FreeBSD 4.4 may fix the problem, I will leave Iconv as is and
> update FAQ. Thanks for you input.
>
> Tinny
>
> Michael Huedepohl wrote:
>
> > Tinny Ng wrote:
> > >
> > > Michael,
> > >
> > > The compilation error should have been fixed by Pei Yong yesterday, and I have just
> > > posted the newer version of latest nightly build
> > > (http://xml.apache.org/dist/xerces-c/nightly/2001-11-29/). Please try again.
> >
> > Well, our emails just crossed each other at the same time.
> > Indeed, this problem is done.
> > >
> > > Regarding the patch, to make my life easier, it is appreciated if you can use the
> > > latest code base.
> >
> > Well, I've done this meanwhile, as written in the last message.
> > >
> > > And about the IconvTransService.cpp changes, just #define wint_t XMLCh in
> > > IconvTransService.cpp, but not in the header, will that lead to any link error?? I
> >
> > It IS in IconvTransService.cpp, has never been in the header!
> > There's no change at all from my side to IconvTransService.hpp!
> >
> > > would prefer an ICU-only port patch with FAQ updated for Iconv problem to avoid OS
> > > specific changes in IconvTransService.cpp. Or may be you can do something similar
> > > to 390 (Iconv390TransService) and 400 (Iconv400TransService) => create a FreeBsd
> > > specific Iconv service. This approach also sounds better.
> >
> > Unfortunately, for the rest of the year I'm very short on time,
> > so I think it's not realistic to make this change now.
> > I think it would be annoying not to have Iconv, but I leave it up to you
> > just to omit the IconvTransService.cpp changes and add some words to the FAQ.
> >
> > Michael
> > >
> > > Tinny
> > >
> > > Michael Huedepohl wrote:
> > >
> > > > Tinny Ng wrote:
> > > > >
> > > > > Michael,
> > > > >
> > > > > Just checked the mail archive, and I think you have submitted two patches.
> > > > > One on Sept 27, and one on Oct 1 ....
> > > >
> > > > The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> > > > The second patch included a patch from Max Gotlib for the Iconv transcoder,
> > > > in addition. Both are based on Xerces 1.5.1 release.
> > > >
> > > > > To avoid grepping the wrong patch, can you zip all your patches (better use
> > > > > the latest code base) and resend the zip file again? Thanks!!
> > > >
> > > > I tried to use the nightly build from yesterday
> > > > (xml-xerces_20011128111840.tar.gz)
> > > > for forming a new patch, but this version produced compilation errors with gcc
> > > > (see below). I checked it on Solaris with the original sources, and got the
> > > > same errors - so it's independent from the FreeBSD port.
> > > >
> > > > >
> > > > > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > > > > Normally this should coded in those compiler specific header
> > > > > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > > > > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > > > > IconvTransService.cpp directly.
> > > >
> > > > I understand your intention, but I'm afraid this will be hard or impossible,
> > > > because my ICU version uses the original XMLCh definition, and only the IConv
> > > > version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> > > > take
> > > > place in IconvTransService.cpp where also some FreeBSD replacements for the
> > > > wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> > > > not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> > > > <wchar.h> and <wctype.h>.
> > > >
> > > > So, what do you think - can you use my patch from Sept 27 and merge the
> > > > changes and bug fixes which appeared after 1.5.1 into it, or would you
> > > > like to get a new patch based on the nightly build although I cannot test it
> > > > because of the compilation errors caused by some other bug?
> > > > And in the latter case, do you prefer the ICU-only port without OS specific
> > > > changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> > > > compromise in code structure?
> > > >
> > > > Here are the compiler messages:
> > > >
> > > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> > > > XMLAbstractDoubleFloat.cpp
> > > > In file included from XMLAbstractDoubleFloat.cpp:72:
> > > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > > declaration `operator =' with no type
> > > > gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> > > > gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
> > > >
> > > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> > > > DatatypeValidatorFactory.cpp
> > > > In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> > > > from
> > > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > > from DatatypeValidatorFactory.cpp:165:
> > > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > > declaration `operator =' with no type
> > > > In file included from
> > > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > > from DatatypeValidatorFactory.cpp:165:
> > > > /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> > > > `operator =' with no type
> > > > In file included from
> > > > /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> > > > from DatatypeValidatorFactory.cpp:166:
> > > > /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> > > > `operator =' with no type
> > > > gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> > > > gmake[2]: Leaving directory
> > > > `/home/michael/xerces_20011128111840/src/validators/datatype'
> > > >
> > > > Regards, Michael
> > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Tinny
> > > > >
> > > > > Michael Huedepohl wrote:
> > > > >
> > > > > > Is it possible to integrate the FreeBSD support supplied by me
> > > > > > some weeks ago?
> > > > > >
> > > > > > --
> > > > > > Michael Huedepohl, Mozquito Technologies
> > > > > >
> > > > > > Tinny Ng wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > We've finished most of the schema features, and are now in testing and
> > > > > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > > > > you have any urgent fix or important code wanna to get in, please do so.
> > > > > > >
> > > > > > > Feel free to play with the latest nightly build
> > > > > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > > > > >
> > > > > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > > > > should be sometime early December.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Tinny Ng
> > > > > > > XML Parsers Development
> > > > > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FreeBsd Patch (was Re: Plan for Xerces-C++ 1.6)
Posted by Tinny Ng <tn...@ca.ibm.com>.
Michael,
Your patch is now in. If FreeBSD 4.4 may fix the problem, I will leave Iconv as is and
update FAQ. Thanks for you input.
Tinny
Michael Huedepohl wrote:
> Tinny Ng wrote:
> >
> > Michael,
> >
> > The compilation error should have been fixed by Pei Yong yesterday, and I have just
> > posted the newer version of latest nightly build
> > (http://xml.apache.org/dist/xerces-c/nightly/2001-11-29/). Please try again.
>
> Well, our emails just crossed each other at the same time.
> Indeed, this problem is done.
> >
> > Regarding the patch, to make my life easier, it is appreciated if you can use the
> > latest code base.
>
> Well, I've done this meanwhile, as written in the last message.
> >
> > And about the IconvTransService.cpp changes, just #define wint_t XMLCh in
> > IconvTransService.cpp, but not in the header, will that lead to any link error?? I
>
> It IS in IconvTransService.cpp, has never been in the header!
> There's no change at all from my side to IconvTransService.hpp!
>
> > would prefer an ICU-only port patch with FAQ updated for Iconv problem to avoid OS
> > specific changes in IconvTransService.cpp. Or may be you can do something similar
> > to 390 (Iconv390TransService) and 400 (Iconv400TransService) => create a FreeBsd
> > specific Iconv service. This approach also sounds better.
>
> Unfortunately, for the rest of the year I'm very short on time,
> so I think it's not realistic to make this change now.
> I think it would be annoying not to have Iconv, but I leave it up to you
> just to omit the IconvTransService.cpp changes and add some words to the FAQ.
>
> Michael
> >
> > Tinny
> >
> > Michael Huedepohl wrote:
> >
> > > Tinny Ng wrote:
> > > >
> > > > Michael,
> > > >
> > > > Just checked the mail archive, and I think you have submitted two patches.
> > > > One on Sept 27, and one on Oct 1 ....
> > >
> > > The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> > > The second patch included a patch from Max Gotlib for the Iconv transcoder,
> > > in addition. Both are based on Xerces 1.5.1 release.
> > >
> > > > To avoid grepping the wrong patch, can you zip all your patches (better use
> > > > the latest code base) and resend the zip file again? Thanks!!
> > >
> > > I tried to use the nightly build from yesterday
> > > (xml-xerces_20011128111840.tar.gz)
> > > for forming a new patch, but this version produced compilation errors with gcc
> > > (see below). I checked it on Solaris with the original sources, and got the
> > > same errors - so it's independent from the FreeBSD port.
> > >
> > > >
> > > > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > > > Normally this should coded in those compiler specific header
> > > > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > > > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > > > IconvTransService.cpp directly.
> > >
> > > I understand your intention, but I'm afraid this will be hard or impossible,
> > > because my ICU version uses the original XMLCh definition, and only the IConv
> > > version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> > > take
> > > place in IconvTransService.cpp where also some FreeBSD replacements for the
> > > wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> > > not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> > > <wchar.h> and <wctype.h>.
> > >
> > > So, what do you think - can you use my patch from Sept 27 and merge the
> > > changes and bug fixes which appeared after 1.5.1 into it, or would you
> > > like to get a new patch based on the nightly build although I cannot test it
> > > because of the compilation errors caused by some other bug?
> > > And in the latter case, do you prefer the ICU-only port without OS specific
> > > changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> > > compromise in code structure?
> > >
> > > Here are the compiler messages:
> > >
> > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> > > XMLAbstractDoubleFloat.cpp
> > > In file included from XMLAbstractDoubleFloat.cpp:72:
> > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > declaration `operator =' with no type
> > > gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> > > gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
> > >
> > > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> > > DatatypeValidatorFactory.cpp
> > > In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> > > from
> > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > from DatatypeValidatorFactory.cpp:165:
> > > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > > declaration `operator =' with no type
> > > In file included from
> > > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > > from DatatypeValidatorFactory.cpp:165:
> > > /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> > > `operator =' with no type
> > > In file included from
> > > /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> > > from DatatypeValidatorFactory.cpp:166:
> > > /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> > > `operator =' with no type
> > > gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> > > gmake[2]: Leaving directory
> > > `/home/michael/xerces_20011128111840/src/validators/datatype'
> > >
> > > Regards, Michael
> > >
> > > >
> > > > Thanks!
> > > >
> > > > Tinny
> > > >
> > > > Michael Huedepohl wrote:
> > > >
> > > > > Is it possible to integrate the FreeBSD support supplied by me
> > > > > some weeks ago?
> > > > >
> > > > > --
> > > > > Michael Huedepohl, Mozquito Technologies
> > > > >
> > > > > Tinny Ng wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > We've finished most of the schema features, and are now in testing and
> > > > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > > > you have any urgent fix or important code wanna to get in, please do so.
> > > > > >
> > > > > > Feel free to play with the latest nightly build
> > > > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > > > >
> > > > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > > > should be sometime early December.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Tinny Ng
> > > > > > XML Parsers Development
> > > > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FreeBsd Patch (was Re: Plan for Xerces-C++ 1.6)
Posted by Michael Huedepohl <mi...@mozquito.com>.
Tinny Ng wrote:
>
> Michael,
>
> The compilation error should have been fixed by Pei Yong yesterday, and I have just
> posted the newer version of latest nightly build
> (http://xml.apache.org/dist/xerces-c/nightly/2001-11-29/). Please try again.
Well, our emails just crossed each other at the same time.
Indeed, this problem is done.
>
> Regarding the patch, to make my life easier, it is appreciated if you can use the
> latest code base.
Well, I've done this meanwhile, as written in the last message.
>
> And about the IconvTransService.cpp changes, just #define wint_t XMLCh in
> IconvTransService.cpp, but not in the header, will that lead to any link error?? I
It IS in IconvTransService.cpp, has never been in the header!
There's no change at all from my side to IconvTransService.hpp!
> would prefer an ICU-only port patch with FAQ updated for Iconv problem to avoid OS
> specific changes in IconvTransService.cpp. Or may be you can do something similar
> to 390 (Iconv390TransService) and 400 (Iconv400TransService) => create a FreeBsd
> specific Iconv service. This approach also sounds better.
Unfortunately, for the rest of the year I'm very short on time,
so I think it's not realistic to make this change now.
I think it would be annoying not to have Iconv, but I leave it up to you
just to omit the IconvTransService.cpp changes and add some words to the FAQ.
Michael
>
> Tinny
>
> Michael Huedepohl wrote:
>
> > Tinny Ng wrote:
> > >
> > > Michael,
> > >
> > > Just checked the mail archive, and I think you have submitted two patches.
> > > One on Sept 27, and one on Oct 1 ....
> >
> > The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> > The second patch included a patch from Max Gotlib for the Iconv transcoder,
> > in addition. Both are based on Xerces 1.5.1 release.
> >
> > > To avoid grepping the wrong patch, can you zip all your patches (better use
> > > the latest code base) and resend the zip file again? Thanks!!
> >
> > I tried to use the nightly build from yesterday
> > (xml-xerces_20011128111840.tar.gz)
> > for forming a new patch, but this version produced compilation errors with gcc
> > (see below). I checked it on Solaris with the original sources, and got the
> > same errors - so it's independent from the FreeBSD port.
> >
> > >
> > > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > > Normally this should coded in those compiler specific header
> > > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > > IconvTransService.cpp directly.
> >
> > I understand your intention, but I'm afraid this will be hard or impossible,
> > because my ICU version uses the original XMLCh definition, and only the IConv
> > version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> > take
> > place in IconvTransService.cpp where also some FreeBSD replacements for the
> > wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> > not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> > <wchar.h> and <wctype.h>.
> >
> > So, what do you think - can you use my patch from Sept 27 and merge the
> > changes and bug fixes which appeared after 1.5.1 into it, or would you
> > like to get a new patch based on the nightly build although I cannot test it
> > because of the compilation errors caused by some other bug?
> > And in the latter case, do you prefer the ICU-only port without OS specific
> > changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> > compromise in code structure?
> >
> > Here are the compiler messages:
> >
> > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> > XMLAbstractDoubleFloat.cpp
> > In file included from XMLAbstractDoubleFloat.cpp:72:
> > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > declaration `operator =' with no type
> > gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> > gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
> >
> > g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> > -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> > -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> > -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> > DatatypeValidatorFactory.cpp
> > In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> > from
> > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > from DatatypeValidatorFactory.cpp:165:
> > /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> > declaration `operator =' with no type
> > In file included from
> > /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> > from DatatypeValidatorFactory.cpp:165:
> > /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> > `operator =' with no type
> > In file included from
> > /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> > from DatatypeValidatorFactory.cpp:166:
> > /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> > `operator =' with no type
> > gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> > gmake[2]: Leaving directory
> > `/home/michael/xerces_20011128111840/src/validators/datatype'
> >
> > Regards, Michael
> >
> > >
> > > Thanks!
> > >
> > > Tinny
> > >
> > > Michael Huedepohl wrote:
> > >
> > > > Is it possible to integrate the FreeBSD support supplied by me
> > > > some weeks ago?
> > > >
> > > > --
> > > > Michael Huedepohl, Mozquito Technologies
> > > >
> > > > Tinny Ng wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > We've finished most of the schema features, and are now in testing and
> > > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > > you have any urgent fix or important code wanna to get in, please do so.
> > > > >
> > > > > Feel free to play with the latest nightly build
> > > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > > >
> > > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > > should be sometime early December.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tinny Ng
> > > > > XML Parsers Development
> > > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
FreeBsd Patch (was Re: Plan for Xerces-C++ 1.6)
Posted by Tinny Ng <tn...@ca.ibm.com>.
Michael,
The compilation error should have been fixed by Pei Yong yesterday, and I have just
posted the newer version of latest nightly build
(http://xml.apache.org/dist/xerces-c/nightly/2001-11-29/). Please try again.
Regarding the patch, to make my life easier, it is appreciated if you can use the
latest code base.
And about the IconvTransService.cpp changes, just #define wint_t XMLCh in
IconvTransService.cpp, but not in the header, will that lead to any link error?? I
would prefer an ICU-only port patch with FAQ updated for Iconv problem to avoid OS
specific changes in IconvTransService.cpp. Or may be you can do something similar
to 390 (Iconv390TransService) and 400 (Iconv400TransService) => create a FreeBsd
specific Iconv service. This approach also sounds better.
Tinny
Michael Huedepohl wrote:
> Tinny Ng wrote:
> >
> > Michael,
> >
> > Just checked the mail archive, and I think you have submitted two patches.
> > One on Sept 27, and one on Oct 1 ....
>
> The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> The second patch included a patch from Max Gotlib for the Iconv transcoder,
> in addition. Both are based on Xerces 1.5.1 release.
>
> > To avoid grepping the wrong patch, can you zip all your patches (better use
> > the latest code base) and resend the zip file again? Thanks!!
>
> I tried to use the nightly build from yesterday
> (xml-xerces_20011128111840.tar.gz)
> for forming a new patch, but this version produced compilation errors with gcc
> (see below). I checked it on Solaris with the original sources, and got the
> same errors - so it's independent from the FreeBSD port.
>
> >
> > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > Normally this should coded in those compiler specific header
> > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > IconvTransService.cpp directly.
>
> I understand your intention, but I'm afraid this will be hard or impossible,
> because my ICU version uses the original XMLCh definition, and only the IConv
> version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> take
> place in IconvTransService.cpp where also some FreeBSD replacements for the
> wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> <wchar.h> and <wctype.h>.
>
> So, what do you think - can you use my patch from Sept 27 and merge the
> changes and bug fixes which appeared after 1.5.1 into it, or would you
> like to get a new patch based on the nightly build although I cannot test it
> because of the compilation errors caused by some other bug?
> And in the latter case, do you prefer the ICU-only port without OS specific
> changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> compromise in code structure?
>
> Here are the compiler messages:
>
> g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> XMLAbstractDoubleFloat.cpp
> In file included from XMLAbstractDoubleFloat.cpp:72:
> /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> declaration `operator =' with no type
> gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
>
> g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> DatatypeValidatorFactory.cpp
> In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> from
> /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> from DatatypeValidatorFactory.cpp:165:
> /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> declaration `operator =' with no type
> In file included from
> /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> from DatatypeValidatorFactory.cpp:165:
> /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> `operator =' with no type
> In file included from
> /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> from DatatypeValidatorFactory.cpp:166:
> /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> `operator =' with no type
> gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> gmake[2]: Leaving directory
> `/home/michael/xerces_20011128111840/src/validators/datatype'
>
> Regards, Michael
>
> >
> > Thanks!
> >
> > Tinny
> >
> > Michael Huedepohl wrote:
> >
> > > Is it possible to integrate the FreeBSD support supplied by me
> > > some weeks ago?
> > >
> > > --
> > > Michael Huedepohl, Mozquito Technologies
> > >
> > > Tinny Ng wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We've finished most of the schema features, and are now in testing and
> > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > you have any urgent fix or important code wanna to get in, please do so.
> > > >
> > > > Feel free to play with the latest nightly build
> > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > >
> > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > should be sometime early December.
> > > >
> > > > Thanks!
> > > >
> > > > Regards,
> > > >
> > > > Tinny Ng
> > > > XML Parsers Development
> > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6 / FreeBSD port
Posted by Michael Huedepohl <mi...@mozquito.com>.
Hi Tiny,
let me answer a second time to your email from Nov 23,
because things have changed meanwhile.
First of all, I found that the compilation bug from the
nightly build has been fixed, as I've seen from the CVS Web
interface. I replaced the three files
src/util/XMLAbstractDoubleFloat.hpp
src/util/XMLDouble.hpp
src/util/XMLFloat.hpp
with the new versions, and now everything went perfectly.
In addition to my first patch for FreeBSD, I also ported the
examples, and they all work well.
I compared all the files which I modified for the FreeBSD port
with the version numbers and dates from the CVS Web interface
and confirmed that they are all up-to-date now.
Since you prefer a zip file instead of a patch script, I've
created a zip file containing the modified files and the new
FreeBSD platform specific files, of course in the corresponding
directories.
With this port, you can configure on FreeBSD with ICU transcoder
(-t icu) or with the native transcoder (Iconv, default).
The Iconv part has been written originally by Max Gotlib and
slightly corrected by me. It's ONLY contained in the file
IconvTransService.cpp, so you can decide for yourself to add
this modification or to omit the changes in IconvTransService.cpp
If you omit it, the configure with native transcoder will fail
at least on FreeBSD up to version 4.3 because
- wchar.h and wctype.h don't exist
- towupper doesn't exist
- wcstombs and mbstowcs are not conforming to the standard
(NULL pointer argument for array length computation doesn't work)
Development goes on and at least the header files seem to be
available in FreeBSD 4.4, but I'm not sure if the rest is also OK.
So the Iconv port would still be helpful, but with the drawback
of having platform specific code in IconvTransService.cpp.
I don't see an easy way of moving this code elsewhere.
But XMLCh is not redefined as you complained - only wint_t
(which is also undefined on FreeBSD) is defined here to be XMLCh,
which is quite conforming to the definition in XXXDefs.hpp.
Hope you can integrate/commit it now.
Cheers, Michael
Michael Huedepohl wrote:
>
> Tinny Ng wrote:
> >
> > Michael,
> >
> > Just checked the mail archive, and I think you have submitted two patches.
> > One on Sept 27, and one on Oct 1 ....
>
> The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
> The second patch included a patch from Max Gotlib for the Iconv transcoder,
> in addition. Both are based on Xerces 1.5.1 release.
>
> > To avoid grepping the wrong patch, can you zip all your patches (better use
> > the latest code base) and resend the zip file again? Thanks!!
>
> I tried to use the nightly build from yesterday
> (xml-xerces_20011128111840.tar.gz)
> for forming a new patch, but this version produced compilation errors with gcc
> (see below). I checked it on Solaris with the original sources, and got the
> same errors - so it's independent from the FreeBSD port.
>
> >
> > BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> > Normally this should coded in those compiler specific header
> > src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> > specific changes in src/util/Compilers/XXXDefs.hpp instead of
> > IconvTransService.cpp directly.
>
> I understand your intention, but I'm afraid this will be hard or impossible,
> because my ICU version uses the original XMLCh definition, and only the IConv
> version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
> take
> place in IconvTransService.cpp where also some FreeBSD replacements for the
> wcstombs, mbstowcs, and towupper functions are supplied. These functions are
> not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
> <wchar.h> and <wctype.h>.
>
> So, what do you think - can you use my patch from Sept 27 and merge the
> changes and bug fixes which appeared after 1.5.1 into it, or would you
> like to get a new patch based on the nightly build although I cannot test it
> because of the compilation errors caused by some other bug?
> And in the latter case, do you prefer the ICU-only port without OS specific
> changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
> compromise in code structure?
>
> Here are the compiler messages:
>
> g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
> XMLAbstractDoubleFloat.cpp
> In file included from XMLAbstractDoubleFloat.cpp:72:
> /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> declaration `operator =' with no type
> gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
> gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
>
> g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
> -I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
> -D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
> -I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
> DatatypeValidatorFactory.cpp
> In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
> from
> /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> from DatatypeValidatorFactory.cpp:165:
> /xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
> declaration `operator =' with no type
> In file included from
> /xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
> from DatatypeValidatorFactory.cpp:165:
> /xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
> `operator =' with no type
> In file included from
> /xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
> from DatatypeValidatorFactory.cpp:166:
> /xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
> `operator =' with no type
> gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
> gmake[2]: Leaving directory
> `/home/michael/xerces_20011128111840/src/validators/datatype'
>
> Regards, Michael
>
> >
> > Thanks!
> >
> > Tinny
> >
> > Michael Huedepohl wrote:
> >
> > > Is it possible to integrate the FreeBSD support supplied by me
> > > some weeks ago?
> > >
> > > --
> > > Michael Huedepohl, Mozquito Technologies
> > >
> > > Tinny Ng wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We've finished most of the schema features, and are now in testing and
> > > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > > you have any urgent fix or important code wanna to get in, please do so.
> > > >
> > > > Feel free to play with the latest nightly build
> > > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > > >
> > > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > > should be sometime early December.
> > > >
> > > > Thanks!
> > > >
> > > > Regards,
> > > >
> > > > Tinny Ng
> > > > XML Parsers Development
> > > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
Re: Plan for Xerces-C++ 1.6
Posted by Michael Huedepohl <mi...@mozquito.com>.
Tinny Ng wrote:
>
> Michael,
>
> Just checked the mail archive, and I think you have submitted two patches.
> One on Sept 27, and one on Oct 1 ....
The one of Sept 27 is sufficient. This port uses (and needs) the ICU transcoder.
The second patch included a patch from Max Gotlib for the Iconv transcoder,
in addition. Both are based on Xerces 1.5.1 release.
> To avoid grepping the wrong patch, can you zip all your patches (better use
> the latest code base) and resend the zip file again? Thanks!!
I tried to use the nightly build from yesterday
(xml-xerces_20011128111840.tar.gz)
for forming a new patch, but this version produced compilation errors with gcc
(see below). I checked it on Solaris with the original sources, and got the
same errors - so it's independent from the FreeBSD port.
>
> BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
> Normally this should coded in those compiler specific header
> src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
> specific changes in src/util/Compilers/XXXDefs.hpp instead of
> IconvTransService.cpp directly.
I understand your intention, but I'm afraid this will be hard or impossible,
because my ICU version uses the original XMLCh definition, and only the IConv
version (from Max Gotlib) redefines XMLCh - I'm afraid this distinction must
take
place in IconvTransService.cpp where also some FreeBSD replacements for the
wcstombs, mbstowcs, and towupper functions are supplied. These functions are
not implemented in the FreeBSD 4.3 Standard C library, as well as the headers
<wchar.h> and <wctype.h>.
So, what do you think - can you use my patch from Sept 27 and merge the
changes and bug fixes which appeared after 1.5.1 into it, or would you
like to get a new patch based on the nightly build although I cannot test it
because of the compilation errors caused by some other bug?
And in the latter case, do you prefer the ICU-only port without OS specific
changes in IconvTransService.cpp, or the combined ICU+Iconv port with some
compromise in code structure?
Here are the compiler messages:
g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
-I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
-D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
-I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/XMLAbstractDoubleFloat.o
XMLAbstractDoubleFloat.cpp
In file included from XMLAbstractDoubleFloat.cpp:72:
/xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
declaration `operator =' with no type
gmake[1]: *** [XMLAbstractDoubleFloat.o] Error 1
gmake[1]: Leaving directory `/home/michael/xerces_20011128111840/src/util'
g++ -fPIC -DFREEBSD -I/usr/local/include -c -O -DXML_USE_ICU_TRANSCODER
-I/usr/local/lib/icu/current/include -DXML_USE_INMEM_MESSAGELOADER
-D_THREAD_SAFE -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET
-I/xml-xerces/include -o /xml-xerces/obj/FREEBSD/DatatypeValidatorFactory.o
DatatypeValidatorFactory.cpp
In file included from /xml-xerces/include/util/XMLDouble.hpp:92,
from
/xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
from DatatypeValidatorFactory.cpp:165:
/xml-xerces/include/util/XMLAbstractDoubleFloat.hpp:167: ANSI C++ forbids
declaration `operator =' with no type
In file included from
/xml-xerces/include/validators/datatype/DoubleDatatypeValidator.hpp:84,
from DatatypeValidatorFactory.cpp:165:
/xml-xerces/include/util/XMLDouble.hpp:143: ANSI C++ forbids declaration
`operator =' with no type
In file included from
/xml-xerces/include/validators/datatype/FloatDatatypeValidator.hpp:85,
from DatatypeValidatorFactory.cpp:166:
/xml-xerces/include/util/XMLFloat.hpp:138: ANSI C++ forbids declaration
`operator =' with no type
gmake[2]: *** [DatatypeValidatorFactory.o] Error 1
gmake[2]: Leaving directory
`/home/michael/xerces_20011128111840/src/validators/datatype'
Regards, Michael
>
> Thanks!
>
> Tinny
>
> Michael Huedepohl wrote:
>
> > Is it possible to integrate the FreeBSD support supplied by me
> > some weeks ago?
> >
> > --
> > Michael Huedepohl, Mozquito Technologies
> >
> > Tinny Ng wrote:
> > >
> > > Hi all,
> > >
> > > We've finished most of the schema features, and are now in testing and
> > > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > > you have any urgent fix or important code wanna to get in, please do so.
> > >
> > > Feel free to play with the latest nightly build
> > > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> > >
> > > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > > should be sometime early December.
> > >
> > > Thanks!
> > >
> > > Regards,
> > >
> > > Tinny Ng
> > > XML Parsers Development
> > > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Tinny Ng <tn...@ca.ibm.com>.
Michael,
Just checked the mail archive, and I think you have submitted two patches.
One on Sept 27, and one on Oct 1 ....
To avoid grepping the wrong patch, can you zip all your patches (better use
the latest code base) and resend the zip file again? Thanks!!
BTW I notice your patch in IconvTransService.cpp redefine XMLCh for FreeBSD.
Normally this should coded in those compiler specific header
src/util/Compilers/XXXDefs.hpp. Please see if you can localize your FreeBSD
specific changes in src/util/Compilers/XXXDefs.hpp instead of
IconvTransService.cpp directly.
Thanks!
Tinny
Michael Huedepohl wrote:
> Is it possible to integrate the FreeBSD support supplied by me
> some weeks ago?
>
> --
> Michael Huedepohl, Mozquito Technologies
>
> Tinny Ng wrote:
> >
> > Hi all,
> >
> > We've finished most of the schema features, and are now in testing and
> > wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> > you have any urgent fix or important code wanna to get in, please do so.
> >
> > Feel free to play with the latest nightly build
> > (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> > and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
> >
> > Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> > should be sometime early December.
> >
> > Thanks!
> >
> > Regards,
> >
> > Tinny Ng
> > XML Parsers Development
> > IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Plan for Xerces-C++ 1.6
Posted by Michael Huedepohl <mi...@mozquito.com>.
Is it possible to integrate the FreeBSD support supplied by me
some weeks ago?
--
Michael Huedepohl, Mozquito Technologies
Tinny Ng wrote:
>
> Hi all,
>
> We've finished most of the schema features, and are now in testing and
> wrapping up mode. So I think it's time to call for Xerces-C++ 1.6. If
> you have any urgent fix or important code wanna to get in, please do so.
>
> Feel free to play with the latest nightly build
> (http://xml.apache.org/dist/xerces-c/nightly/), and let us know any bugs
> and leaks found so that we can fix them before releasing Xerces-C++ 1.6.
>
> Unless we hear any on-hold request, the target date for Xerces-C++ 1.6
> should be sometime early December.
>
> Thanks!
>
> Regards,
>
> Tinny Ng
> XML Parsers Development
> IBM Toronto Laboratory, email: tng-xml@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org