March 2005 - Boost - lists.boost.org

RE: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

On Tue, 2005-03-15 at 12:06 +0000, Paul A Bristow wrote: > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held > | Sent: 15 March 2005 00:13 > | To: boost(a)lists.boost.org > | Subject: [boost] Re: FSM Review > > | It will be a sad day when Boost rejects a good library because > | another library in a different part of the design space is > | theoretically faster. > > IMO this hits the nail on the head. > > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > Sorry, but check the archives before "speculating" on when comments have been made. I argued for state charts to be implemented in terms of STT at the pre-review in May 2004. > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. > Rejection is not permanent. If a library has flaws and they are substantial enough then it should be rejected so that when changed, it can be reviewed again. I would like to see a state chart lib in boost but not as it currently stands. I would not mind if it was accepted as *beta* which would tell users that it has caveats. /ikh

1 0

Boost.Thread docs and more (1.32)
by Johan Nilsson 15 Mar '05

15 Mar '05

Hi, I was browsing the website for Boost.Thread 1.32 updates and became somewhat confused. This is just the few items I noticed during a quick browse. 1. The library isn't mentioned along with other updated libraries on the start page. 2. Quote from 'Design/The Next Phase': "The next phase will address more advanced synchronization concepts, such as read/write mutexes and barriers.". I guess this is just one of the mentioned "remaining inconsistencies" from the release notes. 3. In the release notes it is also stated that recursive_mutex is now implemented using a critical section under Win32. AFAIK this was already the case with 1.31 (or perhaps even earlier?). I also glanced a bit at the recursive_mutex implementation under Win32 and it looks a bit weird to me (this is just an extract): --- recursive_mutex.cpp --- ... recursive_mutex::recursive_mutex() : m_mutex(0) , m_critical_section(false) , m_count(0) { m_critical_section = true; if (m_critical_section) m_mutex = new_critical_section(); else m_mutex = new_mutex(0); } recursive_mutex::~recursive_mutex() { if (m_critical_section) delete_critical_section(m_mutex); else delete_mutex(m_mutex); } ... The if/else clause exists in virtually all methods even though there is no way to affect it from client code. Is this some kind of preparation for future improvements, just some cut and paste from recursive_try_mutex, or ...? 5. Last (but not least): Why aren't the more recent contributors mentioned a bit more up-front in the documentation - I think they deserve a lot more credit than this? // Johan

1 0

Re: [boost] No tests on como?
by Bronek Kozicki 15 Mar '05

15 Mar '05

Bronek Kozicki <brok(a)rubikon.pl> wrote: > 2 como does not support dynamic libraries at all; this is going to be > improved with next version (hopefully to be released soon) my poor memory does not serve me well. Apparently there is some support for consuming DLLs (like system libraries), however support for building them is still lacking. B.

1 0

Re: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

