cpp-netlib-devel

[cpp-netlib-devel] Dependence on std::string

[Glyn M. <gly...@gm...>]

Guys,

I've been giving a little thought to something Dean mentioned in his last
message about using std::string in the network library.

The first thing I thought of was that Dean stated that "everything is a
template".  Apart of course from std::string.  I have created a branch in
SVN named gxm) which replaces all references to std::string with an extra
template parameter.  Happily, this passes all the original tests (with an
additional template specialization so that const char * is converted to a
std::string).  However, this creates a problem (certainly with GCC) because
the wchar_t typedef is the same as char and its not possible to overload
const wchar_t * in the same way.  So the following code will not compile:

wmessage wmsg;
wmsg << header(L"wide characters");

Another thing I see is that boost filesystem and boost program_options have
dealt with a very similar problem to this.  But if we use the same approach
(see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
accept the use of a cpp source file, meaning we will no longer have a header
only library.

What do others think about this?

G

Re: [cpp-netlib-devel] Dependence on std::string

[Matt G. <mgr...@in...>]

Glyn Matthews wrote:

> Another thing I see is that boost filesystem and boost program_options 
> have
> dealt with a very similar problem to this.  But if we use the same 
> approach
> (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> accept the use of a cpp source file, meaning we will no longer have a 
> header
> only library.


Why is that so bad?  More to the point, why would it be a requirement 
for something as big as a network protocol library to be header-only?


Matt

Re: [cpp-netlib-devel] Dependence on std::string

[Glyn M. <gly...@gm...>]

Matt,

On 17/07/07, Matt Gruenke <mgr...@in...> wrote:
>
> Glyn Matthews wrote:
>
> > Another thing I see is that boost filesystem and boost program_options
> > have
> > dealt with a very similar problem to this.  But if we use the same
> > approach
> > (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> > accept the use of a cpp source file, meaning we will no longer have a
> > header
> > only library.
>
>
> Why is that so bad?  More to the point, why would it be a requirement
> for something as big as a network protocol library to be header-only?



I don't think this is so bad, but the original rationale document as set out
by Dean specifically mentions that he wants this as a header only library.
 Glyn

Re: [cpp-netlib-devel] Dependence on std::string

[<rhy...@gm...>]

Hi, Glyn

I am recently working on a binary protocol oriented network framework
based on ASIO in my project. So I do care more about a binary protocol
oriented message type. so I have once asked Dean a question during a
private communication:

    What's the granularity of the Tag template parameter of
    basic_message<> template? One tag per message type (I means
    text/binary here) or one tag per protocol?

And Dean replied:

    The Tag template parameter is meant to differentiate the message
    types -- for easy extension. That means, to be clear, the message
    tags I envision are:

    tags::unicode
    tags::text (tags::default_)
    tags::binary
    tags::stream
    tags::serializable_text
    tags::serializable_binary
    tags::serializable_xml

    Among many others I haven't thought of yet. :D

    They are tags, because I don't intend to put the overhead of an
    abstract message class as the base class for all the message
    types.  That allows us to implement a basic_message<tags::text>
    and basic_message<tags::binary>, and specialize the
    implementations without having to rely on inheritance and runtime
    polymorphism.

As Dean stated, with such tags, we can specialize different message
types. And I think the message type tags should imply the underlying
storage policy of that type of basic_message. Say, tags::text
(tags::default_) implies an std::string storage facility, while
tags::unicode implies an std::wstring storage facility, and
tags::stream may implies a boost::asio::streambuf storage facility (as
what I've done in my own project). So I suggest we could include a
storage_type in the tags struct:

    struct tags {
        struct default_ {
            typedef std::string storage_type;
        };

        typedef default_::text;

        struct unicode {
            typedef std::wstring storage_type;
        };

        struct stream {
            typedef boost::asio::streambuf storage_type;
        };

        ...
    };

    typedef basic_message<tags::text> message;
    typedef basic_message<tags::unicode> wmessage;
    typedef basic_message<tags::stream> smessage;
    ...

Would this be sane?

Cheers
Cheng


Glyn Matthews wrote:
> Guys,
>
> I've been giving a little thought to something Dean mentioned in his 
> last message about using std::string in the network library.
>
> The first thing I thought of was that Dean stated that "everything is 
> a template".  Apart of course from std::string.  I have created a 
> branch in SVN named gxm) which replaces all references to std::string 
> with an extra template parameter.  Happily, this passes all the 
> original tests (with an additional template specialization so that 
> const char * is converted to a std::string).  However, this creates a 
> problem (certainly with GCC) because the wchar_t typedef is the same 
> as char and its not possible to overload const wchar_t * in the same 
> way.  So the following code will not compile:
>
> wmessage wmsg;
> wmsg << header(L"wide characters");
>
> Another thing I see is that boost filesystem and boost program_options 
> have dealt with a very similar problem to this.  But if we use the 
> same approach (see the file "boost/detail/utf8_codecvt_facet.hpp" )  
> then we'd have to accept the use of a cpp source file, meaning we will 
> no longer have a header only library.
>
> What do others think about this?
>
> G
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

Re: [cpp-netlib-devel] Dependence on std::string

[Cheng L. <rhy...@gm...>]

By the way, I wish that Dean may explain the seven proposed tags in 
detail, especially the binary tag and the stream tag which seems may 
feed my appetite :-D

连城 wrote:
> Hi, Glyn
>
> I am recently working on a binary protocol oriented network framework
> based on ASIO in my project. So I do care more about a binary protocol
> oriented message type. so I have once asked Dean a question during a
> private communication:
>
>    What's the granularity of the Tag template parameter of
>    basic_message<> template? One tag per message type (I means
>    text/binary here) or one tag per protocol?
>
> And Dean replied:
>
>    The Tag template parameter is meant to differentiate the message
>    types -- for easy extension. That means, to be clear, the message
>    tags I envision are:
>
>    tags::unicode
>    tags::text (tags::default_)
>    tags::binary
>    tags::stream
>    tags::serializable_text
>    tags::serializable_binary
>    tags::serializable_xml
>
>    Among many others I haven't thought of yet. :D
>
>    They are tags, because I don't intend to put the overhead of an
>    abstract message class as the base class for all the message
>    types.  That allows us to implement a basic_message<tags::text>
>    and basic_message<tags::binary>, and specialize the
>    implementations without having to rely on inheritance and runtime
>    polymorphism.
>
> As Dean stated, with such tags, we can specialize different message
> types. And I think the message type tags should imply the underlying
> storage policy of that type of basic_message. Say, tags::text
> (tags::default_) implies an std::string storage facility, while
> tags::unicode implies an std::wstring storage facility, and
> tags::stream may implies a boost::asio::streambuf storage facility (as
> what I've done in my own project). So I suggest we could include a
> storage_type in the tags struct:
>
>    struct tags {
>        struct default_ {
>            typedef std::string storage_type;
>        };
>
>        typedef default_::text;
>
>        struct unicode {
>            typedef std::wstring storage_type;
>        };
>
>        struct stream {
>            typedef boost::asio::streambuf storage_type;
>        };
>
>        ...
>    };
>
>    typedef basic_message<tags::text> message;
>    typedef basic_message<tags::unicode> wmessage;
>    typedef basic_message<tags::stream> smessage;
>    ...
>
> Would this be sane?
>
> Cheers
> Cheng
>
>
> Glyn Matthews wrote:
>> Guys,
>>
>> I've been giving a little thought to something Dean mentioned in his 
>> last message about using std::string in the network library.
>>
>> The first thing I thought of was that Dean stated that "everything is 
>> a template".  Apart of course from std::string.  I have created a 
>> branch in SVN named gxm) which replaces all references to std::string 
>> with an extra template parameter.  Happily, this passes all the 
>> original tests (with an additional template specialization so that 
>> const char * is converted to a std::string).  However, this creates a 
>> problem (certainly with GCC) because the wchar_t typedef is the same 
>> as char and its not possible to overload const wchar_t * in the same 
>> way.  So the following code will not compile:
>>
>> wmessage wmsg;
>> wmsg << header(L"wide characters");
>>
>> Another thing I see is that boost filesystem and boost 
>> program_options have dealt with a very similar problem to this.  But 
>> if we use the same approach (see the file 
>> "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to accept the 
>> use of a cpp source file, meaning we will no longer have a header 
>> only library.
>>
>> What do others think about this?
>>
>> G
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Cpp-netlib-devel mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>>   
>
>

Re: [cpp-netlib-devel] Dependence on std::string

[Dean M. B. <mik...@gm...>]

Hi Glyn!

On 7/17/07, Glyn Matthews <gly...@gm...> wrote:
> Guys,
>
> I've been giving a little thought to something Dean mentioned in his last
> message about using std::string in the network library.
>
> The first thing I thought of was that Dean stated that "everything is a
> template".  Apart of course from std::string.  I have created a branch in
> SVN named gxm) which replaces all references to std::string with an extra
> template parameter.  Happily, this passes all the original tests (with an
> additional template specialization so that const char * is converted to a
> std::string).  However, this creates a problem (certainly with GCC) because
> the wchar_t typedef is the same as char and its not possible to overload
> const wchar_t * in the same way.  So the following code will not compile:
>
> wmessage wmsg;
> wmsg << header(L"wide characters");
>
> Another thing I see is that boost filesystem and boost program_options have
> dealt with a very similar problem to this.  But if we use the same approach
> (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then
> we'd have to accept the use of a cpp source file, meaning we will no longer
> have a header only library.
>
> What do others think about this?
>

I haven't checked out your code yet, but I'm excited to see how this
works (or breaks). :)

Our problem primarily here is that header(L"key", L"value") is an
inline method which returns a specific instance of type
header_directive<tags::default_>. Now if we overloaded that inline
method with say something like:

    inline impl::header_directive<tags::unicode>
    header(typename tags::unicode::str_type const & header_name,
            typename tags::unicode::str_type const & header_value) {
        return impl::header_directive<tags::unicode>(header_name,
                header_value);
    };

And then do a typedef such as:

  typedef basic_message<tags::unicode> message_w ;
  typedef basic_message<tags::unicode> wide_message ;
  typedef basic_message<tags::unicode> message_wide ;

We'd also like to then have tags::unicode typedef the correct type for
the string as 'str_type'. That way we can customize just tags::unicode
for different platforms, and have the check for GCC implement the
correct type there.

Would you think that works? I hope I made sense... :D

(Cheng, I will indulge you with that request from the other email...
Let me write down my thoughts.) :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Dependence on std::string

[Dean M. B. <mik...@gm...>]

SGkgQ2hlbmchCgpPbiA3LzE4LzA3LCDBrLPHIDxyaHl0aG0ubWFpbEBnbWFpbC5jb20+IHdyb3Rl
Ogo+IEhpLCBHbHluCj4KPiBJIGFtIHJlY2VudGx5IHdvcmtpbmcgb24gYSBiaW5hcnkgcHJvdG9j
b2wgb3JpZW50ZWQgbmV0d29yayBmcmFtZXdvcmsKPiBiYXNlZCBvbiBBU0lPIGluIG15IHByb2pl
Y3QuIFNvIEkgZG8gY2FyZSBtb3JlIGFib3V0IGEgYmluYXJ5IHByb3RvY29sCj4gb3JpZW50ZWQg
bWVzc2FnZSB0eXBlLiBzbyBJIGhhdmUgb25jZSBhc2tlZCBEZWFuIGEgcXVlc3Rpb24gZHVyaW5n
IGEKPiBwcml2YXRlIGNvbW11bmljYXRpb246Cj4KPiAgICAgV2hhdCdzIHRoZSBncmFudWxhcml0
eSBvZiB0aGUgVGFnIHRlbXBsYXRlIHBhcmFtZXRlciBvZgo+ICAgICBiYXNpY19tZXNzYWdlPD4g
dGVtcGxhdGU/IE9uZSB0YWcgcGVyIG1lc3NhZ2UgdHlwZSAoSSBtZWFucwo+ICAgICB0ZXh0L2Jp
bmFyeSBoZXJlKSBvciBvbmUgdGFnIHBlciBwcm90b2NvbD8KPgo+IEFuZCBEZWFuIHJlcGxpZWQ6
Cj4KPiAgICAgVGhlIFRhZyB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaXMgbWVhbnQgdG8gZGlmZmVyZW50
aWF0ZSB0aGUgbWVzc2FnZQo+ICAgICB0eXBlcyAtLSBmb3IgZWFzeSBleHRlbnNpb24uIFRoYXQg
bWVhbnMsIHRvIGJlIGNsZWFyLCB0aGUgbWVzc2FnZQo+ICAgICB0YWdzIEkgZW52aXNpb24gYXJl
Ogo+Cj4gICAgIHRhZ3M6OnVuaWNvZGUKPiAgICAgdGFnczo6dGV4dCAodGFnczo6ZGVmYXVsdF8p
Cj4gICAgIHRhZ3M6OmJpbmFyeQo+ICAgICB0YWdzOjpzdHJlYW0KPiAgICAgdGFnczo6c2VyaWFs
aXphYmxlX3RleHQKPiAgICAgdGFnczo6c2VyaWFsaXphYmxlX2JpbmFyeQo+ICAgICB0YWdzOjpz
ZXJpYWxpemFibGVfeG1sCj4KPiAgICAgQW1vbmcgbWFueSBvdGhlcnMgSSBoYXZlbid0IHRob3Vn
aHQgb2YgeWV0LiA6RAo+Cj4gICAgIFRoZXkgYXJlIHRhZ3MsIGJlY2F1c2UgSSBkb24ndCBpbnRl
bmQgdG8gcHV0IHRoZSBvdmVyaGVhZCBvZiBhbgo+ICAgICBhYnN0cmFjdCBtZXNzYWdlIGNsYXNz
IGFzIHRoZSBiYXNlIGNsYXNzIGZvciBhbGwgdGhlIG1lc3NhZ2UKPiAgICAgdHlwZXMuICBUaGF0
IGFsbG93cyB1cyB0byBpbXBsZW1lbnQgYSBiYXNpY19tZXNzYWdlPHRhZ3M6OnRleHQ+Cj4gICAg
IGFuZCBiYXNpY19tZXNzYWdlPHRhZ3M6OmJpbmFyeT4sIGFuZCBzcGVjaWFsaXplIHRoZQo+ICAg
ICBpbXBsZW1lbnRhdGlvbnMgd2l0aG91dCBoYXZpbmcgdG8gcmVseSBvbiBpbmhlcml0YW5jZSBh
bmQgcnVudGltZQo+ICAgICBwb2x5bW9ycGhpc20uCj4KPiBBcyBEZWFuIHN0YXRlZCwgd2l0aCBz
dWNoIHRhZ3MsIHdlIGNhbiBzcGVjaWFsaXplIGRpZmZlcmVudCBtZXNzYWdlCj4gdHlwZXMuIEFu
ZCBJIHRoaW5rIHRoZSBtZXNzYWdlIHR5cGUgdGFncyBzaG91bGQgaW1wbHkgdGhlIHVuZGVybHlp
bmcKPiBzdG9yYWdlIHBvbGljeSBvZiB0aGF0IHR5cGUgb2YgYmFzaWNfbWVzc2FnZS4gU2F5LCB0
YWdzOjp0ZXh0Cj4gKHRhZ3M6OmRlZmF1bHRfKSBpbXBsaWVzIGFuIHN0ZDo6c3RyaW5nIHN0b3Jh
Z2UgZmFjaWxpdHksIHdoaWxlCj4gdGFnczo6dW5pY29kZSBpbXBsaWVzIGFuIHN0ZDo6d3N0cmlu
ZyBzdG9yYWdlIGZhY2lsaXR5LCBhbmQKPiB0YWdzOjpzdHJlYW0gbWF5IGltcGxpZXMgYSBib29z
dDo6YXNpbzo6c3RyZWFtYnVmIHN0b3JhZ2UgZmFjaWxpdHkgKGFzCj4gd2hhdCBJJ3ZlIGRvbmUg
aW4gbXkgb3duIHByb2plY3QpLiBTbyBJIHN1Z2dlc3Qgd2UgY291bGQgaW5jbHVkZSBhCj4gc3Rv
cmFnZV90eXBlIGluIHRoZSB0YWdzIHN0cnVjdDoKPgo+ICAgICBzdHJ1Y3QgdGFncyB7Cj4gICAg
ICAgICBzdHJ1Y3QgZGVmYXVsdF8gewo+ICAgICAgICAgICAgIHR5cGVkZWYgc3RkOjpzdHJpbmcg
c3RvcmFnZV90eXBlOwo+ICAgICAgICAgfTsKPgo+ICAgICAgICAgdHlwZWRlZiBkZWZhdWx0Xzo6
dGV4dDsKPgo+ICAgICAgICAgc3RydWN0IHVuaWNvZGUgewo+ICAgICAgICAgICAgIHR5cGVkZWYg
c3RkOjp3c3RyaW5nIHN0b3JhZ2VfdHlwZTsKPiAgICAgICAgIH07Cj4KPiAgICAgICAgIHN0cnVj
dCBzdHJlYW0gewo+ICAgICAgICAgICAgIHR5cGVkZWYgYm9vc3Q6OmFzaW86OnN0cmVhbWJ1ZiBz
dG9yYWdlX3R5cGU7Cj4gICAgICAgICB9Owo+Cj4gICAgICAgICAuLi4KPiAgICAgfTsKPgo+ICAg
ICB0eXBlZGVmIGJhc2ljX21lc3NhZ2U8dGFnczo6dGV4dD4gbWVzc2FnZTsKPiAgICAgdHlwZWRl
ZiBiYXNpY19tZXNzYWdlPHRhZ3M6OnVuaWNvZGU+IHdtZXNzYWdlOwo+ICAgICB0eXBlZGVmIGJh
c2ljX21lc3NhZ2U8dGFnczo6c3RyZWFtPiBzbWVzc2FnZTsKPiAgICAgLi4uCj4KPiBXb3VsZCB0
aGlzIGJlIHNhbmU/Cj4KCllvdSB0b29rIHRoZSB3b3JkcyBvdXQgb2YgbXkgZW1haWwuIDopCgpF
c3NlbnRpYWxseSwgeW91IGhhdmUgcHJldHR5IG11Y2ggZXhwbGFpbmVkIHdoYXQgSSBoYXZlIGJl
ZW4gdGhpbmtpbmcKb2YgZG9pbmcgYWxsIHRoaXMgd2hpbGUuIFRoZSAndGFnJyBpcyBtZWFudCB0
byBkaWZmZXJlbnRpYXRlIGJldHdlZW4KaW1wbGVtZW50YXRpb25zIG9mIHRoZSBtZXNzYWdlIHR5
cGUsIGFuZCB0aHVzIHRoZSBiZWhhdmlvciBvZiB0aGUKYWxnb3JpdGhtcyB0aGF0IG9wZXJhdGUg
b24gdGhlc2UgbWVzc2FnZSB0eXBlcy4gU28gc2luY2Ugd2UgaGF2ZSAob3IKc2hvdWxkIGhhdmUp
IHRoZSBUYWcgdGVtcGxhdGUgcGFyYW1ldGVyIGluIGFsbCB0aGUgaW1wbGVtZW50YXRpb25zIG9m
CnRoZSBhbGdvcml0aG1zLCB3ZSBzaG91bGQgYmUgYWJsZSB0byByZWZhY3RvciB0aGVtIGFwcHJv
cHJpYXRlbHkgdG8KbWFrZSB0aGVtIGVpdGhlcgoKICAxKSB3b3JrIGRpZmZlcmVudGx5IGZvciBk
aWZmZXJlbnQgbWVzc2FnZSB0eXBlcwogIDIpIG5vdCBiZSBhdmFpbGFibGUgZm9yIHNlbGVjdGVk
IG1lc3NhZ2UgdHlwZXMgb3IKICAzKSBiZSBnZW5lcmljIGVub3VnaCB0byB3b3JrIHdpdGggYWxs
IHRoZSBtZXNzYWdlIHR5cGVzCgotLSB0aGlzIHdvdWxkIGFsbG93IHVzIHRvIGdyb3cgdGhlIGxp
YnJhcnkgYXMgbmVjZXNzYXJ5IGluIGRpZmZlcmVudApkaXJlY3Rpb25zIGZvciBiaW5hcnkgaW1w
bGVtZW50YXRpb25zLCB1bmljb2RlIGltcGxlbWVudGF0aW9ucywKc3RhbmRhcmQgc3RyaW5nIGlt
cGxlbWVudGF0aW9ucywgZXRjLgoKUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoYXQncyBub3QgY2xl
YXIgeWV0LiBCYXNpY2FsbHkgdGhvdWdoIENoZW5nJ3MKcXVvdGluZyBteSBtZXNzYWdlIHRvIGhp
bSAod2hpY2ggSSB0aGluayBzaG91bGQgaGF2ZSBiZWVuIENDJ2VkIG9yCnNlbnQgdG8gdGhlIG1h
aWxpbmcgbGlzdCBhcyB3ZWxsLCA7KSApIHByZXR0eSBtdWNoIGV4cGxhaW5zIHdoYXQgSSBoYWQK
aW4gbWluZC4KCj4gQ2hlZXJzCj4gQ2hlbmcKPgoKVGhhbmtzIHZlcnkgbXVjaCBDaGVuZyBmb3Ig
cG9zdGluZyB0aGUgYWJvdmUgZXhwbGFuYXRpb24hCgpTbyBHbHluLCB3b3VsZCB5b3UgdGhpbmsg
dGhlIGFib3ZlIGluc2lnaHRzL3N1Z2dlc3Rpb25zIGhlbHA/CgotLSAKRGVhbiBNaWNoYWVsIEMu
IEJlcnJpcwpodHRwOi8vY3BsdXNwbHVzLXNvdXAuYmxvZ3Nwb3QuY29tLwptaWtoYWlsYmVyaXMg
QVQgZ21haWwgRE9UIGNvbQorNjMgOTI4IDcyOTE0NTkK

Re: [cpp-netlib-devel] Dependence on std::string

[Glyn M. <gly...@gm...>]

Q2hlbmcsIERlYW4sCgpPbiAxOC8wNy8wNywgRGVhbiBNaWNoYWVsIEJlcnJpcyA8bWlraGFpbGJl
cmlzQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPiBIaSBDaGVuZyEKPgo+IE9uIDcvMTgvMDcsIMGss8cg
PHJoeXRobS5tYWlsQGdtYWlsLmNvbT4gd3JvdGU6Cj4gPiBIaSwgR2x5bgo+ID4KPgo+IFRoYW5r
cyB2ZXJ5IG11Y2ggQ2hlbmcgZm9yIHBvc3RpbmcgdGhlIGFib3ZlIGV4cGxhbmF0aW9uIQo+Cj4g
U28gR2x5biwgd291bGQgeW91IHRoaW5rIHRoZSBhYm92ZSBpbnNpZ2h0cy9zdWdnZXN0aW9ucyBo
ZWxwPwoKCgpZZXMsIHRoYXQncyBjbGFyaWZpZWQgdGhpbmdzIGZvciBtZS4gIEkgaGF2ZSB0byBi
ZSBob25lc3QgYW5kIHNheSBJIGRpZG4ndApyZWFsaXNlIHRoYXQgdGhlIHRhZ3Mgd291bGQgYWxz
byBzcGVjaWFsaXplIGhvdyB0aGUgc3RyaW5nIHdvdWxkIGJlCnN0b3JlZC4gICBCdXQgSSBzZWUg
bm93IHRoZSBiZW5lZml0cyBvZiB0aGlzIGFwcHJvYWNoLgoKU28gaXRzIG5vdCBub3cgd29ydGgg
bG9va2luZyBhdCB0aGUgY29kZSBJIGRldmVsb3BlZCAodW5sZXNzIHlvdSB0aGluayB5b3UKZ2Fy
bmVyIHNvbWV0aGluZyBlbHNlIG91dCBvZiBpdCksIGJ1dCBhdCBsZWFzdCBpdCBsZWQgbWUgdG8g
bGVhcm4gc29tZXRoaW5nCm5ldyA7KQpHbHluCg==