- Boost - lists.boost.org

Re: [boost] [Serialization] Formal Review
by Robert Ramey 19 Apr '04

19 Apr '04

Matthew Vogt wrote: * What is your evaluation of the documentation? ... > I think the documentation addresses extending the library with > serialization of external types better than it addresses extending the > library with new archives (although, this is probably a biased view :) ) True. I didn't anticipate this much interest in making new archive classes. Also making a new archive class is harder than specifying a new serialization so I spent less effort on explaining it. > That said, the library seems not to limit anything an archive implementor > may want to do. My only remaining concern is regarding controlling access > to indiviual overloads of 'save' or 'load'. This seems to break down, due > to the fact that all accesses are from the 'access' class. I would be curious to see a specific example of this. 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. Some sections of code are definitely candidates for extraction from the serialization library, largely identified by Robert in the 'Miscellaneous' section of the documentation. The strong typedef and state_saver utilities could be extracted, perhaps to the utility library. Perhaps the extended type info infrastructure is useful outside the library. > The dataflow iterators are very interesting, but I'm not sure how they > interact with the iterator adaptors library, or with sandbox views > library. I would love to see separate discussion of this (on a separate thread please). This area overlaps with iteratator adaptors and views an maybe collection traits and who know what else. This is something I've always wanted and now I (almost) have it. My current implementation (not yet uploaded) is much improved but has the same interface and intention. > The unicode conversion code is certainly useful, but I imagine it might be > better to leave it as an implementation detail of serialization, until > someone volunteers to investigate a complete solution for this issue. I would love to see someone take this out. Ron Garcia wrote this and it worked to my satisfaction. I had problems making a good test and with portability to other compilers/libraries. Maybe Ron or someone else wants to move this to somewhere else. Robert Ramey

3 2

Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 19 Apr '04

19 Apr '04

Matthew Vogt wrote: > Yes, I had better explain here. In the case that I'm addressing, the > format is not a means to an end, but an end in itself. The goal of this > effort is to use the serialization library framework not to produce > reversible transformations between arbitrary C++ and a byte stream, but to > take targeted C++ objects and produce known binary representations. > I don't think it is a case of coupling, merely one of limitation. An > object that can be serialized into XDR format must use only a limited > range of C++ types in it's composition - but having accepted that > limitation, it can still be serialized into a less limiting archive type > with the same code. OK - I'm still wary, but if you find this doable and useful more power to you. > > 3) I'm curious about the override for the saving of vector. ... > > > I need to override the serialization of vector, because the vector must be > > serialized with a known policy to yield a required layout in the archive. > > The fact that this serialization happens (at this point in time) to be > > exactly the same as the default implementation is not relevant - that can > > be changed at any time, but the CDR, XDR and other binary formats must > > not change. > > I'm still not convinced - its seems to me that it shouldn't need to be > overridden for XDR and CDR which is what these classes do. What about list, > deque, set, etc. > > 3) I'm curious about the override for the saving of vector. ... > Well, I never thought these were necessary, remembering that I am > providing for classes, which are designed to be serialized into a > particular binary format. In a binary format, all collections will boil > down to a group of repetitions, which are either preceded by a > length/count argument, or whose length is a defined property of the > format itself. Correct. That's exactly what the current implementations of STL classes do. So my question is why override vector for you xdr/cdr archives? > For me, vector has always sufficed, in either fixed_length<>, or > variable_length<> guise. Perhaps others have differing experience. For your xdr/cdr archives to appealing to the boost users that have asked for this and for these archives to be tested to the same standards, all STL collections will have to be handled. I do not think the override for vector is necessary. If it is necessary then its probably necessary to provide overrides for all the STL collection classes. > But there are inherent limitations in marshalling (per my usage). > Pointers, which are adeptly handled by the general library, are not valid > elements of a marshalled data set. I disagree here, I think the ability to pass "equivalent" pointers across space( marshalling ) is just as valuable as the ability to pass them acrose time ( persistence ). This puts a fine point on my views. I think that in the past, much of the difficulty of the topic was due the fact that different people viewed in terms of marshalling and other in terms of persistence and there is a lot of overlap. (One attempt to define "serialization" when to 200 words !). I believe my definition as stated in the start of the documentation factored out the commonality and I resolved to focus on that. I also believe that this has turned out to be one of the main reasons that the library has been embraced to the extent that it has. This explains my reluctance to consider Marshalling as a special case. I would like to see your xdr/cdr archives finished off at the same level of generality as the other archives. Any special purpose marshalling would leverage off that. Robert Ramey