Hi Dave, I've taken the liberty of correcting my poor spelling in the quoted parts of my message of last night. My only excuse is that it was late :-(. ( And I am a native English speaker :-( ). On Mon, 2005-03-14 at 22:34 -0600, David B. Held wrote: > Iain K. Hanson wrote: > > [...] > > There is no doubt ( in my mind ) that Andreas has done some very > > good work. The issue is whether this library is suitable for > > acceptance into boost. IIUC boost is predominately about best of > > breed libs. > > Yes. And sometimes there is more than one best in the breed. Agreed. We have a collection of containers to deal with genuine trade- offs. > > > The primary philosophy in C++ is you don't pay for what you don't use. > > ...And yet, we have iostreams. I don't know the history of iostreams or std::string but I'd be surprised and a little disappointed if there flaws were known and yet they were still admitted to the std. I know iostreams pre-dates the std so perhaps its historical. > > Andreas has deliberately taken a different approach. He has chosen > > to go for the all singing, all dancing heavy weight approach. > > ...Much like shared_ptr<>, which got into TR1. And I dare say that > shared_ptr<> is used in far more performance sensitive contexts than > the FSM. If we declared that shared_ptr<> is the end-all, be-all > smart pointer for C++, I would be as unhappy as you are. For very different reasons. shared_ptr deals with safety. The current FSM proposal takes a feature like state specific storage and every user has to pay for it whether they need it or not even if there is another cheaper way to provide it. ( there always is ). > > > He has explained his approach on this list. You pay for State > > Specific Storage whether you want it or not. You currently get > > non-linear event dispatch ( without orthaganal regions ) if you > > use outer states. And you get horrible performance on transitions > > ( with loss of state specific storage when you transition out of > > a state ). > > And if that were a deal-breaker, people wouldn't be using the > library, would they? Apparently, there are applications where > these are not the critical metrics, and people have already found > use for it. I'm sure its useful. Just as iostreams and std::string are useful. But I don't think that std::string would get through a boost review if presented for the first time today. And nor would it deserve to. Associative containers have O ( log N ) performance for a number of operations because of the underlying algorithm. The current FSM ( State Chart ) proposal has its performance characteristics because of the choices made by the author not for any fundamental underlying reason. All state charts can be collapsed to a STT. > > > I know that if I hand write a GOF state pattern I can get close > > to the scalability of the FSM lib but with constant time event > > dispatch through a single indirection and can change state through > > a single assignment. > > But can you provide all the other features of the FSM proposal? If > not, then you're comparing apples to oranges, right? Of course. At the end of the day, the most an FSM lib can give us is the elimination of some boiler plate code. The doing away with cut and paste. I think few will be willing to pay the performance price to do away with boiler plate and cut & paste. > > FSM is the domain but whether it is spelt STT or StateChart is > > irrelevant one can be mechanically collapsed to the other. But > > the fsm proposal does not do this. > > > > If we have a StateChart lib in boost it should scale as well as any > > other library in boost > > I'm not quite sure what you're saying here, but clearly there is > precedent for solutions at different granularities/complexities > /performance tradeoffs in Boost. Consider tokenizer/regex/spirit. > Consider compose/bind/lambda. If you think that Boost needs a > low-level FSM that concentrates on performance over abstraction, > you may be right. But if you think that it does not need an FSM > library that focuses on abstraction and ease of use, it would > appear that some users might disagree with you. > I think that you are mistaking me. I strongly believe in solutions at different granularities and the trade-offs that they require. If this proposal was an just an std::map and presented as the containers library then it would just need docs to be corrected to say that it is part of a containers lib. ( Just as Andreas has agreed his proposal should be spelt StateChart ). My issue is that this is a std::vector with the performance and weight of std::map. When we know this up front then *I believe* it is a good reason to vote for rejection. /ikh

1 0

[addressof] patch for Borland
by Eric Niebler 15 Mar '05

15 Mar '05

Borland doesn't like boost::addressof when used with arrays. It won't let you reinterpret_cast from an array reference to a char &. Russell Hind was good enough to test the following patch for me and confirmed that it works around the problem. (This is needed to get BOOST_FOREACH to work with Borland.) If no one objects, I'll apply the patch myself. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: addressof.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/addressof.hpp,v retrieving revision 1.7 diff -b -d -u -r1.7 addressof.hpp --- addressof.hpp 27 Jul 2004 03:43:33 -0000 1.7 +++ addressof.hpp 14 Mar 2005 18:15:31 -0000 @@ -33,6 +33,22 @@ &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } +// Borland doesn't like casting an array reference to a char reference +// but thes overloads work around the problem. +# if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) +template<typename T,std::size_t N> +T (*addressof(T (&t)[N]))[N] +{ + return reinterpret_cast<T(*)[N]>(&t); +} + +template<typename T,std::size_t N> +const T (*addressof(const T (&t)[N]))[N] +{ + return reinterpret_cast<const T(*)[N]>(&t); +} +# endif + } #endif // BOOST_UTILITY_ADDRESSOF_HPP

4 8

Re: [boost] Re: boost/pending/mutable_queue missing clear() function
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 Mar '05

----- Mensaje original ----- De: Douglas Gregor <doug.gregor(a)gmail.com> Fecha: Lunes, Marzo 14, 2005 9:29 pm Asunto: Re: [boost] Re: boost/pending/mutable_queue missing clear() function > > On Mar 14, 2005, at 12:55 PM, David Abrahams wrote: > > > Douglas Gregor <doug.gregor(a)gmail.com> writes: > > > >> On Feb 11, 2005, at 5:39 PM, Lloyd J Lewins wrote: > >> > >>> I notice that mutable_queue is missing a clear() function, > i.e. a low > >>> overhead way of emptying the entire queue (without resorting to > >>> repeated > >>> pops). However, I think clear() can be implemented as follows: > >>> > >>> void clear() { clear(); } > >>> > >>> Which is efficient and (often) fast. > > > > Surely that one only runs until you blow the stack. Am I missing > > something? > > No, but neither did I :) The correct code (in CVS of course) is: > > void clear() { c.clear(); } > A silly and totally OT std-riddle: would an optimizer be allowed to rewrite void clear() { clear(); } as if: void clear() {} ? If not, why not? (with observable behavior in mind) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[iostreams] Major interace changes planned -- comments requested
by Jonathan Turkanis 14 Mar '05

