Re: Migration to Git

2019-05-15 Thread Boris Kolpackov
Cantor, Scott  writes:

> On 5/13/19, 9:23 AM, "Boris Kolpackov"  wrote:
> 
> > I also think we can drop any mentinoning of 2-series during this
> > conversion. There are, however, other bits of the documentation
> > (like Doxygen-generated). Here is step #15 that I mentioned:
> 
> That's not in the current readme [...].

I think I now understand what's going on: the xerces/c/web/ repository
is no longer used at all. Instead, it's all (including the generated
Doxygen documentation) in xerces/site/trunk/production/xerces-c/.

I think it then makes sense to omit web from conversion to Git.

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Migration to Git

2019-05-13 Thread Boris Kolpackov
Roger Leigh  writes:

> Mentioned briefly a few months back, but we could take the Git migration as
> an opportunity to convert the old StyleBook XML to Markdown and move the
> docs to github pages, generated directly from git automatically.

I assume the "github pages" part is acceptable to Apache due to the
recent announcement?


> I would certainly be happy to do the conversion, if there was consensus for
> doing so.

Yes, please. I doubt anyone will object but I think we will need a
vote to be compliant with the Apache way.

I also think we can drop any mentinoning of 2-series during this
conversion. There are, however, other bits of the documentation
(like Doxygen-generated). Here is step #15 that I mentioned:

15. Update the website by taking a binary package and extracting the 
doc/html directories. The web pages are stored in 
/www/xml.apache.org/xerces-c. You will also need to update the
documentation pdf in the pdf directory (which has both a pdf and
pdf.tar.gz). Recommend copying the new documentation over the
existing files. Be sure to change the permissions on the files
and directories:

find . -type f -exec chmod 664 {} ;
find . -type d -exec chmod 775 {} ;

If the binaries are for different platforms you may also need to 
update the download.html file to point to the new binaries.
Verify that the website is updated (may take a while to be 
refreshed on the real webserver).


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Migration to Git

2019-05-10 Thread Boris Kolpackov
Cantor, Scott  writes:

> On 4/29/19, 10:34 AM, "Boris Kolpackov"  wrote:
> 
> > The latter two are direct copies from the web/ and admin/ SVN directories.
> 
> I believe that the web/ repository is actually directly published as
> the web site, so there probably is additional work to do to change
> how that's happening. I don't know the details of how it works, that
> step to commit to svn was as far as I ever made it.

Hm, looking at admin/release-procedure.txt, step 15 in particular,
suggest that it's at least not the whole process.

In any case, I suggest that we convert it to Git now and decide
what extra steps, if any, are required later.


> > I think we should try to migrate the release tags (the ones
> > in the Xerces-C_X_Y_Z form). I also wouldn't mind converting
> > them to the now well-established vX.Y.Z form.
> 
> I would cast a mild vote of preference for just using X.Y.Z for
> the tag names rather than embellishing them at all with any other
> characters, but otherwise +1

I have two reasons to prefer vX.Y.Z over just X.Y.Z:

1. This is the convention that is promoted (and sometimes
   required, like in Go) in modern languages and package
   manager. As a result, it is well recognized by tooling
   (e.g., GitHub will automatically recognize a tag like
   this as a release).

2. We may want to use X, X.Y, or X.Y.Z for release-series
   branches. We currently call such branches as xerces-X.Y
   but if you think about it, this 'xerces-' prefix is
   tautological (we are already in the xerces-c repository).

So, to summarize, vX.Y.Z has potential benefits without any
drawbacks that I can think of. So why not?

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Migration to Git

2019-05-10 Thread Boris Kolpackov
Roger Leigh  writes:

> > xerces-cxx.git
> > xerces-cxx-web.git
> > xerces-cxx-admin.git
> 
> Do we need "-cxx" as a suffix here, or would "-c" be better?

Yes, good point. Our source distributions are called xerces-c, binary
packages seem to also be called like that (e.g., Debian's, libxerces-c).
So, yes, let's make it xerces-c.git, etc.

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Migration to Git

2019-04-29 Thread Boris Kolpackov
The vote to migrate the Xerces-C++ repository from SVN to Git has
passed and I would like to discuss the next step.

According to https://gitbox.apache.org, this should be as easy
as opening and issue with the Apache Infra. Before doing this,
however, it would be good to agree on the desired repositories
and their structure.

I've browsed through some of the existing project on Gitbox
looking for established practices:

https://gitbox.apache.org/repos/asf

As well as through the Xerces-C++ SVN repository to see what
we've got:

http://svn.apache.org/viewvc/xerces/c/?root=Apache-SVN

Based on that I would suggest that we have the following
repositories:

xerces-cxx.git
xerces-cxx-web.git
xerces-cxx-admin.git

The latter two are direct copies from the web/ and admin/ SVN
directories.

For the first repository I propose the following straightforward
mapping:

heads/master  <-  trunk
heads/xerces-2<-  branches/xerces-2
heads/xerces-2.8  <-  branches/xerces-2.8
heads/xerces-3.0  <-  branches/xerces-3.0
heads/xerces-3.1  <-  branches/xerces-3.1

I think we should try to migrate the release tags (the ones
in the Xerces-C_X_Y_Z form). I also wouldn't mind converting
them to the now well-established vX.Y.Z form.

Roger and everyone else, does this sound reasonable/doable?

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Call for vote on migrating Xerces-C++ repositories to Git

2019-04-29 Thread Boris Kolpackov
Boris Kolpackov  writes:

> I would like to call for a vote to migrate Xerces-C++ SVN repositories
> to Git, specifically, to the Apache Gitbox service:
> 
> https://gitbox.apache.org/

The vote passes with 7 in favor and 0 against.

Shortly I am going to send an email to c-dev with the proposed
next steps.

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Call for vote on migrating Xerces-C++ repositories to Git

2019-04-22 Thread Boris Kolpackov
I would like to call for a vote to migrate Xerces-C++ SVN repositories
to Git, specifically, to the Apache Gitbox service:

https://gitbox.apache.org/

This is my +1.

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Git source repository

2019-04-20 Thread Boris Kolpackov
Roger Leigh  writes:

> With the reboot of the Xalan PMC, the Xalan SVN repositories are currently
> being converted to Gitbox.

For those unaware, Gitbox is the Apache's Git service with writable
mirroring on GitHub:

https://gitbox.apache.org/


> Would it please be possible to do this for the Xerces repositories as well?
> I would be happy to assist with it.

Yes, that would be nice (and sorry for letting this slide after
bringing it up a few weeks ago).

I think before we can pull the trigger, we should have a formal
vote (even though there were no objections during the last
discussion).

Do you want to start it or I can do it?

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Support for build2, migration to git, etc

2019-03-25 Thread Boris Kolpackov
Cantor, Scott  writes:

> Practically speaking, the security process and the web site have been the
> main sources of friction for me, and I think the latter is definitely a
> choice. We could simply accept that it's not viable and shut it down in
> favor of a simple wiki page with the download links, etc.

Agree.


> Apache's security process is definitely a source of problems for me, it
> demands too much effort and is one of the reasons I tend to look for reasons
> not to do them. I don't believe in doing the work of downstream packagers as
> a precondition for doing fixes, and their process leans too far in that
> direction.

Ok, didn't know that.


> I just believe in transparency so everybody knows the situation.

Yes, I agree we should make it clear if/when things are insecure.
And I think it is also perfectly reasonable to switch to "disabled
by default" for functionality (such as DTD) which has known security
issues but which we cannot fix (for whatever reasons).


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Support for build2, migration to git, etc

2019-03-25 Thread Boris Kolpackov
Roger Leigh  writes:

> I'm doing all my work in git using the git mirror anyway,, so I would be
> more than happy to use git for the main repository.  It's much more
> efficient.

Great!


> Regarding build2, are there sufficient benefits over the existing autotools
> and cmake build to make it worth the cost for supporting three build
> systems?

Continuous CI would be the major benefit. And I am committing to absorbing
the costs by maintaining it (also see below).


> Maintaining two with exact feature parity and behaviours is already a
> maintenance burden.  I think three is too many, and would recommend we
> drop one if we are going to support a new one.  And I think that would
> have to be the autotools build.

I would prefer not to make support for build2 conditional on dropping
support for autotools (but we can vote on this separately if you would
like). As I mentioned above, we are prepared to do all the maintenance.
In fact, bared some major restructuring, I don't expect there to be any.
In particular, addition/removal/renaming of source code will be picked
up automatically. Upon release, the version will need to be changed in
one place but I am prepared to handle that as well.


> Regarding the CI side, can it integrate with Apache's github repo like we
> have already for Travis and AppVeyor?

build2 CI is a bit different in that it is "push" rather than "pull".
That is, you normally develop something in a branch, then CI it, if
all looks good, merge to master and then maybe CI master, for good
measure.

This is not to say that we can't also trigger it from a post-commit
hook or some such.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Support for build2, migration to git, etc

2019-03-24 Thread Boris Kolpackov
Cantor, Scott  writes:

> No concerns with git, if that's something Apache allows as the
> "official" repo now [...]

I would sure hope so.


> My only concern with the build system is that I need the autoconf
> support so as long as that's not going anywhere, anything else is
> up to the people offering to maintain it.

Yes, it will be purely additive and I am committing to maintaining
it.


> FWIW, GitHub's terms of use are impossible for me to accept for
> any active development work due to their indemnification clause.

I used GitHub as an example. I am happy with any similar service
(e.g., GitLab).


> If I were to fork, it would only be in the interest of ensuring that
> nobody else used the code under the impression it were being maintained
> for general use, and to ensure that the library naming wouldn't conflict
> with any other packaging.

Well, my motivation for forking would be to continue maintaining the
project for general use but with less "friction".

I also think you are over-burdening yourself with responsibility:
yes, security issues are bad news but in the end the license clearly
states that things come as-is and without any warranty.


> But fundamentally, the issue is viability.

We have a product (CodeSynthesis XSD) that depends on it so we are
planning to use and maintain it going forward. At the same time we
view it as a mature (if not legacy) codebase so we have no plans to
add any new features, etc. I am, however, not sure whether Apache is
interested in a project like this.

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Support for build2, migration to git, etc

2019-03-23 Thread Boris Kolpackov
I would like to add support for the build2[1] build system, similar
to how it was done recently for CMake. One of the benefits will be
continuous building and testing[2] on a wide range of platforms and
compilers[3] (currently 33). I am committing to maintaining this
support going forward.

Before doing this (and provided there is support in the first place,
of course), I would really like to migrate the project from svn to
git (hopefully with the help of Apache Infra). Last time this came
up, I don't believe there were any strong opposition to such a
switch.

I would like to put these two points to a vote but before doing so
I thought I would check what the sentiment is.

Finally, seeing that we are on the topic of migration and switching,
the question of the overall viability as the Apache project has come
up recently and some mentioned that they have considered forking the
project and hosting the fork in a less "structured" setting (e.g.,
GitHub). So maybe it makes sense to consider/discuss this possibility
as well (perhaps it could be a "move" rather than a fork if Apache is
no longer interested in the project).

What do you think?

[1] https://build2.org/
[2] https://ci.cppget.org/
[3] https://ci.cppget.org/?build-configs

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces-C 3.2.1 - call for vote

2018-02-26 Thread Boris Kolpackov
+1 & thanks for all the hard work!

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Can we assume C99?

2017-07-07 Thread Boris Kolpackov
Cantor, Scott  writes:

> I don't know what the baseline has been for the code base, is C99 a
> reasonable requirement?
> 
> I need SIZE_MAX to fix some bounds checking errors, just need to know
> if I need to waste time on an autoconf test for it.

My experience has been that supporting a standard (like C99 or C++98)
is pretty pointless, especially for things like C++11 and beyond: most
compilers these days only support a subset of their features. Your case
is a good example: VC is not C99-compliant but has SIZE_MAX. When it
comes to C++, VC supports features from 14 and 17 while not being fully
C++11-compliant.

So what we found works much better is to define a set of compilers and
their versions that we support -- any feature supported by all of them
is fair play.

Perhaps we should do something like this for Xerces-C++, especially if
we plan to start migrating to C++11. In fact, this will be a great aid
to gradual migration since we can just start using new features if they
are available in all the supported compilers.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Integrating CMake support for xerces

2017-06-12 Thread Boris Kolpackov
Roger Leigh  writes:

> If we every wanted to drop the Autotools to only have one system to
> maintain, this would provide compatibility with a traditional
> configure/make/make install workflow.  I'm not suggesting doing this at this
> point in time, just wanted to mention the existence of this solution as a
> possibility for the future.

It would still require CMake to be installed, right? One of the main
advantages of autotools is all you need is a compiler (and make),
everything else is included.

I think if we drop autotools, then we drop them good, without hitching
ourselves to some half-solutions with questionable long-term prospects.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Status of trunk / main-3.3 comparison

2017-05-02 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott  writes:

> If anybody who knows the DOM impl could weigh in on what the heck that
> code in DOMCasts.hpp/cpp was doing and why, I'd welcome the perspective.

Yeah, infamous Xerces-C++ brain-death ;-)

Try to replace this (and if it works other similar) function with:

template 
static inline DOMNodeImpl*
castToNodeImpl(const T* p)
{   
  return >fNode;
}

There might still be some cases you you will have to cast the argument
to appropriate DOM*Impl type.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Call for vote

2016-06-24 Thread Boris Kolpackov
+1, Thanks Scott! Unfortunately couldn't find time to test.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Status of cleanup after release

2015-03-23 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I have one last TODO, which is to rewrite the admin/release-procedure
 file to reflect the actual process [...]

Yes, that would definitely be very helpful. I haven't done it myself
when I did the release which I regretted many, many times.

Thanks again for you work!

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: [VOTE] release of 3.1.2

2015-03-18 Thread Boris Kolpackov
+1

Thanks, Scott!

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I don't either, but to be blunt, the branch shouldn't be in the state it's 
 in if you think it needs that much testing, because if a security issue 
 pops up, you don't have the luxury of taking a lot of time.
 
 I completely understand your point about using the trunk, and I agree with 
 it. It's not worth the risk. But any fixes to the branch should be very 
 carefully looked at, in which case testing can be fairly pro-forma.

