January 2007 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Euclidean MST using CGAL and Boost
by miles mccoo 29 Jan '07

29 Jan '07

> > > Hi, > > > I patched together code for Euclidean MST based on CGAL and Boost. I > posted in on Wikipedia because I couldn't think of a more appropriate place. > > > http://en.wikipedia.org/wiki/Sample_Code_for_Euclidean_MST_using_Boost_and_… > > > > I would love to receive feedback on it. I hope someone finds it's useful. > > > > Miles >

2 1

Work-around for linker removed BOOST_AUTO_TEST_CASE code
by daniel.hawson＠virgin.net 29 Jan '07

29 Jan '07

I'd encountered a problem with a particular way I'd set up a test application where some BOOST_AUTO_TEST_CASE functions would be executed while others wouldn't. I suspect this may be Visual Studio (2005) specific. I've got a work-around, which I thought might help others in the same situation. The scenario is this - Main test application: testapp.cpp - #define BOOST_AUTO_TEST_MAIN "TestApp for some Lib" #include <boost/test/auto_unit_test.hpp> BOOST_AUTO_TEST_CASE(IGetExecutedByTestFramework) { BOOST_CHECK(false); } External library, containing: somemodule_tests.cpp - #include "somemodule.h" #include <boost/test/auto_unit_test.hpp> //Test functionality provided by somemodule.h //... BOOST_AUTO_TEST_CASE(IDontGetExecuted) { BOOST_CHECK(false); } My Visual Studio solution contains two projects - - mylibtestapp: A console executable to run all test cases in mylib Contains only testapp.cpp - mylib: A statically linked lib containing a bunch of .cpp/.h files and, so far, just one ..._tests.cpp file. The solution is set up so that mylibtestapp depends on mylib. It also explicitly links with the boost 'unit_test_framework.lib'. It compiles and links fine. When running, only the 'IGetExecutedByTestFramework' gets executed. I manually expanded the BOOST_AUTO_TEST_CASE macro for 'IDontGetExecuted' and the debugger wouldn't step into any of the test registrar object constructor code, so I assume the linker decided to strip out the code for some reason. As soon as I added the following to somemodule_tests.cpp - int g_fiddle; and change testapp.cpp to 'extern int g_fiddle;' and manually insert the 'init_unit_test_suite(int argc, char* argv[])' with some trivial use of 'g_fiddle' (using it in a printf), then both test cases get executed. After poking around with the linker options little further, I've found that all unit tests will run as originally intended, without having to use any extern frigs, so long as the mylibtestapp's 'Configuration Properties'>Linker>General>'Use Library Dependency Inputs' is set to 'Yes'. The difference being that the linker command-line now contains mylib.lib instead of the individual .o files of mylib. Weird. -- Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 28/01/2007 13:12

1 0

std::string to std::wstring
by John Christopher 29 Jan '07

29 Jan '07

Hello, Does Boost contain facilities to convert std::string into std::wstring and the other way around? Thanks in advance

5 7

[mpl] Problem comparing iterators
by Küppers, Ben 29 Jan '07

29 Jan '07

Gents, For illustration purposes I created the following code that iterates through a sequence and accumulates the distances between the current iterator and the beginning of the sequence. Somehow this code works for normal ranges (range1 and range2) but fails to compile for joint_view range3 (80-plus errors). Changing the call to distance to compare between begin and end or between _2 and _2 (self) works. I am at a loss here. Can someone point out what I am doing wrong? Thanks Ben #include <iostream> #include <boost/mpl/arithmetic.hpp> #include <boost/mpl/begin.hpp> #include <boost/mpl/distance.hpp> #include <boost/mpl/for_each.hpp> #include <boost/mpl/iter_fold.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/mpl/plus.hpp> #include <boost/mpl/push_back.hpp> #include <boost/mpl/range_c.hpp> #include <boost/mpl/vector_c.hpp> namespace mpl = boost::mpl; template< class _Sequence > struct distances { typedef typename mpl::iter_fold< _Sequence, mpl::long_< 0 >, mpl::plus< mpl::_1, mpl::distance< typename mpl::begin< _Sequence >::type, // typename mpl::end< _Sequence >::type // mpl::_2, mpl::_2 > > >::type type; }; int main( int argc, char* argv[] ) { typedef mpl::range_c< char, 'a', 'd' >::type range1; typedef mpl::range_c< char, 'm', 'q' >::type range2; typedef mpl::joint_view< range1, range2 >::type range3; typedef distances< range3 >::type type1; std::cout << type1(); std::cout << std::endl; return 0; } This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

