libxmlplusplus-general — Open discusions about libXML++

Re: Fwd: Re: [libxml++] xmlpp::DomParser w/ multiple files

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Jeudi 12 Juin 2003 09:13, Daniel Hedlund a =E9crit :
> Christophe,
>
>      I can possibly work on a patch but I've just started studying for my
> exams again.  I will try to this
> weekend.  Cheers,
>

Thanks.


Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+50/uB+sU3TyOQjARAuIjAKDdShSsdH/EGbZTT+mKF1TIAUH5uwCfWyG5
7P/vrYCWyznZS+KT3RJCl7k=3D
=3D+SHm
=2D----END PGP SIGNATURE-----

[libxml++] Error Checking in parsers

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think we need to implement something a bit more clean and solid for check=
ing=20
errors after a parsing.

We already have a common function check_for_exception() which check for=20
validity errors only.
I propose to make it check it _context->errNo, so any error libxml could=20
report we catch it.
Since the errNo an int, I propose to modify parse_error class to take a lib=
xml=20
error number as a parameter in the constructor.

Comments/remarks welcome,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5wJYB+sU3TyOQjARAkGnAKCdVpkfwcqFRjj36OrTCNVU3tm2cACgm/Iu
ZTJ5v+OfCVMDzXaHzzoVVkA=3D
=3DLCtK
=2D----END PGP SIGNATURE-----

Re: [libxml++] Unknown encoding crashes DOM Parser

[<p....@ic...>]

> I wonder if it would be enough to move the _doc initialisation lower,
after
> _context->wellFormed and _context->valid are checked ?
> In other terms, does _context->wellFormed and _context->valid implies
> _context->myDoc ?

I tested this assumption and the answer is no. The program still segfaults
when moving the _doc initialization downward.

Best regards, Peter.

Re: [libxml++] Unknown encoding crashes DOM Parser

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 11 Juin 2003 11:23, Christophe de VIENNE a =E9crit :
> I wonder if it would be enough to move the _doc initialisation lower, aft=
er
> _context->wellFormed and _context->valid are checked ?
> In other terms, does _context->wellFormed and _context->valid implies
> _context->myDoc ?
>
>

It seems that no. I'll investigate this a bit more.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5vhnB+sU3TyOQjARAvFJAKDTTHmgSqu55BYZlOxgBKJcPy+4IwCfXSBF
fKH9FK8qTAsiWYSRwY6fI4E=3D
=3DkwnL
=2D----END PGP SIGNATURE-----

Re: [libxml++] Unknown encoding crashes DOM Parser

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Le Mardi 10 Juin 2003 13:07, p....@ic... a =E9crit :
> The following encoding
>       <?xml version=3D"1.0" encoding=3D"ISO-8859-15"?>
> leads to a crash under Windows and Linux.
>
> In domparser.cc / DomParser::parse_context() one finds:
>
> xmlParseDocument(_context);
> _doc =3D new Document(_context->myDoc); // context->myDoc is 0 if encodin=
g is
> illegal, therefore the constructor segfaults
>
> It should be checked if _context->myDoc is a valid pointer.
>

Thanks for pointing this problem.

I wonder if it would be enough to move the _doc initialisation lower, after=
=20
_context->wellFormed and _context->valid are checked ?
In other terms, does _context->wellFormed and _context->valid implies=20
_context->myDoc ?
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5vT0B+sU3TyOQjARAmktAJ4skoiSOiVChiw331oTWe+KsYc+iwCgtxmj
aEaOjyi9PFyk7jkp6JnXN84=3D
=3D2Imr
=2D----END PGP SIGNATURE-----

Re: [libxml++] indent again

[<joe...@un...>]

Am Mittwoch, 11. Juni 2003 09:59 schrieb Christophe de VIENNE:
> Le Mercredi 11 Juin 2003 09:47, J=F6rn Seger a =E9crit :
> > There is no such method in version 0.23!?
>
> Indeed... 0.24 is coming soon, before that you can use CVS version.

OK - thanks!

Re: [libxml++] indent again

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 11 Juin 2003 09:56, J=F6rn Seger a =E9crit :
>
> Is there are date for next release version?
>

This week for sure, probably today as soon as I've applied the pending=20
patches.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5uIPB+sU3TyOQjARAikHAJ9dHutkBUvPcdmkKZ3T80QiuWaDWQCg111a
J7x058JEQgwFWf8D7AJVFro=3D
=3DU4Ea
=2D----END PGP SIGNATURE-----