It is no so much the changes that I am worried about. It is the fact
that a lot of outside things (platforms, compilers, libraries, etc)
that Xerces-C++ depends on have changed a lot.

But, also, knowing what kind of a rotten mess Xerces-C++ code base
is, it is hard to know what even a trivial change will trip up.


 I am not going to add in project files for a compiler I can't test. That 
 flies in the face of the exact point you made above. If you think the 
 files on trunk work, we can add them.

Add them and I will test.


 As far as docs go, I obviously need specifics.

You will have to go through the website docs and figure what needs
updating. If something specific is unclear, ask and I will try to
help. But don't expect me to provide a step-by-step guide for you.
I unfortunately really don't have the time for that right now.


 Do you think I do have time?

I am not asking you to do anything.


 After about 2011-2012 or so, the branch simply died. Every fix was applied 
 to trunk only, even when it was minor.

Ok, I guess I missed that.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 It's been years, Boris. I think you're being very aggressive here with 
 somebody trying to help and able to do so only within the limits of his 
 own funding and project needs. That's how this stuff works. If you're 
 going to set requirements that I can't meet, then there's not much I can 
 say.

See it from my POV: I have a ton of users that are pretty happy with
3.1.1. Now comes Scott and wants to cut a half-tested release just
to satisfy his immediate needs. Once you do this I will start getting
emails from my users saying why doesn't my stuff (which depends on
Xerces-C++) works in this or that situation. I don't want that.



 I can't go back and review every commit you all have made. I can be very 
 careful with any commits *I* make, and I can test my use cases and allow a 
 bit of time beyond that. If you're asking me to wait months, no, I can't 
 do that. I have constraints too.

Nobody is talking about months. Here is what I suggest you do:

1. Prepare the release (with all the updates to docs, new projects,
   etc).
   
2. Publish it as a pre-release for, say, a week (i.e., announce on
   the lists).
   
3. I will test it to the best of my abilities (even though I have
   absolutely zero time for it right now) and report any problems
   (I will also review the changes for any ABI breakage).
   
4. If all looks good, you publish the release.

BTW, I am surprised you had to back-port so many bug fixes to the
3.1 branch. Normally anything that is backwards-compatible gets
committed to both head and 3.1. Are you sure you are using 3.1
and not, say, 3.1.1?

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 Correction, it's not an ABI change, the pool entry class isn't exported on 
 Windows...

What about other platforms?! If this class is defined in a public header
(i.e., a header that is installed) and the function is virtual, then this
is an ABI change.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I definitely don't have the cycles for a beta and it wouldn't fit my 
 timeline anway.

Then you shouldn't be making the release.


 I'm on VC10 for my builds, and I believe those are already there.

What about other users of Xerces-C++? When we publish a new release,
it is presumed that it will work on all commonly-used platforms and
compilers, not only what Scott Cantor needs.


 What's the bare minimum we can do once I have a tarball tested?

Bare minimum is to make sure 3.1.2 is as good quality as 3.1.1. I
don't think you are approaching it with the right attitude. If all
you need is a bug-fix that only has to work for your specific case,
then just provide a patch (or a patched version of Xerces-C++) to
your users.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I've reviewed all the resolved issues against the trunk, and backported 
 15-20 or so to the branch.
 
 Once I have access I'll commit.

Before you do this have someone review your back-ports to double
check there are no ABI breakages.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-16 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 FWIW, I've done very little testing of trunk other than building it,
 so I don't have a sense of how good a shape it's in or how much has
 changed.

Unless you are prepared to do a good amount of testing (I can help
somewhat but you will have to take the lead, e.g., package a beta,
announce it, etc, etc), I would strongly suggest that you do the
bug-fix release (i.e., 3.1.2). Simply back-port the fix that is
only on trunk (and maybe check if there are more fixes that haven't
been applied to the 3.1). Stillm packaging a beta is probably a
good idea. As is adding new VC++ project/solution files (i have
them in XSD but they use different DLL naming).

Also, I must warn you, Xerces-C++ release process is probably
the most brain-dead thing you will ever experience. There is
the admin/ repository with some outdated release information.
I will also try to answer questions if you have any (I've done
the last couple of releases).

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[ANN] CodeSynthesis XSD 4.0.0 released, adds support for C++11

2014-07-22 Thread Boris Kolpackov
Hi,

I am pleased to announce the release of CodeSynthesis XSD 4.0.0.

XSD is an open source, cross-platform W3C XML Schema to C++ data
binding compiler. Provided with a schema, it generates C++ classes
that represent the given vocabulary as well as XML parsing and
serialization code. You can then access the data stored in XML
using types and functions that semantically correspond to your
application domain rather than dealing with elements, attributes,
and text in a direct representation of XML such as DOM or SAX.

Major new features in this release:

  * Support for C++11 in addition to C++98.

  * Support for ordered types including mixed content.

  * Support for anyType and anySimpleType content extraction as
DOM and text, respectively.

  * Improved streaming, partially in-memory parsing and serialization
support including better XML namespace handling and streaming at
multiple document levels.

  * Automatic generation of make-style dependency information.

This release also adds support for Clang as well as Visual Studio 2012
(11.0) and 2013 (12.0).

A more detailed discussion of these features can be found in the following
blog post:

http://www.codesynthesis.com/~boris/blog/2014/07/22/codesynthesis-xsd-4-0-0-released/

For the complete list of new features in this version see the official
release announcement:

http://www.codesynthesis.com/pipermail/xsd-announcements/2014/41.html

XSD is written in portable C++ (both C++98/03 and C++11 are supported) and
you should be able to use it with any reasonably modern C++ compiler. In
particular, we have tested this release on GNU/Linux (x86/x86-64), Windows
(x86/x86-64), Mac OS X (x86), and Solaris (x86/x86-64/SPARC) with GNU g++
4.2.x-4.8.x, MS Visual C++ 2005, 2008, 2010, 2012, 2013, Sun Studio 12u2,
and Clang 3.x.

More information, documentation, source code, and pre-compiled binaries
are available from:

http://www.codesynthesis.com/products/xsd/

Enjoy,
Boris


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Issue with collapsing whitespace in a union during schema validation

2014-01-07 Thread Boris Kolpackov
Hi,

Rob Cameron r...@international-characters.com writes:

 This is a very clear and useful test case demonstrating the issue.
 I think you are correct.  Your sample file should validate against either
 schema. I am ccing the c-dev@xerces list because it appears to be a bug
 in Xerces itself.

I would suggest that you also file a bug report in Jira (and attach
the test case) so that this doesn't get lost. We can then try to fix
it for the next release.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Regarding Xercesc++ performance

2013-06-14 Thread Boris Kolpackov
Hi Rinil,

Baxi, Rinil Rushabh rinil.b...@hp.com writes:

 I have 2 Xerces-C++ libraries available on my platform (2.4 and 3.1).
 Both are built without threads. I am trying to compare performance
 of both of them. To compare performance I am using different sized
 xml files to parse using the samples (1kb, 65kb, 256Kb, 1Mb, 2Mb,
 5Mb and 15Mb). I have put each sample in a script and run the same
 sample 1000 times to compare the parsing time.

Hm, I wouldn't do it like that. I would make the test itself perform
1000 iterations and also include a few warm up iterations. If you are
interested, CodeSynthesis XSD[1], which is based on Xerces-C++, includes
'performance' examples that show how to do this. They also show how
to configure Xerces-C++ parsers for optimal performance (things like
schema preloading, etc). The one for DOM is in examples/cxx/tree/ and
the one for SAX2 -- examples/cxx/parser/.

 
 We observed that till 1Mb xml file size performance of Xerces-C++ 3.1
 is better after that it starts deteriorating.

We definitely tested the performance difference between 2 and 3-series
and I am pretty sure Xerces-C++ 3 did consistently better.

[1] http://www.codesynthesis.com/products/xsd

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces-C / Patch Release Request

2013-04-11 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I'm happy to spend some time testing the build on my supported platforms
 once it's ready to go.

Yes, that would great. The more testing we can get done, the better.


 I would suggest as a way of perhaps reducing time commitment than actually
 producing binaries for other than Windows is not a great use of time.

Yes, I was also thinking along those lines, especially for platforms
like HPUX, AIX, etc. But perhaps you are right, maybe we should drop
everything except Windows. Would be good idea to send an email to the
lists and check if anyone objects.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces-C / Patch Release Request

2013-04-10 Thread Boris Kolpackov
Hi Steven,

shath...@e-z.net shath...@e-z.net writes:

 I would like to see a patch release for Xerces-C (XML Parser).
 
 The current version of Xerces is 3.1.1.
 I propose a patch relase of Xerces-C as 3.1.2.

A bugfix release (e.g., 3.1.2) would normally be released to fix
something, not to add new features. So I think we should aim for
3.2.0 (from trunk).


 Tasks:
 *  Update the version.incl file
 *  Merge the trunk to the 3.1 branch
 *  Perform quality assurance testing on the 3.1 branch
 *  Update the Xerces-C website documents
 *  Package the distributions
 *  Submit the distribution artifacts to the mirrors
 *  Announce a patch release

I wish it were that easy ;-). A (possibly incomplete) list of release
tasks can be found here:

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt?view=log

The major ones are:

- Test on all the platforms/C++ compilers that we claim to support
- Build binaries for all the platforms/C++ compilers that we claim to support
- Update (brain-dead) Xerces-C++ website management system

I also remember last time I did a release, Apache infra people told
me that it was the last time we were able to publish our binaries
(I think it were the binaries) that way and we would have to change
to the new way with the next release. Not sure what that would
involve.

Overall, Xerces-C++ release is quite a tedious and often frustrating
process, not something you would want to do often (which is also the
reason why you would try to get it right the first time).


 I can offer some assistance at getting the Xerces-C patch release
 ready for distribution.

I was hoping to find time and make a release around June or July.
It would also be a good idea to spend some time and try to fix some
new bugs that have been uncovered since the 3.1.0 release. Not sure
if you would like to wait or if you want to press ahead. But your
help would be greatly appreciated.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: [VOTE]: Set up admin group for Xerces Wiki to eliminate SPAM

2013-04-04 Thread Boris Kolpackov
Sounds good to me. +1.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces_C - Microsoft Upgrade

2013-02-15 Thread Boris Kolpackov
Hi,

shath...@e-z.net shath...@e-z.net writes:

 FYI: Windows - Cygwin and MinGW
 
 These systems are deprecated.

I don't think anyone deprecated MinGW. Everything should build
fine with autotools and I see at least MinGW supported in the
future.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces Performance Acceleration Project: icXML

2013-01-27 Thread Boris Kolpackov
Hi Rob,

Rob Cameron r...@international-characters.com writes:

 icXML is the name of our project to dramatically accelerate
 Xerces performance on modern commodity processors by taking
 advantage of SIMD and multicore capabilities and parallel bit
 stream technology.

I wanted to try icXML with CodeSynthesis XSD[1] for some time
now. Just haven't been able to find the time.

I have a few questions:

1. It is my understanding that icXML is interface-compatible
   with Xerces-C++ 3-series. Is that correct?

2. Have you done any parallelization of the XML Schema validation
   engine?

3. You've shown results for icXML in two configurations, single-
   threaded and with 2 threads. Is there any documentation that
   describes these extra parameters/options/etc. In other words,
   how would I go about specifying the number of threads?

[1] http://www.codesynthesis.com/products/xsd/

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Xerces-C version identifiers in svn trunk

2012-12-20 Thread Boris Kolpackov
shath...@e-z.net shath...@e-z.net writes:

 The current xerces-c released version is 3.1.1 -- the development
 svn.a.o/xerces/c/trunk still references 3.1.0 in the following files.

The trunk will eventually become 3.2.0.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Commented] (XERCESC-1971) Cannot build on Mac OS X 10.7

2011-08-14 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084825#comment-13084825
 ] 

Boris Kolpackov commented on XERCESC-1971:
--

Nathaniel, Xerces-C++ 2.8.0 is no longer maintained/supported. There will be no 
new releases in 2-series. Have you tried to build Xerces-C++ 3.1.1?

 Cannot build on Mac OS X 10.7
 -

 Key: XERCESC-1971
 URL: https://issues.apache.org/jira/browse/XERCESC-1971
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 2.8.0
 Environment: Mac OSX 10.7 (Lion).   Must be built in 64-bit mode to 
 be binary-compatible with standard Lion builds.
Reporter: Nathaniel Tagg

 This has been seen before, for example:
 http://web.archiveorange.com/archive/v/3yUylsC2yFLq8CqyP0Ml
 The code will not build, failing in several places. I do not require Mac OSX 
 specific tools; I'd be very happy with just POSIX-compliant libraries, if 
 such a build option were possible.
 Although one can download a 32-bit binary, it will not compile against 
 standard 64-bit binaries in other code. I'm compiling  a large number of 
 other libraries against XercesC, and cannot modify the build systems to build 
 on 32-bit mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1959) serializeGrammars does not work between 32 and 64 bit systems

2011-03-05 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002969#comment-13002969
 ] 

Boris Kolpackov commented on XERCESC-1959:
--

Daniel, I agree the current implementation is not ideal so if you would like to 
come up with a patch, then that would be very welcome.

David, regarding backwards compatibility, there is a format version number 
stored with the binary representation. Now, the problem is that the version 
itself is stored in a non-portable manner. Luckily it is always 32-bit 
(unsigned int) so we can write 0x there for the new format which will 
make sure that any previous version (regardless of the endianness) will not 
compare equal.


 serializeGrammars does not work between 32 and 64 bit systems
 -

 Key: XERCESC-1959
 URL: https://issues.apache.org/jira/browse/XERCESC-1959
 Project: Xerces-C++
  Issue Type: Bug
  Components: Validating Parser (XML Schema)
Affects Versions: 3.1.1
 Environment: Win Vista 32 bit + VS 2010 express, Xerces-C 3.1.1 binary
 Ubuntu 10.10 64 bit, Xerces-C 3.1 installed
