August 2004 - Boost - lists.preview.boost.org

Re: Copyright
by Vladimir Prus 27 Aug '04

27 Aug '04

David Abrahams wrote: > Vladimir Prus <ghost(a)cs.msu.su> writes: > > Could you clarify? To be exactly specific, if I have a file with the > > following content, as a part of Boost.Build test: > > > > int main() { return 0; } > > > > why does it need copyright? > > Files without copyrights make corporate lawyers nervous, and that's a > barrier to adoption. If everything in Boost is copyrighted, there > won't be any problem with dropping a Boost release on a corporate > server. *Any* file without copyright? What about 'boost.css' or 'c++boost.gif' for example? What about BoostBook DTD, which has the following: Copyright (c) 2002 by Peter Simons <simons(a)computer.org>. All Rights Reserved. What about tools/regression/xsl_reports/merger/__init__.py And, for a completely interesting question, whose copyright should be on 'status/explicit-failures-markup.xml'? Of all the authors? The reason I'm asking all this is that it seems that a lot effort was already spend to add copyrights, and more is likely to be spend and I find it hard to believe that lawyers will examine every single file of Boost. Maybe, just headers and the code which goes into compiled libraries really need to be license-clean. - Volodya

2 1

[program_options + test] Intel problem
by Vladimir Prus 27 Aug '04

27 Aug '04

The error message in http://tinyurl.com/6ynh9 says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand. Could any expert take a look? - Volodya

7 11

a problem with lambda expressions
by zaufi 27 Aug '04

27 Aug '04

Hi, everybody! We've got a problem with a following code that does not compile: -------------------------------------------------------------------------------------- #include <list> #include <algorithm> #include <boost/lambda/bind.hpp> int main() { using namespace boost::lambda; std::list<std::list<int> > l; bool some_are_empty = false; std::for_each(l.begin(), l.end(), var(some_are_empty) = bind(&std::list<int>::empty, _1) || some_are_empty); return 0; } ---------------------------------------------------------------------------------------- Compiler (gcc 3.4.1) gives the following errors: ---------------------------------------------------------------------------------------- lambda-problem.cc: In function `int main()': lambda-problem.cc:13: error: no match for 'operator||' in 'boost::lambda::bind(const Arg1&, const Arg2&) [with Arg1 = bool (std::list<int, std::allocator<int> >::*)() const, Arg2 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >](((const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&) (+boost::lambda::<unnamed>::_1))) || some_are_empty' lambda-problem.cc:13: note: candidates are: operator||(bool, bool) <built-in> -------------------------------------------------------------------------------------- Can anybody shed a light on what are we doing wrong in this example?

3 2

discrepancy between regression tests and manual testing
by Bronek Kozicki 27 Aug '04

27 Aug '04

While examining some error in regression tests I have noticeed that this error does not appear when I'm starting bjam in "test" directory of library. It does however appear in regression test. Reason for this discrepancy is that regression tests are always started from boost/status/Jamfile , and this Jamfile contains number of settings for specific tests ; thus when test started from different Jamfile (like the one in test directory) these settings are not applied, effectively both Jamfiles produce different results. I hope it's possible to move all these library-specific settings into specific Jamfiles in test directories? Right now it might be quite difficult to fix regression errors for someone not willing to run full regression tests. B.

1 0

Re: mingw test results
by John Maddock 27 Aug '04

27 Aug '04

> >I've been looking at your regression test results for mingw: > > > >config_test and all the regex tests are failing with a runtime exit code of > >128, however they pass for me here, and for some of the other testers as > >well (see the Bronek Kozicki results). Do you have any idea what's > >happening here? If you can get a stack backtrace for the problem that's > >happening in config_test that would be a big help. > > I re-compiled the test (config) using dev-cpp (which is the mingw I'm > using) and ran the test manually AND with the debugger > error_count (and what gets returned) is clearly 0 in both runs. > > apparently there is some hiccup w/ the interface to the boost test fixture. > I'll be happy to debug there if someone can give me a hint where to start. Not sure, but you could try: bjam -a -d2 config_test which may indicate some kind of difference between what bjam is doing, and what your manual builds are doing; then again it may not :-( Thanks! John.

1 0

Re:[boost] Re: [1.32 Plan] Stalled forever?
by Robert Ramey 27 Aug '04

27 Aug '04

