headers
Eric Niebler | 1 Dec 2010 04:25
Picon
Favicon
Gravatar

Re: Is merging to the release branch allowed again?

On 11/30/2010 2:23 PM, Beman Dawes wrote:
> On Tue, Nov 30, 2010 at 9:58 AM, Marshall Clow <mclow.lists <at> gmail.com>wrote:
> 
>> On Nov 30, 2010, at 6:44 AM, Hartmut Kaiser wrote:
>>
>>> Since I hate holding back merging to the release branch to the last
>>> minute
>>> before the next release I would like to start doing this asap. Any idea
>>> when
>>> this might be allowed again?
>>
>> It is my belief that once the release is made, the release branch is open
>> for changes again.
>> In fact, I merged files to the release branch last night.
>>
>> If this is incorrect, then I'm sure one of the release managers will step
>> up and slap me silly^H^H^H^ gently correct me.
> 
> Yep, OK to merge to release.

I guess you've now (indirectly) answered in the negative my question
about a point release to address the type_traits vc-7.1 regression.
That's too bad.

--

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bjørn Roald | 1 Dec 2010 05:27

Re: Library for configuration file parsing

On 11/30/2010 09:20 AM, Denis Shevchenko wrote:
> On 29.11.2010 23:58, Bjørn Roald wrote:
>> However we do have existing libraries in this domain, even if the 
>> features vary.
> Hello again, Bjørn!
>
> I venture to suggest to consider my library in Boost Vault. You are 
> right, there are exists libraries of the same domain. But I see that 
> in Boost, for example, exists TWO libraries for work with regular 
> expressions, Regex and Xpressive. And this is good (imho), because 
> user can choose between libraries (for example, between header-only 
> and linking variants). Program_options is auto linking, my library is 
> header-only. :-)

There is nothing preventing acceptance other than acceptance in a 
review.  So I wish you good luck  :-)  All I am expressing is that I 
would like to see effort in the same domain consolidated if that work 
out for the authors.  I also think you would have a better chance 
getting your features into boost that way, but that is only my opinion.

As for Regex and Xpressive, you are right.  This is one example of boost 
libraries covering the same domain. However they AFAIK have different 
implementation approaches.  Also their API vary in non trivial ways.  
Expressive support a completely different approach to instantiate 
regular expressions at compile-time rather than run-time. Regex is tied 
to a proposal for the C++ standard library.  So I think that there is a 
certain amount of rationale for making and keeping separate solutions.

--

-- 
Bjørn
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrik Sundberg | 1 Dec 2010 06:25
Picon

Re: Is merging to the release branch allowed again?

On Wed, Dec 1, 2010 at 4:25 AM, Eric Niebler <eric <at> boostpro.com> wrote:
> On 11/30/2010 2:23 PM, Beman Dawes wrote:
>> Yep, OK to merge to release.
>
> I guess you've now (indirectly) answered in the negative my question
> about a point release to address the type_traits vc-7.1 regression.
> That's too bad.

Shouldn't point releases be originating from the actual release anyway?

/$
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Leonid Frenkel | 1 Dec 2010 08:58
Picon

Conversion operator for boost any

Hello,

I found adding the following conversion operator to Boost.Any was very
helpful in some cases: (specially when using macros inside functions)

template <typename ValueType>
operator ValueType()
{
return any_cast<ValueType>(*this);
}
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Paul A. Bristow | 1 Dec 2010 10:16

Re: [mpl-cf] [RFC] MPL Real Numbers using Continued Fractions

> -----Original Message-----
> From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
> On Behalf Of Hal Finkel
> Sent: Tuesday, November 30, 2010 7:12 PM
> To: boost <at> lists.boost.org
> Subject: Re: [boost] [mpl-cf] [RFC] MPL Real Numbers using Continued
Fractions

> That was also my original assumption, but I found it worked pretty well in
> practice. For one thing, I've chosen a convention such that all of the
(non-zero)
> integers have the same sign, This means that there is no "catastrophic
> cancellation," and also makes implementing the comparison ops relatively
> simple (comparison is cheap compared to arithmetic).
> 
> To be fair, my original use case was the generation of ratios of pi for
use in FFT
> kernels, and as you've noted above, all of the integers in the pi
expansion are
> fairly small (and there are a lot of 1s), so maybe it is not entirely
representative,
> but I've yet to encounter a case where this has caused a problem. That
having
> been said, I've not really tried to find such a case either. I can
certainly think
> about this more carefully.

I'm not sure what the OP really wanted to calculate, 
(if he really needed MPL calculation or MPL was just convenient)
but I thought I would just add that if the need is something as simple as
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel James | 1 Dec 2010 10:32
Picon

Re: Is merging to the release branch allowed again?

On 1 December 2010 05:25, Henrik Sundberg <storangen <at> gmail.com> wrote:
> On Wed, Dec 1, 2010 at 4:25 AM, Eric Niebler <eric <at> boostpro.com> wrote:
>> On 11/30/2010 2:23 PM, Beman Dawes wrote:
>>> Yep, OK to merge to release.
>>
>> I guess you've now (indirectly) answered in the negative my question
>> about a point release to address the type_traits vc-7.1 regression.
>> That's too bad.
>
> Shouldn't point releases be originating from the actual release anyway?