2 1

Re: Re: Serialization Formal Review #2
by Robert Ramey 19 Apr '04

19 Apr '04

Matthias Troyer wrote: > I have two more questions regarding the serialization library which I > need to have answered before I can see if I can read my old archives > with your library: > 1. when overloading the save/load functions in an archive, do I bypass > writing preambles and other class information or do I need to overload > operator <<? What is the difference between implementing operator<< and > save? > 2. which functions do I need to implement in my archive class to skip > writing the standard preamble that your archives write? Is it just the > init function or are there more functions? Depending on the implementation traits for each class, there may be a preamble written by the serialization library. This contains information such as version number, class id info, perhaps export key, etc required by the s library to reconstruct a faithful reproduction of the original data. If there is a preamble, there is no information in that can be discarded and still reproduce the original data. In general it can't be guaranteed that one can read an arbitrary file format created independently of the serialization library. With the serialization library, it's the class/instance structure that drives the file format rather than the other way around. To transition to use the serialization library the strategy would be: a) add serialization to the classes desired. b) write a program which reads the "old" data files using the "old" method - whatever that might be. c) invoke serialization to save in the desired new format. The old data files should no longer be necessary. Best regards Matthias

2 1

Re: [boost] a note on serialization docs
by Robert Ramey 19 Apr '04

19 Apr '04

David Abrahams wrote: > When viewing [boost] a note on serialization docs > http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, > the right ends of some of the words are tucked underneath the > scrollbar at the right of the window. The HTML or stylesheet should > have some kind of margin to prevent this effect. This annoys me also. Even worse is thie fact that some lines don't break. I've toyed around with this but haven't found the fix. Its especially odd to me given that it imports the style.css from the boost directory but other pages don't show this behavior. I believe its some MSIE quirk. If anyone knows how to address this I'm all ears. Robert Ramey

1 0

static sized strings
by Reece Dunn 19 Apr '04

19 Apr '04

There is currently a static-sized array in the Boost library that allows you to operate on arrays of fixed size. I was wondering if something similar exists for strings, in particular, providing buffer-overflow safe string operations. I have an nstring< std::size_t n > string class that provides size-safe copying and comparison, allowing for you to do things like: nstring< 20 > s; s.copy( "Hello World!" ) if( s == "Hello" ) ... // note: this will succeed! This is useful for things like processing file format headers, as it allows things like: struct tar_header { nstring< 100 > name; ... nstring< 8 > magic; ... }; if( hdr.magic == "ustar\x20\x20\0" ) // GNU TAR archive ... else if( hdr.magic == "ustar\0" ) // POSIX TAR archive ... else // invalid format I also have a formatter class that provides buffer-safe printf-like operations on the constructor and as a functor, e.g.: formatter< 512 > fmt( "%s: %s", type, msg ); std::cout << fmt << '\n'; std::cout << fmt( "error: %s", msg ) << '\n'; This can be useful when you need to format a string without making use of a string buffer, e.g.: std::ostringstream fmt; fmt << type << ": " << msg; std::cout << fmt.str() << '\n'; fmt.str( std::string()); // clear string buffer fmt << "error: " << msg; std::cout << fmt.str() << '\n'; Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

[thread] again ;)
by John Torjo 19 Apr '04

19 Apr '04

