libxmlplusplus-general — Open discusions about libXML++

[libxml++] looking for XPATH details - get html tag <script with his attributes ...

[Jens K. <jk...@we...>]

Hello,

I found some code on a website (dont remember):
What I want, is, to check for the tag <script src ...>
TIA

int test_html(request_rec *req, char* file)
{
     std::string url = "http://127.0.0.1/";
     curlpp::Easy request;

     // Specify the URL
     request.setOpt(curlpp::options::Url(url));

     // Specify some headers
     std::list<std::string> headers;
     headers.push_back(HEADER_ACCEPT);
     headers.push_back(HEADER_USER_AGENT);
     request.setOpt(new curlpp::options::HttpHeader(headers));
     request.setOpt(new curlpp::options::FollowLocation(true));

     // Configure curlpp to use stream
     std::ostringstream responseStream;
     curlpp::options::WriteStream streamWriter(&responseStream);
     request.setOpt(streamWriter);

     // Collect response
     request.perform();
     std::string re = responseStream.str();

     // Parse HTML and create a DOM tree
     xmlDoc* doc = htmlReadDoc((xmlChar*)re.c_str(), NULL, NULL, 
HTML_PARSE_RECOVER | HTML_PARSE_NOERROR | HTML_PARSE_NOWARNING);

     // Encapsulate raw libxml document in a libxml++ wrapper
     xmlNode* r = xmlDocGetRootElement(doc);
     xmlpp::Element* root = new xmlpp::Element(r);

     std::string xpath = "//html/head/title/text()";
     auto elements = root->find(xpath);

     //std::string ads = "//html/head/"
     // the line below is the crash point
     std::string dstr = 
dynamic_cast<xmlpp::ContentNode*>(elements[0])->get_content();

     ap_rprintf(req,dstr.c_str());
     xmlFreeDoc(doc);

     return OK;
}



