May 2010 - Boost - lists.boost.org

Re: [boost] [MSM] move to trunk
by Christophe Henry 19 May '10

19 May '10

> On 5/18/2010 8:22 AM, Christophe Henry wrote: >> >> I'm a bit jetlagged but (luckily) had an uneventfull trip back. And >> the BoostCon was worth it! > > Indeed! It was great to meet you. It was great to meet you too! >> I plan to check in into the trunk in the next few weeks, I really want >> MSM to be in 1.44. >> I only need to write some unit tests so it should be pretty quick. >> I'll post a mail as soon as I'm done. > > If it's just a matter of unit tests and the interfaces are stable, I > suggest just merging it to trunk now and working on the tests there. > When it's ready, you can merge to release. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com Yes the interfaces and docs are stable, so it is just a matter of writing test cases and add a jam file. Then I will merge MSM to the trunk fast (probably tomorrow) and then start writing the tests. Thanks! Christophe

1 0

sparse_vector class
by Neil Girdhar 19 May '10

19 May '10

boost/numeric/ublas/vector_sparse.hpp implements a "sparse vector" for arithmetic types. I generalized this for default constructible types, and was wondering if anything like this has been considered for inclusion as a separate boost library. Code available on request.

1 0

Boostcon followup - Boost Lockfree review - On behalf of Mark Moir
by Tomas Puverle 19 May '10

19 May '10

I have been in touch with Mark Moir (he was one of the transactional memory speakers at boostcon), wrt the boost lockfree library. As an expert in the field, he was kind enough to do a mini-review. I am posting his comments here and am hoping that these don't get lost in the usual fray of activity, as he is one of the few bona-fide experts in the field that will take the time to actually review the submission. His comments are below: ==== This is mostly a matter of taste, but I don't much care for the approach of having CAS increment the version number, rather than having this explicit in the algorithm, for at least the following reasons: - it is not in keeping with standard cas operations, so an important part of the algorithm appears to be missing; at a minimum, cas should be renamed to cas_and_bump_version or something. - not all algorithms need to increment the version number on every CAS, for example, the stack algorithm is correct provided we increment the version number of every pop; it does not need to be done on push. This is only a (probably minor) performance concern in the stack algorithm, but one can imagine cases in which it would be important not to increment the version every time, and for such cases, a different library would be needed. - There is an awkward mix of handling version numbers in the fifo code. The node constructor explicitly increments the version number, whereas all other dealing with the version number are hidden behind cas, etc. Furthermore, this explicit incrementing is unnecessary, as far as I can tell. To avoid a "late" enqueue accidentally succeeding, the version number of a node's next pointer should be incremented once for each time it goes through the queue. But this is done by the cas of the enqueue that installs a node after it, and I think this is sufficient. I don't like "just in case" code. The authors should understand whether it's really necessary, and if so, document the reason. If (as I suspect), it's not, they should get rid of it. - I also think there should be more comments about these kinds of subtle issues, especially because the Michael & Scott paper played a little fast and loose with this. (Although they do confess to using a free list, there is a strong suggestion that nodes can be "freed" (as opposed to being put in a type-stable free list), and also no discussion of the importance of preserving version numbers of nodes in the free list. - I think there is a bug in the empty method of the fifo, at least for some memory models. (Note too that M*S did not present an empty method, so again additional comments would be appropriate IMO.) The problem is that the order of the reads is critical to ensure correctness, but there is no memory barrier to enforce this ordering. (Note that if either the compiler or the processor reorders the two loads, it is possible for empty to read tail while the queue is nonempty, then another enqueue happens, then all items that were in the queue when tail was read are removed. Now head has the same value as was read from tail previously, so the comparison can succeed and empty can return true, but the queue was never empty.) Again, I think a comment would be appropriate. ====== Hope this is helpful. Best wishes, Tom PS: It was a real pleasure meeting everyone at the conference.

3 4

BoostCon 2011 Hotel Reservation Billing
by David Abrahams 19 May '10

19 May '10

FYI, last year the Meadows' move to an automated reservation system caused some issues with the amount people were charged for reservations. After inquiring specifically into billing for 2011 reservations, this is what I heard back from Doug Crawford: > I met with our reservations team. > For your group, we'll go back to manual deposits. > Aspen Meadows will agree to the following: > Room reservations will be accepted with 1 night deposit > > Balance due 30 days prior to arrival > > Reservations made 30 days or less prior to arrival will be > charged in full. > > Standard reservations cancellations policies apply - > reservations are non refuncable less than 14 days of arrival. ^----------------sounds intriguing, but I think this is meant to say “non-refundable.” ;-) Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

