- Boost - lists.boost.org

Steps before moving to Subversion
by Beman Dawes 01 May '05

01 May '05

Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week. (I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.) Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first. Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository. Some of the possible tasks to be accomplished before a final conversion: * Research any remaining questions from Boosters regarding Subversion. * Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.) * Set up a trial repository, like the one Troy set up, but on the actual machine at IU. * Set up write authorization. This might be a good time to prune the write-access list to those still active. * Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?) * Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.) * Put change notifications in place. * Verify that backup (tarball or whatever) procedures are in place and functioning. * Update Boost documentation which refers to the source repository. * Schedule and execute the actual changeover. Comments? --Beman PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/

14 28

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 01 May '05

01 May '05

----- Mensaje original ----- De: Edward Diener <eddielee(a)tropicsoft.com> Fecha: Miércoles, Abril 27, 2005 10:25 pm Asunto: [boost] Re: [test][comeau] problem with va_list > JOAQUIN LOPEZ MU?Z wrote: > > Current tests for Comeau 4.3 show this problem: > > > > "G:\boost\boost/test/impl/test_tools.ipp", line 136: error #135: > > namespace > > "std" has no member "va_list" > > std::va_list args; > > > > Looks like va_list is not properly injected into std:: > > (yet BOOST_NO_STDC_NAMESPACE is *not* defined > > for this platform, and I guess for a good reason.) > > I've googled for this and found some discussions at the > > Boost list on the very same problem, with no definitive > > answer :( > > > > 1. Could anyone take a look at Comeau stdlib <cstdargs> > > and see what's going on? > > It is <cstdarg>, and in libcomo for Comeau 4.3.3 I see: > > #include <stdarg.h> > > namespace std { > > using ::va_list; > > } > > Comeau uses the back end compiler for the C headers, such as > stdarg.h, > although it provides a few of its own for various compilers > evidently to > make up for some compiler deficiences. I do not see any stdarg.h > among > the latter. What is the back end compiler being used for the > failing test ? > VC 7.1. The offending file seems pretty straightfoward (http://tinyurl.com/e27be) so I don't really have a clue what's going on... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 12

broken links in ublas docs
by John Maddock 01 May '05

01 May '05

Several of the ublas doc pages reference the file: libs/numeric/ublas/doc/c++boost.gif which does not in fact exist, I assume these links should point to boost.png now? Any chance of the authors fixing this up? Thanks, John.

1 0

Boost.Test and gcc-2.95
by John Maddock 01 May '05

01 May '05

I don't know if the following are fixable or not, but there are a few regex lib tests failing on gcc-2.95 with: In file included from /boost/head-regression/boost/boost/test/included/test_exec_monitor.hpp:27, from ../libs/regex/test/object_cache/object_cache_test.cpp:19: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp: At top level: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:37: redefinition of `struct io_saver_type' /boost/head-regression/boost/boost/test/impl/results_reporter.ipp:35: previous definition here /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:40: confused by earlier errors, bailing out Given that this is an old compiler can these be fixed without undue heroics? Thanks, John.

2 2

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Viernes, Abril 29, 2005 6:36 pm Asunto: Re: [boost] Re: [test][comeau] problem with va_list > Quoting Edward Diener <eddielee(a)tropicsoft.com>: > > For whatever reason, although #include <cstdarg> is in the > source file, > > when the Comeau compiler is executed it never actually includes the > > file. This must be a bug in the Comeau compiler but perhaps Greg > Comeau> has a fix for it. > > Do you have libcomo31 properly installed and built? Did you try > "Hello world" > using iostreams? > > Broneck, if I'm not wrong you have access to a properly setup Comeau environment. It'd be great if you could apply a patch to your local version of boost/test/impl/test_tools.ipp and see what happens. The patch reduces to issuing a namespace std{using ::va_list;} for the Comeau compiler. If this works, a lot of tests that are currently failing because of this single problem could clear up (or at least progress to some further error.) If the patch works, there's still the issue of tuning the workaround: is it a problem with all versions of stdlibcomo, under any backend? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

Re: [boost] Re: Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Sábado, Abril 30, 2005 8:32 pm Asunto: [boost] Re: Re: [test][comeau] problem with va_list > > 1. Replace <cstdarg> with <stdarg.h> > > 2. Remove std:: qualifications for all entities belonging > > to <cstdarg> > > Done. Committed in cvs. > > Gennadiy Thank you! Let's see if this improves regression results on the next turnaround. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Sábado, Abril 30, 2005 5:13 pm Asunto: Re: [boost] Re: [test][comeau] problem with va_list > Edward Diener wrote: > > Bronek Kozicki wrote: > >> Edward Diener wrote: > >>> void test() { std::va_list avar; } > >> isn't "va_list" a C macro? > > No, it is a standard type. > > it's not a shame not to use it in C++ programs, thus I'm not > ashamed not > knowing this detail ;) Anyway, I think that my program > demonstrates > workaround. > Does this improve the general regression tests? If so, please by all means apply the patch to the CVS. I'd suggest you follow the formulation of Peter Dimov: 1. Replace <cstdarg> with <stdarg.h> 2. Remove std:: qualifications for all entities belonging to <cstdarg> It is extremely unlikely that whis can cause regression for other compilers, so IMHO it is the safest bet. Thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[polity_ptr]smart_ptr_test passes, but with SIGSEGV during "clean-up"
by Larry Evans 30 Apr '05

