gmane.comp.lib.boost.devel

Re: [type_erasure][release] okay to add to release?

Daniel James — 2013-05-22T08:39:42

Ah crap, I didn't realise this was a new library, so I haven't looked
it at closely enough, or done any of the other things that need to be
done. I'll deal with later, although there are some inspect failures
that need to be cleaned up:

http://boost.cowic.de/rc/docs-inspect-trunk.html#type_erasure

The release branch inspect isn't working at the moment, possibly a bug
in its html generation.

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

Re: JSON Parser + Boost Fusion + adapted structs

Max Skvortsov — 2013-05-22T03:03:07

I have been looking at Boost.Fusion to enable the parser to
reflection-in-c

I used BOOST_FUSION_ADAPT_STRUCT in conjuction with boost.serialization to
automate serialization of messages between clients and server in my
application. It just reflects simple C++ structs with data to XML/TEXT for
pass them throughout network.
After few experiments with RTTI, some kind of type erasure (with "variant"
and
"any" types), true object-oriented approach and boost.fusion I have found
that
the last one gives more benefits and fit in static type system of C++ more
naturally.


As alternate you look at implementation of serialization in
Different ORM libraries, but they use external tools
Message passing and RMI libraries like Apache.Thief or libcppa, but they use
RTTI AFAIK.

I think boost.fusion is the only one way to implement true compile-time
reflection. With certain restrictions, of course.


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

Re: Git Modularization Review no vote heads-up

Jürgen Hunold — 2013-05-22T07:56:26

Hi Dave,

On Tuesday, 21. May 2013 22:30:10 Dave Abrahams wrote:

It this is the only rationale, then let us please abort the idea of history 
rewriting and start making things right after the conversion. git "move" just 
works fine, even with git svn ;-) And please remember that svn still has no 
atomic "mv", but just "rm/add" combination which is quite error prone, 
especially with svn merge. Been there, still doing that.


In this case reducing directory depth and removing artefacts from v1 -> v2 
transition, I presume.

But this can easily be done after the conversion.

I think we already lost too much time with failed rewrite attempts, so let us 
get a working repository first. Then Volodya can test git mv v2/* . and report 
results. Afterwards, we can always try rewriting in a separate clone.

Yours,

Jürgen

Re: [githelp] modular boost instructions?

Jürgen Hunold — 2013-05-22T07:48:12

Hi Dave,

On Wednesday, 22. May 2013 00:08:54 Dave Abrahams wrote:

Aborted with.

Revision 44341
++ WARNING: refs/tags/tools/build/BOOST_BUILD_V1 is copying from branch 
refs/tags/BOOST_BUILD_V1 but the latter doesn't exist. Continuing, assuming 
the files exist in repository build

Revision 44923
++ ERROR: sandbox: fast-import process error

make[2]: *** [CMakeFiles/conversion] Error 255
make[1]: *** [CMakeFiles/conversion.dir/all] Error 2
make: *** [all] Error 2


Dave, can you please disable all history rewriting attemps for Boost.Build and 
start again? It is much more important to get a working repository now as a 
lot of people want to start contributing.

I'll address Volodya's concerns in the other thread.

Yours,

Jürgen

[heap] van Emde Boas tree proposal

Jeremy Murphy — 2013-05-22T07:30:40

Hi everyone,

I propose to add the van Emde Boas tree (vEBt) to Boost, primarily as a
container adaptor to satisfy the Boost.Heap concept and interface.


Rationale

The vEBt is an extremely efficient data structure for satisfying the
operations of a priority queue.  Where u = |U| and U is the universe of
numbers that can be stored in the container, the vEBt performs top() in
O(1) and push(), pop(), erase() in O(lg lg u).  U is, however, limited by
type and range: positive integer values from 0 to 2^w (where w is the word
size)*.  The naive implementation uses an abysmal Θ(u) space but this can
be improved to Θ(n) with hashing.


Design

If people support the idea of the vEBt in principle then I would be really
interested in their thoughts on ... should u be a run-time or compile-time
constant?  Should the vEBt be available as a data structure for purposes
other than a priority queue?


Implementation

I recently finished the basic implementation of the algorithm, so anyone
interested in seeing a teething new-born is welcome to take a look.**
 Gritty questions and constructive criticism about class structure, etc are
always welcome.  The code won't meet all the programming guidelines yet,
but don't worry, I have them in mind.

Cheers.

Jeremy


* There is a good lecture on it from MIT here:
https://www.youtube.com/watch?v=AjFtTQevtq0
** https://code.google.com/p/veb-heap/

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

Re: [githelp] modular boost instructions?

Dave Abrahams — 2013-05-22T07:08:54

on Tue May 21 2013, Dave Abrahams <dave-AT-boostpro.com> wrote:


I think this is probably fixed now.  We'll know for sure after
http://jenkins.boost.org/job/Boost2Git/1538/ completes.

Re: Git Modularization Ready for Review

Andrey Semashev — 2013-05-22T06:29:01

On Wed, May 15, 2013 at 11:59 PM, Andrey Semashev <andrey.semashev< at >gmail.com


Ping? Any opinions on this?

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

Re: [githelp] modular boost instructions?

Dave Abrahams — 2013-05-22T05:57:28

on Tue May 21 2013, legalize+jeeves-AT-mail.xmission.com (Richard) wrote:


Actually, what we actually wanted reviewed (distribution of SVN changes
to Git repositories, branches, and tags) is perfectly ready.  Even
though it's a completely separate issue, I know that most people just
care about seeing submodules, though, so I'm working on a fix for the
problem.

Re: [test]: heap tests broken in release

Vicente J. Botet Escriba — 2013-05-22T05:49:02

Le 22/05/13 06:40, Tim Blechmann a écrit :
Hi,

maybe seen the differences of Boost.Test in trunk and release would help 
you.

Best,
Vicente

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

Re: Git Modularization Review no vote heads-up

Dave Abrahams — 2013-05-22T05:30:10

on Tue May 21 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:


Well, there's nothing really we can do about that lack of trust.  It's a
simple matter to move files in Git.


Why do you want to revise history?


How do you define "right?"

Re: Git Modularization Ready for Review

Dave Abrahams — 2013-05-22T05:26:01

on Tue May 21 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:


That doesn't sound like a very accurate reflection of history.  There
used to be code in tools/build/, directly.  What "other branch" should
that go into, and at what path would you like it to be placed?

And there are lots of changes outside trunk/ that should get similar
treatment, whatever you decide to do.  See:

https://github.com/boostorg/build/branches
https://github.com/boostorg/build/tags

One possibility is that you keep everything under tools/build (other
than tools/build/v2) in the branches where it currently resides, but put
it in a subdirectory called v1/ rather than at the top level.  However,
there's probably a point in history where that stuff would *belong* at the
top level because, e.g., v2 didn't exist.


We could... but I am a little concerned about making changes to history
that diverge too far from reality.  Remember, you are free to move
things around and rename branches after modularization is
complete... but I'm not sure we should do too much revision of the
actual history.  Thoughts?

[test]: heap tests broken in release

Tim Blechmann — 2013-05-22T04:40:41

hi all,

for some reasons, the tests of boost heap are broken in release. it
crashes somewhere in boost.test code. trunk works well ...

FP=0x7fffdee7d5e0 [/usr/include/c++/4.7/ext/new_allocator.h#120]
   1 __gnu_cxx::__alloc_traits<std::allocator<unsigned long>
[/usr/include/c++/4.7/ext/alloc_traits.h#203]
   2 std::vector<unsigned long,std::allocator<unsigned long>
[/usr/include/c++/4.7/bits/vector.tcc#354]
   3 std::vector<unsigned long,std::allocator<unsigned long>
[/usr/include/c++/4.7/bits/stl_vector.h#893]
   4 boost::unit_test::test_suite::add PC=0x0056d823, FP=0x7fffdee7d6d0
[/media/hd3btr/sources/boost-release/boost/test/impl/unit_test_suite.ipp#139]
   5 boost::unit_test::ut_detail::test_init_caller::operator ()
PC=0x00577721, FP=0x7fffdee7d710
[/media/hd3btr/sources/boost-release/boost/test/impl/framework.ipp#96]
   6
boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::ut_detail::test_init_caller>
PC=0x0057c657, FP=0x7fffdee7d730
[/media/hd3btr/sources/boost-release/boost/test/utils/callback.hpp#42]
   7
boost::unit_test::ut_detail::callback0_impl_t<int,boost::unit_test::ut_detail::test_init_caller>::invoke
PC=0x0057c526, FP=0x7fffdee7d760
[/media/hd3btr/sources/boost-release/boost/test/utils/callback.hpp#89]
   8 boost::unit_test::callback0<int>::operator () PC=0x00586d31,
FP=0x7fffdee7d780
[/media/hd3btr/sources/boost-release/boost/test/utils/callback.hpp#118]
   9
boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>,boost::unit_test::callback0<int>
[/media/hd3btr/sources/boost-release/boost/test/impl/execution_monitor.ipp#281]
  10 boost::execution_monitor::catch_signals PC=0x00585ecf,
FP=0x7fffdee7e290
[/media/hd3btr/sources/boost-release/boost/test/impl/execution_monitor.ipp#885]
  11 boost::execution_monitor::execute PC=0x00585f8b, FP=0x7fffdee7e370
[/media/hd3btr/sources/boost-release/boost/test/impl/execution_monitor.ipp#1211]
  12 boost::unit_test::framework::init PC=0x7f7a20adb04a,
FP=0x7fffdee7e400
[/media/hd3btr/sources/boost-release/boost/test/impl/framework.ipp#268]
  13 boost::unit_test::unit_test_main PC=0x7f7a20af0c17,
FP=0x7fffdee7e4b0
[/media/hd3btr/sources/boost-release/boost/test/impl/unit_test_main.ipp#177]
  14 main             PC=0x004d6439, FP=0x7fffdee7e4d0
[/media/hd3btr/sources/boost-release/boost/test/unit_test.hpp#59]
  15 __libc_start_main PC=0x7f7a1fecfea3, FP=0x7fffdee7e590
[/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.17.so]
  16 _start           PC=0x004d6344, FP=0x7fffdee7e598
[/media/hd3btr/sources/boost-release/bin.v2/libs/heap/test/fibonacci_heap_test.test/gcc-4.7/debug/threading-multi/fibonacci_heap_test]

--

any idea?

thanks, tim


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

Re: [githelp] modular boost instructions?

Richard — 2013-05-22T03:16:00

[Please do not mail me a copy of your followup]

boost< at >lists.boost.org spake the secret code
<1369115164.11156.166.camel< at >frodo2> thusly:


Yes, that helps a lot.  Mainly, you confirmed everything that I suspected.

I'm happy to wait for the dust to settle a little bit more.

I thought things were farther along because there have been some
threads about a review for modular boost.  It ain't ready for
primetime yet.

I wanted to try it out for changes to boost.test documentation, but
I'll wait longer for htat.  I've got my own mercurial workflow that's
capturing my changes in revisions right now.

Re: [graph] A few additions to propose to BGL

Mikael Persson — 2013-05-21T23:43:11

Hi Jeremiah, thanks for the reply,
here are the answers to some of your questions:

under the Boost license for them to be included.

Sure, that was implied when I said "I'm willing to contribute them back".
The code in my public repository is GPL-licensed, but I'm the sole author
and I will re-license whatever parts would be incorporated into Boost. No
problem.


https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/bgl_more_property_maps.hpp
Could you please briefly explain the others?  How does self_property_map
differ from typed_identity_property_map; I see that yours returns a
reference rather than a value, but is that important?

Currently, Boost uses "put_get_helper" as a CRTP-style helper class to give
the "put-get" free-function capabilities to property map classes that are
then only required to have an operator[]. The subobject_put_get_helper
class does the same but for the cases where the mapped value is a subobject
(e.g., data-member) of the key value. This is the main thing. This idea of
the mapped value being a subobject of the key value is a pretty critical
thing and allowing it is probably the major "change" introduced by some of
these property-maps.

There are two kinds of property-maps in my header.

The first kind are those that are useful when creating custom graph classes
with BGL-like property-maps associated to them:

whole_bundle_property_map:
This map delivers the vertex_bundled / edge_bundled associated with a given
vertex or edge descriptor. This exists in the BGL as implementation details
of graphs like adjacency_list (I believe it is
"vec_adj_list_vertex_all_properties_map").

propgraph_property_map:
This is a property-map that relies on some get-function on the graph. BGL's
adjacency_list implements calls like "get(prop_tag, graph, key)" as a
combination of "get(prop_tag, graph)" to get the property-map and them
"prop_map[key]" to get the value. This property-map does the reverse, in
implements "prop_map[key]" in terms of "get(prop_tag, graph, key)", which
is easier to implement when writing a new graph class (if you've looked at
the BGL's adjacency_list implementation, you know what I mean).

bundle_member_property_map:
Similarly to the others, this is what you can use to implement calls like
"get(&MyBundle::SomeMember, graph)" on any graph that implements the
operator[]. The motivation for this is the same as the other two.

In other words, I have a more straight-forward approach, my graph types
implement an operator[] to get the vertex-/edge-bundle, and possibly some
specific "get(prop_tag, graph, key)" overloads. The existing BGL classes
have a much more convoluted implementation, probably as a consequence of
starting out using only boost::property<> and property-maps. I simply found
it easier to do things the other way around in my implementations, which
led to these property-maps as building-blocks to turn a simple graph class
implementation into one that fully supports BGL-style property-maps. That's
all this is. The BGL is not very welcoming from a user to write/use his own
graph classes, one of the main hurdle is wrapping one's head around the
convoluted property-map-related meta-programming it uses (and implicitly
requires).

The second kind are those that deal directly with bundles:

self_property_map:
This is an "identity" map, but it doesn't do a copy. That's all. It differs
from existing "typed_identity_property_map" exactly because of that. But
it's a critical difference when coupled with the next two property-maps.

composite_property_map:
This is can be used to chain two property-maps, i.e., the value-type of the
inner-map is the key-type of the outer-map. That's pretty self-explanatory
I think.

data_member_property_map:
This delivers a data-member of a key-type object. For example, consider
this simple function:

template <typename Graph, typename PositionMap>
void add_random_vertex(Graph& g, PositionMap position) {
  typedef typename boost::graph_traits<Graph>::vertex_bundled VertexProp;

  VertexProp vp;                 // create a vertex-bundle to be inserted
into the graph.
  put(position, vp, rand() );    // set its position value.
  add_vertex(vp, g);             // add it to the graph.
};

Here, the position map would be of type data_member_property_map, it's
key-type is the vertex_bundled type and it's value-type is some position
type. The point here is that the vertex-property (given to the add_vertex
function) can be set with a generic property-map. This was essential to me,
and I'm sure would be useful to others too. AFAIK, the BGL's doesn't have
such capability. Note that coupled with the composite-property-map, you
can, for example, create a vertex-descriptor to bundle-member property-map
out of a whole_bundle_property_map and a data_member_property_map, which is
also very handy.

So much for a "brief" explanation, sorry.


think of Boost.PropertyTree?  It has a different domain than your concepts,
but is also trying to represent trees.  There also seem to be (limited)
tree concepts in Boost.Graph; see <boost/graph/tree_traits.hpp> and
<boost/graph/graph_as_tree.hpp>.  They do not appear to be heavily used,
though, and yours look to be cleaner and more capable.

Frankly, I don't understand the point of Boost.PropertyTree, I think it's
just too foreign for me to say much about it, I think the domain is just
very different, and I'm not a big fan, in general, of the whole "making a
tree-like container", I don't see the point.

I actually didn't know about the BGL's tree_traits / graph_as_tree. It's
minimalistic, to say the least. The only thing it has is the
"traverse_tree" function, which is just confusing (N.B.: it's implemented
with actual recursive calls, that's not acceptable), and the root /
children / parent functions (which are kind of trivial). It's very
incomplete, and doesn't really address the main thing, which is
constructing and destructing the tree structure. When constructing a tree
(using a BGL graph), you always create a vertex and then create an edge to
its parent, and when destructing a tree, you always clear an edge, remove a
vertex, and possibly all its children (which can be tricky). These are the
annoying / error-prone operations that also break genericity (e.g., you
cannot change a graph-class for a tree-class without having to re-code
these parts, and similarly if the assumptions about the graph-class change).

Another possible set of useful functions for trees would be "re-wiring"
function, such as re-connecting a child to a new parent. Currently, with my
tree concepts, you can remove an entire branch, but you cannot "move it" to
another parent. This obviously doesn't make sense for all tree types, but
could constitute another refined concept (e.g., "ReWireableTree").


original graph's vertex and edge indexes (with not all values valid) and
filters out the removed vertices in traversals.  Could you please compare
your approach to that?

The filtered_graph is used when the user has some external mechanism for
"invalidating" vertices, and wants to create a filtered view of the
vertices. The NonCompactGraph concept would apply to graphs that have an
internal mechanism that invalidates vertices, and yet conserve an
unfiltered view of itself. In other words, the concept encodes the
predicates that would/could be used when building a filtered view. I guess
that's the best way I can put it. I thought this concept made sense when I
first wrote it, but that conviction has been growing weaker ever since.


places that you would use the non-compact iterators that are not
immediately followed by filtering the vertices manually?

That is exactly why my convictions have grown weak. I have never used
random-access on the vertex iterators, and can't think of a reason to.
Every traversal I have in my code is followed by a manual test for
validity... well, I forgot it in some places, which caused me a lot of
grief. So, I'm mostly on your side on this. I certainly know that people
use random-access when using the grid_graph class, which could also
potentially be made to have "holes" in it. But there are no such classes
(neither in BGL nor in my proposed additions).

I'd be more than willing to remove that NonCompactGraph concept, and amend
some of my implementations to inherently be "filtered" to skip invalid
vertices and edges during traversals.


part of the concept; it just means that code that uses them would rely on
that particular type rather than the general concept.  You could also have
a refining concept that adds the extra functionality.

I'll leave it as is, especially if I remove the NonCompactGraph concept.
Although it wouldn't be hard to have a general function template like:

template <typename Graph>
void repack_graph(Graph&) { };

and overload it for any graph that does provide such a capability. In other
words, have genericity by the "works for all, but actually does something
only when needed" principle. No need for an additional concept.


https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/bgl_tree_adaptor.hpp
https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/pooled_adjacency_list.hpp

I agree. The tree adaptor is sort of an obvious and easy item to include if
tree concepts are introduced (currently, it only works for adjacency_list,
could be extended further, I was just too lazy to do all the
meta-programming required to dispatch to correct overloads). The pooled
adjacency list is very useful too. I was tempted by the option of using a
Boost.Pool allocator for a std::list vertex storage, but that doesn't
really work quite as well, due to the overhead of the next/prev pointers
and the non-linear traversal pattern. So, I would favor this approach
instead. Also note that my implementation relies on Boost.Variant to
discriminate valid/invalid nodes and to store the "next-hole" pointers
within the invalid vertices (i.e., as a "union"), but I'm open to
suggestions if there is a better way to do it.


https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/linked_tree.hpp
https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/d_ary_bf_tree.hpp
https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/graph_alg/d_ary_cob_tree.hpp
doesn't, and that causes problems for some users.

I don't really understand what you mean by "external storage". These trees
are for storage, nothing else. If you externalize the storage, there
wouldn't be much left except an adaptor (like the tree-adaptor above). The
linked-tree does the exact same kind of work as the adjacency_list, but
restricted to a tree structure (each node has one parent (one in-edge) and
any number of children (and out-edges)). The contiguous layout trees are
similar except they have a maximum number of children (fixed-arity). They
do not have any other "logic" beyond enforcing those invariants (one
parent, some children for each node). So, the only thing they do is
storage. In fact, I have mostly used the contiguous layout trees as the
external storage for other things (to improve cache-performance).

About the d-ary heap, I've been using it a lot, it's a great little heap
implementation, but it's quite annoying to use. But my main problem with it
is the fact that it uses external storage for the indices. But that's a bit
off-topic.

trees that allow going from parents to children, not just the other way?

All my trees are bi-directional. You can get to the parent node via the
"in_edges(v, g)" function (or there could be an additional function for
that in the tree concepts), just like a normal graph, except that there is
a guarantee that there is always exactly one in-edge, unless it's the root
vertex. The contiguous layout trees are bi-directional without any overhead
because, given a vertex, you can calculate the memory location of the
parent vertex or any child vertex with some simple arithmetic. The
breadth-first layout is optimal for breadth-first traversal (which is just
a linear memory traversal), it is also, AFAIK, as good as can be for
best-first search/traversal, and it's also pretty good for depth-first
traversal (of course, a depth-first layout would be better for that). But
again, these are merely for storage purposes. For actually organizing the
tree, you would code stuff on top of that, for example, I have a Dynamic
Vantage-Point tree implementation that I use for metric-space partitioning
(for fast nearest-neighbor queries), and the tree storage type is just one
template parameter (and relies on the proposed tree concepts to use it):
https://github.com/mikael-s-persson/ReaK/blob/master/src/ReaK/ctrl/path_planning/dvp_tree_detail.hpp

This separation of "storage" versus "indexing" is very important in my
opinion. There is the indexing logic by which the tree is created /
organized / re-wired, and there is the way it is stored in memory. The
indexing logic seems to be more the domain of the Boost.Intrusive library
(red-black trees, AVL-trees, etc.., this is all "indexing logic", not
storage). And my trees are purely in the domain of storage.


Cheers,
Mikael.

Re: [MPL] Bug with default lambda expressions?

Larry Evans — 2013-05-21T23:04:58

This sounds like a problem similar to the one here:

http://article.gmane.org/gmane.comp.lib.boost.devel/227344

Maybe reading that thread would give you some ideas for
a solution.

HTH.

Larry




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

Re: [circular_buffer] Volunteer(s) needed

Jan Gaspar — 2013-05-21T22:12:05

Hi guys,

Thanks for the interest to participate.

I suggest you have a look at the list of the bugs/tasks which needs to be done. If you feel you can do it, assign the task to yourself and work on it. If you get stuck ask for help.

Cheers.

Jan




________________________________
 From: Jan Gaspar <jano_gaspar< at >yahoo.com>
To: "boost< at >lists.boost.org" <boost< at >lists.boost.org> 
Sent: Tuesday, 21 May 2013, 6:26
Subject: [boost][circular_buffer] Volunteer(s) needed
 


Hi all,

Is there any volunteer that could take over the circular_buffer library? I do not maintain it any more.

There are several bugs which need to be fixed and one challenging feature request (to implement move semantics).

Here is the full list:

Type: Bugs

#4100     some boost classes have sizeof that depends on NDEBUG
#5362     circular_buffer does not compile with BOOST_NO_EXCEPTIONS
#6277     Checked iterators are not threadsafe
#6747     Circular_Buffer / Bounded_Buffer inside Template class problem
#7025     circular buffer reports warning: " type qualifiers ignored on function return type" while compile.
#7950     Eliminate W4-warnings under
 VS2005
#8012     Inconsistency in linearize()
#8438     vector & circular_buffer storage misbehave when using compiler optimizations

Type: Feature Requests

#5511     Documentation needs some improvement
#7888     circular_buffer should support move semantics

Type: Patches

#8032     Warning fixes in circular_buffer

(Prior doing any changes please read how the circular_buffers' documentation is generated: http://svn.boost.org/svn/boost/trunk/libs/circular_buffer/doc/HOWTO-srcdoc)

Thanks and regards,

Jan

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

Re: [circular_buffer] Volunteer(s) needed

Jan Gaspar — 2013-05-21T21:56:01

Thanks, Paul. That would be awesome.

Jan

________________________________
 From: Paul A. Bristow <pbristow< at >hetp.u-net.com>
To: boost< at >lists.boost.org 
Sent: Tuesday, 21 May 2013, 15:07
Subject: Re: [boost] [circular_buffer] Volunteer(s) needed

more.

I'd be willing to update the docs (probably using the Quickbook with Doxygen and Autoindex setup
which is much more 'standard' and so more easily updated by others - and also makes much better use
of the excellent Doxygen comments, and provide full indexes of functions etc). 

The text part of the docs will remain more or less as-is except that the examples can be displayed
using snippets ensuring the code and docs stay in sync.

I'd also provide the necessary file so that those who prefer Doxygen display can use that format.
(The attached post on the Clang development group tells how Clang and Doxygen are becoming more
'friendly' and this may give even more benefits - though I've yet to try this).

Paul

PS I've not offering the maintain the software!Hi All,

I'm pleased to announce that as of version 1.8.4 doxygen can optionally use libclang to 
provide a more accurate source browsing experience, and better syntax highlighting, 
cross referencing, and call graphs.

To enable this feature use
./configure --with-libclang

and then set CLANG_ASSISTED_PARSING to YES in doxygen's configuration file.
Additional compiler options can be passed via CLANG_OPTIONS.

You can download doxygen from: http://www.doxygen.org/download.html
or get the code directly from GitHub: https://github.com/doxygen/doxygen

Feedback is welcomed.

Regards,
  Dimitri
_______________________________________________
cfe-dev mailing list
cfe-dev< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

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

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

Re: [1.54.0] Deadline for major changes approaching

Daniel James — 2013-05-21T21:33:29

Not strenuously at all.

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

Re: [MPL] Bug with default lambda expressions?

Eric Niebler — 2013-05-21T21:31:32

I'm not an expert, but it sounds like a bug to me. You should probably
file it (http://svn.boost.org) so it doesn't get lost. Assign it to
Aleksey Gurtovoy (agurtovoy). A patch certainly couldn't hurt. Even
better if it came with a test. :-)

Re: [parameter] BOOST_PARAMETER_CONSTRUCTOR bug

James Hirschorn — 2013-05-21T21:29:29


Yes, that works. I should have checked here before making the report...

Thanks,
James


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

Re: [thread] SEVERE bug on packaged_task constructor inC++11 mode.

Eric Niebler — 2013-05-21T21:25:15

As you can see from the release schedule
(http://www.boost.org/development/index.html), the release branch is
open for bug fixes until next Monday. Get a fix checked into trunk and
let tests cycle. Then you can merge to release.