Re: [libxml++] indent again

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 11 Juin 2003 09:47, J=F6rn Seger a =E9crit :
> There is no such method in version 0.23!?
>

Indeed... 0.24 is coming soon, before that you can use CVS version.

Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5uFRB+sU3TyOQjARAjqUAJ99dkYX+pTTB+L01/oeCVN6CCY0mwCfTfAD
Uf4n7FWq7y1auoKIYwpp2u8=3D
=3D/X35
=2D----END PGP SIGNATURE-----

[libxml++] indent again

[<joe...@un...>]

Hi,

I read many things about keeping blanks, whitespaces, indenting etc. (It's=
=20
hard to follow the discussion within the web-interface)

I have only one simple question:

How am I able to produce _readable_ output (I don't really care for indents=
,=20
but some CR would be nice)?

Maybe I didn't get the point, but I got 2 things, that makes me gonna feel=
=20
this is important.
I'm working with big files (some about 8MB), they are really _not_ readable=
 in=20
any kind when there is no <CR>. Secondly the parser is _significantly_=20
slower, when the file is an 8MB xml stream. I don't know why, but version=20
0.21.0 is much faster (with xml produced by this version).

regards - J=F6rn

[libxml++] [ libxmlplusplus-Patches-751868 ] Including <istream> breaks compilaton

[SourceForge.net <no...@so...>]

Patches item #751868, was opened at 2003-06-10 11:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=751868&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Wakely (redi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Including <istream> breaks compilaton

Initial Comment:
The introduction of <istream> into saxparser.cc
(revision 1.31) breaks compilation with older
pre-standard compilers such as GCC 2.95.
Replacing it with <iostream> fixes this, as already
done with the following changes:

2003-04-19 09:24  murrayc

        * document.cc: 2003-04-18  Murray Cumming 
<mu...@us...>
        >
        >         * Applied Jaka Jejcic's patch to fix
compilation on
        NetBSD, including
        >         iostream.h instead of istream.h.
        >

2003-01-03 01:44  murrayc

        * parsers/parser.h: 2002-12-24  Morten Brix
Pedersen
        <mo...@wt...>

                * Include <iostream> instead of
<istream> to compile on gcc
        2.95.4.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=751868&group_id=12999

[libxml++] Unknown encoding crashes DOM Parser

[<p....@ic...>]

The following encoding
      <?xml version="1.0" encoding="ISO-8859-15"?>
leads to a crash under Windows and Linux.

In domparser.cc / DomParser::parse_context() one finds:

xmlParseDocument(_context);
_doc = new Document(_context->myDoc); // context->myDoc is 0 if encoding is
illegal, therefore the constructor segfaults

It should be checked if _context->myDoc is a valid pointer.

Best regards, Peter.

Re: [libxml++] xmlpp::DomParser w/ multiple files

[Christophe de V. <cde...@al...>]

Le Lundi 9 Juin 2003 14:07, Daniel Hedlund a =E9crit :
> G'day,

Hi,

>
>      Your group's project is great and I'm helping by using the libraries
> and giving feedback.

Thanks for your interest in libxml++

>  I'm not sure if
> there is already something implemented in xmlpp yet but it would be great
> if you could be able to "detach" or
> copy a node (ie. the root node) from the parser so when the parser goes
> to open up a second file that the
> original parsed node tree will still exist?
>
> 1.  Open up XML file 1 (xml1)
> 2.  Detach the root node from the parser (rn1)
> 3.  Open up XML file 2 (xml2)
> 4.  still have access to rn1
>

There is no such feature for now.
To do so there is two ways :

1. Add a function to DomParser to detach a Document from the parser and avo=
id=20
it to be released by the DomParser
for example :
	Document DomParser::detach_document()
or
	Document DomParser::release_document()

2. Give the possibility to detach any node (and all its children) from a tr=
ee,=20
and to attach it anywhere we want. These could be done with functions like=
=20
Node::attach_node(Node *) / Node::detach_node(Node *).

The 1. should be quite trivial to implement, a patch would be very welcome.
2. implies more reflexion. If someone has ideas on how to do that and want =
to=20
propose a patch, we can discuss it.

Cheers,

Christophe

[libxml++] xmlpp::DomParser w/ multiple files

[Daniel H. <dhe...@po...>]

G'day, 
 
     Your group's project is great and I'm helping by using the libraries 
