June 2009 - Boost - lists.boost.org

trunk vs release
by troy d. straszheim 04 Jun '09

04 Jun '09

From another thread: Steven Watanabe wrote: > AMDG > > troy d. straszheim wrote: >> I've been wondering a bit about this in-syncness recently. >> >> - Does anybody know offhand what the last release was that was >> branched directly from trunk? >> >> - Is there a way to determine, with SVN, how many lines of diff >> there are between trunk and release? I've tried without >> success.... the diff gets to ~80k lines and then the network times >> out. I wonder if I'm doing something wrong. Of course I can get >> some numbers with git but I'm not quite sure I trust them yet. >> >> % git diff --shortstat svn/release svn/master 3505 files changed, >> 209061 insertions(+), 58428 deletions(-) > > This is probably correct as far as it goes. However, it's hard to > tell how much it really means. About half the modified files seem to > be generated html, judging by the output of > > svn diff https://svn.boost.org/svn/boost/branches/release > https://svn.boost.org/svn/boost/trunk --summarize > Hm, that svn command isn't very helpful and runs for ~5 minutes. I'm seeing about 160k lines total changed in actual code (.cpp, .ipp, .hpp). Full report in case anybody is interested: http://sodium.resophonic.com/trunk_vs_release.txt Poking around it looks like the current release branch was created from the fixed 1.34.1 tag in oct 2007 (@ r40341). The 1.34.1 release was in turn branched from... looks like that goes back into the days of CVS, I'll consider it lost. Git maintains that the last common commit between the current trunk and release branches is > 3 years ago: http://gitorious.org/boost/svn/commit/4914d4934fbc7368e2d43e057f6fffdac0f46… So if the trunk is really just a staging area for merges to release, does the notion of having the release branch and trunk 'in sync' at this point make any sense? Why have just one such staging area? -t

13 74

[Serialization]#3118 basic_binary_oarchive.hpp - save_override possible loss of data warnings
by Jeff Flinn 04 Jun '09

04 Jun '09

I've posted the following ticket in light of the current bug sprint. ----------- The following save_override overloads cause possible loss of data warnings on MSVC8 and XCode3.1.2/gcc4.0.1 void save_override(const version_type & t, int) void save_override(const class_id_type & t, int) void save_override(const class_id_reference_type & t, int) with their respective assignments: const unsigned char x = t.t; const int_least16_t x = t.t; While a possible fix would be: const unsigned char x = static_cast<unsigned char>(t.t); const int_least16_t x = static_cast<int_least16_t>(t.t); there is still a possibility of a silent loss of data. We could be safer and use numeric_cast, but that would possibly impact code size and performance, and would introduce a library dependency. Why are the xxx_type strong typedef's using int rather than the smaller types that are being serialized? Any thoughts on the best solution? Thanks, Jeff

4 5

[Bug Sprint][random] overload resolution for constructors/seed
by Steven Watanabe 03 Jun '09

03 Jun '09

AMDG I'm looking at the following tickets: https://svn.boost.org/trac/boost/ticket/351 https://svn.boost.org/trac/boost/ticket/2887 https://svn.boost.org/trac/boost/ticket/2424 #351 and #2887 are effectively the same boost::mt19937 prng1; boost::mt19937 prng2(prng1); // does not call copy constructor #2424 is int seed = 0; boost::mt19937 prng1(seed); // doesn't compile #2424 can be fixed easily without breaking backwards compatibility. Fixing #351 and #2887 will silently change the meaning of the constructor call above. It will also be difficult to emulate the previous (documented) behavior. However, looking at the current standard draft, the constructor that causes these problems is not present, so the standard mersenne twister will have a well behaved copy constructor. Also, only lagged_fibonacci_01, mersenne_twister, and subtract_with_carry provide the offending constructor, so Boost.Random is not consistent. I'd like to have the copy constructor called. What do others think? When testing fixes, I found that rand48 behaves differently with an int64_t seed than with an int32_t seed. According to the current draft standard, they should be equivalent. Should rand48 be changed or should I leave it alone? In Christ, Steven Watanabe

