- Boost - lists.preview.boost.org

Bug Sprint Report for Monday, June 1st
by Marshall Clow 02 Jun '09

02 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Monday was a good day - lets keep it up! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[Bug Sprint] [fusion] tickets needing maintainer / OP attention
by Stjepan Rajko 02 Jun '09

02 Jun '09

The following fusion tickets are ready for maintainer action or feedback from the OP: #1404 - Unordered Fusion Map constructors * could use feedback from the OP (Dean Michael Berris) #1529 - Missing include statement * patch ready #1601 - distane of boost::tuple * patch ready, see comments #1614 - vector workaround needed for MSVC9 * could use feedback / test case from OP (François Barel) Stjepan

2 1

[task] - boost.task (replacement for boost.threadpool)
by k-oli＠gmx.de 01 Jun '09

01 Jun '09

Hi, boost vault (section 'Concurrent Programming' - http://www.boostpro.com/vault/) contains boost.task. It replaces boost.threadpool and provides a framework for parallel execution of tasks (launching task in the current thread, in a new thread, as sub-task or in a pool of threads). The code looks someting like this: std::string echo( std::string const& msg) { return msg; } void main() { boost::task::handle< std::string > h( boost::task::async( boost::task::new_thread(), boost::task::make_task( echo, "Hello World!") ) ); std::cout << h.get() << std::endl; } or long fibonacci_fn( long n) { if ( n == 0) return 0; if ( n == 1) return 1; long k1( 1), k2( 0); for ( int i( 2); i <= n; ++i) { long tmp( k1); k1 = k1 + k2; k2 = tmp; } return k1; } void main() { std::cout << "worker-threads running in default-pool == "; std::cout << boost::task::default_pool().size() << "\n"; boost::task::handle< long > h1( boost::task::async( boost::task::default_pool(), boost::task::make_task( fibonacci_fn, 10) ) ); boost::task::handle< long > h2( boost::task::async( boost::task::default_pool(), boost::task::make_task( fibonacci_fn, 5) ) ); std::cout << "fibonacci(10) == " << h1.get() << "\n"; std::cout << "fibonacci(5) == " << h2.get() << std::endl; } best regards, Oliver

2 3

[Bug Sprint] - Ticket #816 - duplicat initial members -> erase_key postcond. fail
by Larry Evans 01 Jun '09

01 Jun '09

This ticket now has a simple solution: https://svn.boost.org/trac/boost/ticket/816#comment:4 Since it just changes the docs, it won't break any code and will help avoid any complaints about the documentation when some user inadvertently includes duplicates in the args to set. Could this doc change be applied and the ticket closed? -Larry

1 0

float_mem_cast
by Steven Ross 01 Jun '09

01 Jun '09

There is one function necessary for users to be able to cast their own float types. Should it be in spreadsort.hpp or some separate header file? It seems silly to have a separate header file for it, but I guess it might be used on its own. //Casts a float to the specified integer type template<class Data_type, class Cast_type> inline Cast_type float_mem_cast(const Data_type & data) { //Only cast IEEE floating-point numbers, and only to a same-sized integer BOOST_STATIC_ASSERT(sizeof(Cast_type) == sizeof(Data_type)); BOOST_STATIC_ASSERT(std::numeric_limits<Data_type>::is_iec559); BOOST_STATIC_ASSERT(std::numeric_limits<Cast_type>::is_integer); Cast_type result; std::memcpy(&result, &data, sizeof(Cast_type)); return result; }

4 7

Second call: The Boost Bug Sprint is coming!!
by Marshall Clow 01 Jun '09

01 Jun '09

The boost bug sprint is coming! It starts _this_ Friday, May 28th, and runs through Sunday June 7th. The goal is to address a large number of open bugs/patches/feature requests in the Trac system at <http://svn.boost.org/trac/report/1>. There are currently 791 open tickets; we'd like to knock that number down _a lot_. What can you do? 1) You can fix bugs. * If you are a library maintainer, you can commit your fixes. ;-) * If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. 2) You can characterize bugs. * You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. * You can write test cases demonstrating the problem, and attach them to the Trac ticket. * You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." 3) You can test patches. * Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. * You can write test cases for the patches, and attach them to the ticket. 4) You can help implement new features. * There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). Every day during the bug sprint, I'll post the # of tickets modified/closed/opened on the previous day, as well as the total number of open tickets. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

14 34

Bug Sprint Report for Sunday, May 31st
by Marshall Clow 01 Jun '09

01 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Well, we've slowed down some, but we're still making progress. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Boost.Process article: Tutorial and request for comments
by Boris Schaeling 01 Jun '09

01 Jun '09

I've written an article about Boost.Process: http://www.highscore.de/cpp/process/ I've also fixed a few bugs in Boost.Process (which is now 0.31): http://www.highscore.de/boost/process.zip And the latest source code can also be found in the sandbox: https://svn.boost.org/svn/boost/sandbox/process/ For developers not familar with Boost.Process the article is a tutorial to get more easily started. For developers familiar with Boost.Process it is a request for comments. I've been looking at the big picture finally trying to find out where and how Boost.Process should be changed and in which direction it should move to become a complete library one day. As not everyone will read the entire article here are my thoughts: 1) Boost.Process is based on a few concepts like 'process' and 'context'. While those make sense there are other concepts where I wonder if they should be dropped: * 'executable' is the executable name which in practice must be a std::string. I think the original idea was to support numerous string types. This leads to the question how to support different Unicode encodings which I think is still unanswered in the Boost community. Other libraries, eg. Boost.Interprocess, simply stick to one string type (typically std::string). * 'handle' is the underlying native file handle of a stream (file descriptor on POSIX systems, handle on Windows). The concept is based on a class in the detail namespace of Boost.Process. There is just one class and it's not meant to be used by users of the library either. Thus I'm not sure what's the benefit of having an explicit 'handle' concept at all. 2) Environment variables must be sorted on Windows but not on POSIX systems. On Windows the type environment could be a typedef for std::map and on POSIX systems for std::unordered_map. Currently it's always a typedef for std::map. Is that ok? Should it be changed? Should a macro be provided in case developers want to use different typedefs? 3) Currently Boost.Process is really only useful for creating child processes. It's not possible for example to detect and iterate over other processes on a system. I guess Boost.Process should be enhanced here. Then one day the well-known utility 'ps' on POSIX systems could be implemented in Boost C++. Any comments? 4) When a process is created the standard streams (stdin, stdout and stderr) are closed by default. Is this a good choice? If it isn't what should happen otherwise? Inherting standard streams (which is the default behavior with fork on POSIX systems)? 5) Boost.Process requires to specify an absolute path to an executable which should be started. There is a helper function which returns the absolute path for an executable name (it uses the environment variable PATH). The question is if this should be done automatically if no absolute path is given? 6) When a stream of a child process is captured Boost.Process automatically creates a pipe. As pipes don't support asynchronous operations on Windows a named pipe is required (called FIFO on POSIX systems). Currently a macro must be defined to make Boost.Process use a named pipe on Windows. It might make more sense to enable developers to choose either a pipe or a FIFO explicitly - not only on Windows but on all platforms. Any comments? 7) It's possible to capture and access streams of a child process. Those streams are derived from std::istream and std::ostream and thus only support blocking I/O operations. Currently the underlying handle has to be fetched to initialize a generic I/O object from Boost.Asio to use asynchronous I/O operations. How should the library be changed to make it easier to use asynchronous I/O? 8) There is a method wait() which makes it possible to wait for another process to exit. Currently wait() is provided by the class child though. Shouldn't it really be defined by the class process (so you can wait not only for child processes to exit)? 9) As wait() blocks an asynchronous alternative should be provided. 10) The Windows-specific classes all start with win32_ (eg. win32_child). Wouldn't it make more sense to use windows_ instead (like windows_child) or a windows namespace? First other libraries use windows_ (see Boost.Interprocess). Second there should be no reason why a class like win32_child can't be used on a 64-bit Windows. Boris

4 10

Interest check: container with preallocated buffer
by Dmitry Vinogradov 01 Jun '09

01 Jun '09

Boost.Array offers constant size container with preallocated buffer, Boost.Optional provides from zero to one element. There are no STL container with preallocated buffer and it seems custom allocator does not help to do this with existing containers. Does any container exist to offer functionality like Boost.Array but allowing to store from 0 to N elements? Is there any interest in such container? PS. It's similar to fixed_string but as a generic container. -- Dmitry

9 23

[Bug Sprint] Ticket #315 (new Feature Requests) - Implement operator[] for Tokenizer
by Joel Falcou 01 Jun '09

01 Jun '09

https://svn.boost.org/trac/boost/ticket/315 Is there any objection in term of concept to give tokenizer this kin dof random access operator ? If no one is against that, I'll attach patch and test. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 3

[thread] #2739 shouldn't at_thread_exit work on the main thread?
by vicente.botet 01 Jun '09

01 Jun '09

Hi, Anthony, I have submitted a patch that makes a regression on the test test_tss. My patch was related to add a atexit call for the main thread when make_external_thread_data is called, but it adds also for the thread created with native threads. So the patch don't work. Is there a way to make a difference between the main thread and the others? BTW the test fails on cygwin gcc 3.6.4, could someone test it on Windows or Linux to see if this is specific to cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

3 9

[Bug Sprint] Ticket #2867 - Adding a get_expected_args member to format
by Joel Falcou 01 Jun '09

01 Jun '09

https://svn.boost.org/trac/boost/ticket/2867 This ticket has a working patch + test attached. Should be merged and closed. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 2

Tickets with patches & mpl::switch_
by Joel Falcou 01 Jun '09

01 Jun '09

Here is some ticket that already contains a valid patch and test * mpl::zip doesn't support metafunction use https://svn.boost.org/trac/boost/ticket/1992 * Various unused args warning removal in ASIO : https://svn.boost.org/trac/boost/ticket/1341 * Various gcc warning in numeric https://svn.boost.org/trac/boost/ticket/1338 Other things. I've submitted some MPL::switch_ correction and addition here: https://svn.boost.org/trac/boost/ticket/2249 Now I'm not sure if the fix is what switch was really about after second thoughts. So can soemoen confirm I didn't modified the intended semantic. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

1 0

[config] Deprecate/remove BOOST_NO_INITIALIZER_LISTS
by Daniel James 01 Jun '09

01 Jun '09

Hi, Once BOOST_NO_0X_HDR_INITIALIZER_LIST has been added to release, I think we should remove BOOST_NO_INITIALIZER_LISTS. It's confusing having both macros. BOOST_NO_INITIALIZER_LISTS is probably useless as it only indicates compiler support and initializer lists can't really be used without the header. I seem to be the only person who uses it, so it might be okay to just remove it immediately or if not, deprecate it and remove it in the next release. Does that sound okay? Daniel

3 5

Bug Sprint Report for Saturday, May 30th
by Marshall Clow 31 May '09

31 May '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 7:15 AM PDT 5/31: 763 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[Bug Sprint] Ticket #613 - boost/crc.hpp uses non-standard conforming syntax
by Joel Falcou 31 May '09

31 May '09

https://svn.boost.org/trac/boost/ticket/613 The bugs seems indeed to have disappeared on gcc 4+. Should we close this one ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 2

Re: [boost] [Modularization] A new approach to header modularization
by JOAQUIN M. LOPEZ MUÑOZ 31 May '09

31 May '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Beman Dawes [bdawes(a)acm.org] Enviado el: jueves, 28 de mayo de 2009 23:06 Para: boost(a)lists.boost.org Asunto: Re: [boost] [Modularization] A new approach to header modularization > > On Thu, May 28, 2009 at 10:53 AM, troy d. straszheim > <troy(a)resophonic.com> wrote: > > In no particular order: > > > > - There is still the toplevel filesystem.hpp and friends to deal with. > > The way to deal with that is to migrate those to within the library's > header directory. > > As boost grows, filling the boost/ with headers becomes less and less > attractive. I don't see why this is less attractive than having boost/ filled with folders. > Of course we have to leave the current headers there for > compatibiltiy, but that location could be deprecated and eventually > only <boost/filesystem/filesystem.hpp> supported. *This* is less attractive to me; I think a Boost lib is entitled to have at least one top level header; many use it to include all or the the most usual components. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[Bug Sprint] - Ticket #2599 - corner case in boost::fusion::all
by Joel Falcou 31 May '09

31 May '09

https://svn.boost.org/trac/boost/ticket/2599 This ticket contains a working patch and should be merged/closed. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 1

Patches on tickets #3050 and #3051
by Marshall Clow 31 May '09

31 May '09

I tested these patches on darwin (gcc 4.0.1). They didn't break anything; which is not really surprising, since they are merely ifdef-ing out code on some systems - but not on darwin. If anyone builds with BOOST_NO_IOSTREAM and/or BOOST_NO_TYPEID, I would appreciate it if you could test out these patches. Thanks in advance! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Can someone (using Windows) check ticket #316?
by Marshall Clow 31 May '09

31 May '09

It's hard to tell, but those look like Visual Studio warnings. If they no longer exist, that ticket should be closed. If they do still exist, they should be looked into. <https://svn.boost.org/trac/boost/ticket/316> Thanks! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 4

Phoenix Reloaded
by Eric Niebler 31 May '09

31 May '09

I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. To that end, I have ... ... created a Wiki page for coordinating our efforts: https://svn.boost.org/trac/boost/wiki/BoostPhoenix3 ... created a branch at branches/phoenix_v3. Anybody interested in helping out or just following along should do the following from BOOST_ROOT (trunk): cd boost svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/boost/phoenix cd ../libs svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/libs/phoenix There is nothing in boost/phoenix right now but stub headers, and libs/phoenix is simply copied from trunk/libs/spirit/phoenix. On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some ideas I have about what Phoenix-on-Proto might look like. Feedback is welcome. -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 14

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, > I > think there is interest for such a feature, especially if > you are willing to > maintain it on regular basis. If there is an interest in it and, it would be accepted I'd be glad to continue supporting it on regular basis. Probably it may be integreted with regeression test to ensure that Boost still works after renaming. > If we do expect all > possible users to have Python > installed, it may be nice to use python for this. But > how do you propose to > integrate with bcp? 1. First of all this script is "one time use" and it is targeted for mostly project maintainers/managers that need to solve name collision problems. So, if it is not a big price to install Python to run such script, especially that it is availible by default for most supported platforms, like Solaris, FreeBSD, Linux, with an exception of Windows where in can be easily installed. So I don't see a real problem in using Python for this purpose. In any case there are already some Perl scripts are used for code generation. (See Boost.Asio for example) 2. I don't see it as a part of BCP but rather the tool that can be used together, like: bcp --boost=/path/to/boost bind.hpp regex asio my_boost_dir boost_rename.py my_boost_dir mybst Because it can be actually applied on full Boost tree, if someone wants its full version. Artyom > -- > Bjørn Roald > > > On Saturday 30 May 2009 10:55:25 am Artyom wrote: > > Hello, > > > > Some updates: > > ------------- > > > > 1. Added copyright - Boost License. > > 2. Some more regression tests passed, some code > cleanup > > > > Questions: > > ---------- > > > > 1. How can I submit it as an addon to BCP utility? > > 2. Have anybody tested it, I'd like to see if there > any problems, > > especially on Windows platform -- I > hadn't tested it there. > > > > > > Thanks > > Artyom > > > > P.S.: The source is there http://art-blog.no-ip.info/files/rename.py > > > > --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> > wrote: > > > From: Artyom <artyomtnk(a)yahoo.com> > > > Subject: [BCP] Script for global renaming Boost > Namespace > > > To: boost(a)lists.boost.org > > > Date: Monday, May 25, 2009, 11:14 AM > > > Hello, > > > > > > Today Boost does not provide any backward binary > > > compatibility. This > > > makes big problems in shipping 3rd part libraries > that > > > depend on Boost > > > because library user must use the same version of > Boost as > > > that 3rd > > > part library was compiled with. > > > > > > The problem is become even more critical for ELF > platforms > > > (UNIXes) > > > where all symbols are exported by default. > > > > > > I had written a small Python script that switches > boost > > > namespace > > > to other, allowing 3rd part project include it > without > > > collisions > > > with primary Boost namespace. > > > > > > The script passes over the source tree of boost > and changes > > > each > > > include path from <boost/foo/bar.hpp> too > > > <newnamespace/foo/bar.hpp> > > > and renames all macros and identifiers from > > > some_BOOST_something to > > > some_NEWNAMESPACE_something and > some_boost_something to > > > some_newnamespace_something. > > > > > > It does not touch comments (copyright) and > strings unless > > > the string > > > is in form "boost/.*" which is usually some > reference for > > > include. > > > > > > I've run this script on the 1.39 version of boost > and > > > successfully build full boost release and run > some of > > > regression tests > > > like Boost.Asio, Boost.Regex, Boost.Function and > others, > > > > > > The source code is available at: > > > http://art-blog.no-ip.info/files/rename.py > > > > > > You run it as: > > > > > > ./rename /path/to/boost/source > > > new_namespace_name > > > > > > It renames all macros and namespaces to new > namespace, and > > > renames > > > main include directory to new_namespace_na,e. > > > > > > Few points: > > > > > > 1. It is only alpha version script, I just want > to see > > > feedback and > > > proposals > > > 2. I do not update build scripts. I assume that > each > > > library that > > > tryes to import its own version of > Boost > > > would provide its own > > > build system. > > > 3. The build scripts should be updated > differently because > > > they have > > > different syntax and grammar. The > > > required changes are to > > > fix different build defines > > > > > > Please, give feedback proposal. If there someone > who is > > > familiar > > > with Boost.Build systems can actually help, this > would be > > > very good. > > > > > > Today there is a big problem with working with > different > > > versions of > > > Boost. It should be solved. > > > > > > I think this script may be a valuable addition > to > > > Boost.BCP utility > > > that allows extracting a subset of boost for > integration in > > > 3rd part > > > tools and libraries. > > > > > > Thanks, > > > Artyom > > > > > > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

mingw help
by Vladimir Prus 30 May '09

30 May '09

We have two issues: https://svn.boost.org/trac/boost/ticket/1907 https://svn.boost.org/trac/boost/ticket/2181 that claim the the names of library files on mingw are wrong. Unfortunately, the picture is not exactly clear, and it's not even clear what the right naming would be. I'd appreciate if somebody who actually uses mingw could clarify these points: 1. Currently, we use the same naming on mingw as on windows -- foo.dll and foo.lib for shared libs and import libs, and libfoo.lib for static library. Is this OK? 2. Are the search rules listed in tools/build/v2/tools/gcc.jam around line 657 matching the reality? 3. Is naming in (1) compatible with using -Bstatic to request static libs? Thanks, Volodya

3 4

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, Some updates: ------------- 1. Added copyright - Boost License. 2. Some more regression tests passed, some code cleanup Questions: ---------- 1. How can I submit it as an addon to BCP utility? 2. Have anybody tested it, I'd like to see if there any problems, especially on Windows platform -- I hadn't tested it there. Thanks Artyom P.S.: The source is there http://art-blog.no-ip.info/files/rename.py --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> wrote: > From: Artyom <artyomtnk(a)yahoo.com> > Subject: [BCP] Script for global renaming Boost Namespace > To: boost(a)lists.boost.org > Date: Monday, May 25, 2009, 11:14 AM > Hello, > > Today Boost does not provide any backward binary > compatibility. This > makes big problems in shipping 3rd part libraries that > depend on Boost > because library user must use the same version of Boost as > that 3rd > part library was compiled with. > > The problem is become even more critical for ELF platforms > (UNIXes) > where all symbols are exported by default. > > I had written a small Python script that switches boost > namespace > to other, allowing 3rd part project include it without > collisions > with primary Boost namespace. > > The script passes over the source tree of boost and changes > each > include path from <boost/foo/bar.hpp> too > <newnamespace/foo/bar.hpp> > and renames all macros and identifiers from > some_BOOST_something to > some_NEWNAMESPACE_something and some_boost_something to > some_newnamespace_something. > > It does not touch comments (copyright) and strings unless > the string > is in form "boost/.*" which is usually some reference for > include. > > I've run this script on the 1.39 version of boost and > successfully build full boost release and run some of > regression tests > like Boost.Asio, Boost.Regex, Boost.Function and others, > > The source code is available at: > http://art-blog.no-ip.info/files/rename.py > > You run it as: > > ./rename /path/to/boost/source > new_namespace_name > > It renames all macros and namespaces to new namespace, and > renames > main include directory to new_namespace_na,e. > > Few points: > > 1. It is only alpha version script, I just want to see > feedback and > proposals > 2. I do not update build scripts. I assume that each > library that > tryes to import its own version of Boost > would provide its own > build system. > 3. The build scripts should be updated differently because > they have > different syntax and grammar. The > required changes are to > fix different build defines > > Please, give feedback proposal. If there someone who is > familiar > with Boost.Build systems can actually help, this would be > very good. > > Today there is a big problem with working with different > versions of > Boost. It should be solved. > > I think this script may be a valuable addition to > Boost.BCP utility > that allows extracting a subset of boost for integration in > 3rd part > tools and libraries. > > Thanks, > Artyom > > > >

2 1

[Conversion] Looking for a review manager
by vicente.botet 30 May '09

30 May '09

Hi there, I'm looking for a review manager for the new Conversion library. Anyone around here who would like to volunteer? "Generic explicit conversion between unrelated types: generic convert to and assign to functions which can be specialized by the user to make explicit conversion between unrelated types + partial specialization for std::complex, std::pair, boost::optional, boost::rational, boost::interval and between boost::chrono::time point and boost::ptime and between boost::chrono::duration and boost::time duration" Waiting for that any comments on the library is welcome. You can retrieve it from https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conv… Regards, _____________________ Vicente Juan Botet Escribá

1 0