and giving feedback.  I'm not sure if 
there is already something implemented in xmlpp yet but it would be great 
if you could be able to "detach" or 
copy a node (ie. the root node) from the parser so when the parser goes
to open up a second file that the 
original parsed node tree will still exist? 
 
1.  Open up XML file 1 (xml1) 
2.  Detach the root node from the parser (rn1) 
3.  Open up XML file 2 (xml2) 
4.  still have access to rn1 
 
     Essentially I will be opening up thousands of xml files into memory
at once, each following a single DTD 
and I would not like to really need 1000 instances of the parser (and
thus probably 1000 loaded copies of the 
DTD into memory) open when all I really want is just a nice simple
memory-efficient tree of nodes that I can 
refer back to. 
     I'm sure I could do it by using the libxml2 libraries, but any way
to do it without going that deep?  Thanks.  
Cheers, 
 
 
                                            Daniel Hedlund 
                                            dhe...@po... 

[libxml++] libxml++ 0.23.0: Patch to remove gcc warnings

[<p....@ic...>]

Hi

I attached a patch that removes several gcc warnings.

Best regards, Peter.

(See attached file: libxml++-0.23.0.gcc-warnings.patch)

Re: [libxml++] iso-8859-1 encoded characters

[Thomas J. <tho...@in...>]

> > When I use the write_to_string() function, everything is normal.
> > The dom_read_write program shows no sign of a problem, too.
> > But when you get the content of a node, the umlauts are broken
> > and show up as two garbage characters.
>
> This is normal. The in-memory encoding format of libxml2 is _always_ UTF-8,
> in which special character are encoded on several octets. You can use iconv
> to translate them to iso-8859-1.

Thanks for the two quick responses!

Either I'm going to use iconv or I now have a good reason
to switch my code to UTF-8 anyway.

Thomas

Re: [libxml++] iso-8859-1 encoded characters

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Vendredi 6 Juin 2003 15:12, Thomas Jarosch a =E9crit :
> Hi!
>
> I'm experiencing a very strange behavior when I try to use special
> iso-8859-1 characters like the German umlauts. The problem is easily
> reproducebale with the dom_parser example program of libxml++.
> Attached is a small testcase to show the problem.
>
> When I use the write_to_string() function, everything is normal.
> The dom_read_write program shows no sign of a problem, too.
> But when you get the content of a node, the umlauts are broken
> and show up as two garbage characters.

This is normal. The in-memory encoding format of libxml2 is _always_ UTF-8,=
 in=20
which special character are encoded on several octets. You can use iconv to=
=20
translate them to iso-8859-1.

Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+4JSVB+sU3TyOQjARAm4gAJ0aSJ7yxgnO3Q+ZvQYlU+UErZ2VwwCaAiqS
b0NY1tz5vt+JXFqYcampaeI=3D
=3DprR+
=2D----END PGP SIGNATURE-----

[libxml++] iso-8859-1 encoded characters

[Thomas J. <tho...@in...>]

Hi!

I'm experiencing a very strange behavior when I try to use special iso-8859-1
characters like the German umlauts. The problem is easily reproducebale
with the dom_parser example program of libxml++.
Attached is a small testcase to show the problem.

When I use the write_to_string() function, everything is normal.
The dom_read_write program shows no sign of a problem, too.
But when you get the content of a node, the umlauts are broken
and show up as two garbage characters.
(look at the output of dom_parser example)

Any help is appreciated.

I'm using libxml++-0.23.0 and libxml2-2.5.7.

cheers,
Thomas

Re: [libxml++] windows compile error with latest release

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 4 Juin 2003 07:56, Forrest Osterman a =E9crit :
> Hi guys,
> I'm having a problem compiling your latest release. (0.23.0)
>

Thanks for reporting it.

