- Boost-users - lists.boost.org

[ASIO] Streambuf not containing full line
by Gonzalo Garramuno 26 Feb '14

26 Feb '14

I am using asio asynchronically. I have: void tcp_session::start_read() { // Set a deadline for the read operation. // input_deadline_.expires_from_now(boost::posix_time::seconds(30)); // input_deadline_.expires_at(boost::posix_time::pos_infin); // Start an asynchronous operation to read a newline-delimited message. boost::asio::async_read_until(socket(), input_buffer_, '\n', boost::bind(&tcp_session::handle_read, shared_from_this(), boost::asio::placeholders::error)); } void tcp_session::handle_read(const boost::system::error_code& ec) { if (stopped()) return; if (!ec) { // Extract the newline-delimited message from the buffer. std::string msg; std::istream is(&input_buffer_); is.exceptions( std::ifstream::failbit | std::ifstream::badbit | std::ifstream::eofbit ); try { while ( std::getline(is, msg) ) { // parse msg here (gets truncated to last 256 chars or so) std::cerr << msg << std::endl; } } catch ( const std::ios_base::failure& e ) { std::cerr << "getline failure " << e.what() << std::endl; } } My problem is that I am seeing messages that are not a full line, but a truncation of the line, as if a buffer gets full with 256 characters. I am unsure what I am doing wrong. I get a getline failure saying basic_ios::clear.

2 1

[fusion] nth runtime element of a sequence
by MM 26 Feb '14

26 Feb '14

Hello, I just wanted to confirm there's no provided method to get the n'th element of say a fusion vector where n is known at runtime, except of handling it explicitkly with a switch case? Thanks MM

4 9

Project link error with Wave on OSX
by Olivier Prat 26 Feb '14

26 Feb '14

I've just updated a project that was working under XCode 4 with boost 1.48 to XCode 5 and boost 1.55 (installed with MacPorts). Now I have a link error with Wave which wasn't the case before. This somehow baffles me as I thought everything was template based. I am also linking with libboost-wave.mt.a but that doesn't solve the problem. The linker errors are, among 6 others: Undefined symbols for architecture x86_64: "boost::wave::cpplexer::new_lexer_gen<__gnu_cxx::__normal_iterator<char*, std::string>, boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > >, boost::wave::cpplexer::lex_token<boost::wave::util::file_position< boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >::new_lexer(__gnu_cxx::__normal_iterator<char*, std::string> const&, __gnu_cxx::__normal_iterator<char*, std::string> const&, boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > const&, boost::wave::language_support)", referenced from: I've tried forcing std::string as the BOOST_WAVE_STRINGTYPE, but that just changes the signatures of the undefined symbols. I fail to see what has changed and I am completely stuck. I would have understood if I had a compiler error but this is a link error. Is this something to do with the standard C++ library? For my project, C++ dialect is C++98 and the standard library is libstdc++. Thanks in advance, Olivier

2 4

Question on writing HTTP parser
by gomti 25 Feb '14

25 Feb '14

Hello. I'm newbie for boost library. I'm trying to write a HTTP Parser, which handles the HTTP message coming from the proxy server. I don't know much about the boost, so I'm really confused on what to use to write my functionality. When I search on the internet, some say that I need to used Boost.Asio and Some say Boost.Spirit. When I looked over the document for each, I found that Boost.Asio is like network library for C++ and Boost.Spirit is for writing compilers. As I mention above, I want to write a http parser. I think the relevant one is the following: https://github.com/joyent/http-parser Please give me some advice. Since this is my first posting, I don't know the culture in this mailing list so if I'm doing some mistake in here, please let me know. Thanks.

3 3

Parallel Dijkstra with Predecessors
by Florian Meier 25 Feb '14

25 Feb '14

Hi, I am trying to use the parallel Dijkstra implementation with predecessors, but I am not able to compile it. Please have a look at the following diff against boost_1_53_0/libs/graph_parallel/example/dijkstra_shortest_paths.cpp (You can find the modified version attached.) ------------------------------------------- @@ -45,8 +45,10 @@ /* An undirected, weighted graph with distance values stored on the vertices. */ +typedef adjacency_list_traits<vecS, distributedS<mpi_process_group, vecS>, undirectedS>::vertex_descriptor vertex_descriptor; + typedef adjacency_list<vecS, distributedS<mpi_process_group, vecS>, undirectedS, - /*Vertex properties=*/property<vertex_distance_t, float>, + /*Vertex properties=*/property<vertex_distance_t, float, property<vertex_predecessor_t, vertex_descriptor> >, /*Edge properties=*/property<edge_weight_t, float> > Graph; @@ -71,7 +73,7 @@ // Compute shortest paths from vertex 0 dijkstra_shortest_paths(g, start, - distance_map(get(vertex_distance, g))); + distance_map(get(vertex_distance, g)).predecessor_map(get(vertex_predecessor, g))); // Output a Graphviz DOT file std::string outfile = filename; ------------------------------------------- This (actually get(vertex_predecessor, g)) gives me ------------------------------------------- In file included from /usr/include/boost/property_map/parallel/distributed_property_map.hpp:706:0, from /usr/include/boost/property_map/property_map.hpp:645, from /usr/include/boost/graph/properties.hpp:19, from /usr/include/boost/mpi/graph_communicator.hpp:30, from /usr/include/boost/mpi.hpp:27, from /usr/include/boost/graph/distributed/mpi_process_group.hpp:30, from dijkstra_shortest_paths.cpp:16: /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp: In instantiation of ‘void boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::handle_message<Reduce>::handle_multiput(int, int, const std::vector<boost::unsafe_pair<typename boost::property_traits<StorageMap>::key_type, typename boost::property_traits<StorageMap>::value_type> >&, boost::graph::parallel::trigger_receive_context) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>; typename boost::property_traits<StorageMap>::value_type = boost::detail::parallel::global_descriptor<long unsigned int>; typename boost::property_traits<StorageMap>::key_type = long unsigned int]’: /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:255:18: required from ‘void boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::handle_message<Reduce>::setup_triggers(boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::process_group_type&) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, shor t int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>; boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::process_group_type = boost::graph::distributed::mpi_process_group]’ /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:35:3: required from ‘boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::distributed_property_map(const ProcessGroup&, const GlobalMap&, const StorageMap&, const Reduce&) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, floa t> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>]’ /usr/include/boost/graph/distributed/adjacency_list.hpp:3468:50: required from ‘typename boost::property_map<boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, Property>::type boost::get(Property, boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>&) [with Property = boost::vertex_predecessor_t; OutEdgeListS = boost::vecS; ProcessGroup = boost::graph::distributed::mpi_process_group; InVertexListS = boost::vecS; InDistribution = boost::defaultS; DirectedS = boost::undirectedS; VertexProperty = boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >; EdgeProperty = boost::property<boost::edge_weight_t, float>; GraphProperty = boost::no_property; EdgeL istS = boost::listS; typename boost::property_map<boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, Property>::type = boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<b oost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t> >]’ dijkstra_shortest_paths.cpp:77:106: required from here /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:236:47: error: no match for call to ‘(boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >) (const long unsigned int&, boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t , float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t> >::value_type&, const boost::detail::parallel::global_descriptor<long unsigned int>&)’ values[i].second)); ^ In file included from /usr/include/boost/graph/distributed/breadth_first_search.hpp:23:0, from /usr/include/boost/graph/breadth_first_search.hpp:404, from /usr/include/boost/graph/dijkstra_shortest_paths.hpp:21, from dijkstra_shortest_paths.cpp:19: /usr/include/boost/graph/parallel/properties.hpp:90:11: note: candidates are: class apply ^ /usr/include/boost/graph/parallel/properties.hpp:95:9: note: T boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T) const [with T = boost::detail::parallel::global_descriptor<long unsigned int>] T operator()(T key) const { return key; } ^ /usr/include/boost/graph/parallel/properties.hpp:95:9: note: candidate expects 1 argument, 3 provided /usr/include/boost/graph/parallel/properties.hpp:96:9: note: T boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T, T, T) const [with T = boost::detail::parallel::global_descriptor<long unsigned int>] T operator()(T key, T, T y) const { return y; } ^ /usr/include/boost/graph/parallel/properties.hpp:96:9: note: no known conversion for argument 1 from ‘const long unsigned int’ to ‘boost::detail::parallel::global_descriptor<long unsigned int>’ ------------------------------------------- What is wrong here? Greetings, Florian

2 1

boost/graph/metric_tsp_approx.hpp patch, is there interest?
by Paolo Bolzoni 25 Feb '14

25 Feb '14

Dear list, In the boost/graph/metric_tsp_approx.hpp:224 is a note // TODO: This is will be O(n^2) if vertex storage of g != vecS. Since I am exactly in this situation I made a patch for my use, I added a bundled property to MSTImpl's vertices to contain a descriptor to keep track of the original graph vertices. It is a small modification, but since there is a TODO perhaps there is interest? If so how should I share it? Of course any comment is welcome. Your sincerely, Paolo

1 0

[icl] Icl broken for c++11's hint semantics. Fix provided.
by Joachim Faulhaber 25 Feb '14

25 Feb '14

Dear Icl users, due to a subtle effect of the changed hint semantics for associative containers, the icl library is broken in versions <= 1.55.0 when used with new STL-libraries that implement the new c++11 standard. This bug is fixed in the upcoming Boost 1.56.0. (see regression tests at http://www.boost.org/development/tests/master/developer/icl.html) Since the release of boost 1.56.0 seems to take longer than planned due to restructuring efforts for modular-boost, users of Boost.Icl affected by the problem may choose to pull the fixed Boost.Icl directly from the git repository and replace your_boost_1_55_0/boost/icl with the new code. The libs/icl part does not need an update. Another possibility is to apply the patch-file diff_icl_1_55_0_and_master.patch that is attached to this post to your local boost library 1.55.0: 1. cd to your_boost_1_55_0 root directory. your_boost_1_55_0> 2. From the command line type your_boost_1_55_0> patch -p2 < diff_icl_1_55_0_and_master.patch You may check the patched library by moving to your_boost_1_55_0/libs/icl/test and run your_boost_1_55_0/libs/icl/test> bjam Sorry for the inconvenience. Best regards, Joachim P.S.: For those interested in details of the issue here is a report: The semantics of insertion with hint in associative containers changed in c++11 form insert-after-hint (c++98/03) to insert-before-hint (c++11) see e.g. proposal N1780: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html so for an associative container c of type C, a value x and an iterator hint c.insert(hint, x); //tries to insert x right after hint in c++98 c.insert(hint, x); //tries to insert x before hint in c++11 In accordance with this behavior, if using the insert function std::pair<bool, iterator> C::insert(value_type const& x); (success, hint) = c.insert(x); the iterator hint of unsuccessful insertion is the matching hint, pointing to [c++98] the last element y in c that is not greater x, so x can be inserted *after* that hint. [c++11] the first element z in c that is greater than x, so x can be inserted *before* that hint. In Boost.Icl I used the returned hint-iterator of the insert function, that always returned the last overlapping interval y for an inserted interval x given the interval's exclusive-less ordering under c++98. With the changed hint semantics, this returned hint-iterator did not point to the last interval y overlapping x anymore but to the first interval z not overlapping x. Therefore the code was broken and returned false results. -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Intrusive unordered set and thread safety
by Dave Davoren 25 Feb '14

25 Feb '14

Hi, I have been playing around with the boost intrusive unordered set. If my application is multi-threaded I do not see any way to make the set thread safe at a bucket level. I have seen a previous post from November 2012 "[Intrusive] unordered_set and thread safety" which asked the same question. At that point it was not implemented but I have not seen any updates in that area since. My question is, has it been implemented or is there a plan to implement such a feature in the near future? Thank you, Dave.

2 2

Re: [Boost-users] [interprocess] Shared memory object
by Ahmed Charles 24 Feb '14

24 Feb '14

Windows doesn't have to write to disk if there is no memory pressure in the case of a page file but if you have an explicit file being mapped, then you'll get writes to disk. This hypothesis should be easy to observe by monitoring the disk activity during your perf tests. ________________________________ From: Davies, John Sent: 2/21/2014 1:28 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [interprocess] Shared memory object >From my reading, the Windows version is faster but it doesn't have the persistence as the Linux version. The description mentions this: A class that wraps the native Windows shared memory that is implemented as a file mapping of the paging file. Unlike shared_memory_object<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/shared_mem…>, windows_shared_memory<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/windows_sh…> has no kernel persistence and the shared memory is destroyed when all processes destroy all their windows_shared_memory<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/windows_sh…> objects and mapped regions for the same shared memory or the processes end/crash. Boost lets you choose what means more to you. ___________________________________ John Davies Contractor Home Respiratory Care Philips Home Healthcare Solutions 1740 Golden Mile Highway Monroeville, PA 15146 Email: john.davies(a)philips.com Fax: 724-387-4109 From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Patrick Steele Sent: Thursday, February 20, 2014 11:40 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [interprocess] Shared memory object Tests at the time were showing the Windows version to operate about twice as fast. If nothing has changed I guess I will remain with it then. I had just been hoping for the code to be more platform dependent. On 20 February 2014 14:44, Ion Gaztañaga <igaztanaga(a)gmail.com<mailto:igaztanaga@gmail.com>> wrote: El 20/02/2014 11:42, Patrick Steele escribió: Hi, can anyone tell me if there is a performance or other difference between boost::interprocess::shared_memory_object and boost::interprocess::windows_shared_memory? With the version of boost we were using back in 2011 ( boost 1.48 ), we found that windows_shared_memory operated faster than shared_memory_object when transporting around 10MB of data. Is this still the case? Thanks, Nothing has changed AFAIK. shared_memory_object is a memory mapped file whereas windows_shared_memory is backed by the pagefile. I don't know why Windows should make one faster than the other, though. Best, Ion _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[iostreams] gzip problem
by Olaf Krzikalla 24 Feb '14

24 Feb '14

Hi @boost, I have a file format containing chunks of gzipped data (using gzip_decompressor/gzip_compressor). Inbetween these chunks there is other (plain) data. So can keep the archive seekable. However apparently this doesn't work out as it should. Whenever gzip_decompressor reaches the end of a chunk it throws an exception. The trouble-making line is in basic_gzip_decompressor::read: if (footer_.done()) { if (footer_.crc() != this->crc()) boost::throw_exception(gzip_error(gzip::bad_crc)); int c = boost::iostreams::get(peek); if (traits_type::is_eof(c)) { ----------------------------- state_ = s_done; } else { peek.putback(c); base_type::close(peek, BOOST_IOS::in); state_ = s_start; header_.reset(); footer_.reset(); } } Thus after the footer is read and checked, the decompressor checks whether or not eof is reached. Obvisiously this isn't the case here - the decompressed chunk is just embedded in the file. Thus the decompressor restarts, but cannot find another header thus throwing an exception. Would it be reasonable to just insert a break? header_.reset(); footer_.reset(); + break; } } This would solve _my_ problem. Or is there another way to work around this issue? Best Olaf

2 2