-- 
        .  ."|
       /| /  |  _.----._
      . |/  |.-"        ".  /|
     /                    \/ |__
    |           _.-"""/        /
    |       _.-"     /."|     /
     ".__.-"         "  |     \
        |              |       |
        /_      _.._   | ___  /
      ."  ""-.-"    ". |/.-.\/
     |    0  |    0  |     / |
     \      /\_     _/    "_/
      "._ _/   "---"       |
      /"""                 |
      \__.--                |_
        )          .        | ".
       /        _.-"\        |  ".
      /     _.-"             |    ".
     (_ _.-|                  |     |"-._.
       "    "--.             .J     _.-'
               /\        _.-" | _.-'
              /  \__..--"   _.-'
             /   |      _.-'
            /| /\|  _.-'
           / |/ _.-'
          /|_.-'
        _.-'

[libxml++] DomParser::parse_stream() extremely slow

[Andrej v. d. Z. <and...@gm...>]

Hi,

Maybe it is a known issue, but I noticed that
DomParser::parse_stream() is extremely slow for big XML documents, as
compared to DomParser::parse_memory(). For a 20MB document the former
takes more than 5 min on my computer, while the latter only 6 seconds.

So using:
stringstream post_stream;
parser.parse_memory(post_stream.str());

Instead of:
stringstream post_stream;
parser.parse_stream(post_stream);

Make a big difference. Unfortunately I have no time to get into the
sources, just wanted to let you know.

Best regards,
Andrej

[libxml++] Moving the mailing list

[Murray C. <mu...@mu...>]

I am moving the mailing list to the gnome.org servers:
http://mail.gnome.org/mailman/listinfo/libxmlplusplus-list

We already use gnome.org for almost everything else.

You should have received an invitation already. You can also just
subscribe at the link above.

-- 
mu...@mu...
www.murrayc.com
www.openismus.com

[libxml++] Document::write_to_string() results strange characters like "&#xE9"

[Aurélien A. <ca...@gm...>]

Hello everyone,

I manipulate some xml::Element that have some UTF-8 parts (attributes), when
i use Document::write_to_string() the UTF-8 characters in the Glib::ustring
resulted have been replaced by some strange characters suite ( like '&#xE9'
).

I don't think that it is normal, someone knows where is the problem ?

I have checked the xmlpp::Element attributes , they are in the good encoding
but Document::write_to_string() seems to don't like my UTF-8 characters.

Aurélien.

Re: [libxml++] Libxml++ development

[Murray C. <mu...@mu...>]

CCing the mailing list, because you didn't.

On Thu, 2010-09-09 at 17:52 +0000, m-l...@us...
wrote:
> Hello,
> I realized that the library is no more developped

I don't think that's particularly true.

>  whereas there is still 
> some work to do:
> - add unit tests (for regression purpose)
> - add support for creating CDATA node
> - add better support for namespaces
> - clean correctly sax parser when an exception other than 
> xmlpp::exception (or one of its derived class) is thrown.
> 
> I think I can help to do part of this.

Sure. Patches are as welcome as ever, please.

> In the future, I think the API can evolve to integrate some iterators to 
> make it more friendly.


-- 
mu...@mu...
www.murrayc.com
www.openismus.com

Re: [libxml++] Add CdataNode to DOM tree

[Murray C. <mu...@mu...>]

On Wed, 2010-08-18 at 15:01 +0900, Andrej van der Zee wrote:
> Hi,
> 
> In need a way to add a CdataNode child to a Node*. I can only find
> examples how to read CdataNode and examples how to add TextNode. Is
> there a way to create a CdataNode and add it to a DOM tree?

Should we just add an Element::set_child_cdata() method, like the
existing ones Element::set_child_text() method?
http://library.gnome.org/devel/libxml
++/unstable/classxmlpp_1_1Element.html#a9be4234049fe13f2941d9c7a5dbc37e2

And an add_child_cdata() like add_child_text()?
http://library.gnome.org/devel/libxml
++/unstable/classxmlpp_1_1Element.html#a15cd56e871aaf9625b7f4fbedb97c764

-- 
mu...@mu...
www.murrayc.com
www.openismus.com

[libxml++] Import a node after/before a sibling node

[Aurélien A. <ca...@gm...>]

Hi all,
sorry for advance for my english, it's not my mother tongue.

I have a problem with the wrapper libxml++, i want to import recursively a
node but after a specified child node.
I see that it's possible to import node but i think it's impossible to do it
after a specified node, the imported node become the first child of the
target node.

So i think i have to do it with the C functions but i don't find the right
way to do it, someone know how to do it ?

Aurelien

Re: [libxml++] Add CdataNode to DOM tree

[Andrej v. d. Z. <and...@gm...>]

Talking to myself, but maybe somebody wants to do the same thing. Anyway,
after studying the libxml++ sources I noticed that you can add any node
through the underlying c-object like this:

string content = "some content";
_xmlNode * cnode = cppnode>cobj();
xmlNodePtr cdata = xmlNewCDataBlock(cppdoc->cobj(), (const xmlChar*)
content.c_str(), content.size());
xmlAddChild(cnode, cdata);

The c++ wrapper registers a callback in the c-lib that is called when a node
is added to the c-doc, creates a c++ object for the c-node and adds it to
the c++-doc. Something like that at least...

Greets,
Andrej

Re: [libxml++] Add CdataNode to DOM tree

[Andrej v. d. Z. <and...@gm...>]

Still no answer, not much activity on this list. Still stunned that the
libxmlpp does not provide any interface for adding (only reading) a
CDataNode. Is it impossible?
Andrej

On Wed, Aug 18, 2010 at 3:01 PM, Andrej van der Zee <
and...@gm...> wrote:

> Hi,
>
> In need a way to add a CdataNode child to a Node*. I can only find
> examples how to read CdataNode and examples how to add TextNode. Is
> there a way to create a CdataNode and add it to a DOM tree?
>
> Thank you,
> Andrej
>

[libxml++] Add CdataNode to DOM tree

[Andrej v. d. Z. <and...@gm...>]

Hi,

In need a way to add a CdataNode child to a Node*. I can only find
examples how to read CdataNode and examples how to add TextNode. Is
there a way to create a CdataNode and add it to a DOM tree?

Thank you,
Andrej

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[Murray C. <mu...@mu...>]

On Wed, 2010-07-28 at 15:13 -0400, David Benoit wrote: 
> Attached is the proposed first patch.  Source cloned from git yesterday.  Comments welcome.

Please put this in bugzilla.

I'm generally still thinking about this and haven't quite decided yet.

-- 
mu...@mu...
www.murrayc.com
www.openismus.com

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

Attached is the proposed first patch.  Source cloned from git yesterday.  Comments welcome.

David

NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

> -----Original Message-----
> From: Steven [mailto:red...@gm...]
> Sent: Wednesday, July 28, 2010 3:00 AM
>
> I'm not really a libxml++ developer, but, when changing the underlying
> type in the installer (really the installer, and not some compile
> flags?),
> wouldn't this pose an issue to other applications, dependent on
> libxml++?
> Wouldn't they need to be recompiled as well?
> I use Debian, so libxml++ is pre-build and installed using the package
> manager, but what if someone creates a binary with the other string
> implementation?
>
> Just asking :)