'is_pointer_like' or 'is_smart_pointer' or similar, again
by Gottlob Frege 29 Jan '07

29 Jan '07

A while back there was discussion of detecting smart pointers. The discussion started with Ovanes Markarian Date: Thu, 22 Jun 2006 19:19:07 +0200 (CEST) From: "Ovanes Markarian" <om_boost(a)keywallet.com> Subject: [Boost-users] inspecting templates and boost::is_pointer To: boost-users(a)lists.boost.org Message-ID: <41230.194.138.18.132.115099674 > > 7.squirrel(a)www.keywallet.com> > Content-Type: text/plain;charset=iso-8859-1 > > Hello all, > > I am trying to specialize boost::is_pointer so, that it can determine if a > type is a pointer > wrapper (shared_ptr, auto_ptr, weak_ptr). ..... And, first off, yes, we now know that expanding is_pointer would be bad. So, instead we want 'is_pointer_like' or something like that. There were suggestions regarding detecting operator->() and/or unary operator *(). What ever came of this? I am asking, of course, because I could really use an 'is_pointer_like<>' or 'is_smart_ptr' right now. And if it is still unsolved, I've got 2 more suggestions: detecting that boost::get_pointer() (for boost::bind) has been defined, and/or just looking for some common internals of the smart_ptrs (hack!) - or adding some common internal typedef/value - ie T::is_smart_pointer. Thanks, Tony

4 6

[Boost-build]/[bjam] Problem compiling CVS bjam from sources
by D Garvey 29 Jan '07

29 Jan '07

As far as I'm aware I'm using pretty much a default ubuntu installation with gcc 4.1.2. After compiling bjam from sources, using these<http://boost.org/boost-build2/doc/html/jam/building.html>instructions, and running the tests, I get the following failures: root@---------:/usr/local/src/boost/tools/jam/test# sh test.sh > --- Testing SHELL builtin... > --- Testing W32_GETREGNAMES builtin... > --- Testing var expansion... > --- Testing var on target semantics... > --- Testing var expansion... > var_expand.jam:14: error: [FAILED] (==) '' > var_expand.jam:17: error: [FAILED] (==) '' > --- Complete: PASSED(21) *FAILED(2)* > The output from the compilation is below (it seems to work, even with the lists of warnings): root@hallah:/usr/local/src/boost/tools/jam# cd src | sh ./build_dist.sh > ../../../Jamfile.v2:335: in load-aux > rule path.glob-tree unknown in module Jamfile</usr/local/src/boost>. > /usr/share/boost-build/build/project.jam:318: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:120: in load-parent > /usr/share/boost-build/build/project.jam:447: in initialize > /usr/share/boost-build/build/project.jam:301: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:120: in load-parent > /usr/share/boost-build/build/project.jam:447: in initialize > /usr/share/boost-build/build/project.jam:301: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:170: in project.find > /usr/share/boost-build/build-system.jam:148: in load > /usr/share/boost-build/kernel/modules.jam:261: in import > /usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build > /usr/local/src/boost/boost-build.jam:9: in module scope > cp: cannot stat `html/*': No such file or directory > ### > ### Using 'gcc' toolset. > ### > rm -rf bootstrap > mkdir bootstrap > gcc -o bootstrap/jam0 command.c compile.c debug.c execunix.c expand.c > fileunix.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c > lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c > regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c > strings.c filesys.c builtins.c pwd.c class.c native.c w32_getreg.c > modules/set.c modules/path.c modules/regex.c modules/property-set.cmodules/sequence.c modules/order.c > execnt.c filent.c > compile.c: In function 'compile_set': > compile.c:1151: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > compile.c: In function 'compile_settings': > compile.c:1244: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean > ...found 1 target... > ...updating 1 target... > ...updated 1 target... > ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= > ...found 46 targets... > ...updating 2 targets... > [MKDIR] bin.linuxx86 > [COMPILE] bin.linuxx86/bjam > compile.c: In function 'compile_set': > compile.c:1151: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > compile.c: In function 'compile_settings': > compile.c:1244: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > hash.c: In function 'hash_search': > hash.c:126: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > ...updated 2 targets... > Note that the first 10 or so lines of the output above keep coming up when I'm trying to build other boost libraries. What am I doing wrong? --- Darren Garvey

