Michael Caisse | 1 Jan 01:12 2011

Re: [wiki] Warning Guidelines for VC

On 12/31/2010 07:40 AM, Paul A. Bristow wrote:
> Well it's really good to get news from the 'horse's mouth'  - even if the
> news is bad!
>
> So it would seem that there is no reliable way to determine if any code
> (including STL) is C++ Standard Conforming,
> apart from trying to compile it on a non-Microsoft Standard Conforming
> Compiler in strict mode?
>    

We might have different philosophies, but I would not have trusted any 
single compiler for that information. And while we all try our best for 
standard conforming code, in the end it is various compiler conforming 
code that must be written.

> So while many, if not most, Boost Users will deplore this on principle,
> I fear we must be pragmatic and accept this, however unhappily.
>
> Fortunately, our extensive testing schedule using all the many compilers
> (using their 'strict' mode where possible) will reveal un-portability before
> any final Boost release 'hits the streets'.
>    

I often think of the Boost community as people who need to target 
multiple compilers/platforms. That might be wrong or too narrow. As far 
as Boost libraries are concerned, I think this is a non-issue. The code 
has to work with various compilers either at their least common 
conforming level or at various compiler specific alternatives. I don't 
see how the flag actually could help unless you were developing only on 
MSVC and then trying to port to other platforms.
(Continue reading)

Shaun Jackman | 1 Jan 01:54 2011
Picon

Re: [BGL] Get properties from an out_edge_iterator efficiently

Hi Jeremiah,

In many cases, an edge_descriptor is a pair<vertex_descriptor,
vertex_descriptor>. If the container of adjacent vertices is an unsorted
vector or list, then it requires searching that list. An
out_edge_iterator on the other hand is likely an iterator pointing
directly to the edge in question. Yes, an edge_descriptor could contain
an edge_iterator, but that increases the size and complexity of an
edge_descriptor unnecessarily.

Cheers,
Shaun

On Thu, 2010-12-16 at 22:11 -0800, Jeremiah Willcock wrote:
> On Thu, 16 Dec 2010, Shaun Jackman wrote:
> 
> > Hi,
> >
> > I have a graph implementation where
> >        get(tag, graph, out_edge_iterator)
> > is much more efficient than
> >        get(tag, graph, edge_descriptor)
> > which is probably not an usual case.
> >
> > Would it make sense for BGL to provide a default implementation of the
> > former that dereferences the iterator and calls the latter? Graphs for
> > which the former is more efficient could then specialize this function
> > template.
> 
> I don't see many use cases where an iterator would be that much faster to 
(Continue reading)

Dean Michael Berris | 1 Jan 10:20 2011
Picon

Re: Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Prelude: The world needs ubiquitous Internet service on the cheap,
because there are parts of the world where the Internet isn't as
accessible. Or... I should really stop engaging in discussions around
holiday times so that I don't miss out on the conversation. ;) That
said, please see in-lined below.

On Wed, Dec 29, 2010 at 2:41 PM, Edward Diener <eldiener <at> tropicsoft.com> wrote:
> On 12/28/2010 9:56 PM, Dean Michael Berris wrote:
>>
>>
>> Actually, I'd +2 if you said a review should be open until the library
>> gets into the main distribution. And even after that, reviewing the
>> quality of the library should be on-going and shouldn't stop at the
>> point of inclusion into Boost. ;)
>
> If a review, as it sometimes happens, determines that a library does not
> qualify for Boost but if some things were improved it might, I would agree
> with you that a review could be ongoing if the developer of the library is
> committed to maklng changes that would improve it. But I do not see the
> advantage of keeping reviews open until the library is accepted, especially
> with libraries deemed not of a high enough quality for Boost. OTOH nothing
> keeps a developer from making changes in his library and re-submitting it
> for inclusion into Boost again.
>

Well, there's the rub.