Yes and no.  The configuration change (the second change that I expect would not be integrated with the source) would be a change in the build configuration that changes the compilation, not the install.  It would be something that the package maintainer would be aware of, and nobody else.

The distributed libxml++ package would be shipped as it is today, with Glib::ustring as the storage.  The proposed (first) patch to the mainline code would simply:
 - rename all occurrences of Glib::ustring to xmlpp::string, and associated changes
 - add a "string.h" file that contains:
    namespace xmlpp {
      typedef ::Glib::ustring string;
    }
This would result in no change in process, effective API, binary, ABI, etc.  It simply makes things more flexible.

David

NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

Re: [libxml++] Revisting the Glib::ustring vs. std::string issue.

[Steven <red...@gm...>]

On Tue, July 27, 2010 19:09, David Benoit wrote:
> Hi,
>
> I have read all the previous posts regarding the use of Glib::ustring and
> std::string for use with libxml++.  I have even read the bug and the
> associated patch.  I understand Murray's point of view and agree with him
> from a package maintainer's point of view.
>
> However, I would really like to move forward with one part of the proposed
> change, and am willing to produce an updated patch.
>
....
> The second change was to allow the
> underlying type of xmlpp::string to be selected by the installer.  If only
> this change is integrated with the code, the second change can be easily
> done by anyone who really needs it.
>

I'm not really a libxml++ developer, but, when changing the underlying
type in the installer (really the installer, and not some compile flags?),
wouldn't this pose an issue to other applications, dependent on libxml++?
Wouldn't they need to be recompiled as well?
I use Debian, so libxml++ is pre-build and installed using the package
manager, but what if someone creates a binary with the other string
implementation?

Just asking :)

Kind regards,
Steven


-- 
Rarely do people communicate; they just take turns talking.

[libxml++] Revisting the Glib::ustring vs. std::string issue.

[David B. <be...@bl...>]

Hi,

I have read all the previous posts regarding the use of Glib::ustring and std::string for use with libxml++.  I have even read the bug and the associated patch.  I understand Murray's point of view and agree with him from a package maintainer's point of view.

However, I would really like to move forward with one part of the proposed change, and am willing to produce an updated patch.

The change that David Yan submitted on 2007-02-10 had two changes.  The first was to rename all of the use of Glib::ustring to xmlpp::string.  This, I believe, should be adopted in the mainline as it has no functional change, and would serve to minimize the number of locations the external glibmm libraries are referenced.  The second change was to allow the underlying type of xmlpp::string to be selected by the installer.  If only this change is integrated with the code, the second change can be easily done by anyone who really needs it.

I would like to use libxmlpp, but my target system doesn't have (nor will it) any glib libraries.  That dependency is a non-starter.  However, like many other libraries, I am willing to patch this one -- I purpose build all of the third-party libraries I use, I don't use the system version.  The inclusion of the first of David Yan's changes (updated to match the current code, of course) would allow be, and anyone else, to make my patch much MUCH smaller.

I understand the desire to keep the current api, and appreciate that, as Murray said, it would be too easy for the wrong version of a package to be released with some OS, causing havoc.  That said, what do you think of including the first part of those changes into the main-line?

Thanks!

David


NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

[libxml++] Problems running make (Install) on libxml++-2.6. OS X 10.4.11 Powerpc