2 2

BoostCon 2007 Program Committee progress report
by Beman Dawes 28 Jan '07

28 Jan '07

We've got interesting proposals from experienced presenters, have accepted a bunch, and have started to put together a tentative schedule for the week. We should finish accepting proposals in the next week or so and be able to go public with the schedule real soon after that. The people we have sessions proposals from are listed below. If you sent in a proposal and are not on the list, please contact me right away! Dave Abrahams Beman Dawes Jeff Garland Doug Gregor Mat Marcus Scott Meyers Eric Niebler Kevlin Henney Howard Hinnant Harmut Kaiser / Joel de Guzman Sean Parent Gennadiy Rozental Timothy Shead Jeremy Siek Matthias Troyer The conference dates (May 14-16) are firm, and other arrangements are moving forward. See http://www.boost.org/more/BoostCon07.html Thanks to Dave Abrahams and Boost-Consulting for providing the wiki we are using to coordinate conference planning. It is invaluable. --Beman Dawes, BoostCon 2007 Program Committee chair

4 3

socket streams?
by grahamspam＠earthlink.net 28 Jan '07

28 Jan '07

Hello, I did not find a streams implementation for sockets. Is such being developed? Thanks, Jeff

6 6

Re: [Boost-users] problem with boost::strong_components
by Dmitry 28 Jan '07

28 Jan '07

Hi, Tamas Why you don't try this, seems should work: graph_t cityg (bigedges.begin (), bigedges.end (), bigweights.begin (), dim); int num = strong_components(cityg, &component[0]); you use std::vector as vertex storage, right? Regards, Dmitry > Hello, > I'm trying to use the boost library's strong_components function to > partition a graph to connected sub-partitions, and ran into a problem. > std::vector<int> other; > // fill up the vector with the vertices by pushing back each one. The number > of vertices is about 170k and the biggest vertex index is about 260k. > // .. > // bigedges and bigweights have the edges and the weights, dim is the total > number of vertices - all these are checked and proper. > > graph_t cityg (bigedges.begin (), bigedges.end (), bigweights.begin (), > dim); > std::vector<int> component(num_vertices(cityg)); > int num = strong_components(cityg, &component[0], boost::vertex_index_map > (&other[0])); > > Tamas >

1 0

[regex] memory exhausted
by Kyle Alons 27 Jan '07

27 Jan '07

