- Boost - lists.preview.boost.org

[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

GGL Review
by Michael Caisse 22 Nov '09

22 Nov '09

Let me start by apologizing for the short amount of time I was able to put into this review. I have spent about 5 hours reviewing the documentation, looking at some of the source and trying a few examples of mine own. Clearly an enormous amount of work has gone into this library and I feel like it deserves more of my time than I am able to give right now. Nevertheless, I thought it important to review the most critical portions of the library. Based on the library review announcement, GGL is promoting key concepts for describing geometries. Some algorithms are provided. As such, it seems to me that the interfaces and concepts are key and is what I have devoted my time to looking at. And now for the executive summary spoiler: I believe that this library offers well defined concepts for geometry. The design is sound and the extension capabilities appear to be reasonable based on my short trial. I found the interface and concepts to the library usable and therefore recommend acceptance of this library within Boost. That was a wordy way of saying it has a Yes vote from me. ===== What is your evaluation of the design? ===== I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library. ===== What is your evaluation of the implementation? ===== Very clean. Every file I opened and took a look at was readable and easy to follow. The directory structure is obvious and made exploring the library an easy feat. I would like to see ggl::exception inherit from boost::exception instead of std::exception. I was unable to spend time evaluating the implementations of algorithms in any detail. ===== What is your evaluation of the documentation? ===== I found the "Design rationale" section well written and quite applicable to the problem at hand. According to the review announcement: "GGL defines concepts for geometries and implements some algorithms on such geometries." As such, the concepts are paramount to the review and the design rationale provides more than tidbits about the underlying structure of the library. It provides the requirements for compliance to the concepts promoted by the library. Adding generality step-by-step while using a basic concept such as distance allows the reader to follow the logic behind the tag-dispatching and quickly see how extensions and modifications could be incorporated. I am not typically a fan of Doxygen generated docs for generic libraries. Much has already been said about this by other reviewers; however, I did not find the documentation as lacking as some have described. I think the current state is adequate for using the library and did not encounter any problems using the docs while writing my own small tests. I can see that some of the descriptions are a little terse and if I was trying to implement something more complex I might have questions. A few specific comments on the docs......................... design.html section "Return type" typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& G1 , G2 const& G2 , S const& strategy) -- should be -- typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& g1 , G2 const& g2 , S const& strategy) and inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& G1, G2 const& G2) -- should be -- inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& g1, G2 const& g2) design.html section "Multi" The comments at first confused me. They are correct but by the end of reading a whole page on type traits my eyes were getting tired. Perhaps something like this for clarification: struct distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…> < GeometryTag1, GeometryTag2, G1, G2, Strategy, false, // G1 is_multi result true // G2 is_multi result > ===== What is your evaluation of the potential usefulness of the library? ===== I think a library implementing generic geometry concepts is extremely useful in many domains. I think this library provides usable concepts for a geometry library with a design and implementation that allows extension to user types and algorithms. ===== Did you try to use the library? With what compiler? Did you have any problems? ===== I found that the examples did not compile using the normal method. I was using the boost_1_41_0 release. cd libs/ggl/example bjam release Changing the Jamfile include requirement to <include>../../.. makes it work fine. I compiled with VC8, gcc-4.3.3, and gcc-4.3.2 m68k-elf cross-compile. The cross-compiler is for a device without FPU and I will continue looking at this library for integer only calculations next week. gcc-4.3.3 spat a bunch of warnings about "use of C99 long long integer constant" from boost/integer_traits.hpp. Not a GGL issue. The 03_polygon_example.cpp tickles some uninitialized warnings with gcc-4.3.3 that originate from intersection.hpp. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== I spent about 5 hours reviewing the library with a careful read of the Main Page, Design rationale, Spatial set-theoretic operations, and Relation to Boost and std libraries. I also looked over the source code, examples and implemented my own small test cases. ===== Are you knowledgeable about the problem domain? ===== Somewhat. I spent almost 10-years working with GDS-II and other semiconductor mask formats. I worked on transforming data at the "server" level and writing microcode for very accurate and high speed rendering on custom hardware. I have about a year experience working with GIS data sets. I can appreciate the integer versus floating point discussion that has been going on. Different domains have very different requirements. Those who promote the idea that integer only is pointless or floating point is THE solution haven't worked in the other domains. One is not more important than the other; however, concepts described by a library should be able to adapt to either. This library obviously performs in the FP realms and I have no problem envisioning how to adapt types and algorithms to work with it for integer only problems. I hope to explore this domain further in the coming weeks with GGL. Thank you GGL team for your hard work. Thank you Hartmut for your willingness to manage this review. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[serialization][1.41] export.hpp should #include extended_type_info.hpp
by Marco Jez 22 Nov '09