Dear boosters, As far as I've heard a while back, the only reason [thread] library cannot be built as a static library was because of TSS. That to me (and to others as I've seen) seems quite a show-stopper - in a lot of apps I don't use the [thread] lib just because of this. Most of my multi-threaded applications (around 95%) and as I know a lot of other multi-threaded apps. don't need TSS. Even if they do, usually they don't need advanced clean-up code (reason for why [thread] was required to be a DLL). ***Most*** of the time, any allocated TSS objects can be let to leak resources (which they hardly have - mostly IMHO some small amount of allocated memory). The above make me think that we really should enable [thread] to be a static library again ;). It should be documented in the docs that the static version of the [thread] runtime will leak TSS objects, and users can choose whether they will use [thread] as a DLL or as a runtime static lib. What do others think? As a side-note, allowing the [thread] lib to be a static lib is quite simple (please you gurus out there, correct me if I'm wrong). In fact, here's the patch. (note: config.hpp = boost/thread/detail/config.hpp, and I did not modify the jamfile.V2, since I can't test it) Best, John // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP #define BOOST_THREAD_CONFIG_WEK01032003_HPP #include <boost/config.hpp> // insist on threading support being available: #include <boost/config/requires_threads.hpp> #if defined(BOOST_HAS_WINTHREADS) # if defined(BOOST_THREAD_BUILD_DLL) # define BOOST_THREAD_DECL __declspec(dllexport) # elif defined(BOOST_DYN_LINK) // john.torjo # define BOOST_THREAD_DECL __declspec(dllimport) # else # define BOOST_THREAD_DECL // linking to library # endif #else # define BOOST_THREAD_DECL #endif // BOOST_HAS_WINTHREADS // john.torjo /* // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_thread // // If we're importing code from a dll, then tell auto_link.hpp about it: // # define BOOST_DYN_LINK // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled */ #endif // BOOST_THREAD_CONFIG_WEK1032003_HPP # Copyright (C) 2001-2003 # William E. Kempf # # Permission to use, copy, modify, distribute and sell this software # and its documentation for any purpose is hereby granted without fee, # provided that the above copyright notice appear in all copies and # that both that copyright notice and this permission notice appear # in supporting documentation. William E. Kempf makes no representations # about the suitability of this software for any purpose. # It is provided "as is" without express or implied warranty. # # Boost.Threads build Jamfile # # Additional configuration variables used: # 1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32 # library should be used instead of "native" threads. This feature is # mostly used for testing and it's generally recommended you use the # native threading libraries instead. PTW32 should be set to be a list # of two strings, the first specifying the installation path of the # pthreads-win32 library and the second specifying which library # variant to link against (see the pthreads-win32 documentation). # Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib" # Declare the location of this subproject relative to the root. subproject libs/thread/build ; # Include threads.jam for Boost.Threads global build information. # This greatly simplifies the Jam code needed to configure the build # for the various Win32 build types. import ./threads ; { template thread_libs ## sources ## : <template>thread_base ## requirements ## : <sysinclude>$(BOOST_ROOT) ## default build ## : ; # Base names of the source files for libboost_thread. CPP_SOURCES = condition mutex recursive_mutex thread tss xtime once exceptions barrier threadmon ; lib boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <runtime-link>static # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; dll boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <define>BOOST_THREAD_BUILD_DLL=1 <runtime-link>dynamic # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; stage bin-stage : <dll>boost_thread <lib>boost_thread #: <tag><debug>"d" : debug release ; install thread lib : <dll>boost_thread <lib>boost_thread ; }

3 6

Re: Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 19 Apr '04

19 Apr '04

Jeff Garland wrote: > I believe that Matthew has now demonstrated that archive extension is > possible, which I believe is one of the major changes from the first > review. That said, any documentation of this process would clearly be a > plus. In a typical proprietary archives writing of the version and type > numbers will need to be shut off. So I can imagine documenting these > sorts of issues. As it turns out, type id, and object id are really required only for pointers and version is in fact optional. It would be possible to make an archive which: a) trapped (BOOST_STATIC_ASSERT) attempts to serialize a pointer b) trapped attempt to save/load object id and class id c) implemented null serialization of version numbers and trapped attempts to use version number != 0 This would work only on serializations that had implementation attributes of no versioning, and no object tracking. If used on other types, it would trap at compiler time. I believe that you would have what you wanted. In general, the part of the library which saves/loads the preamble is invoked only for pointers. An easy way to check this is to generate XML archive and find that there are not attributes for this types. Robert Ramey