The attached sample works properly in boost v1.30.2 but fails with a 'Memory exhausted' exception in v1.31 through v1.33.1. Is this a bug, and/or do you have any ideas on rephrasing the expression to work in boost 1.33.1? Thanks. --------------------- Kyle Alons http://www.kinook.com begin 666 regex.zip M4$L#!!0````(`!!2+38?'+8'N0$``&<#```(````=&5S="YC<'"54LMNVS 0 M/,N _V'AJ UI"VI3]P'(;@]]H7?W%@8%(Z\E`A(E4.M81I-_[Y*6W3A%"_0@ M:K'#F1TNYL+8O-JN$9:W3=/1"X<%]FG9MA_&HXL3UG?DC"W.>AONH:ZY-QX9 M2U!K8X4OM"OR!/)2NZFO[ZYOY'CT<SR*R.WY]%74T3K+#J)@; *5L;@X`6;0 MAHV8Y)E2QK9;2JFGB0R7=J6I$$2!Y'EB<^!+"1Z,C(79^]"!&5PJ>[D`[_%\ M*/:M6Y$3$Z'4;J:4D"*=WBMEIW*U[PAKI=+/FO3P6R%!N"G%=2)OTJE4:L[E M@R\_8F&L4E=*O?H;]W#[*?&+73-M>-1C=P[;*KB+K^)!,TB=].)Y_/H;5BVZ M]%-C[]#15]?4C.)W4R,_)YXST.ZY4HI'ROA-</D/O;?_I_>.S<<'[]Y]2$^6 MA?B$Y8IAPPG\AFYUAUEF&U?K"N[_`$S./[F(GFZCV9)XK/^C1E>@\+GQ0Y+C MNN313" WIQ!Y?L@1%^=!\A LEWZ"#TGTP%^N*2]!Y(WM"((2]CFV9!K['% > M$]RR->)\/NLF;"/=E9I$,.!%^'1(6V?A)7>X\0M02P,$% ````@`%W4L-B4* M`<.C" ``.6\```D```!I;G!U="YT>'3M7%]OVS80?UZ!?@<B3PZ6REVQ84#; M#$B<K<O0=5F<K ."/- 2:W.518VDDGI#/]D>]I'V%7;47\JF:-FUY#J6'A*% M.I)WO[O[\41)^>^??_O])QL]'C_J]]%+'$GV9$P"PK$DWG=QHSJN)E0@EWD$ MW6.!<@$TFB&,)&.^DXM>1H&D4X)^(UQ0%CQ_YCQUOGGZ[;-OG:^?*:%<<##! MP9@(Z(ZD&OX=]0F:XAER<20(HH'+.">N1",RP7>4<80##]U3WX<6Y#,A$7V7 MCR8G)%$01N(DUS#1ZV7?8-AR3%8Y'C^*9XI_Q&@)%G&7%*"5-5#(W0O//\IP M.M9Q<M*Q`CPE(L0PS"]84.%<GSL7G'V8H;\?/U)&1X(&8S2<"4FFSAG%XP!0 MH:YX8;C\EHR<(>%WU"7J^A?)Q71<27U3GP&;ABP@@?P9K#!*Z*,JW21SF6^: MW]3Y]ZFO.E/LT[^P!!!,0F=8XK1=_]E7;N5DBOE[T?\N:;O)U?;(&4O4AZ#B MSJL,=G7E1$I.1Y$DO0/E@8,C=*!C?W!X6QY-P]4Y(Z-H/"9\*$EX->$L&D^* MX>8[EM&#OH*.08\!*#)F?*;IH8)D8=X2M/!'>GY*`P_@*7J_@2 Y/ABPX!WE MTQC&(<,AF/4FBY[C@XF4X?-^'X8-(TX=QL?]?+XP&OG412'F$CR!7!\+@?3A MT'.[MQTUWX\PP\"G8&W6G@5IX;,JOVE:Z//V#O4AU*%X(LV 8Q20^TRO-T0J MW>(KO<,7B=PU]T%*L<J)"_H*1TA^$H9*?\+1EPB\_PZ[V"/]>WU6!XOIAX,7 MQ<0?369\;D<5K,9@*GONC+G15$4ID1/F:5%I")I71/X`@+ZF0D* 79(_(R+D MDCA3<@(209"E@M>"')L4AM1Q.0UC]RB5TQP`<><UE9#:P*,7F,/P4N7FS#</ M4[:[W,%YRW$8$B_+"G6D,:D14?QC2"32@.C1`%:B*UCSH 6&.T)QPR49@[H+ M(<Q&?\":=G,+BY2(?"D(a)1.-H/0_NV'L`O8RPBO&\Q]_5X:=/;Y%*=/IX^*(L MPXF,>(!^)'X(9 G)``DBKQC82M2XO5[/`,%A+[7@YNGMX>&1Y!$Y7)8U2Y(_ MG>7\1,P"]S(>'9V"RD%=M(^R(>(1!MCW1]A]#P5%<G*48HFPNCR48-^"?U(L M8I_$<[?IF"--54W'S<!:BM_O`T\'U80\+LYK1S$,F^*E]VXCW+*3]HGP=*8T M[^BP!,>R-)TP+I4<\N3TS)2'*_!D[H!&DM(BD>J^TWRZGKM:(MJM>W9;A)QZ MI:/EU6E9>2@2>T_'"0R+MU U>#5'4,LZ\.X.DEP*0J-<94:K;>(H6]H1QMIU M7$<?AFHNC:Z5BX3X>M+YTPL\4Z*U60S8QDAT>P"%X 8\W6IMN -!L=T:LEL8 M-K P=(O"W*)0BR8VQOY;2_*'P>NK.JLU`M^Z7[='S1TMKT?+8R*_#R25L]/9 MN;??A%R"(LEN]1Q3Q=BYMS+AS(a)-;.R6+.7>/)JT0-DF#FT"[5?(J(]71UHJT M-> $U-5?,]@?[H*T`L\O(F!R&V*ZA$C+DI,QP)R>@])0N@@`.QBK7S\I4%1& M0#Y&,I%9DP*-3JJ;F7.*6U(XL<8B$)M8?5TW>H%R4]O!M)[BLR(-OH(T,"=6 M+'AS6\Z8IABWA3!HCK5W,4":6262G ;ZKO9GU>*P?I[66BV:2(#LI*7%XCKT M]G C^HY1#^FF][082;*^8B^A1.)SX-4NK-)YJB4,6P$;9<8ZIC=);DT#UPP1 MQ5$#Q%!";]7RM!Z[M$T#0Q+LT1UN[$AE<OUZ0,\/>LK!=5S]F14%/&E2>-@I M(P5Z\POYTM0HM*Z6T>UHCGV:0KY)QMHAOS5+?KKS=IST!CAPB;]GM)<875[T MC;F4W_K8"2T'<7.+>$D/RT!*N>98:G6@&KT=W#+,S9)*BO7#H)571%YP.B47 M3-"8_O?^66X9CB2EAL3-5_6K6;C62]D+,-=.CF1VBX!2:2<?Q=;!NN&'KDV[ MI>TGJ7.0KLI2W>LM1.KE\"5Q";TCGK)ACZ@Q?X_-`H=>;:Q#B!:85ZP;JK@/ MXBTSI)U-_)IH-4QI&P2V(?;*PROAK$K,ML%>M8(F.VEUXSM_=K&7>]^Y]>:[ M',E5R_(]K44H-WB34BC1]'9X;32:WQEO'LLV=L(a)+0!_,C9U.JWO('6DN5 &Q MR?+E$U*@NG9)]-]*X5+!+JU5+9^"9S-DD0;38KVR/F]LIEA9%B7924NT\YJQ M]]?AQ>F^??N?N &<60:@E[=C/IQ-1\P_2E\1P?PZ\ CW9W"Y:$LV/(I5_(IC MCZB!L@T1\UOJ*_/7@IOJ9EENADU$L\PF%AMKK0`*\RUYOXG_\-++'=4.WVXE M2IHD\+T-J":7F^1-LKE8V>8R\QF]"Y:ALL=+S'JTT<@Z\GDF_$XO#9OW;AO\ M_Q "H3U*[\A<W]_4;ZM>TV _MSGG02CNP--<#F1YHT\K_HK&(9'2UTO"0()< M(+"KQIVO'S-Z\8A+I]A'GOMKA../FO2V5YP)<<'!3KUUP*93*D1,+T7KF_A! MI%O,#F8%$+GT+AXT;9RCL5C+@L6"Y%GFJ7KMH\Z>KB%\5MH[L#%##'KU]9J5 M9=DQUNGFO64?=!F/:@ZU"6D>MHEI+K>)Y3%@-;04&%;)6DM!%D)6B2*NFMZF M7\AFLUY:CEL$DLPW"QCY8)FHSA+6>1>X8^G(*:.8Y4P\LTQ29Y]ELCHG+9,M MF,J*0)F_K*(ZJ]E1M4"YP(!5@DM*.G.G3W[FTW&MA?@ZKM4D-*YMXS'>`N$^ MC*=Y^E<\NHG[7"E7HM&5S,F"$3>M^FF@.;HZ<D^.CMQ+$EJT6>3:_$#41 =F MU322L AT-7=7<YL%LP^/S2+;*<L["N\HO"2W80IO[U-U$X]OJ91?_" Q5N"K M7IJND5!EJRE;1QB*8JU+KQ!=A"S]9<*OZ3.8^G]02P,$% ````@`L%$M-@P* MIPFT" ``Q6\```H```!O=71P=70N='AT[5Q?;]LV$']>@7X'(D\.ELI=L6% MVPQ(G*W+T'59G*P#BC[0$FMSE46-I))Z0S_9'O:1]A5VU%_*IBC9M>0FEAX2 MA3J2=[^[^_%$2?GOGW^'PT=;/1X^& [1<QQ)]FA*`L*Q)-YW<:,ZKF94()=Y M!-UB@7(!-%D@C"1COI.+7D:!I'."?B-<4!8\?>(\=KYY_.V3;YVOGRBA7' T MP\&4".B.I!K^'?4)FN,%<G$D"**!RS@GKD03,L,WE'&$`P_=4M^'%N0S(1%] MEX\F9R11$$;B)-<PT>OYT&!8/2;K' \?Q#/%/V*T!(NX2PK0RAHHY&Z%YQ]E M.!WK.#GI6 &>$Q%B&.87+*APKL^="\X^+-#?#Q\HHR-!@RD:+X0D<^>,XFD` MJ%!7/#-<?DTFSICP&^H2=?V+Y&(ZKJ2^J<^(S4,6D$#^#%88)?11E6Z2N<PW MS6_J_/O<5YTI]NE?6 (()J$S+'':KO\<*K=R,L?\O1A^E[2]R=7VR!E+U(>@ MXLZ+#'9UY41*3B>1)(,#Y8&#(W2@8W]P^+8\FH:K<T8FT71*^%B2\&K&632= M%<,M=RRC!WT%G8(>(U!DROA"TT,%R<J\)6CAC_3\E 8>P%/T?@5!<GPP8L$[ MRN<QC&.&0S#K518]QP<S*<.GPR$,&T:<.HQ/A_E\833QJ8M"S"5X`KD^%@+I MPZ&G=F\[:KX?88:13\':K#T+TL)G57[3M-#G'1SJ0ZA#\42:`<<H(+>97J^( M5+K%5P:'SQ*Y:^Z#E&*5$Q?T%8Z0_"0,E?Z$HR\1>/\==K%'AK?ZK X6\P\' MSXJ)/YK,^-R.*EB-P53VW!ESH[F*4B)GS-.BTA T+XC\`0!]286$`+LD?T9$ MR)HX4W("$D&06L%K08Y-"D/JN)R&L7N4RFD.@+CSDDI(;>#1"\QA>*ER<^&; MARG;7>[@O.8X#(F7984ZTIC4B"C^,282:4 ,: `KT16L>= "PQVAN.&23$'= ME1!FDS]@37OS%A8I$?E20(C&T7H>W+#W`'H9817C>8^_J\-/G]XBE>CT\?!9 M6883&?$`_4C\$,@2D@$21%XQL)6H<0>#@0&"PT%JP9O';P\/CR2/R&%=UM0D M?SK+^8E8!.YE/#HZ!96#IF@?94/$(XRP[T^P^QX*BN3D*,42875Y+,&^%?^D M6,0^B>?NTC%'FJJ:CMN!M12_WP>>#JH)>5R<-XYB&#;%2^_=1;AE)]T3X>E" M:=[380F.NC2=,2Z5'/+D_,R4AVOP9.Z 5I+2(I'J?J?Y=#-W=42T._?LK@@Y M]4I/R^O3LO)0)/:>CA,85F^A&O!JCJ"6=>#=.TAR*0BM<I49K:Z)HVQI3Q@; MUW$]?1BJN32ZUBX2XNM)YT\O\$R)UF4Q8!LCT>T>%();\'2GM>$="(K=UI#] MPK"%A:%?%)86A48TL37VWUF2WP]>7]=9G1'XSOVZ.VKN:7DS6IX2^7T@J5R< M+LZ]_2;D$A1)=JOGF"K&SKVU"7<9V,8I6<QY]VC2"F&;-+@-M#LEKS)2/6VM M25LC3D!=_36#_>$N2"OP_"H")K<AIDN(M"PYF0+,Z3DH#:6+`+"#J?KUDP)% M903D8R03F0TIT.BDIIE9#L\?.)OG`5JV"43"Q0!BTI+EB<$6@1B%ZNLZ+BNL MG,(#U@\4Y169\A5DBCGW8L$W;\M)U18I=Q I[1'[/8VA=M::A!E@$:AV>=42 MLWFV-UISVLB1[*2C)><Z]/#^;6??,.HAW?2!%B,),53L2)26@B7P&I=GZ3S5 M$H8-A:V29Q/3V^2_MH%KAXCBJ %B**&W;I';C%VZIH$Q"?;H/CEVI#*Y><F@ MYP<]Y> ZKO[,Z@:>-"D\[)21`KV3M;XV>PK#JF5T4]LCJ+:<TR:IW2_7MDNA MNG_O.'6.<. 2?\_(,S&Z7#H8TRV_Q[+38@[B]DJ!DAZ6@91R[1'9^D"U>M^Y M8YC;)944Z_M!*R^(O."P&%PP0>-E8.^?*Y?A2%)J3-Q\X;]:A!N](+X"<^/D M2&:W""B5[N1CX298M_P`N&VW=/U4=PG2=5FJ?]6&2+TLOB0NH3?$4S;L$37F M[]19X-"KC4T(T0+SFG5#%?=!O&6&=/.TH"%:+5/:%H%MB;WR\$HXJQ*S7;!7 MHZ#)3CK=/L^?@.SE#GINO?DN1W+54K\SM@KE%F]2"B7:WE1OC$;[^^OM8]G% M/GL!Z+VYL=-I=0^Y(\V%*B"V6;Y\0@I4URZ)_CLI7"K8I;.JY5/P;(<LTF!: MK5<VYXWM%"MU49*==$0[+QE[?QU>G.[;_R%(W #.+ ,PR-LQ'R_F$^8?I2^: M8'X=>(3["[A<M"4;'L4J?L6Q1]1 V8:(^8WYM?EKQ4U-LRPWPR:B6683BXVU M5@"%^9:\7^N?FM3D45>OE>TD2MHD\+T-J#:7F^1]M*58V>4R\QF]49:ALL=+ MS&:TT<HZ\GDF_)U>&K;OW2[X_SX$0G>4WI.YOK^IWU:]I,%^;G,N@U#<@:>Y M',CR1I]6_!6-8R*EKY>$@02Y0&!7C;M</V;TXA&7SK&///?7",<?6.EM+S@3 MXH*#G7KKB,WG5(B87HK65_&#2+>8'<P*('+I33QHVKA$8[&6!8L%R;/,4_7: M1Y,]74/XK+5W8&.&&/3JZPTKR[)CK-,M>\L^:!V/:@ZU"6D>MHEI+K>)Y3%@ M-;04&%;)1DM!%D)6B2*NVMZF7\EFLUY:CEL$DLPW"QCYH$Y49PGKO"O<43MR MRBAF.1//U$GJ[%,GJW-2G6S!5%8$ROQE%=59S8ZJ!<H5!JP2K"GIS)T^^9E/ MS[46XNNY5I/0N+:+QW@KA'L_GN;IWP+I)NYSI5R)1E\R)PM&W+3N!X;FZ.K) M/3EZ<B]):-%FD>OR,U,3'9A5TTC"(M#7W'W-;1;,/E\VB^RF+.\IO*?PDMR6 M*;R[#]Y-/+ZC4G[U@\18@:\&:;I&0I6MIFR=8"B*M2Z#0G05LO27";^VSV#J M_P%02P$"% `4````" `04BTV'QRV![D!``!G`P``" `````````!`" ````` M````=&5S="YC<'!02P$"% `4````" `7=2PV)0H!PZ,(```Y;P``"0`````` M```!`" ```#?`0``:6YP=70N='AT4$L!`A0`% ````@`L%$M-@P*IPFT" `` MQ6\```H``````````0`@````J0H``&]U='!U="YT>'102P4&``````,``P"E )````A1,````` ` end

2 8