- Boost - lists.boost.org

TravisCI and Coveralls integration instructions
by Antony Polukhin 12 Jan '15

12 Jan '15

Hi all, The following step by step instruction https://svn.boost.org/trac/boost/wiki/TravisCoverals may be useful for those of you who want to: * make sure that tests cover all the code lines * make the README.md more colorful and useful * use additional testing infrastructure Here are some examples of how the results looks like: * https://github.com/boostorg/variant#test-results * https://github.com/boostorg/type_index#test-results P.S.: Shall I add this tutorial to "Guidelines" or to the "Infrastructure" section of the Wiki? -- Best regards, Antony Polukhin

2 1

[boost.fiber] regarding to migration of fibers between threads?!
by Oliver Kowalke 12 Jan '15

12 Jan '15

Hello, boost.fiber was reviewed in January 2014 and now I've finished the requested changes. Unfortunately the migration of fibers between threads is not stable yet, but synchronizing fibers running in different threads works. I'd like to know if fiber migration is absolute necessary to pass the next review or might it be acceptable to finish this feature later. so long, Oliver

2 1

[mixin] Library name
by Matus Chochlik 12 Jan '15

12 Jan '15

On Mon, Jan 12, 2015 at 1:32 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > On Mon, Jan 12, 2015 at 1:21 PM, Borislav Stanimirov <b.stanimirov(a)abv.bg> > wrote: > > > > > * EntityComponent - not great since it doesn't exactly follow the > > entity-component-system pattern, although it can be said that it allows > the > > construction of entities from components. > > > > > As long as you consider that it is not implementing the ECS pattern, it > shouldn't use this name indeed. > > +1 If the `Mixin` name is 'bad' because it is used to describe something different in C++ then `EntityComponent` is 'bad' for the same reason

1 0

Re: [boost] GSoC Proposal[game dev and boost c++]
by Mudit Sharma 12 Jan '15

12 Jan '15

Respected all, As we all know in game development Rotation and Translation play the most important role..I propose to implement either[whichever is relevant to boost] using boost geomtry(of course) and uBLAS(will make calculations easier)... Can this be taken up as a project for summers?

3 2

[Mixin] Some comments
by Vicente J. Botet Escriba 12 Jan '15

12 Jan '15

Hi, First of all, I want to say that I like your library too much. It is quite close to a library I was working one EntityRoleSubject. You library could be extended to to take in account the subjective programming paradigm (see below). I have some comments/remarks/questions: * I have some doubts about the name mixin. What a mixin has more than a facet or an aspect? Mixins in C++ have a specific mean in the context of CRTP. Why have you chosen the mixin name? * The construction of the mixins in the tutorial is done always with the default constructor. Can we do emplace construction? How can you ensure the invariants of some mixing classes? * The priority of the messages doens't compose well. The user needs to have a global view of the application so that it can assign the correct priority. I have not a better suggestion, but I think that this issue would need more insight. * Respect to subjective programming: it would be great to be able to create subject from an entity so that only the mixins of the subject would play when a reference to this subject is addressed. subject<Mix_1, .... Mix_n> s (o); o.get<Mix_k>() works as expected. o.get<Other>() compile fails if not equal to any Mix_k * The macro bm_this :( * I would like to see what is behind the scenes the different macros in an implementation section. * The entity-mixin relation is not recursive, that is, a mixin can not have associated mixins, or can them? * Can a mixin D inherit from another mixin B? Could the mixing D be retrieved when getting the mixing B? mutate(o).add<D>; o.get<B>()->f() // f been a virtual function on B? * The example of the mixin headphones_player show that the play() implementation makes use of get_sound() provided by other mixins. This dependency is not explicit. I would expect to be able to say that headphones_player depends on another mixing providing the get_sound message. That's all for now.I will come back later when i will read more. A BTW, the reference documentation doesn't contain the add<M>/get<M> mutate functions? Best, Vicente

4 11

[chrono] Dependency on math?
by Beman Dawes 12 Jan '15

12 Jan '15

The latest dependency report shows chrono as having a dependency on math. See http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-overview.html math is really big. In testing bpm, an install of timer (which depends on chrono) slowed noticeably when it got to math. Presumably the build is also much slower, although I haven't tested that yet. Is the math dependency really needed? Thanks, --Beman

7 18

[Mixin] Some comments
by Matus Chochlik 12 Jan '15

12 Jan '15

On Sun, Jan 11, 2015 at 4:02 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > On Sun, Jan 11, 2015 at 8:41 AM, Matus Chochlik <chochlik(a)gmail.com> > wrote: > [8<] > > > > I've been playing with some ECS designs lately and tried to implement two > > of my own [1],[2] (maybe those are among those you've already seen) (and > > sorry for the shameless plug). Based on what I've seen, if the ECS is to > be > > used according to the usage patterns you usually see in a game (or > > rendering) engine, I believe it is better for the component instances to > be > > stored together, outside of the entities (for locality of reference, > > efficient (re-)allocation, etc.). > > > > > I violently agree. > > > > The entity should IMO be just an unique identifier > > > My experiments so far reach to the same conclusion: it's the most flexible > and potentially efficient approach. > > > > and in both of my > > implementations there is a `manager` class that can be used to > > store/modify/query/remove/etc. the components of an entity. This way > > operations that are common, like execute this function (every iteration > of > > the update loop) on all entities with this set of components can be > > implemented more efficiently. > > > > In my current implementation I call the object > holding all components a "cluster". The Cluster hold one "pool" > of component by type of components. > Currently all the pools are the same type and basically are > augmented flat_maps but I recently realized that a more flexible system > could be implemented by letting the cluster user insert different kinds of > polls > depending on how he wants the component type to be memory managed ( > like a vector or like an actual pool or with allocated nodes?), how > "updates" are processed (in parallel, concurrent, jsut a loop?). > I plan to try this design in the coming months. > Ditto, In my second implementation I've defined an interface for the component storage objects (classes managing instances of components of one type in the manager). The interface is flexible enough to allow local or remote mutable/immutable storages, or storages using an RDBS, a web service, etc., to actually store the component instances. From the users' POV all this is transparent, they manipulate the components uniformly through the manager, they just need to specify what kind of storage should be used when registering the component type in a manager. > > I didn't solve the component-inter-requirements problem though, I'm not > sure > if I should implement this at all, and if yes should it be compile-time > checked > as Vincente suggests? In which case the cluster would have to know > the types it can manage at compile time too, because I see no way for > an entity to be able to be checked at compile time except for a construct > like > the suggested "subject". > I'm not sure what Vincente's use case is, but in game engines the ECS *deliberately* places very few constraints on the components and how they can be combined in an entity. The idea is that the programmer does not have enough knowledge of what the content creators or modders will want to do and statically constraining the components too much requires complete recompilation every time a change is made in the game logic accessing the ECS which is undesirable for the original content creators and usually impossible for modders. Furthermore game engines very often support modification of the ECS through scripting which again could be hindered if constraints were placed on how the components are combined. These concerns IMHO apply also on other applications, like CAD/CAM, etc. using an ECS. [8<] > > > > But having implemented several apps using this approach I find it quite > > limiting in some situations that the group of components is static. > > Sometimes it is useful (for example for debugging) to have the ability to > > add/remove component *types* on-the-fly. [2] allows this but its > > unfinished. > > > I can do that in my implementation indeed, it is helpful. > As said before I think it can be improved by allowing the user to provide > the > container of component for a type, making him chose how to manage them > as long as the container match a specific set of requirement (concept?). > > I use an abstract interface and so far the overhead from virtual function calls is not very dramatic. [8<]

3 2

[build] Test marked as compile-fail is now reported as a failure.
by Adam Wulkiewicz 12 Jan '15

12 Jan '15

Hi, Since yesterday one test marked as compile-fail is now reported as a failure on the regression tests page. It's the test: rtree_values_invalid on the page: http://www.boost.org/development/tests/develop/developer/geometry-index.html Surprisingly other tests aren't. see e.g.: geographic_custom_point_with_wrong_units on the page: http://www.boost.org/development/tests/develop/developer/geometry.html They seem to be defined the same way in the Jamfile: https://github.com/boostorg/geometry/blob/develop/index/test/rtree/Jamfile.… https://github.com/boostorg/geometry/blob/develop/test/point_concept/Jamfil… AFAIS the oldest run when it failed was of the runner: teeks99-03c-Ubuntu12.04-64 on Sat, 10 Jan 2015 02:05:44. On Fri, 09 Jan 2015 18:36:55 (teeks99-08b-win2012R2-64on64) everything was ok. Furthermore when run locally it's also reported as a failure. Some time ago of course "(failed-as-expected)" message was printed instead. Do you have any idea what may be wrong? Regards, Adam

2 1

[filesystem] Problems with UTF-8 paths in GIT.
by Rene Rivera 12 Jan '15

12 Jan '15

This commit < https://github.com/boostorg/filesystem/commit/785d521b54140763dd23ef091a18d…> is causing me some problems with some git clients. In particular the git client in Eclipse errors out with some unsupported / invalid messages. I know why those dir names are the way they are.. But we still are supposed to follow the naming rules we agreed to < http://www.boost.org/development/requirements.html#Directory_structure>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

About a Ratio/MPL submodule and removing dependencies from Ratio/Chrono on MPL.
by Vicente J. Botet Escriba 10 Jan '15

10 Jan '15

Hi, Boost.Ratio has a logical submodule providing an extension to the standard see boost::ratio as an MPL type adding struct rational_c_tag : int_<10> {}; This submodule could be moved to the subdirectory of libs/ratio/mpl so that the users of boost::ratio, shouldn't depend on MPL. Boost.Chrono depends already on MPL, but the dependencies are really minor - see below (and can be replaced by StaticAssert and TypeTraits, so that this dependency could be removed also. Do you think removing the dependencies of Boost.Ratio and Boost.Chrono on Boost MPL has value? Best, Vicente P.S. I know that currently TypeTraits depends on MPL, but we expect to resolve this dependency already. |<boost/mpl/assert.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/bool.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/if.hpp>| * from |<boost/chrono/io/duration_get.hpp>| * from |<boost/chrono/io_v1/chrono_io.hpp>| |<boost/mpl/logical.hpp>| * from |<boost/chrono/detail/is_evenly_divisible_by.hpp>| * from |<boost/chrono/duration.hpp>|

3 2