Reporter: Daniel Turcanu

 Serialization of schema grammar does not work between Windows 32 and Linux 64 
 bit. Serializing on one machine (with serializeGrammars) and deserializing on 
 the other (with deserializeGrammars) fails ungracefully.
 Serializing and deserializing on the same machine works fine.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Win32TransService.obj LNK2019 error

2011-03-05 Thread Boris Kolpackov
Hi Mayra,

Please post usage questions to the c-us...@xerces.apache.org mailing list
instead of c-dev.

Mayra mlchav...@gmail.com writes:

 1XercesLib.lib(Win32TransService.obj) : error LNK2019: unresolved external
 symbol __imp__RegQueryValueExA@24 referenced in function bool __cdecl
 xercesc_3_1::isAlias(struct HKEY__ * const,char * const,unsigned int)
 (?isAlias@xercesc_3_1@@YA_NQAUHKEY__@@QADI@Z)

You are linking to a static version of Xerces-C++ library. All the unresolved
symbols are Registry functions. You need to link your application to
Advapi32.lib.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Error configuring Xerces 3.1.1

2010-12-16 Thread Boris Kolpackov
Hi Helen,

Helen Gao h...@tibco.com writes:

 When I run ./configure, I got some errors in config.log.  

 conftest.c:11:28: ac_nonexistent.h: No such file or directory
 
 conftest.cpp:81:39: CoreServices/CoreServices.h: No such file or
 directory

This is normal as configure performs various tests and some of them
are expected to fail on some platforms. If you see no errors in
STDERR and the script existed with 0, then everything went fine.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Static Xerces 3.0.0 lib for HPUX pa-risc architecture

2010-12-13 Thread Boris Kolpackov
Hi Gundja,

Gundja gundja.skladi...@gmail.com writes:

 I am trying to use Xerces 3.0.0 at HPUX pa-risc 32 bit box.
 I am trying to find static Xerces lib (3.0.0) version but did not have luck
 with it so far.
 
 Is it available?

PA-RISC is discontinued by both HP and Xerces-C++.

 And if there is no out of box binaries is there a way to build it for
 pa-risc 32 bit.

Follow the build instructions for UNIX and add --disable-shared to the
configure command line.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1951) Missing Libs.private in the xerces-c pkg-config file

2010-11-29 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1951:
-

Fix Version/s: (was: 3.1.1)

Thanks for the patch.

 Missing Libs.private in the xerces-c pkg-config file
 

 Key: XERCESC-1951
 URL: https://issues.apache.org/jira/browse/XERCESC-1951
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.1, 3.1.2, 3.2.0, 4.0.0
 Environment: MinGW cross compiling
Reporter: Volker Grabsch
 Fix For: 3.1.2, 3.2.0, 4.0.0

 Attachments: xerces-fix-pkgconfig.patch


 When compiling Xerces statically with libCURL support, the command
 pkg-config xerces-c --static --libs
 does not output the CURL lib and its dependencies. This finally leads to 
 linker errors.
 The attached patch fixed this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Created: (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess

2010-11-22 Thread Boris Kolpackov (JIRA)
Build-in UCS4 transcoder does not respect endianess
---

 Key: XERCESC-1950
 URL: https://issues.apache.org/jira/browse/XERCESC-1950
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.1
 Environment: any
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0
 Attachments: test.xml

Built-in UCS4 transcoder does not respect endianess of the requested encoding. 
Try this on the attached test file:

DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml
DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml

The resulting two files will have the same representations for long 
characters, little-endian if run on LE machine, and big-endian if run on a BE 
machine. The UTF-32 transcoder doesn't seem to have this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess

2010-11-22 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1950:
-

Attachment: test.xml

 Build-in UCS4 transcoder does not respect endianess
 ---

 Key: XERCESC-1950
 URL: https://issues.apache.org/jira/browse/XERCESC-1950
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.1
 Environment: any
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0

 Attachments: test.xml


 Built-in UCS4 transcoder does not respect endianess of the requested 
 encoding. Try this on the attached test file:
 DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml
 DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml
 The resulting two files will have the same representations for long 
 characters, little-endian if run on LE machine, and big-endian if run on a BE 
 machine. The UTF-32 transcoder doesn't seem to have this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1947) XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding single characters that require 3 or more bytes as UTF8.

2010-10-14 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1947:
-

Fix Version/s: 3.2.0
   3.1.2

Ben, the reason I am interested in whether this affects parsing/serialization 
is because if it does then we have a critical issue and a bug-fix release is 
probably needed. If it only affects TranscodeToStr, which is only used in a few 
net accessors, then this is not critical (it is highly unlikely a URI will 
contain a three-byte UTF-8 sequence) and can wait until the normal release 
cycle. I think we both agree this only affects TranscodeToStr. Scheduling this 
bug for 3.1.2/3.2.0.



 XMLUTF8Transcoder::transcodeTo  fails with an exception when transcoding 
 single characters that require 3 or more bytes as UTF8.
 

 Key: XERCESC-1947
 URL: https://issues.apache.org/jira/browse/XERCESC-1947
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.0, 3.1.1
 Environment: Tested on mac os and debian linux. The failure is only 
 manifest on v3.1.x
Reporter: Ben Griffin
Priority: Critical
 Fix For: 3.1.2, 3.2.0

 Attachments: TransService.patch, transtest.cpp


 This can be demonstrated with the following 2 lines of code.
   const XMLCh uval [] = { 0x254B, 0x}; //BOX DRAWINGS HEAVY VERTICAL 
 AND HORIZONTAL (needs 3 bytes for utf-8)
   char* uc = (char*)TranscodeToStr(uval,UTF-8).adopt(); cout  uc  
 endl  flush; XMLString::release(uc); //faulty exception;
 The error is: terminate called after throwing an instance of 
 'xercesc_3_1::TranscodingException'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1947) XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding single characters that require 3 or more bytes as UTF8.

2010-10-12 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920195#action_12920195
 ] 

Boris Kolpackov commented on XERCESC-1947:
--

Ben, is this only a problem in TranscodeToStr or can you also get this by 
parsing/serializing XML? It is my understanding that this only affects 
TranscodeToStr.

 XMLUTF8Transcoder::transcodeTo  fails with an exception when transcoding 
 single characters that require 3 or more bytes as UTF8.
 

 Key: XERCESC-1947
 URL: https://issues.apache.org/jira/browse/XERCESC-1947
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.0, 3.1.1
 Environment: Tested on mac os and debian linux. The failure is only 
 manifest on v3.1.x
Reporter: Ben Griffin
Priority: Critical
 Attachments: TransService.patch, transtest.cpp


 This can be demonstrated with the following 2 lines of code.
   const XMLCh uval [] = { 0x254B, 0x}; //BOX DRAWINGS HEAVY VERTICAL 
 AND HORIZONTAL (needs 3 bytes for utf-8)
   char* uc = (char*)TranscodeToStr(uval,UTF-8).adopt(); cout  uc  
 endl  flush; XMLString::release(uc); //faulty exception;
 The error is: terminate called after throwing an instance of 
 'xercesc_3_1::TranscodingException'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.

2010-09-07 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1936:
-

Fix Version/s: 3.1.2
   3.2.0
   4.0.0

Yes, I just tried your test with ICU and I get the error. Scheduling this bug 
for the next release.

 ICUTransService and IconvGNUransService CAN NOT deal with huge file.
 

 Key: XERCESC-1936
 URL: https://issues.apache.org/jira/browse/XERCESC-1936
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.8.0, 3.1.1
 Environment: RHEL-5.5
 glibc-2.5-49.el5_5.2
 libicu-3.6-5.11.4
Reporter: kirby zhou
 Fix For: 3.1.2, 3.2.0, 4.0.0


 If a huge file passed to XMLReader, it will call TransService mulitple times, 
 and splite the file content into several fragments.
 Unfortunately, the fragment will contain incomplete multi-byte characters.
 But neither ICUTransService nor IconvGNUransService deal with it. 
 ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and 
 IconvGNUransService did not deal with EINVAL.
 Both 2.8.0 and 3.1.1 have the same bug.
 For example, make 2 XML like that:
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/small.xml
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/big.xml
 # the small.xml and big.xml are analogical. 
 ]# samples/SAXPrint -x=gbk ~/small.xml 
 ?xml version=1.0 encoding=gbk?
 data
 中文汉字A中文汉字A
 /data
 # with icu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: char 0x6C49 is not representable in 'gbk' encoding
 # with iconvgnu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ]# samples/SAXPrint -x=gbk ~/big.xml 
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: invalid multi-byte sequence

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1451) Valgrind reports mismatched new/delete[] usage

2010-08-24 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901970#action_12901970
 ] 

Boris Kolpackov commented on XERCESC-1451:
--

Daniel, Have you tried the latest release (3.1.1)? 2.8.0 is no longer supported 
so even if there is a bug, it won't be fixed in 2.x.y release series.

 Valgrind reports mismatched new/delete[] usage
 --

 Key: XERCESC-1451
 URL: https://issues.apache.org/jira/browse/XERCESC-1451
 Project: Xerces-C++
  Issue Type: Bug
Affects Versions: 2.5.0, 2.6.0
 Environment: Red Hat 9 (Shrike 2.4.20-6smp), Dell Precision 530
 Valgrind 2.4.0
 g++ 3.2.2
Reporter: Glenn Miyake

 Valgrind reports a mismatch new/delete[] 
 MemoryManagerImpl::allocate(unsigned) appears to allocate using just 
 new(size).
 This memory is then incorrectly freed using array delete (delete []) in 
 XMLString::release.
 Simply changing the release method to call delete does not work since it 
 appears that release is also used to free memory allocated with new [].
 Partial valgrind output follows:
 ==21267== Mismatched free() / delete / delete []
 ==21267==at 0x1B903D5D: operator delete[](void*) (vg_replace_malloc.c:161)
 ==21267==by 0x1BB0A9EC: xercesc_2_6::XMLString::release(unsigned short**) 
 (in /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x836BC59: 
 altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:451)
 ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() 
 (Node.cpp:469)
 ==21267==  Address 0x1BE20C18 is 0 bytes inside a block of size 3912 alloc'd
 ==21267==at 0x1B9036A6: operator new(unsigned) (vg_replace_malloc.c:132)
 ==21267==by 0x1BA7C51B: 
 xercesc_2_6::MemoryManagerImpl::allocate(unsigned) (in 
 /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x1BA49F0A: 
 xercesc_2_6::DOMWriterImpl::writeToString(xercesc_2_6::DOMNode const) (in 
 /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x836BC23: 
 altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:440)
 ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() 
 (Node.cpp:469)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1940) Problem in prefix parsing while creating Documnet, Element, Attributes on all platforms : Issue is in poolString creation

2010-08-23 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1940:
-

Fix Version/s: 3.1.2
   3.2.0

Thanks for the report, Anil. I am scheduling this for 3.1.2 and 3.2.0. Though 
the patch doesn't look portable (dynamic allocation of an array).

 Problem in prefix parsing while creating Documnet, Element, Attributes on all 
 platforms : Issue is in poolString creation
 -

 Key: XERCESC-1940
 URL: https://issues.apache.org/jira/browse/XERCESC-1940
 Project: Xerces-C++
  Issue Type: Bug
  Components: DOM
Affects Versions: 3.0.1, 3.1.1
 Environment: ALL Platform, ALL OS
Reporter: Anil G Pandge
Priority: Critical
 Fix For: 3.1.2, 3.2.0

 Attachments: DOMDocumentImpl.hpp.patch, MainPro.cpp


 Description:
 
 When I create a DOM document using xerces APIs, for very specific input its 
 creating wrong payload. This is observable on 64-bit but on 32-bit. For 
 testing I have written sample with createDocument API which creates DOM 
 document and print it in string format.
 I ran the test on following inputs:
 createDocument(types:statusSet,http://xyz.com;);
 createDocument function just create dom document and prints payloads. 
 Following is the outputs of above string on 32-bit machine.
 32 bit platforms output:
 prefix = types:statusSet
 LocalName = statusSet
 doc = types:statusSet xmlns:types:statusSet=http://xyz.com/
 ===
 Severity : Critical
 ===
 Platforms: ALL
 ==
 Cause and resolution
 
 I debugged xerces code, issue is in 
  File : DOMDocumentImpl.hpp
  Function : DOMDocumentImpl::getPooledNString(const XMLCh *in, XMLSize_t n)
 Patch:
 ==
 --- DOMDocumentImpl.hpp2008-07-24 15:58:29.0 +0530
 +++ 
 /data/eclipse_workspace/CppIT-3.1.0/XercesTEst/src/xercesc/dom/impl/DOMDocumentImpl.hpp
 2010-08-22 10:36:18.0 +0530
 @@ -401,9 +401,11 @@
pspe = fNameTable[inHash];
while (*pspe != 0)
{
 -if (XMLString::equalsN((*pspe)-fString, in, n))
 -  return (*pspe)-fString;
 -pspe = ((*pspe)-fNext);
 +  XMLCh firstN[n];
 +  XMLString::copyNString(firstN,in,n);
 +  if (XMLString::equals((*pspe)-fString, firstN))
 +  return (*pspe)-fString;
 +  pspe = ((*pspe)-fNext);
}
 Issue:
 ==
   1. getPooledNString computes hash of prefix and searches in fNameTable.
   2. Once hash is found, code cheks pooledString and 'n' characters of 
 qualifiedString. ! WRONG !
   3. if comparision is true it returns the pooled string.
   Ex:
   In case of types:statusSet, it will compare types:statusSet 
 and first 6 characters of types:, it found comparision true. It return 
 pooled string types:statusSet as prefix ! WRONG !
 How to reporduce:
 =
   Very easy to reproduce. Run the sample program I have attached.
   
 Resolution:
 ===
   I have attached patch file with resolution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.

2010-08-03 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1936:
-


Hi,

Can you attach the sample files to the bug report? The content that you have 
pasted in the description is all garbled. Also, would you be able to come up 
with a patch for this issue?

 ICUTransService and IconvGNUransService CAN NOT deal with huge file.
 

 Key: XERCESC-1936
 URL: https://issues.apache.org/jira/browse/XERCESC-1936
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.8.0, 3.1.1
 Environment: RHEL-5.5
 glibc-2.5-49.el5_5.2
 libicu-3.6-5.11.4
Reporter: kirby zhou

 If a huge file passed to XMLReader, it will call TransService mulitple times, 
 and splite the file content into several fragments.
 Unfortunately, the fragment will contain incomplete multi-byte characters.
 But neither ICUTransService nor IconvGNUransService deal with it. 
 ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and 
 IconvGNUransService did not deal with EINVAL.
 Both 2.8.0 and 3.1.1 have the same bug.
 For example, make 2 XML like that:
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/small.xml
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/big.xml
 # the small.xml and big.xml are analogical. 
 ]# samples/SAXPrint -x=gbk ~/small.xml 
 ?xml version=1.0 encoding=gbk?
 data
 中文汉字A中文汉字A
 /data
 # with icu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: char 0x6C49 is not representable in 'gbk' encoding
 # with iconvgnu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ]# samples/SAXPrint -x=gbk ~/big.xml 
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: invalid multi-byte sequence

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Validate the data contained in a DOM tree