2 2

[iostreams] #2406: implementation in header causes link errors
by Vladimir Prus 03 Jun '09

03 Jun '09

Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch: https://svn.boost.org/trac/boost/changeset/53427 I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something. Thanks, Volodya

2 1

[parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I have a few questions about the parameter library. Please note that I am using argument packs directly, since I am creating them from another data structure. 1. Is there a way to build Boost.Parameter ArgumentPacks from a program? I am currently using many internal data structures of Boost.Parameter (empty_arg_list and such). Is there another interface to use? 2. Is there a way to tell at compile-time whether a particular parameter exists in an ArgumentPack? I currently have a metafunction that uses a special default type and tests for that; is there a more "official" way? 3. I have a case where the default type for a named parameter cannot be instantiated in some cases where that parameter is given explicitly. The operator||() lazy defaults don't seem to work for that because they get the result_type member from my default right away, even if it won't be used. I currently have a hack to work around this using my parameter_exists test and some metaprogramming. The reason I am working on this low of a level is that I am playing with converting Boost.Graph named parameter structures into ArgumentPacks to have access to Boost.Parameter's nicer capabilities and syntax. I thus need to build all of the argument data structures and such within another function and then access them later. Thank you for your help. -- Jeremiah Willcock

2 5

[Modularization] A new approach to header modularization
by Beman Dawes 03 Jun '09

03 Jun '09

I've started to put together a wiki page based on our ongoing Header Modularization discussions. See http://svn.boost.org/trac/boost/wiki/HeaderModularization I listed eight approaches to meeting the Goals/Objectives/Needs/Wants, and was about to identify the weaknesses of each approach when I hit on approach nine: Move (permanently) each library's root/libs/libname contents into root/boost/libname for the library. In other words, instead of moving the boost/... tree headers to the libs/... tree, merge the libs/... tree into the boost/... tree. For example, Boost.Filesystem is currently organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp libs/ filesystem/ build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... After the reorganization, filesystem would be organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... In theory, the root/libs/... tree isn't needed anymore. In practice we might want to keep a root/libs/libname/index.html entry for each library so docs links don't break. Apologies if someone already suggested this approach. It is so simple I can't believe someone didn't already suggest it. Unless I'm missing something, this is the only approach that appears to do fairly well for all of the Goals/Objectives/Needs/Wants, and very well for most of them. It would require some rework of scripts and other setups that depend on the current organization of libs/..., but that seems minor compared to the long-term benefits. Comments? --Beman

18 50

Attachments from old bug tracker
by Jeremiah Willcock 03 Jun '09

03 Jun '09

It appears that somebody attached patches to the equivalent of bug 900 (https://svn.boost.org/trac/boost/ticket/900) in the old bug tracker, and these patches were not moved over to the new tracker. Is it possible to get these attachments? -- Jeremiah Willcock

2 1

Re: [boost] boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

> > does anyone know where can I get the videos of the presentations at >> boostcon? >> > > When they are available (i.e, when I finish working on them), I will post > here > detailing where they are. > > Note: Not all the presentations were videotaped. > Thanks! Just curious, was the presentation by Andrei(Iterators must go) was videotaped? and any chance to grab the videotapes(and the ppts) for earlier boostcons?

2 1

boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

does anyone know where can I get the videos of the presentations at boostcon?

2 1

[Bug Sprint] What to do with "library submissions"?
by Marshall Clow 03 Jun '09

03 Jun '09

I'm not sure they belong in the Trac system; but where do they belong? I guess it depends on what's going to happen to them.... If they're additions to existing libraries, should they be "feature requests"? If they're new libraries, should they go in the sandbox? https://svn.boost.org/trac/boost/ticket/2749 https://svn.boost.org/trac/boost/ticket/2893 -- -- 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.

2 1