14 Mar '05

Hi All, Several important extensions of the Iostreams library have been on hold for over a month while I have tried to resolve the issue described in this message. Unfortunately it didn't get much attention during the review, so I'm hoping I can generate some discussion now. I'm sorry about the length of this message; I've been stuck on this for a long time and would really appreciate some help. I. The Problem --------------------------- Standard iostreams do not work well with non-blocking or asynchronous i/o. I would eventually like to extend the library to provide support for non-blocking and async i/o, and when I do so I expect I will have to introduce some new Device concepts. However, I would like to modify the *current* filter concepts so that they will work unchanged when non-blocking and asynchronous devices are introduced. There are several reasons for this: 1. Proper isolation of concepts. A filter represents a rule for transforming character sequences; ideally, how the sequence is accessed should not be relevant. For example, it would be silly to require separate versions of a toupper_filter for blocking and non-blocking i/o, since they would both represent the same simple rule. 2. Maximal code reuse. While it would just be silly to require several versions of a toupper_filter, it would be extremely wasteful to require several versions of more complex components like compression or encryption filters. 3. Reduced complexity of the library. The library already has a large number of concepts; I don't want to double or triple the number of filter concepts when non-blocking and async i/o is introduced. II. The Solution (the easy part) --------------------------- I believe it will suffice to: - provide the functions put() and write() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been written to the underlying data sink even though no error has occurred. - Provide the functions get() and read() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been read from the underlying data source, even though no error has occurred and EOF has not been reached. This is easily achieved for put() and write(), and almost as easily for read(): - Instead of returning void, put() can return a bool indicating whether the given character was successfully written. - Instead of returning void, write() can return an integer indicating the number of characters written. - Currently, when read returns fewer characters than the requested amount it is treated as an EOF indication. Instead, we can allow read to return the actual number of characters read, and reserve -1 to indicate EOF, since it is not needed as an error indication. III. The Solution (the ugly part) --------------------------- The function get presents more of a challenge. Currently it looks like this (for char_type == char): struct my_input_filter : input_filter { template<typename Source> int get(Source& src); }; The return type already serves a dual purpose: it can store a character or an EOF indication. Unfortunately, with non-blocking or async i/o there are now three possible results of a call to get: 1. A character is successfully retrieved. 2. The end of the stream has been reached. 3. No characters are currently available, but more may be available later. My preferred solution is to have get() return an instance of a specialization of a class template basic_character which can hold a character, an EOF indication or a temporary failure indication: template<typename Ch> class basic_character { public: basic_character(Ch c); operator Ch () const; bool good() const; bool eof() const; bool fail() const; }; typedef basic_character<char> character; typedef basic_character<wchar_t> wcharacter; character eof(); // returns an EOF indication character fail(); // returns a temporary failure indication. wcharater weof(); wcharater wfail(); [Omitted: templated versions of eof and fail] Alternatively, the member functions good, eof and fail could be made non-member functions taking a basic_character. IV. Examples (feel free to skip) --------------------------- With these changes, the uncommenting_input_filter (http://tinyurl.com/3ue9r) could be rewritten as follows: class uncommenting_input_filter : public input_filter { public: explicit uncommenting_input_filter(char comment_char = '#') : comment_char_(comment_char) { } template<typename Source> character get(Source& src) { character c = boost::io::get(src); if (c.good() && c == comment_char_) while (c.good() && c != '\n') c = boost::io::get(src); return c; } private: char comment_char_; }; Similarly, usenet_filter::get (http://tinyurl.com/6xqvk) could be rewritten: template<typename Source> int get(Source& src) { // Handle unfinished business. if (eof_) return EOF; if (off_ < current_word_.size()) return current_word_[off_++]; // Compute curent word. current_word_.clear(); while (true) { character c; if (!(c = boost::io::get(src)).good()) { if (c.eof()) eof_ = true; if (current_word_.empty()) return c; else break; } else if (isalpha((unsigned char) c)) { current_word_.push_back(c); } else { // Look up current word in dictionary. map_type::iterator it = dictionary_.find(current_word_); if (it != dictionary_.end()) current_word_ = it->second; current_word_.push_back(c); off_ = 0; break; } } return this->get(src); // Note: current_word_ is not empty. } V. Problems ---------------------------- 1. Harder to learn. Currently the function get and the concept InputFilter are very easy to explain. I'm afraid having to understand the basic_character template before learning these functions will discourage people from using the library. 2. Harder to use. Having to check for eof and fail make writing simple filters, like the above, slightly harder. I'm worried that the effect on more complex filters may be even worse. This applies not just to get, but to the other functions as well, since their returns values will require more careful examination. 3. Performance. It's possible that the change will have a negative effect on performance. I was planning to implement it and then perform careful measurements, but I have run out of time for this. I think the effect will be slight. VI. Benefits ------------------------ A positive side-effect of this change would be that I can rename the filter concepts InputFilter --> PullFilter OutputFilter --> PushFilter and allow both types of filter to be added either to input or to output streams. Filter writers could then choose the filter concept which best expressed the filtering algorithm without worrying whether it will be used for input or output. VII. Alternatives. 1. Adopt the convention that read() always blocks until at least one character is available, and that get() always blocks. This would give up much of the advantage of non-blocking and async i/o. 2. Add new non-blocking filter concepts, but hide them in the "advanced" section of the library. All the library-provided filters would be non-blocking, and users would be encouraged, but not required, to write non-blocking filters. If you've made it this far THANK YOU!!! Please let me know your opinion. Jonathan

