- Boost - lists.boost.org

[interhreads] Could not build the documentation
by Edward Diener 16 Jan '11

16 Jan '11

When I attempted to build the docs for the interthreads library up for review I received: "C:\Programming\VersionControl\sandbox\interthreads\libs\interthreads\doc\interth reads.qbk:1: warning: Invalid attributes for 'article document info': purpose, category reference/act_traits.qbk: error: Could not open input file. reference/fork.qbk: error: Could not open input file. reference/fork_after.qbk: error: Could not open input file. reference/fork_all.qbk: error: Could not open input file. reference/wait_for_all.qbk: error: Could not open input file. reference/wait_for_any.qbk: error: Could not open input file. reference/algorithm.qbk: error: Could not open input file. reference/wait.qbk: error: Could not open input file. reference/wait_until.qbk: error: Could not open input file. reference/get.qbk: error: Could not open input file. reference/is_ready.qbk: error: Could not open input file. reference/has_value.qbk: error: Could not open input file. reference/has_exception.qbk: error: Could not open input file. reference/wait_all.qbk: error: Could not open input file. reference/wait_all_until.qbk: error: Could not open input file. reference/get_all.qbk: error: Could not open input file. reference/are_all_ready.qbk: error: Could not open input file. reference/have_all_value.qbk: error: Could not open input file. reference/have_all_exception.qbk: error: Could not open input file. reference/detach.qbk: error: Could not open input file. reference/joinable.qbk: error: Could not open input file. reference/join.qbk: error: Could not open input file. reference/join_until.qbk: error: Could not open input file. reference/interrupt.qbk: error: Could not open input file. reference/interruption_requested.qbk: error: Could not open input file. reference/detach_all.qbk: error: Could not open input file. reference/join_all.qbk: error: Could not open input file. reference/are_all_joinable.qbk: error: Could not open input file. reference/join_all_until.qbk: error: Could not open input file. reference/interrupt_all.qbk: error: Could not open input file. reference/interruption_requested_all.qbk: error: Could not open input file. reference/basic_threader.qbk: error: Could not open input file. reference/launcher.qbk: error: Could not open input file. reference/threader.qbk: error: Could not open input file. reference/scheduler.qbk: error: Could not open input file. reference/typeof/futures.qbk: error: Could not open input file. reference/typeof/launcher.qbk: error: Could not open input file. reference/typeof/threader.qbk: error: Could not open input file. reference/typeof/basic_threader.qbk: error: Could not open input file. reference/typeof/scheduler.qbk: error: Could not open input file. reference/asynchronous_executor_decorator.qbk: error: Could not open input file. reference/basic_threader_decorator.qbk: error: Could not open input file. reference/launcher_decorator.qbk: error: Could not open input file. interthreads.qbk: error: Error count: 43."

3 5

Re: [boost] [General] Always treat std::strings as UTF-8
by Artyom 16 Jan '11

16 Jan '11

> From: Dave Abrahams <dave(a)boostpro.com> > > Peter Dimov wrote: > > > > Alexander Lamaison wrote: > > > I'm opposed to this strategy simply because it differs from the way > > > existing libraries treat narrow strings. > > > > It differs from them because it's right, and existing libraries are > > wrong. Unfortunately, they'll continue being wrong for a long time, > > because of this same argument. > > Does the "right" strategy come with some policies/practices that can > allow it to coexist with the existing "wrong" libraries? If so, I'm > all +1 on it. > Combining old libraries with new ones: ====================================== It would be simple to combine a library that uses old policies with new ones. namespace boost { std::string utf8_to_ansi(std::string const &s); std::string ansi_to_utf8(std::string const &s); std::wstring utf8_to_wide(std::string const &s); std::string wide_to_utf8(std::wstring const &s); } - If it supports wide strings call boost::utf8_to_wide **under Windows platform** and nothing is lost. - If it supports only narrow strings: a) if it is encoding agnostic: like some unit-test that only open files named with ASCII names, then you can safely ignore and pass UTF-8 string as ASCII and ASCII as UTF-8 as is the subset of it. b) Do following: 1. Fill a bug to library owner on not-supporting Unicode strings under Windows. 2. Use utf8_to_ansi/ansi_to_utf8 to pass strings to this library under Windows. Current State of Using Wide/ANSI API in Boost: ============================================== I've did a small search to find which libraries use what API: Following use both types of API: ------------------------------- thread asio system iostreams regex filesystem According to new policy they should replace ANSI api by wide api and conversion between UTF-8 and UTF-16 Following libraries use only ANSI API -------------------------------------- interprocess spirit test random The should replace their ANSI api by Wide one with a simple glue of utf8_to_wide/wide_to_utf8 Following libraries use STL functions that are not aware of unicode under windows --------------------------------------------------------------------------------- std::fstream - Serialization - Graph - wave - datetime - property_tree - progam_options fopen - gil - spirit - python - regex Need to replace with something like: boost::fstream and boost::fopen that work with UTF-8 under windows. The rest of the libraries seems to be encoding agnostic. Artyom

5 10

Re: [boost] Compiler error in gcc3+ involving template template parameter and default parameters
by Brent Spillner 16 Jan '11

16 Jan '11

On 01/15/2011 10:41 PM, Edward Diener wrote: >I am showing this gcc3 bug just in case any other Boost developer has >run into it and knows some easy workaround. It will save me some time as >the workaround in the actual case, which is more complicated, is very >laborious as I envision it ( I have not yet attempted to code up the >laborious workaround ). I ran into this type of case as the problem in >my tti library which is keeping it from supporting gcc3+. Your sample code compiles for me without errors or warnings (other than the unused variable) under GCC 4.4.4 and 4.5.2. Is there a particular GCC version that you need to support? In my experience GCC versions before 4.4 have badly broken template support and should be avoided if at all possible. >I am looking for a workaround for gcc3+ compilers which does not involve >getting rid of the default parameters. If I remove the default >parameters, and change the instantiation of tkf to: I would start by removing the "template<class>" / "template<class, class>" specifications on the dependent types F. Those may be what sent you into a poorly-tested and bug-ridden corner case in whichever release of GCC you're using, and should be unnecessary--- the compiler will not be able to instantiate the base class F<typename P1::type> when F requires two parameters, nor F<typename P1::type, typename P2::type> when it accepts only one, and should SFINAE to the proper case. If you do need those explicit constraints on F to work around problems in GCC 3 or another compiler, and it's feasible to nest a new typedef into all types that are legal as the F argument of eval<>, you could construct something like template <class T, class P = noparam> struct ptmf { typedef int type; typedef ptmf<T, P> is_unary; }; template <class T, class P1, class P2> struct other { typedef int type; typedef other<T, P1, P2> is_binary; }; template <template<class> class F, class P1> struct eval<F<P1> > : typename F<typename P1::type>::is_unary {}; template <template<class,class> class F, class P1, class P2> struct eval<F<P1, P2> > : typename F<typename P1::type, typename P2::type>::is_binary {}; If you need to support F types to which you can't add typedefs, you'll have to use the template <class F> struct F_traits{} pattern to provide ::is_unary, ::is_binary, etc.

2 1

GIL io_new review
by Lubomir Bourdev 16 Jan '11

16 Jan '11