22 Nov '09

Hi everyone. Header file <boost/serialization/export.hpp> has a dependency to <boost/serialization/extended_type_info.hpp>, because it defines the macro BOOST_CLASS_EXPORT_KEY2 which specializes the class template guid_defined<> which, in turn, is defined in extended_type_info.hpp. Perhaps export.hpp should #include extended_type_info.hpp? Regards, Marco

1 0

[build] Performance tests
by vicente.botet 22 Nov '09

22 Nov '09

Hi, I would like to execute some performance test with Boost.Build. Is there a way to force the execution of the tests without building the executables? Are there some examples of performance tests for some Boost libraries? Thanks, Vicente _____________________ Vicente Juan Botet Escribá

3 6

[property_tree]bug in serialization of json, when it process UTF8 encoding string with std::string.
by Qiu Yuzhou 22 Nov '09

22 Nov '09

Hi, Because char is singed in msvc, the ptree serialization code will truncate the value when it greater than 127. Patch for boost_1_41_0\boost\property_tree\detail\json_parser_write.hpp: 21a22,33 > template<typename Ch> > unsigned long to_unsigned( Ch ch ) > { > return static_cast<unsigned long>( ch ); > } > template<> > inline unsigned long to_unsigned<char>( char ch ) > { > unsigned char* p = reinterpret_cast<unsigned char*>( &ch ); > return *p; > } > 46c58 < unsigned long u = (std::min)(static_cast<unsigned long>(*b), 0xFFFFul); --- > unsigned long u = (std::min)(to_unsigned<Ch>(*b), 0xFFFFul); Patch for boost_1_41_0\boost\property_tree\detail\json_parser_read.hpp 141a142 > template<typename CH_T> 148,149c149,150 < u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<Ch>::max)())); < c.string += Ch(u); --- > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<CH_T>::max)())); > c.string += CH_T(u); 152a154,165 > template<> > struct a_unicode<char> > { > context &c; > a_unicode(context &c): c(c) { } > void operator()(unsigned long u) const > { > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<unsigned char>::max)())); > c.string += char(u); > } > }; > 250c263 < | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)] --- > | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode<Context::Ch>(self.c)] Best, Qiu Yuzhou

1 0

ACCU 2010 - Boost folks there ?
by Alp Mestan 22 Nov '09

22 Nov '09

Hi, I'm currently wondering whether I'll go to ACCU 2010 or not. But I just would like to know if any Boost folk will be there, and if there will be some talk or whatever, about Boost ? Thanks. -- Alp Mestan http://alpmestan.wordpress.com/ http://alp.developpez.com/

2 3

[fiber] version 0.1.1 available (incl. docs)
by Oliver Kowalke 21 Nov '09

21 Nov '09

I've uploaded a new version of boost.fiber - it contains the docs as requested. http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu… kind regards, Oliver

1 0

Boost.Python question about converters and make_getter
by John Wiegley 21 Nov '09

21 Nov '09

I have a converter registered for a boost::optional<amount_t> object. If I use it as follows, my code works just fine: boost::optional<amount_t> py_price(annotation_t& ann) { return ann.price; } class_< annotation_t > ("Annotation") .add_property("price", py_price) ; However, if I dispense with the intermediary and use make_getter, I get an exception stating that no conversion exists for optional<amount_t>: class_< annotation_t > ("Annotation") .add_property("price", make_getter(&annotation_t::price)) ; The attached file demonstrates this bug using Boost 1.40 and Python 2.6.1. I'm running it on OS X 10.6.2 with g++ 4.4.2. My steps were: g++-mp-4.4 -I/usr/include/python2.6 -I/usr/local/include/boost-1_40 -o bug.so bug.cc -L/usr/local/lib -lboost_python-xgcc44-d-1_40 -lpython -shared $ python >>> import bug >>> x = bug.Annotation() >>> x.price2 # This works just fine >>> x.price # This causes an abort() due to terminate() John