2010-07-30 Thread Boris Kolpackov
Hi Vladimir,

Vladimir Loubenski vloub...@opentext.com writes:

 My understanding that single way to validate data (Validation against
 XML schema) in a DOM tree is to create the DOM document, write it back
 as XML and re-parse it with validation turned on. Are there plans to
 support validation direct from the DOM tree?

No, there are no plans to support this at the moment. It is also 
questionable how useful this feature will be since it is not clear
what one can do when a validation error has been detected. There
are some errors that will be hard/impossible to fix programmatically
(say, pattern validation error). For a more detailed discussion of
this topic, see the following post:

http://www.codesynthesis.com/pipermail/xsd-users/2008-January/001443.html


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Development plans for XML Schema 1.1

2010-06-27 Thread Boris Kolpackov
Hi Khaled,

Khaled Noaman knoa...@ca.ibm.com writes:

 Xerces-J 2.10 was just release and it included experimental support for 
 XML Schema 1.1. Are there any future plans to implement XML Schema 1.1 in 
 Xerces-C?

I chatted with Alberto about this the other day. It seems before we
make any major changes to the XML Schema processor in Xerces-C++, it
would be wise to decouple the validators from XML scanners and make
them just another stage in the pipeline. The current architecture
is very hard to maintain and has a number of serious shortcomings
(e.g., the fact that certain validation errors are detected only
after the SAX events have been fired).

Also, the XML Schema 1.1 spec is not yet a recommendation. I am not 
very familiar with the W3 process, but isn't it still a moving target?

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Created: (XERCESC-1931) Add support for Windows-style UNC URIs

2010-06-02 Thread Boris Kolpackov (JIRA)
Add support for Windows-style UNC URIs
--

 Key: XERCESC-1931
 URL: https://issues.apache.org/jira/browse/XERCESC-1931
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Utilities
Affects Versions: 3.1.1
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0


There are three ways to represent Windows network share paths in URI that are 
in use today:
file://host/path
file:host/path
file:/host/path

Xerces-C++ only supports the later two. The first encoding is the Microsoft 
recommended[1] and Windows API functions construct URI this way. We should 
probably add support for the first format as well.

[1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1930) CRLF is replaced by space

2010-05-31 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1930.


Resolution: Invalid

  CRLF is replaced by space
 --

 Key: XERCESC-1930
 URL: https://issues.apache.org/jira/browse/XERCESC-1930
 Project: Xerces-C++
  Issue Type: Bug
Affects Versions: 2.2.0
Reporter: Harpreet

 Hi, 
 Our code creates a xml where description tag contains text in the format 
 abcdCRLFefgh where CR stands for carriage return and LF stands for line 
 feed. Now when we pass the xml to xerces, the CRLF combo is converted to 
 space which is unexpected.
 Is this issue already reported? I searched over the net and in JIRA as well 
 but could not find any such reported issues.
 Is there any workaround available for this.
 Thanks
 Harpreet

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Question About xerces code

2010-05-25 Thread Boris Kolpackov
Hi Henry,

In the future please send questions about Xerces-C++ to one of the
project's mailing lists instead of to me directly. For technical
questions like these c-dev is appropriate (which, BTW, I've CC'ed
to my reply).


Wang, Henry (LeftHand Networks) henry.wa...@hp.com writes:

 Hi. Boris;
 My name is Henry Wang, I am with HP Corp. We have a project using 
 Xerces, and we constantly have memory leak. We use Purify trying to find 
 where the leak is. Purify always point to ContentSpecNode constructor is 
 leaking memory. I studied the xerces code and have several questions here.
 I appreciate your help in understanding this code. Thanks.
 
 1. In ContentSpecNode::ContentSpecNode() constructor,
 fElement = new (fMemoryManager) QName(*element);
 
 this does not allocate memory, just replace memory allready allocated 
 by FMemoryManager, but then the destructor of ContentSpecNode is:
 
 delete fElement;
 
 This will call Standard Library delete function.
 
 Don't we have a mis-match here, the fMemoryManager should be called to 
 de-allocate memory, right ?

QName derives from XMemory which overloads operator delete() to free 
the memory using the memory manager. See the XMemory implementation 
for details.


 2. In void TraverseSchema::validateAnnotations() {
 
 we have:
 
 ContentSpecNode* left  = new (memMgr) ContentSpecNode(appInfoElemDecl, 
 memMgr);
 ContentSpecNode* right = new (memMgr) ContentSpecNode(docElemDecl, memMgr);
 ContentSpecNode* root  = new (memMgr) 
 ContentSpecNode(ContentSpecNode::ModelGroupChoice
 , left
 , right
 , true
 , true
 , memMgr);
 
 Does the memMgr smart enough to replace different section of memory 
 for these three consective replacements?, How the delete will work?

I am not sure what you mean by these. new (memMgr) ... will allocate
the memory block using the memory manager. operator delete () from
XMemory will release it.


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: svn tag for 3_1_1 missing?

2010-05-11 Thread Boris Kolpackov
Hi Ben,

Ben Griffin b...@redsnapper.net writes:

 A svn tag for Xerces-C++ 3.1.1 appears to be missing.

Sorry, I completely forgot about this. The tag is now in place. 
Thanks for reporting this!

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1925) Wrong temporary token type causes regex construction to fail

2010-05-09 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1925:
-

Fix Version/s: 3.1.2
   3.2.0

Scheduling for 3.1.2, 3.2.0.

 Wrong temporary token type causes regex construction to fail
 

 Key: XERCESC-1925
 URL: https://issues.apache.org/jira/browse/XERCESC-1925
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Reporter: John Keeping
 Fix For: 3.1.2, 3.2.0

 Attachments: xerces-range-token-merge.patch


 When checking for token overlap in a regular expression a temporary range 
 token is constructed and merged with another range token. This temporary 
 token has type Token::T_RANGE so the merge fails if the actual token is of 
 type Token::T_NRANGE.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1926) IGXMLScanner can fail to properly set its XSModel.

2010-05-09 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1926:
-

Fix Version/s: 3.1.2
   3.2.0

Scheduling for 3.1.2, 3.2.0.

 IGXMLScanner can fail to properly set its XSModel.
 --

 Key: XERCESC-1926
 URL: https://issues.apache.org/jira/browse/XERCESC-1926
 Project: Xerces-C++
  Issue Type: Bug
  Components: Validating Parser (XML Schema)
Reporter: John Keeping
 Fix For: 3.1.2, 3.2.0

 Attachments: xerces-model-update.patch


 If an IGXMLScanner is used for a document with no schema and then reset to 
 scan a document with a schema the model is not set correctly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1922) MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type 'void *' and pointer-to-function

2010-05-09 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1922.


Fix Version/s: 3.1.2
   3.2.0
   (was: 3.1.0)
   Resolution: Fixed

Fix is in SVN, thanks.

 MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type 
 'void *' and pointer-to-function
 --

 Key: XERCESC-1922
 URL: https://issues.apache.org/jira/browse/XERCESC-1922
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build
 Environment: Mac OS X 10.6.3, g++ 4.2.1, xerces 3.1
Reporter: isidoro ghezzi
Priority: Minor
 Fix For: 3.1.2, 3.2.0

   Original Estimate: 1h
  Remaining Estimate: 1h

 Compiling with $ g++ --version
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
 having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is:
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp: In 
 static member function 'static bool 
 xercesc_3_1::MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported()':
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:461: 
 error: ISO C++ forbids comparison between pointer of type 'void *' and 
 pointer-to-function
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:462: 
 error: ISO C++ forbids comparison between pointer of type 'void *' and 
 pointer-to-function
 to avoid that, i suggest to change:
 [code]
 bool
 MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
 {
 return UpgradeScriptInfoToTextEncoding != (void*)NULL
  CreateTextToUnicodeInfoByEncoding != (void*)NULL
 ;
 }
 [/code]
 to:
 [code]
 bool
 MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
 {
 return (0L != UpgradeScriptInfoToTextEncoding)
  (0L != CreateTextToUnicodeInfoByEncoding)
 ;
 }
 [/code]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1923) removing extras semicolon

2010-05-09 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1923.


Fix Version/s: 3.1.2
   3.2.0
   Resolution: Fixed

The fix is in SVN, thanks!

 removing extras semicolon
 -

 Key: XERCESC-1923
 URL: https://issues.apache.org/jira/browse/XERCESC-1923
 Project: Xerces-C++
  Issue Type: Test
  Components: Samples/Tests
Affects Versions: 3.1.0
 Environment: MacOS 10.3.6, xerces 3.1, gcc 4.2
Reporter: isidoro ghezzi
 Fix For: 3.1.2, 3.2.0

   Original Estimate: 1h
  Remaining Estimate: 1h

 Compiling with $ g++ --version 
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) 
 having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is: 
 $ make check
 ...
 Compiling src/DOM/DOMMemTest/DOMMemTest.cpp
 src/DOM/DOMMemTest/DOMMemTest.cpp:50: error: extra ';'
 src/DOM/DOMMemTest/DOMMemTest.cpp:1489: error: extra ';'
 Compiling src/DOM/Normalizer/Normalizer.cpp
 src/DOM/Normalizer/Normalizer.cpp:203: error: extra ';'
 Compiling src/DOM/RangeTest/RangeTest.cpp
 src/DOM/RangeTest/RangeTest.cpp:55: error: extra ';'
 src/DOM/RangeTest/RangeTest.cpp:966: error: extra ';'
 Compiling src/DOM/Traversal/Traversal.cpp
 src/DOM/Traversal/Traversal.cpp:55: error: extra ';'
 src/DOM/Traversal/Traversal.cpp:557: error: extra ';'
 Compiling src/EncodingTest/EncodingTest.cpp
 src/EncodingTest/EncodingTest.cpp:82: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:96: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:111: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:172: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:443: error: extra ';'
 solved simply removing extra ; at above lines.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: [VOTE]: Nomination of Mukul Gandhi for Xerces PMC Membership

2010-05-02 Thread Boris Kolpackov

+1

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1924) Cannot open include file: 'inttypes.h': No such file or directory

2010-04-30 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1924.


Resolution: Invalid

Please don't ask for help by creating bug report. Rather, post your question to 
the c-users mailing list:

http://xerces.apache.org/xerces-c/mailing-lists.html


 Cannot open include file: 'inttypes.h': No such file or directory
 -

 Key: XERCESC-1924
 URL: https://issues.apache.org/jira/browse/XERCESC-1924
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: Cygwin 1.7.5 running on Vista using Visual C++ 2008 
 Express Edition
Reporter: R Manger

 I am trying to install GDML add-on to Geant4, but I get an error when 
 Xerces_autoconf_config.hpp calls for 'inttypes.hh.' Here is an excerpt of the 
 compilation process:
 Compiling G4GDMLParser.cc ...
 G4GDMLParser.cc
 c:/xerces/include\xercesc/util/Xerces_autoconf_config.hpp(88) : fatal error 
 C1083: Cannot open include file: 'inttypes.h': No such file or directory
 make[2] *** [c:/Geant4/geant4_9_3/tmp/WIN32-VC/G4gdml/G4GDMLParser.o] Error 2
 make[1]: *** [objs] Error 2
 I know that Visual Studio is set up to communicate with cygwin properly 
 because I have built many other cpp toolkits in this environment. What may be 
 the problem?
 Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[ANN] CodeSynthesis XSD 3.3.0 released

2010-04-28 Thread Boris Kolpackov
Hi,

I am pleased to announce the availability of CodeSynthesis XSD 3.3.0.

CodeSynthesis XSD is an open-source (GPL2 + proprietary license), cross-
platform W3C XML Schema to C++ data binding compiler. Provided with a
schema, it generates C++ classes that represent the given vocabulary as
well as parsing and serialization code. You can then access the data
stored in XML using types and functions that semantically correspond to
your application domain rather than dealing with elements, attributes,
and text in a direct representation of XML such as DOM or SAX.

XSD uses Xerces-C++ as the underlying XML parser which allows for greater
flexibility while processing XML. For example, the data can be pre-processed
using the DOM representation before being converted to C++ classes as well
as post-processed before being serialized back to XML. Other features
that are made possible with this architecture include the representation
of XML Schema wildcard content (xs:any and xs:anyAttribute) as DOM fragments,
optional bi-directional association between DOM nodes and C++ class instances,
as well as the execution of XPath queries with the ability to access the
result as C++ class instances.

Major new features in this release:

  * Support for uniform parsing and serialization of XML documents
with varying root elements.

  * Configurable application character encoding (UTF-8, ISO-8859-1, etc).

  * Support for stream-oriented, partially in-memory/partially event-
driven XML parsing and serialization.

  * Support for embedding the binary representation of the schema
grammar into the application.

  * Generation of the detach functions that allow moving object
