- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1538741 ] wstring_rvalue_from_python crash on zero length PyObject
by SourceForge.net 11 Aug '06

11 Aug '06

Bugs item #1538741, was opened at 2006-08-11 14:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1538741&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Goncalo Nuno M. de Carvalho (glslang) Assigned to: David Abrahams (david_abrahams) Summary: wstring_rvalue_from_python crash on zero length PyObject Initial Comment: Using Python 2.3 (OSX native) and OSX 10.4.7 (powerpc-apple-darwin8- gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)) Boost version is 1_33_1 and was compiled from source. When PyObject_Length(intermediate) is zero in wstring_rvalue_from_python::extract (when referring to an empty string) a crash will occur in PyUnicode_AsWideChar, most probably because 0 is then passed to it. Doing a if( result.empty( ) ) return std::wstring( ) right after the result string is constructed seems to solve this and produce correct results on my code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1538741&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Whatever happened to boost::circular_buffer?
by Will Wilson 11 Aug '06

11 Aug '06

Hi All, I was just wondering what happened to this very handy container, as I notice it still hasn't made it into the boost release. This is despite it being formally reviewed over two years ago. According to http://boost.org/more/formal_review_schedule.html it's listed as "Accepted -- not added yet". Is there anything preventing the addition of the circular_buffer? If not, can I just +1 including it in the next release. Cheers, Will Wilson.

4 3

[Boost-bugs] [ boost-Bugs-1538697 ] Possible problem with condition releasing
by SourceForge.net 11 Aug '06

11 Aug '06

Bugs item #1538697, was opened at 2006-08-11 13:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1538697&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Vest (davevest) Assigned to: Mike Glassford (glassfordm) Summary: Possible problem with condition releasing Initial Comment: I think this is a bug but since I have only just started using the threads library it could be a misunderstanding on my part. Since the actual application is quite complex I've created an imaginary scenario that shows the problem. Scenario: A single 'throttle' manager that only lets three threads at a time perform some work. When a thread wants to work it must successfully addRef and when it has finished it releases. Problem: If all available 'slots' are used I am using a condition in the addRef to wait for a release before continuing. Therefore I would expect that after the wait I can successfully assert that a slot is available. However, sometimes this does not appear to be true and I can only assume that sometimes the condition is not working properly. Work around: In CThrottle::release remove the 'unlock' so that the notify_one occurs while the method still has a lock on the m_mutexChangeState. Have I misunderstood how condition is supposed to work? Thanks, Dave. The code: #include <boost\thread\thread.hpp> #include <boost\thread\recursive_mutex.hpp> #include <boost/thread/condition.hpp> #include <boost/shared_ptr.hpp> #include <windows.h> #include <crtdbg.h> #include <vector> class CThrottle { int m_nThrottle; public: CThrottle() : m_nThrottle(0) {} void addRef() { boost::mutex::scoped_lock lockIncrement ( m_mutexIncrement ); boost::recursive_mutex::scoped_lock lockChangeState( m_mutexChangeState ); if ( !isAllowed() ) m_condition.wait( lockChangeState ); _ASSERT( isAllowed() ); // PROBLEM ++m_nThrottle; } void release() { boost::recursive_mutex::scoped_lock lockChangeState( m_mutexChangeState ); --m_nThrottle; lockChangeState.unlock(); m_condition.notify_one(); } bool isAllowed() { boost::recursive_mutex::scoped_lock lockChangeState( m_mutexChangeState ); return m_nThrottle < 3; } private: boost::mutex m_mutexIncrement; boost::recursive_mutex m_mutexChangeState; boost::condition m_condition; }; class CTestThread { public: CTestThread( CThrottle * pThrottle ) : m_pThrottle( pThrottle ) {} void operator()() { m_pThrottle->addRef(); std::cout << "Do something\n"; m_pThrottle->release(); } CThrottle * m_pThrottle; }; typedef boost::shared_ptr<CTestThread> _TestThreadPtr; int main(int argc, _TCHAR* argv[]) { CThrottle * pThrottle = new CThrottle(); boost::thread_group groupThreads; std::vector<_TestThreadPtr> list; for( int n=0; n < 10000; ++n ) { _TestThreadPtr ptrTest( new CTestThread ( pThrottle ) ); groupThreads.create_thread( *ptrTest.get() ); list.push_back( ptrTest ); } groupThreads.join_all(); delete pThrottle; return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1538697&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

boost wanted libraries
by shams 11 Aug '06

11 Aug '06

Hi, Does anyone know about the following libraries: boost::logging (required much in offically boost) boost::smart_assert boost::output_formatters if these libraries are available in the sandbox cvs? Does anyone know if they are ever going going to make it into boost? Thanks Shams

2 2

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 10 Aug '06

10 Aug '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Miércoles, Agosto 9, 2006 7:32 am Asunto: [boost] Boost.Bimap - Informal Review Request > Hello, > > Boost.Bimap, my SoC project is ready to confront the list. [...] > * Do you like the usage interface? Very much. I like the fact that in its most basic usage typedef bimap<A,B> bm_type; the syntax is as simple as it can get, yet the library allows for much more elaborated instantiations. > * In relation with Boost.MultiIndex, Do you think that it is > worth to have a bidirectional map library in Boost, that trades > generality for a better specialized user interface? > (Because this library was encouraged by the boost mentors the > answer will surely be yes, but it is a nice discussion to have) I think the barrier entry for Boost.Bimap is much lower that for Boost.MultiIndex, which is one of the main goals of the project. I also like the fact that Boost.Bimap is introduced without references to B.MI: many potential users of Boost.Bimap need not know anything about B.MI, so B.B can be regarded as a solution on its own in those cases rather than a transition stage to B.MI. > * Do you like the extended mapping framework? > Do you think it is intuitive for someone with a stl background? I think the framework is sound. I've got some doubts as to the understability of the part where the set of relation type is specified, this being perhaps the most unconventional aspect of the framework. > * What do you think of the design of operator[]? > Is there a better way to be coherent with the stl that does not > imply throwing exceptions? I think the current design of operator[] is almost dictated by the peculiarities of B.B: the semantics is as close as possible to that of std::map, but not closer. > * What is your evaluation of the implementation? > I am very interested in your reaction to the zero-overhead achieved > by the almost-standard mutant_relation class, and the standard > compliant label that this library acquires by including the > standard_relation class. Standardwise this is the most controversial part of the design. My personal opinion is that it's a deviation worth commiting to in order to achieve zero overhead. Others may dissent, though. Just to bring this issue forward to the list, let me state the problem in simple terms. Currently, Boost.Bimap is relying on the following three classes being layout-compatible for the same choice of arguments X and Y (actual names do not match those used inside B.B): template<typename X,typename Y> struct relation { X left; y right; }; template<typename X,typename Y> struct pair_by_left { X first; Y second; }; template<typename X,typename Y> struct pair_by_right { X second; Y first; }; Assuming layout compatibility allows us to "see" the elements of a bimap as pair_by_left's in the left view and pair_by_right's in the right view, thus matching the (first=key,second=data) syntax of a regular std::map. Needless to say all C++ compilers we know of do in fact provide such a layout compatibility. If we adhered strictly to the C++ standard, this kind of mirroring could only be achieved with non-zero overhead --for instance, holding references to left and right properly named "first" and "second" accordingly to the view. If I'm not wrong B.B assumes layout compatibility by default but can decay to a standard compliant solution for those (as of yet unknown) compilers where it could be needed. What do others think about this issue? > A big part of the library implementation is ContainerAdaptor. > Do you deem Boost.ContainerAdaptor worth eventually proposing to > Boost? Maybe the following can be tried to assess the power of this component: what about trying to implement Boost.PointerContainer using ContainerAdaptor, if only as a proof of concept? Would this result in a significant reduction in code size? > Looking forward to getting your feedback, I've got a feature request about list_of and vector_of. When writing for instance: bimap<set_of<X>,list_of<Y> > we know (unlike in Boost.MultiIndex) that the Y part does not belong to any index key and thus can be freely mutated. Could it be possible that, in those cases, the associated relation class held a mutable Y allowing for direct manipulation of that member? > Matias Capeletto Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

[regrex] Failure on newly added test regex_regress_threaded on Tru64/GCC
by Markus Schöpflin 10 Aug '06

10 Aug '06

For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2. Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT. Is there anything I can do to help in debugging? Markus

2 9

[Boost-bugs] [ boost-Patches-1538176 ] VARNAMES bjam rule doesn't work for global module
by SourceForge.net 10 Aug '06

10 Aug '06