[Justin W. K. <niv...@ho...>]

  I have the dependencies, I ran ./configure succesfully, but when Irun 
make, it pops it following error message. Please help. Thank you,
Justin King

g++ -dynamiclib -single_module -flat_namespace -undefined suppress -o 
.libs/libxml++-2.6.1.0.1.dylib  .libs/attribute.o .libs/dtd.o 
.libs/document.o .libs/noncopyable.o .libs/keepblanks.o -all_load  
parsers/.libs/libparsers.a exceptions/.libs/libexceptions.a 
nodes/.libs/libnodes.a io/.libs/libio.a  -L/usr/local/lib -L/sw/lib 
/usr/local/lib/libxml2.dylib /usr/local/lib/libz.dylib 
/usr/lib/libiconv.dylib /usr/lib/libm.dylib 
/usr/local/lib/libglibmm-2.4.dylib /sw/lib/libgmodule-2.0.dylib 
/sw/lib/libintl.dylib /usr/lib/libc.dylib /sw/lib/libgobject-2.0.dylib 
/usr/local/lib/libsigc-2.0.dylib /sw/lib/libglib-2.0.dylib 
/usr/local/lib/libintl.dylib /sw/lib/libiconv.dylib  -install_name  
/usr/local/lib/libxml++-2.6.1.dylib -compatibility_version 2 
-current_version 2.1
ld: multiple definitions of symbol ___divdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_divdi3.o) private 
external definition of ___divdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_divdi3_s.o) 
definition of ___divdi3
ld: multiple definitions of symbol ___udivdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_udivdi3.o) private 
external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_udivdi3_s.o) 
definition of ___udivdi3
ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private 
external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) 
definition of ___umoddi3
ld: multiple definitions of symbol ___floatdidf
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_floatdidf.o) private 
external definition of ___floatdidf in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_floatdidf_s.o) 
definition of ___floatdidf
ld: multiple definitions of symbol ___moddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_moddi3.o) private 
external definition of ___moddi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_moddi3_s.o) 
definition of ___moddi3
ld: multiple definitions of symbol ___cmpdi2
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_cmpdi2.o) private 
external definition of ___cmpdi2 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_cmpdi2_s.o) 
definition of ___cmpdi2
ld: multiple definitions of symbol ___fixdfdi
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_fixdfdi.o) private 
external definition of ___fixdfdi in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_fixdfdi_s.o) 
definition of ___fixdfdi
ld: multiple definitions of symbol ___fixsfdi
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_fixsfdi.o) private 
external definition of ___fixsfdi in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_fixsfdi_s.o) 
definition of ___fixsfdi
ld: multiple definitions of symbol ___fixunsdfdi
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_fixunsdfdi.o) private 
external definition of ___fixunsdfdi in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_fixunsdfdi_s.o) 
definition of ___fixunsdfdi
ld: multiple definitions of symbol ___fixunssfdi
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_fixunssfdi.o) private 
external definition of ___fixunssfdi in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_fixunssfdi_s.o) 
definition of ___fixunssfdi
ld: multiple definitions of symbol ___floatdisf
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_floatdisf.o) private 
external definition of ___floatdisf in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_floatdisf_s.o) 
definition of ___floatdisf
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit 
command failed
make[2]: *** [libxml++-2.6.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Re: [libxml++] const bool xmlpp::KeepBlanks::Default = true [Writing an XML]

[Murray C. <mu...@mu...>]

I think this is just an issue of libxml refusing to format a document that has possibly-significant text nodes. Please see the archive for the last few days.

----- Original message -----
> Hi all,
>
>
> I would use the function Document::write_to_file_formatted to write an XML file.
> The problem is that i was not able to have the output formatted in a right way,
> it is like it's not formatted. I try then to compile an xml2 example to see if
> it produces an output well formatted and it's ok.
> [http://xmlsoft.org/examples/tree2.c]. My analysis is (but maybe i am wrong)
> that function write_to_file_formatted is a wrapper for do_write_to_file.
> (obviously) In do_write_to_file, the first line is KeepBlanks
> k(KeepBlanks::Default). It seems to me that it sets libxml2's keepsblanks (or
> something like that) to the value true using a const value (KeepBlanks::Default,
> which i can't modify). It seems to me that to produce a formatted output the
> following conditions must be satisfied: 1) keepsblanks = false 2)
> xmlIndentTreeOutput = 1
>
> Can you explain me how to achieve the desired formatted output, please?
>
>
> Thank you in advance,
> Andrea
>
> ps: apologize for my english.
>
>
>           