model sub-trees without copying. 

  * Support for XML compression.

  * Smaller and faster generated code for polymorphic XML Schemas 
(xsi:type and substitution groups).

The release also adds support for a range of new operating system and C++
compiler versions, including:

  * AIX 6.x
  * Mac OS X 10.6
  * Windows 7,
  * Windows Server 2008

  * Visual Studio 2010 (10.0)
  * GNU g++ 4.5.0
  * Intel C++ 11
  * Sun Studio 12.1
  * IBM XL C++ 11

Visual Studio 2010 project and solution files are provided for all the
examples.
  
For the complete list of new features in this release see:

http://www.codesynthesis.com/pipermail/xsd-announcements/2010/38.html

CodeSynthesis XSD is available on IBM AIX, GNU/Linux, HP-UX, Mac OS X,
Solaris, Windows, OpenVMS, and z/OS. Supported C++ compilers include: 
GNU g++, HP aCC, IBM XL C++, Intel C++, Sun C++, and MS Visual C++.

More information, documentation, source code, and precompiled binaries
for all the supported platforms are available from:

http://www.codesynthesis.com/products/xsd/


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Xerces-C++ 3.1.1 released

2010-04-27 Thread Boris Kolpackov
Hi,

I am pleased to announce the release of Xerces-C++ 3.1.1. This version 
is a bug-fix release and is binary-compatible with Xerces-C++ 3.1.0.
It also adds project and solution files for Visual Studio 2010 (10.0).

The following bugs have been fixed in this version compared to the 
previous release (3.1.0):

XERCESC-1920 XERCESC-1919 XERCESC-1918 XERCESC-1916 XERCESC-1914 
XERCESC-1913 XERCESC-1912 XERCESC-1911 XERCESC-1907

For the compete list of changes see:

http://xerces.apache.org/xerces-c/releases.html

This release is available in source code and as pre-compiled
libraries/examples for the following platforms and architectures:

32 bit:

   Windows - MSVC 7.1
   Windows - MSVC 8.0
   Windows - MSVC 9.0
   Windows - MSVC 10.0
   GNU/Linux - g++ 3.4.x
   AIX 5.3 - xlC 7
   Solaris 10 - Sun C++ 5.10, both SPARC and x86
   HP-UX 11i - aCC A.06.x, IA64
   Mac OS X - g++ 4.0, x86

64 bit:

   Windows - MSVC 8.0
   Windows - MSVC 9.0
   Windows - MSVC 10.0
   GNU/Linux - g++ 3.4.x
   AIX 5.3 - xlC 7
   Solaris 10 - Sun C++ 5.7, both SPARC and x86-64
   HP-UX 11i - aCC A.06.x, IA64

The source code archives and pre-compiled libraries are available
from the download page:

http://xerces.apache.org/xerces-c/download.cgi

Note that it takes up to 24 hours for the release to propagate to all 
the mirrors so use the master distribution directory if the files are 
not yet available on your favorite mirror. It is important that you 
verify the integrity of the files you download using either the PGP 
signatures or MD5 checksums as described on the download page.

Finally I would like to thank all who contributed source code, 
submitted bug reports, and helped test the release.

Enjoy,
Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1921) Buffer overflow in XMLString::replaceTokens()

2010-04-21 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1921.


Resolution: Invalid

Scott, the documentation for replaceTokens specifies that the buffer should be 
maxChars + 1 long to accommodate for the null terminator. While this interface 
is not ideal, this function is internal so I am not sure whether it makes sense 
to change it. I have audited all the places it is called from and they all make 
sure to allocate extra character in the buffer. Please reopen this issue if you 
see an actual buffer overrun.

 Buffer overflow in XMLString::replaceTokens()
 -

 Key: XERCESC-1921
 URL: https://issues.apache.org/jira/browse/XERCESC-1921
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
 Environment: Probably any C++ Environment
Reporter: Scott Colcord

 The function XMLString::replaceTokens() does not take its terminating NULL 
 into account when comparing with the maxChars limit passed by the caller.  
 Consequently, when passed a too-large string, it will overwrite one XMLCh 
 after the buffer.
 It should be changed to test (curOutInd+1  maxChars), and increment 
 curOutInd when setting the null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1920) UnixHTTPURLInputStream core-dumps

2010-04-21 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1920.


 Assignee: Boris Kolpackov
Fix Version/s: 3.1.1
   3.2.0
   Resolution: Fixed

Fix is in SVN and will be included in the upcoming 3.1.1 release. Thanks for 
the report!

 UnixHTTPURLInputStream core-dumps
 -

 Key: XERCESC-1920
 URL: https://issues.apache.org/jira/browse/XERCESC-1920
 Project: Xerces-C++
  Issue Type: Bug
  Components: SAX/SAX2
Affects Versions: 3.0.1
 Environment: Solaris 32 bit
Reporter: Kristian Ivarsson
Assignee: Boris Kolpackov
 Fix For: 3.1.1, 3.2.0


 Using SAX2XMLReader or SAXParser to parse following XML (note the tripple 
 slashes) makes the application to core dump and a SEGV occurs in 
 UnixHTTPURLInputStream::UnixHTTPURLInputStream() where function 
 gethostbyname() is called
 ...
const char * const xml =
   ?xml version='1.0' encoding='ISO-8859-1' standalone='no'?
   !DOCTYPE root SYSTEM 'http:///server.org/dtd.dtd'
   root/;
 ...
 What happens is that the first (and only) argument to gethostbyname() is 0 
 (zero/null) and some inner machanism of gethostbyname() cannot handle that
 I'm not sure what class/mechanism in XercesC is to blame though ?
 It could be XMLURL::XMLURL() that doesn't throw because of an invalid URL
 It could be XMLURL::getHost() that returns 0 instead of an empty 
 XMLCh-sequence
 It could be XMLString::transcode() that doesn't complain when transcoding a 
 null-XMLCh-sequence
 It could be ArrayJanoitor::ArrayJanoitor() that doesn't complain about that 
 an unnecessary assignment has ben given to it
 It could be UnixHTTPURLInputStream::UnixHTTPURLInputStream() that tries to 
 operate on a null-char-array
 It could be Solaris::gethostbyname() that doesn't have proper error-handling 
 of input parameters (cannot be solved in this project though)
 I haven't tried it with any of the DOMParsers, but I would guess that the 
 behaviour would be similar if the same underlaying mechanisms are (re)used

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1919) Access violation in AbstractDOMParser::docComment()

2010-04-18 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1919.


 Assignee: Boris Kolpackov
Fix Version/s: 3.1.1
   3.2.0
   Resolution: Fixed

The fix is in SVN and will be in the shortly-to-be-released 3.1.1. Thanks for 
reporting this and for the test case!

 Access violation in AbstractDOMParser::docComment()
 ---

 Key: XERCESC-1919
 URL: https://issues.apache.org/jira/browse/XERCESC-1919
 Project: Xerces-C++
  Issue Type: Bug
  Components: Non-Validating Parser
Affects Versions: 3.1.0
 Environment: Windows 7
 Visual C++ 2008
 Static manually built version of Xerces 3.1.0
Reporter: Dmitriy V'jukov
Assignee: Boris Kolpackov
 Fix For: 3.1.1, 3.2.0

 Attachments: crash.xml


 I parse an XML document with the following code:
 XercesDOMParser parser;
 parser.setCreateEntityReferenceNodes(false);
 parser.setLoadExternalDTD(false);
 parser.setLoadSchema(false);
 parser.setSkipDTDValidation(true);
 parser.setExitOnFirstFatalError(false);
 MemBufInputSource source ((XMLByte const*)decoded.begin(), 
 decoded.size(), L);
 parser.parse(source);
 Parser crashes in:
 void AbstractDOMParser::docComment(const XMLCh* const comment)
 {
 if (fCreateCommentNodes) {
 DOMComment *dcom = fDocument-createComment(comment);
 castToParentImpl (fCurrentParent)-appendChildFast (dcom); // -  
 fCurrentParent == 0
 fCurrentNode = dcom;
 }
 }
 with fCurrentParent == 0.
 Current position of parser is line 233, column 17, i.e. straight after !-- 
 Scripts --
 Here is the XML document:
 [attached as 'crash.xml']

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



VOTE RESULT for the 3.1.1 release

2010-04-16 Thread Boris Kolpackov
Hi,

The vote passes with 7 +1 votes (4 from PMC members) and no other votes.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1919) Access violation in AbstractDOMParser::docComment()

2010-04-16 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12857882#action_12857882
 ] 

Boris Kolpackov commented on XERCESC-1919:
--

Dmitriy, can you attach the XML document as a file to this bug report instead 
of pasting it in the description? If I copy it from your report, I get a bunch 
of errors. After fixing those the document parses fine with DOMCount. No 
crashes.

 Access violation in AbstractDOMParser::docComment()
 ---

 Key: XERCESC-1919
 URL: https://issues.apache.org/jira/browse/XERCESC-1919
 Project: Xerces-C++
  Issue Type: Bug
  Components: Non-Validating Parser
Affects Versions: 3.1.0
 Environment: Windows 7
 Visual C++ 2008
 Static manually built version of Xerces 3.1.0
Reporter: Dmitriy V'jukov

 I parse an XML document with the following code:
 XercesDOMParser parser;
 parser.setCreateEntityReferenceNodes(false);
 parser.setLoadExternalDTD(false);
 parser.setLoadSchema(false);
 parser.setSkipDTDValidation(true);
 parser.setExitOnFirstFatalError(false);
 MemBufInputSource source ((XMLByte const*)decoded.begin(), 
 decoded.size(), L);
 parser.parse(source);
 Parser crashes in:
 void AbstractDOMParser::docComment(const XMLCh* const comment)
 {
 if (fCreateCommentNodes) {
 DOMComment *dcom = fDocument-createComment(comment);
 castToParentImpl (fCurrentParent)-appendChildFast (dcom); // -  
 fCurrentParent == 0
 fCurrentNode = dcom;
 }
 }
 with fCurrentParent == 0.
 Current position of parser is line 233, column 17, i.e. straight after !-- 
 Scripts --
 Here is the XML document:
 !DOCTYPE html
 html id=www-netvibes.com lang=en-US dir=ltr
 head
   meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
   titleNetvibes - Dashboard Everything/title
   meta name=application-name content=Netvibes /
   meta name=application-url content=http://www.netvibes.com; /
   meta name=robots content=noodp,noydir /
   meta name=description content=First personalized dashboard publishing 
 platform for the Web.  Digital life managment, Widget distribution services 
 and brand observation rooms. For agencies, brands and media companies, 
 Netvibes delivers secure, scalable personalized workspaces, portals and 
 industry dashboards /
   meta name=keywords content=dashboard, dashboards, saved searches, 
 watch, tracking, in touch with, personalized, customized, trends, rss, rss 
 syncing, widgets, gadgets, brand monitoring, updates, e-reputation, tracking, 
 streams, twitter client, facebook pages, free, browse, search, monitor, real 
 time, share, multi-language, international, sort, instant update, reporting, 
 gauge, filter, business intelligence, brand observation, benchmark, 
 performance, evolution, real time data, social media, trending topics, 
 conversations, mentions, live, user-generated, opml, atom, xml, mashup, uwa 
 /
   link href=http://blog.netvibes.com/rss.php; rel=alternate 
 type=application/rss+xml title=Netvibes blog /
   link href=http://cdn.netvibes.com/css/base/static-home.css?v=1; 
 media=screen rel=stylesheet type=text/css /
   link href=/en rel=canonical /
   link rel=shortcut icon href=http://cdn.netvibes.com/favicon.ico; /
   link rel=icon href=http://cdn.netvibes.com/img/netvibes-32x32.png; 
 sizes=32x32 /
   link rel=icon href=http://cdn.netvibes.com/img/netvibes-48x48.png; 
 sizes=48x48 /
   link rel=search type=application/opensearchdescription+xml 
 title=Netvibes href=http://www.netvibes.com/opensearch.xml; /
 /head
 body
 div id=container class=home
 div id=header
 h1a href=/ class=logoNetvibes/a/h1
 p id=signinspanAlready have an account?/span a 
 href=/signin rel=nofollowSign in/a/p
 p id=languageInterface language:  a 
 href=javascript:void(0);English/a/p
 /div
 div id=content-wrapper class=rounded
 div id=content role=main
 
 div id=top class=autoclear
 !--[if lt IE 7]
 div id=ie6-disclaimer
 If you'd like the best Netvibes experience, we recommend that you 
 upgrade to the most recent version of your browser./div
 ![endif]--
 
 h2Your Personal Dashboards/h2
 div class=carousel-clip
 div class=carousel-list
 div id=intro
 div class=left
 div id=video
 /div
 /div
 div class=right
 h3All you care about. Live./h3
 pTrending topics. Tweets. Feeds. Friends. Photostreams. 
 Videos. Podcasts. Email. Widgets./p
 pAll in one place and always up-to-date, Netvibes is the 
 faster and easier way to enjoy the entire real-time Web. Instantly create as 
 many different

VOTE for 3.1.1

2010-04-12 Thread Boris Kolpackov
Hi,

Since the 3.1.0 release a couple of months ago, a number of bugs
have been detected and fixed, a few of which a fairly major. I 
would therefore like to propose that we publish the 3.1.1 bugfix-
only release.

Also, if any of the committers have any pending fixes that they 
would like to include into this release, please let me know.

Here is my +1 for this release.

Boris


-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: VOTE for 3.1.1

2010-04-12 Thread Boris Kolpackov
Hi David,

davidhinz interfold.com davidh...@interfold.com writes:

 Where can we review the bug fixes that would be going into 3.1.1?

The best place would probably be the SVN repository, in particular
the xerces-3.1 branch:

http://svn.apache.org/viewvc/xerces/c/branches/xerces-3.1/

Revision 905265 is the start of the branch and corresponds to 3.1.0.
It will probably be the easiest to use the svn client to either get
the changes as one big patch or to browse them commit-by-commit.

Also the c-dev mailing list archives include automatic messages 
corresponding to all the commits with the corresponding patches:

http://xerces.apache.org/xerces-c/mailing-lists.html

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1910:
-

Fix Version/s: 3.1.0
   (was: 3.2.0)
   (was: 3.1.1)

 The RegularExpression 'matches' function no longer returns the start and end 
 position of a match
 

 Key: XERCESC-1910
 URL: https://issues.apache.org/jira/browse/XERCESC-1910
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.0.1
 Environment: Windows
Reporter: Steve Roberts
 Fix For: 3.1.0


 We have recently upgraded from version 2.2.0 to version 3.0.1. Between these 
 versions a change was made to the RegularExpression::matchUnion function, so 
 that it now uses a local version of the context structure. The result of this 
 is that the 'fMatch' member of the context can be changed from its original 
 instance. Therefore, back in the RegularExpression::matches function, just 
 before it returns, it sets the start and end position of the match:
 context.fMatch-setStartPos(0, (int)matchStart);
 context.fMatch-setEndPos(0, matchEnd);
 However, the 'fMatch' object no longer matches the one that was passed 
 through to function (due to what happened in 'matchUnion') and therefore 
 these values don't get returned to the calling function.
 Therefore, I think that in the 'matches' function is should actually be 
 setting the start and end position of the 'pMatch' property that is passed 
 into the function, rather than the 'context.fMatch'.
 The code we are using to call the regular expression is this:
   XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
   if( re.matches( text, match ) )
   { ...
 where expression = ([\-\(]?\d{1,3}([, 
 ]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
 and text = 13.13

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1910.



Assuming this is fixed since 3.1.0.

 The RegularExpression 'matches' function no longer returns the start and end 
 position of a match
 

 Key: XERCESC-1910
 URL: https://issues.apache.org/jira/browse/XERCESC-1910
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.0.1
 Environment: Windows
Reporter: Steve Roberts
 Fix For: 3.1.0


 We have recently upgraded from version 2.2.0 to version 3.0.1. Between these 
 versions a change was made to the RegularExpression::matchUnion function, so 
 that it now uses a local version of the context structure. The result of this 
 is that the 'fMatch' member of the context can be changed from its original 
 instance. Therefore, back in the RegularExpression::matches function, just 
 before it returns, it sets the start and end position of the match:
 context.fMatch-setStartPos(0, (int)matchStart);
 context.fMatch-setEndPos(0, matchEnd);
 However, the 'fMatch' object no longer matches the one that was passed 
 through to function (due to what happened in 'matchUnion') and therefore 
 these values don't get returned to the calling function.
 Therefore, I think that in the 'matches' function is should actually be 
 setting the start and end position of the 'pMatch' property that is passed 
 into the function, rather than the 'context.fMatch'.
 The code we are using to call the regular expression is this:
   XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
   if( re.matches( text, match ) )
   { ...
 where expression = ([\-\(]?\d{1,3}([, 
 ]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
 and text = 13.13

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1916) TranscodeFromStr fails with invalid UTF8 encoded strings

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1916:
-

Fix Version/s: 3.2.0
   (was: 3.0.1)
  Component/s: Utilities
   (was: DOM)

Scheduling for 3.2.0.

 TranscodeFromStr fails with invalid UTF8 encoded strings
 

 Key: XERCESC-1916
 URL: https://issues.apache.org/jira/browse/XERCESC-1916
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
 Environment: WIN32, Solaris32
Reporter: Kristian Ivarsson
 Fix For: 3.2.0


 If you got an invalid encoded UTF-8-sequence, the TranscodeFromStr ends up by 
 throwing a OutOfMemoryException and if you use XMLTranscoder::transcodeFrom() 
 directly you'll somehow probably end up in a loop that never ends, 'cause it 
 stops to consume/eat bytes. Shouldn't there be some 
 InvalidEncodingException instead ?
 ...
 const char string[] = HÖPP;
 const int size = strlen( string);
 xercesc::TranscodeFromStr transcoder( reinterpret_castconst XMLByte 
 *(string), size, UTF8);
 // OutOfMemoryException

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1918) XInclude broken with multiple level includes

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1918:
-

Fix Version/s: 3.1.1
   3.2.0

Scheduling for 3.1.1.

 XInclude broken with multiple level includes
 

 Key: XERCESC-1918
 URL: https://issues.apache.org/jira/browse/XERCESC-1918
 Project: Xerces-C++
  Issue Type: Bug
  Components: Non-Validating Parser
Affects Versions: 3.0.0
 Environment: linux, windows
Reporter: keith mcneill
 Fix For: 3.1.1, 3.2.0

 Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, 
 xinclude-middle.xml, xinclude-top.xml


 If you use xinclude on multiple levels ( 2) with relative path names.  
 XInclude will break with an error something like no scheme.
 I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude.
 When an includeDoc was found it created a DocumentFragment to hang the new 
 copied nodes off of.  At the end of processing it would paste the 
 DocumentFragment on to the document.  The problem was that DocumentFragment 
 lost the absolute path in its getBaseURI().  This absolute path also 
 contained the scheme.
 This diff fixes XInclude by not using a DocumentFragment.  We just use 
 insertBefore() to insert the new nodes in the destination document in order.  
 This way the getBaseURI() is never lost.
 I've also included a fix to XIncludeLocation.prependPath().  PrependPath used 
 to slam a new path on the beginning of the current path without checking to 
 see if the current path already had a scheme.  For example you could end up 
 with paths like:  file:///new/parent/file:///old/child.  Now it will produce 
 file:///new/parent/old/child.  XIncludeLocation probably needs to get smarter 
 about dealing with schemes  URI's in general.
 I've included a diff an example files that can be run with the XInclude 
 sample. 
 Note that with these fixes the xerces c++ xinclude behaves more like the java 
 xinclude support.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1914) SEnumVal does not produce correct output

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1914:
-

Fix Version/s: 3.1.1
   3.2.0

Need to check what's going on here.

 SEnumVal does not produce correct output
 

 Key: XERCESC-1914
 URL: https://issues.apache.org/jira/browse/XERCESC-1914
 Project: Xerces-C++
  Issue Type: Bug
  Components: Samples/Tests
Affects Versions: 3.1.0
 Environment: Windows
Reporter: David Burrell
 Fix For: 3.1.1, 3.2.0


 SEnumVal does not produce correct output. Our application relies on the 
 ability to enumerate the grammar. The last release that worked correctly was 
 2.3.0.
 We cannot upgrade to any later version until we find a solution to this 
 problem.
 The main problem is that the content model appears to be incorrect. This can 
 be seen by comparing formatted content models produced by SEnumVal.
 Here is partial output from SEnumVal, comparing 2.3.0 with 3.1.0...
 xerces-c 2.3.0: (showing correct output)
 
 Name: category
 Model Type:   Children
 Create Reason:Declared
 ContentType:  OneOrMore
 Content Model:(severity)+
 ComplexType:
   TypeName:   ,C2
   ContentType:OneOrMore
 Attributes:
   Name:   name
   Type:   CDATA
   Default Type:   #REQUIRED
   Base Datatype:  string
   Name:   categoryCode
   Type:   CDATA
   Default Type:   #REQUIRED
   Base Datatype:  string
 Enumeration:  
   0
   1
   2
 
 3.1.0: ( incorrect - content model should be '(severity)+' )
 
 Name: category
 Model Type:   Children
 Create Reason:Declared
 ContentType:  ModelGroupSequence
 Content Model:(severity,)
 ComplexType:
   TypeName:   ,__AnonC2
   ContentType:ModelGroupSequence
 Attributes:
   Name:   categoryCode
   Type:   CDATA
   Default Type:   #REQUIRED
   Base Datatype:  string
 Enumeration:  
   0
   1
   2
   Name:   name
   Type:   CDATA
   Default Type:   #REQUIRED
   Base Datatype:  string
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1785) Build and test on all supported platforms

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1785:
-

Fix Version/s: 3.2.0
   (was: 3.1.0)

 Build and test on all supported platforms
 -

 Key: XERCESC-1785
 URL: https://issues.apache.org/jira/browse/XERCESC-1785
 Project: Xerces-C++
  Issue Type: Task
  Components: Build
Reporter: Boris Kolpackov
Priority: Blocker
 Fix For: 3.2.0


 We need to make sure that building, testing and installation work on all 
 platforms that we have committed to support. See the following Wiki page for 
 the status:
 http://wiki.apache.org/xerces/XercescBuildStatus

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1907:
-

Fix Version/s: 3.1.1
   3.2.0

Scheduling for 3.1.1

 PDB file name for static 64-bit debug builds in VC8 and VC9 project files are 
 not library specific
 --

 Key: XERCESC-1907
 URL: https://issues.apache.org/jira/browse/XERCESC-1907
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: Windows
Reporter: Boris Kolpackov
Priority: Minor
 Fix For: 3.1.1, 3.2.0


 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are 
 still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not 
 for 64-bit, for some reason.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org




[jira] Closed: (XERCESC-1912) Conflicting includes cpuid.h and intrin.h (both define __cpuid)

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1912.


  Assignee: Boris Kolpackov
Resolution: Fixed

Fix is in SVN.

 Conflicting includes cpuid.h and intrin.h (both define __cpuid)
 ---

 Key: XERCESC-1912
 URL: https://issues.apache.org/jira/browse/XERCESC-1912
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: GCC 4.4 (mingw) with mingw-w64 environment (64-bit, 
 cross-compiling under Debian GNU/Linux)
Reporter: Tommi Vainikainen
Assignee: Boris Kolpackov
Priority: Minor
 Fix For: 3.1.1, 3.2.0


 GCC (since 4.3 AFAIK) contains cpuid.h which defines _get_cpuid(...) and 
 __cpuid(level, a, b, c, d).
 intrin.h is Windows-API which defines __cpuid(int CPUInfo[4], int InfoType)
 Definitions of __cpuid are clearly not compatible.
 However when cross-compiling with GCC-mingw for Windows, configure script 
 detects existence of both cpuid.h and intrin.h and includes both in 
 PlatformUtils.cpp
 Following trivial patch workarounds this problem.
 diff -ur xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 
 xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp
 --- xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 2009-08-28 
 16:21:24.0 +0300
 +++ xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp 2010-02-15 
 11:16:33.0 +0200
 @@ -37,7 +37,7 @@
  #if HAVE_SYS_TIMEB_H
  #include sys/timeb.h
  #endif
 -#if HAVE_CPUID_H
 +#if HAVE_CPUID_H  !XERCES_HAVE_INTRIN_H
  #   include cpuid.h
  #endif
  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1911) spelling fixes for xerces

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1911.


  Assignee: Boris Kolpackov
Resolution: Fixed

Changes are in SVN. Note also that there were a couple of wrong/incomplete 
fixes in the provided patch.

 spelling fixes for xerces
 -

 Key: XERCESC-1911
 URL: https://issues.apache.org/jira/browse/XERCESC-1911
 Project: Xerces-C++
  Issue Type: Bug
Reporter: timeless
Assignee: Boris Kolpackov
Priority: Trivial
 Fix For: 3.1.1, 3.2.0

 Attachments: 12456044


 I was running a spelling fix process against a Symbian repository and 
 discovered that a portion of the changes was to Xerces, so I'm trying to 
 deliver the spelling fixes here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1907.


  Assignee: Boris Kolpackov
Resolution: Fixed

Fix is in SVN.

 PDB file name for static 64-bit debug builds in VC8 and VC9 project files are 
 not library specific
 --

 Key: XERCESC-1907
 URL: https://issues.apache.org/jira/browse/XERCESC-1907
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: Windows
Reporter: Boris Kolpackov
Assignee: Boris Kolpackov
Priority: Minor
 Fix For: 3.1.1, 3.2.0


 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are 
 still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not 
 for 64-bit, for some reason.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1918) XInclude broken with multiple level includes

2010-04-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1918.


  Assignee: Boris Kolpackov
Resolution: Fixed

I have re-implemented the patch and committed it. Also fixed a few bugs and 
memory leaks in XInclude code while at it.

 XInclude broken with multiple level includes
 

 Key: XERCESC-1918
 URL: https://issues.apache.org/jira/browse/XERCESC-1918
 Project: Xerces-C++
  Issue Type: Bug
  Components: Non-Validating Parser
Affects Versions: 3.0.0
 Environment: linux, windows
Reporter: keith mcneill
Assignee: Boris Kolpackov
 Fix For: 3.1.1, 3.2.0

 Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, 
 xinclude-middle.xml, xinclude-top.xml


 If you use xinclude on multiple levels ( 2) with relative path names.  
 XInclude will break with an error something like no scheme.
 I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude.
 When an includeDoc was found it created a DocumentFragment to hang the new 
 copied nodes off of.  At the end of processing it would paste the 
 DocumentFragment on to the document.  The problem was that DocumentFragment 
 lost the absolute path in its getBaseURI().  This absolute path also 
 contained the scheme.
 This diff fixes XInclude by not using a DocumentFragment.  We just use 
 insertBefore() to insert the new nodes in the destination document in order.  
 This way the getBaseURI() is never lost.
 I've also included a fix to XIncludeLocation.prependPath().  PrependPath used 
 to slam a new path on the beginning of the current path without checking to 
 see if the current path already had a scheme.  For example you could end up 
 with paths like:  file:///new/parent/file:///old/child.  Now it will produce 
 file:///new/parent/old/child.  XIncludeLocation probably needs to get smarter 
 about dealing with schemes  URI's in general.
 I've included a diff an example files that can be run with the XInclude 
 sample. 
 Note that with these fixes the xerces c++ xinclude behaves more like the java 
 xinclude support.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Problem writing large XML file

2010-04-08 Thread Boris Kolpackov
Hi Vladimir,

Vladimir Loubenski vloub...@opentext.com writes:

 I have large amount of data (more than computer RAM) that I need to
 wrote to XML file. How can I do that?

There is no out of the box support for this in Xerces-C++. What you
can do is create and serialize DOM fragments one at a time. In XSD[1]
we have an example called streaming (examples/cxx/tree/streaming/)
that shows how to do this.

[1] http://codesynthesis.com/products/xsd/

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1918) XInclude broken with multiple level includes

2010-03-31 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852089#action_12852089
 ] 

