- Boost - lists.preview.boost.org

[python] division operator in 3.1
by Trigve Siver 09 Aug '10

09 Aug '10

Hi, I've found bug in boost python with division operator. Division operator with custom types doesn't work with python 3.1. It is because there were some changes in this regard in python 3. I've created ticket with patch https://svn.boost.org/trac/boost/ticket/4497 . Can somebody look at it? Thanks Trigve

3 3

[1.44] Release notes
by Daniel James 09 Aug '10

09 Aug '10

Hello, If you haven't done so yet, with the beta coming out it's a good time to add your entries to the release notes so that people know what to test. You can edit the file in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. If you're able to build the release notes, I better warn you that I've changed the build system a little. Recent versions of quickbook are generating slightly different mark up, and if that's used for old entries, they can appear as new in rss feeds. So to avoid that, it now stores a hash of the quickbook files to only update their entry if the source changes. It should just work, you just need to commit the '*-hashes.txt' files at the same time as the rss files. If you want to force an update, you can delete the appropriate line in the text file. thanks, Daniel

5 7

[mpl] BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF
by Edward Diener 09 Aug '10

09 Aug '10

I found the BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF macro in the latest has_xxx.hpp of mpl on the trunk. Is BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TEMPLATE_DEF ) scheduled to be added to Boost in an upcoming release ? I find it useful for TMP introspection in much the same way as BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF ).

5 10

Re: [boost] [GIL] color convert and color tranfer characteristics
by Fabien Castan 09 Aug '10

09 Aug '10

> Interesting! I would be interested in those implementation for the > toolbox extension. Let me know if you're interested submitting. I can > help out when needed. yes sure. > I'm not sure I follow here. Small code sample possible? You can see the code, it's just the beginning...: http://github.com/nrondaud/TuttleOFX/blob/master/plugins/image/process/colo… You can also see: * some utilities on gil we use (some are only a copy of standard functions adding a progress structure to get progress informations) and others needs a big clean: http://github.com/nrondaud/TuttleOFX/tree/master/libraries/tuttle/src/tuttl… * a copy of boost_gil_extensions with some modifications, in progress too: http://github.com/nrondaud/TuttleOFX/tree/master/3rdParty/boost_gil_extensi… > Right now color_convert doesn't supply passing the rgb_to_luminance > algorithm. But I 'm not sure if that's needed for your case. When you > use the algorithm copy_and_convert_pixels algorithm you pass as the > third parameter the color converter. In your case just define your own > color converter. Yes, but inside a templated function using abstract colors it's not always easy to do. Regards, Fabien

2 1

awesome visualization of Boost SVN repo
by Kenny Riddile 09 Aug '10

09 Aug '10