2 2

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

21 Nov '09

C++ is an for expert system and "boost" is a place for the most advanced users of c++ to share experiences. If you don't agree with that basic statement, we don't have much to talk about. I know that calling some one "average" at a particular skill is a loaded statement. It implies a sense of superiority that is uncomfortable to some. However, "average" only comes with a great deal of practice and hard work. Most of us, only ever become average at a handful of things in our life, if we are lucky. Actually, calling someone average at something is highly complimentary. If you are uncomfortable with the term "average", take your sensibilities elsewhere. No back to the issue at hand: Boost needs to separate out the core libraries from the experimental libraries. The libraries within boost that have stable api's should separated from those that don't. Boost needs a system similar to debains. People need to know what parts of boost are backwards compatible. At the same time, we need to allow for complete interface changes to the experimental libraries, to encourage and nurture those libraries that are still in active development, but still very usable. I don't see this as a difficult issue to comprehend at all. Its quite surprising to me that it gets so much push back. This is the single reason why so many people are so resistant to using boost. Hopefully somebody will take up this issue, as I fear without it, boost will become trivialized after the next release of the c++ standard. I'm just saying what people are thinking in the trenches. >From my perspective, as the former review wizard, and long time follower of boost, the current situation of having a dozen libraries in the queue, and probably a dozen more waiting behind the scenes is unacceptable. If we distributed those libraries currently waiting to be reviewed as part of the non-stable part of boost, we could be much more liberal about what libraries get accepted. The important review would then be determining when a library is going to be switched from the non-stable to the stable portion of boost. Tom Brinkman

2 1

[ANN] Elements of Programming study group
by David Abrahams 21 Nov '09

21 Nov '09

FYI, over at http://cpp-next.com we're running a study group on the new book by Alex Stepanov & Paul McJones that might be of interest to generic library authors and users.

2 1

[Ticket #3548] Comeau C++ reports global scope has no int64_t
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, I've been trying to diagnose and fix the problem with missing definition of int64_t and uint64_t when using Comeau C/C++ frontend on Linux 32-bit with GCC 4.x. I submitted all details to the Trac: https://svn.boost.org/trac/boost/ticket/3548 Shortly, the problem is that if <sys/types.h> header is included then <boost/cstdint.hpp> can't import uint64_t/int64_t types. However, if <stdint.h> is used, everything works. 1) Does compile with Comeau + GCC #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 2) 1) Does compile with Comeau + GCC as well #include <stdint.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 3) Does not compile with Comeau + GCC #include <sys/types.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } What I found is that there are slight differences, in GNU C Library, in how those integer types are defined: 1) <sys/types.h> # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif 2) <stdint.h> # else __extension__ typedef long long int int64_t; # endif More details are in the #3548 ticket report. Shortly, sys/types.h vs stdint.h are somewhat competing and seem to confuse <boost/cstdint.hpp> definitions. Both headers define __int8_t what disables the other definitions, thus depending on which header goes first, that one wins but with different effect regarding int64_t type. I exchanged a few e-mails with Comeau team about it and, as for this moment, we've concluded this slight differences between the two headers seem a bit odd and competing indeed. Comeau team has been very helpful and they are willing to make further investigation of this problem. In the meantime, I decided to report this issue to GNU C Library bugzilla (I should send to their mailing list first, my mistake): http://sourceware.org/bugzilla/show_bug.cgi?id=10990 Ulrich Drepper confirmed that this is not GNU C Library issue: "stdint.h is a C99 header and C99 demands the implementation of long long. The headers are correct." Fair enough. However, it makes it more difficult to me to understand where fixes should go. So, I'd like to ask the Community here for help in diagnosing this problem. My thought for now is that if Boost Integer is used with Comeau C/C++ frontend with GCC, Boost configuration could detect if <sys/types.h> was included first and try to disable its effects, like undefine __int8_t and only let int64_t and uint64_t definitions from <stdint.h> header. I believe that solving this problem is quite important to make Boost compilable with Comeau C/C++ frontend, because, as far as I've tested, it mostly leaks when compiling Boost.Test and tests of Boost libraries. I'd be thankful for any thoughts on this. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

1 0

Status of Comeau toolset for upcoming 1.41.0
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, Recently, I've reported [1] issues [2] related to building with Comeau toolset. The upcoming release info [3] does not mention Comeau toolset. May I ask what's the status of support of Comeau? Is it safe to assume Boost 1.41.0 will be usable with Comeau C/C++ ? [1] http://lists.boost.org/Archives/boost/2009/10/157410.php [2] https://svn.boost.org/trac/boost/ticket/3548 https://svn.boost.org/trac/boost/ticket/3558 [3] http://beta.boost.org/users/news/version_1_41_0 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 5

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

> If I had a library that only implemented quad-trees and then proposed > it as Boost.Generic Spatial Index, I would think the reviewers would > have something to say about that. > Please note that GGL is a "geometry library" implemented using "generic programming". Though we aim to a broad scope, we don't aim to "generic geometry" Barend p.s. (please make the To: of this thread: boost, and not boost-users)

2 2

Updating the Boost Review Process Was: [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 21 Nov '09

21 Nov '09

I propose these 3 changes (starting with the word ADD: below) to the current review policy in http://www.boost.org/community/reviews.html I realize that there is no mention to the word "vote" in the review policy, just "review comments". See message below for rationale on why these may be good changes. ----------------------------------- INTRODUCTION ... The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received from boost mailing list members. ADD: Consensus should be objectively measured with the votes and otherwise the right to accept solely by the review manager could be revoked. ... RESULTS At the conclusion of the comment period, the Review Manager will post a message to the mailing list saying if the library has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated. ADD: In conflicting reviews or with little consensus the Review Manager should justify way the library was accepted or not accepted. NOTES FOR REVIEW MANAGERS ... ADD: The review manager must not have or have had business ties with the library author/organization. ... ---------- Forwarded message ---------- From: Jose <jmalv04(a)gmail.com> Date: Mon, Nov 16, 2009 at 12:09 PM Subject: Re: [boost] [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale To: boost(a)lists.boost.org Hi, I am not expert in geometry but what matters is that boost continues to provide generic libraries (if possible !) like BGL, GIL, .. I think there is no blame on library authors which make a huge effort. What was broken is the review process, and some of the reasons why the review process was broken were: 1) The result of the review was 6 positive to 4 negative, when boost normally aims for consensus. This is the most objective point. Also, the issues the review manager was proposing to be fixed would not change the votes as the library was not appropiate even for 2D geo applications 2) The scope of GTL was changed before the review (see snippet 2 at the end) but the review docs still mention a wider app focus (see snippet 1 at the end). This confusion appeared when GTL was being reviewed. 3) The review manager didn't have time for the review (if you look at the apology at the beginning of the review email summary) 4) The GGL library proposal, which had been iterating the design with input from boost, in my opinion received an unfair treatment in the way the schedule was managed. 5) Boost failed to set the scope for a geometry library/ies and created tension with candidate library authors There are more points but I don't like long emails. I propose to change the current review process: http://www.boost.org/community/reviews.html ----------------- NOTES FOR REVIEW MANAGERS Decides if there is consensus to accept the library, and if there are any conditions attached. ----------------- AMENDMENT 1 that consensus should be objectively measured (with the votes) and otherwise the right to accept solely by the review manager could be revoked. Clearly there was no consensus in this library, and no clear discussion if one single library was possible (I understand your points that multiple libraries in this case may be preferable but still that is not incompatible with a complete design discussion) AMENDMENT 2 The review manager should have or have had no business ties with the library author/organization. Amendment 2 is not related to this review, but this would support the current transparency. I feel that in some cases there might be a vague prejudice in favor of big/important/known organizations to get their libraries accepted regards jose --------------------------------------------- Snippet from Boost.Polygon docs http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm "These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library." 7/19/09 I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. ------------------------------------------------

17 64

Fixing warnings - progress
by Paul A. Bristow 21 Nov '09

21 Nov '09

I've updated https://svn.boost.org/trac/boost/wiki/WarningFixes on progress we are making (a little effort would go a long way to fixing the remaining warnings) to show what has been fixed, and where we need more information, and more work. Please post information to be added, or edit the page yourself - it is a wiki after all ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

Hi Michael, Thanks for your review! I don't understand some of the problems you have had, so I'll explain or ask some things. > Some general thoughts: > > Integration with Boost.Units should be encouraged. I don't think > is_angle, etc should be in GGL. If I have a vector of quantities, > things should Just Work. > I think you mean is_radian, which is used internally to know if spherical coordinates are in degree's or in radian's. We didn't thought it a good idea, just for this one piece, to integrate with another boost library. Though for some coordinate systems it certainly would make sense (see also answer to Brandon's review) > As it is, Barend favors GIS, > Bruno favors gaming, and the resulting library is a mashup of GIS > terms and other arbitrary terminology and it excels in no one > particular area. > Thanks for your namespace suggestion in another thread. This will help to improve this. > > Yes. I spent a few hours trying to get it to with ESRI, a leader in > the GIS domain. Their API is completely COM based however, and it > proved extremely difficult to get working with GGL. I wasn't able to > successfully do this with Boost.Polygon either. > Yes, it would be very cool if this would work nicely, and it is meant to work. It is not clear to me if you get anything working, or nothing. However, I'll come back to you because it would be very useful if there is an example, showing integration between GGL and ESRI. > The Examples link at the bottom of the main page of documentation is > broken (last line), This was not a hyperlink (could be though, sorry) > and custom_point_example.cpp doesn't compile - > cs::cartesian needs to be ggl::cs::cartesian. > This surprises me. It is declared within a macro, so ggl namespace is not necessary there. I've not heard of this problem before, and it seems to compile fine normally for everyone (so I must now say: for most people). Are you sure? > It was not clear what includes I had to include to register my custom > point type. GEOMETRY_REGISTER_POINT_2D is defined in > ggl/geometries/register/point.hpp, but the following won't compile: > Normally, including <ggl/ggl.hpp> is enough, but indeed this should also compile, will be add the dependency. > It also doesn't appear that the custom point type can be in its own > namespace when using these registration macros. For instance, the > following doesn't compile: > > namespace foo { > struct test { > double x, y; > }; > } > GEOMETRY_REGISTER_POINT_2D(foo::test, double, ggl::cs::cartesian, x, y) > [...] I had to have "using namespace math" just to register my point correctly. > Yes, that was a known issue and should have been documented. We didn't search for the solution yet, it must be simple. > Using the haversine strategy caused compilation errors > because there was no overload of get_as_radian<>() for my point type. > > 1. It's not documented that the haversine strategy requires > get_as_radian, or at least I didn't see it. > Spherical coordinate systems use get_as_radian internaly (using is_radian), but it should never be necessary to overload it yourself. The normal procedure is registering your point as cs::spherical<degree> coordinate system. That would have been fine, and that was expected for the haversine function. You probably used cs::cartesian, and it didn't know if it was degree or radian. Anyway, I see your problem though, we will correct this and/or document this better. > I finally got haversine working with my point type by defining > get_as_radius as above, and the result was correct. I must say, it is a great workaround, nice that you got it working also like that. > This almost went smoothly, except that I had to specialize > strategy_tag, but didn't see any mention of this requirement in the > docs. Once I did that, my distance strategy worked and returned the > same value as haversine for values along the equator. > To be complete, the vincenty is also part of the gis extension, it was first not included, but later we wanted to show that 07 graph example, showing nicely the integration between BGL and GGL (there were not too many comments on this though). I understand that you implemented your own strategy, very cool. And indeed, you should specialize your strategy_tag, if (and only if) you want to use that one by default. Another way would have been that you specified the strategy as additional parameter. Great you got it all working like this! Of course, everything should work, but you did use some quite advanced features of GGL, and I like to see that you did succeed there. We will work on the documentation so these scenario's will cause less problems. Thanks again, Barend

1 0

Help needed in fixing warnings
by John Maddock 21 Nov '09

21 Nov '09

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! Cheers, John.

9 23

[1.41.0] iostreams/device/mapped_file.hpp has no include guards
by troy d. straszheim 21 Nov '09

21 Nov '09

making a trac ticket... -t

2 2