Take what I said in the context of collaborative development instead
of the current way of getting libraries into Boost. My issue with the
status quo is that the barrier to entry for a library (and thus a
(Continue reading)

Dean Michael Berris | 1 Jan 10:23 2011
Picon

Re: Respecting a projects toolchain decisions

On Tue, Dec 28, 2010 at 10:23 PM, Nelson, Erik - 2
<erik.l.nelson <at> bankofamerica.com> wrote:
> Dean Michael Berris wrote on Tuesday, December 28, 2010 7:05 AM
>> I'm not talking about having 4 different sites for one library -- I'm
>> saying, for each Boost library there should be one issue tracker. This
>> means if you need to check anything regarding that library, then you
>> go to exactly one place.
>>
>
> It sounds to me like Vladimir goes to exactly one place right now.
>

Well, if you look at it the same way I do, in Github I only ever go to
one place too. I can follow the repositories/projects I'm interested
in, and find the appropriate issues that I care about accordingly too.

--

-- 
Dean Michael Berris
about.me/deanberris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Dean Michael Berris | 1 Jan 10:27 2011
Picon

Re: Respecting a projects toolchain decisions

On Tue, Dec 28, 2010 at 11:51 PM, Rene Rivera <grafikrobot <at> gmail.com> wrote:
> On 12/28/2010 6:00 AM, Dean Michael Berris wrote:
>>
>> On Tue, Dec 28, 2010 at 5:33 PM, John Maddock<boost.regex <at> virgin.net>
>>  wrote:
>>>> 3. I'm not sure how the "single point of failure" comes into play, but
>>>> centralized anything means that one thing goes down, then everything
>>>> fails. I don't think I need to stress that point any more than I have
>>>> to. ;)
>>>
>>> OK you win on that one ;-)
>>>
>>
>> ;-)
>
> Well... Centralized doesn't need to mean single point of failure. And
> there's plenty of industry practice in making centralized and fault-tolerant
> services.
>

Sure, none of which we follow at Boost at the moment IIUC. ;-)

I mean, really, when the server hosting the website, the subversion
repo, and Trac go down, where do we go? Is there some magical standby
machine that's going to kick in as some hot backup which mirrors the
whole Boost repo, Trac, and website?

--

-- 
Dean Michael Berris
about.me/deanberris
(Continue reading)

Dean Michael Berris | 1 Jan 10:33 2011
Picon

Re: Respecting a projects toolchain decisions

On Wed, Dec 29, 2010 at 10:08 AM, Dave Abrahams <dave <at> boostpro.com> wrote:
> At Tue, 28 Dec 2010 19:25:52 +0800,
> Dean Michael Berris wrote:
>>
>> Sure, but the whole point that you have a central place to query the
>> information is what's broken -- especially if you have to resort to
>> these "hacks" just to filter out what's important for you.
>>
>> Imagine if you had one issue tracker per Boost library. Then you don't
>> have to worry about crafting the queries to get the relevant
>> information in the first place.
>
> I disagree with you on this one.  Even if I had every project in a
> separate tracker, I would still want something to aggregate the issues
> so I could prioritize and look in one place for all the things that
> are relevant to me... see Redmine, for example.
>

Right, I guess I never really had that issue as I generally want to be
in a certain "mode" when I'm looking through issues.

GitHub makes that really simple since I only get notifications on
issues I'm involved in -- ones where I either commented or posted
myself -- and then I can go look at the issues relevant to the library
I'm working on from that library's issue tracker.

I think this is also the reason why I don't like the Trac approach
where all the issues just get piled up in the same container and you
have to filter it out actively.

(Continue reading)

Dean Michael Berris | 1 Jan 10:39 2011
Picon

Re: Respecting a projects toolchain decisions

Klaim, please don't top post. See
http://www.boost.org/community/policy.html#quoting

That said, please see my response in-lined below:

On Wed, Dec 29, 2010 at 7:49 PM, Klaim <mjklaim <at> gmail.com> wrote:
> I know about the 7 years existence of the ticket, but if you follow closely
> the (very) recent evolution of TRAC, or simply look at the features of the
> (late) coming version :
> http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.13
> <http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.13>The discussion
> about how it will be achieved is there :
> http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject
> The related tasks planned are there :
> http://trac.edgewall.org/wiki/MultipleProjectSupport
> You see that it's planned (at least). It was not planned before as you
> pointed it correctly.
>