So I just discovered Gource ( http://code.google.com/p/gource/ ) and it is an absolutely amazing little program. I downloaded and converted the SVN log file for the Boost trunk repository and it was mesmerizing to watch Boost grow before my eyes over the course of 10 years. To save others the time and trouble, I've attached the converted log file so everyone can check it out. Just run: gource --log-format custom boost_gource.log or gource -WIDTHxHEIGHT -f --log-format custom boost_gource.log for full-screen. Have fun :) -Kenny Riddile

4 3

[intrusive] recursive intrusive data structures
by Tim Blechmann 09 Aug '10

09 Aug '10

hi all, is there an easy way to define recursive data structures? something like: struct my_node: boost::intrusive::list_base_hook<> { boost::intrusive::list<my_node> children; }; i am currently using a base class as helper, which causes very dirty code, since i explicitly need to cast from the base to the main class all over the place: struct my_node_base: boost::intrusive::list_base_hook<> {}; struct node: my_node_base { boost::intrusive::list<my_node_base> children; }; thanks, tim -- tim(a)klingt.org http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius

2 4

Jamroot changes
by Vladimir Prus 09 Aug '10

09 Aug '10

Folks, I have just checked in a big refactoring of Jamroot. Over the time it has grown too big and too unstructured, so I've added a new module, boostcpp, and moved most of the scary logic there, also clarying that logical blocks. I have tested the changes the best I could, but it is possible something still breaks. So, if you observe some strange behaviour when building trunk, you might want to immediately report that to me. Thanks, Volodya

1 0

Re: [boost] [GIL] color_convert
by fabien.castan＠free.fr 08 Aug '10

08 Aug '10

Hi Christian, > Only for rgba gil is using partial specialization since it's using the > rgb equivalent to do the wanted conversion. I think it's best to stick > with total specialization to avoid confusions and/or breaking other > people's code. > >> The goal of creating this generic conversion is that I can still make the conversion using an intermediate rgb colorspace if there is no specialization. > I think I just said that. ;-) For me, we can do that for all colorspaces. Sorry, I'm not sure to understand your position. You are agree to remove total specialization, even for rgba ? Are you agree to create a generic conversion from Colorspace to C2 for all colorspaces ? default_color_converter_impl<C1,rgba_t> // to remove default_color_converter_impl<rgba_t,C2> // do the same thing for all colorspace > Even when converting from gray to cmyk you wanna create a temporary > rgb value? I believe this is a bad idea for various reasons. Please > correct me when I'm wrong. I think there is only two problems: * approximation * performance But if we want to correct these problems we have only to create the missing specialization. So I don't see any problem. It's always interesting to have all conversions. I don't think we will have a specialization to make the conversion from hsl to cmyk in a near futur. So in these cases propose a solution with approximation and performance cost sounds good to me. And it works fine with user custom colorspaces. Regards, Fabien

2 1

[1.44.0][Math] Requesting permission to merge to release.
by John Maddock 08 Aug '10

08 Aug '10

If possible, I'd like to fix this issue: https://svn.boost.org/trac/boost/ticket/4504 for the final 1.44 release. The fix is trivial: https://svn.boost.org/trac/boost/changeset?reponame=&new=64597%40trunk%2Fbo… but the actual bug manifests as a rather nasty numerical error. There's also a related patch to update the tests, which is slightly more risky in that it adds many new test cases: https://svn.boost.org/trac/boost/changeset?reponame=&new=64597%40trunk%2Fli…. Is it acceptable to merge these to release at this late stage? Thanks, John.

2 4

[bcp] Bcp namespace rename on 1.44 release beta 1 causes runtime errors on range lib and build tool
by Cliff Green 08 Aug '10

08 Aug '10

John (and others), I just tested a full Boost extract with namespace rename (and namespace alias) on 1.44 release beta 1. After bootstrap building bjam from the distribution, I built bcp and then attempted to extract all of Boost (libs and tools) with namespace rename and alias (this time using "." to extract everything). I'm getting runtime errors from bcp: **** exception(200): Invalid parameter detected by C runtime library I've isolated it down to one library and one tool - the range library, and the build tool. All other libraries and tools individually successfully extract (with namespace rename). I tried doing a Boost root library build (with bjam) after the extract, but missing critical pieces of build is causing problems (which makes sense). I assume this is a high pri (at least the build tools part), so I'll be happy to help in any way. Cliff

2 4

[config] Support for variadic macros
by Edward Diener 07 Aug '10

07 Aug '10

What is the boost macro which can be used to determine whether or not a compiler supports variadic macros ? I looked at the config macros but could not find the necessary macro documented there.

4 12

[proto][1.43] Problem with proto::matches
by Antoine de Maricourt 07 Aug '10

07 Aug '10

Hi Eric, I went into the following error with a grammar using terminals of T[N] (terminal<int[2]> in the example, gcc 4.5.0, boost 1.43): /usr/local/include/boost/proto/matches.hpp:1026:13: error: ambiguous class template instantiation for struct boost::proto::detail::lambda_matches<int [2], boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:119:13: error: candidates are: struct boost::proto::detail::lambda_matches<T, boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:129:13: error: struct boost::proto::detail::lambda_matches<T [M], U, -0x00000000000000001l> Adding the following specialization in matches.hpp solves it: template<typename T, std::size_t M> struct lambda_matches<T[M], proto::_ BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(-1)> : mpl::true_ {}; Best regards, Antoine

2 4

[config] Configuratiion support for variadic macro
by Edward Diener 07 Aug '10

07 Aug '10

Should not Boost have a configuration macro indicating compilers which have support for variadic macros ?

1 0

[1.44][beta] Patch for missing header in boost/random/subtract_with_carry.hpp
by Denis Arnaud 07 Aug '10

07 Aug '10

Hello, following is a small patch to fix a compilation issue with boost/random/subtract_with_carry.hpp: ------------------------------------------------------------------------------------- --- a/boost/random/subtract_with_carry.hpp +++ b/boost/random/subtract_with_carry.hpp @@ -30,7 +30,7 @@ #include <boost/random/detail/seed.hpp> #include <boost/random/detail/operators.hpp> #include <boost/random/linear_congruential.hpp> - +#include <boost/random/detail/generator_seed_seq.hpp> namespace boost { namespace random { ------------------------------------------------------------------------------------- That issue has been spotted by Fedora packagers in the building of the QuantLib library: https://bugzilla.redhat.com/show_bug.cgi?id=621631 Could someone add that patch to the 1.44 branch? Thanks in advance Best Regards Denis

3 2

[bcp] Enhancements to bcp extract and namespace rename
by Cliff Green 06 Aug '10

06 Aug '10

John, as promised, here's a couple of enhancement requests to bcp, relative to namespace renaming. I know time can be (very) limited, so I'll help in any way I can, or maybe we can see if someone is looking for a relatively small contribution they can make to Boost, in a useful utility. I can file trac tickets, if you'd like (I haven't before, so will need to look at the process). First, a statement of project needs (and I would expect others have similar needs): --- My workgroup provides software libraries (using Boost) to another group (this is within a large aerospace company in the Seattle area) that also uses Boost. Unfortunately the Boost versions can be (and typically are) different. Both sets of software (libraries) are compiled into the same executable. The namespace rename feature of bcp allows multiple versions of Boost to co-exist in the same executable. The one restriction is that for a given translation unit (.cpp file), the same version of Boost must be used. (I know Artyom, I believe, also has a tool that allows multiple versions of Boost even in the same translation unit, but this is not something we need, and I would guess is a corner case for most developers.) Enhancement requests: -- I couldn't find a way to "wildcard" extract and rename all Boost libraries. I ended up performing the extract / rename one-by-one. I suppose I could generate a list of the libraries and compose an invocation of bcp with all libraries explicitly listed (assuming command line buffers won't be exhausted), or write a script to do this, but it seems that it wouldn't be hard for bcp to do it inside the code. -- Related to above, when extracting (and renaming) one-by-one, the same dependent libraries are copied out (and overwritten) over and over. With a "wildcard" (or "full list of libraries") I assume that shared dependent libraries would only be copied once. -- Related to above, if there's a "full copy, rename namespace for all libraries" facility, managing multiple shared dependent libraries becomes a moot point, since all libraries will be copied (dependent or not). And related to this is copying the few remaining non-source files that make up a release. So it comes down to using bcp not to extract a subset of dependent libraries, but instead to perform a full copy of a release, renaming namespaces in source code as appropriate. What do you think? Again, thanks for the quick and excellent help, Cliff

