- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1567818 ] Fruchterman-Reingold grid performance can be improved
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567818, was opened at 2006-09-29 11:23 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=1567818&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: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Fruchterman-Reingold grid performance can be improved Initial Comment: Jens Müller schrieb: I have the code at home, so I'll send it this afternoon. It's attached ... Please test if it's faster for you, too ... Index: fruchterman_reingold.hpp =========================================== ======================== RCS file: /cvsroot/boost/boost/boost/graph/ fruchterman_reingold.hpp,v retrieving revision 1.11 diff -r1.11 fruchterman_reingold.hpp 134c134 < std::size_t adj_start_row = row == 0? 0 : row - 1; --- /* std::size_t adj_start_row = row == 0? 0 : row - 1; 147a148,201 } */ // Alternative 1: std::size_t adj_start_row = row == 0? 0 : row - 1; std::size_t adj_end_row = row == rows - 1? row : row + 1; std::size_t adj_start_column = column == 0? 0 : column - 1; std::size_t adj_end_column = column == columns - 1? column : column + 1; for (std::size_t other_row = adj_start_row; other_row <= adj_end_row; ++other_row) for (std::size_t other_column = adj_start_column; other_column <= adj_end_column; ++other_column) if ((other_row <= row && other_column <= column && (other_row != row || other_column != column)) || (other_column == column+1 && other_row == row - 1)) { // Repulse vertices in this bucket bucket_t& other_bucket = buckets[other_row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } // Alternative 2: /* if (row != 0) { std::size_t other_row = row - 1; if (column != 0) { std::size_t other_column = column - 1; // field 1 bucket_t& other_bucket = buckets[other_row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } // field 2 bucket_t& other_bucket = buckets[other_row * columns + column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } if (column != columns - 1) { // field 3 std::size_t other_column = column + 1; bucket_t& other_bucket = buckets[other_row * columns + column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } 148a203,215 } if (column != 0) { std::size_t other_column = column - 1; // field 4 bucket_t& other_bucket = buckets[row * columns + other_column]; for (v = other_bucket.begin(); v != other_bucket.end(); ++v) { apply_force(*u, *v); apply_force(*v, *u); } } */ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567818&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567812 ] Numbered headers don't work with "preferred" syntax
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567812, was opened at 2006-09-29 11:20 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=1567812&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: signals Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Numbered headers don't work with "preferred" syntax Initial Comment: Hi, I'd like to write the "Preferred syntax" of a signal while including a header for a fixed number of parameters. This works for boost::function, but not for boost::signal. Surprisingly, it seems that signal1.hpp does only generate a signal1 template, in contrast to function1.hpp. :[ Couldn't that be aligned to boost::function? #include <boost/function/function1.hpp> typedef boost::function1<void, void> F1; // compiles typedef boost::function<void (void)> F2; // compiles #include <boost/signals/signal1.hpp> typedef boost::signal1<void, void> S1; // compiles typedef boost::signal<void (void)> S2; // does not compile -- David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567812&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1567811 ] Johnson All-Pairs needs better "no path" information
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567811, was opened at 2006-09-29 11:19 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=1567811&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: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Johnson All-Pairs needs better "no path" information Initial Comment: Hi, The Johnson's SP algorithm as implemented in the BGL does not easily provide a way to determine whether two vertices are do have a path between them. I include below a simplified version of the example provided with the BGL. Running it I get the output below: D[0][0]=0 D[0][1]=3 D[0][2]=-4 D[1][0]=2147483647 <- no path between nodes '1' and '0' D[1][1]=0 D[1][2]=2147483643 <- no path between nodes '1' and '2' D[2][0]=-2147483645 <- no path between nodes '2' and '0' D[2][1]=-2147483645 <- no path between nodes '2' and '1' D[2][2]=0 That is, there isn't one single value that represents lack of connectivity - one has to pick a value close enough to 'inf' and discriminate with that. Shouldn't 'inf' (however represented) describe lack of connectivity? (To get around this problem, at the moment I run a transitive closure before JSP and use the result of that to determine whether two vertices are connected). Does this make sense or am I missing something? Thanks, Andrea #include <boost/property_map.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/johnson_all_pairs_shortest.hpp> #include <iostream> int main() { using namespace boost; typedef adjacency_list<vecS, vecS, directedS, no_property, property< edge_weight_t, int, property< edge_weight2_t, int > > > Graph; const int V = 3; typedef std::pair < int, int >Edge; Edge edge_array[] = { Edge(0, 1), Edge(0, 2) }; const std::size_t E = sizeof(edge_array) / sizeof(Edge); Graph g(edge_array, edge_array + E, V); property_map < Graph, edge_weight_t >::type w = get(edge_weight, g); int weights[] = { 3, -4 }; int *wp = weights; graph_traits < Graph >::edge_iterator e, e_end; for (boost::tie(e, e_end) = edges(g); e != e_end; ++e) w[*e] = *wp++; std::vector < int >d(V, (std::numeric_limits < int >::max)()); int D[V][V]; johnson_all_pairs_shortest_paths(g, D, distance_map(&d[0])); std::cout << " "; std::cout << std::endl; for (int i = 0; i < V; ++i) for (int j = 0; j < V; ++j) std::cout << "D[" << i << "][" << j << "]=" << D[i][j] << std::endl; return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567811&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

std::tr1::unordered* and functional/hash
by Dave Handley 29 Sep '06

29 Sep '06

My first question here is a simple one - are there any plans for an implementation of unordered_set etc. from TR1 to be included in boost. Since the vast majority of the std::tr1 libraries are from boost, except for this one, it seems an obvious gap to try and fill. My second thought concerns the interface in std::tr1 for unordered_set - specifically for the find, count and equal_range functions. In the std::tr1 documents that I have read, the interface is very vanilla: // lookup iterator find(const key_type& k); const_iterator find(const key_type& k) const; size_type count(const key_type& k) const; std::pair<iterator, iterator> equal_range(const key_type& k); std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const; However, the interface we use on our internal version of this is slightly different - based primarily on the interface for boost.multi_index: template <typename CompatibleKey> iterator find(const CompatibleKey &k); template <typename CompatibleKey, typename CompatibleHash, typename CompatiblePred> iterator find(const CompatibleKey &k, const CompatibleHash &hash, const CompatiblePred &pred); etc. This is useful for performance reasons in many cases. For example, in the case of an unordered_set<std::string> we can then provide a hash function and comparator that work with both std::string and const char *. This can then either be provided through the type of the container, or simply through the second version of the find function. For example: struct StringHasher { size_t operator()(const char *str_) const; size_t operator()(const std::string &str_) const; }; struct StringComparator { bool operator()(const char *lhs_, const std::string &rhs_) const; bool operator()(const std::string &lhs_, const char *rhs_) const; bool operator()(const std::string &lhs_, const std::string &rhs_) const; }; typedef std::tr1::unordered_set<std::string, StringHasher, StringComparator> Set1; typedef std::tr1::unordered_set<std::string> Set2; Set1 set1; set1.find("abc"); // This will not create a std::string temporary in the find function. Set2 set2; set2.find("abc", StringHasher(), StringComparator()); // This will also not create a temporary set2.find("abc"); // This will create a temporary My final thought is that it would be useful if the boost.functional/hash provided functionality as standard similar to the StringHasher/StringComparator above. I use this sort of code a lot when I'm working with hash containers and boost.multi_index and it seems wasteful to have to rewrite it regularly - especially when it is so simple to do. Any thoughts on these points? Dave Handley

1 0

[boostbook] Allow SVN dates in last-revision
by Julio M. Merino Vidal 29 Sep '06

29 Sep '06

Hello, While developing my SoC project under a Subversion repository I found that the 'Last revised' entry in the main documentation page generated by Boostbook did not appear correctly. Upon further investigation, it appears that Boostbook's HTML generation code only recognizes CVS' $Date$ tag format. Therefore it failed to process SVN's entity contents and resulted in an empty date string. The attached patch adds support for SVN dates and tries to automatically detect the appropriate format. I hope this is correct and can be integrated into the tree. Thanks. -- Julio M. Merino Vidal <jmmv84(a)gmail.com> The Julipedia - http://julipedia.blogspot.com/

2 1

[Boost-bugs] [ boost-Bugs-1567797 ] GraphViz reader ignores graph properties
by SourceForge.net 29 Sep '06

29 Sep '06

Bugs item #1567797, was opened at 2006-09-29 11:04 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=1567797&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: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: GraphViz reader ignores graph properties Initial Comment: The GraphViz reader ignores all graph properties. Oops! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1567797&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [asio] SSL operation sporadically returns "Access is denied"
by Christopher Kohlhoff 29 Sep '06

29 Sep '06

Hi Scott, I was about to write to say that I ran your previous test program for about half an hour without any problems. > I started thinking about my own client code and read up on the > socket class. The docs say the socket object is unsafe for > shared objects. So I put locks around every async_read or > async_write operation. However, it still fails. > > Is the problem with my code the fact that 2 threads are using > the same socket? Yes, that is a problem. I don't know if it is *the* problem. > Is that just not possible? Rather than using a mutex, a better approach would be to use an asio::strand object. You can use a strand to wrap your handlers and they won't be executed concurrently (see the last timer tutorial for an example). A mutex will *not* give the correct behaviour in the case of "composed" operations like boost::asio::async_write. (Note: i'm assuming you're using the latest code in CVS here.) However, I am not confident that the current SSL wrapper implementation is thread safe even if you use a strand. It may simply be safer at this time to stick to using an individual SSL object from a single thread. In practice that means only calling io_service::run() from a single thread. What exactly is it that you want to do with the second thread? There may be another way of structuring it to give the same effect while keeping all access to the ssl/socket object from the one thread. Cheers, Chris

1 0

Re: [boost] [asio] SSL operation sporadically returns "Access is denied"
by Scott 29 Sep '06

29 Sep '06

Hi Chris, > > In the client, I have 2 threads. The main thread is the one > that sends > random messages to the server. The other thread handles all incoming > responses and prints out the number of bytes received. Both > threads share > the same io_service. It is my understanding from the docs > that multiple > threads can all share an io_service, but please let me know > if the code is > incorrect. I started thinking about my own client code and read up on the socket class. The docs say the socket object is unsafe for shared objects. So I put locks around every async_read or async_write operation. However, it still fails. Is the problem with my code the fact that 2 threads are using the same socket? Is that just not possible? Thanks, Scott

1 0

Trouble with asio while compiling libtorrent
by the-real-sim＠gmx.de 29 Sep '06

29 Sep '06

Hello List, i tried to compile libtorrent (libtorrent.sf.net) but i get the following error message: ../include/libtorrent/asio/socket_base.hpp:432: error: '__invalid_size_argument_for_IOC' cannot appear in a constant-expression ../include/libtorrent/asio/socket_base.hpp:432: error: template argument 1 is invalid ../include/libtorrent/asio/socket_base.hpp:455: error: '__invalid_size_argument_for_IOC' cannot appear in a constant-expression ../include/libtorrent/asio/socket_base.hpp:455: error: template argument 1 is invalid ../include/libtorrent/asio/basic_stream_socket.hpp: In member function 'size_t asio::basic_stream_socket<Protocol, Service>::in_avail()': ../include/libtorrent/asio/basic_stream_socket.hpp:786: error: request for member 'get' in 'command', which is of non-class type 'int' ../include/libtorrent/asio/basic_stream_socket.hpp: In member function 'size_t asio::basic_stream_socket<Protocol, Service>::in_avail(Error_Handler)': ../include/libtorrent/asio/basic_stream_socket.hpp:808: error: request for member 'get' in 'command', which is of non-class type 'int' make[2]: *** [allocate_resources.lo] Error 1 someone from the libtorrent list said i should post here. the ./configure script from libtorrent ran without a hitch. here's what's on my G3 Powerbook: Ubuntu 6.06 LTS ubuntu boost version: 1.33.1-2 any hints/tips/ideas welcome :) thanks in advance, #Simon -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