2 1

a note on serialization docs
by David Abrahams 19 Apr '04

19 Apr '04

When viewing http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, the right ends of some of the words are tucked underneath the scrollbar at the right of the window. The HTML or stylesheet should have some kind of margin to prevent this effect. Cheers, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 1

Re:Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 19 Apr '04

19 Apr '04

> Jeff Garland writes: > Yes, for 'random access' archives (think relational database buffer here) > it's possible the archive process will need additional meta-data not > provided in the base library setup (think mapping of classes to tables and > attributes to columns). And yes, I've implemented this one before as well > -- it's a very handy bit of infrastructure. > but in fact I believe given the current library it could now > be done by writing and archive and perhaps some enhancements to the > registration. I faced the same problem with XML meta-data. I resolved with the NVP wrapper which kept XML out of the library core - really a big thing for me as I have had to continually refactor to keep things from growing totally out of control. I'm sure this idea of making a wrapper which includes meta-data along with the data itself is going to be useful in cases like this. > I think in the past Robert has considered this "out of scope", Well, yes. I have fought a continuing battle to limit scope. > BTW, I think the references should include a reference to this paper which > discusses many of these variations and design issues. > http://www.ubilab.org/publications/print_versions/pdf/plop-96-serializer.pdf I've seen this paper, and at this suggestion was made before. I think I included a reference to it but the link moved. There's another whole field to plow regarding web references as opposed to published ones. Robert Ramey

1 0

move semantics
by Andrea Torsello 19 Apr '04

19 Apr '04