> I'm compiling on win2k, with msvc6.
> I followed the instructions for unpacking the libraries, and got the
> libxml2 and iconv into the correct places, and when I compile, I get this
> error:
>
> Compiling...
> domparser.cc
> d:\development\lib\libxml++-0.23.0\libxml++\keepblanks.h(17) : error C225=
8:
> illegal pure syntax, must be '=3D 0'
> d:\development\lib\libxml++-0.23.0\libxml++\keepblanks.h(17) : error C225=
2:
> 'Default' : pure specifier can only be specified for functions
>
>   class KeepBlanks {
>     public:
> -->      static const bool Default =3D true;
>
> So, I guess it thinks you are trying to declare a pure virtual function?
> I'm not sure why. Has this been addressed already?

It's not a virtual function, it's a constant. It's seems that msvc6 does no=
t=20
support this syntax.
Could someone used to msvc6 tells us how to workaround this ?

Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+3aCrB+sU3TyOQjARAmrPAJ4+M01CGxFEMUFcoAJZsgxWIzvB6gCdEzqT
QGByT1oqHhGpYYsxcSp2fHM=3D
=3Dy/Ul
=2D----END PGP SIGNATURE-----

[libxml++] windows compile error with latest release

[Forrest O. <for...@ho...>]

Hi guys,
I'm having a problem compiling your latest release. (0.23.0)

I'm compiling on win2k, with msvc6.
I followed the instructions for unpacking the libraries, and got the libxml2 
and iconv into the correct places, and when I compile, I get this error:

Compiling...
domparser.cc
d:\development\lib\libxml++-0.23.0\libxml++\keepblanks.h(17) : error C2258: 
illegal pure syntax, must be '= 0'
d:\development\lib\libxml++-0.23.0\libxml++\keepblanks.h(17) : error C2252: 
'Default' : pure specifier can only be specified for functions

  class KeepBlanks {
    public:
-->      static const bool Default = true;

So, I guess it thinks you are trying to declare a pure virtual function?  
I'm not sure why. Has this been addressed already?

TIA,
-Forrest

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

[libxml++] Memory leak?

[Morten H. <mor...@pd...>]

Hi,

I have used libxml++ a little bit lately, and I *think* I have found a =
memory leak in the write_to_string() function in the class Document. =
Internally this functions call the libxml functions xmlDocDumpMemory() =
and xmlDocDumpMemory(). Both of these functions internally call yet =
another libxml function, which says in it's code documentation that the =
caller of the function is responsible for freeing the allocated buffer =
using xmlFree().

But, as we can see in Document's write_to_string(), the code does not =
free the buffer after calling the libxml functions, it only creates a =
copy of the buffer in a std::string and returns that copy. Thus the =
original allocated memory is not destroyed.

Anyone agree with me on this one? :)

Thanks in advance,
Morten.

Re: [libxml++] keek blancs.

[Christophe de V. <cde...@al...>]

Le Mercredi 28 Mai 2003 20:31, and...@am... a =E9crit :
> Q: I'm a little bit confused by this.
> I thought that parse_file, etc., were methods on
> a parser object, e.g.
> xmlpp::Parser::parse_file,
> xmlpp::DomParser::parse_file,
> xmlpp::SaxParser::parse_file.
>
> Has it been made into a free function in a version
> I have not downloaded yet?
> (I wish I could get CVS across my company's firewall,
> legitimately.)

I was speaking of the free parsing functions which are defined in=20
document.[h|cc], not the ones which resides in Parsers.

RE: [libxml++] keek blancs.

[<and...@am...>]

> I don't think we want this kind of complication. I don't think it's
> necessary.

As long as you promise to never add any more optional
parameters.

Adding optional parameters with default values 
messes up inheritance. Fragile base class.

RE: [libxml++] keek blancs.

[<and...@am...>]

> Not keeping blancs at parsing time or adding some when 
> writing to indent is breaking the XML specifications.
> However I think it can be useful to do so.

I agree that it is useful to do so
- sufficiently useful that some such functionality
should be provided as part of a standard library
like libxml++ (or else it will be constantly reinvented
in slightly different ways).


> So I propose to modify the API of libxml to give the 
> possibility not to keep blanks (xmlKeepBlanksDefault option in libxml).

However, I question whether it is appropriate to add 
options to the parsing functions.  That's a slippery 
slope.  If more options get added this way it leads to
"fragile base class", which matters to me because I hope/plan 
to have my own Parser derived class, something like TwigParser
(halfway between DomParser and SaxParser).



Better to make it a property... since C++ doesn't really have
properties, make it a data member of Parser, with the appropriate
accessors.

>  1) add a parameter to parsing functions :
> Document* 
>     xmlpp::parse_file(
>         const std::string& filename,
>         bool keepblanks = KeepBlancs::Default
>     )
>     throw(exception)
> etc.

Q: I'm a little bit confused by this.
I thought that parse_file, etc., were methods on
a parser object, e.g. 
xmlpp::Parser::parse_file,
xmlpp::DomParser::parse_file,
xmlpp::SaxParser::parse_file.

Has it been made into a free function in a version
I have not downloaded yet?
(I wish I could get CVS across my company's firewall,
legitimately.)

Anyway, assuming that it has not been:

