RE: [boost] 1.30.0-b1: filesystem::path::swap
At 06:18 AM 3/12/2003, Geurt Vos wrote: Hi, Is there any reason boost::filesystem::path doesn't provide a swap(path ) function? If there is, I think the docs should explain why, but if there isn't, well, can it still be implemented before 1.30.0 goes gold? Let me turn the question around and ask what your expectations would be for a swap member beyond what is already offered by std::swap? No throw guarantee? Yes. That is, this is the main (or actually only) reason for asking. OK, I've added it to do-list.htm. I don't want to try to add it for 1.30.0 - it's too late at this point. If you want to send me a patch, feel free! --Beman PS: In researching this, I found that the C++ standard seemed to indicate that basic_string::swap() did not give the expected guarantee not to throw. I've raised the issue with the committee, as it looks to me like a defect. Of course, the defect might just be in my expectation for basic_string::swap(). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 10:54 AM 3/12/2003, Vladimir Prus wrote: Beman Dawes wrote: Here is my list of outstanding patches and fixes. It would be great if we could resolve the bulk of these for 1.30.0. * [bgl] pass by value Awaiting response from Jeremy Per off-list discussion, I've comitted the changes. They are also merged to RC branch. There may be more similiar issues, but that's not for 1.30. OK, removed from list. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Outstanding patches and fixes
At 11:33 AM 3/12/2003, Gennadiy Rozental wrote: * [Boost.Test] Request for const fix in unit_test_suite.hpp Posted 12 Feb 2003. Did this ever get resolved? Gennadiy? Fixed in second revision. OK, removed from list. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Outstanding patches and fixes
At 10:56 AM 3/12/2003, Markus Schöpflin wrote: Beman Dawes wrote: * Multi-array constructor patch Has been applied, but caused Win32 Metrowerks constructors test failure. I was just about to fix it but noticed, that Ronald already fixed it. OK, Metrowerks is now passing. Removed from list. * PRB with type_traits::is_member_function_pointer Would prefer John Maddock or someone else more familiar with type traits regeneration make this change. Done with help from Aleksey. OK, removed from list. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 11:50 AM 3/12/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: * Boost.Python private email Final changes promised for Wednesday night. Those are done. OK, removed from list. I'd like to watch http://cci.lbl.gov/boost/ go through one more successful test cycle. Even though we are getting lots of fixes today, we won't cut off fixes until sometime tomorrow morning at the earliest. I'll review progress then, and post the list of outstanding stuff again. * [Boost.Python] rpms and small fix for RedHat Awaiting reply. Dave? I'm not sure what this is about. Link? Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar 2003. Here is the entire message: I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 11:52 AM 3/12/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: * [status/Jamfile] Jamfile patches for Borland Need a decision. Dave? I'm also not aware of these issues. See http://aspn.activestate.com/ASPN/Mail/Message/boost/1566296 Because it is a build related issue, I'd like input from Boost.Build experts. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Bidirectionnal map
At 06:03 PM 3/12/2003, David B. Held wrote: On an unrelated note, one thing that might be a concern is that I did not write the map from scratch. I used the STLport implementation of std::map, which came from SGI or HP (or both, for all I remember). I wonder if the license is Boost-compatible? Can anyone comment? I suppose I could rewrite the map from scratch, but this is a ton of work that I especially don't have time to do, and it would be a shame if it had to be done because of licensing issues. You would have to go back and find the specific license. No way to tell without seeing the exact license covering the code you started with. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc 3.2.2
At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote: The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc 3.2.2. The error message appears at the top of: http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test .../boost/boost/lexical_cast.hpp:92: `wstring' undeclared in namespace `std' This worked before: http://cci.lbl.gov/boost/results/1047490620/dailylog_coral_test (There are some other unrelated problems on this platform.) The same code also caused problems for Win32 GCC, Intel, and VC++ 6.0. I've added a quick fix for lexical_cast.hpp line 92, which cleared a lot of the problems, but not all of them. See http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html AFAIK, all the new fails are because of lexical_cast.hpp use. I've already privately emailed Kevlin and Terje, but given time zone differences they may not see the messages right away. This sort of last minute snafu reinforces Ralf's earlier message; it really isn't good software development practice to sit on changes for months, and then try to get them working after a branch for release. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp Itanium2 RC_1_30_0
At 08:12 PM 3/10/2003, David Abrahams wrote: OK to check this into the RC_1_30_0 branch? Go for it! You don't need to ask permission to make stuff work. (it's nice to notify the list when you do, though) It helps me too; I'm trying to track outstanding issues with RC_1_30_0, so it helps to know when an issue is closed. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] fixes to release_procedures.htm
At 04:16 AM 3/10/2003, Martin Wille wrote: the attached patch fixes two typos in the release procedures document. Fixed. Thanks! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] release procedure typo(?)
At 12:23 AM 3/11/2003, Gennadiy Rozental wrote: Hi, Beman In examples for release procedure you are using: merged_to_1_26_2. While in Release Procedures for the Release Manager section you are mention: merged_to_RC_n_n_n. What is correct? Should read merged_to_RC_1_26_2. Martin Wille already submitted a patch. P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? I've added a FAQ to the page: What is the purpose of the merged_to_RC_n_n_n tag? This tag allows multiple merges from the main trunk to the release candidate branch. Without it, merging an initial main trunk fix into the release candidate branch would work, but merging a second fix from main trunk to release candidate branch would result in a merge conflict. Although this procedure seems convoluted, it works much better in practice than several prior procedures we tried. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: release procedure typo(?)
At 10:36 AM 3/11/2003, Gennadiy Rozental wrote: P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. Imagine I change the file abc.cpp. 1. I commited it im main trank: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) No! abc.cpp will already have been tagged with merged_to_RC_whatever by the release manager (or by you, if you had previously applied a fix according to the procedure.) 3. I merge it to the release branch Additionally if I need to change it again, before step 2 Iwill nedd to untag it: cvs tag -d merged_to_RC_whatever, which is also is not in release procedure right now. Did I get it correct? No. AFAIK, the release procedure is correct as written, modulo typos. I've been using the WinCVS version repeatedly for the better part of a week now, and it is working like a charm. Much easier than previous procedures. Please look at the procedure again and see if it is still unclear. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0-b1: filesystem::path::swap
At 03:23 AM 3/10/2003, Geurt Vos wrote: Hi, Is there any reason boost::filesystem::path doesn't provide a swap(path ) function? If there is, I think the docs should explain why, but if there isn't, well, can it still be implemented before 1.30.0 goes gold? Let me turn the question around and ask what your expectations would be for a swap member beyond what is already offered by std::swap? No throw guarantee? More efficient? Or are you asking that filesystem::path satisfy more container requirements? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bad links on regression log cs-win32-RC_1_30_0.html
At 03:57 PM 3/11/2003, Alisdair Meredith wrote: All the links to warnings/fails point to the d: drive and so are a little inaccessible right now g Argh! I've been fooling around with the setup to allow running tests on both the main trunk and the release candidate, and that is clearly having some unexpected fallout. No promises as to when it will be fixed, but we really do need to address linking problems permanently. Perhaps by pointing the links at CVS. Also, is there any way to get the 'differences emphasised' view? Often a single test starts passing/failing and it is very hard to locate which one has changed, especially without the previous test results for reference. I know! That's my favorite too. But the procedure for generating it is a horrible hack done just to prove the concept. The permanent solution would be to keep the information in the .xml file. No idea when that might be implemented, however:-( It would be particularly nice to be able to see history, but that may be a dream for the distant future. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: C++ Standards Committee upcoming meeting
At 07:12 PM 3/11/2003, Dietmar Kuehl wrote: Beman Dawes wrote: The C++ Standards Committee will be meeting in Oxford, UK, April 7th through 11th. As always, Boosters are welcome to attend as technical experts - See http://www.boost.org/more/cpp_committee_meetings.html. Is there going to be general Boost meeting on Sunday something like this? At the last meetings there always was some kind of Boost meeting, at least for meeting Boosters in person. Doug Gregor is tentatively planning to host a session on the Boost documentation system he has been working on. No date or time yet.c Doug, how are your plans shaping up? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Spirit and regression tests
At 07:07 PM 3/11/2003, Alisdair Meredith wrote: Is there any reason the Spirit tests are not integrated into the regression suite at the moment? Too much for 1.30.0. The same applies to Boost.Python. As soon as 1.30.0 ships we need to review a bunch of operational issues, including regression tests, to see where to go from here. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Jamfile patches for Borland
At 08:27 PM 3/11/2003, Alisdair Meredith wrote: Borland fails several tests due to missing exports from limits in its dynamic runtime library. One question: Is there any way to work around the missing exports by adding some Borland specific code to boost/limits.hpp? Or would that just cause problems if the user happened to link staticly? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] EH in the regression tools
At 10:50 AM 3/9/2003, David Abrahams wrote: Just browsing, I noticed: if ( !file ) throw fs::filesystem_error( process_jam_long.cpp, pth, can't open output file ); But I can't find a catch block anywhere in the program. Am I missing something? Yes: int cpp_main( int argc, char ** argv ) So execution_monitor will take care of the catch. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Does this compiler need configuring?
At 02:17 AM 3/8/2003, Daryle Walker wrote: Try compiling libs/config/config_info.cpp and running it. The output will tell you what the configuration looks like. It will identify the platform, compiler, library, and the important macros defined for each. Look for macros which are obviously wrong, such as BOOST_NO_STDC_NAMESPACE. I can't compile the file; the BOOST_NO_STDC_NAMESPACE mistake results in a compilation error (which prevents running). How would I override this particular macro? I could preprocess the file, and here are the results, removing the macro printings that result two identical strings (which I think means that the macro isn't defined at all): ... print_macro(BOOST_NO_STDC_NAMESPACE, =) ; So Howard was right - BOOST_NO_STDC_NAMESPACE is defined but shouldn't be. Look at boost/config/posix_features.hpp, around line 38: # ifndef __APPLE_CC__ // GCC strange ignore std mode works better if you pretend everything // is in the std namespace, for the most part. #define BOOST_NO_STDC_NAMESPACE # endif Note that this is inside an #if: #if __MACH__ !defined(_MSL_USING_MSL_C) It looks to me like something is wrong with one or the other of these two pieces of code. But since I know nothing of the Mac OS, I won't hazard a guess as to the exact problem or the fix. Mac experts? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
At 11:08 AM 3/7/2003, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. The submission was three files, including patches for docs and tests. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PRB with type_traits::is_member_function_pointer
At 09:00 AM 2/18/2003, Markus Schöpflin wrote: Hi there, currently, the is_member_func_test fails for VACPP6 with the following error messages: /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_functio n_pointer.hpp, line 37.29: 1540-1206 (S) The class template instantiation of is_mem_fun_pointer_implvoid (UDT::*)() is ambiguous. /home/auto/schoepf/src/extern/boost- ... When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks compiler has the same problem. Could anyone please add a check for __IBMCPP__ =600 at line 345 of this file and regenerate it? Markus, It doesn't look like this change was ever made. Would you still like to see it made? Does anyone have an objection? It would only affect the IBM compiler. (I'm trying to make sure that patches haven't fallen on the floor. Please excuse the bother if the patch was not applied because it was rejected, and I just didn't see any message indicating that.) I'll make the change if it is still needed. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Does this compiler need configuring?
At 03:49 PM 3/7/2003, Howard Hinnant wrote: On Thursday, March 6, 2003, at 03:33 AM, Daryle Walker wrote: I've attached the project I used, so maybe some Metrowerks expert can find the obvious thing I forgot (or maybe it's actually a misconfiguration, or [worse] a bug). I'm a Metrowerks expert, but not a boost expert. Your project is set up to use MSL C which correctly puts ptrdiff_t into namespace std. The above code can't find ::ptrdiff_t because cstddef only defined std::ptrdiff_t. It looks to me like BOOST_NO_STDC_NAMESPACE is being mistakenly defined somewhere. Daryle, Try compiling libs/config/config_info.cpp and running it. The output will tell you what the configuration looks like. It will identify the platform, compiler, library, and the important macros defined for each. Look for macros which are obviously wrong, such as BOOST_NO_STDC_NAMESPACE. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] C++ Standards Committee upcoming meeting
The C++ Standards Committee will be meeting in Oxford, UK, April 7th through 11th. As always, Boosters are welcome to attend as technical experts - See http://www.boost.org/more/cpp_committee_meetings.html. Contact me privately if you want more information. The committee's pre-meeting papers are now available. (The membership list is for members only, and so is password protected, but the rest are available to the public.) See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford The papers this time around include final, or close to final, proposals for adding type traits, regex, shared_ptr, bind, and a number of other bits and pieces from Boost to the Standard Library TR. While the author's of course get the main credit, everyone who participates in Boost in any way can justifiably feel proud of these proposals. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost talks at ACCU
There are going to be several talks about Boost libraries or related topics at the ACCU conference in Oxford, UK, April 2nd through 5th: * Design and Implementation of the Boost Graph Library by Jeremy Siek * Metaprogramming and the Boost Metaprogramming Library by David Abrahams * The Lambda Library : Unnamed Functions for C++ by Jaako Jarvi * Binding C++ to Python with the Boost Python Library by David Abrahams * Multi-Platform software Development; Lessons from the Boost libraries by Beman Dawes A number of other Boost participants will be speaking on non-boost topics, including Gabriel Dos Reis, Kevlin Henney, Greg Colvin, and Andrei Alexandrescu. More info at http://www.accuconference.co.uk/ --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGI MIPSpro Compilers]
At 07:59 PM 3/7/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote: ... I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. Ralf, Thanks for being alert to that. Please post a brief note once you have finished all commits. I haven't really figured out when we will close off RC_1_30_0, but it won't be until Tuesday at the very earliest. I have some Boost.Python things I want to merge into the release. We'll take stock Tuesday morning [US Eastern time] and see what is left to be done. In the meantime, I'd like any boost developers sitting on user submitted patches to either commit them or to post a message on the list saying why the patch is rejected. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 11:35 AM 3/5/2003, David Abrahams wrote: The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. So this is something each developer would do when merging to the branch from MAIN if they want 'extra' information in CVS about where the merge took place? If this is correct, I'm generally opposed to this extra step as I don't see what it is going to buy you above and beyond what you can get in CVS log command. Am I missing something? If you make a big change on the trunk and need to merge to the branch, and then you do it again, you want cvs merge -jmerged_to_RC_whatever -jHEAD In order to make the merge work properly. If the release manager doesn't tag the head at the merge point, the first person to merge from trunk to branch messes up that arrangement. OK, I've added the tag merged_to_RC_1_30_0 to the CVS at the appropriate point in time. It took a couple of hours experimenting with the sandbox to figure out how to do this correctly. WinCVS (and presumably cvs itself) seems to report time as UTC, but expects input times to be local. The tagging itself took over an hour even though SourceForge CVS seemed to running very quickly this morning on other operations. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 11:38 AM 3/6/2003, Beman Dawes wrote: At 11:35 AM 3/5/2003, David Abrahams wrote: The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. So this is something each developer would do when merging to the branch from MAIN if they want 'extra' information in CVS about where the merge took place? If this is correct, I'm generally opposed to this extra step as I don't see what it is going to buy you above and beyond what you can get in CVS log command. Am I missing something? If you make a big change on the trunk and need to merge to the branch, and then you do it again, you want cvs merge -jmerged_to_RC_whatever -jHEAD In order to make the merge work properly. If the release manager doesn't tag the head at the merge point, the first person to merge from trunk to branch messes up that arrangement. more/release_procedures.htm has been updated to reflect these discussions. The changes to more/release_procedures.htm were made on the main trunk, and then merged into RC_1_30_0, and the process repeated several times as the instructions were refined and corrected. In other words, the procedure was applied to its own documentation:-) At least in WinCVS, this was a good deal easier than the old way IMO. Please take a look at more/release_procedures.htm and suggest any corrections necessary. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS repository locked?
At 11:04 AM 3/6/2003, Vladimir Prus wrote: I see this, when doing update: cvs server: [07:46:57] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build . cvs server: [08:02:58] waiting for beman_dawes's lock in /cvsroot/boost/boost/tools/build Beman, is there anything you can do about it? Like killing client or updating again? Or ony sourceforge admins are in position to fix this? If it really was a hung lock, only the sourceforge people can unlock it. But more likely you just happened to access during the more than an hour it took to apply the merged_to_RC_1_30_0 tag. There was a delay of more than ten minutes right at the end with no apparent activity. I don't know why it took so long, unless it had to do with tagging at a past date rather than the current state. Let me know if you continue to have problems, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal: static_string library
At 05:58 PM 3/5/2003, Robert Klarer wrote: There's already been some discussion of this library under the thread Proposal: strings as template parameters, but static_string hasn't been the subject of its own thread, so I'm starting this one. I'd like to solicit opinions about this project. Is it worthwhile? The purpose of the static_string library is to offer an alternative to string literals and the standard type const std::string. A static_string uses no dynamically allocated memory, and is more efficient at execution time than either string literals or basic_strings. Yes, agreed. That would be useful. IIRC, the C++ committee's performance working groups has talked about such a string in the past. But... The syntax for declaring a static_string is unfortunate... boost::static_string's', 't', 'a', 't', 'i', 'c', '_' StrType1; Unfortunate? Is that one of those understatement jokes Canadians are known for? I'd say it is way worse that unfortunate - it is ugly and error prone. Lack of internationalization support is also a serious concern. There are questions that come to mind: * Can you come up with a small, workable language extension that eases those problems? * Can you come up with an alternate design that gives up a tiny bit of efficiency (one pointer indirection perhaps) but then allows reasonable construction and internationalization? Wondering-out-loud, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 09:50 AM 3/5/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... Dave, what did you mean by that? It sounds like you expect the RC_1_30_0 tag to go on the main trunk and some other tag on the branch. No. What is the point of that? How are the tags used? The point is that if there are multiple merges from the trunk to the branch, you'll need something to mark the version on the trunk of the previous merge. At the point you first create the branch, the previous merge point is the same as the branch point. Ah! That makes sense. The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. OK, I'll add that to the procedure. Does that clear up my concern? Yes, thanks. I'll aim to get the new tag and procedure page in place later today. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Variant Library Review
At 08:31 PM 3/4/2003, Andrei Alexandrescu wrote: If the authors were aware of the previous work and used it as a source of inspiration, it's nice to give credit where it is due. It costs nothing and it is considerate. It is also very much Boost policy, and has been right from the start. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HTML documentation imported into 1.30.0
At 11:44 AM 3/5/2003, Douglas Gregor wrote: I've imported the BoostBook-generated HTML documentation into the RC_1_30_0 branch under doc/html. The affected libraries are: Any, Function, Ref, and Signals. Other than the new directory there should be no effect Should we include PDF and/or man pages for these libraries? - The PDFs are about 270k uncompressed, 127k compressed - Man pages are about 90k uncompressed, 8k compressed I thought we agreed to make pdf, man, and all formats other than HTML available on some separate site. There are still a lot of people who use dial-up lines and have no viable alternative. We need to limit the Boost distribution to core files and put the other stuff elsewhere. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal: strings as template parameters?
At 12:23 PM 3/2/2003, Jason House wrote: I believe I've seen traffic earlier about some kind of upcoming deadline for proposals for becoming part of the C++ standard. There was a deadline yesterday (3 March) for papers to go in the pre-meeting mailing, and there is another in April for final proposals for the upcoming Library Technical Report (TR). For changes to the core language, no formal cut-off date has been set AFAIK. But language changes require a lot of consideration - the committee likes to hear from compiler vendors who have successfully implemented the changes, for one thing. Thus anyone seriously considering a language change needs to be working on their proposal right now. Because Boost is library oriented, comp.std.c++ would be a better place to discuss core language changes. OTOH, library based solutions are of interest to Boost. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] SourceForge computer farm
At 08:55 PM 3/2/2003, Daryle Walker wrote: When I read a web page for a project (in this case, HTML-Tidy at http://tidy.sourceforge.net), I noticed that they built/tested their library every day automatically with computers SourceForge leaves for automation. Maybe we should use those computer for our regression testing? I read the docs awhile ago, and their compile farm didn't seem suitable for Boost. I've forgotten the exact reason; possibly it had to do with the tools we need (bjam and the post-processing tools?) It isn't always easy to keep the regression tests running on a local machine. I have trouble imagining how to trouble shoot problems on a remote machine. But perhaps others have had positive experiences with the SourceForge compile farm? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] New release procedure? [was: 1.30.0 branch-for-release complete]
At 06:45 PM 3/1/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: The tag is RC_1_30_0 Didn't we agree that we were going to tag the trunk and generally do any merges from the trunk to the branch? This tag appears to be on the branch AFAICT. OK, I've now gone back and read the entire thread. Here is a summary: Jeff Garland [EMAIL PROTECTED] writes: It seems to me that part of the release process that would delay merges from the candidate branch to the main branch is misguided. Critical changes made to the release branch should be immediately merged on the main branch. This avoids the issues of forgetting to merge later which can lead to lost fixes or fixes that are much harder to merge. At 05:46 PM 10/24/2002, David Abrahams wrote: I think the whole approach of merging from the release to the main trunk is totally misguided. If there's a fix which _can_ be applied in the trunk, it should be made there *first*. At least if it breaks something in the release candidate we'll be more likely to hear about it that way. If the trunk has already diverged too far for the fix to be applicable, it's a non-issue anyway. No one disagreed with this assessment. Jeff Garland posts a partially updated set of developer procedures: http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm At this point the discussion fragments into details and corner cases. The updated release_procedures.htm was never committed to CVS. So, if we are going to do merges from the trunk to the branch for 1.30.0 we need a finalized procedure right away. Jeff? Dave? I'd really like it to include the Release Procedures for the Release Manager, which is currently blank. While I understand the general idea, I'm not sure what the release manager does differently. How is the branch named? What is the tag that goes on the main trunk and how is it named? Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 branch-for-release complete
At 04:01 PM 3/3/2003, Mark Rodgers wrote: Is it time we introduced beta releases into the release procedure? It seems to me that it would be a good idea to tar up 1.30.0 RC and give everyone a chance to try it out and report feedback without having to use CVS. I know CVS puts me off. Questions include How much of a hassle would it be for someone? (Beman?) Not much. But I'd like to get an indication people will really try a beta before we go to the trouble. How many extra people would be encourage to test the beta? Good question. Are there others interested in a beta? Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Increase in binary size
At 10:03 AM 3/3/2003, Lars Gullik Bjønnes wrote: I see that when upgrading LyX to use the upcomming 1.30.0 release instead of the 1.29.0 release our binary size increases by more than 125kB... Not sure what goes into your binary size. Does that include source code, tests, examples, and docs? 1.30.0 includes four libraries which were not in 1.29.0. Spirit in particular, is a major library with lots of docs, examples, tests, etc. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Does this compiler need configuring?
At 02:03 AM 3/4/2003, Daryle Walker wrote: I'm trying to use the more_io.zip stuff currently under review with a copy of Metrowerks CodeWarrior Developement Studio (Mac OS X Edition, v8). I haven't got anything to compile. If there is a question of configuration as John's rely indicates, a good way to debug the problem is to run the config_info regression test. Inspect the output to see if it is reporting the right platform, compiler version, and library. Don't even bother trying anything else until config_info is reporting the correct information. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 branch-for-release
OK, I've finally shipped my ACCU talk slides and can concentrate on 1.30.0. Sorry for the delays. One issue surfaced mid-week; some Win32 compilers (VC++, possibly others) are silently failing to compile certain source lines terminated with a CR only. (The traditional Apple Mac line termination is a CR only.) Gennadiy should get some kind of prize for figuring this out; I had failed several times to understand what was happening. In the past we talked about restricting line terminations to either CR/NL or NL as a convenience to the bulk of users, but hadn't done anything about it since it seemed low priority. But now that we are seeing CR terminations actually causing silent miscompilations, I'd like to fix this ASAP. I don't know how widespread the problem is; I'll look at it this morning and fix if possible. In any case, branch-for-release should happen sometime today (Saturday, US Eastern time). --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 branch-for-release
At 01:01 PM 3/1/2003, David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Beman Dawes [EMAIL PROTECTED] writes: OK, I've finally shipped my ACCU talk slides and can concentrate on 1.30.0. Sorry for the delays. Beman, it appears that you didn't tag the trunk at the branch point, which will make multiple merges to the branch more difficult. Do you want me to do it? Oops; I should learn to read, sorry :( You haven't done the branch yet. Right. I've just rerun the Win32 tests and am about ready. Will take a break for a hour or so and then review my checklist. If everything looks OK, will branch late this afternoon (Eastern US time.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 branch-for-release complete
The tag is RC_1_30_0 I'm going to take a break for the rest of the weekend, and then we should get together a list of what needs to be done before the actual release. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 36 short films about smart pointer....
-or-trivial-dtor: The type is complete or the destructor is trivial. incomplete-with-non-trivial-dtor: The type is incomplete and the destructor is non-trivial. A user-deletion function defined in a translation context when the type is complete must be supplied. conversion-to-ptr no-implicit-conversion: operator T* is not defined for the pointed-to type T. This ensures that an unwanted conversion will never occur. It is thus the slightly safer choice. implicit-conversion: operator T* is defined for the pointed-to type T. This mimics built-in pointers, and improves readability in programs where many function arguments require raw pointers. Acknowledgements Portions of this discussion are based on boost mailing list postings by Kevlin Henney. The format for this page was patterned after Jeremy Siek's Mutex Feature Diagram page. Revised 13 Oct 2000 © Copyright Beman Dawes, 2000 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ANSI/ISO VC++ Conformance Strategy in VS 2003
At 02:37 PM 2/26/2003, Jason Shirk wrote: Jonathan Caves, Herb Sutter, and I will be hosting a webchat on C++ conformance in VC7.1 (aka Everett) tomorrow (2/27, 1PM PST). See http://msdn.microsoft.com/chats/ for details. My thanks to the Boost moderators for allowing this announcement. Eventually we plan to start a boost-interest mailing list which will then become the most appropriate place for announcements like this. But since that hasn't happened yet, we felt it was OK to accept Jason's post. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] operators.hpp fixed
At 04:34 PM 2/26/2003, Daniel Frey wrote: I just found a small bug of my implementation of NRVO-friendly operators. Nothing serious, I just forgot to respect the setting of BOOST_FORCE_SYMMETRIC_OPERATORS for the shift-operators. I already fixed it in CVS. I hope this is OK without asking on the list first as I just fixed my own stupid oversight and the fix is pretty obvious :) Is there already a branch for the upcoming 1.30.0 where this should be merged to? No, we still haven't branched. The tentative target is tomorrow morning (US East Coast Time). So go ahead and commit your fix on the main trunk. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
At 08:34 AM 2/25/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Go ahead and make the change, unless someone voices an objection. I'm wondering how may other places we have similar problems? Now you know why I've been making such a stink about insidious ADL! Is there any programatic way to detect them? I've been trying to get compiler vendors to add a warning for names to which ADL applies but which are found in the local namespace. This, at least, would give us a way to detect likely candidates. No takers yet :(. Hum, it looks like Microsoft took you up on it. See the shared_ptr_test warning on the VC++ 7.1 beta regression test. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
At 07:32 PM 2/24/2003, Daniel Frey wrote:
Hi,
I came across the following problem:
When I have a class X which lives in a namespace where there's a function
'checked_delete' declared that can take a X*, smart_ptr (and probably
others)
that use checked_deleter (note the 'r'!) cannot call checked_delete. It's
ambiguous due to argument dependent lookup. To fix it, I had to make the
call to checked_delete in checked_deleter qualified:
templateclass T struct checked_deleter
{
typedef void result_type;
typedef T * argument_type;
void operator()(T * x) const
{
::boost::checked_delete(x);
}
};
(alas for checked_array_deleter)
Comments?
Go ahead and make the change, unless someone voices an objection.
I'm wondering how may other places we have similar problems?
Is there any programatic way to detect them?
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Managers Wanted
At 03:41 PM 2/24/2003, Thomas Witt wrote: I am looking for volunteers who are willing to act as review manager. Due to the increasing number of review requests the current pool of review managers just isn't enough. As of now we do have a backlog of five outstanding reviews. For those interested in the details I have updated the review schedule in CVS. The updated schedule will move to the web with the 1.30.0 release. The ideal review manager is an experienced boost developer that is known to the people on the list. Though he don't need to have submitted a library himself. Nor does she actually have to be a he. Further information about the job of a review manager can be found on the webpage http://www.boost.org/more/formal_review_process.htm People who are willing to volunteer, please contact me by private email. Please think seriously about volunteering. It doesn't take a huge amount of time to manage a review, yet it is really important to Boost. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] No mail
At 05:27 AM 2/20/2003, Anthony Williams wrote: Is there something up with the boost list today? I haven't received anything on the list since yesterday, though a quick check on gmane indicates that there has been activity. Early Tuesday (US Central time) an HP router got into a fight with a Cisco router at our Indiana University host. But that was fixed by mid-morning Tuesday, and everything has been normal since then AFAIK. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 06:24 PM 2/17/2003, Douglas Gregor wrote: On Monday 17 February 2003 04:49 pm, Beman Dawes wrote: Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Well, you'll have the doc source on your machine, and can generate whatever format you want. Where is this documented? How long does it take? It there a way to only regenerate the files that change, or does the entire Boost docs have to be generated? I'd like to give it a try, but need pointers to docs. I don't even have an XML editor at the moment, let alone any of the other tools. The documentation isn't big (~650k, much smaller compressed). However, generated documentation tends to change a lot even with minor changes to the input, so unless someone has a good way to tell CVS don't track any history for this file then the CVS repository will get huge with the histories of these generated files. Understood. So we need to come up with some other smooth way of updating the documentation HTML files on developers machines to match the CVS state. Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. Sure, but we also have documentation that's inconsistent across libraries, not indexable, and unavailable in any format other than HTML. Our current simple model is simple for simple uses, but doesn't extend to any more advanced cases. A system that is too cumbersome to use isn't really more advanced, it is just a mess. We need to make the new system as easy to use as the old one or only the masochists will use it. Using generated documentation has some up-front costs: you'll need to get an XSLT processor, and maybe some stylesheets (if you don't want them downloaded on demand), and probably run a simple configuration command (now a shell script; will be in Jam eventually). I don't mind some added costs as long as the system is easy to use. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Mac OS (Darwin) failures?
In looking at the Mac OS (Darwin) regression tests to see why there are so many failures, a number of tests are failing with only this message: /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: use of `long double' type; its size may change in a future release /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: (Long double usage is reported only once for each file. /usr/local/boost/boost/type_traits/is_float.hpp:22: warning: To disable this warning, use -Wno-long-double.) There are two odd things about this: 1) This is just a warning so why is the test being reported as failing? 2) The darwin toolset specifies CFLAGS : -Wno-long-double, so why is the warning even being issued? Any ideas? (I can't test because of lack of access to the platform.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] datetime and long long
At 11:26 AM 2/18/2003, Jeff Garland wrote: Take a look at bosot/date_time/compiler_config.hpp which does something similar. All we need to do to fix these regressions is add the compiler to the list of those that don't have std::abs at line 34. Based on the above, I've bump the VC++ version up to 1310 to cover version 7.1. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Win32/VC++ 7.1 final beta regression tests posted
Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ The folks at Microsoft asked that we identify these tests as beta, since the actual release may get slightly different results. And of course the Boost code is not quite the 1.30.0 release yet either. I'll try to rerun these occasionally, but they won't happen daily unless someone makes a specific request. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32/VC++ 7.1 final beta regression tests posted
At 02:35 PM 2/18/2003, Alisdair Meredith wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ From the department of nitpickers ;¬ ) The links to the fail messages refer to .../cs-win32-links.htm#... rather than .../cs-vc71beta-links.htm#... I manually fixed-up the URL in my browser and saw that the vc71beta html file is present and correct though. Duh... Fixed. Thanks! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Win32/VC++ 7.1 final beta regression tests posted
At 02:21 PM 2/18/2003, Peter Dimov wrote: Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ You might want to disable warning 4675, resolved overload was found by argument-dependent lookup. Yeah, I saw that too. But I don't want to put effort into VC++ 7.1 until (1) Boost 1.30.0 is out the door, (2) we have a release copy, (3) I finish some non-Boost work which is backing up. If you want to make changes yourself, feel free to do so. However, please test to make sure whatever you change doesn't screw up VC++ 7.0. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Crunch time
Those not getting responses to queries posted to this list should be aware that it is crunch time for a lot of Boost developers - some of us are variously trying to finish off release 1.30.0, participate in a public review, meet looming deadlines for submissions to the C++ standards committee and the ACCU conference, or get in a mid-winter vacation. Some are trying to do all of those things at once! Thus apologies in advance if response is slower than usual. And don't be shy about reposting in a week or two if you don't get a response. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32/VC++ 7.1 final beta regression tests posted
At 05:26 PM 2/18/2003, Bo Persson wrote: A lot of the failures seems to be a warning that 7.1 actually does the right thing. A bit unfair to count this as a failure! Warnings aren't counted as failures. A test compile, link, or run has to actually report failure (via non-zero return code). I've cleared the boost\type_traits\is_convertible.hpp(154) problem. That accounted for a dozen or so failures, so the results are looking even better. Failure rate dropped to 8%. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 11:56 AM 2/18/2003, William E. Kempf wrote: Well, I'm in favor of that, since we're moving at least some of the documentation to Boost.Book with this release (or so I gathered). So what's the group opinion on this one? I'd like to hold off as many changes as possible until after the release. I don't have time to think clearly about the problems involved, and I'd like to actually try out some of the software too. The final day or two before a branch-for-release isn't a good time for this important discussion. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Win32 Metrowerks problems [was Re: [test] revision two]
At 05:12 AM 2/17/2003, Gennadiy Rozental wrote: There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2. I think I've got them fixed. Testing now. And what is the fix? Add MSL_All-DLL_x86.lib to the MWWinx86LibraryFiles environmental variable. prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32. It what supposed to happend. Important thing is whether the test is aborted at that moment or Boost.Test notification appear. For Metrowerks, the assertion caused a dialog box to pop up, requiring manual intervention. That's a problem, of course, for an automated test suite. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Graph, Property patches and remarks from HP
At 09:44 AM 2/17/2003, David Abrahams wrote: Jeremy Siek [EMAIL PROTECTED] writes: The graph_type.hpp file gets generated by a test file, in fact, it gets generated over and over again. The purpose is to test the many different variations of the adjacency_list. OK, can you make the appropriate fix, then? The other failure that is a bit worrying is Win32/Metrowerks. This is a highly conforming compiler that implements two-phase lookup. The test passed with older version of the compiler. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 12:04 AM 2/17/2003, Douglas Gregor wrote: I've removed the HTML-only documentation for these three libraries from CVS, as the documentation for each is now maintained in BoostBook. libraryname/index.html forwarding documents are in place to get to the generated documentation (in doc/html), and when we near the release I will provide a tarball/zip archive of the generated HTML, the contents of which should be extracted into $BOOST_ROOT before it is archived for release. Any questions/problems/objections/requests? Ouch! That means the current HTML docs for these libraries aren't available to Boosters who depend on CVS to keep up-to-date, or to the inspect program, or any other operations that depends on the CVS tree including an exact representation of what a release would look like. I think you need to develop a procedure so that a documentation change is reflected in the CVS doc/html files right away. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 12:04 AM 2/17/2003, Douglas Gregor wrote: I've removed the HTML-only documentation for these three libraries from CVS,as the documentation for each is now maintained in BoostBook. libraryname/index.html forwarding documents are in place to get to the generated documentation (in doc/html), and when we near the release I will provide a tarball/zip archive of the generated HTML, the contents of which should be extracted into $BOOST_ROOT before it is archived for release. Any questions/problems/objections/requests? Another effect of that change was to break all links to these docs from other Boost libraries. We won't even mention links from other web sites. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regression progress; Win32
At 11:21 PM 2/15/2003, Carl Daniel wrote: Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This morning's Win32 regression tests have been posted. Looking at the diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html, there are still some worries: An aside - Since 1.30.0 will likely be the Boost version when MSVC 7.1 (Everett) ships, it would be nice to have VC7.1 regression results. I can understand perhaps not posting 7.1 results until the RTM version is available, but is anyone even running the regression tests on the final beta (build 2292) or RC1 (build 2346) versions regularly? Curiosity got the better of me, and I did an experimental run on build 2292. Looks pretty good. A vast improvement over prior releases. Problems noted: * Missing overloads for long long. * boost/type_traits/is_convertible.hpp line 153 giving it fits. * A few other scattered failures on code working for other compilers. I'm not going to post the results; no point in worrying about workarounds until we see what the actual shipped version does. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
At 02:00 PM 2/17/2003, Douglas Gregor wrote: On Monday 17 February 2003 11:21 am, Beman Dawes wrote: Ouch! That means the current HTML docs for these libraries aren't available to Boosters who depend on CVS to keep up-to-date, They're always available here, regenerated nightly in HTML, DocBook, FO, PDF, and man pages: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html That really isn't very satisfactory. In the last hour for example, pages on that web site have only been available sporadically. One minute access is OK, the next minute the site or page can't be found. No problems with other popular web sites. Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Extract http://www.cs.rpi.edu/~gregod/boost/doc/boost-doc-html.tar.gz into $(BOOST_ROOT) and you'll have a full release. I think you need to develop a procedure so that a documentation change is reflected in the CVS doc/html files right away. We don't want to stick all of the generated HTML into CVS (too big). If it is too big for the regular CVS, isn't it too big for the distribution too? How big is big? Documentation changes will show up the next morning at the aforementioned site. I'd like to add a link to this generated documentation on the main page (so it is obvious that both the current release documentation and the current CVS documentation are available on-line). Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. It really isn't practical for many Boost developers to download a whole tarball and unpack it every time they want to be sure their Boost tree is up to date. Unpacking doesn't do things like getting rid of obsolete files either. Need a way to just download the changed files - and that sounds like CVS to me. So I think we need to figure out a way for generated docs to work in the context of CVS. Or am I just being too picky? They will only break if the links try to link inside the documentation files, e.g., to a specific anchor. Links that go directly to the library's entry point (index.html) will find the meta-refresh index.html that redirects to the generated documentation. I've checked with inspect: nothing broke. Well, but that's because there are only three libraries being generated now. Some lib's docs do a lot more linking to other boost docs. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32 Metrowerks problems [was Re: [test] revision two]
At 09:38 AM 2/15/2003, Beman Dawes wrote: In the meantime, I'm working around the problem on my local machine by inactivating the crtdbg stuff for Metrowerks. I've also posted a message on the Metrowerks Win32 newsgroup (see below). OK, I've had a response from Metrowerks: The crtdbg.h header isn't a standard part of the Metrowerks runtime library or MSL. It is included in the Win32-x86 Suppor Folder as part of the VCPP Headers folder, but these are really just headers from VC++ that are included because some builds need them. However, while the header is there, CW's library doesn't actually implement the debugging mechanism that this header describes. This is why you're link does not work -- the code just isn't there. So Gennadiy's temporary fix is really the permanent fix. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regression progress; Win32
At 11:21 PM 2/15/2003, Carl Daniel wrote: Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This morning's Win32 regression tests have been posted. Looking at the diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html, there are still some worries: An aside - Since 1.30.0 will likely be the Boost version when MSVC 7.1 (Everett) ships, it would be nice to have VC7.1 regression results. I can understand perhaps not posting 7.1 results until the RTM version is available, but is anyone even running the regression tests on the final beta (build 2292) or RC1 (build 2346) versions regularly? I considered that briefly, but decided not to pursue it for several reasons. The Win32 regression testing is already sucking up too much of my time and my computer's time. Every added compiler makes that worse. And changing the setup so close to the Boost release doesn't seem smart to me. The Boost policy not to test betas is probably a good one, too. I'll add VC++ 7.1 as soon as possible once I get a release copy, but have no idea when that will be. However, if you wanted to start running VC++ 7.1 regression tests now, and posting them as a separate set of tables, that would be fine with me. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regression progress; Win32
At 05:33 PM 2/15/2003, Gennadiy Rozental wrote: * test lib has three tests failing all compilers; at least some of these passed until recently. Note that errors_handling_test and results_resport_test failures does not lead ot any error messages. So I would recommend to perform clean build of those two. I'll take a look at these later today, after this morning's test has finished running. test_fp_comparisons IS failing on all compilers for now. It shows some problems with comparison alsorithm. I will take a closer look after release. Maybe you could take a quick look sooner? We aren't going to branch for release until Monday, and the release won't happen for some time after that. The whole point of the schedule is to allow time to fix lately discovered problems. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regression progress; Win32
At 08:22 AM 2/16/2003, Beman Dawes wrote: At 05:33 PM 2/15/2003, Gennadiy Rozental wrote: * test lib has three tests failing all compilers; at least some of these passed until recently. Note that errors_handling_test and results_resport_test failures does not lead ot any error messages. So I would recommend to perform clean build of those two. I'll take a look at these later today, after this morning's test has finished running. bjam is reporting: don't know how to make result_report_test.pattern don't know how to make errors_handling_test.pattern So it looks like something is wrong with your Jamfile. Is bjam running it OK on your machine? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: OpenBSD regression, hanging tests!
At 10:52 AM 2/16/2003, Gennadiy Rozental wrote: Changing line 64 to: #elif defined(BOOST_HAS_SIGACTION) !defined(__OpenBSD__) Does make the tests not hang any more. Instead it causes them to fail with core dumps, or perhaps that's a success? errors_handling_test supposed to cause FPE and crash in case if signal handling is turned off. I do not know about thread tests. The problems with hanging tests may be related to the thread safety issues discoverred by John. We may try to retry to use signal handling once I address above issues. This includes both the test and thread hangs. What about random? random_test hung again on Win32 for one compiler this morning. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Regression progress; Win32
At 11:24 AM 2/16/2003, Gennadiy Rozental wrote: bjam is reporting: don't know how to make result_report_test.pattern don't know how to make errors_handling_test.pattern So it looks like something is wrong with your Jamfile. I followed Dave A. recommendation and placed them in input section of run rule. The above tests expect them as first command line argument. The files themself are located in test directory. Did you forget to check them in? They under cvs for a long time. Note that Linux regression tests works as expected. That might be a sign there is a problem when ALL_LOCATE_TARGET is being used. Please try a test with ALL_LOCATE_TARGET set to a tree outside of your boost tree, and see if that still works. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Win32 Metrowerks problems [was Re: [test] revision two]
At 10:21 AM 2/16/2003, Gennadiy Rozental wrote: However, while the header is there, CW's library doesn't actually implement the debugging mechanism that this header describes. This is why you're link does not work -- the code just isn't there. So Gennadiy's temporary fix is really the permanent fix. There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2. I think I've got them fixed. Testing now. prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SCO config
At 10:55 AM 2/16/2003, Gennadiy Rozental wrote: Someone will need to add an SCO specific platform config - I don't have the access to the platform, nor do I know how to detect it - but if you can provide me with the information, or if you just want to go ahead and add it then do so. I will try to look into this. What is the usual procedure for adding platform specific config? See www.boost.org/libs/config/config.htm#config_script and www.boost.org/libs/config/config.htm#modify_guidelines HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tables, UI improvement...
At 12:36 PM 2/16/2003, Rene Rivera wrote: Yes, I do plan to convert the script to C++. It won't happen until the Summer though, when I have more time for this, and to hopefully submit other things to Boost. And perhaps by that time you'll have a single XML file for me to parse ;-) I think we can generate that pretty quickly. It would essentially just be the concatenation of all the individual .xml files already generated. I haven't looked lately to see if that would provide 100% of all the needed information, but it must be pretty close. But I'm overcommitted until May, so it will have to wait until then. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Win32 Metrowerks problems [was Re: [test] revision two]
At 09:18 PM 2/13/2003, Gennadiy Rozental wrote: No, it is some sort of configuration problem. Look on metrowerks linking errors thread. It about the same issue with different undefined symbol I have a vague memory of that, but can't find the thread. Can you be more specific? In the meantime, I'm working around the problem on my local machine by inactivating the crtdbg stuff for Metrowerks. I've also posted a message on the Metrowerks Win32 newsgroup (see below). --Beman The Boost Test library recently added an additional use of the CRT debug facilities (crtdbg.h). Using the command line tools, this resulted in a linker error: ### mwld Linker Error: # Undefined symbol: '__declspec(dllimport) __CrtSetReportHook (__imp___CrtSetReportHook)' # referenced from 'int boost::execution_monitor::execute(bool, int) (?execute@execution_monitor@boost@@QAEH_NH@Z)' in execution_monitor.cpp:192 The linker environment variables look like this: MWWinx86Libraries=+C:\Program Files\Metrowerks\CodeWarrior\MSL;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support; MWWinx86LibraryFiles=MSL_C_x86.lib;MSL_Extras_x86.lib;MSL_Runtime_x86.lib;MSL_C++_x86.lib;gdi32.lib;user32.lib;kernel32.lib; What needs to be changed to resolve this error? Is there a way to prevent errors like this in the future? This is the second or third time use of names from a Metrowerks supplied header has caused linker errors. The same code worked without manual intervention on the Borland, Microsoft, and Intel compilers. Although in many ways the Metrowerks compiler is superior, the Metrowerks linker seems to be behind the other vendors in this respect. TIA, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regression progress; Win32
This morning's Win32 regression tests have been posted. Looking at the diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html, there are still some worries: * random/random_test is failing, and/or exhausting compiler memory for most compilers, on both Win32 and other platforms. * signals lib is failing all Intel and Microsoft tests; as recently as a few days ago the bulk of these were passing. * test lib has three tests failing all compilers; at least some of these passed until recently. * test lib is causing new Borland warnings for many other libraries. See type_traits/is_pointer_test for example. Help in clearing these problems would be appreciated! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tables, UI improvement...
At 12:45 PM 2/15/2003, Rene Rivera wrote: As someone mentioned previously... The links to libraries and source are broken. I took a few minutes to put in an .htaccess file on the server that redirects those links to reasonable places. For the library links they are redirected to the corresponding www.boost.org point. For the source code links they are redirected to the SourceForge CVS view of the file. The cool syntax highlighted version :-) Wow, that's really neat! Thanks! The problem has always been that linking the source code to the web site would reach a possibly obsolete version of the code. By linking to the CVS, that problem is neatly solved. Thanks, Rene! --Beman PS: It would probably be good if you added the scripts to CVS. Maybe in tools/regression. That way, we have a backup copy and others can help with maintenance. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] When to branch-for-release 1.30.0?
In terms of new libraries and most major revisions, Boost developers committed their files early, so we are in great shape. Thanks to the developers of Filesystem, Optional, Interval, MPL, Spirit, Smart pointers, Date-Time. (If your library didn't get mentioned, its because no one updated boost-root/index.htm Latest News, where I got the above list of libraries.) Bjorn Karlsson, our Maintenance Wizard, has been working with developers to clear maintenance issues major and minor. However, various regression test failures, hangs, and loops have come up in the last few days, and I'd like to clear at least some of these before branch-for-release. So I'm proposing we spend Saturday and Sunday trying to clear regression test problems, and then branch-for-release Monday around noon Eastern US time, (5PM UTC). Comments? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 11:38 AM 2/12/2003, Rene Rivera wrote: [2003-02-11] Beman Dawes wrote: At 09:01 AM 2/10/2003, Toon Knapen wrote: I think the traffic-light colors should suffice. I find adding black confusing. I agree. The traffic-light metaphor falls apart when you add black. Yea, but black is used in the regresion tests themselves. How does it not fall appart there? Do we just get rid of black, and the 48 hour test become green? Or is there some better way to show age? SourceForge CVS browsing used a scheme where recent commits are reported as n hours, less recent as n days, still less recent as n weeks, and really old files as n months. One the release happens, there will be a set of tests for 1_30_0 which will grow old, yet there is nothing wrong with that. I'm wondering if the hour/day/week/month scheme would work better, particularly for those release tests? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 12:35 PM 2/13/2003, David Abrahams wrote: Whatever we do with color, most of the text that needs to be readable should be black on white. That's been shown to be most readable for most people, on average. That's a good point. Color-blind people may have trouble with anything that depends purely on color to convey information. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
At 11:53 AM 2/13/2003, Gennadiy Rozental wrote: Hi, everybody Today I committed second revision to Boost.Test library. Wow, is that a good idea one day before we branch for release? I should have done it week ago, but was really sick. Anyway, It does not contain anything that should break backward compartibility. However, problems with Boost.Test broke a lot of Metrowerks tests. --Beman PS: I started the Win32 tests running this morning, and then left right away for a meeting. When I got back, random_test had been looping for six hours. Sigh. I don't know that's related. I'll run the Win32 tests several times a day as long as lots of changes are being checked in. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Help with policy_ptr
At 01:47 AM 2/12/2003, David B. Held wrote: ...I hope there's still a chance for it to be considered for the next version of the standard library. The April meeting deadline is not for the next version of the Standard Library; rather it is for the Library Technical Report. While nothing has been formally decided, I'm personally hoping that the LWG will start accumulating proposals for a 2nd Technical Report right away. Proposals accepted for a second TR might miss the next revision of the standard, but they still would be on track for eventual inclusion. Regardless of the details, please don't give up on this or any other valuable work just because it isn't going to be ready for the April C++ committee meeting. Rather, concentrate on getting it ready for Boost review and acceptance. That's a big step forward for a library. Standardization can come later. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
At 11:02 AM 2/13/2003, David Abrahams wrote: That said, the level of support for Sun compilers is likely to depend on two things in the future: 1. Sun's willingness to address the serious bugs in their compiler implementation which prevent much progress at all from being made. Given a reasonably well-conforming compiler, little specific attention should be needed in order to get most things working well. 2. Someone stepping up to run regular regression tests on Sun, and someone at Boost getting them set up to do it. I believe someone at Mentor Graphics volunteered to run the tests, but I think we may have dropped the ball on our side. Now that we have both documentation and a script, a number of people have been able to get the tests running on various platforms. Perhaps those that care about Sun could search the archives for the message from the Mentor Graphics folks, and ask them to give the tests a try. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 04:56 PM 2/13/2003, Rene Rivera wrote: OK, I've made some changes to the page... Added an Age column, removed green from the age color scheme, and moved the age color scheme to the age column only. Comments? The changes seem nice improvements to me. Dropping the Age colors entirely would be fine with me, although I don't feel strongly about it. Thanks for the tweaks! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
At 04:19 PM 2/13/2003, Rene Rivera wrote: When I got back, random_test had been looping for six hours. Sigh. I don't know that's related. I had similar problems with the OpenBSD tests. It ran last night and I woke up to it still hung, using 99% CPU, in one test (thread/test_condition). Killed it and a few others after that to make it complete. thread/test_condition under GCC was a long time problem for Win32/GCC, although the symptom was a hang with no CPU activity. Bill Kempf put in some kind of trap to detect this, and that solved the problem as far as testing went (although I don't think he has found why the behavior is pathological). You might want to make sure he is aware the same or similar problem is showing up on OpenBSD. That may help him to diagnose it. As far as random/random_test goes, it has been a problem for a long time (although not looping until today), failing on most or all Win32 compilers. Jens hasn't responded to emails, so if someone else could suggest patches it would be a help. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [test] revision two
At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote: However, problems with Boost.Test broke a lot of Metrowerks tests. For some reason I could not locate Metrowerks compilation errors on Test Status page. As for Metrowerks linking errors I have a suspicion that it has something to do with Metrowerks toolset. Also I could not locate errors from errors_handling_test. I fixed it in last update and it should work now (At least it works for me on 4 win32 compilers using bjam) The same with result_report_test. Hum. I'll try clearing out old bin files and see if that helps. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Win32 Metrowerks problems [was Re: [test] revision two]
At 08:17 PM 2/13/2003, Beman Dawes wrote: At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote: However, problems with Boost.Test broke a lot of Metrowerks tests. For some reason I could not locate Metrowerks compilation errors on Test Status page. As for Metrowerks linking errors I have a suspicion that it has something to do with Metrowerks toolset. Also I could not locate errors from errors_handling_test. I fixed it in last update and it should work now (At least it works for me on 4 win32 compilers using bjam) The same with result_report_test. Hum. I'll try clearing out old bin files and see if that helps. No, it is some sort of configuration problem. The linker is looking for a symbol __CrtSetReportHook (see below). This is part of the Windows SDK, which Metrowerks does support. It looks like for some reason, the library isn't being found. My MWWinx86Libraries setup looks like this: MWWinx86Libraries=+C:\Program Files\Metrowerks\CodeWarrior\MSL;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support; I changed it to the following: MWWinx86Libraries=+C:\Program Files\Metrowerks\CodeWarrior\MSL;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support\Libraries\Win32 SDK; But still no luck. Any Metrowerks experts out there? --Beman mwld -search -maxerrors 5 -maxwarnings 20 -export dllexport -nowraplines -g -subsystem console -o d:\boost-regr\libs\filesystem\test\bin\operations_test.test\cwpro8\debug\runtime-link-dynamic\operations_test.exe @d:\boost-regr\libs\filesystem\test\bin\operations_test.test\cwpro8\debug\runtime-link-dynamic\operations_test.CMD ### mwld Linker Error: # Undefined symbol: '__declspec(dllimport) __CrtSetReportHook (__imp___CrtSetReportHook)' # referenced from 'int boost::execution_monitor::execute(bool, int) (?execute@execution_monitor@boost@@QAEH_NH@Z)' in execution_monitor.cpp:192 Errors caused tool to abort. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 09:01 AM 2/10/2003, Toon Knapen wrote: I think the traffic-light colors should suffice. I find adding black confusing. I agree. The traffic-light metaphor falls apart when you add black. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fix for some Interval library tests
At 10:07 PM 2/7/2003, Dave Gomboc wrote: I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar) How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the compiler's ADL implementation is broken, it's that the library implementation isn't protected against ADL lookups where it needs to be. The rule-of-thumb is to begin these deficiency macros with BOOST_NO_ to make it clear a conforming implementation does not need the macro. So BOOST_NO_STD_LIB_ADL_PROTECTION might be a better name. John Maddock is really the gatekeeper for this sort of macro, and he is also familiar with the Borland compiler. John, what do you think? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Minimal test tool - very minor comments spell checking documentation
At 05:07 AM 2/11/2003, Paul A. Bristow wrote: As for spell checking, MS FrontPage astonishingly doesn't appear to include a spelling checker ... MS FrontPage has had a spell checker for years. Select tools menu, click page options..., and select the spelling options you prefer. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] request for modification.
At 12:48 PM 2/6/2003, Dave Abrahams wrote: It looks like the intel compiler still supports long long when used with the -ansi option. I searched around for good specs, but could find no definitive outline of what other restrictions it adds. So at least as far as long long is concerned, it's good to go. OK, thanks. Why don't you: a. make a copy of the current regression results for Intel b. modify the toolset to add -ansi c. compare the results and see if any new errors crop up which shouldn't be there. ?? If all of that works out, you can check in the toolset mod. I gave it a try, and got this message: icl: warning: option '-Qansi' is deprecated; use '-Qansi_alias' instead I tried again, with -Qansi_alias, with no changes whatsoever in the test results. I've gone ahead and committed the change to CVS, but wonder if this is really the option Ron wanted?. Intel's docs say: -Qansi_alias directs the compiler to assume the following: Arrays are not accessed out of bounds. Pointers are not cast to non-pointer types, and vice-versa. References to objects of two different scalar types cannot alias. For example, an object of type int cannot alias with an object of type float, or an object of type float cannot alias with an object of type double. If your program satisfies the above conditions, setting the -Qansi_alias flag will help the compiler better optimize the program. However, if your program does not satisfy one of the above conditions, the -Qansi_alias flag may lead the compiler to generate incorrect code. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
At 09:48 AM 2/12/2003, Markus Schöpflin wrote: I just updated the regression tests for AIX for both Visual Age 5 and Visual Age 6 and I will try to update at least once a week until Toon gets access to another maching. Thanks! On a side note, how do the compiler version numbers get into the status tables? They don't show up for AIX and the comments in the toolset jam file seem to indicate, that they somehow should. The version numbers are supposed to be extracted from the config_info.output file, which is part of the residue left by bjam. Let's see... The program scans for version , but the message in vacpp.hpp doesn't have that. Fixed in CVS. Thanks again! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Do Jamfiles need copyrights?
Bjorn Karlsson and I are wondering if Boost should require copyrights on Jamfiles. Obviously if a Jamfile author wants to copyright a Jamfile he or she creates, that fine. But what about Jamfiles where the author didn't add a copyright? Do the lawyers care, or are these files to minor to worry about? (I'm assuming, perhaps incorrectly, that Boosters probably aren't worried much about lack of a copyright on a Jamfile and that if any is worried, it would be lawyers.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Some comments about the regression tests
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote: Hi, I tried to use the regression tests with the interval library; and it worked: I just ran run_tests.sh on a linux computer with gcc 3.2.2 and intel cc 7.0 and looked at the results. So, if nobody objects or does it before me, I will modify status/Jamfile so that it automatically handles the interval library. Yes, please do! The subinclude approach works best. Please note that the regular Win32 regression tests won't be run Friday through Tuesday due to a short vacation:-) However, something bothers me. In the big array with all the tests and compilers (cs-something.html), library names are wrong. For example, all the tests for ublas and interval are mixed under the same library called numeric. Is it possible for the regression tools to pick up the name defined in the jamfile (``test-suite interval : [ run...'')? Or to use a longer name like numeric/ublas and numeric/interval for example? That's on the do-list, but I don't know when it will get fixed. Last point, is there something wrong with the linux computer used for the regression tests on http://boost.sourceforge.net/regression-logs/ ? With gcc 3.2, it fails 179 tests. When I gave it a try for the interval library, I got a value which is roughly the same as for windows and openbsd (only 13 tests failed, but it was sunday). Sound suspicious. Alkis? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Some comments about the regression tests
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote: However, something bothers me. In the big array with all the tests and compilers (cs-something.html), library names are wrong. For example, all the tests for ublas and interval are mixed under the same library called numeric. Is it possible for the regression tools to pick up the name defined in the jamfile (``test-suite interval : [ run...'')? Or to use a longer name like numeric/ublas and numeric/interval for example? OK, fixed. The status report will show numeric/ublas, numeric/interval, or whatever. Update and recompile tools/regression/process_jam_log.cpp for the change to take affect. Also update libs/numeric, which will pickup a file name sublibs which is used to tell the regression reporting system that an additional level of library directories is present. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Do Jamfiles need copyrights?
At 01:16 PM 2/5/2003, Martin Wille wrote: Beman Dawes wrote: Bjorn Karlsson and I are wondering if Boost should require copyrights on Jamfiles. Jamfiles are part of the build system; they won't become part of a an executable. So everything is fine when a vendor ships a binary or a DLL. However, when Boost is incorporated to some other open source project, missing copyrights and licences might become a problem. Moreover, copyright statements hinder evil-doers to wrongfully claim ownership. I'm not a lawyer, so I'm just guessing, bit I think we should put copyrights into Jamfiles, Makefiles and the like as well. I'm convinced. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 release schedule
At 11:31 AM 1/28/2003, Beman Dawes wrote: The tentative release schedule for 1.30.0 looks like: January 31 - Finish commits of major new components. February 14 - Branch for release. By end of February - Final release. This schedule is still looking good. I'm taking a mini-vacation Thursday through Tuesday (the 11th), so there won't be any Win32 regression tests during that time:-( One last test tonight is running now, and I'll try to get one off tomorrow morning. It looks like several people have checked in fixes since this morning, and I've fixed a problem with the differential report. In the meantime, the tests for several other platforms are running nicely. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
At 03:22 AM 2/4/2003, Vladimir Prus wrote: Terje Slettebø wrote: ... Have you looked at Jen Maurer's persistence library? It was an elegant design and quite good at handling the issues you are discussing, IIRC. It is still in CVS under the branch persistence-initial. I've always been sorry Jens lost interest in carrying it forward to formal review. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] compile warnings
At 04:47 AM 2/4/2003, Vladimir Prus wrote: Beman, I've just got the following: gcc.compile ../../../libs/filesystem/build/bin/gcc-3.2/release/link-static/operations_po six_windows.o ../../../libs/filesystem/src/operations_posix_windows.cpp: In member function `boost::filesystem::directory_iterator::directory_iterator(const boost::filesystem::path)': ../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: `const char*name' might be used uninitialized in this function ../../../libs/filesystem/src/operations_posix_windows.cpp: In member function `boost::filesystem::directory_iterator::directory_iterator(const boost::filesystem::path)': ../../../libs/filesystem/src/operations_posix_windows.cpp:210: warning: `const char*name' might be used uninitialized in this function ../../../libs/filesystem/src/operations_posix_windows.cpp: In function `void boost::filesystem::copy_file(const boost::filesystem::path, const boost::filesystem::path)': ../../../libs/filesystem/src/operations_posix_windows.cpp:383: warning: `int outfile' might be used uninitialized in this function This shows up during release builds only. I've looked at warnings, and in first case gcc is just not smart enough -- but would be nice to eliminate the warning. In the other case the warning is correct, AFAICT. The second case is actually incorrect too. The indent was wrong on the throw, so it wasn't obvious that an exception is thrown in the only case where outfile isn;t initialized. I've added otherwise unneeded initialization in both cases to quiet the compiler warnings. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
At 03:35 AM 2/4/2003, Andrei Alexandrescu wrote: Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... * Should a PBSP supply policies that are prone to be used unsafely? I'd say no is an acceptable answer, at least for something like the T* conversion in widely used libraries like the Standard Library and Boost. * Should a PBSP allow user supplied policies to modify interface, perhaps in ways that may be unsafe or even just unfortunate? That's tougher. At some point I lose interest in a PBSP if it prevents me from doing the things I want to do, even if I only want to do them in the privacy of my own code. The original SmartPtr design leaves the onus of choosing the right policy combination to the application designer. To me, that's a design I find reasonable and in keep with the spirit of C++. Safer designs are possible that reject policy combinations that don't go together at the price of being more complicated or less efficient or less flexible. Yes, understood. One of the advantages of a generative approach is the improved ability to reject invalid policy combinations. In the generative experiments I tried a couple of years ago, there wasn't a problem with added complexity or less efficiency, but the result was definitely less flexible. A GenVoca or curiously recurring template pattern hierarchy might be able to solve all those problems, but they were at the boundary of my skill level, so I never tried them. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Results of Cray SV1 regression tests
At 05:06 PM 2/4/2003, Matthias Troyer wrote: I have run the regression tests on a Cray SV1 system using the Cray C++ 3.6 compiler and posted the results on http://www.comp-phys.org/boost/cs-sn9626.html Thanks, Matthias, those are really interesting. I'm always curious how C++ in general and Boost in particular does on systems other than the usual beige desktop boxes. Why don't you consider posting the results on SourceForge with the other results? It would be nice to use something that included cray rather than sn9626 in the file names, and we ought to tweak the config to better identify the platform and compiler, but those are just nits. I have not looked at all the problems yet and will do so when I find time. For now I have posted it just in case that someone (such as a library author) is interested. One of the problems is that there is no int16_t type on the Cray SV1 and other vector machines (with the exception of the newly announced X1 on which int16_t exists but is very slow). Thus it might be good to add a BOOST_NO_INT16_T macro in analogy to the BOOST_NO_INT64_T macro. Another problem is that the type long long exists but is not supported by the standard library (e.g. the operator (std::ostream, long long) is not defined). Since long and long long are both 64 bit there is actually no need to ever use long long. I'll have to check why long long is used in some of the tests. There are a few other places where I guess that there is a compiler problem, since I do believe that most of the boost code should be standard conforming. Any comments by the experts are welcome. I took a look, and quite a few of the failures are tests that also have trouble on other compilers. Hopefully some of these will pass in the next week or two as we get ready for the release. There are probably have a few configuration issues to be worked out, but really it isn't a bad showing for a first try. config_info is reporting the compiler as using the EDG front-end, but not identifying the library. Whose copyrights are on the headers? As far as the filesystem library goes, the two run errors detected are really minor; the implementation seems to be reporting one error code differently from other POSIX systems, and it is allowing remove on a directory that is not empty. I can fix both of those problems if you can tell me some macro name that uniquely identifies Cray C++ (because the same problems aren't showing on other POSIX platforms.) Thanks for sharing your results! Most of us will never see a Cray, let alone test on one. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Historical releases...
At 05:52 PM 2/4/2003, Rene Rivera wrote: In a bout of cleaning, and wanting to learn about SourceForge file distribution... I put all the historical releases of Boost, and the current also, in the SourceForge files distribution system. Thanks! Looks great! I was wondering who added the other releases and the bjam files:-) Also available now are bzip2 versions for those interested in smaller downloads. For details see: http://sourceforge.net/project/showfiles.php?group_id=7586 I'll add bz2 files to future releases. Could you send me a copy of the script or command you used? My knowledge of bzip2 is exactly zero, except that I do see cygwin has supplied a version for my Windows box. Did you run the earlier ones with UNIX line endings? The .bz2 files are so much smaller than the .zip that I wouldn't be surprised if we get asked to also supply the untranslated line ending files in the .bz2 format. We'd need to come up with a distinctive naming convention. With this the historical releases that usually are available on the boost.sourceforge.net/release, are no longer. Now only the latest release is available there. I've also been trying out the SourceForge release system with good results. It's really amazing how much easier it all became after they improved their docs. Starting with the 1.30.0 release, the plan is to only make the SourceForge file list the only download source. I've already updated more/download.html in CVS. Now we are no longer overpassing the disk quota. And have space for those lovely pictures of people that was suggested be moved :-) Yes, I'm planning to move those next week before the 1.30.0 branch for release. Thanks again, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