6 49

[range] rationale for transform_range() algorithm?
by Eric Niebler 14 Mar '05

14 Mar '05

Background: I have been working on range-based algorithms and adaptors. The algorithms are variants of the std::algorithms that accept ranges instead of a [begin,end) iterator pair. The adaptors are like the iterator adaptors, except they adapt ranges. Following the principal of least surprise, I want to call my range adaptors filter_range, indirect_range, reverse_range and transform_range (to parallel filter_iterator, indirect_iterator, etc). But I can't do this, because there already is a transform_range, and it's a function! Problem: At the bottom of iterator_range.hpp is this: template< typename SeqT, typename Range, typename FuncT > inline SeqT transform_range( const Range& r, FuncT Func ) { SeqT Seq; std::transform( begin( r ), end( r ), std::back_inserter(Seq), Func ); return Seq; } I'm not sure why. It looks like a range-based algorithm, but ... why provide only one? (Two actually -- copy_range is there also.) And why call it transform_range() instead of just calling it "transform" and making it part of a complete range-based algorithm library? Solution: I suggest the functions copy_range() and transform_range() should be removed or moved into a "deprecated" namespace, freeing up the identifier "boost::transform_range" to be a type, analagous to boost::transform_iterator. Development should proceed on a range-based algorithms library to fill the need that the existing "transform_range()" function is meeting. Thoughts? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 10

boost/pending/mutable_queue missing clear() function
by Lloyd J Lewins 14 Mar '05

14 Mar '05

I notice that mutable_queue is missing a clear() function, i.e. a low overhead way of emptying the entire queue (without resorting to repeated pops). However, I think clear() can be implemented as follows: void clear() { clear(); } Which is efficient and (often) fast. I don't think there is any need to "clear" the index_array (since the constructor for mutable_queue doesn't initialize its contents) Lloyd J. Lewins Fellow, Raytheon Co., llewins(a)raytheon.com +1 (310) 647-8832

3 3

bug fixes for boost::filesystem::exists on Win32
by Robert Mathews 14 Mar '05

14 Mar '05

Hi: I was trying to do something simple with the boost::filesystem library on Win32 && I noticed that it has trouble with UNC paths. I think I noticed 2 bugs with boost::filesystem::exists (possible patch attached). Finally, I also had a question about what consistutes a "part" of a path. Here's the context: I was trying to get all of the parts of a path, starting at the front and moving to the end in order to find out at which point a path was invalid. So, I wrote a path-checker that went something like this: using namespace std; namespace fs = boost::filesystem; void check_path(const string iPath) { fs::path::default_name_check(fs::native); fs::path aCurrentPath; for(fs::path::iterator aItr1=iPath.begin(); aItr1!=iPath.end(); aItr1++) { aCurrentPath /= *aItr1; bool aExists(fs::exists(aCurrentPath)); if(!aExists) { cout << "Hey, this was invalid path and it failed at aCurrentPath" << endl; return false; } } return true; } The function works fine if you give it paths like "D:/foo/bar", but a UNC path like \\computername\share\foo\bar doesn't work. The reason is that the path::iterator returns the following results for the beginning of the UNC path: "//computername" "/" "share" "/" "foo" ... etc and "//computername" is not a valid path. I've got a couple of questions about this: 1) Why is the separator "/" a separate part of the path? Shouldn't there be a way to only get the directory parts of the path w/o the separators? Just curious .. I couldn't find a reference to that in the discussion list. 2) boost::filesystem::exists("//computername") will return false, always. That seems like the wrong answer, given that the path::iterator has returned it as a part of the path. I notice that the filesystem code does otherwise understand UNC paths otherwise. 3) boost::filesystem::exists("//computername/nofreelunch") will return true, if even "nofreelunch" doesn't exist. Looking at the implementation of filesystem::exists in boost libs/filesystems/src/operations_posix_windows.cpp line 324, I'd like to propose the following changes to fix cases 2 & 3. To fix case 3 above, the error code return for an invalid share is not PATH_NOT_FOUND, but ERROR_BAD_NETPATH. That's a simple addition to the list of error codes to check. That should be uncontroversial. To fix case 2 above, one must notice that you have a UNC path with 1 element - ie, a computer name. At the point you can either follow the hint in the code and simply return true, or you can call a different WIN32 function to see if the server exists. Attached is a proposed patch for both issues. Thanks. begin 666 operations_posix_windows.cpp.patch M26YD97@Z(&]P97)A=&EO;G-?<&]S:7A?=VEN9&]W<RYC<' -"CT]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T-"BTM+2!O<&5R871I;VYS7W!O<VEX7W=I;F1O=W,N M8W!P"2AR979I<VEO;B R-3(W,2D-"BLK*R!O<&5R871I;VYS7W!O<VEX7W=I M;F1O=W,N8W!P"2AW;W)K:6YG(&-O<'DI#0I 0" M,S(Q+#$P("LS,C$L,S@@ M0$ -"B @(" @("!]#0H@(" @(" @<F5T=7)N('1R=64[#0H@(R @(&5L<V4- M"BT@(" @("!I9B(a)Z.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN M8U]S='(H*2 I(#T](#!X1D9&1D9&1D8I#0HK"2 @<W1R:6YG(&%0871H*'!H M+G-T<FEN9R@I*3L-"BL)("!B;V]L(&ES54Y#4&%T:"AA4&%T:"YS:7IE*"D@ M/B S("8F(&%0871H+G-U8G-T<B@P+#(I(#T]("(O+R(I.R O+R T/4QA<F=E M(&5N;W5G:"!P871H('1O(&AA=F4@82!L96%D:6YG("\O(&%N9"!A="!L96%S M=" Q(&UO<F4@8VAA<F%C=&5R#0HK"2 @<W1R:6YG.CIS:7IE7W1Y<&4@84YE M>'13;&%S:"AA4&%T:"YF:6YD7V9I<G-T7V]F*"(O(BPR*2D[#0HK"2 @8F]O M;"!I<T]N;'E#;VUP=71E<DYA;64H:7-53D-0871H("8F"0D)"0D)+R\@;6%K M92!S=7)E('1H:7,@82!53D,@<&%T:"!O9B!S;VUE('1Y<&4N#0HK"0D)"0D) M"2 @*&%.97AT4VQA<V@@/3T@<W1R:6YG.CIN<&]S('Q\"2\O(&QO;VL@9F]R M("\O8V]M<'5T97)N86UE#0HK"0D)"0D)"2 @("AA3F5X=%-L87-H(#T]("AA M4&%T:"YS:7IE*"D@+2 Q*2 F)B!A4&%T:"YS:7IE*"D@/B S("\O(&%L;&]W M("\O8V]M<'5T97)N86UE+R!A;F0@9F5N8V4@;V9F("<O+R\G(&EN<'5T( T* M*PD)"0D)"0D@(" I*2D[#0HK"2 @:68H:7-/;FQY0V]M<'5T97).86UE*0T* M*R-I9F1E9B!F86YC>5]C:&5C:VEN9PT**PD)(" O+R!)(&1O;B=T(&MN;W<@ M:68@>6]U('=A;G0@=&\@9V\@=&AI<R!F87(@;W(@;F]T/PT**PD)(" O+R!9 M;W4G;&P@:&%V92!T;R C:6YC;'5D92 \;&TN:#X@86YD(&QI;FL@86=A:6YS M="!.971A<&DS,BYL:6(@)B8@=&AE;B!W;W)R>2!A8F]U="!A;&P@=F%R:6]U M<R!V97)S:6]N<R!O9B!W:6YD;W=S("XN( T**PD@('L-"BL)"2 @3%!315)6 M15)?24Y&3U\Q,# @85-E<G9E<DEN9F\H3E5,3"D[#0HK"0D@($Y%5%]!4$E? M4U1!5%53(&%3=&%T=7,H3F5T4V5R=F5R1V5T26YF;T$H#0HK"0D)"0D)"0D) M"2 @<&@N<W1R:6YG*"DL#0HK"0D)"0D)"0D)"2 @,3 P+ T**PD)"0D)"0D) M"0D@("A,4$)95$4J*2 F85-E<G9E<DEN9F\-"BL)"0D)"0D)"0D)("D[#0HK M"0D@(&EF*&%397)V97));F9O*0T**PD)"2 @3F5T07!I0G5F9F5R1G)E92AA M4V5R=F5R26YF;RD[#0HK"0D@(')E='5R;B!A4W1A='5S(#T]($Y%4E)?4W5C M8V5S<SL-"BL)("!]#0HK(V5L<V4-"BL)(" O+R!!="!L96%S="P@:68@>6]U M(')E8V]G;FEZ92!T:&%T('1H:7,@82!C;VUP=71E<B!N86UE+"!Y;W4@8V]U M;&0@9&\@=V]R<V4@=&AA;B!T;R!A<W-U;64@:70@;6EG:'0@97AI<W0N#0HK M"2 @<F5T=7)N('1R=64["0D)#0HK(V5N9&EF"2 @#0HK"2 @96QS92!I9B@Z M.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN8U]S='(H*2 I(#T] M(#!X1D9&1D9&1D8I#0H@(" @(" @>PT*(" @(" @(" @(%5)3E0@97)R(#T@ M.CI'971,87-T17)R;W(H*3L-"BT@(" @(" @("!I9B@H97)R(#T]($524D]2 M7T9)3$5?3D]47T9/54Y$*2!\?" H97)R(#T]($524D]27TE.5D%,241?4$%2 M04U%5$52*2!\?" H97)R(#T]($524D]27U!!5$A?3D]47T9/54Y$*2!\?" H M97)R(#T]($524D]27TE.5D%,241?3D%-12DI#0HK(" @(" @(" @:68H*&5R M<B ]/2!%4E)/4E]&24Q%7TY/5%]&3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E]) M3E9!3$E$7U!!4D%-151%4BD@?'P@*&5R<B ]/2!%4E)/4E]0051(7TY/5%]& M3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E])3E9!3$E$7TY!344I#0HK"0D)*&5R M<B ]/2!%4E)/4E]"041?3D544$%42"D-"BL)"2 @("D-"B @(" @(" @(" @ M("!R971U<FX@9F%L<V4[("\O($=E=$9I;&5!='1R:6)U=&5S(&9A:6QE9"!B M96-A=7-E('1H92!P871H(&1O97,@;F]T(&5X:7-T#0H@(" @(" @(" @+R\@ M9F]R(&%N>2!O=&AE<B!E<G)O<B!W92!A<W-U;64@=&AE(&9I;&4@9&]E<R!E M>&ES="!A;F0@9F%L;"!T:')O=6=H+ T*(" @(" @(" @("\O('1H:7,@;6%Y M(&YO="!B92!T:&4@8F5S="!P;VQI8WD@=&AO=6=H+BXN(" H2DT@,C P-# S %,S I#0H` ` end

1 0