[libxml++] const bool xmlpp::KeepBlanks::Default = true [Writing an XML]

[Andrea F. <pl...@ro...>]

Hi all,


I would use the function Document::write_to_file_formatted to write an XML file.
The problem is that i was not able to have the output formatted in a right way, it is like it's not formatted.
I try then to compile an xml2 example to see if it produces an output well formatted and it's ok. [http://xmlsoft.org/examples/tree2.c].
My analysis is (but maybe i am wrong) that function write_to_file_formatted is a wrapper for do_write_to_file. (obviously)
In do_write_to_file, the first line is KeepBlanks k(KeepBlanks::Default).
It seems to me that it sets libxml2's keepsblanks (or something like that) to the value true using a const value (KeepBlanks::Default, which i can't modify).
It seems to me that to produce a formatted output the following conditions must be satisfied:
1) keepsblanks = false
2) xmlIndentTreeOutput = 1

Can you explain me how to achieve the desired formatted output, please?


Thank you in advance,
Andrea

ps: apologize for my english. 


      

Re: [libxml++] Also Have Problems with UTF-8 in Example Code: 'Glib::ConvertError'

[Murray C. <mu...@mu...>]

On Tue, 2010-03-30 at 16:36 -0400, Nic...@ga... wrote:
> Is this a problem with freeBSD 8.0 or the example code? Again, thank
> you for your help.

Maybe, yes, someone on the gtkmm-list just said:
"
I remember having some problems with
std::locale::global(std::locale(""));
under FreeBSD 6.x.

Basically, it just abort()ed with:

"locale::facet::_S_create_c_locale name not valid".

Something to do with libstdc++/libc incompatibility.
Googling around hints that this issue may affect Darwin (OS X)
too.
"

http://mail.gnome.org/archives/gtkmm-list/2010-March/msg00161.html

I'm afraid you'll have to investigate that yourselves because I am not
using FreeBSD, though if you are lucky then someone will mention a
solution in that gtkmm-list thread.

-- 
mu...@mu...
www.murrayc.com
www.openismus.com

Re: [libxml++] Also Have Problems with UTF-8 in Example Code: 'Glib::ConvertError'

[<Nic...@ga...>]

Thank you for looking into this! I've added this line to the top of my main, but still have a crash:

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort trap: 6 (core dumped)

My 'locale' command shows that I am using en_US.UTF-8, which is also listed in `locale -a`.

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

If I export LANG=C, I return to the original error: terminate called after throwing an instance of 'Glib::ConvertError'.

Is this a problem with freeBSD 8.0 or the example code? Again, thank you for your help.

Nic

Re: [libxml++] Also Have Problems with UTF-8 in Example Code: 'Glib::ConvertError'

[Murray C. <mu...@mu...>]

On Tue, 2010-03-23 at 10:54 -0400, Nic...@ga... wrote:
> > It crashes with 'Glib::ConvertError'. Removing the UTF-8 characters fixes the problem, but obviously that's not a great solution. Also, if I do not attempt to 'cout' the field with UTF-8 characters, it also does not crash, but I need to output the field.

Yes, this was a problem with the use of std::cout in the examples, not
with the actual libxml++ implementation. You are not the first to notice
it and it has bothered me for a while.

I have committed a fix now that I've finally figured it out after
talking to Daniel Elstner:
http://git.gnome.org/browse/libxml
++/commit/?id=6f91e4489fba79f70c33029d2d9a76fd03fe6276

It adds this code to the main() of all the examples:

std::locale::global(std::locale(""));


-- 
mu...@mu...
www.murrayc.com
www.openismus.com

Re: [libxml++] ignore empty text nodes

[Andrej v. d. Z. <and...@gm...>]

Hi,