Boris Kolpackov commented on XERCESC-1918:
--

Keith, thanks for the patch. I would like to commit it, however, the project's 
charter[1] requires me to get the answers to the following questions from you 
before I can do this:

a) Name and employer

b) Are you the author of the code being contributed?

c) Do you have the right to grant the copyright and patent licenses for the 
contribution that are set forth in the ASF v.2.0 license 
(http://www.apache.org/licenses/LICENSE-2.0)?

d) Does your employer have any rights to code that you have written, for 
example, through your contract for employment? If so, has your employer given 
you permission to contribute the code on its behalf or waived its rights in the 
code?

e) Are you aware of any third-party licenses or other restrictions (such as 
related patents or trademarks) that could apply to your contribution? If so, 
what are they? 

If you can provide the answers as a comment for this issue, that would be great.

[1] http://xerces.apache.org/xerces-c/charter.html


 XInclude broken with multiple level includes
 

 Key: XERCESC-1918
 URL: https://issues.apache.org/jira/browse/XERCESC-1918
 Project: Xerces-C++
  Issue Type: Bug
  Components: Non-Validating Parser
Affects Versions: 3.0.0
 Environment: linux, windows
Reporter: keith mcneill
 Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, 
 xinclude-middle.xml, xinclude-top.xml


 If you use xinclude on multiple levels ( 2) with relative path names.  
 XInclude will break with an error something like no scheme.
 I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude.
 When an includeDoc was found it created a DocumentFragment to hang the new 
 copied nodes off of.  At the end of processing it would paste the 
 DocumentFragment on to the document.  The problem was that DocumentFragment 
 lost the absolute path in its getBaseURI().  This absolute path also 
 contained the scheme.
 This diff fixes XInclude by not using a DocumentFragment.  We just use 
 insertBefore() to insert the new nodes in the destination document in order.  
 This way the getBaseURI() is never lost.
 I've also included a fix to XIncludeLocation.prependPath().  PrependPath used 
 to slam a new path on the beginning of the current path without checking to 
 see if the current path already had a scheme.  For example you could end up 
 with paths like:  file:///new/parent/file:///old/child.  Now it will produce 
 file:///new/parent/old/child.  XIncludeLocation probably needs to get smarter 
 about dealing with schemes  URI's in general.
 I've included a diff an example files that can be run with the XInclude 
 sample. 
 Note that with these fixes the xerces c++ xinclude behaves more like the java 
 xinclude support.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Help validating XML against an XSD?

2010-03-16 Thread Boris Kolpackov
Hi Scott,

Scott Cantor canto...@osu.edu writes:

 At least with imports, I suppose that in the absence of circular references,
 one could strip the import statements of their paths and preload in the
 order needed to resolve the imports, but that won't help with includes.

This would only be necessary if schemas used absolute paths/URL to
include/import other schemas. In my experience, most sane schemas 
use relative paths to include/import files inside the vocabulary 
and would only use absolute URLs to import external vocabularies.

In such cases, as you suggest, loading external schemas explicitly 
first and then loading the dependant schemas works fairly well.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Help validating XML against an XSD?

2010-03-15 Thread Boris Kolpackov
Hi Timothy,

Stone, Timothy M tst...@ida.org writes:

 Hm, I've given it some offort, but cannot seem to get it going.  I have a
 .xsd and a .xml file, and I just want to test if the XML is compliant with
 the XSD.

Seeing that this is becoming sort of a FAQ (though without a good answer),
I have written a little post plus included a couple of examples that you
may find useful:

http://www.codesynthesis.com/~boris/blog/2010/03/15/validating-external-schemas-xerces-cxx/

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Help validating XML against an XSD?

2010-03-15 Thread Boris Kolpackov
Hi,

Scott Cantor canto...@osu.edu writes:

  Another simple way to achieve the same is setting the
  fgXercesSchemaExternalSchemaLocation and
  fgXercesSchemaExternalNoNameSpaceSchemaLocation parameters (or using
  setExternalSchemaLocation and setExternalNoNamespaceSchemaLocation
  methods if available).
 
 [...]
 
 But it's also important to note that naively using those options won't work
 either, because (in what I've always considered a buggy feature, though
 it's probably to spec) those overrides only apply to the schema lookup
 *within* the XML instance being validated, and NOT to any lookup of imported
 schemas in the schemas you pull in. They only go one layer deep, in other
 words.

The other problem with this approach is that the resolution of the
paths is relative to the document path unless they are absolute
URI qualified with 'file://' or similar.


 So a complete solution (in code) really has to register an EntityResolver
 and fully hijack the whole mechanism in some brittle ways, unfortunately.

If you are using a fairly-recent version of Xerces-C++ (i.e., 3.0.0 or
later) then a much simpler and more robust solution is as described
in the blog mentioned above.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Help validating XML against an XSD?

2010-03-15 Thread Boris Kolpackov
Hi Scott,

Scott Cantor canto...@osu.edu writes:

 I think I know the answer, but is the fgXercesLoadSchema feature new in 3.x?

Yes, it is available since 3.0.0.


 I seem to recall finding no reliable way to prevent it from following
 imports in dependent schemas in the past without registering my own 
 resolver and playing some games, so my strategy has been to register 
 the namespace - entity mappings in various ways, rather than 
 registering and loading schemas directly like your sample does.

fgXercesLoadSchema won't prevent loading imported/included schemas
that are referenced from schemas that you explicitly load with the
loadGrammar() calls. Only schemas that are specified in the XML
documents.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: DOM Level 3 Validation

2010-03-04 Thread Boris Kolpackov
Hi Tobias,

Tobias Stadler ts.stad...@gmx.de writes:

 are there any plans on implementing DOM Level 3 Validation support?

No, there are no plans to implement this specification, as far as I
know. Depending on which features you need, you may be able to emulate
some of that functionality using PSVI.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1917) GCCDefs str[n]icmp prototype and symbol exposure

2010-02-24 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1917:
-

  Priority: Minor  (was: Major)
Issue Type: Improvement  (was: Bug)

FYI, there are no plans to release any more versions in the 2-series. In the 
3-series we use a similar workaround but in a cross-platform way, so this patch 
is not easily applicable. Also, what is the problem with having these symbols 
visible in the Xerces-C++ library?

 GCCDefs str[n]icmp prototype and symbol exposure
 

 Key: XERCESC-1917
 URL: https://issues.apache.org/jira/browse/XERCESC-1917
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build
Affects Versions: 2.8.0
 Environment: linux x86_64 gcc
Reporter: George Gensure
Priority: Minor

 The stricmp and strnicmp prototypes provided as a workaround for those 
 functions missing in gcc/glibc installations are defined in the global scope 
 and without extern C qualifiers.  As a result, these are the *only* 
 non-xerces_2_8 namespaced functions exposed by the shared library on linux.  
 I recognize that the compiler workarounds are included prior to the xercesc 
 namespace definition, and as a compromise I'd be happy to see the definitions 
 have their prototypes changed to be within an extern C block, as well as 
 __attribute__((visibility(hidden))) applied to their definitions.  The 
 following diff applies cleanly to the 2.8 release and corrects my problem:
 --- src/xercesc/util/Compilers/GCCDefs.hpp
 +++ src/xercesc/util/Compilers/GCCDefs.hpp
 @@ -130,8 +130,10 @@
  #if !defined(__CYGWIN__)  !defined(__MINGW32__)
 +extern C {
  int stricmp(const char* const str1, const char* const  str2);
  int strnicmp(const char* const str1, const char* const  str2, const unsigned 
 int count);
 +}
  #endif // ! __CYGWIN__
 --- src/xercesc/util/Compilers/GCCDefs.cpp
 +++ src/xercesc/util/Compilers/GCCDefs.cpp
 @@ -33,11 +33,13 @@
  #if !defined(__CYGWIN__)  !defined(__MINGW32__)
 +__attribute__((visibility(hidden)))
  int stricmp(const char* const str1, const char* const  str2)
  {
   return strcasecmp(str1, str2);
  }
 +__attribute__((visibility(hidden)))
  int strnicmp(const char* const str1, const char* const  str2, const unsigned 
 int count)
  {
   if (count == 0)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1915) Segmentation fault in getPooledString

2010-02-24 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1915.


Resolution: Invalid

This is a problem in XL C++ optimizer as explained in one of the comments for 
XERCESC-1904. The workaround is to add -qalias=noansi. 

 Segmentation fault in getPooledString
 -

 Key: XERCESC-1915
 URL: https://issues.apache.org/jira/browse/XERCESC-1915
 Project: Xerces-C++
  Issue Type: Bug
  Components: DOM
Affects Versions: 2.7.0
 Environment: AIX 6.1, powerpc, IBM XL C/C++ for AIX, V10.1
Reporter: Olov Brötell
Priority: Blocker

 Segmentation fault in getPooledString after call to 'createSPE'. 
 -
 ...
 // This string hasn't been seen before.  Add it to the pool.
 *pspe = spe = createSPE(in, fDoc);
 return spe-fString;
 }
 -
 Reproducible in my environment *unless* built with debugging symbols (-d).
 Steps to reproduce:
 - build xerces-c_2_7_0 on AIX 6.1 with IBM XL C/C++ for AIX, V10.1 (32 or 64 
 bit)
 - build sample programs
 - execute for example CreateDOMDocument to get segfault
 $dbx -d 1 -C core
 Type 'help' for help.
 [Object file is not specified. Using CreateDOMDocument as an object file]
 warning: The core file is not a fullcore. Some info may
 not be available.
 [using memory image in core]
 reading symbolic information ...
 Segmentation fault in getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs 
 at 0xd50d8e24
 0xd50d8e24 (getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs+0xa4) 
 907f stw   r3,0x0(r31)
 (dbx) where
 getPooledString__Q2_11xercesc_2_713DOMStringPoolFPCUs() at 0xd50d8e24
 DOMDocumentImpl.getPooledString(const unsigned short*)() at 0xd4e88d70
 DOMElementImpl.DOMElementImpl(xercesc_2_7::DOMDocument*,const unsigned 
 short*)() at 0xd50e8fa8
 DOMElementNSImpl.DOMElementNSImpl(xercesc_2_7::DOMDocument*,const unsigned 
 short*,const unsigned short*)() at 0xd50e77a4
 DOMDocumentImpl.createElementNS(const unsigned short*,const unsigned 
 short*)() at 0xd4e7aec4
 DOMDocumentImpl.DOMDocumentImpl(const unsigned short*,const unsigned 
 short*,xercesc_2_7::DOMDocumentType*,xercesc_2_7::MemoryManager
 *)() at 0xd4e7acf0
 DOMImplementationImpl.createDocument(const unsigned short*,const unsigned 
 short*,xercesc_2_7::DOMDocumentType*,xercesc_2_7::MemoryMa
 nager*)() at 0xd4e908c4
 unnamed block in main(argC = 1,  = /\362)^P), line 140 in 
 CreateDOMDocument.cpp
 unnamed block in main(argC = 1,  = /\362)^P), line 140 in 
 CreateDOMDocument.cpp
 main(argC = 1,  = /\362)^P), line 140 in CreateDOMDocument.cpp

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1913) Change to importNode to copy prefixes breaks when xmlns= is present

2010-02-17 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1913:
-

Fix Version/s: 3.2.0
   3.1.1

 Change to importNode to copy prefixes breaks when xmlns= is present
 -

 Key: XERCESC-1913
 URL: https://issues.apache.org/jira/browse/XERCESC-1913
 Project: Xerces-C++
  Issue Type: Bug
  Components: DOM
Affects Versions: 3.1.0
 Environment: Affects all platforms
Reporter: Scott Cantor
 Fix For: 3.1.1, 3.2.0


 A change to importNode was made to copy over prefixes of nodes with non-empty 
 namespaces, using setPrefix. This causes setPrefix to throw a DOMException if 
 called on the default namespace declaration node (xmlns=) because it checks 
 for that explicitly.
 The revised fix should check for that case in one of the two spots, probably 
 in setPrefix by ignoring the issue when the prefix supplied is NULL.
 Mailing list thread here:
 http://marc.info/?t=12662079471r=1w=2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1913) Change to importNode to copy prefixes breaks when xmlns= is present

2010-02-17 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1913.


Resolution: Fixed
  Assignee: Boris Kolpackov

Fix is in the trunk and in the 3.1.1 branch.

 Change to importNode to copy prefixes breaks when xmlns= is present
 -

 Key: XERCESC-1913
 URL: https://issues.apache.org/jira/browse/XERCESC-1913
 Project: Xerces-C++
  Issue Type: Bug
  Components: DOM
Affects Versions: 3.1.0
 Environment: Affects all platforms
Reporter: Scott Cantor
Assignee: Boris Kolpackov
 Fix For: 3.1.1, 3.2.0


 A change to importNode was made to copy over prefixes of nodes with non-empty 
 namespaces, using setPrefix. This causes setPrefix to throw a DOMException if 
 called on the default namespace declaration node (xmlns=) because it checks 
 for that explicitly.
 The revised fix should check for that case in one of the two spots, probably 
 in setPrefix by ignoring the issue when the prefix supplied is NULL.
 Mailing list thread here:
 http://marc.info/?t=12662079471r=1w=2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Possible conflict in 3.1 between importNode and setPrefix

2010-02-17 Thread Boris Kolpackov
Hi Scott,

Scott Cantor canto...@osu.edu writes:

 It would work if the setPrefix method was altered to check for NULL before
 throwing the exception.

The thing is the create* functions in each case are passed qualified names
so they set the correct prefix, according to my tests. Unfortunately, the
test that led to the original fix cannot be found. So I think it is safest 
to revert the change.


 Doing that now. The Debian packaging folks indicated to me informally that
 it would help them justify a downstream patch to 3.1.0 if there were a patch
 checked in on the branch. Do you plan to do that soon?

Done. Use the 3.1 branch for the 3.1.0 bugfixes.

Boris