First I apologize for not being active in the past several years in the Boost community due to time constraints. I only had a few hours to do this review, but I also reviewed Christian's code a couple of years ago. When we introduced GIL to Boost I was hesitant to include the I/O extension in the Boost submission. I felt that doing the I/O right is a major project and it is better to do it right or not at all. However, without any I/O support it would be very hard to use GIL, so we had to include some I/O extension that provides reasonable support for common formats. Christian has been (and still is) very passionate to make the next generation I/O. He started working on this at least four years ago and have been improving and polishing the code ever since. The problem with I/O is that you can never declare success. There are an unlimited number of file formats, back-ends, ways to read and write the image, image representations, compression settings, etc. For each of these one needs to deal with completeness, performance, test cases, failure modes, platform dependencies... All we can hope for is push the boundary as much as we can, and leave the rest for the next update. What is important in the first release is to get the design right. Once we have a solid foundation we can add a lot of functionality quickly and transparently. Domagoj had some constructive criticism so I will start with that. On the issue of using classes vs free functions, I don't think there is a huge difference either way. The the new_io code borrows the style from GIL, which uses free functions as algorithms (if you call I/O "algorithms"). GIL in turn borrows this style from the STL. Using functions one can extend functionality with overloading (but there are ways to do this with classes too) and it is nicer to be able to read/write a file with one line, without having to first construct a reader/writer and then call it. But these are minor quibbles. On the issue of performance, I don't think one test with one file format being 30% slower proves that there are serious performance issues. My guess is that Christian has been focusing on adding functionality and never got around to work on performance improvements, which usually means that we can get a lot of speedup by doing some simple optimizations in the inner loops. On the issue of using/not using streams, I don't have a strong opinion, except that stream support for I/O was one of the highest requested functionalities in GIL's review. Domagoj, you should have been more vocal at that time. Christian simply responds to the wishlist of the Boost community. In general, I feel that performance might be a bit overhyped in recent discussions. The image I/O operations are often dominated by disk access and by compression, etc. I don't think avoiding a copy of the pixels would make much of a difference in the majority of uses. That said, we do want to make sure GIL I/O is as fast as it can be. On the issue of supporting different backends, I agree with Domagoj that this is important and we should make sure to support it. In Christian's design everything is done in reader and writer classes, which are currently specialized for a specific file format and backend. One could imagine creating classes for other backend+file format combinations without much (any?) changes to the current design. The reader/writer files from the same backend could have common base classes or share functionality in other ways as appropriate. - What is your evaluation of the design? The design is fine, but I would like the requirements for adding new file formats / backends to be made more explicit. Specifically we want a concept for a file format reader/writer/etc and adding new file formats would constitute providing models for these concepts. - What is your evaluation of the implementation? It looks fine but haven't played with it much. - What is your evaluation of the documentation? The documentation is adequate, but requires cleanup and fixing of lots of typos. - What is your evaluation of the potential usefulness of the extensions? Very useful. However, there is some missing functinality which in my opinion is important to have: 1. The ability to read an image without specifying the file format at compile time 2. The ability to support multiple back-ends 3. The ability to efficiently read/write an image in parts - Did you try to use the extensions? With what compiler? Did you have any problems? I did not do anything non-trivial with them. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 3 hours looking at the code (but I reviewed a verion about 3 years ago) - Are you knowledgeable about the problem domain? I am familiar with GIL but not very much with file format libraries. - Do you think the extensions should be accepted as a part of Boost.GIL library? Let us consider our options carefully. We could do a "reject" on the basis that there is another alternative libarary (Domagoj's library). I don't think this is a good idea. I looked briefly at his library; there are things I like about it but also things I don't. There are certainly a lot of things that are missing. I will refrain from discussing it because it is not under review but the point is that in its current state it is not superior to what Christian has. Domagoj can improve his library further, but so can Christian, and Christian has been working on this for four years now and had submitted his library for review long time ago. This is a huge effort on behalf of Christian, he produced some great and very useful work and a reject will be demoralizing after so many years of work, and is unjustified given that fundamentally he has the right design. We could do an "accept". I would be ok with this, but there is some important functionality that is missing and adding it will require moderate work and some changes to the interface So my recommendation is "conditional accept" after the above identified must-have functionality has been added, specifically: - Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the filename. - Support for different backends. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. It is not immediately obvious to me why this would be a bad design choice; if someone disagrees they should elaborate. - Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. I'd like to hear the opinion of people who would use this more advanced options. My preference is that Christian joins forces with Domagoj to collaborate on these and take the best of their libraries to gil.io. Looks like Domagoj also spent a lot of time and effort on this problem and has gained a lot of valuable intuition. I don't want to see his efforts go to waste either. Other todo items: - Improve the language in the documentation section. - Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. - Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. - Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. Finally, here is an idea that I like, but may be too much work to do in the current release: I would like to have a GIL virtual image view associated with a given file. That would allow reading/writing to simply be copy_pixels, and reading into a different format to be copy_and_convert_pixels. Reading a given ROI could simply be done by creating a subimage_view. The cool thing about this is one could in theory make changes to images without even loading them in memory. The caviat is that doing this right and efficiently is very hard, requires clever caching, plus a wrong access pattern can result in horribly bad performance. Lubomir

5 20

[ratio] namespace ratios
by vicente.botet 16 Jan '11

16 Jan '11

Hi, Before moving all the classes on Boost.Ratio from boost:: to boost::ratios:: I wanted to signal that Boost.Ratio follows the names on the C++0x standard and that these names where choosen to be used in the std context and that any class is prefixed by ratio_. If a specific ratios namespace were in their minds, I'm sure that they will not use the ratio_add<> but just add<>. Please let me know if I'm wrong here. typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::add<R1, R2> R; If we put all of them in boost::ratios maybe the class names contains redundant information typedef boost::ratios::ratio<1, 2> R1; typedef boost::ratios::ratio<1, 3> R2; typedef boost::ratios::ratio_add<R1, R2> R; Do the Boost community agree with these names or is this one of the special cases that needs consideration? Best, Vicente

3 2

[tools/regression] compiler_status & library_status build error
by KTC 16 Jan '11

16 Jan '11

Executing bjam in tools/ fail to build library_status on trunk or release, and fail to build compiler_status on release. I'm guessing they still need to be fixed for Boost.Filesystem v3. KTC

1 0

[Creasing (Sequence Properties)] where is the documentation
by Edward Diener 16 Jan '11

16 Jan '11

For the Creasing (Sequence Properties) library up for review I do not see how to build any documentation, nor is there any documentation for it in the download.

1 0

[bitset] documentation does not build
by Edward Diener 16 Jan '11

16 Jan '11

Attempting to build the documentation for bitset, I get a bunch of errors: "C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1079 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p..\..\..\bin.v2\libs\integer\doc\msvc- 10.0\debug\threading-multi>bitfield.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-bitf ield.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-bitfi eld.xml.XML { bitfield.qbk.QUICKBOOK } } error: created from ./bitfield error: added properties: <preserve-test-targets>on <python-debugging>off <python >2.6 <threadapi>win32 error: removed properties: none C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1078.actualize from module object(file-target)@1078 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1087.actualize from module object(action)@1087 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1088.actualize from module object(file-target)@1088 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:811: in actualize-source-type from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:832: in actualize-sources from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:759: in object(action)(a)1092.actualize from module object(action)@1092 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:311: in actualize-action from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:499: in actualize-no-scanner from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:135: in object(file-target)(a)1093.actualize from module object(file-target)@1093 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:748: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module C:\Programming\VersionControl\sandbox\boost-build.jam:66: in module scope from m odule" The docs need to be buildable for anyone to use the library or be willing to review it.

1 0

[1.46] Release notes
by Daniel James 15 Jan '11

15 Jan '11

Hello all, Since the code freeze is coming up, it's time to write your release notes. If you want to add them yourself, you can edit 'boost_1_46_0.qbk' in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. I didn't get the new site building system ready in time for this release, so you should probably leave it to me to generate the html from your changes. Daniel

2 1

[Review] Dead link for Endian on the Review Schedule page
by Edward Diener 15 Jan '11

15 Jan '11

On the review schedule page at http://www.boost.org/community/review_schedule.html the link for Beman Dawes Endian library is dead.

1 0