>
> void remove_whitespace_nodes(xmlpp::Document & doc)
> {
>    xmlpp::NodeSet whitespace_nodes =
> doc.get_root_node()->find("//text()[normalize-space()='']");
>    for (xmlpp::NodeSet::const_iterator it = whitespace_nodes.begin();
>         it != whitespace_nodes.end();
>         ++it)
>    {
>        (*it)->get_parent()->remove_child(*it);
>    }
> }
>

Thank you, that's a nice one!

Greets,
Andrej

Re: [libxml++] ignore empty text nodes

[Knut A. R. <kn...@if...>]

* Andrej van der Zee

> I am a happy user of libxmlpp for some time now. One thing I could not
> find out yet. How can I ignore empty text nodes?
[...]

Hi.

I have used the following XPath-based technique to remove such nodes in 
order to "normalize" XML-documents that are stored in pretty-printed 
format. The reason I had them stored pretty-printed, was to improve 
readability in a test suite. I would not use pretty-printing on XML that 
is going directly between machines.

void remove_whitespace_nodes(xmlpp::Document & doc)
{
     xmlpp::NodeSet whitespace_nodes = 
doc.get_root_node()->find("//text()[normalize-space()='']");
     for (xmlpp::NodeSet::const_iterator it = whitespace_nodes.begin();
          it != whitespace_nodes.end();
          ++it)
     {
         (*it)->get_parent()->remove_child(*it);
     }
}

Make sure the XPath above does not identify nodes that carries meaning 
to your application, otherwise you would have to refine it somehow.

-- 
Sincerely,
Knut Aksel Røysland

Re: [libxml++] ignore empty text nodes

[Murray C. <mu...@mu...>]

On Fri, 2010-03-26 at 20:07 +0900, Andrej van der Zee wrote:
> Though, I am doubting the correctness of the
> "doc->write_to_stream_formatted()" method now.  I expect the output to
> be formatted, but if you look at the last few nodes, they are not
> formatted at all. See below. Am I misunderstanding something?

I stopped using it in Bakery (now in Glom) too. I think it just gives up
when it finds child text nodes, because it can't generically know if
they should be indented with white space.

I did this:
http://git.gnome.org/browse/bakery/commit/?id=54d85442f58228609a147f461934b75387fa8d7d
 

-- 
mu...@mu...
www.murrayc.com
www.openismus.com

Re: [libxml++] ignore empty text nodes

[Andrej v. d. Z. <and...@gm...>]

Hi,

>
> Yes. I guess you are doing that somehow anyway during your "merge" of
> two documents.

Actually I am using import_node().


> I guess I'd accept a patch that adds an
> Element::remove_empty_text_nodes() method. The you could call that on
> get_root_node().

I will have a look when I have time.

Though, I am doubting the correctness of the
"doc->write_to_stream_formatted()" method now.  I expect the output to
be formatted, but if you look at the last few nodes, they are not
formatted at all. See below. Am I misunderstanding something?

Thank you,
Andrej


-------------- output of write_to_stream_formatted(), is it really
formatted? ----------------


<?xml version="1.0" encoding="UTF-8"?>
<session xmlns="http://www.contentional.eu" version="1.0"
clientName="Belastingdienst" projectName="GBV" phase="1" iteration="1"
sessionName="M2 - AUTO TEST3">
  <hosts>
    <host name="apmvsq1" cluster="apmvsp1+2" type="mainframe"
smtEnabled="0" numCpus="666" opsys="ToBeOverwittenByParser"
hardware="ToBeOverWrittenByParser"
serviceLevel="ToBeOverwittenByParser" cpuSpeed="1"
cpuSpeedBenchmark="MIPS" cacheHitPerc="95" cacheHitTime="0.0015"
cacheMissTime="0.005" monitoringTool="ascb" timeDiff="67"/>







  </hosts>
<msrs><msr xmlns="http://www.contentional.eu" type="SU" guiName="SU1"
ignoreEteValidator="0"><parser-logs><ete
filename="SU1/20100304-GBV-M2-SU1.ete"/><resource
filename="SU1/20100304-GBV-M2-SU1.mf"
hostname="apmvsq1"/></parser-logs></msr></msrs></session>