Patches item #1538176, was opened at 2006-08-10 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1538176&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yakov Markovitch (markovitch) Assigned to: Nobody/Anonymous (nobody) Summary: VARNAMES bjam rule doesn't work for global module Initial Comment: VARNAMES bjam rule always returns empty list for the global module. This is due to the fact that builtin_varnames relies upon module_t::variables struct member being not NULL if there are variables in the module, which is wrong for the "currently running module" (i.e. frame->module->variables is _always_ NULL). This is due to the way enter_module() and var_hash_swap() work. Since builtin_varnames() always runs in the global module context, global module's 'variables' member is always NULL when builtin_varnames() is called. The proposed patch fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1538176&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2006-08-10 [RC_1_34_0])
by Douglas Gregor 10 Aug '06

10 Aug '06

Boost Regression test failures Report time: 2006-08-10T06:50:05Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 240 failures in 24 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) multi_array (1) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (20) program_options (9) python (58) random (1) rational (4) regex (1) serialization (26) signals (16) spirit (1) test (2) tr1 (51) typeof (9) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |multi_array| iterators: msvc-8.0 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 callbacks: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exec: cw-9.4 darwin-4.0.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_from_python_test: darwin-4.0.1 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress_threaded: gcc-4_0_3_tru64 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_primitive_text_warchive: msvc-8.0 test_registered_xml_archive_dll: msvc-8.0 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

[program_options] bugfix partially correct
by Ovanes Markarian 10 Aug '06

10 Aug '06

An assertion bug with VC 8.0 is partially correct at least in the version I found in CVS. options_description.cpp revision=1.16.2.1 This calculation does not assume the indent in the line used. The line_length added produces longer line sequence as would fit in the line, so a line wrap occurs. The output looks somehow ugly: -v [--version] test line dkakal alalalala a sdk dkdkdkd instead of: -v [--version] test line dkakal alalalala a sdk dkdkdkd Current calc: LineNo. 393 // Take care to never increment the iterator past 394 // the end, since MSVC 8.0 (brokenly), assumes that 395 // doing that, even if no access happens, is a bug. 396 unsigned remaining = distance(line_begin, par_end); 397 string::const_iterator line_end = line_begin + 398 ((remaining < line_length) ? remaining : line_length); My proposal would be adding before the while loop (line 377): size_t offset = line_length - indent; LineNo. 393 // Take care to never increment the iterator past 394 // the end, since MSVC 8.0 (brokenly), assumes that 395 // doing that, even if no access happens, is a bug. 396 unsigned remaining = distance(line_begin, par_end); 397 string::const_iterator line_end = line_begin + 398 ((remaining < offset) ? remaining : offset); With Kind Regards, Ovanes Markarian With Kind Regards, Ovanes

1 0

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 10 Aug '06

10 Aug '06

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Agosto 10, 2006 11:13 am Asunto: Re: [boost] Boost.Bimap - Informal Review Request [...] > However, looking at the reference docs for the list view, I'm > confused, for > example what is: > > O(I(n)) ? > > Looked a lot like a mis-spelled O(log(n)) when I looked at the html. > > What is O(D(n)) , O(R(n)) , O(M(n)) ? > > None of these have immediately obvious meanings to me. This notation is inherited from Boost.MultiIndex, so let me explain it briefly: the problem with documenting complexities for B.MI is that the overall O() estimate for a given operation depends on the number and type of indices the container is composed of: for instance, inserting into a container with a hashed index and a list-like index is O(1), but if we add an oredred index (which is based on a rb-tree) then the overall insertion complexity raises to O(log n). To document all this with precision, I analyze (complexity-wise) every operation in terms of six "primitives": * copying, * insertion, * hinted insertion, * deletion, * replacement, * modification, Each index, viewed in isolation, is characterized by a so-called complexity signature composed of functions c(n),i(n),h(n),d(n), r(m) and m(n). We use uppercase to refer to the sum of all individual contributions, for instance C(n)=c1(n)+...+cN(n) where ci is the copying complexity of the i-th index. Then, I can say that insertion into a multi-index container is O(I(n)): the exact expression of I(n) can be then calculated by summing the correspoding i(n) of each index, which are given in the reference. This is all explained in http://boost- consulting.com/boost/libs/multi_index/doc/reference/indices.html#comple xity_signature and also replicated (in the context of Boost.Bimap) in the reference of this lib. Is this clear now? > Thanks, John. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0