-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Possible conflict in 3.1 between importNode and setPrefix

2010-02-16 Thread Boris Kolpackov
Hi Scott,

Scott Cantor canto...@osu.edu writes:

 The patch backs out the change, from the look of it. What was the change
 intended to address?

There was a test case reported on the XQilla mailing list which 
showed that qualified elements would loose their prefixes during
import. As a result, the explicit call to setPrefix was added for
elements and, just to be sure, I assume, for attributes. The change
for attributes was a bad idea since it doesn't work for the xmlns=
attributes.


 Is the bug in Jira, by the way? I'm not finding it. I have some downstream
 packagers that would be served by having it filed, so I can take care of
 that if it's needed.

There is no Jira issue. Feel free to create one, though.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Possible conflict in 3.1 between importNode and setPrefix

2010-02-15 Thread Boris Kolpackov
Hi Scott,

This is a known bug. I also have a patch:

http://www.codesynthesis.com/~boris/tmp/xerces-c-3.1.0-dom-import.patch

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match

2010-02-15 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1910:
-

Fix Version/s: 3.2.0
   3.1.1

Scheduling for 3.1.1 and 3.2.0. Proposed fix is in the c-dev archives.

 The RegularExpression 'matches' function no longer returns the start and end 
 position of a match
 

 Key: XERCESC-1910
 URL: https://issues.apache.org/jira/browse/XERCESC-1910
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.0.1
 Environment: Windows
Reporter: Steve Roberts
 Fix For: 3.1.1, 3.2.0


 We have recently upgraded from version 2.2.0 to version 3.0.1. Between these 
 versions a change was made to the RegularExpression::matchUnion function, so 
 that it now uses a local version of the context structure. The result of this 
 is that the 'fMatch' member of the context can be changed from its original 
 instance. Therefore, back in the RegularExpression::matches function, just 
 before it returns, it sets the start and end position of the match:
 context.fMatch-setStartPos(0, (int)matchStart);
 context.fMatch-setEndPos(0, matchEnd);
 However, the 'fMatch' object no longer matches the one that was passed 
 through to function (due to what happened in 'matchUnion') and therefore 
 these values don't get returned to the calling function.
 Therefore, I think that in the 'matches' function is should actually be 
 setting the start and end position of the 'pMatch' property that is passed 
 into the function, rather than the 'context.fMatch'.
 The code we are using to call the regular expression is this:
   XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
   if( re.matches( text, match ) )
   { ...
 where expression = ([\-\(]?\d{1,3}([, 
 ]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
 and text = 13.13

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1911) spelling fixes for xerces

2010-02-15 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1911:
-

Fix Version/s: 3.2.0
   3.1.1

Scheduling for 3.1.1 and 3.2.0. Thanks for the patch!



 spelling fixes for xerces
 -

 Key: XERCESC-1911
 URL: https://issues.apache.org/jira/browse/XERCESC-1911
 Project: Xerces-C++
  Issue Type: Bug
Reporter: timeless
Priority: Trivial
 Fix For: 3.1.1, 3.2.0

 Attachments: 12456044


 I was running a spelling fix process against a Symbian repository and 
 discovered that a portion of the changes was to Xerces, so I'm trying to 
 deliver the spelling fixes here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Updated: (XERCESC-1912) Conflicting includes cpuid.h and intrin.h (both define __cpuid)

2010-02-15 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov updated XERCESC-1912:
-

Fix Version/s: 3.2.0
   3.1.1

Scheduling for 3.1.1 and 3.2.0. Thanks for the patch!

 Conflicting includes cpuid.h and intrin.h (both define __cpuid)
 ---

 Key: XERCESC-1912
 URL: https://issues.apache.org/jira/browse/XERCESC-1912
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: GCC 4.4 (mingw) with mingw-w64 environment (64-bit, 
 cross-compiling under Debian GNU/Linux)
Reporter: Tommi Vainikainen
Priority: Minor
 Fix For: 3.1.1, 3.2.0


 GCC (since 4.3 AFAIK) contains cpuid.h which defines _get_cpuid(...) and 
 __cpuid(level, a, b, c, d).
 intrin.h is Windows-API which defines __cpuid(int CPUInfo[4], int InfoType)
 Definitions of __cpuid are clearly not compatible.
 However when cross-compiling with GCC-mingw for Windows, configure script 
 detects existence of both cpuid.h and intrin.h and includes both in 
 PlatformUtils.cpp
 Following trivial patch workarounds this problem.
 diff -ur xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 
 xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp
 --- xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 2009-08-28 
 16:21:24.0 +0300
 +++ xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp 2010-02-15 
 11:16:33.0 +0200
 @@ -37,7 +37,7 @@
  #if HAVE_SYS_TIMEB_H
  #include sys/timeb.h
  #endif
 -#if HAVE_CPUID_H
 +#if HAVE_CPUID_H  !XERCES_HAVE_INTRIN_H
  #   include cpuid.h
  #endif
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match

2010-02-11 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832466#action_12832466
 ] 

Boris Kolpackov commented on XERCESC-1910:
--

Steve, do I understand you correctly in that you are saying that certain 
functionality (that you used to rely on) has been removed between the two 
version as opposed to that there is a bug that affects the current version?

 The RegularExpression 'matches' function no longer returns the start and end 
 position of a match
 

 Key: XERCESC-1910
 URL: https://issues.apache.org/jira/browse/XERCESC-1910
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.0.1
 Environment: Windows
Reporter: Steve Roberts

 We have recently upgraded from version 2.2.0 to version 3.0.1. Between these 
 versions a change was made to the RegularExpression::matchUnion function, so 
 that it now uses a local version of the context structure. The result of this 
 is that the 'fMatch' member of the context can be changed from its original 
 instance. Therefore, back in the RegularExpression::matches function, just 
 before it returns, it sets the start and end position of the match:
 context.fMatch-setStartPos(0, (int)matchStart);
 context.fMatch-setEndPos(0, matchEnd);
 However, the 'fMatch' object no longer matches the one that was passed 
 through to function (due to what happened in 'matchUnion') and therefore 
 these values don't get returned to the calling function.
 Therefore, I think that in the 'matches' function is should actually be 
 setting the start and end position of the 'pMatch' property that is passed 
 into the function, rather than the 'context.fMatch'.
 The code we are using to call the regular expression is this:
   XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
   if( re.matches( text, match ) )
   { ...
 where expression = ([\-\(]?\d{1,3}([, 
 ]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
 and text = 13.13

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Closed: (XERCESC-1908) Xerces-c SAX application crashed on Solaris 10 x64

2010-02-11 Thread Boris Kolpackov (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Boris Kolpackov closed XERCESC-1908.


Resolution: Invalid

I am assuming this is a toolchain problem and closing this issue. If there is 
new information pointing to Xerces-C++, please reopen it.

 Xerces-c SAX application crashed on Solaris 10 x64
 --

 Key: XERCESC-1908
 URL: https://issues.apache.org/jira/browse/XERCESC-1908
 Project: Xerces-C++
  Issue Type: Bug
  Components: SAX/SAX2
Affects Versions: 2.7.0, 2.8.0, 3.0.0, 3.0.1
 Environment: $uname -a
 SunOS xsol-qa1 5.10 Generic_137138-09 i86pc i386 i86pc
 $CC -V
 CC: Sun C++ 5.7 2005/01/07
Reporter: Bill Fu
 Attachments: config.tar.gz, sample test result.jpg, 
 testsax_64so.tar.gz


 This issue just happens on Solaris 10 x64. There is no problem on other 
 platforms, such as Solaris 10 x86 (32-bit), AIX (both 32 and 64), HP-UX (both 
 PA-RISC and IA64), Linux x86 etc.
 I wrote a xerces-c sax application on Solaris 10 x64. The class MXmlHandler 
 was the xml handler what was inherited from DefaultHandeler.
 The following is the compiler and linker flags.
 Compiler flags: -mt -xarch=amd64 -g -I/usr/app/xercesc/2.8/include 
 Linker flags: -mt -xarch=amd64 -L/usr/app/xercesc/2.8/lib -lxerces-c
 At the begining of the method
   void startElement(  const   XMLCh* consturi,
   const   XMLCh* constlocalname,
   const   XMLCh* constqname,
   const   Attributes attributes);
 the value of the parameter qname was wrong. For example the qname should be 
 a string like schemaName, but it was a recognised string. This is the 
 behavior in RELEASE libraries. In the DEBUG mode, the application crashed in 
 xerces-c libraries.
 The following is traceback.
 =[1] xercesc_2_8::XMLAttr::getValue(this = 0x18), line 486 in XMLAttr.hpp
   [2] xercesc_2_8::VecAttrListImpl::getValue(this = 0x4cc3e8, index = 1U), 
 line 86 in VecAttrListImpl.cpp
   [3] 0xfd7ffeab6546(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffeab6545
   [4] xercesc_2_8::SAXParser::startElement(this = 0x4cc3a8, elemDecl = CLASS, 
 elemURLId = 1U, elemPrefix = 0xfd7ffe1bb3b0, attrList = CLASS, attrCount 
 = 2U, isEmpty = false, isRoot = true), line 971 in SAXParser.cpp
   [5] xercesc_2_8::IGXMLScanner::scanStartTag(this = 0x4cd6b8, gotData = 
 true), line 2101 in IGXMLScanner.cpp
   [6] xercesc_2_8::IGXMLScanner::scanContent(this = 0x4cd6b8), line 899 in 
 IGXMLScanner.cpp
   [7] xercesc_2_8::IGXMLScanner::scanDocument(this = 0x4cd6b8, src = CLASS), 
 line 215 in IGXMLScanner.cpp
   [8] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 
 0x4d4530), line 460 in XMLScanner.cpp
   [9] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 
 0x4c7f68 ../dats/adr3xml.dat), line 468 in XMLScanner.cpp
   [10] xercesc_2_8::SAXParser::parse(this = 0x4cc3a8, systemId = 0x4c7f68 
 ../dats/adr3xml.dat), line 587 in SAXParser.cpp

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] Commented: (XERCESC-1908) Xerces-c SAX application crashed on Solaris 10 x64

2010-02-04 Thread Boris Kolpackov (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829590#action_12829590
 ] 

Boris Kolpackov commented on XERCESC-1908:
--

Bill, I tried your test case on Solaris 10 x86-64 with Sun CC 5.10 (I don't 
have access to 5.7 at the moment) and Xerces-C++ 3.1.0 (I used a pre-built 
library from the website) . Both test cases (pic and non-pic) print the 
expected result. So I think this is either a compiler issue or there is 
something special about your setup. Can you download the latest version of Sun 
CC (can be installed side-by-side with older versions) and see if you still get 
the same problem?

 Xerces-c SAX application crashed on Solaris 10 x64
 --

 Key: XERCESC-1908
 URL: https://issues.apache.org/jira/browse/XERCESC-1908
 Project: Xerces-C++
  Issue Type: Bug
  Components: SAX/SAX2
Affects Versions: 2.7.0, 2.8.0, 3.0.0, 3.0.1
 Environment: $uname -a
 SunOS xsol-qa1 5.10 Generic_137138-09 i86pc i386 i86pc
 $CC -V
 CC: Sun C++ 5.7 2005/01/07
Reporter: Bill Fu
 Attachments: config.tar.gz, sample test result.jpg, 
 testsax_64so.tar.gz


 This issue just happens on Solaris 10 x64. There is no problem on other 
 platforms, such as Solaris 10 x86 (32-bit), AIX (both 32 and 64), HP-UX (both 
 PA-RISC and IA64), Linux x86 etc.
 I wrote a xerces-c sax application on Solaris 10 x64. The class MXmlHandler 
 was the xml handler what was inherited from DefaultHandeler.
 The following is the compiler and linker flags.
 Compiler flags: -mt -xarch=amd64 -g -I/usr/app/xercesc/2.8/include 
 Linker flags: -mt -xarch=amd64 -L/usr/app/xercesc/2.8/lib -lxerces-c
 At the begining of the method
   void startElement(  const   XMLCh* consturi,
   const   XMLCh* constlocalname,
   const   XMLCh* constqname,
   const   Attributes attributes);
 the value of the parameter qname was wrong. For example the qname should be 
 a string like schemaName, but it was a recognised string. This is the 
 behavior in RELEASE libraries. In the DEBUG mode, the application crashed in 
 xerces-c libraries.
 The following is traceback.
 =[1] xercesc_2_8::XMLAttr::getValue(this = 0x18), line 486 in XMLAttr.hpp
   [2] xercesc_2_8::VecAttrListImpl::getValue(this = 0x4cc3e8, index = 1U), 
 line 86 in VecAttrListImpl.cpp
   [3] 0xfd7ffeab6546(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffeab6545
   [4] xercesc_2_8::SAXParser::startElement(this = 0x4cc3a8, elemDecl = CLASS, 
 elemURLId = 1U, elemPrefix = 0xfd7ffe1bb3b0, attrList = CLASS, attrCount 
 = 2U, isEmpty = false, isRoot = true), line 971 in SAXParser.cpp
   [5] xercesc_2_8::IGXMLScanner::scanStartTag(this = 0x4cd6b8, gotData = 
 true), line 2101 in IGXMLScanner.cpp
   [6] xercesc_2_8::IGXMLScanner::scanContent(this = 0x4cd6b8), line 899 in 
 IGXMLScanner.cpp
   [7] xercesc_2_8::IGXMLScanner::scanDocument(this = 0x4cd6b8, src = CLASS), 
 line 215 in IGXMLScanner.cpp
   [8] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 
 0x4d4530), line 460 in XMLScanner.cpp
   [9] xercesc_2_8::XMLScanner::scanDocument(this = 0x4cd6b8, systemId = 
 0x4c7f68 ../dats/adr3xml.dat), line 468 in XMLScanner.cpp
   [10] xercesc_2_8::SAXParser::parse(this = 0x4cc3a8, systemId = 0x4c7f68 
 ../dats/adr3xml.dat), line 587 in SAXParser.cpp

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



  1   2   3   4   5   6   7   8   >