November 2009 - Boost - lists.preview.boost.org

Meta State Machine library review starts Monday
by Tom Brinkman 23 Nov '09

23 Nov '09

I remember hearing alot about UML years ago, but I have not heard very much about it lately (last 5 years). Any sense who popular UML is these days. It seems to me it was once greatly touted as the cure to most of project management and prototyping needs. Does anyone have any experience using it? Where is it primarily used, what kind of projects can benefit from it?

1 0

Preliminary submission: generic linear algebra algorithms library Boost LA
by Emil Dotchevski 23 Nov '09

23 Nov '09

I remember some past discussions on this mailing list about the need for similar library in Boost, so I hope it is OK to skip the interest query and request a preliminary review for Boost LA. Boost LA provides a set of generic linear algebra algorithms, primarily for working with vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the vector_traits and matrix_traits templates. Documentation and source code available at http://www.revergestudios.com/boost-la, released under the Boost Software License. Thanks, Emil Dotchevski

9 25

[GGL] Is this a bug, or undocumented behavior?
by Jonathan Franklin 23 Nov '09

23 Nov '09

I have been running some of my own polygon union test cases on the union_inserter. The union_inserter doesn't appear to return a minimal set. E.g. if the start point of a polygon appears in the union, it will appear twice (consecutively). Is this expected behavior? If so, it should probably be documented. I have some other algorithms which expect a sequence of unique points, so I would need to pre-process the result of this function call. Thanks, Jon

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Thomas Klimpel 22 Nov '09

22 Nov '09

Stefan Seefeld wrote: > Wait. You'd like to have releases bundle both, and you don't want to > provide distinct guarantees. What's the point in this split, then ? 1) To make the life of package maintainers (e.g. debian, ubuntu) easier. 2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package. 3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this. Regards, Thomas

2 3

[1.41] Are docs on the website updated?
by Andrey Semashev 22 Nov '09

22 Nov '09

I'm looking at Boost.DateTime changelog page: http://www.boost.org/doc/libs/1_41_0/doc/html/date_time/details.html#date_t… It looks like it has not been updated since the previous release. The source documentation in SVN (release branch) includes changes between 1.40 and 1.41. Is this a known issue?

2 2

new library boost.fiber in vault
by Oliver Kowalke 22 Nov '09

22 Nov '09

I've re factored boost.fiber (-> boost vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu…) The library provides a so called lightweight thread of execution (also known as user-space thread or fiber on WIN32). The API is modeled after boost.thread. Beside a scheduler (currently simple round-robin) for the fibers the library provides sync. primitives like mutex, condition- and event-variables (auto-reset, manual-reset, count-down). Message can be passed between fibers via bounded-/unbounded-fifo. Some feedback would be nice. regards, Oliver

5 15

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Thomas Klimpel said: >> I don't know whether I understand your concerns. >> I'm just not sure that it >> will be easy to agree on a set of core >> libraries. If it were just the official boost libraries >> themselves, it would at least be easy to figure out >> which library must necessarily be considered as >> "core". But you will never know exactly which boost >> libraries are used by closely boost related projects, >> like the libraries in the sandbox. For them, the >> official release boost libraries present the "core" >> libraries, and the other sandbox libraries are the >> experimental ones (and as Glas shows, it is quite >> possible that there is even a dependence to another >> experimental library). My major concern is about how to encourage continued innovation. Having potential libraries languish in the review queue for many many months, in some cases, years, can't be a good thing for getting people to want participate in boost. Think about all the people behind the scenes that see the review queue and say, why bother, its too cumbersome. There are alot of good ideas out there, but they need a place to get some exposure, and to flush them out. Debian has demonstrated that a stable and a non-stable branch can be quite successful. Boost should adopt a similar approach.

2 1

Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Continued from "Shouldn't both logging proposals be reviewed in the same formal review" Vladimir Batov said: > People will eventually start asking to distribute boost in parts, where > the "core" libraries are separated from the "experimental" libraries. >>> Isn't it already the case? Just put yourself into the shoes of a project >>> manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come >>> over and say -- there is a library that does what we want. Your first >>> questions will be 1) quality? 2) will the lib. around long enough? 3) will >>> the interface be stable enough? 4) etc. >>> In that setting I suspect you'll steer clear from anything >>> "inspirational-only". > For boost to remain popular and successful, this issue will eventually > have to be addressed. Fortunately, it probably does not need to be > addressed for a few years. >>> I'll probably have to disagree. I'd be more likely leaning towards >>> "addressed now". I'm actually sympothetic with your point of view and you've certainly made some strong points. My experience has been similar. Nevertheless, no matter how much you wish boost was something different, Boost's mission statement is pretty clear. I dont see that changing anytime soon. You should know that my favorite development library is Gnome (GLIB). http://library.gnome.org/devel/glib/2.22/ Its a very different library, its mission statement clearly states different priorities. Granted its a 'C' library, but its the library that my teams turns to for most of our programming needs. Its not community based like boost is. Not much original thinking is done their, its all about being practical, minimilistic and writing tight code. Boost is different. The libraries here reach for the moon -- some succeed. Boost is where I come for inspiration and there has been some absolutly brillant successes. However, for practical day to day developer needs, I discourage doing too much advanced C++. Neverthless, boost needs to keep on pushing the envelope. Functional programming is the future and boost is where you come to see whats possible in that domain. I would hate to see that change. If boost's focus is switched to addressing the needs of day to day "average" programmers, I would loose interest. I want boost developers to continue to reach for the stars. If "average" developers happen to find boost useful, of course they can use it, but they need to appreciate where boost priorities have been and use it appropriately.

10 14

[thread] Bug sprint #3097 throwing destructor
by Vicente Botet Escriba 22 Nov '09

22 Nov '09

Ticket Description: thread::detach() and thread::~thread() could throw thread_resource_error while locking thread_info_mutex. Currently it is on windows only. Hi Anthony, A simple reading of the current code let me think that this bug has been solved. thread::~thread() { detach(); } void thread::detach() { release_handle(); } void thread::release_handle() { lock_guard<mutex> l1(thread_info_mutex); thread_info=0; } Do you agree? Best, Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint--3097-throwing-destructor-tp26467… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Review] GGL Review ends today, November 22nd
by Hartmut Kaiser 22 Nov '09

22 Nov '09

Hi all, The review of the Generic Geometry Library officially ends today, November 22nd. Please send in your reviews if you have not done so yet. If you need more time for your review, please get in contact directly with me to work out some individual schedule. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0