Make your whitespace handling mode a private data member
of Parser.  With the appropriate accessors.

>  2) add an accessor to Parser :
> Parser::set_keepblanks(bool value)

A slight trick, from Stroustrup, that gives you the equivalent 
of keyword options:

Instead of 
  void Parser::set_keepblanks(bool value)
make it
  Parser& Parser::set_keepblanks(bool value)
as in
  Parser& Parser::set_keepblanks(bool value) {
      this->m_keepblanks = value;
      return *this;
  }

So, instead of  
  DomParser domparser;
  domparser.parse_file(filename,/*keepblanks=*/true);
you do
  domparser.set_keepblanks(true).parse_file(filename);


Such "Stroustrup keywords" have some minor issues:
either you want to make parse_file a virtual function in Parser,
so that it picks up the derived DomParser::parse_file or 
SaxParser::parse_file; or you have to make set_keepblanks
a delegate in derived classes, with a slightly different
return.  {Virtual functions better, IMHO.}



>  3) add following functions to Document :
> Document::write_to_formated_file(const std::string& filename, const 
> std::string& encoding = std::string()) throw(exception);
> Document::write_to_formated_memory(const std::string& filename, const 
> std::string& encoding = std::string()) throw(exception);

First, spelling: write_to_formatted_file...

Second, this caused me to notice the assymmetry:
   Parser::parse_file(string_filename), 
   Parser::parse_memory(string), 
   Parser::parse_stream(istream)
   Document::write_to_file(string_filename), 
   Document::write_to_string(string)
"Obviously" want write_to_stream(ostream).

It also tends to suggest that what is wanted is a Formatter object,
separate from the Document. Possibly an object that exposes both a
Parser interface for input, and a Formatter interface for output,
since much of the time the input and output keep blanks setting 
will be similar.
   Maybe "Printer" is a betteer name than "Formatter".
What's an antonym for "Parser"?

But that's gilding the lily - BDUF, Big Design Up Front.  
For now, 
	Document::write_to_formatted_file
is fine, with the assunmption being that Document
will have copied the keepblanks setting 
(aka the Formatter object) from the Parser that created it.




> The default behavior would remain the same.
> 
> Do you agree on this ?

Overall, yes, with the minor tweaks to the interface
that I mention above.

Re: [libxml++] keek blancs.

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 28 Mai 2003 16:12, Christophe de VIENNE a =E9crit :
> > write_to_file_formatted()
> > write_to_string_formatted().
>
> You're right. I'll do it this way.

It's in the CVS, feel free to test.

Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+1M6CB+sU3TyOQjARAjr6AKDLxmACcW8T2+6i8IfQbm8oI7LqqgCg4rcc
xLNYGLshI+TImn5MZytPBKo=3D
=3Dm4M4
=2D----END PGP SIGNATURE-----

[libxml++] keek blancs.

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Not keeping blancs at parsing time or adding some when writing to indent is=
=20
breaking the XML specifications.
However I think it can be usefull to do so. For example in my application I=
 do=20
have XML files in which I have no content nodes, and that I have to edit by=
=20
hand. Having them indented automatically is _very_ much easier than to=20
include artificial content nodes. I'm sure I'm not alone in this case.

So I propose to modify the API of libxml to give the possibility not to kee=
p=20
blanks (xmlKeepBlanksDefault option in libxml).

The modification would be the following :

 1) add a parameter to parsing functions :
Document* xmlpp::parse_file(const std::string& filename, bool keepblanks =
=3D=20
KeepBlancs::Default) throw(exception)
Document* parse_memory(const std::string& contents, bool keepblanks =3D=20
KeepBlancs::Default) throw(exception);
Document* parse_stream(std::istream& is, bool keepblanks =3D=20
KeepBlancs::Default) throw(exception);

 2) add an accessor to Parser :
Parser::set_keepblanks(bool value)

 3) add following functions to Document :
Document::write_to_formated_file(const std::string& filename, const=20
std::string& encoding =3D std::string()) throw(exception);
Document::write_to_formated_memory(const std::string& filename, const=20
std::string& encoding =3D std::string()) throw(exception);


The default behavior would remain the same.

Do you agree on this ?


Best regards,


Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+1K45B+sU3TyOQjARAqnIAJ0bi48MB0JHl0esnr2Qn2zRvQAipgCfR/tO
3MYd6pQpKFNI4iOwKPrZ2p4=3D
=3Dgx4A
=2D----END PGP SIGNATURE-----