>> The branch should occur now. MPL update can go into the next release. >> Or you can see it a slightly different way. Branch and release 1.32 now. >> Rebranch and release 1.32 when MPL update has been added and any >> related issues resolved. >Please be patient. >Aleksey is having a hard time getting finished and the release date has >slipped; it's true. That said, the very existence of this release is due >to our need to have a Boost release with an updated MPL for >http://www.boost-consulting.com/mplbook. The CD for the book has to be >final by early next month, and there's no possible way we can do two >releases before that time. The schedule is getting increasingly tight; I >just hope we can do _one_. >I considered what would happen if we branched now and Aleksey integrated >his changes into the release branch. It seems apparent that it would only >slow the release down further, since the changes would have to be >integrated into the trunk, too. This would be even worse than the current situation. My real question was what is the downside of including MPL in release 1.33 rather than 1.32 ? The important thing is the release date - not the release number. I believe that the rest of concentrating on a bug free release of 1.32 while others get MPL ready for the NEXT release will result in a sooner release date for the current library + MPL than otherwise. So my suggestion is: Branch 1.32 rc now - make only bug fixes. Actually at this point they aren't really bugs so much as accommodation to different platforms, tool configuration scripts. Etc. Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If MPL slips in with no ripple effect - well no harm done. If MPL ripples through creating a bunch of new test failure, still no harm done, 1.32 is still available. This would in effect de-couple the release progress of the boost library as a whole from any issues associated with a particular library. I didn't not think that I would be able to make the release for the serialization library - indeed - I couldn't make the original one. I was prepared to work at my own pace and upload a "serialization add-in" compatible with the latest release. It would be then up to the manager of the next to decide whether it was worthy to be included in the next "boost release" Actually, all boost libraries - including an MPL update, should take this approach. Robert Ramey

5 4

[minmax] patch to solve issue in GCC 2.95
by Joaquín Mª López Muñoz 27 Aug '04

27 Aug '04

GCC 2.95 has problems supporting using declarations inside functions, as indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. This affects a minmax test in this compiler. The following trivial patch moves a using directive to global scope and solves the issue. This would make it all green for minmax regression tests under every platform considered. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 46a47,48 > using namespace boost; > 50d51 < using namespace boost;

1 0

[1.32 Plan] Stalled forever?
by JOAQUIN LOPEZ MU?Z 27 Aug '04

27 Aug '04

I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future. People are beginning to divert (a review in progress, etc.) I haven't been involved in previous releases, but I guess a month delay is well over what's considered normal/acceptable. Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient? Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 7

Re:Re: [boost] Seialization library current status
by Robert Ramey 27 Aug '04

27 Aug '04

>Bronek Kozicki wrote: #include <fstream> #include <boost/config.hpp> #include "test_tools.hpp" int main() { const char * testfile = boost::archive::tmpnam(NULL); test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa_implementation(os); printf("boom\n\n"); } I'm amazed you could figure this out. Thank you, this is very helpful. Robert Ramey

2 1

RE: [boost] [Boost.Test] New testing procedure?
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

> According to http://tinyurl.com/3f32c tests have been failing > (IIUC for several days if not longer) because of > protected/private access violations in the test library. See > the end of http://tinyurl.com/35ole for details. IMO this > situation is unacceptable, and I'm looking for practical > solutions. Problems with the Boost.Test affect our ability > to get meaningful feedback on the state of other libraries. > > If Gennadiy can't test on more compilers before checking in, > and respond faster to problems introduced in its source, and > if library authors genuinely find Boost.Test useful, maybe we > need to move to a different model wherein the test library's > own tests are run on a CVS branch of the code (?) so that > Gennadiy can see and deal with his problems before they are > merged into the main trunk and break everything else? I do test on as much compilers I have accessible. In this particular case It was working on all compilers but Borland. I posted request for workaround while ago. Still no response. I had to test other configuration and I committed it. Actually I was surprised that so many compilers had an issue with completely innocent using declaration. Anyway I think it should be fixed as of last night. I found some hack that should work on complaining compilers. I will see the results of regression test today. As for creating separate brunch for Boost.Test development, I do not really mind. But I believe it will create an extra headache for regression testers (and me). Essentially we will need to have two copies of development tree. And run Boost.Test unit test in a separate tree. I will need to keep moving files back and forth 2 branches. Also I wonder how it will interact with release procedure. You may noticed that I am trying to introduce modification in Boost.Test in "packages", meaning I do not d code modifications all the time. I am not sure that several days of "no regression test on some compilers", worth all that trouble. Especially since all the developers could always rollback Boost.Test modification locally for development testing. Regards, Gennadiy.

4 10