Hi, I have been investigating move semantics and think that I came up with a solution that is strongly influenced by both David Abrahams' move approach and Andrei Alexandrescu's mojo, but solves some of the problems I have encountered with them. The basic idea is to use the explicit keyword to force the compiler to use the X(X const &) constructor only in two cases. 1) When explicitly copying a const object i.e. X const x; X y(x); //use explicit copy constructor 2) When passing by const ref void f(X const &); X makeX(); void foo() { f(makeX()); //use explicit copy constructor } In all other cases the other constructor take precedence. Note that the template trick David Abrahams uses in his move approach would lead to an error on a conforming compiler when confronted with case #2 (unless more recent versions corrected this). I chose to keep the temporary and constant subtypes from mojo because they allow me to discriminate between const values, non-const rvalues and non-const rvalues. The lack of this capability was the major problem I had with David Abrahams' move. My use-case was a vector-like container that increases but never decreases the size of its backing store. In order to provide the never decreasing backing-store semantic, operator = moves the backing store from a temporary only if the new data does not fit in the existing space. Hence, operator = must be able to discriminate between temporaries and non-temporaries. My solution fullfills almost all the requirements I had: 1) passing by value moves non-const rvalues and copies everithing else. 2) its is transparent to the user of the class. Alexandrescu's Mojo fails this because of the special return type, while Abrahams' move fails it because of the pass-by-const-ref problem described above. 3) it allows to discriminate between constants, non-const lvalues, and non-const rvalues. Alexandrescu's Mojo allows it, while Abrahams' move does not. 4) Provides move semantics to templated classes with (almost) no odd side-effect. The only side-effect is that template type deduction does not work with temporary discrimination. Hence in the sample code the template type of the "discriminate" function must be specified explicitly. please find attached a sample file illustrating my move approach. I tested the code with gcc 3.3.1 and successfully compiled it with comeau online. What do you think? Andrea Torsello P.S. please cc me as I am not subscribed and I check the mailinglist archives sporadically begin 666 move_test.cc M(VEN8VQU9&4\:6]S=')E86T^#0H-"@T*=7-I;F<@<W1D.CIC;W5T.PT*=7-I M;F<@<W1D.CIE;F1L.PT*#0IN86UE<W!A8V4@;6]V90T*>PT*"71E;7!L871E M(#QC;&%S<R!4/B!S=')U8W0@96YA8FQE9 T*"7L-"@D)8VQA<W,@8V]N<W1A M;G0@+R\@='EP92!S=6=A<B!F;W(@8V]N<W1A;G1S#0H)"7L-"@D)8V]N<W0@ M5"H@9&%T85\[#0H)"7!U8FQI8SH-"@D)97AP;&EC:70@8V]N<W1A;G0H8V]N M<W0@5"8@;V)J*2 Z(&1A=&%?*"9O8FHI('M]#0H)"6-O;G-T(%0F(&=E="@I M(&-O;G-T('L@<F5T=7)N("ID871A7SL@?0T*"0E].PT*#0H)"6-L87-S('1E M;7!O<F%R>2 Z('!R:79A=&4@8V]N<W1A;G0@+R\@='EP92!S=6=A<B!F;W(@ M=&5M<&]R87)I97,-"@D)>PT*"0EP=6)L:6,Z#0H)"65X<&QI8VET('1E;7!O M<F%R>2A4)B!O8FHI(#H@8V]N<W1A;G0H;V)J*2![?0T*"0E4)B!G970H*2!C M;VYS="![(')E='5R;B!C;VYS=%]C87-T/%0F/BAC;VYS=&%N=#HZ9V5T*"DI M.R!]#0H)"7T[#0H-"@EO<&5R871O<B!T96UP;W)A<GDH*0T*"7L-"@D@(" @ M<F5T=7)N('1E;7!O<F%R>2AS=&%T:6-?8V%S=#Q4)CXH*G1H:7,I*3L-"@E] M#0H);W!E<F%T;W(@8V]N<W1A;G0H*2!C;VYS= T*"7L-"@D@(" @<F5T=7)N M(&-O;G-T86YT*'-T871I8U]C87-T/&-O;G-T(%0F/B@J=&AI<RDI.PT*"7T- M"@T*#0H)<')O=&5C=&5D.@T*"0EE;F%B;&5D*"D@>WT@+R\@:6YT96YD960@ M=&\@8F4@9&5R:79E9"!F<F]M#0H)"7YE;F%B;&5D*"D@>WT@+R\@:6YT96YD M960@=&\@8F4@9&5R:79E9"!F<F]M#0H)?3L-"GT-"@T*=&5M<&QA=&4\='EP M96YA;64@5#X-"F-L87-S(%D@.B!P=6)L:6,@;6]V93HZ96YA8FQE9#Q9/%0^ M(#X-"GL-"G!U8FQI8SH-"G1Y<&5D968@='EP96YA;64@;6]V93HZ96YA8FQE M9#Q9/%0^(#XZ.G1E;7!O<F%R>2!T96UP;W)A<GD[#0IT>7!E9&5F('1Y<&5N M86UE(&UO=F4Z.F5N86)L960\63Q4/B ^.CIC;VYS=&%N="!C;VYS=&%N=#L- M"@T*62@I('M]#0H-"F5X<&QI8VET(%DH63Q4/B!C;VYS=" F*2![(&-O=70@ M/#P@(F5X<&QI8VET(&-O<'D@8V]N<W1R=6-T;W)<;B([('T-"EDH63Q4/B8I M('L@8V]U=" \/" B;F]N+6-O;G-T(&QV86QU92!C;W!Y(&-O;G1R=6-T;W)< M;B([('T-"EDH8V]N<W1A;G0I('L@8V]U=" \/" B8V]N<W0@8V]P>2!C;VYS M=')U8W1O<EQN(CL@?0T*62AT96UP;W)A<GDI('L@8V]U=#P\(")N;VXM8V]N M<W0@<G9A;'5E(&UO=F4@8V]N<W1R=6-T;W)<;B([('T-"GT[#0H-"@T*=&5M M<&QA=&4\='EP96YA;64@5#X-"ED\5#X@;6%K95DH*2![<F5T=7)N(%D\5#XH M*3M]#0H-"G1E;7!L871E/'1Y<&5N86UE(%0^#0I9/%0^(&-O;G-T(&UA:V59 M8V]N<W0H*2![<F5T=7)N(%D\5#XH*3M]#0H-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9V5T62A9/%0^*2![?0T*#0IT96UP;&%T93QT>7!E;F%M M92!4/@T*=F]I9"!G9719<F5F*%D\5#XF*2![?0T*#0IT96UP;&%T93QT>7!E M;F%M92!4/@T*=F]I9"!G97198V]N<W1?<F5F*%D\5#X@8V]N<W0@)BD@>WT- M"@T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM:6YA=&4H M63Q4/B8I('MC;W5T(#P\(")D:7-C<FEM:6YA=&4Z(&YO;BUC;VYS="!L=F%L M=65<;B([?0T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM M:6YA=&4H='EP96YA;64@63Q4/CHZ8V]N<W1A;G0I('MC;W5T(#P\(")D:7-C M<FEM:6YA=&4Z(&-O;G-T('9A;'5E7&XB.WT-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9&ES8W)I;6EN871E*'1Y<&5N86UE(%D\5#XZ.G1E;7!O M<F%R>2D@>V-O=70@/#P@(F1I<V-R:6UI;F%T93H@;F]N+6-O;G-T(')V86QU M95QN(CM]#0H-"FEN="!M86EN*"D-"GL-"ED\:6YT/B!Y,3L-"ED\:6YT/B!C M;VYS="!Y,CL-"@T*63QI;G0^('0Q*'DQ*3L@+R]C;W!Y(&YO;BUC;VYS="!L M=F%L=64-"ED\:6YT/B!T,BAY,BD[("\O8V]P>2!C;VYS="!L=F%L=64-"ED\ M:6YT/B!T,RAM86ME63QI;G0^*"DI.R O+V-O<'D@=&5M<&]R87)Y#0I9/&EN M=#X@=#0H;6%K95EC;VYS=#QI;G0^*"DI.R O+V-O<'D@8V]N<W0@=&5M<&]R M87)Y#0H-"F=E=%EC;VYS=%]R968H>3$I.R O+W!A<W,M8GDM8V]N<W0M<F5F M(&YO;BUC;VYS="!L=F%L=64-"F=E=%EC;VYS=%]R968H>3(I.R O+W!A<W,M M8GDM8V]N<W0M<F5F(&-O;G-T(&QV86QU90T*9V5T66-O;G-T7W)E9BAM86ME M63QI;G0^*"DI.R O+W!A<W,M8GDM8V]N<W0M<F5F(&YO;BUC;VYS="!T96UP M;W)A<GD-"F=E=%EC;VYS=%]R968H;6%K95EC;VYS=#QI;G0^*"DI.R\O<&%S M<RUB>2UC;VYS="UR968@8V]N<W0@=&5M<&]R87)Y#0H-"F=E=%DH>3$I.R O M+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T(&QV86QU90T*9V5T62AY,BD[("\O M<&%S<RUB>2UV86QU92!C;VYS="!L=F%L=64-"F=E=%DH;6%K95D\:6YT/B@I M*3L@+R]P87-S+6)Y+79A;'5E(&YO;BUC;VYS="!T96UP;W)A<GD-"F=E=%DH M;6%K95EC;VYS=#QI;G0^*"DI.R O+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T M('1E;7!O<F%R>0T*#0ID:7-C<FEM:6YA=&4\:6YT/BAY,2D[("\O;F]N+6-O M;G-T(&QV86QU90T*9&ES8W)I;6EN871E/&EN=#XH>3(I.R O+V-O;G-T(&QV M86QU90T*9&ES8W)I;6EN871E/&EN=#XH;6%K95D\:6YT/B@I*3L@+R]N;VXM M8V]N<W0@=&5M<&]R87)Y#0ID:7-C<FEM:6YA=&4\:6YT/BAM86ME66-O;G-T M/&EN=#XH*2D[("\O8V]N<W0@=&5M<&]R87)Y#0H-"@T*<F5T=7)N(# [#0I] ` end

5 38