Sorry, but I myself loved Trac when it came out as it looked better
than Bugzilla. I was stuck in a place where Bugzilla was sacred and
the thought of moving to something better didn't even get discussed as
it was one of those "taboo" issues. Anyway, I'm glad they stuck with
Bugzilla because even Bugzilla seems to be evolving much faster/better
than Trac.

The project doesn't inspire confidence if there isn't an active
community of users and developers dedicated to improving the product.
Even if Trac 0.13 does deliver on its promises and does do things in a
better way, then it would take time for me to even consider using it
(Continue reading)

Dean Michael Berris | 1 Jan 10:41 2011
Picon

Re: Respecting a projects toolchain decisions

On Thu, Dec 30, 2010 at 2:09 PM, Steven Watanabe <watanabesj <at> gmail.com> wrote:
> AMDG
>
> On 12/28/2010 3:34 AM, Vladimir Prus wrote:
>>
>> I'd be very much against the idea of checking 4 different sites as
>> opposed to 1 -- at least, until I have 4 pairs of hand to work on
>> 4 different projects at the same time. In fact, I so much dislike
>> having to check N different issue trackers that I have a student working
>> on a tool to present issues from different trackers in a single UI.
>> However,
>> until that project is done, I'd much rather not having things split up
>> unnecessary.
>
> I very strongly agree.  I periodically go through every open
> ticket in trac.  Having separate issue trackers would make this
> practically impossible.
>

Interesting point. Definitely well taken.

I just wonder though how that practice of "periodically going through
every open ticket in Trac" scales. Is it just me who doesn't do this
and who would rather focus on libraries that actually mean more to me?

--

-- 
Dean Michael Berris
about.me/deanberris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Dean Michael Berris | 1 Jan 10:42 2011
Picon

Re: [fiber] new version

On Tue, Dec 28, 2010 at 2:37 PM, Oliver Kowalke <k-oli <at> gmx.de> wrote:
> Am 28.12.2010 05:47, schrieb Dean Michael Berris:
>>
>> Oliver, do you have Boost.Fiber in Github or Gitorious where I (and
>> maybe others) can watch your progress as you develop it in Git?
>
> http://gitorious.org/~k-oli/boost-dev/k-olis-boost
>

+1 for Awesomeness! :D

--

-- 
Dean Michael Berris
about.me/deanberris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Edward Diener | 1 Jan 14:50 2011

Re: Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

On 1/1/2011 4:20 AM, Dean Michael Berris wrote:
> Prelude: The world needs ubiquitous Internet service on the cheap,
> because there are parts of the world where the Internet isn't as
> accessible. Or... I should really stop engaging in discussions around
> holiday times so that I don't miss out on the conversation. ;) That
> said, please see in-lined below.
>
> On Wed, Dec 29, 2010 at 2:41 PM, Edward Diener<eldiener <at> tropicsoft.com>  wrote:
>> On 12/28/2010 9:56 PM, Dean Michael Berris wrote:
>>>
>>>
>>> Actually, I'd +2 if you said a review should be open until the library
>>> gets into the main distribution. And even after that, reviewing the
>>> quality of the library should be on-going and shouldn't stop at the
>>> point of inclusion into Boost. ;)
>>
>> If a review, as it sometimes happens, determines that a library does not
>> qualify for Boost but if some things were improved it might, I would agree
>> with you that a review could be ongoing if the developer of the library is
>> committed to maklng changes that would improve it. But I do not see the
>> advantage of keeping reviews open until the library is accepted, especially
>> with libraries deemed not of a high enough quality for Boost. OTOH nothing
>> keeps a developer from making changes in his library and re-submitting it
>> for inclusion into Boost again.
>>
>
> Well, there's the rub.
>
> Take what I said in the context of collaborative development instead
> of the current way of getting libraries into Boost. My issue with the
(Continue reading)


Gmane