3 3

SVN either down or slowing to a crawl?
by John Maddock 06 Aug '10

06 Aug '10

Anyone any ideas? SVN has been almost impossibly slow the last few days, and today I can't connect at all :-( Cheers, John.

6 9

[Boost] [Random] reproducing numbers generated by R.
by Ronan Trépos 06 Aug '10

06 Aug '10

Dear Boost community, For validity concerns, I'm trying to reproduce pseudo random numbers generated by the sofware R with boost::random library. The R default number generator is the Mersenne-Twister with period 2^19937 -1 . 1. In R I tried : > set.seed(13) > runif(1) 0.7103224 2. With boost I tried : boost::mt19937 rng(13); boost::uniform_01<boost::mt19937> zeroone(rng); std::cout << zeroone() << std::endl; 0.777702 Has someone already experienced that ? Is it possible to reproduce the same numbers ? Maybe the mismatch comes from the fact that generated integers are translated into [0;1).. Thanks, Ronan Trépos -- Trépos Ronan INRA unité BIA, équipe MAD, Toulouse http://carlit.toulouse.inra.fr/wikiz/index.php/Ronan_TREPOS tel : 05 61 28 53 34

2 2

[website] Documentation up again.
by Daniel James 06 Aug '10

06 Aug '10

Hi, The documentation should be up again now, although only for the last two versions of boost. Daniel

1 0

docs website unaccessible
by Andrey Asadchev 06 Aug '10

06 Aug '10

hello I seem to be getting access forbidden for any file in http://www.boost.org/doc/

2 1

[preprocessor] Can it be used with C?
by Andy Venikov 06 Aug '10

06 Aug '10

It's not explicitly stated in the documentation, but since the preprocessor is supposed to be the same between C++ and C, can boost.preprocessor be used in C code? Thanks, Andy.

2 1

[offtopic] cygwin and wchar
by Eric Niebler 05 Aug '10

05 Aug '10

I see that the cygwin toolset now expects wchar support, and I've heard that cygwin does indeed support wchar now, but I don't know what I need to do to get it. Simply running the cygwin installer and letting it update everything doesn't seem to do the trick. Help? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 10

[1.44] Beta release candidate available
by Beman Dawes 05 Aug '10

05 Aug '10

Release candidate files for the 1.44.0 beta are available at http://boost.cowic.de/rc/ As always, the release managers appreciate it if you download the candidate of your choice and give it a try. Report both success and failure. I'm concerned about the number of failures showing for Build, Python, and Thread libraries. See http://beta.boost.org/development/tests/release/developer/summary.html. We need to fix those before the final release, but I don't want to hold the beta up any more. Thanks, --Beman

7 12

[GIL] color convert and color tranfer characteristics
by fabien.castan＠free.fr 05 Aug '10

05 Aug '10

Hi, I have a problem with the distinction between colorspaces and color characteristics. I'm writing a basic transfer characteristics between lin, log, sRGB, rec601, rec709... I'm writing something like I talked for colorspaces, in the mail about "color_correct": * a specialization between each color characteristic and lin * a generic conversion to a templated type using an intermediate lin conversion I have two problems: 1) I have written a per channel functor, which seems to be the right way. But I don't know how to not apply it on the alpha channel if there is an alpha channel... without loosing performances because my common usage is rgba :). 2) I don't know how we can connect this with color_convert, because if we want to make a conversion from RGB to gray, we have to assume that RGB is linear (?) and we need to precise if we want a rec709 or rec601 luminosity... GIL code use an approximation of Rec601 to compute the luminance. Y' = 0.299 R' + 0.587 G' + 0.114 B' (Rec. 601 coefficients) Y' = 0.2126 R' + 0.7152 G' + 0.0722 B' (Rec. 709 coefficients) Best regards, Fabien

2 1

Re: [boost] [GIL] color_convert
by fabien.castan＠free.fr 05 Aug '10

05 Aug '10

Hi, > I cannot recreate your problem. Here is a little test app that works > fine on my machine ( VC10 ) The problem is that I define a generic conversion like that: /// \ingroup ColorConvert /// \brief Converting HSL to any pixel type. Note: Supports homogeneous pixels only. /// /// Done by an intermediate RGB conversion template <typename C2> struct default_color_converter_impl<hsl_t,C2> { template <typename P1, typename P2> void operator()(const P1& src, P2& dst) const { typedef hsl_t C1; typedef typename channel_type<P1>::type T1; typedef typename channel_type<P2>::type T2; pixel<T2,rgb_layout_t> tmp; default_color_converter_impl<C1,rgb_t>()(src, tmp); default_color_converter_impl<rgb_t,C2>()(tmp, dst); } }; So it's in conflict with: template <typename C1> struct default_color_converter_impl<C1, rgba_t>, if I use color_convert( hslPixel, rgbaPixel ). The goal of creating this generic conversion is that I can still make the conversion using an intermediate rgb colorspace if there is no specialization. I think we can have a good solution, if we apply this method to all colorspaces: * define a generic conversion to another colorspace using an intermediate rgb colorspace conversion, only in one direction MyColorspace -> typename C2 (so without typename C1 -> MyColorspace). That's why I would like to remove typename C1 -> rgba_t implementation. * redefine the conversion for colorspaces we want to make a direct conversion

2 1

Re: [boost] Checking library binary compatibility with respect tocompile time options [repost\
by Robert Ramey 05 Aug '10

05 Aug '10

I notice that the link I sent to a respond to the above didn't handle the attachments well. So here they are again. Robert Ramey Original post from back in may Turns out that the idea of a single boost library deployment has come up a couple of times here at BoostCon 2010. While preparing my presentation I considered the problem of what would happen if one installed one library which depended on an newer version of a different library than the user already had installed. I actually woke up in the middle of the night imagining someone would ask about that during my talk. I puzzled about it for some time and the day before I found a way to address it - in my own mind at least. It also seems that it turns out that there are tools that can also manage this. It's not that I don't trust tools but I wear a belt AND suspenders. So I would like a method which guarentees that when I build one library, I don't accidently include code from a prerequisite library which is a version so old that things won't work. I would also like to know that I'm not accidently running with a DLL built with an old version. Basically each library includes a file "manifest.hpp". This get's included when any header get's includes (once at most due to include guards). This includes a static assert that checks that the prequiste libraries are of sufficiently recent version that a dependent library (or user application) requires. There is also a manifest.cpp file included in the library which checks any prequiste DLLS. This would be an exheedingly small overhead to avoid what could be an incredibly large headache. I just verified that the code compiles so at this point it's only an idea. But it seems that some kind of check like this is un-avoidable of one want's to deploy libraries as needed rather than as a monolithic distribution. FYI - no one asked me about this problem at my presentation. Add one more confirmation of Murphy's law. Robert Ramey

2 1