Nabble - Boost - Dev

Re: [Review] GGL review starts today, November 5th

2009-11-10T03:37:50Z

Hi Joachim,

> I am currently reading your docs and I think your design is *very* good.
>
Thanks, good to hear.

> I will take more time to investigate the lib and send a review at the end
> of the review period.
>
>
OK, perfect, looking forward to it.

Regards, Barend

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T02:41:26Z

On Tue, Nov 10, 2009 at 9:48 AM, John Maddock <john@...> wrote:
>
> Not yet, but it hits my stuff as well, so sometime I want to see it fixed.
> BTW I believe there are quite a few changes to Boost.Integer in Trunk that
> have never been merged to release as well, which adds extra complications
> :-(

They mainly look like new developments, and the test results aren't
great so IMO we should probably just move them onto a branch and copy
the files from the release branch. They can be merged back later if
someone wants to deal with them.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] GGL review starts today, November 5th

2009-11-10T02:36:22Z

2009/11/5 Hartmut Kaiser <hartmut.kaiser@...>:
>
> Hi all,
>
> The formal review of the Generic Geometry Library (GGL) starts today,
> November 5, 2009 and will finish November 15, 2009.

Hi Barend,

I am currently reading your docs and I think your design is *very* good.
I will take more time to investigate the lib and send a review at the end
of the review period.

Thanks to you, Bruno and Mateusz for this contribution.
Joachim
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[msm] Version 2.0 available

2009-11-10T02:27:08Z

Dear Boosters,

I'm happy to announce the review-ready new version of Msm (2.0).
Msm is a framework which enables you to build a Finite State Machine
in a straightforward, descriptive and easy-to-use manner.
The generated code is optimized for speed and will force you to use
neither RTTI nor anything virtual.
Msm supports most of UML state machine features:
- state entry/exit
- transition actions/guards
- composite states
- history
- orthogonal regions
- terminate states
- deferred events
- explicit entry/fork
- entry/exit pseudostates
- anonymous transitions
- transition conflicts
and much more.

Msm v2.0 is a redesign of Msm v1.20 and offers a separation beetween
front- and back-ends. There is currently one backend and several
frontends:
- the same frontend as Msm v1.20
- a variation of this frontend based on functors for actions
- eUML, a boost::proto-based compile-time language allowing you to use
UML notations directly inside your code, thus making writing code from
a state machine diagram easier.

eUML also comes in with a functional programming library similar to
Boost.Phoenix, adapted to state machines.

