- Boost - lists.boost.org

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

Bug Sprint Report for Friday, May 29th
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added three new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> The following bugs appear to have been fixed, but the tickets were never closed. I would appreciate it if the library maintainers could verify this and close the tickets. https://svn.boost.org/trac/boost/ticket/145 Iterator https://svn.boost.org/trac/boost/ticket/287 date_time The following tickets are feature requests that are unlikely ever to be implemented. Should they be closed? https://svn.boost.org/trac/boost/ticket/558 database https://svn.boost.org/trac/boost/ticket/100 concept_check https://svn.boost.org/trac/boost/ticket/182 concept_check --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- 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.

3 3

[#1497] Ruling needed on tracker usage
by Beman Dawes 03 Jun '09

03 Jun '09

Dave is pressing to do something about this ticket: > Yes, please! Beman, please read the head of that thread: > http://thread.gmane.org/gmane.comp.lib.boost.devel/167139 > > IMO this is '''exceedingly''' important, and the only reason I'm not doing > it myself is that it seems to be the domain of the release managers. It > will be an especially huge missed opportunity if we don't get this > straightened out before the bug sprint. Oops! That starts today! We'd > better get moving. > > Again, if there's any way I can help, including writing the policy, please > let me know. By the way, I'm not attached to eliminating "to be > determined," if that helps in any way to resolve this. The concern of the thread mentioned was about milestones for 1.35.0. The same concern applies today, although the milestone numbers have changed. > [the milestone list] > shows all the tickets that have been assigned to the 1.35.0 milestone. > Does this list have any meaning? It doesn't for me, and hasn't since we went to a schedule-driven release system a year and a half ago. > In other words, are we actually > intending to address all of these problems for 1.35, and put off other > tickets for 1.35.1 or 1.36.0? > > IMO getting this list sorted out and handling the tickets one-by-one > is the most productive way to get us from here to a successful release > of 1.35.0. That may mean a number of new tickets need to be added > (probably at least one for each major failure we're seeing in > http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.h… > and possibly others) and it will require part of the release team to > triage the whole list of tickets assigned to 1.35.0 and make some > decisions to put certain tickets off for later. In an organization with paid developers and paid managers, it might be possible to look at the tickets, look at the people and other resources available, assign milestone priorities accordingly, and then use progress on clearing them as a metric to guide release activities. But I'm at a loss for how we could use such milestones for Boost. So any ideas would be appreciated if folks think the milestones do have a place in Boost's process of getting releases out. --Beman

3 2

[profile_templates] minor issue + patch
by Jonathan Franklin 03 Jun '09

03 Jun '09

Steven, I was playing around w/ the profile_templates tool on my Ubuntu box (Jaunty Jackelope - 9.04), and wasn't getting any results. After a little investigation, I discovered that the regex that postprocess.cpp uses for the enter_message wasn't matching the warning that my gcc compiler (4.3.3) was spitting out. Turns out that the regex is looking for a single char here: (.*): warning: .int -----------------^ But I'm getting a unicode E28098 (left single quotation mark), which is 3 chars, hence the failure to match. Being somewhat content w/ my terminal settings (and lazy to boot), I just modified the regex to match .+int instead of .int, and it *seems* to work fine. I think I have a sandbox account, and can commit the attached patch if you like the fix. Jon

2 2

Bug Sprint Report for Tuesday, June 2nd
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We slowed down a lot on Tuesday - let's pick it up again. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- 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.

1 0

Unicode: what kind of binary compatibility do we want?
by Mathias Gaunard 03 Jun '09

03 Jun '09

As I am finishing putting property look-up together for the Unicode library GSoC, I am wondering what kind of binary compatibility it should aim for. The work from Graham Barnett back in 2005 defined an abstract base class with virtual functions for every unicode-related feature but I believe that's overkill. Basically, the current property design I have is like this struct some_property { enum type { some_default, some_value1, some_value2, ... _count; } }; some_property::type get_some_property(char32 ch); With get_some_property a simple look-up in the table, but the table layout being version dependent it would need to be in the library TUs. However, a new version of the library may return a value that is not within the enum. Should it then work like this? some_property::type get_some_property(char32 ch) { some_property::type p = get_some_property_impl(ch); if(p >= some_property::_count) return some_property::some_default; return p; } some_property::type get_some_property_impl(char32 ch); Is that suitable? Or do we want more/less flexibility? Apart from that, expect a documentation update by the end of the week.

5 7

[parameter] Bug 3114
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I submitted bug 3114 (https://svn.boost.org/trac/boost/ticket/3114) with a preliminary patch to implement my feature request several days ago, and have not yet received a response. I believe that this feature would make Boost.Parameter much more useful for certain use cases, especially in libraries such as Boost.Graph where the defaults for named parameters may use templates that cannot be instantiated or do not include required members in some cases when users specify explicit arguments to a function. I made sure not to change the interface for existing default handlers by requiring a special tag to enable the new interface on a handler-by-handler basis. Could I please have the patch examined, generalized to more platforms, and possibly applied? Thank you. -- Jeremiah Willcock

2 1