- Boost - lists.boost.org

[thread] #2637 shared mutex lock
by vicente.botet 30 May '09

30 May '09

Hi, "The folowing should be added template<typename TimeDuration?> bool shared_mutex::timed_lock_shared(TimeDuration? const & relative_time); template<typename TimeDuration?> bool shared_mutex::timed_lock(TimeDuration? const & relative_time); " Anthony, I think that this ticket is already on the released shared_mutex.hpp files: template<typename TimeDuration> bool timed_lock_shared(TimeDuration const & relative_time) { return timed_lock_shared(get_system_time()+relative_time); } template<typename TimeDuration> bool timed_lock(TimeDuration const & relative_time) { return timed_lock(get_system_time()+relative_time); } So it can be closed. Best, _____________________ Vicente Juan Botet Escribá

1 0

[thread] #2741 proposal to manage portable and non portable thread attributes
by vicente.botet 30 May '09

30 May '09

Hi, Anthony, I have attached to the ticket https://svn.boost.org/trac/boost/ticket/2741 a test files and patches for the feature POSIX implementation Do you think that this is on the right way? Best, _____________________ Vicente Juan Botet Escribá

1 0

Re: [boost] [Graph] how to test/submit patch
by Tim Keitt 30 May '09

30 May '09

On Fri, May 29, 2009 at 2:08 PM, Marshall Clow <marshall(a)idio.com> wrote: > At 1:02 PM -0500 5/29/09, Tim Keitt wrote: >> >> I would like to submit a patch for the Graph library. (This is the >> iterator splitting issue I raised some time ago.) > > Same answer as on the -users list ;-) > >> So what is the procedure? >> >> 1) check out source from sourceforge SVN (done) >> 2) make changes >> 3) run tests??? (what is the best way to ensure the behavior has not >> changed?) > > Run the tests. I was trying to ascertain where they live and how to run them. > If you think that there should be more tests, write them. Should be easy to come up with a test case or two. Just checking to see if I haven't missed something standard in terms of regressions, etc. > Ideally, you should write a test that fails on the unpatched version of the > library, and succeeds after applying your patch. The goal is not to change the existing behavior. My patch should not affect algorithms called on the built-in data structures. It will make the library compatible with my own data structures that require slightly more restrictive assumptions regarding iterator pairs. > >> 4) generate the patch (use svn diff?) > > Yep. Its been a long time -- are there preferred formats/switches when calling diff? (I recall vaguely a -p argument.) > >> 5) submit somewhere > > In a Trac ticket. <http://svn.boost.org> OK. Thanks for the help. THK > >> I just want to be sure I'm pulling the correct tree and there is some >> means to run regressions on my changes. > > Sounds good to me. > -- > -- Marshall > > Marshall Clow Idio Software <mailto:marshall@idio.com> > > It is by caffeine alone I set my mind in motion. > It is by the beans of Java that thoughts acquire speed, > the hands acquire shaking, the shaking becomes a warning. > It is by caffeine alone I set my mind in motion. > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Timothy H. Keitt Associate Professor Section of Integrative Biology University of Texas at Austin http://www.keittlab.org/

2 1

profile-templates
by Stefan Seefeld 30 May '09

30 May '09

Hello, I'v just learned about your template instantiation profiler tool, and I'm very intrigued ! What is the best way to download and build it ? I tried to check out sandbox/tools/profile_templates, but it seems that is not meant to be used stand-alone. Do I really need to check out the entirety of the sandbox (which is huge !) ? Or are there better ways to do it ? (How does that question fit into the current modularization discussion ? :-) ) Many thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

[parameter] Preventing instantiation of lazy binding operator() until default is needed
by Jeremiah Willcock 29 May '09

29 May '09