I'll be happy for any comment.
You can find Msm v2.0 in:
- the vault (http://www.boostpro.com/vault/index.php?directory=Msm)
- the boost sandbox (http://svn.boost.org/svn/boost/sandbox/msm/)

The documentation can be found at libs/msm/doc/index.htm and the code
in the boost/msm subdirectory.

The 1.0 and 1.10 are now retired. To close up the 1.x path, I'll bring
a 1.21 with the latest bugfixes and then retire the 1.20 from the
vault.

Best regards,

Christophe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-10T02:17:48Z

> Would it be possible to get the warning output from the regression tests,
> at least for libs/{graph,property_map,graph_parallel}? I do not believe I
> have easy access to the compilers that are going to be used for warning
> checking.

Hmm, I can run graph and property_map locally, but I don't have MPI
configured/installed - I suspect it would be a lot easier for some with that
already available to run those!

The logs are quite large, so I'll mail them separately.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-10T01:58:48Z

>> While not as easy for you as some yet undiscovered change to
>> noncopyable, can't you just use the MSVC pragma warning dance around
>> your classes to quiet that warning in each case?
>
> I could, and I might but....
>
> To my mind this is an invalid warning. The code in question is not
> incorrect
> and the boost::noncopyable provides the protection against the situation
> that the warning is designed to detect. So from my perspective the
> best would be to add /wd4511 and /wd4512 to the compiler switches.
>
> Of course that's not really a good solution because other code might
> not have the boost non_copyable protection. Ideally the compiler
> would be able detect that the copy/assigment functions can't be
> used in this case any way. Or maybe the compiler needs some sort
> of class attribute.

Nod. I think this is a common issue: the warning is entirely bogus in this
case, but in other contexts users may find it genuinely useful. The
question is whether we can silence the "noise" to a level that allows the
user to turn on a higher level of warnings and get useful output from their
code only. In this case yes, I believe we can.

> in the meantime...
>
> Of course I can conditionaly include pragma for this compiler.
> The problem is that you start have to doing for all compilers
> and they've all got their own set of quirks. This makes the
> code harder to read, understand and maintain. You HAVE
> to do it sometimes to work around bogus compiler errors
> but I'm sort of reluctant to embark upon this to work around
> bogus compiler warnings. This raises the question about how
> to handle the "warning" that such and such a function has been
> "deprecated" when it actually hasn't and of course those
> warnings which are just hints that sometimes have to be
> knowingly violated.
>
> Basically, once you start considering this - it sort of
> takes on a life of its own.

Nod. I don't think anyone is suggesting that all of boost be warning free
with all possible compilers, that just wouldn't be possible IMO. But does
that mean that we shouldn't try to do better with the most popular tools?

Not a rhetorical question, just feeling my way yours.... John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T01:48:39Z

> if, in SVN trunk as of revision 57535, I go to libs/program_options/test
> and run:
>
> bjam warnings=all cxxflags=-Wextra
>
> I get a pile of warnings like this:
>
> ../../../boost/integer.hpp:145:24: warning: use of C99 long long integer
> constant
>
> These are actually only warnings that are now printed. Does anybody know
> what
> to do with them?

Not yet, but it hits my stuff as well, so sometime I want to see it fixed.
BTW I believe there are quite a few changes to Boost.Integer in Trunk that
have never been merged to release as well, which adds extra complications
:-(

Looking at the code in question, it appears the warning is from the
preprocessor phase as the line in question reads:

#if BOOST_HAS_XINT && (BOOST_UXINT_MAX > ULONG_MAX)

So we can't just declare constants-as-variables in one place to fix this as
we need values usable in preprocessor directives. Looks like we'll need
another #pragma GCC system_header, and as suggested elsewhere I'll try and
add a way to turn off those pragmas in Boost.Config.

HTH, John.

PS don't let warnings in dependencies stop you from declaring the library
"clean" on https://svn.boost.org/trac/boost/wiki/WarningFixes, it's
understood that dependencies may cause warnings, but they'll get fixed at
some point if we all work through the list.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T00:50:14Z

Vladimir Prus schrieb:

> Sascha Ochsenknecht wrote:
>
>> I think "long long" is from the C99 standard and the GNU g++ doesn't use
>> this mode by default (?).
>>
>> For me, the warnings disappear if I use add:
>> cxxflags=-std=c++0x
>
> But on the other hand, it was reported that this mode has quite a number
> of failures relative to standard mode. And it's not the default anyway.
> So, I suppose somebody has to patch integer.hpp anyway.
>

I agree.

The option I added wasn't supposed to be the solution. Just a hint.

Cheers,
Sascha
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T00:47:03Z

Sascha Ochsenknecht wrote:

> I think "long long" is from the C99 standard and the GNU g++ doesn't use
> this mode by default (?).
>
> For me, the warnings disappear if I use add:
> cxxflags=-std=c++0x

But on the other hand, it was reported that this mode has quite a number
of failures relative to standard mode. And it's not the default anyway.
So, I suppose somebody has to patch integer.hpp anyway.

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T00:37:40Z

Vladimir Prus wrote:

> Hi,
>
> if, in SVN trunk as of revision 57535, I go to libs/program_options/test
> and run:
>
> bjam warnings=all cxxflags=-Wextra
>
> I get a pile of warnings like this:
>
> ../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant
>
> These are actually only warnings that are now printed. Does anybody know what
> to do with them?
>
>

There was a discussion about these warnings recently.
One possible solution is to place constants like the following in one of
the boost headers.

__extension__ unsigned long long const ullong_max =
~static_cast<unsigned long long>(0);
__extension__ long long const llong_max = ullong_max >> static_cast<long
long>(1);
__extension__ long long const llong_min = -llong_max - static_cast<long
long>(1);

BR, Dmitry
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [integer] long long warning

2009-11-10T00:36:49Z

I think "long long" is from the C99 standard and the GNU g++ doesn't use
this mode by default (?).

For me, the warnings disappear if I use add:
cxxflags=-std=c++0x

Cheers,
Sascha

Vladimir Prus schrieb:

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] GGL review starts today, November 5th

2009-11-10T00:36:26Z

Hi Luke,

First, congratulations with the acceptance of your library.

> This library looks like a very good example of generic interfaces for geometry objects and several well known and useful geometry algorithms.
>
> [questions snipped]

Thanks for your interest and reading our documentation.

You ask a lot and I'll answer a lot, but give me a day or two.

Regards, Barend

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[integer] long long warning

2009-11-09T23:02:38Z

Hi,

if, in SVN trunk as of revision 57535, I go to libs/program_options/test
and run:

bjam warnings=all cxxflags=-Wextra

I get a pile of warnings like this:

../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant

These are actually only warnings that are now printed. Does anybody know what
to do with them?

Thanks,
Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T22:14:11Z

Patrick Horgan wrote:
> But redundant. It's already built into gcc to do this. If you just have
> the pragma and then build with -Wsystem-headers it turns the warnings back
> on. No sense in reinventing the wheel.
> Cheers,
> Patrick

But wouldn't that also cause the standard library and other actual
system headers to generate warnings? It would presumably be difficult
to pick out the Boost warnings from the standard library ones, just as
Boost users currently complain about picking out warnings from their
code amidst Boost warnings.

--Jeffrey Bosboom
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T21:48:28Z

Emil Dotchevski wrote:

... elision by patrick...
This assumes that a policy that requires warnings to be "fixed" is
desirable or that it will lead to a better Boost (note that I'm not
arguing against disabling warnings in Boost headers.)

It's a safe assumption. Having been through this pain a number of times I
know that it leads to consistently better code. I've seen it many times.
In fact yesterday, coincidently, (or not, it was because I was talking to
him about this discussion), I was working through the code of someone I
highly respect as a programmer with decades of experience who's sat on a
couple of different language standard committees, and while getting rid of
warnings in his code, I found some real bugs. Had he been used to running
at a high warning level, those bugs wouldn't have crept into his code. This
didn't surprise me a bit. It always happens. You start building with
higher warning levels on any large body of code and you always find real
bugs. That's the point of it. A couple of them were really obvious, once
the messages pointed me to them, but of course you know how our eyes see
what we expect. A lot of the warnings were annoying and made me do silly
things, like reverse a condition so that I could move a throw up and a
return down. Some of them were technically bugs, like comparisons between
signed and unsigned but in the problem domain we knew that the bug would
never be hit, but still bad code, and sometimes you get data outside the
problem domain--surprise! Eventually I got it down to multiple copies of a
warning out of boost/archive/binary_oarchive.hpp signed vs unsigned
conversion just from including it. Frustrating. In the next day or two
I'll get back into it and figure that out (it's a line in
basic_binary_oarchive::save_override). You might think that a waste of
time, but it's not. The point is that now the code can be built normally
with a higher warning level, and now that I've gotten rid of most of the
noise, except for boost noise, more bugs will be caught before they get out
in the wild.
It's obvious that you don't like it. I know. It's a pain in the ass.
But--there are real and large benefits that will help you and those that
come after with this code for as long as people are building it and building
with it. The potential payoff is huge! Just silencing all the warnings by
disabling them means that you don't get the advantage that building with
higher warning levels brings you. Certainly, if that's all you were going
to do, it would pointless.
If you're sure a complaint is a bug for the compiler that generates the
warning, write a bug against them, but silence it for your users. Make sure
if you do that that you revisit silencing it after the compiler writers fix
their bug.
Patrick
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T19:55:49Z

Stewart, Robert wrote:

Emil Dotchevski wrote:

Would it be a good idea to document a macro
BOOST_NO_GCC_SYSTEM_HEADER, to enable developers to use something
like:

#ifndef BOOST_NO_GCC_SYSTEM_HEADER
#pragma GCC system_header
#endif

The motivation being that a developer could still see warnings by
#defining BOOST_NO_GCC_SYSTEM_HEADER while (by default) hiding
warnings for users of the library?

That seems useful.

But redundant. It's already built into gcc to do this. If you just have
the pragma and then build with -Wsystem-headers it turns the warnings back
on. No sense in reinventing the wheel.
Cheers,
Patrick
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [BGL] Trying to get a correclty working Parallel BFS code

2009-11-09T17:22:03Z

On Wed, Nov 4, 2009 at 3:39 PM, Nick Edmonds <ngedmond@...>wrote:

>
> On Nov 4, 2009, at 6:22 PM, Sandeep Gupta wrote:
>
> On Wed, Nov 4, 2009 at 3:11 PM, Sandeep Gupta <gupta.sandeep@...
>> >wrote:
>>
>>
>>>
>>> On Wed, Nov 4, 2009 at 12:18 PM, Nick Edmonds <ngedmond@...
>>> >wrote:
>>>
>>>
>>>> On Nov 3, 2009, at 10:44 PM, Sandeep Gupta wrote:
>>>>
>>>> On Mon, Nov 2, 2009 at 12:43 PM, Nick Edmonds <ngedmond@...
>>>>
>>>>> wrote:
>>>>>>
>>>>>
>>>>>
>>>>> On Oct 31, 2009, at 1:00 AM, Sandeep Gupta wrote:
>>>>>>
>>>>>> On Fri, Oct 30, 2009 at 6:41 AM, Jeremiah Willcock <
>>>>>> jewillco@...
>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> On Thu, 29 Oct 2009, Sandeep Gupta wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Thu, Oct 29, 2009 at 1:12 PM, Jeremiah Willcock <
>>>>>>>> jewillco@...
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 29 Oct 2009, Sandeep Gupta wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Oct 28, 2009 at 5:49 PM, Sandeep Gupta <
>>>>>>>>>> gupta.sandeep@...
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 27, 2009 at 9:31 PM, Jeremiah Willcock <
>>>>>>>>>>>
>>>>>>>>>>> jewillco@...
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 27 Oct 2009, Sandeep Gupta wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The error snippet regarding predecessor map:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> error: no match for call to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> '(boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::error_property_not_found>)
>>>>>>>>>>>>>>> (const boost::detail::parallel::global_descriptor<unsigned
>>>>>>>>>>>>>>> int>&)'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ../../../boost/property_map/parallel/impl/distributed_property_map.ipp:141:
>>>>>>>>>>>>>>> error: no match for call to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> '(boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::error_property_not_found>)
>>>>>>>>>>>>>>> (const boost::detail::parallel::global_descriptor<unsigned
>>>>>>>>>>>>>>> int>&,
>>>>>>>>>>>>>>> boost::detail::error_property_not_found&, const
>>>>>>>>>>>>>>> boost::detail::error_property_not_found&)'
>>>>>>>>>>>>>>> ../../../boost/graph/parallel/properties.hpp:95: note:
>>>>>>>>>>>>>>> candidates
>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>> T
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T)
>>>>>>>>>>>>>>> const [with T = boost::detail::error_property_not_found]
>>>>>>>>>>>>>>> ../../../boost/graph/parallel/properties.hpp:96: note:
>>>>>>>>>>>>>>> T
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T,
>>>>>>>>>>>>>>> T, T) const [with T =
>>>>>>>>>>>>>>> boost::detail::error_property_not_found]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremiah, Do you think that I should file a bug report for
>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Although I was hoping (and actually needed quite urgently)
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> minor issue and get fixed quickly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You need to pass a predecessor map to the algorithm as one of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> parameters
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (or put it as a part of your graph but making an external
>>>>>>>>>>>>> property
>>>>>>>>>>>>> map
>>>>>>>>>>>>> to
>>>>>>>>>>>>> give
>>>>>>>>>>>>> to the algorithm is easier).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Jeremy,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It took me a while but I finally figure out how to pass the
>>>>>>>>>>>>>
>>>>>>>>>>>>> predecessor
>>>>>>>>>>>>
>>>>>>>>>>>> map. Unfortunately it doesn't have any effect. Also, I might be
>>>>>>>>>>>>
>>>>>>>>>>>> wrong
>>>>>>>>>>>>> but I
>>>>>>>>>>>>> don't see any logical reason why predecessor map should have
>>>>>>>>>>>>> any
>>>>>>>>>>>>> bearing
>>>>>>>>>>>>> on
>>>>>>>>>>>>> the correctness of the depth. I have attached the new code. I
>>>>>>>>>>>>> am
>>>>>>>>>>>>> not
>>>>>>>>>>>>> able
>>>>>>>>>>>>> to print out the predecessor because I am not able to figure
>>>>>>>>>>>>> out
>>>>>>>>>>>>> its
>>>>>>>>>>>>> type.
>>>>>>>>>>>>> Maybe you could help me resolve this.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It would be nice to have this code running. I need to profile
>>>>>>>>>>>>> graph
>>>>>>>>>>>>>
>>>>>>>>>>>>> performance on a new machine by tomorrow. Again, thanks for you
>>>>>>>>>>>>>
>>>>>>>>>>>> patience
>>>>>>>>>>>> and
>>>>>>>>>>>> time. I really appreciate you looking into this.
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Jeremiah,
>>>>>>>>>>>>
>>>>>>>>>>>> Was just wondering if you had time to look into this or any
>>>>>>>>>>>> suggestion
>>>>>>>>>>>>
>>>>>>>>>>>> on
>>>>>>>>>>>>
>>>>>>>>>>>> how further proceed. I can get you the output of predecessor
>>>>>>>>>>> map if
>>>>>>>>>>> that
>>>>>>>>>>> would help.
>>>>>>>>>>> Just that I haven't be been able to figure out what the is type
>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>> property map returned by make_distributed_property_map.
>>>>>>>>>>> Please let me know your thoughts.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The person who really knows this library is not around as far as
>>>>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>>> know;
>>>>>>>>>> he
>>>>>>>>>> might be on vacation. The type returned from
>>>>>>>>>> make_distributed_property_map
>>>>>>>>>> is documented on <URL:
>>>>>>>>>> http://www.osl.iu.edu/research/pbgl/documentation/graph/
>>>>>>>>>> distributed_property_map.html>. One thing that you could do to
>>>>>>>>>> debug
>>>>>>>>>> things is to put in your own color map and look at what values it
>>>>>>>>>> ends
>>>>>>>>>> up
>>>>>>>>>> with at the end of the algorithm, and possibly even to put in a
>>>>>>>>>> local
>>>>>>>>>> color
>>>>>>>>>> map that prints out when elements are changed. That might be a
>>>>>>>>>> lot
>>>>>>>>>> of
>>>>>>>>>> work
>>>>>>>>>> for what could end up being an obvious problem (that I just don't
>>>>>>>>>> know
>>>>>>>>>> how
>>>>>>>>>> to diagnose), though. BTW, does the example in
>>>>>>>>>> libs/graph_parallel/example/breadth_first_search.cpp work for you?
>>>>>>>>>> It
>>>>>>>>>> appears to be doing the same thing you want to do. If that works,
>>>>>>>>>> it
>>>>>>>>>> could
>>>>>>>>>> be a problem in your visitor.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I derived this code from
>>>>>>>>>> graph_parallel/example/breadth_first_search.cpp.
>>>>>>>>>>
>>>>>>>>>> The problem is that I don't understand the input and the output of
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>> example code. It would be great if I could get an explanation for
>>>>>>>>> the
>>>>>>>>> format of the input file. Then I can transform my graph into that
>>>>>>>>> format
>>>>>>>>> and pass to the algorithm. That would be enough for my current
>>>>>>>>> purpose.
>>>>>>>>>
>>>>>>>>> As time permits I would try out your suggestions and let know of
>>>>>>>>> update.
>>>>>>>>> In
>>>>>>>>> the meantime I am hoping that I would get input from other relevant
>>>>>>>>> authors.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is what I could tell from the code.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Input:
>>>>>>>> http://people.sc.fsu.edu/~burkardt/data/metis_graph/<http://people.sc.fsu.edu/%7Eburkardt/data/metis_graph/>
>>>>>>>> <http://people.sc.fsu.edu/%7Eburkardt/data/metis_graph/>
>>>>>>>> <http://people.sc.fsu.edu/%7Eburkardt/data/metis_graph/>
>>>>>>>>
>>>>>>>> metis_graph.html<
>>>>>>>>
>>>>>>>> http://people.sc.fsu.edu/%7Eburkardt/data/metis_graph/metis_graph.html
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Output:
>>>>>>>> http://www.graphviz.org/doc/info/lang.html
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks Jeremiah. The link was helpful. I understood the input graph
>>>>>>>> format.
>>>>>>>> Its for undirected graph only. However the BFS output is still
>>>>>>>> coming
>>>>>>>> out
>>>>>>>> to
>>>>>>>> be incorrect. I tried with a sample line graph of 4 nodes and it
>>>>>>>> exhibits the same problem as before.
>>>>>>>>
>>>>>>>> The distances of nodes on process 2 is not getting updated. On the
>>>>>>>> other
>>>>>>>>
>>>>>>>> hand dijkstra shortest paths example is working correctly.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Sandeep
>>>>>>>
>>>>>>>
>>>>>>> I rewrote most of your code before I realized that you're outputting
>>>>>> all
>>>>>> your distances on process 0, even for vertices process 0 doesn't own.
>>>>>> The
>>>>>> large value you see is std::numeric_limits<distance_type>::max. When
>>>>>> you
>>>>>> call get(distance, vertex(i, g)) for some i not owned by the current
>>>>>> process
>>>>>> a ghost cell is created for the requested value and a request sent to
>>>>>> the
>>>>>> owner of that vertex for the correct value. get() then returns
>>>>>> whatever
>>>>>> the
>>>>>> default value is for the distance property map, which in this case is
>>>>>> infinity (i.e. std::numeric_limits<distance_type>::max.
>>>>>>
>>>>>> In some cases you may get the correct distance value because process 0
>>>>>> has
>>>>>> previously requested that value (and it may or may not be up to date).
>>>>>> If
>>>>>> process 0 has never requested that distance value and it doesn't own
>>>>>> the
>>>>>> vertex, then you'll get infinity.
>>>>>>
>>>>>> You need to gather all your data before you output it from a single
>>>>>> node
>>>>>> (i.e. issue a get() or request() which is a get with no return value,
>>>>>> for
>>>>>> each data element). If you want your code to be scalable you should
>>>>>> output
>>>>>> your data in a distributed fashion from all nodes at once. Remember
>>>>>> that
>>>>>> updated values won't be guaranteed to arrive until the next
>>>>>> synchronization
>>>>>> step.
>>>>>>
>>>>>> If you want the modified version of your code let me know and I'll
>>>>>> finish
>>>>>> it and ship it your way.
>>>>>>
>>>>>> -Nick
>>>>>>
>>>>>>
>>>>>> Hi Nick,
>>>>>>
>>>>>> Thanks so much for looking into this. Sorry, I couldn't get to it
>>>>>>
>>>>> earlier
>>>>> due to other concerns. I corrected the mistake you mentioned and I
>>>>> don't
>>>>> get
>>>>> numeric_limit<>::max() for any nodes anymore.
>>>>>
>>>>> I believe the graph/distributed/graphviz.hpp was outputting the
>>>>> distance
>>>>> in
>>>>> correct fashion.
>>>>>
>>>>> Unfortunately, the output is still coming out to be incorrect.
>>>>> It was also the case with output from graphviz.hpp.
>>>>>
>>>>> For the test graph that we mentioned before, essentially
>>>>> 0 --> 1 --> 2 --> 3,
>>>>> 0 --> 4 --> 3
>>>>>
>>>>> the distance output is as follows:
>>>>> global node-id : distance
>>>>> 0 : 0
>>>>> 1 : 1
>>>>> 2 : 2
>>>>> 3 : 1 //(wrong: should be 2)
>>>>> 4 : 0 // should be 1
>>>>>
>>>>> If possible can you send me your version of the code. Let me know if
>>>>> you
>>>>> need mine (the updated version).
>>>>>
>>>>>
>>>>
>>>> Given the description of your problem above, and assuming you're using a
>>>> block distribution with 8 vertices, it sounds like you're initializing
>>>> the
>>>> distance to the first vertex on *each* process to 0, as opposed to only
>>>> the
>>>> distance to the source. The vertex with global index 4 is actually
>>>> local
>>>> index 0 on process one using the above distribution. If you initialize
>>>> the
>>>> distances to the vertices with global indices 0 and 4 to 0, then your
>>>> results make sense. Let me know if that's not the case, but I surmise
>>>> that
>>>> it is.
>>>>
>>>> Very much so :-). Thanks for getting me started with by catching these
>>>>
>>> minor but fatal mis-understandings with PBFS code. I understood that call
>>> vertex(i,g) creates a descriptor for ith global vertex.
>>>
>>> Also there's a problem in your depth labeling visitor. In the case of
>>>
>>>> cross-processor edges the process that owns the target of the edge
>>>> doesn't
>>>> necessarily have the distance to the source of the edge available
>>>> locally.
>>>> This will lead to incorrect distance labels even though tree and
>>>> non-tree
>>>> edges will still be correctly recognized since the BFS is
>>>> level-synchronized. The fastest way to handle this is to modify the BFS
>>>> queue to also pass distance data (which is how the shortest paths
>>>> algorithms
>>>> do it). You could also send the data separately and probe for it on the
>>>> receiving side. Check out the distributed betweenness centrality code
>>>> for
>>>> how to create a distributed queue which contains tuples of data one
>>>> element
>>>> of which is a vertex (in order to know where to route the data).
>>>> Integrating this type of vertex queue (i.e. one that contains a data
>>>> payload) with BFS basically just requires handling the data payload on
>>>> the
>>>> receiving side.
>>>>
>>>> I would try this out. So basically the default call
>>>>
>>>
>>> boost::breadth_first_search
>>> (g, start,
>>> boost::visitor(boost::make_bfs_visitor(boost::record_distances(distance,
>>> boost::on_tree_edge()))));
>>>
>>> wouldn't work. I assumed that distributed BFS implementation did exactly
>>> what you mentioned.
>>> Although I would write my own, parallel visitor as well per your
>>> suggestions.
>>>
>>> thanks
>>> Sandeep
>>>
>>>
>>>
>>> Let me also add that I did modified code that initializes only the
>>>
>> distance to 0th vertex of processor 0. In this case i am facing the
>> dilemma
>> of what should I pass as start vertex for processes > 0. I can't pass the
>> global start vertex (probably the type won't be acceptable to
>> breadth_first_search.
>>
>> I will dig further into the betweeness centrality and dijkstra code to
>> figure this out. Appreciate your input.
>>
>
> The short answer is, just pass the same source vertex on all processors.
>
> Explanation: Each processor will push the source vertex on the distributed
> queue but all the non-local pushes end up being no-ops since the source
> vertex is black at the end of the first BFS level when the messages arrive.
> The source vertex just has to be graph_traits<Graph>::vertex_descriptor,
> which you can construct using vertex() call if you want to generate it from
> a global vertex index. The fact that all processors push the source vertex
> is an artifact of reusing the sequential BFS code, it could be changed but I
> haven't found it to be an issue thus far.
>
> This actually brings up an interesting feature of BFS, its possible to
> start a BFS from multiple source vertices by passing a different source on
> each processor (you can also pass a queue containing additional starting
> vertices if you need > num_procs sources). The strongly connected
> components algorithm uses this approach to run many BFSs on disconnected
> subgraphs in parallel.
>
> One last note on your visitor, my statement was incorrect, sorry. I was
> looking at some other code and confused it with yours, your depth labeling
> visitor will work fine because it 'pushes' distance labels. Basically it
> writes the distance to the vertex it pushes onto the queue into the
> distributed property map at the same time (actually immediately before).
> This means that at the next synchronization step both the distance and the
> vertex descriptor will arrive, in fact the ordering of the messages insures
> that the distance will arrive prior to the vertex on the queue. Sorry about
> that, I was looking at another visitor that was 'pulling' data, which is
> much more problematic.
>
> Hopefully that solves all your problems and my apologies again on leading
> you to believe there was something wrong with your visitor.
>
> The data model is a little tricky to wrap your head around, but once you've
> written some code it should become more intuitive.
>
>
> Hi Nick,
>

Thanks for the explanation of the distributed BFS. This is indeed quite
helpful. Especially at later stages. I haven't gotten to a point to comment
on the data model but the current architecture is swell from what I can
judge.

I hesitate to ask explanation at every minor detail but I now confused
about passing the same vertex descriptor. Specifically I didn't quite grasp
the statement "source vertex just has to be
graph_traits<Graph>::vertex_descriptor, which you can construct using
vertex() call if you want to generate it from a global vertex index".
The source vertex has to graph_traits<Graph>::vertex_descriptor which I
takes two arguments the index and the graph --these two parameters can only
identify local vertices. For global vertices we need global descriptors
which also require the owner.

Appreciate your help in clarifying this.

Thanks
Sandeep
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T14:58:51Z

On Mon, Nov 9, 2009 at 11:25 AM, Stewart, Robert <Robert.Stewart@...> wrote:

> Emil Dotchevski wrote:
>> On Mon, Nov 9, 2009 at 6:27 AM, Stewart, Robert
>> <Robert.Stewart@...> wrote:
>> > Determining whether a policy is unfair is subjective. If
>> > one considers,
>> > in this case, that zero warnings at some Boost-established warnings
>> > setting is important to demonstrating code quality and to make the
>> > job of reviewers as easy as possible, then it is a fair policy.
>> Alternatively, the reviewers could compile at lower warnings level.
>> Most likely they wouldn't even need to do that, because they will
>> simply build using the author scripts, which will likely produce a
>> build without warnings.
> Either is certainly possible, but if there are established warning levels, it
> is reasonable to expect that level or stricter.

This assumes that a policy that requires warnings to be "fixed" is
desirable or that it will lead to a better Boost (note that I'm not
arguing against disabling warnings in Boost headers.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [smart_ptr]make_shared_array/allocate_shared_arrayfunction templates

2009-11-09T13:50:06Z

On Mon, Nov 9, 2009 at 7:19 PM, Peter Dimov <pdimov@...> wrote:

> Frank Mori Hess wrote:
>
> Is it allright if I fix the perfect forwarding bug
>> (https://svn.boost.org/trac/boost/ticket/2962) in
>> make/allocate_shared before it maybe gets copied into a
>> make/allocate_shared_array?
>>
>
> Yes of course. I wonder why I defined forward this way.

Alright, so after the fix is done someone will have to pick up the glove and
add these. I have no idea regarding the svn updating policy, I guess not
everybody can just go ahead and check in..? I would do this if I could.

Roman.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-09T12:54:36Z

On Mon, Nov 9, 2009 at 3:39 PM, Robert Ramey <ramey@...> wrote:
> Stewart, Robert wrote:
>>
>> While not as easy for you as some yet undiscovered change to
>> noncopyable, can't you just use the MSVC pragma warning dance around
>> your classes to quiet that warning in each case?
>
> Of course I can conditionaly include pragma for this compiler.

At that point, isn't it less work to just declare the copy c-tor and
the assignment operator private? The MSDN documentation says that
this will silence the warning. I guess it would have been nice of
them to look in base classes as well when considering this warning...

> The problem is that you start have to doing for all compilers
> and they've all got their own set of quirks. This makes the
> code harder to read, understand and maintain. You HAVE
> to do it sometimes to work around bogus compiler errors
> but I'm sort of reluctant to embark upon this to work around
> bogus compiler warnings. This raises the question about how
> to handle the "warning" that such and such a function has been
> "deprecated" when it actually hasn't and of course those
> warnings which are just hints that sometimes have to be
> knowingly violated.
>
> Basically, once you start considering this - it sort of
> takes on a life of its own.

I think the proper way to deal with those warnings is documentation
that states that Boost libraries may emit those warnings unless

_CRT_SECURE_NO_WARNINGS
_SCL_SECURE_NO_WARNINGS

are defined. C++ didn't deprecate those functions, Microsoft did, so
it's no longer Boost's concern.

--Michael Fawcett
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-09T12:36:11Z

Stewart, Robert wrote:

> Robert Ramey wrote:
>>
>> I thought the serialization library was "clean" until someone
>> complained
>> that there were warnings at level 4. When I investigated, I found
>> that the major complaint was that that I had "const" members
>> so the compiler couldn't generate copy/assigment functions.
>> It turns out that these classes used the boost::noncopyable
>> facility. So to eliminate these warnings this facility needs
>> to be re-implemented in a different way.
>
> While not as easy for you as some yet undiscovered change to
> noncopyable, can't you just use the MSVC pragma warning dance around
> your classes to quiet that warning in each case?

I could, and I might but....

To my mind this is an invalid warning. The code in question is not
incorrect
and the boost::noncopyable provides the protection against the situation
that the warning is designed to detect. So from my perspective the
best would be to add /wd4511 and /wd4512 to the compiler switches.

Of course that's not really a good solution because other code might
not have the boost non_copyable protection. Ideally the compiler
would be able detect that the copy/assigment functions can't be
used in this case any way. Or maybe the compiler needs some sort
of class attribute.

in the meantime...

Of course I can conditionaly include pragma for this compiler.
The problem is that you start have to doing for all compilers
and they've all got their own set of quirks. This makes the
code harder to read, understand and maintain. You HAVE
to do it sometimes to work around bogus compiler errors
but I'm sort of reluctant to embark upon this to work around
bogus compiler warnings. This raises the question about how
to handle the "warning" that such and such a function has been
"deprecated" when it actually hasn't and of course those
warnings which are just hints that sometimes have to be
knowingly violated.

Basically, once you start considering this - it sort of
takes on a life of its own.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

2009-11-09T11:47:06Z

On Mon, 2009-11-09 at 10:22 -0800, Marshall Clow wrote:
> One note: I'm using "diff" to calculate the changes, and sometimes it
> reports changes that "svn diff" does not
> (things like changed "$Id: " lines, for instance). So sometimes when
> you click on the link, you'll get "no changes".

Is it GNU diff? If so, you might want to try
diff -b -I '\$Id[^$]*\$' -I '\$Date[^$]*\$' -I '\$Revision[^$]*\$'
(assuming unix shell; some other form of quoting otherwise...)

This isn't perfect - it won't detect other changes on a line with a
$Id$, but that would be fairly unusual. You might need to extend this
with other SVN keywords.

Also, if there are other changes in the same diff-block as the SVN
keyword changes, then the ignore pattern doesn't actually appear to trim
things out. (I've tested this with mpl/accumulate.hpp, and it silences
the diffs.)

The "-b" is just to ignore changes of whitespace (in my case,
differences in line endings).

Phil

--
Phil Richards, <news@...>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-09T11:29:47Z

Robert Ramey wrote:
>
> I thought the serialization library was "clean" until someone
> complained
> that there were warnings at level 4. When I investigated, I found
> that the major complaint was that that I had "const" members
> so the compiler couldn't generate copy/assigment functions.
> It turns out that these classes used the boost::noncopyable
> facility. So to eliminate these warnings this facility needs
> to be re-implemented in a different way.

While not as easy for you as some yet undiscovered change to noncopyable, can't you just use the MSVC pragma warning dance around your classes to quiet that warning in each case?

_____
Rob Stewart robert.stewart@...
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T11:25:00Z

Emil Dotchevski wrote:

> On Mon, Nov 9, 2009 at 6:27 AM, Stewart, Robert
> <Robert.Stewart@...> wrote:
>
> > Determining whether a policy is unfair is subjective. If
> > one considers,
> > in this case, that zero warnings at some Boost-established warnings
> > setting is important to demonstrating code quality and to make the
> > job of reviewers as easy as possible, then it is a fair policy.
>
> Alternatively, the reviewers could compile at lower warnings level.
> Most likely they wouldn't even need to do that, because they will
> simply build using the author scripts, which will likely produce a
> build without warnings.

Either is certainly possible, but if there are established warning levels, it is reasonable to expect that level or stricter. A reviewer should be able to examine the library as any Boost user would. Why would following a warnings policy be different unless a specific exception were incorporated into the policy?

> > If reviewers are expected to judge code quality and it produces
> > myriad warnings with established warnings settings, what might
> > reviewers conclude?
>
> The only reasonable conclusion is that the author prefers a lower
> warning level, or uses a different compiler. As far as I am concerned,
> a library should be evaluated only based on its documented interface.

A reasonable conclusion is that the submitter chose to ignore established Boost norms and doesn't care about the effect on reviewers, your assertion to the contrary notwithstanding.

If trying to test against the library produces myriad warnings at established Boost warning levels, as a Boost user should expect, the reviewer shouldn't judge the usability of the library highly.

_____
Rob Stewart robert.stewart@...
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Help needed in fixing warnings

2009-11-09T10:54:33Z

On Sun, 8 Nov 2009, John Maddock wrote:

> Dear all,
>
> I've started a wiki page here:
> https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate
> on fixing warnings from Boost libraries.
>
> As noted the initial effort should be directed towards core libraries - those
> that get included and reused by other libraries.
>
> You can help by:
>
> * Running the tests for your favorite libraries (those not already listed, or
> with "unknown" status), and updating their "Status" field to reflect whether
> any work is needed.
> * Filing bug reports if it's not obvious how to silence the warnings.
> * Filing patches if the fixes are obvious.
> * Fixing the code if you're a library author!
>
> There's something for everyone there, whether you're a Boost newbie, or a
> hardened veteran, so I hope that many hands can make light work of this!

Would it be possible to get the warning output from the regression tests,
at least for libs/{graph,property_map,graph_parallel}? I do not believe I
have easy access to the compilers that are going to be used for warning
checking.

-- Jeremiah Willcock
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T10:45:24Z

On Mon, Nov 9, 2009 at 6:27 AM, Stewart, Robert <Robert.Stewart@...> wrote:

> Daniel James wrote:
>> On Fri, Nov 6, 2009 at 2:13 PM, Stewart, Robert
>> <Robert.Stewart@...> wrote:
>> > Daniel James wrote:
>> >>
>> >> Currently, we don't even require that a library builds on
>> >> any specific
>> >> compilers, let alone warning free. What you're suggesting adds a
>> >> considerable burden on a developer - which is particularly
>> >> unfair if
>> >> the library is eventually rejected. Implementation issues
>> >> can be fixed
>> >> after the review and, in this case, I would hope it would
>> >> be with the
>> >> help of the boost community.
>> >
>> > It isn't unfair if the submitter understands a policy a priori.
>>
>> How does understanding an unfair burden in advance make it fair?
>
> Determining whether a policy is unfair is subjective. If one considers,
> in this case, that zero warnings at some Boost-established warnings
> setting is important to demonstrating code quality and to make the
> job of reviewers as easy as possible, then it is a fair policy.

Alternatively, the reviewers could compile at lower warnings level.
Most likely they wouldn't even need to do that, because they will
simply build using the author scripts, which will likely produce a
build without warnings.

> If reviewers are expected to judge code quality and it produces
> myriad warnings with established warnings settings, what might
> reviewers conclude?

The only reasonable conclusion is that the author prefers a lower
warning level, or uses a different compiler. As far as I am concerned,
a library should be evaluated only based on its documented interface.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

2009-11-09T10:22:45Z

On Nov 9, 2009, at 8:39 AM, Steven Watanabe wrote:

> AMDG
>
> Marshall Clow wrote:
>> [ I'm assuming that you mean to add the diff to the bottom of the
>> file, and include a link from the table - unless you know a way to
>> get svn to disgorge a diff from a URL ]
>
> You can get it from trac
>
> https://svn.boost.org/trac/boost/changeset?new_path=/trunk/libs/units&old_path=/branches/release/libs/units

Thanks, Steven (and Frank!)

Here's an updated HTML file.

One note: I'm using "diff" to calculate the changes, and sometimes it
reports changes that "svn diff" does not
(things like changed "$Id: " lines, for instance). So sometimes when
you click on the link, you'll get "no changes".

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

diff2.html.zip (64K) Download Attachment

Re: [Serialization] warnings and maybe a 'bug'

2009-11-09T10:14:30Z

Christoph Duelli wrote:

> Robert Ramey wrote:
>
>> Christoph Duelli wrote:
>>
>>> I also get lots of
>>> boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but
>>> not used where XXXX is some class name of mine
>>
>> Is it possible that the class is marked "EXPORT" when this is not
>> in fact necessary?
> Well, when *is* it necessary?
> The serialization code for classes are usually looks like this:
>
> BOOST_CLASS_EXPORT_GUID(Node, "Node")
>
> void Node::serialize(InArchive & ar, const unsigned int /*
> file_version */){ ar & BOOST_SERIALIZATION_NVP(m_sFileName)
> & ... ;
> }
> void Node::serialize(OutArchive & ar, const unsigned int /*
> file_version */ {
> ar & BOOST_SERIALIZATION_NVP(m_sFileName)
> & ... ;
> }
>
>
> Maybe I have misunderstood when I need to used
> BOOST_CLASS_EXPORT_GUID; I will read up on that again.
>
>
>>> ii) maybe a 'bug' (code does no longer compile)
>>> Code that used to compile with Boost 1.40 does no longer compile
>>> with the
>>> 1.41 beta:
>>> (I had no time to investigate yet; in case it is obvious for you
>>> once you
>>> see the code I have decided to include this point in this posting):
>>>
>>> boost/archive/shared_ptr_helper.hpp:114: error: cannot convert
>>> 'const boost::serialization::extended_type_info_typeid<MEPfad>' to
>>> 'const boost::serialization::extended_type_info*' in return
>>> (where MEPfad is a class of mine)
>>
>> In this case the code actually looks wrong to me. I'm curious why it
>> never failed any tests. If you have a small bit of source which
>> traps
>> this problem, I would be curious to see it.
> I have created a stripped down example that exhibits the error.
> (Basic ingredients: shared_ptr, binary_iarchive.)
> See attachment.

The "serialize" function should never be called directly by the app.

I'll look into why this is not trapped.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] GGL review starts today, November 5th

2009-11-09T09:41:06Z

Hartmut Kaiser wrote:
> The formal review of the Generic Geometry Library (GGL) starts today,
> November 5, 2009 and will finish November 15, 2009.
> GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz
> Loskot, with substantial input from this Boost mailing list.

This library looks like a very good example of generic interfaces for geometry objects and several well known and useful geometry algorithms.

This is not a review.

I found it difficult to answer my questions about the library based on the documentation. I am having difficulty coming up with a complete list of features for the library. It seems there is more implemented than documented. Specifically, I'd like to know more about the ggl::algorithms::overlay namespace, which appears to contain algorithms of interest to me, but is not documented.

I'll ask my questions on the list to help me identify which header files I should look at to understand the interfaces and implementation of interesting algorithms in the GGL.

1. Does the library support other Boolean operations between pairs of polgyons than intersection?
Union
XOR
AND NOT
2. If so, does the library support the union of more than two overlapping polygon simultaneously (three or more mutually overlapping polygons)?
3. Does the library support map overlay operations of two layers? Of more than two layers simultaneously?
4. If the non-self-intersecting invariant is violated at the input of the polygon pair intersection algorithm what does the algorithm do?
5. Is there a way to check self-intersecting invariant before attempting an intersection operation?
6. Is there a way to fix a polygon that is self-intersecting to be non-self intersecting?
7. When intersection points are snapped to the floating point grid at the output of the polygon pair intersection algorithm edges may move laterally some small distance which may introduce self intersection artifacts. How is this handled by the polygon intersection algorithm?
8. What is the algorithmic complexity of the polygon intersection algorithm?
9. Could you please provide the community with a description of the polygon intersection algorithm?
10. Is the polygon intersect bounding box algorithm linear time?
11. When a polygon is intersected against a bounding box the same problem can happen that self intersections are introduced in the output polygon(s) when intersection points are snapped to the floating point grid. These artifacts cannot be addressed by a linear time algorithm. Are the output polygons of the polygon intersects bounding box algorithm implemented by this library potentially self intersecting?
12. Is the distance algorithm implemented for linestring pairs? For polygon pairs? If so, what algorithmic complexity does it have, and can you describe the algorithm for the community?
13. Why is there no custom polygon example in the documentation?
14. Why do you need interior_type for the polygon concept traits? What requirements does the interior_type need to satisfy? Is it expected to be an stl container?
15. What happens if you instantiate the polygon pair intersection algorithm with integer coordinates?
16. What is required for a data type to satisfy the requirements of a coordinate type?
17. Can you tell us more about the support and usage of high precision numerical datatypes?

With enough time and effort reading the code and exercising it I can answer all of these questions for myself, but a little help from the library author would be greatly appreciated. If the answers to some of my questions can be found in the documentation please let me know where.

It is unfortunate that Fernando's buisness success leaves him so little time recently--hopefully he will be able to conduct a review. I think that as a CGAL author and user of both GPC and CGAL in his consulting work his review of the polygon intersection algorithm in GGL would be insightful.

Thanks,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Serialization] warnings and maybe a 'bug'

2009-11-09T09:27:10Z

Robert Ramey wrote:

> Christoph Duelli wrote:
>
>> I also get lots of
>> boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but
>> not used where XXXX is some class name of mine
>
> Is it possible that the class is marked "EXPORT" when this is not
> in fact necessary?
Well, when *is* it necessary?
The serialization code for classes are usually looks like this:

BOOST_CLASS_EXPORT_GUID(Node, "Node")

void Node::serialize(InArchive & ar, const unsigned int /* file_version */){
ar & BOOST_SERIALIZATION_NVP(m_sFileName)
& ... ;
}
void Node::serialize(OutArchive & ar, const unsigned int /* file_version */
{
ar & BOOST_SERIALIZATION_NVP(m_sFileName)
& ... ;
}

Maybe I have misunderstood when I need to used BOOST_CLASS_EXPORT_GUID; I
will read up on that again.

>> ii) maybe a 'bug' (code does no longer compile)
>> Code that used to compile with Boost 1.40 does no longer compile with
>> the
>> 1.41 beta:
>> (I had no time to investigate yet; in case it is obvious for you once
>> you
>> see the code I have decided to include this point in this posting):
>>
>> boost/archive/shared_ptr_helper.hpp:114: error: cannot convert 'const
>> boost::serialization::extended_type_info_typeid<MEPfad>' to 'const
>> boost::serialization::extended_type_info*' in return
>> (where MEPfad is a class of mine)
>
> In this case the code actually looks wrong to me. I'm curious why it
> never failed any tests. If you have a small bit of source which traps
> this problem, I would be curious to see it.

I have created a stripped down example that exhibits the error.

(Basic ingredients: shared_ptr, binary_iarchive.)
See attachment.

btw, I get a few of those as well (out of BOOST_CLASS_EXPORT_GUID uses):
boost/mpl/print.hpp:55: warning: comparison between signed and unsigned
integer expressions
[serbug.cpp]

#include <boost/shared_ptr.hpp> #include <boost/serialization/nvp.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/archive/binary_iarchive.hpp> #include <fstream> struct XXX { std::string name; int age; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & BOOST_SERIALIZATION_NVP(name) & BOOST_SERIALIZATION_NVP(age); } }; BOOST_SERIALIZATION_SHARED_PTR(XXX) struct YYY { boost::shared_ptr<XXX> xxx; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & BOOST_SERIALIZATION_NVP(xxx); } }; int main(int argc, char**argv) { XXX xxx; YYY yyy; std::ifstream ifs("test_output", std::ios::binary); typedef boost::archive::binary_iarchive InArchive; InArchive ia(ifs); yyy.serialize(ia, 1); return 0; }

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [smart_ptr]make_shared_array/allocate_shared_arrayfunction templates

2009-11-09T09:19:42Z

Frank Mori Hess wrote:

> Is it allright if I fix the perfect forwarding bug
> (https://svn.boost.org/trac/boost/ticket/2962) in
> make/allocate_shared before it maybe gets copied into a
> make/allocate_shared_array?

Yes of course. I wonder why I defined forward this way.

> IIRC you expressed a preference for using std::forward when I originally
> brought this up. Can I just assume std::forward is available if the
> compiler supports rvalue references? Ticket #3570 suggests this might be
> a problem with stlport however.

Your patch is fine as it is, IMO. We'll probably need to convert the
std::move uses to static_cast<T&&> as well.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [smart_ptr] make_shared_array/allocate_shared_arrayfunction templates

2009-11-09T08:59:21Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 09 November 2009, Peter Dimov wrote:

> Roman Kecher wrote:
> > Hi,
> > I'm suggesting to add the following function templates to allow easy,
> > exception-safe, creation of shared_array objects:
> >
> > - make_shared_array (very similar to make_shared which is used to
> > create a shared_ptr)
> > - allocate_shared_array (again, same functionality like
> > allocate_shared)
> >
> >
> > Is there any reason not to include these?
>
> No, there is no reason to not include them. We just need a volunteer. :-)

Is it allright if I fix the perfect forwarding bug
(https://svn.boost.org/trac/boost/ticket/2962) in make/allocate_shared before
it maybe gets copied into a make/allocate_shared_array? IIRC you expressed a
preference for using std::forward when I originally brought this up. Can I
just assume std::forward is available if the compiler supports rvalue
references? Ticket #3570 suggests this might be a problem with stlport
however.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkr4SmoACgkQ5vihyNWuA4VUYQCdHWDKjLvapj1q8aNQ0GjJxfxK
BbIAoLzhbWXF8tQVlMYcV8Azc8AnRDkK
=nGFi
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Serialization] warnings and maybe a 'bug'

2009-11-09T08:56:11Z

Robert Ramey wrote:

I just double checked - looks very OK to me - ie no bug.

Robert Ramey
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Time for another bug sprint (after 1.41 ships)?

2009-11-09T08:54:58Z

>> [ I'm assuming that you mean to add the diff to the bottom of the
>> file, and include a link from the table - unless you know a way to get
>> svn to disgorge a diff from a URL ]
>
> You can get it from trac
>
> https://svn.boost.org/trac/boost/changeset?new_path=/trunk/libs/units&old_path=/branches/release/libs/units

That's what I thought the URL should be, but trying that with libs/regex or
boost/math yields nonsense (it claims every file has changed - when they
haven't - and links to diffs yield garbage!)

Confused yours, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Official warnings policy?

2009-11-09T08:47:47Z

On Mon, Nov 9, 2009 at 9:27 AM, Stewart, Robert <Robert.Stewart@...> wrote:
>
> When a potential library submitter evaluates Boost policies, those policies may be considered too onerous or not. If the former, Boost might be denied a useful library, but the denial wasn't unfair. All submitters face the same policies and choose whether to accept them. Whether a policy is well or ill conceived can be determined more objectively than can its fairness.
>
> There could be a required evaluation step after the usual review to provide final acceptance. That would make it easier to accept warnings in a library under review. If the author does not meet the (not yet) established warnings policy after a tentative review acceptance but before final acceptance, then it would be rejected. I assume that such a two-stage review process would be fairer in your mind?

I don't think another review is necessary. What if it was the same
review process, but to be allowed to merge to a release branch you
have to meet the new stricter guidelines? That seems like a good
compromise.

--Michael Fawcett
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost