[xml] [PATCH] Correct spelling of "calling"
---
xmlschemas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xmlschemas.c b/xmlschemas.c
index d47512f..fe533e6 100644
--- a/xmlschemas.c
+++ b/xmlschemas.c
@@ -25546,7 +25546,7 @@ xmlSchemaVAttributesComplex(xmlSchemaValidCtxtPtr vctxt)
if (xmlNewProp(defAttrOwnerElem,
iattr->localName, value) == NULL) {
VERROR_INT("xmlSchemaVAttributesComplex",
- "callling xmlNewProp()");
+ "calling xmlNewProp()");
if (normValue != NULL)
xmlFree(normValue);
goto internal_error;
--
2.6.1
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Continuous integration for libxml2?
On 21/10/2015 09:11, David Drysdale wrote: On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard wrote: The biggest issue I have is non-linux, I never use Windows or Macs and I have zero clue that a change there could break the build or else. There are mingw builds of libxml2 done within Red Hat but that's not real Windows tests. The Travis builds do at least add OSX testing, which was fairly straightforward to set up (I disabled the EBCDIC test file because the iconv() on OSX doesn't include EBCDIC support). I imagine a Windows build would a lot more effort to get automated, if/when Travis add support for it... The Windows build could be tested with Appveyor. They offer free CI services for open-source projects. Setup is similar to Travis. Nick ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] indentation (again!)
On 10/16/2015 05:34 AM, Daniel Veillard wrote: Namely, if an element allows mixed content, do not add whitespace. (and you CAN apply indentation on descendants that do NOT allow mixed content). Is there some switch or method that I'm overlooking to achieve this effect? no, indeed this would make sense ... assuming you have a schemas, etc... but when you serialize a document while the DTD *might* be available you can't really find out he RNG or XSD associated (or trust them, download them, etc) it open a can of worm TBH. Yup, I understand; I wasn't really suggest that you introduce this complication at this stage! Just checking whether it was already hidden somewhere. In my case, I'm guaranteed to have the schema available for such information. Is this likely to be relatively easy to implement? (I've managed to avoid learning libxml2's C API, as I use it via Perl's XML::LibXML.) I'd hate to have to give up indentation or write my own serializer have you looked at xmllint --pretty 2 it does pretty printing but without adding (or removing) any significant character, it uses only the non-significant spaces from within markup which are discarded at parsing time. I know it's not what you asked for but might still be useful :-) Not quite what I needed, since I'm doing document surgery all the time. I went ahead & implemented my own serializer, but it wasn't really all that bad, since I could still rely on libxml's lower level string munging :> And surprisingly enough, no significant performance penalty. And it helped me simplify lots of bad heuristics! :> Yay! Thanks for the response; bruce ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 12:13:43PM +0100, David Drysdale wrote:
> On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard wrote:
> > On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
> >> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard
> >> wrote:
> >> > On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
> >> >> Hi folks,
> >> >
> >> > Hi David,
> >> >
> >> >> Does libxml2 have a continuous integration system running over it
> >> >> somewhere?
> >> >
> >> > Not that I know of :)
> >> > TBH the rate of changes is fairly slow, i.e. the code is mature (some
> >> > will call it overripe even !) and while there is bugs, compared to the
> >> > size of the system it's relatively small.
> >> >
> >> >> I've recently been exploring continuous integration systems and I used
> >> >> libxml2 as a guinea pig for getting various tools working in
> >> >> combination. Specifically, I've got a GitHub clone [1] of the repo
> >> >> that links in with Travis [2]; once I added a few small local fixes
> >> >> [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
> >> >> UBSAN and coverage [4] runs.
> >> >
> >> > The biggest issue I have is non-linux, I never use Windows or Macs
> >> > and I have zero clue that a change there could break the build or else.
> >> > There are mingw builds of libxml2 done within Red Hat but that's not
> >> > real Windows tests.
> >>
> >> The Travis builds do at least add OSX testing, which was fairly
> >> straightforward to set up (I disabled the EBCDIC test file because
> >> the iconv() on OSX doesn't include EBCDIC support).
> >
> > Okay
> >
> >> I imagine a Windows build would a lot more effort to get automated,
> >> if/when Travis add support for it...
> >
> > as suggested you could tru to build with mingw, but for the actual
> > regression testing, that's another story indeed
> >
> >> >> Looking at recent bugs, it seems like a couple of other people (Hugh
> >> >> Davenport [5], Hanno Boeck [6]) have also been looking at
> >> >> sanitizer-related things.
> >> >
> >> > Yes, I also get Coverity Scan reports about it.
> >> >
> >> >> So I wondered if the master libxml2 repo already has a continuous
> >> >> build pointed at it (the Gnome continuous build system [7], maybe?),
> >> >
> >> > No not that know of
> >> >
> >> >> and, if so, whether it might be a good idea to turn on various
> >> >> analysis tools to help catch future problems.
> >> >>
> >> >> Thoughts?
> >> >
> >> > Sure, the rate of changes is fairly slow though:
> >> > https://git.gnome.org/browse/libxml2/
> >> >
> >> > But getting a report if something breaks on commit there would be
> >> > appreciated
> >> > as long as there is some logic to avoid pestering the list repeatedly
> >> > with
> >> > the same issue. That was a very painful experience on the very early
> >> > versions
> >> > of Coverity for example,
> >>
> >> I believe the default Travis behaviour is to send email
> >> - to the commit author and committer
> >> - when a commit arrives for which the build is broken
> >> - and when a commit fixes a previously-broken build.
> >> (http://docs.travis-ci.com/user/notifications/)
> >>
> >> As the whole process is commit-triggered, there shouldn't be too many
> >> notifications (given that the rate of changes is low) -- but it does
> >> continue
> >> to pester on each commit until a build break gets fixed.
> >>
> >> How about I set up (for the time being) a cron job to do the following:
> >> - fetch from the master repo
> >> - merge into my testing branch
> >> - push to GitHub...
> >> - triggering a Travis build.
> >>
> >> I *think* that should result in any email notifications from Travis going
> >> to me, because I'll be the committer for the merge commit -- but please
> >> let me know if the process inadvertently spams anyone!
> >
> > may be I should get the SPAM. I wonder if there is a fedmsg backend for
> > travis
> > as getting those message over IRC might be a nice solution rather than mail
> >
> > http://www.fedmsg.com/en/latest/
>
> Simpler than that, it looks like Travis have direct IRC integration:
> http://docs.travis-ci.com/user/notifications/#IRC-notification
Then I think you can easilly pester the #xml channel on irc.gnome.org
or DV (my nick) on irc.gnome.org
thanks,
Daniel
> >> If that goes well and is helpful, we can then talk later about whether/how
> >> to migrate to the master repo.
> >>
> >> Sound OK?
> >
> >
> >yes,
> >
> > thanks !
> >
> > Daniel
> >
> >> Thanks,
> >> David
> >>
> >> > Daniel
> >> >
> >> >>
> >> >> Thanks,
> >> >> David
> >> >>
> >> >> [1] https://github.com/daviddrysdale/libxml2
> >> >> [2] https://travis-ci.org/daviddrysdale/libxml2
> >> >> [3] https://github.com/daviddrysdale/libxml2/commits/test
> >> >> [4] https://coveralls.io/github/daviddrysdale/libxml2
> >> >> [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
> >> >> [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
> >> >> [7] http://bu
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard wrote:
> On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
>> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard wrote:
>> > On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
>> >> Hi folks,
>> >
>> > Hi David,
>> >
>> >> Does libxml2 have a continuous integration system running over it
>> >> somewhere?
>> >
>> > Not that I know of :)
>> > TBH the rate of changes is fairly slow, i.e. the code is mature (some
>> > will call it overripe even !) and while there is bugs, compared to the
>> > size of the system it's relatively small.
>> >
>> >> I've recently been exploring continuous integration systems and I used
>> >> libxml2 as a guinea pig for getting various tools working in
>> >> combination. Specifically, I've got a GitHub clone [1] of the repo
>> >> that links in with Travis [2]; once I added a few small local fixes
>> >> [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
>> >> UBSAN and coverage [4] runs.
>> >
>> > The biggest issue I have is non-linux, I never use Windows or Macs
>> > and I have zero clue that a change there could break the build or else.
>> > There are mingw builds of libxml2 done within Red Hat but that's not
>> > real Windows tests.
>>
>> The Travis builds do at least add OSX testing, which was fairly
>> straightforward to set up (I disabled the EBCDIC test file because
>> the iconv() on OSX doesn't include EBCDIC support).
>
> Okay
>
>> I imagine a Windows build would a lot more effort to get automated,
>> if/when Travis add support for it...
>
> as suggested you could tru to build with mingw, but for the actual
> regression testing, that's another story indeed
>
>> >> Looking at recent bugs, it seems like a couple of other people (Hugh
>> >> Davenport [5], Hanno Boeck [6]) have also been looking at
>> >> sanitizer-related things.
>> >
>> > Yes, I also get Coverity Scan reports about it.
>> >
>> >> So I wondered if the master libxml2 repo already has a continuous
>> >> build pointed at it (the Gnome continuous build system [7], maybe?),
>> >
>> > No not that know of
>> >
>> >> and, if so, whether it might be a good idea to turn on various
>> >> analysis tools to help catch future problems.
>> >>
>> >> Thoughts?
>> >
>> > Sure, the rate of changes is fairly slow though:
>> > https://git.gnome.org/browse/libxml2/
>> >
>> > But getting a report if something breaks on commit there would be
>> > appreciated
>> > as long as there is some logic to avoid pestering the list repeatedly with
>> > the same issue. That was a very painful experience on the very early
>> > versions
>> > of Coverity for example,
>>
>> I believe the default Travis behaviour is to send email
>> - to the commit author and committer
>> - when a commit arrives for which the build is broken
>> - and when a commit fixes a previously-broken build.
>> (http://docs.travis-ci.com/user/notifications/)
>>
>> As the whole process is commit-triggered, there shouldn't be too many
>> notifications (given that the rate of changes is low) -- but it does continue
>> to pester on each commit until a build break gets fixed.
>>
>> How about I set up (for the time being) a cron job to do the following:
>> - fetch from the master repo
>> - merge into my testing branch
>> - push to GitHub...
>> - triggering a Travis build.
>>
>> I *think* that should result in any email notifications from Travis going
>> to me, because I'll be the committer for the merge commit -- but please
>> let me know if the process inadvertently spams anyone!
>
> may be I should get the SPAM. I wonder if there is a fedmsg backend for
> travis
> as getting those message over IRC might be a nice solution rather than mail
>
> http://www.fedmsg.com/en/latest/
Simpler than that, it looks like Travis have direct IRC integration:
http://docs.travis-ci.com/user/notifications/#IRC-notification
>> If that goes well and is helpful, we can then talk later about whether/how
>> to migrate to the master repo.
>>
>> Sound OK?
>
>
>yes,
>
> thanks !
>
> Daniel
>
>> Thanks,
>> David
>>
>> > Daniel
>> >
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >> [1] https://github.com/daviddrysdale/libxml2
>> >> [2] https://travis-ci.org/daviddrysdale/libxml2
>> >> [3] https://github.com/daviddrysdale/libxml2/commits/test
>> >> [4] https://coveralls.io/github/daviddrysdale/libxml2
>> >> [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
>> >> [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
>> >> [7] http://build.gnome.org/
>> >> ___
>> >> xml mailing list, project page http://xmlsoft.org/
>> >> xml@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/xml
>> >
>> > --
>> > Daniel Veillard | Open Source and Standards, Red Hat
>> > veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
>> > http://veillard.com/ | virtualization library http://libvirt.org/
>
> --
> Daniel Veillard
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard wrote:
> > On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
> >> Hi folks,
> >
> > Hi David,
> >
> >> Does libxml2 have a continuous integration system running over it
> >> somewhere?
> >
> > Not that I know of :)
> > TBH the rate of changes is fairly slow, i.e. the code is mature (some
> > will call it overripe even !) and while there is bugs, compared to the
> > size of the system it's relatively small.
> >
> >> I've recently been exploring continuous integration systems and I used
> >> libxml2 as a guinea pig for getting various tools working in
> >> combination. Specifically, I've got a GitHub clone [1] of the repo
> >> that links in with Travis [2]; once I added a few small local fixes
> >> [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
> >> UBSAN and coverage [4] runs.
> >
> > The biggest issue I have is non-linux, I never use Windows or Macs
> > and I have zero clue that a change there could break the build or else.
> > There are mingw builds of libxml2 done within Red Hat but that's not
> > real Windows tests.
>
> The Travis builds do at least add OSX testing, which was fairly
> straightforward to set up (I disabled the EBCDIC test file because
> the iconv() on OSX doesn't include EBCDIC support).
Okay
> I imagine a Windows build would a lot more effort to get automated,
> if/when Travis add support for it...
as suggested you could tru to build with mingw, but for the actual
regression testing, that's another story indeed
> >> Looking at recent bugs, it seems like a couple of other people (Hugh
> >> Davenport [5], Hanno Boeck [6]) have also been looking at
> >> sanitizer-related things.
> >
> > Yes, I also get Coverity Scan reports about it.
> >
> >> So I wondered if the master libxml2 repo already has a continuous
> >> build pointed at it (the Gnome continuous build system [7], maybe?),
> >
> > No not that know of
> >
> >> and, if so, whether it might be a good idea to turn on various
> >> analysis tools to help catch future problems.
> >>
> >> Thoughts?
> >
> > Sure, the rate of changes is fairly slow though:
> > https://git.gnome.org/browse/libxml2/
> >
> > But getting a report if something breaks on commit there would be
> > appreciated
> > as long as there is some logic to avoid pestering the list repeatedly with
> > the same issue. That was a very painful experience on the very early
> > versions
> > of Coverity for example,
>
> I believe the default Travis behaviour is to send email
> - to the commit author and committer
> - when a commit arrives for which the build is broken
> - and when a commit fixes a previously-broken build.
> (http://docs.travis-ci.com/user/notifications/)
>
> As the whole process is commit-triggered, there shouldn't be too many
> notifications (given that the rate of changes is low) -- but it does continue
> to pester on each commit until a build break gets fixed.
>
> How about I set up (for the time being) a cron job to do the following:
> - fetch from the master repo
> - merge into my testing branch
> - push to GitHub...
> - triggering a Travis build.
>
> I *think* that should result in any email notifications from Travis going
> to me, because I'll be the committer for the merge commit -- but please
> let me know if the process inadvertently spams anyone!
may be I should get the SPAM. I wonder if there is a fedmsg backend for travis
as getting those message over IRC might be a nice solution rather than mail
http://www.fedmsg.com/en/latest/
> If that goes well and is helpful, we can then talk later about whether/how
> to migrate to the master repo.
>
> Sound OK?
yes,
thanks !
Daniel
> Thanks,
> David
>
> > Daniel
> >
> >>
> >> Thanks,
> >> David
> >>
> >> [1] https://github.com/daviddrysdale/libxml2
> >> [2] https://travis-ci.org/daviddrysdale/libxml2
> >> [3] https://github.com/daviddrysdale/libxml2/commits/test
> >> [4] https://coveralls.io/github/daviddrysdale/libxml2
> >> [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
> >> [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
> >> [7] http://build.gnome.org/
> >> ___
> >> xml mailing list, project page http://xmlsoft.org/
> >> xml@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/xml
> >
> > --
> > Daniel Veillard | Open Source and Standards, Red Hat
> > veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
> > http://veillard.com/ | virtualization library http://libvirt.org/
--
Daniel Veillard | Open Source and Standards, Red Hat
veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/lis
Re: [xml] Continuous integration for libxml2?
On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard wrote:
> On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
>> Hi folks,
>
> Hi David,
>
>> Does libxml2 have a continuous integration system running over it somewhere?
>
> Not that I know of :)
> TBH the rate of changes is fairly slow, i.e. the code is mature (some
> will call it overripe even !) and while there is bugs, compared to the
> size of the system it's relatively small.
>
>> I've recently been exploring continuous integration systems and I used
>> libxml2 as a guinea pig for getting various tools working in
>> combination. Specifically, I've got a GitHub clone [1] of the repo
>> that links in with Travis [2]; once I added a few small local fixes
>> [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
>> UBSAN and coverage [4] runs.
>
> The biggest issue I have is non-linux, I never use Windows or Macs
> and I have zero clue that a change there could break the build or else.
> There are mingw builds of libxml2 done within Red Hat but that's not
> real Windows tests.
The Travis builds do at least add OSX testing, which was fairly
straightforward to set up (I disabled the EBCDIC test file because
the iconv() on OSX doesn't include EBCDIC support).
I imagine a Windows build would a lot more effort to get automated,
if/when Travis add support for it...
>> Looking at recent bugs, it seems like a couple of other people (Hugh
>> Davenport [5], Hanno Boeck [6]) have also been looking at
>> sanitizer-related things.
>
> Yes, I also get Coverity Scan reports about it.
>
>> So I wondered if the master libxml2 repo already has a continuous
>> build pointed at it (the Gnome continuous build system [7], maybe?),
>
> No not that know of
>
>> and, if so, whether it might be a good idea to turn on various
>> analysis tools to help catch future problems.
>>
>> Thoughts?
>
> Sure, the rate of changes is fairly slow though:
> https://git.gnome.org/browse/libxml2/
>
> But getting a report if something breaks on commit there would be appreciated
> as long as there is some logic to avoid pestering the list repeatedly with
> the same issue. That was a very painful experience on the very early versions
> of Coverity for example,
I believe the default Travis behaviour is to send email
- to the commit author and committer
- when a commit arrives for which the build is broken
- and when a commit fixes a previously-broken build.
(http://docs.travis-ci.com/user/notifications/)
As the whole process is commit-triggered, there shouldn't be too many
notifications (given that the rate of changes is low) -- but it does continue
to pester on each commit until a build break gets fixed.
How about I set up (for the time being) a cron job to do the following:
- fetch from the master repo
- merge into my testing branch
- push to GitHub...
- triggering a Travis build.
I *think* that should result in any email notifications from Travis going
to me, because I'll be the committer for the merge commit -- but please
let me know if the process inadvertently spams anyone!
If that goes well and is helpful, we can then talk later about whether/how
to migrate to the master repo.
Sound OK?
Thanks,
David
> Daniel
>
>>
>> Thanks,
>> David
>>
>> [1] https://github.com/daviddrysdale/libxml2
>> [2] https://travis-ci.org/daviddrysdale/libxml2
>> [3] https://github.com/daviddrysdale/libxml2/commits/test
>> [4] https://coveralls.io/github/daviddrysdale/libxml2
>> [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
>> [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
>> [7] http://build.gnome.org/
>> ___
>> xml mailing list, project page http://xmlsoft.org/
>> xml@gnome.org
>> https://mail.gnome.org/mailman/listinfo/xml
>
> --
> Daniel Veillard | Open Source and Standards, Red Hat
> veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
> http://veillard.com/ | virtualization library http://libvirt.org/
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