1 0

Problem with conditional variables in boost
by Mariusz Kedzierawski 29 Sep '06

29 Sep '06

Hi I think there is a problem in implementation of function: void condition_impl::notify_one() (with BOOST_HAS_MPTASKS beeing defined - apple version) in file condition.cpp There is no mutex release before leaving that function in one place: (The same problem is in fuction notify_all) //------[ BEGIN ]------------------------------------ void condition_impl::notify_one() { unsigned signals = 0; OSStatus lStatus = noErr; lStatus = safe_enter_critical_region(m_mutex, kDurationForever, m_mutex_mutex); assert(lStatus == noErr); if (m_waiting != 0) // the m_gate is already closed { if (m_blocked == 0) { lStatus = MPExitCriticalRegion(m_mutex); assert(lStatus == noErr); return; } ++m_waiting; --m_blocked; /************************************************/ /************************************************/ There is no MPExitCriticalRegion(m_mutex) here ! /************************************************/ /************************************************/ } else { lStatus = safe_wait_on_semaphore(m_gate, kDurationForever); assert(lStatus == noErr); if (m_blocked > m_gone) { if (m_gone != 0) { m_blocked -= m_gone; m_gone = 0; } signals = m_waiting = 1; --m_blocked; } else { lStatus = MPSignalSemaphore(m_gate); assert(lStatus == noErr); } /************************************************/ /************************************************/ Solution could be putting "}" here instead of after ongoing while (signals) {...} /************************************************/ /************************************************/ lStatus = MPExitCriticalRegion(m_mutex); assert(lStatus == noErr); while (signals) { lStatus = MPSignalSemaphore(m_queue); assert(lStatus == noErr); --signals; } } } //------[ END ]------------------------------------ Second problem is in file condition.hpp //------[ BEGIN ]------------------------------------ template <typename M> void do_wait(M& mutex) { /... m_impl.enter_wait(); //... lock_ops::unlock(mutex, state); /************************************************/ /************************************************/ Unlocking mutex and hanging on semaphore should be atomic operation and here it is not (notification can be lost here (becouse of switching between threads) and thread can than wait for it forever). /************************************************/ /************************************************/ m_impl.do_wait(); //... lock_ops::lock(mutex, state); //... } //------[ END ]------------------------------------ Please correct me if I am wrong :) -- Mariusz Kedzierawski M(dot)Kedzierawski(a)gmail.com

4 6