Can Boost accept libraries that works only with C++0x compilers?
by vicente.botet 19 May '10

19 May '10

Hi, Boost has a high reputation due, between others, to having high portable libraries. I was wondering if this portability goal would not return against Boost, and limit the expressivenes of the libraries that can be included if we continue to force them to work with C++98 compilers. Even if C++0x is not yet released, there are already some compilers that allow to release these C++0X specific libraries. In order to have the best of both worlds, what do you think about start accepting libraries that are portable on C++0x compilers? This could be released as a separated package, that will, of course, depend on the current Boost package. I don't know if we need a specific namespace for these kind of libraries. Comments are welcome. Best, Vicente

7 11

Re: [boost] [contract] Boost spoiled function declarations
by Andrzej Krzemienski 18 May '10

18 May '10

> See examples below: Is Boost.Contract parenthesized syntax really more > complex than Boost.Parameter or Boost.Interface? > 1) While I recognize the ugliness of the Boost.Contract parenthesized > syntax, I think it is actually simpler than Boost.Parameter or > Boost.Interface syntax because it is essentially "the usual C++ syntax > with all the tokens wrapped within parenthesis". > 2) It is possible to provide Boost.Contract with macros similar to > ones of Boost.Parameter. Hi, I think you are succesfully making the point that Boost.Contract syntax is no worse than that of Boost.Parameter; and since the latter made it into Boost, the syntax of Boost.Contract should be considered acceptable too. What is interesting is whether it is possible to define a function that validates contracts and allows named parameters at the same time. You already said it was possible. I paste an example from your post below. struct g { CONTRACT_CLASS( (g) ) BOOST_PARAMETER_MEMBER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(num_verticies(graph), index_map)) ) ) CONTRACT_FUNCTION( (public) (template)( (typename)(graph_type) (typename)(visitor_type) (typename)(root_vertex_type) (typename)(index_map_type) (typename)(color_map_type) ) (void) (depth_firt_search)( (graph_type&)(graph) (visitor_type&)(visitor) (root_vertex_type&)(root_vertex) (index_map_type&)(index_map) (copyable)(color_map_type&)(color_map) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; This example is for sure more complex than any Boost.Parameter or Boost.Contract. I believe it should be possible to add another set of macros that would allow defining functions with named parameters and contract verification in a more simpler manner. E.g. something like: struct g { CONTRACT_CLASS( (g) ) CONTRACT_NAMED_PARAM_FUNCTION( // a new macro (public) (void) (depth_firt_search)( (CONTRACT_NAMED_PARAM_REQUIRED_ARG(&graph) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&visitor)(boost::dfs_visitor<>()) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&root_vertex)(*vertices(graph).first) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(&index_map)(get(boost::vertex_index, graph)) CONTRACT_NAMED_PARAM_OPTIONAL_ARG(copyable)(color_map_type&)(color_map) (default_color_map(num_verticies(graph), index_map)) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; Obviously, my example is syntactically wrong and may be impossible, but I think you get the general idea. I am not sure if it is Boost's requirement that different libraries should interoperate smoothly with one another, but it would surely be elegant. I am not sure if this is achievable, as the macro tricks employed in the above libraries are beyond my comprehension. Also, it is not clear whether it should be a task for Boost.Contract maintainer or Boost.Parameter maintainer - the issue seems symmetrical. Regards, &rzej

3 4

[MSM] move to trunk
by Christophe Henry 18 May '10

18 May '10

>Hello Christophe - > >I hope you had an uneventful trip home after boostcon. > >I am starting to use MSM 2.1 this week in a project. I have gotten the >tarball from the sandbox; however, it would be convenient to use the >library from the svn trunk so I can monitor changes before release. Do >you have a time line for checking in the library to trunk? > >Thank you for your time. Take care - >michael Hi Michael, I'm a bit jetlagged but (luckily) had an uneventfull trip back. And the BoostCon was worth it! I plan to check in into the trunk in the next few weeks, I really want MSM to be in 1.44. I only need to write some unit tests so it should be pretty quick. I'll post a mail as soon as I'm done. Cheers, Christophe

2 1

[shared_ptr] enable_shared_from_any ?
by Philip Warner 18 May '10

18 May '10

Many apologies if this has already been debated and discarded, but I have been using boost for a little while now, and most specifically boost::shared_ptr. I recently found enable_shared_from_this{2} and, in SVN, enable_shared_from_raw, and while both of these are extremely useful, ISTM they do not go quite far enough. Specifically, what I would like to see is a solution to the following code: C1 *p = new C1(); shared_ptr<C1> ptr(p); ... ...some time later.... shared_ptr<C1> ptr2<p>; and the resulting mess because of double-deallocation. Yes, one solution id discipline, but for a library developer, a better solution might be robustness in the face of (mild) ignorance or misuse. And yes, this is sloppy, but in our case we have a set of interfaces that want to implement variant function return types based on derived class pointers, and we can not do that by returning shared_ptr objects. We need to return raw pointers, then rewrap them. One solution is shared_from_this etc. Another is to extend shared_from_this so that *any* shared_ptr created from and object that inherits, say, enable_shared_from_any, will always get a shared pointer that works as one might expect. To this end we have built a (trivial) class that inherits from shared_ptr<T> and a matching base class, that together function to achieve what we need. The only real problem is we have to duplicate some parts of shared_ptr (constructors and operators mainly), the second problem is that not being experts in the very fine details of templates, boost, and cross-platform development, it would be extremely convenient if this functionality were implemented within shred_ptr in a similar way to the way enable_shared_from_this is done -- ie. only for those classes that implement an appropriate base class. The third problem is that because it does not have access to shared_ptr internals, it is not as efficient as it might be. Is submitting a patch to shared_ptr the appropriate way forward? Has this been discussed, debated and discarded before? If there is interest I am very happy to submit a patch, and I would also welcome any pointers (no pun intended) as to where the disadvantages and advantages of this kind of approach have been discussed before.

4 7

A Remedy for the Review Manager Starvation
by Joachim Faulhaber 18 May '10

18 May '10

Dear list, at boostcon (which was awesome :) we talked about the "review manager starvation" that boost is suffering from. I have offered a proposal on this topic, which seemed to have found a good acceptance at Tuesday evening's session. I'd like to share this proposal on the list now, in order to develop a more concrete policy, based on the proposal and its discussion. Where does the motivation come from? There is a huge amount of motivation in the "boost process". People really work their butts off. But this motivation is not everywhere in "boost world". Obviously it is lacking in the field of being a review manager. The motivation is mostly in the field of developing and contributing high quality generic libraries: Being a boost contributor. * People have a general desire to contribute something useful. * Boost contributors generally are passionate about generic library development. * Boost as a high quality library collection is THE platform for a contributor to place its contribution. * The boost community and list is an opportunity to learn from an elite in the field of generic library programming. * The formal review is both a reality test of the quality of a contribution and an acknowledgement by the experts. * The motivation to get into boost is caused by its high standards, because it makes boost attractive. * This in turn motivates not everyone, but those who are passionate about high quality generic programming. Boost is like a beautiful woman that is not easy to win. And this is a good thing. Let's be honest: Being accepted into boost and winning a beautiful woman has this in common: It extends our ego for a large part. (Whether this is always wise is another story ... but that's where we're after). So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library. So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin": (4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community. To make this more concrete: (ad 1) Standards: The list of standards that a library submitted for review has to fulfill should be very clear, so the contributor can prepare his lib using that check list *and* the RMA can check the submission thoroughly. This list should be more explicit and more transparent than what we have now: To fulfill the list of requirements for a submission which is checked by the RMA is then the first certifiable standard of quality that a library can obtain in the review process. Included in the list of requirement for first time contributors should be: (1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community (1.2) Issuing reviews for 2 formal reviews of other contributors. (1.3) Being RMA for another library once. (ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements. An RMA will probably be highly motivated, because he learns all about the standards and the review process that helps him for his own library project. (ad 5) An RMA is not necessarily needed for a review. If no RMA is found the review manager can do the job himself (current procedure). If an RMA volunteers he can start to organizing the review process. He checks the lib and requests a review manager, if necessary. If no one steps forward, the RMA starts the review process, which can not be halted by mere inaction. Any acceptable review manager can take that role. If no one takes action, the review is managed by the RMA. The RMA files the final report on the review within 2 weeks after it ends. The RM declares the result within 4 weeks after the review on the basis of the RMA's summary. (ad 6) Based on the high standards that are checked rigorously by the RMA a library submitted to boost gets certified as "conforms boost standards" or similar, even if it fails to be accepted into boost. In addition to the accepted boost libraries, there will be a collection of associated libraries (boost friends) that can be listed on a web page and that officially are allowed to use some logo that informs about the certified state. (ad 4) This is a form of acknowledgement for those who took on the project of a boost contribution but didn't make it into the core collection and to make them friends or associates of boost rather than "boost losers". So this is my proposal. I wanted to post this on the list because it is a result of this years boostcon and also the topic is kind of urgent. On the other hand you can not expect me to participate very much in this discussion for the next week, because I am on vacations. I'm looking forward to your thoughts and I will be back next week. Cheers Joachim P.S.: BoostCon was really great this year! Lot's of interesting talks and the sessions that addressed topics of the boost community were quite inspiring and creative. Not to mention the picnic and jam session (very enjoyable despite cold weather).

11 28

safe bool operator
by Domagoj Saric 18 May '10

18 May '10

While examining source and binary code for the various safe_bool/unspecified_bool_type implementations two issues can be noticed: - source code verbosity/repetition - binary code inefficiency The first issue is made worse by the fact that even this simple idiom is broken on some compilers ('pointed out' by workarounds in smart_ptr/detail/operator_bool.hpp) so workarounds must also be copied/'rediscovered'... The second issue (related to the usual implementation with member function pointers) has two sides, one is that taking the address of a function will force it to be included in the resulting binary even if it is never used or is always inlined and the second is that some compilers produce non-optimal code. For example for the following source code: boost::optional<int> test1; boost::optional<int> test2; __declspec( noinline ) void func() { if ( test1 ) test2 = *test1; } MSVC++ 8.0 and 9.0 will produce the following binary code ... 0F923A26 movzx eax,byte ptr [test1 (0F968210h)] 0F923A2D neg eax 0F923A2F sbb eax,eax 0F923A31 test eax,offset boost::optional_detail::optional_base<int>::is_initialized (0F923B9Eh) 0F923A36 je ... ... but if the if line is changed to if ( test1.is_initialized() ) the following code will be produced: ... 0F923A26 cmp byte ptr [test1 (0F968210h)],0 0F923A2D je ... ... At first I tried a solution that takes advantage of the fact that MSVC++ has plain-pointer-sized/register-sized member function pointers for plain single inheritance non virtual member functions and worked properly but than I found old discussions about the same subject: http://lists.boost.org/Archives/boost/2003/09/52846.php http://lists.boost.org/Archives/boost/2002/10/38624.php where the solution for MSVC++ was to use a pointer member data which gives the same results as my initial solution... Anyways I've attached a .hpp file with a draft implementation proposal (missing the compiler workarounds from smart_ptr/smart_ptr/detail/operator_bool.hpp for example) that uses both approaches... It enables a one liner implementation for a safe_bool operator: class my_class { public: bool some_is_valid_function() const; operator boost::unspecified_bool_type() const { return boost::make_safe_bool( some_is_valid_function() ); } //or by using a macro BOOST_SAFE_BOOL_FROM_FUNCTION( some_is_valid_function() ) } -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman begin 666 safe_bool.hpp M(W!R86=M82!O;F-E#0HC:69N9&5F('-A9F5?8F]O;%]H<' -"B-D969I;F4@ M<V%F95]B;V]L7VAP< T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2T-"B-I;F-L=61E(")M<&PO8F]O;"YH<' B#0HO+RTM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*;F%M97-P86-E(&)O;W-T#0I[#0HO M+RTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*#0IN86UE<W!A M8V4@9&5T86EL#0I[#0H@(" @<W1R=6-T('5N<W!E8VEF:65D7V)O;VQ?='EP M95]H96QP97(-"B @("![#0H@(" @(" @('9O:60@;65M8F5R7V9U;F-T:6]N M*"D@>WT[#0H@(" @(" @(&EN="!M96UB97)?9&%T85\[#0H@(" @?3L-"@T* M(" @('1Y<&5D968@=F]I9" H=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E M<CHZ*G5N<W!E8VEF:65D7V)O;VQ?='EP95]F=6YC=&EO;BD@*"D[#0H@(" @ M='EP961E9B!I;G0@("!U;G-P96-I9FEE9%]B;V]L7W1Y<&5?:&5L<&5R.CHJ M=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@(" @(" @(#L-"@T*(" @('5N M:6]N(&9A<W1?<V%F95]B;V]L#0H@(" @>PT*(" @(" @("!U;G-I9VYE9"!L M;VYG(" @(" @(" @(" @(" @(" @<&QA:6Y?<&]I;G1E<E]P;&%C96AO;&1E M<CL-"B @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N('!O M:6YT97)?=&]?;65M8F5R(" @(" @(" [#0H@(" @?3L-"@T*(" @("\O(" @ M270@:7,@87-S=6UE9"!T:&%T(&EF('1H92!C;VUP:6QE<B!I<R!A8FQE('1O M(&9I="!A('!L86EN+"!S:6YG;&4-"B @(" O+R!I;FAE<FET86YC92!M96UB M97(@9G5N8W1I;VX@<&]I;G1E<B!I;G1O('-I>F5O9B@@=F]I9" J("D@=&AA M="!I=',@;G5L; T*(" @("\O(&)I;F%R>2!R97!R97-E;G1A=&EO;B!I<R!I M9&5N=&EC86P@=&\@82!P;&%I;B!N=6QL('9O:60@<&]I;G1E<B H86QL(&)I M=',-"B @(" O+R!Z97)O960I+B!7:71H;W5T(&$@=V%Y('1O(&-H96-K('1H M:7,@870@8V]M<&EL92!T:6UE('1H:7,@87-S97)T960@870-"B @(" O+R!R M=6YT:6UE+@T*(" @("\O(" @5&AE(&%B;W9E(&YE960@;F]T(&AO;&0@9F]R M(&1A=&$@;65M8F5R('!O:6YT97)S("AE+F<N($U35D,K*R!U<V5S("TQ#0H@ M(" @+R\@9F]R(&YU;&PM9&%T82!M96UB97(@<&]I;G1E<G,I+@T*(" @('1Y M<&5D968(a);7!L.CIB;V]L7SPH('-I>F5O9B@@9F%S=%]S869E7V)O;VP@*2 \ M/2!S:7IE;V8H('5N<VEG;F5D(&QO;F<@*2 I/B!C86Y?=7-E7V9A<W1?8F]O M;%]H86-K.PT*#0H@(" @='EP961E9B!M<&PZ.FEF7PT*(" @(" @(" @(" @ M/ T*(" @(" @(" @(" @(" @(&-A;E]U<V5?9F%S=%]B;V]L7VAA8VLL#0H@ M(" @(" @(" @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N M+ T*(" @(" @(" @(" @(" @('5N<W!E8VEF:65D7V)O;VQ?='EP95]D871A M#0H@(" @(" @(" @(" ^.CIT>7!E('5N<W!E8VEF:65D7V)O;VQ?='EP93L- M"@T*(" @(&EN;&EN90T*(" @('5N<W!E8VEF:65D7V)O;VQ?='EP92!M86ME M7W-A9F5?8F]O;%]W;W)K97(H(&)O;VP@8V]N<W0@=F%L=64L(&UP;#HZ=')U M95\@+RIU<V4@9F%S="UH86-K('9E<G-I;VXJ+R I#0H@(" @>PT*(" @(" @ M("!F87-T7W-A9F5?8F]O;"!C;VYS="!F87-T4V%F94)O;VP@/2![('9A;'5E M('T[#0H@(" @(" @(&%S<V5R= T*(" @(" @(" H#0H@(" @(" @(" @(" H M("$A9F%S=%-A9F5";V]L+G!O:6YT97)?=&]?;65M8F5R(#T]("$A=F%L=64@ M*2 F)@T*(" @(" @(" @(" @(E1H92!V;VED+7!O:6YT97(M<VEZ960@;65M M8F5R('!O:6YT97(@;G5L;"!B:6YA<GDB#0H@(" @(" @(" @(" B<F5P<F5S M96YT871I;VX@87-S=6UP=&EO;B!D;V5S(&YO="!H;VQD(&9O<B!T:&ES(@T* M(" @(" @(" @(" @(F-O;7!I;&5R+W!L871F;W)M+B(-"B @(" @(" @*3L- M"B @(" @(" @<F5T=7)N(&9A<W13869E0F]O;"YP;VEN=&5R7W1O7VUE;6)E M<CL-"B @("!]#0H-"B @("!I;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L M7W1Y<&5?9G5N8W1I;VX-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W M;W)K97(H(&)O;VP@8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O M;%]T>7!E7V9U;F-T:6]N(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @ M(" @(" @<F5T=7)N(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T M>7!E7VAE;'!E<CHZ;65M8F5R7V9U;F-T:6]N(#H@;G5L;%]V86QU93L-"B @ M("!]#0H@(" @:6YL:6YE#0H@(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V1A M=&$-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W;W)K97(H(&)O;VP@ M8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@ M(" @(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E<CHZ M;65M8F5R7V1A=&%?(" @(#H@;G5L;%]V86QU93L-"B @("!]#0H-"B @("!I M;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O M;VQ?=V]R:V5R*"!B;V]L(&-O;G-T('9A;'5E+"!M<&PZ.F9A;'-E7R O*G5S M92!S=&%N9&%R9"!V97)S:6]N*B\@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&UA:V5?<V%F95]B;V]L7W-T86YD87)D7W=O<FME<B@@=F%L=64L('5N<W!E M8VEF:65D7V)O;VQ?='EP92@@," I("D[#0H@(" @?0T*?2 O+R!N86UE<W!A M8V4@9&5T86EL#0H-"@T*='EP961E9B!D971A:6PZ.G5N<W!E8VEF:65D7V)O M;VQ?='EP92!U;G-P96-I9FEE9%]B;V]L7W1Y<&4[#0H-"@T*:6YL:6YE#0IU M;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O;VPH(&)O;VP@8V]N M<W0@=F%L=64@*0T*>PT*(" @(')E='5R;B!D971A:6PZ.FUA:V5?<V%F95]B M;V]L7W=O<FME<B@@=F%L=64L(&1E=&%I;#HZ8V%N7W5S95]F87-T7V)O;VQ? M:&%C:R@I("D[#0I]#0H-"B\O($EF('=E(&-O=6QD('5S92!M96UB97(@<&]I M;G1E<G,@8F5F;W)E('1H92!M96UB97(@:7,@86-T=6%L;'D@9&5C;&%R960O M<V5E;@T*+R\@=V4@8V]U;&0@=7-E($-25% M8F%S960@:&5L<&5R(&-L87-S M97,@9F]R(&UI;FEM=6T@=F5R8F]S:71Y('-A9F5?8F]O; T*+R\@:6UP;&5M M96YT871I;VYS.@T*+R\@=&5M<&QA=&4@/&-L87-S($)A<V4L(&)O;VP@*$)A M<V4Z.BIB;V]L7V9U;F-T:6]N*2 H*2!C;VYS=#X-"B\O(&-L87-S('-A9F5? M8F]O; T*+R\@>PT*+R\@(" @(&]P97)A=&]R('5N<W!E8VEF:65D7V)O;VQ? M='EP92@I(&-O;G-T('L@<F5T=7)N(&UA:V5?<V%F95]B;V]L*"!S=&%T:6-? M8V%S=#Q"87-E(&-O;G-T("H^*"!T:&ES("DM/BIB;V]L7V9U;F-T:6]N*"D@ M*3L@?0T*+R\@?3L-"B\O#0HO+R!C;&%S<R!M>5]C;&%S<R Z('!U8FQI8R!S M869E7V)O;VP\;7E?8VQA<W,L("9M>5]C;&%S<SHZ=F%L:60^#0HO+RXN+@T* M#0HO+RXN+FEN<W1E860@=V4@87)E(&QE9G0@=VET:"!M86-R;W,N+BX-"B-D M969I;F4@0D]/4U1?4T%&15]"3T],7T923TU?1E5.0U1)3TXH(&-O;G-T365M M8F5R1G5N8W1I;VX@*2!<#0H@(" @;W!E<F%T;W(@8F]O<W0Z.G5N<W!E8VEF M:65D7V)O;VQ?='EP92@I(&-O;G-T('L@<F5T=7)N(&)O;W-T.CIM86ME7W-A M9F5?8F]O;"@@8V]N<W1-96UB97)&=6YC=&EO;B@I("D[('T-"@T*(V1E9FEN M92!"3T]35%]3049%7T)/3TQ?1E)/35]$051!*" @(" @8V]N<W1-96UB97)$ M871A(" @(" I(%P-"B @("!O<&5R871O<B!B;V]S=#HZ=6YS<&5C:69I961? M8F]O;%]T>7!E*"D@8V]N<W0@>R!R971U<FX@8F]O<W0Z.FUA:V5?<V%F95]B M;V]L*"!C;VYS=$UE;6)E<D1A=&$@(" @(" @*3L@?0T*#0H-"B\O+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0I]("\O(&YA;65S<&%C92!B M;V]S= T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T-"B-E 7;F1I9B O+R!S869E7V)O;VQ?:'!P#0H` ` end

7 9