30 Apr '05

The test passes, but during program "clean-up", a segmentation violation occurs. Here's the gdb session: GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/sand-box/lje/libs/fields_visitor/test/gcc/debug/smart_ptr_test Running 13 test cases... *** No errors detected Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? () (gdb) bt #0 0x00000011 in ?? () #1 0x08083098 in boost::checked_delete<boost::unit_test::report_formatter> (x=0x80a8c00) at checked_delete.hpp:34 #2 0x0807dc75 in ~scoped_ptr (this=0x80a870c) at scoped_ptr.hpp:77 #3 0x4005339d in __static_initialization_and_destruction_0 (__initialize_p=0, __priority=65535) at ../../../../../libs/test/src/unit_test_result.cpp:297 #4 0x4005343a in global destructors keyed to _ZN5boost9unit_test16unit_test_result4Impl6m_headE () at ../../../../../libs/test/src/unit_test_result.cpp:599 #5 0x400435e0 in __do_global_dtors_aux () from /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/libs/test/build/gcc/debug/boost_unit_test_framework.so #6 0x4005d076 in _fini () from /home/evansl/prog_dev/boost-release/boost_1_32_0/bin.v2/libs/test/build/gcc/debug/boost_unit_test_framework.so #7 0x4000c4f6 in _dl_init () from /lib/ld-linux.so.2 #8 0x4019cae2 in exit () from /lib/libc.so.6 #9 0x40186dce in __libc_start_main () from /lib/libc.so.6 #10 0x08066151 in _start () at ../sysdeps/i386/elf/start.S:102 (gdb) up #1 0x08083098 in boost::checked_delete<boost::unit_test::report_formatter> (x=0x80a8c00) at checked_delete.hpp:34 Anyone else encounter this problem? David or Jonathan, I'll try to narrow the problem down (after all, it may be in the boost_unit_test_framework ), but just thought I'd give others a "heads-up".

2 2

Re: [boost] Re: como toolset failures
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Sábado, Abril 23, 2005 9:50 pm Asunto: Re: [boost] Re: como toolset failures > Rene Rivera wrote: > > > Is this specific files? > > > > I ask because there's already a facility in the como-win32 > toolset for > > removing the --a option by specifying that certain files with > > <no-warn>file.cpp > > I'd say that this problem seems to cripple most test results. But > not > all. The flag you mention should be set for all files that > directly or > indirectly include any of Windows headers. Which I suppose is > rather > large set of files. Maybe it would be good to temporarily (for one > or > two days) remove --a globally and then see results; my computer is > running tests continously. This would give some idea how many > errors > might be due to Windows headers included in strict mode. Obviously > this > will not resolve all problems ;) as como does not support DLLs, > which > also means that boost.thread won't work anyway. > > Before you do that, let me comment on this: the situation is probably not as bad as it seems --many libs are actually completely Windows-unaware and its associated tests fail only because they use Boost.Test, which internally includes some Windows headers. These libs are: algorithm/minmax algorithm/string assign crc disjoint_sets format functional/hash io iostreams lambda logic (tribool) math multi_array multi_index numeric/conversion numeric/interval pool property_map ptr_container random range regex serialization tokenizer tuple variant So, if we fix the problem with Boost.Test we'll get a much higher success rate. In its turn, the problem with Boost.Test seems to lie in that it includes (directly or indirectly, I don't know) the file boost/detail/interlocked.hpp, which fails as shown in http://tinyurl.com/73vvo. So I'd say fixing boost/detail/interlocked.hpp would drastically lower the failure count and would give us a much clearer view of where we really are wrt to Comeau support. Just my 2c. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

12 43

[pointer container] copyability
by David Abrahams 29 Apr '05

29 Apr '05

I had this disagreement with Thorsten in Lillehammer (or was it Oxford?) but he was unimpressed with my arguments. I was wondering what Boost as a whole would think: My Thesis: the library should support copying and assignment of pointer containers using the usual copy/assignment syntax, rather than only allowing a copy via a clone() function. Rationale: Not being able to copy and assign pointer containers is an arbitrary restriction that limits usefulness and expressivity. The argument Thorsten gives against copyability is that the elements would have to be clone()d rather than copied, which is expensive because there's a dynamic allocation per element. I don't get it; we don't arbitrarily prohibit copying of std::vector<std::string> even though that incurs a dynamic allocation per element. Example: Consider std::pair<int,some_pointer_container>. Almost nothing works. IIUC, it's not copyable, can't be initialized, and can't be clone()d. -- Dave Abrahams Boost Consulting www.boost-consulting.com

12 61