This is a subset of my previous email, with a more specific and concrete example. The following code: #include <boost/parameter/name.hpp> #include <boost/parameter/binding.hpp> BOOST_PARAMETER_NAME(my_param) template <typename T> struct s {}; template <typename T> struct bogus { typedef typename s<T>::type result_type; template <typename U> struct result: public s<U> {}; result_type operator()() const {return 0;} }; template <typename ArgPack> void f(const ArgPack& ap) { const char* cs = ap[_my_param || bogus<const char*>()]; } int main(int, char**) { f(_my_param = "foo"); return 0; } does not work because result_type is invalid when the struct bogus is instantiated when creating the default value used in operator||(). If operator()() was a template, I think the compiler would delay instantiating it until it was called. Is there a way to force operator()() to be a template in Boost.Parameter, allowing its return type to only be instantiated when Boost.Parameter knows that the default will be used? This is a simplified example from a larger piece of code where the lazy default does not have a valid return type in some cases, and the parameter must be explicitly specified in those cases. Thank you. -- Jeremiah Willcock

2 2

[random] fixing uniform_int bias
by Steven Watanabe 29 May '09

29 May '09

AMDG Given that we periodically get complaints about the non-uniformity of uniform_int, I'm going to commit that attached patch if no one objects. I had to modify one of the test cases, because it causes the modified uniform_int to loop forever. I believe that this is acceptable, because the test is giving uniform_int a generator that always returns the same value. The rejection method used currently will also loop under certain similar circumstances. The patch also fixes an operator precedence error. However, looking more closely, there appears to be another bug in that branch, which can cause a loop. Aaaaaargh. I'll probably get a complete patch sometime tomorrow, but in the meantime I'd appreciate having another pair of eyes looking at the fix I have. In Christ, Steven Watanabe

1 3

[inspect][filesystem] libs/filesystem/test/ticket_2260_test.cpp
by Jeremiah Willcock 29 May '09

29 May '09

The file libs/filesystem/test/ticket_2260_test.cpp appears in the Boost trunk inspection report at http://boost.cowic.de/rc/inspect-trunk.html but does not appear in SVN. Is that an old file in the directory where the inspections are taking place? -- Jeremiah Willcock

2 1

[1.39.0] Ready for beta?
by Beman Dawes 29 May '09

29 May '09

I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible. Are there any known showstoppers? If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted. Library authors who use Boostbook/Quickbook, but don't have time to look at the full snapshot, might want to check http://boost.cowic.de/rc/boost-docs.7z Known problems/questions: * index.html ??? needs to be replaced by new library count. * pdf docs: Do we want to do anything more for this release? Thanks, --Beman

13 29

[Graph] how to test/submit patch
by Tim Keitt 29 May '09

29 May '09

I would like to submit a patch for the Graph library. (This is the iterator splitting issue I raised some time ago.) So what is the procedure? 1) check out source from sourceforge SVN (done) 2) make changes 3) run tests??? (what is the best way to ensure the behavior has not changed?) 4) generate the patch (use svn diff?) 5) submit somewhere I just want to be sure I'm pulling the correct tree and there is some means to run regressions on my changes. Thanks. THK -- Timothy H. Keitt Associate Professor Section of Integrative Biology University of Texas at Austin http://www.keittlab.org/

3 2

[graph] Request for help with BGL bugs (Bug Sprint)
by Jeremiah Willcock 29 May '09

29 May '09

For those participating in the Boost Bug Sprint, I would appreciate help with the following items to help resolve BGL bugs: 1. Someone who has a copy of LEDA (or is willing to download one) can work on tickets 373, 375, and 1326. Ticket 1326 has an old patch that does not apply cleanly to the current version of BGL in Boost. I would also appreciate knowing which of these issues still exist in current versions of Boost. 2. I would appreciate someone looking at bug 735 and bringing its patch up to date. If there is a way to get a copy of the patch for bug 900 (requested on the Boost list), bringing that up to date would be good as well. 3. Someone should test the patch in bug 1021 and see if it breaks anything else in BGL (and fixes the relevant bug). Also, the copy of reverse_graph in there should be turned into a patch and tested to ensure that it does not undo other changes to BGL since it was created. Any help with these issues would be greatly appreciated. -- Jeremiah Willcock

1 0