Our regression testing system currently only supports two fixed
branches (trunk and release), so to test a point release we need to
keep the release branch dedicated to it.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Dean Michael Berris | 1 Dec 2010 12:32
Picon
Gravatar

Re: [trac] Website performance, and disabling the code browser?

On Wed, Dec 1, 2010 at 1:26 AM, Rene Rivera <grafikrobot <at> gmail.com> wrote:
> On 11/28/2010 9:29 PM, Dean Michael Berris wrote:
>>
>> This is % of what, time since, ever? Or time since a given start date?
>> Do we have ideas as to the daily traffic the trac site gets?
>
> It's % of total time (cumulative). So "/trac" is taking up %67 of the total
> time people waited for the page to get served overall and so on down the
> tree.
>

Alright, that makes sense since /trac is the default page -- does this
mean ticket pages get counted under /trac as well? Or individual
tickets have different entries (I'm assuming this is broken down by
full URI)?

> The time is for the week ending on the 21st. I haven't done the report for
> this past week as it's likely not going to be different and it takes some
> time to process the 300M of data for it.
>
> The perf stats we keep don't include time stamps, just time spent, so I
> can't do daily analysis.
>

Alright. The Google Analytics makes sense for getting this kind of
data though, is as close to real time as possible and is free.

>> Also it looks like the browser is up at the top 3 most visited. Either
>> we disable that or enable caching the pages if that's even possible,
>> maybe look at putting varnish [0] in front of the Apache server. This
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Clow | 1 Dec 2010 14:47
Picon

[Bug Sprint] Status for Wednesday, December 1st

There were 30 changes to the trac database yesterday.
[ I'd like to say "30 tickets were changed", but some tickets were changed more than once. ]

That's a notable decrease in activity from the last few days.

In the last bug sprint, we closed almost 100 tickets.      So far this time, we've closed 17.
If you think it's too late to get involved - you're wrong!

A couple of notes:
1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up.
2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4,
etc) and it worked fine/didn't work/etc"

General information about the bug sprint is here:				https://svn.boost.org/trac/boost/wiki/BugSprintNov2010
General information about how the Trac system works is here:		https://svn.boost.org/trac/boost/wiki/TicketWorkflow

Overall bug count:
November 26:		946
November 27:		939
November 28:		930
November 29:		934		(whoops, that's the wrong direction!)
November 30:		931		(better, but the delta is too small)
December   1:		929

Activities on the trac system yesterday:
	avibahra <at> 	 3
	marshall		 3
	hkaiser		 3
	jwellico		 3
	--others--	18
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Clow | 1 Dec 2010 14:49
Picon

Re: Is merging to the release branch allowed again?

On Nov 30, 2010, at 7:25 PM, Eric Niebler wrote:

> On 11/30/2010 2:23 PM, Beman Dawes wrote:
>> On Tue, Nov 30, 2010 at 9:58 AM, Marshall Clow <mclow.lists <at> gmail.com>wrote:
>> 
>>> On Nov 30, 2010, at 6:44 AM, Hartmut Kaiser wrote:
>>> 
>>>> Since I hate holding back merging to the release branch to the last
>>>> minute
>>>> before the next release I would like to start doing this asap. Any idea
>>>> when
>>>> this might be allowed again?
>>> 
>>> It is my belief that once the release is made, the release branch is open
>>> for changes again.
>>> In fact, I merged files to the release branch last night.
>>> 
>>> If this is incorrect, then I'm sure one of the release managers will step
>>> up and slap me silly^H^H^H^ gently correct me.
>> 
>> Yep, OK to merge to release.
> 
> I guess you've now (indirectly) answered in the negative my question
> about a point release to address the type_traits vc-7.1 regression.
> That's too bad.

Sorry about that, Eric.

-- Marshall
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finkel | 1 Dec 2010 15:25

Re: [mpl-cf] [RFC] MPL Real Numbers using Continued Fractions

On Wed, 2010-12-01 at 09:16 +0000, Paul A. Bristow wrote:
> > -----Original Message-----
> > From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
> > On Behalf Of Hal Finkel
> > Sent: Tuesday, November 30, 2010 7:12 PM
> > To: boost <at> lists.boost.org
> > Subject: Re: [boost] [mpl-cf] [RFC] MPL Real Numbers using Continued
> Fractions
>  
> > That was also my original assumption, but I found it worked pretty well in
> > practice. For one thing, I've chosen a convention such that all of the
> (non-zero)
> > integers have the same sign, This means that there is no "catastrophic
> > cancellation," and also makes implementing the comparison ops relatively
> > simple (comparison is cheap compared to arithmetic).
> > 
> > To be fair, my original use case was the generation of ratios of pi for
> use in FFT
> > kernels, and as you've noted above, all of the integers in the pi
> expansion are
> > fairly small (and there are a lot of 1s), so maybe it is not entirely
> representative,
> > but I've yet to encounter a case where this has caused a problem. That
> having
> > been said, I've not really tried to find such a case either. I can
> certainly think
> > about this more carefully.
> 
> I'm not sure what the OP really wanted to calculate, 
> (if he really needed MPL calculation or MPL was just convenient)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane