Re: [Boost-maint] [boost] Community Maintenance Team and neglected libraries
On Tue, Apr 22, 2014 at 8:46 PM, Ben Pope benpop...@gmail.com wrote: On Wednesday, April 23, 2014 04:08 AM, Edward Diener wrote: None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved. Not having write access is the problem, it's a barrier to the CMT achieving their first two goals of keeping boost building and a healthy test matrix. The context of those goals is the libraries maintained by the CMT, not all Boost libraries. We are expanding the responsibility of the CMT to field queries about pull requests and eventually other maintenance requests where the library maintainer isn't responding, but we are certainly are not asking the CMT to get involved in libraries with active, responsive maintainers. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
Re: [Boost-maint] Community Maintenance Team and neglected libraries
On Tue, Apr 22, 2014 at 12:10 PM, Andrey Semashev andrey.semas...@gmail.com wrote: On Wednesday 23 April 2014 00:29:17 Ben Pope wrote: In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone. There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial. These easy fixes should just happen; make a pull request, ticket with patch, whatever; commit goes in; reminder when tests have cycled; merged to master; profit. This is a recurring topic and unfortunately the problem still stands. CMT was a step forward, but to my mind this is not enough. With SVN we had commit rights everywhere, and such simple fixes went in much easier. After modularization some libraries were left effectively unmaintained and inaccessible. CMT does have rights to push to some libraries but not all and therefore does not fix the problem completely. We've been discussing such issues in steering committee, release management, and community maintenance sessions at C++Now this week, with a couple of more sessions scheduled that will address library review concerns. The details will evolve over time, but the CMT is gaining more responsibility and is being given authority to respond to pull requests to any library when the maintainer isn't available to respond. As procedures evolve, that will expand to cover more situations - pull requests are just the starting point for a general need to be responsive to various kinds of requests. To my mind CMT should have access to all libraries, maintained or not. If a given library is actively maintained then CMT doesn't need to intervene. However, if the maintainer goes silent for considerable time, CMT has the ability to apply such fixes. Yes, that's more or less the approach that has gained support. The actual mechanism will be to continue to limit the CMT write permissions to CMT maintained libraries, but have small group of senior developers within the CMT who have write permissions to all libraries. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
Re: [Boost-maint] [boost] Community Maintenance Team and neglected libraries
On Tue, Apr 22, 2014 at 2:08 PM, Edward Diener eldie...@tropicsoft.comwrote: On 4/22/2014 12:29 PM, Ben Pope wrote: In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone. There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial. Without picking on any particular library or author, here are some examples: * Link the tests with boost::system http://thread.gmane.org/gmane.comp.lib.boost.maint/92 * Merge existing fixes in develop to master http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 * Fight with casts http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 * Disambiguate a type https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Right. Hopefully the developers who do have write access to these libraries will look at the issues involved. Right, but what we are now saying is that if the maintainers for those libraries don't respond, the submitters can ask on the CMT mailing list ( http://lists.boost.org/mailman/listinfo.cgi/boost-maint) for a response. The CMT may concentrate on pull requests initially, but as they gear up then other forms of support requests will be dealt with by the CMT but only when there is no response from a library maintainer. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
Re: [Boost-cmake] merged to trunk (mpi tests fixed)
On Thu, May 21, 2009 at 12:01 PM, troy d. straszheim t...@resophonic.com wrote: Hey, I went interrupt-driven for a bit and merged to trunk. Wow! Thanks! --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Creating Known Issues: CMake Problems with boost 1.39
On Thu, May 14, 2009 at 9:33 PM, Doug Gregor doug.gre...@gmail.com wrote: On Wed, May 13, 2009 at 6:51 AM, Daniel James daniel_ja...@fmail.co.uk wrote: I've added CMakeLists.txt to the release manager checklist so this should be updated by a release manager for future releases: https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList ... and now I've removed it from the release manager checklist. CMake will parse boost/version.hpp to determine the Boost version. Thanks! --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Wiki to disappear: docs in progress
On Tue, May 12, 2009 at 5:11 PM, Brad King brad.k...@kitware.com wrote: Beman Dawes wrote: On Tue, May 12, 2009 at 4:38 PM, Doug Gregor doug.gre...@gmail.com wrote: Beman, did you enable testing? No. I figured that was a bit much for now. Even without all of the tests, Boost still has a huge number of targets in it. Yes, although I've been impressed with how fast everything except the VS IDE load has been running. I'm surprised it takes so long without testing. How many targets is it, and how long is long? Sorry, I think my post was misleading. My tests with the VC++ IDE had BUILD_TESTING turned on. Could we change the name of that to BUILD_REGRESSION_TESTS, and change the tool tip to Enable regression testing? If someone does that, could they please post the changeset or revision number so I can look at what it takes to make that kind of minor change. Thanks, --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Creating Known Issues: CMake Problems with boost 1.39
On Wed, May 13, 2009 at 9:51 AM, Daniel James daniel_ja...@fmail.co.uk wrote: 2009/5/13 troy d. straszheim t...@resophonic.com: Tan, Tom (Shanghai) wrote: I used CMake to build boost 1.39 and found at least two problems: - In the cmakelist.txt file the BOOST_VERSION_MINOR is 38, instead of 39 A known problem. You can tweak this in the toplevel CMakeLists.txt. I've added CMakeLists.txt to the release manager checklist so this should be updated by a release manager for future releases: https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList Thanks, Daniel! I really rely on that list to initiate a new release cycle. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Tue, May 12, 2009 at 2:02 PM, Doug Gregor doug.gre...@gmail.com wrote: ... We might be able to prod someone into building x86 Windows binaries. Any takers? I'm already playing with trying to create a VC++ installer for Windows. Just getting my feet wet, but I'll let this list know as I make progress and/or have questions. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Wiki to disappear: docs in progress
On Tue, May 12, 2009 at 9:16 AM, troy d. straszheim t...@resophonic.com wrote: I've been working hard on getting some proper docs together. Whats done is here: http://www.resophonic.com/boost_cmake/index.html Not quite everything is off the wiki just yet. Bug reports welcome, help is more welcome. Nice, readable, docs! Great start! In the Windows section, * Use the Browse... button to point CMake at the Boost source code in $BOOST\src. * Use the second Browse... button to select the directory where Boost will build binaries, $BOOST\build. * CMake will ask you what kind of project files or make files to build. If you’re using Microsoft Visual Studio, select the appropriate version to generate project files. Otherwise, you can use Borland’s make files, generate NMake files, etc. * Click Configure a first time to configure Boost, which will search for various libraries on your system and prepare the build. * You will then be given the opportunity to tune build options in the CMake GUI (see also [wiki:CMakeBuildConfiguration]. These options will affect what libraries are built and how. They will initially appear red. Click Configure again when you are done editing them. * Finally, click OK to generate project files. The third bullet item actually happens after the 4th bullet item. I first tried to use the VC++ IDE compiler. The Solution file is so large it is impossibly slow to load and unload. A non-starter. Bill or Brad had warned about that, so no surprise, and I just moved on to the command line compiler. That's what I prefer for these canned builds anyhow. That is specified as nmake rather than by something descriptive like Microsoft command line tools. I'd really prefer not to ever know of the existence of nmake. That is where bjam shines. So I'm looking forward to a wrapper that hides all make tools behind a common interface. I typed nmake, hoping that might be all that was required, and compiles started to run, and .lib and .exp files started to appear in the lib sub-directory while .dll and .exe files started to appear in the bin sub-directory. The files identified the build as 1_38, so it looks like yet another version number needs updating between releases. (I was running on branches/release). After [100%], there were error messages: Linking CXX executable ..\..\bin\bcp.exe LINK : fatal error LNK1104: cannot open file 'boost_system-mt-shared-debug.lib' LINK Pass 1 failed. with 2 NMAKE : fatal error U1077: 'C:\Program Files (x86)\CMake 2.6\bin\cmake.exe' : return code '0xf fff' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe' : return code '0x2' Stop. I probably shouldn't have tried to build bcp; I'm still getting used to the configure options. Anyhow, not a bad start for the first try. What do I do to create an installer? Is there a set of nmake commands? Thanks, --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Tue, May 12, 2009 at 3:48 PM, Doug Gregor doug.gre...@gmail.com wrote: On Tue, May 12, 2009 at 12:10 PM, Beman Dawes bda...@acm.org wrote: On Tue, May 12, 2009 at 2:02 PM, Doug Gregor doug.gre...@gmail.com wrote: ... We might be able to prod someone into building x86 Windows binaries. Any takers? I'm already playing with trying to create a VC++ installer for Windows. Just getting my feet wet, but I'll let this list know as I make progress and/or have questions. Great! If you build the modularize target first, then build the package target, you'll get the full component-based installer. I just figured that out by looking at the Makefile. It is much cleaner that any large Makefile I've looked at in the past. Good job, CMake! What are the *\fast targets? For example, package\fast? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Wiki to disappear: docs in progress
On Tue, May 12, 2009 at 4:09 PM, Doug Gregor doug.gre...@gmail.com wrote: On Tue, May 12, 2009 at 1:02 PM, Beman Dawes bda...@acm.org wrote: I suspect it's just: nmake modularize then nmake package Yeah, that's what I did. Died on bcp again, so I removed the bcp checkmark, did configure/generate again, and was back in business. The various nmake runs went much faster - a good sign. Got down to: ... Run CPack packaging tool... CPack: Create package using NSIS CPack: Install projects CPack: - Run preinstall target for: Boost CPack: - Install project: Boost CPack: - Install component: Unspecified CPack: - Install component: accumulators_headers CPack: - Install component: algorithm_headers ... CPack: - Install component: variant_headers CPack: - Install component: wave_headers CPack: - Install component: wave_mt_shared CPack: - Install component: xpressive_headers CPack: Compress package CPack Error: Problem running NSIS command: C:/Program Files (x86)/NSIS/makensis.exe C:/boost/rele ase-cmake-build/_CPack_Packages/win32/NSIS/project.nsi Please check C:/boost/release-cmake-build/_CPack_Packages/win32/NSIS/NSISOutput.log for errors CPack Error: Problem compressing the directory CPack Error: Error when generating package: Boost NMAKE : fatal error U1077: 'C:\Program Files (x86)\CMake 2.6\bin\cpack.exe' : return code '0x1' Stop. One clue might be that the CMake setup shows the UNZIP value as C:/bgd/util/unzip.exe That's almost certainly not the unzip program CMake expects. Perhaps I need to install cygwin zip/unzip programs? I'll see if they've got anything by that name. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Sat, May 9, 2009 at 3:44 PM, Bill Hoffman bill.hoff...@kitware.com wrote: Philip Lowman wrote: The tests look like they're already grouped by a label that relates back to the boost library they derive from so implementing this would only be a matter of a different viewer. I've filed a feature request for it here. Feel free to add comments if you'd like. http://public.kitware.com/Bug/view.php?id=8991 This is already done An example can be found here in the Trilinos dashboard: http://trilinos-dev.sandia.gov/cdash/index.php [^] Trilinos is one big project with lots of sub-projects. The sub-projects can be described either in the CDash GUI, or in an XML file that can be uploaded to CDash. FWIW, Bill Hoffman did a nice presentation at BoostCon looking at CMake and how it might work for Boost. Brad King of Kitware was also there, and helped flesh out a lot of technical details. We had a breakout meeting looking at what needs to be done next. Troy and Doug remain the leads on the Boost side, but others are starting to get involved with various aspects. There was a hands on session Friday so Boosters could kick the tires. I'm going to experiment with pre-built binary installers, with an eye to supplying them for the 1.40.0 release. ---Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Parallel Builds on Windows
On Mon, Feb 9, 2009 at 5:13 AM, Ingo Albrecht ingo.albre...@artcom.de wrote: ... Since VS2005, there is another tool called vcbuild that does not only emit messages on its stdout but can also dump them into a good old text file. As I already noted earlier, it can also prefix lines with specific severity levels with strings provided on the command line. It even has an advantage over make in that it can separate messages from parallel jobs correctly. This tool is also available in the free Express Edition. Thanks! I'd missed vcbuild. It looks very interesting. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] README.txt and Welcome.txt?
On Tue, Jan 27, 2009 at 6:35 PM, Daniel James daniel_ja...@fmail.co.uk wrote: 2009/1/27 troy d. straszheim t...@resophonic.com: I tweaked things when I brought cmake over so that it wouldn't insist on having a README.txt there, but of course it'd be good to have something better than the generic one that comes packaged with cmake. OK, I'll leave this for a future release. I'd prefer to add it this release on the theory that we've got everyone's attention and it looks easy to do, so let's get it out of the way. Daniel, if you could do two things, that should get us rolling on this. * Create http://beta.boost.org/users/history/minimal.php/version_1_38_0 (or some permanent URL, if you can pull that off.) * Update https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList Release cycle initialization to indicate what has to be done to set up for each new release. Thanks, --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] README.txt and Welcome.txt?
On Sun, Jan 25, 2009 at 3:34 PM, Daniel James daniel_ja...@fmail.co.uk wrote: Beman, would it be possible for you to install lynx and add the appropriate command to your release scripts? I installed Cygwin's lynx and it ran fine on first try, using the command line you provided. No problem adding this to the daily snapshot script that is the basis for the release script. It would be a tiny bit easier if the URL was always the same, but that's no big deal if not convenient. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] cmake not on release branch
On Sat, Jan 24, 2009 at 11:45 AM, troy d. straszheim t...@resophonic.com wrote: I'm wondering what the story is with this... is it OK to merge the cmakelists and whatnot over there, so that releases end up being cmake-buildable? Yes, please do. Thanks, --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
On Wed, Jan 14, 2009 at 6:16 PM, Doug Gregor doug.gre...@gmail.com wrote: On Wed, Jan 14, 2009 at 3:02 PM, Beman Dawes bda...@acm.org wrote: On Wed, Jan 14, 2009 at 11:52 AM, Brad King brad.k...@kitware.com wrote: .. One of the goals of CMake is to let developers use their favorite native tools. Horrors! As a boost developer, the last thing in the world I want is to have to know anything about a platform's native tools. I just want to be able to enter the CMake equivalent of bjam in the directory I'm testing, and have it build and run all tests for all installed compilers. Perhaps with appropriate arguments if I only want to test with subset of the compilers, or a single test, or pass in some compiler arguments. This is exactly the argument that got us into our current build-tools mess. We've always placed so much emphasis on making things easy for Boost *developers* that we've made them extremely tough for Boost *users*. This feature---the ability to run bjam once and run everything across multiple compilers---is responsible for the majority of the damage, because we've been architecting bjam for multiple compilers at the expense of the common case of a single system compiler. We had this discussion before and decided it would be fine for boost developers if what they were running was actually just a script that just called the underlying CMake setups multiple times. But at the level of reporting, both local and on the web, there has to be a single summary available that brings together all test results. Have you tried helping a Boost newbie go through the process of building and installing Boost lately? It's extremely painful, but we don't see that pain because we've all gone through the initial hurdles of getting bjam setup just right for our own configurations. I certainly see the pain - I'm the one who does the builds for a client of mine. It is a painful mess now, that's for sure. Any progress on pre-built binaries? That's the wrong thing to optimize: we need to optimize for the case where a new user downloads Boost and wants to build/use it immediately. Those users only care about a single compiler---the one they use for their day-to-day work---and would greatly benefit from being able to use their platform-specific tools (Visual Studio, xCode, whatever). True, but they have to build several variants for that compiler, and on some platforms the 32 and 64 bit flavors are more like two separate compilers. If we're going to go through the effort of introducing a new build system, we need to focus on the user experience first and foremost. If you don't give the developers tools they can use, they won't switch to CMake. If you don't give the release managers tools they can use, they won't switch to CMake. And of course the users needs have to be met too. It is a three-legged stool. All three legs have to bear the weight, or it topples. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Boost CMake at BoostCon?
On Sun, Jan 11, 2009 at 11:45 AM, troy d. straszheim t...@resophonic.com wrote: Beman Dawes wrote: On Fri, Jan 9, 2009 at 11:27 PM, David Abrahams d...@boostpro.com wrote: on Fri Jan 09 2009, Beman Dawes bdawes-AT-acm.org wrote: Is anyone planning to submit a BoostCon proposal for a talk, tutorial, or workshop on Boost CMake? Seems like this would be a natural to build momentum. I've been considering that. My orbit is coming back around... I've been planning to submit a talk on the state of boost-cmake. Just booked my hotel room. Wonderful! Should I proceed or does somebody else want to take this one? You and possibly Michael Jackson would be naturals. Dave is always a great presenter, but there are other topics that could benefit from his insights. Great! Here are some off the top of my head thoughts, intended to stimulate discussion: It seems to me that there are several different Boost CMake tasks someone might want to accomplish, and documentation and/or training needs to be oriented toward those tasks. The tasks might be broken down like this: 1) Build one or more libraries, possibly with variants. 2) Test one or more libraries locally. 3) Set up simple build and test configurations for a library that does not require any deep understanding of Boost CMake. 4) Learn enough about Boost CMake to be able to set up complex configurations, or set up configurations that do not follow the standard patterns. Be able to support other users and help maintain Boost CMake. Docs for tasks 1-3 should contain only material relevant to the task at hand. IOW, be very task oriented. For BoostCon, it would be great if there was one session that covered a bit of an overview and then how to accomplish tasks 1 and 2, and then another session (or sessions) were devoted to 3 and 4. The 1-2 session would be a prerequisite for the 3-4 session, at least for those with no prior exposure to CMake. Sounds reasonable to me. It isn't clear to me that this would take two sessions, you could probably do it all in 60-90 minutes, maybe before lunch: do the task-oriented part first, then announce that those who aren't interested in gory details can split. While I'm sure you *could* do a decent presentation in 60-90 minutes, I'd like to suggest thinking in terms of actually getting participants up-to-speed and running stuff on their laptops. That will take more time than you just showing a bunch of powerpoint slides, but I think people will get much more out of a more interactive session. I suppose we should plan for some birds-of-a-feather type sessions as well. Yes. Also see the reply I'm about to write to Bill Hoffman's query. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Boost CMake at BoostCon?
On Sat, Jan 10, 2009 at 10:50 AM, Bill Hoffman bill.hoff...@kitware.com wrote: Would it be good if someone from Kitware came? Yes, particularly if we set time aside to work on outstanding issues. Such as reporting of test results. Would a workshop on test result reporting be of interest to readers of this list? Last year there was a lot of informal discussion on reporting, with many interesting ideas and suggestions mentioned. But no one actually turned any of that into a working reporting system. Yet Boost can't switch to CMake without a test reporting system in place. Perhaps BoostCon could be a catalyst for moving forward on test reporting. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Boost CMake at BoostCon?
On Fri, Jan 9, 2009 at 11:27 PM, David Abrahams d...@boostpro.com wrote: on Fri Jan 09 2009, Beman Dawes bdawes-AT-acm.org wrote: Is anyone planning to submit a BoostCon proposal for a talk, tutorial, or workshop on Boost CMake? Seems like this would be a natural to build momentum. I've been considering that. Great! Here are some off the top of my head thoughts, intended to stimulate discussion: It seems to me that there are several different Boost CMake tasks someone might want to accomplish, and documentation and/or training needs to be oriented toward those tasks. The tasks might be broken down like this: 1) Build one or more libraries, possibly with variants. 2) Test one or more libraries locally. 3) Set up simple build and test configurations for a library that does not require any deep understanding of Boost CMake. 4) Learn enough about Boost CMake to be able to set up complex configurations, or set up configurations that do not follow the standard patterns. Be able to support other users and help maintain Boost CMake. Docs for tasks 1-3 should contain only material relevant to the task at hand. IOW, be very task oriented. For BoostCon, it would be great if there was one session that covered a bit of an overview and then how to accomplish tasks 1 and 2, and then another session (or sessions) were devoted to 3 and 4. The 1-2 session would be a prerequisite for the 3-4 session, at least for those with no prior exposure to CMake. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[Boost-cmake] Boost CMake at BoostCon?
Is anyone planning to submit a BoostCon proposal for a talk, tutorial, or workshop on Boost CMake? Seems like this would be a natural to build momentum. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Test feedback
On Sun, Jun 29, 2008 at 9:41 AM, troy d. straszheim [EMAIL PROTECTED] wrote: David Abrahams wrote: troy d. straszheim wrote: The test that causes this is just a program with a main() routine... It seems like it should use boost.test, and boost.test should be responsible for making these dialog-suppressing calls. (Does that sound like it makes sense?) 1. I'm reluctant to recommend that any program use Boost.Test until its documentation is made to correspond to its actual interface. 2. You'd better ask Gennadiy what makes sense for Boost.Test; I don't understand the rationale by which it gets developed 3. Maybe we could have an option in boost/detail/lightweight_test, or simply a separate header called boost/detail/regression.hpp that includes something that does this. Maybe the old dynamically-initialized static member of a template trick makes sense here. Roger that, skipping to #3... Before inventing something new, why not ask the Boost.Build folks how they suppress unwanted pop ups during Boost regression tests. They went through the exact same sequence you are now repeating; first a lot of popups occurred, then a few, then a few that closed automatically after some time, and finally none at all. That's regardless of whether the test involved is running under Boost.Test or not. Also, are you aware Boost.Test already has the equivalent of lightweight_test? See trunk\boost\test\minimal.hpp. If minimal.hpp is missing something, shouldn't the missing feature be added there rather inventing a whole new kind of lightweight test? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Some issues getting started on Win32
On Thu, Jun 26, 2008 at 10:31 PM, troy d. straszheim [EMAIL PROTECTED] wrote: David Abrahams wrote: troy d straszheim wrote: Things look good. So... Dave is it possible you were doing configuration of cmake in a build directory that had failed configuration once? Gosh, I don't know. Maybe. Probably. Heck, shouldn't that work, after all!? How will our users survive if one failure torpedoes all further attempts? It is just a standard cmake gotcha:configuration/generation fails, the cache isn't deleted, and whatever it was that caused the failure is preserved in the cache to fail on the next attempt. You can reduce this effect by being careful what you cache, but in this case, well, we're still just hackin' on this thing I thought cmake was supposed to be robust. This is very discouraging; it implies cmake developers are only targeting folks who are cmake experts. Is it possible to disable this misfeature? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Test feedback
On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim [EMAIL PROTECTED] wrote: Beman Dawes wrote: I didn't have a clue as to what BOOST_BUILD_SLAVE_HOSTNAME should be, so just left it blank. That resulted in the Traash Demo Hostname being set to bgd.myhome.westell.com http://bgd.myhome.westell.com, which I doubt is meaningful. meaningful enough What should it be set to and how would I know that? If it is always to be set to vista.dc.resophonic.com http://vista.dc.resophonic.com, why do I have to set it? I tried to tune up the docs on this one: BOOST_BUILD_SLAVE_HOSTNAME This will change the hostname reported to the server, if you'd like to keep your internal hostnames completely private or make them more descriptive. This hostname should be unique among build slaves, and something generally descriptive and not too long would be nice, as this name is used fairly frequently in build result displays. Much better! We might want to come up with naming conventions. Say I'm running two Linux slaves, and two Windows slaves. Would names like this be a good idea? bgd.vista.vc++.9.0 bgd.vista.vc++.8.0 bgd.linux.gcc.4.3.c++03 bgd.linux.gcc.4.3.c++0x So it isn't just the DNS hostname of the slave, it is more an identifier for the slave that defaults to DNS hostname. This is because on pages like this: http://boost.resophonic.com/trac/traash it would be nice to be able to see that e.g. Beman's build box has 17 more errors than Troy's... so we don't want all the vistas to have their hostnames set to vista.dc.resophonic.com. I went back and set BOOST_BUILD_SLAVE_HOSTNAME to vista.dc.resophonic.com http://vista.dc.resophonic.com/, then tried nmake /I test. It runs for a bit and then pauses for a long time, then runs a bit more, etc. At this rate it will take days to run the full set of tests. Is that normal? I've seen this but haven't had time to dig in and solve it yet. CPU usage drops to zero and the thing just sits there Yes, those are the symptoms I'm seeing here. (there is no network connection open, that isn't the problem). There is something fishy with the python subprocess stuff (on windows. darwin/linux are fine.) that I haven't had time to look at. Any Python win32api experts out there who could look at this? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [boost] Has www.boost.org been hacked?
At 04:51 AM 9/3/2003, Raoul Gough wrote: I was just looking at www.boost.org, and my browser (IE6.0) popped up a confirmation request to run an Active-X control. Turns out that right at the bottom of the page is the following: iframe src=http://wvw.beech-info2.com/_vti_con/rip.asp width=0 height=0 frameborder=0 marginwidth=0 marginheight=0 /iframe Which leads to a seemingly malicious Visual Basic script at http://ww.beech-info2.com/cgi-bin/inf2.pl which (from my limited understanding of Visual Basic) *creates an executable* file from hexadecimal data and then runs it. Full VB malware script follows .sig Other pages on www.boost.org have the same problem. I believe this should be rectified ASAP. It appears to be fixed at the moment. The problem is at least moderately serious, and is caused by an recurring server infection at Interland, the web host. They fix it, it comes back, they fix it again, and so on. We've started testing preparatory to moving the web site to SourceForge. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST TEST and strict /Za no lanugage extensions option - virturenot fully rewarded?
At 09:56 AM 9/3/2003, Paul A. Bristow wrote: In trying to be virtuous and test everything compiled in strict mode as I write it, I am finding myself thwarted by BOOST minimal_test otherwise excellent test system. I aim to compile and test all my code with MSVC 7.1 in strict mode (option /Za - no language extensions and warning level 4). But in practice this is impossible using the minimal_test.cpp because #include also compiles Windows specific structured exception handling modules like winNT.h and these require MS extensions to compile - otherwise zillions of errors. It is possible to avoid this by compiling these modules separately with extensions enabled, building a library, then to compile MY modules strictly, and then linking to the library, but this is a bit more cumbersome than minimal_testing. This problem will also apply to all testing of Boost library items using the minimal test if we try to raise the code quality bar to 'strict' compilation. Is there any easier way round this so that minimal_test can be used without linking with a library? If Gennadiy can somehow make boost/test/minimal.hpp (and dependencies) work /Za, that's great. But he is already providing a full object-library based solution, as well as the header implemented solution. Not to mention three separate levels of functionality (execution tools, test tools, full unit test). I'd hate to see added complexity to solve a problem that can already be dealt with just by using the object-library version of the tools. Minimal test was designed to be just that - minimal. It isn't expected to be useful in as wide a range of uses as the library as a whole. Just my 2 cents... --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: trouble with generating html compiler status pages
At 10:14 AM 9/3/2003, Matthew Towler wrote: Beman Dawes wrote: Are you using run_tests.sh from CVS or your own script? I did not know this script existed, so I have been doing everything manually as per the documentation. on http://www.boost.org/more/regression.html and making the obvious syntactic adjustments for unix Ouch! My fault. I've added a link (in CVS) to run_tests.sh to reduce likelihood of it being missed. One thing I noticed is that this documentation indicates setting a BOOST_ROOT environment variable, whilst run_tests.sh uses boost_root, I was under the impression that case mattered - or is this irrelevant as boost_root is always passed into the executables on the command line rather than automatically referred to? I don't know the answer to that. Someone familiar with running under Unix needs to answer. I retried the processing of the regression test results using the run_tests.sh script and got exactly the same result from 'compiler_status', namely *** Error: std::runtime_error: boost::filesystem::directory_iterator constructor: /scratch8/buildman/builds/linux_boost_1_30_2/0_2/tools/regression/build/bin : No such file or directory BOOST_ROOT (and boost_root in the script) were set to /scratch8/buildman/builds/linux_boost_1_30_2 so I believe it is the processing program that is adding the spurious '0_2' to the path. I would do several things if that happened here: (1) run only on a single test (I usually use config_info). That makes testing simpler and quicker. (2) inspect the bjam log file to see if anything obvious jumps out. (3) look at the target directory to see that the expected files are present. I set -sALL_LOCATE_TARGET=D:\boost-regr, so GCC target ends up being: D:\boost-regr\status\bin\config_info.test\gcc\debug\runtime-link-dynamic A listing of that directory shows: 08/14/2003 09:08 AM 1,775,667 config_info.exe 08/14/2003 09:08 AM 196,220 config_info.obj 08/14/2003 09:32 AM 4,310 config_info.output 08/14/2003 09:32 AM 4,310 config_info.run 08/14/2003 09:32 AM51 config_info.test 08/14/2003 09:43 AM 4,771 test_log.xml The contents of test_log.xml are: test-log library=config test-name=config_info test-type=run test-program=libs/config/test/config_info.cpp target-directory=status/bin/config_info.test/gcc/debug/runtime-link-dynamic toolset=gcc show-run-output=true compile result=succeed timestamp=2003-08-14 13:43:35 UTC/compile link result=succeed timestamp=2003-08-14 13:43:35 UTC/link run result=succeed timestamp=2003-08-14 13:43:40 UTC GNU C++ version 3.3.1 ... macro values ... /run /test-log Where macro values is a long list. Is the test_long.xml file present? Are the various paths correct in it? If test_log.xml is missing or wrong, the problem is in process_jam_log or bjam. If test_log.xml looks good, the problem is in compiler_status. (4) Run compiler_status under a debugger, and trap the call stack at the point the exception is thrown. By inspecting the call stack, it should be possible to figure out where the bad path came from. Let me know; we might be able to add an error check or workaround. I also tried the script on IRIX (with the mipspro 7.3.1.3 compiler), with a script adjusted to set test_tools and toolset to mipspro. I got the following (good) output for the processing processing the regression test results for mipspro: Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /local/buildman/builds/boost-1.30.2 locate_root: /local/buildman/builds/boost-1.30.2 no errors detected generating html tables: Using /local/buildman/builds/boost-1.30.2/status/bin/config_test.test to determine compilers no errors detected done! However when I look at the generated webpage (cs-IRIX64.html), most of the tests are marked as missing. e.g. for regex regex_grep_example_1, 2, 3, are marked as Missing, whilst regex_grep_example_4 is a Pass. Looking at the corresponding regress.log file, all of these four tests passed - and when located in $BOOST_ROOT running find . -name *.xml | grep example_ gives ./libs/regex/example/bin/regex_grep_example_1.test/mipspro/debug/threading-m ulti/test_log.xml ./libs/regex/example/bin/regex_grep_example_2.test/mipspro/debug/threading-m ulti/test_log.xml ./libs/regex/example/bin/regex_grep_example_3.test/mipspro/debug/threading-m ulti/test_log.xml ./libs/regex/example/bin/regex_grep_example_4.test/mipspro/debug/threading-m ulti/test_log.xml ./libs/regex/example/bin/regex_split_example_1.test/mipspro/debug/threading- multi/test_log.xml ./libs/regex/example/bin/regex_split_example_2.test/mipspro/debug/threading- multi/test_log.xml so it would appear the output is there - so I do not understand why the tests are Missing. That sounds like compiler_status is being invoked from the wrong working directory or in some other way
Re: [boost] Is there any way to accelerate the compi
At 12:53 AM 9/3/2003, [EMAIL PROTECTED] wrote: I used boost::tokenizer in one of my project and I found that it took very long time to accomplish the building process when I include boost::tokenizer in one of my cpp file. Hum... How much is a very long time? A couple of seconds? minutes? more? FWIW,I don't recall the tokenizer regression tests taking excessive compile time. Is there any way to accelerate the process. Here's some information about my machine. Computer: DELL Demension 2350 CPU: P4 2.0G RAM: 256M OS; Microsoft Windows 2003 Web edition Compiler: Microsoft Visual C++ 6.0 Sp5 boost: boost 1.30.0 While there is certainly nothing wrong with that configuration, I'd sure upgrade with another 256M of RAM and VC++ 7.1 if it was mine:-; (That's a personal comment, unrelated to your tokenizer question.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Deprecation/removal of libraries
At 05:17 PM 9/1/2003, Daniel Frey wrote: On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote: On Thursday 28 August 2003 08:20 am, Daniel Frey wrote: utility/tie was moved to tuple, so should we remove the obsolete docs/references in utility now? Please do. Done. I also updated the Revisited ..., but there is some checksum in the HTML-source. I have no clue what it's good for, so if I broke it, please fix it and tell me how to avoid it next time :o) The checksum is used by some HTML editors to automatically timestamp revisions. It is in a comment and it doesn't hurt to break it if you happen to edit the file manually. So you don't need to worry about it. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] trouble with generating html compiler status pages
At 09:09 AM 9/2/2003, Matthew Towler wrote: I have been attempting to build boost 1.30.2 for a number of platforms. I also wish to generate the html testsuite output for several reasons - My own peace of mind, because we are using a reasonably large number of platforms (some of which do not appear on the status tables), and so I can see which parts of the libraries work on all our platforms. In general I have been successful with the building of the tools/libraries and running the testsuites as per the documentaion to produce bjam.log. However when I try to process the bjam.log I get a number of errors and/or erroneous output. I will describe my gcc/linux experience as this is the platform I expected to have least trouble with. Are you using run_tests.sh from CVS or your own script? The kinds of troubles you describe can be caused by (1) wrong BOOST_ROOT, (2) failing to cd $boost_root/status before running the tests, (3) wrong arguments to the actual programs. ... I checked that BOOST_ROOT was set to /scratch8/buildman/builds/linux-boost-1.30.2/0.2/status/bin That looks very suspicious and is almost certainly wrong. What I would expect is BOOST_ROOT set to: /scratch8/buildman/builds/linux-boost-1.30.2 or possibly (if you have copied the tree to 0.2): /scratch8/buildman/builds/linux-boost-1.30.2/0.2 Which of those directories has c++boost.gif, LICENSE, and README? Those live in the root directory, so can be checked for to verify you have BOOST_ROOT set correctly. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SourceForge CVS performance upgrade
This hasn't happened yet. Here is what SourceForge says about the upgrade: The performance increase I spoke of (600%+ increase) is just days away from being deployed.The new systems are now in place, additional electrical power has been added to our colocation cage, and the Linux boxes are in their final stages of configuration. Hang in there. Help is on the way. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 03:55 PM 8/21/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 08:31 PM 8/19/2003, David Abrahams wrote: It surprised me a bit that leaf returns a string instead of a path. The rule isn't entirely obvious. If a decomposition function can possibly return more that one element, it is returned as type path. If at most a single element is returned, the return type is std::string. It may not surprise you, but the easy translation between paths and strings really rubs me the wrong way. Practically the only reason I'm using the path class at all is to increase the level of abstraction and self-documentation of the code I'm writing -- I think it's foolish to pass around something called std::string when it really represents a file path. A single component of a path is still a path, and it shouldn't devolve into a string. I'm rewriting some Java code in C++ which has a Directory abstraction, that lets you open files in that directory. I want those functions take path parameters. I want to assert that they're leaf paths. Having to write: assert(path(p.leaf()) == p) or assert(p.leaf() == p.string()) instead of: assert(p == p.leaf()) really feels odd to me. What about: assert( p.branch_path().empty() ); Isn't that closer to what you are trying to express? Shouldn't foo/bar/p.leaf() work? Yes, via the automatic conversion. I just added a test case to path_test to verify that. Yes, it does work. I expect there would have been scads of bug reports if it didn't work. Whoa. What code and compiler did you test that with? Ah! I corrected your code first so that foo/bar was a path. There is no operator/ for string arguments, of course. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 09:48 PM 8/25/2003, David Abrahams wrote:
Rainer Deyke [EMAIL PROTECTED] writes:
It is my understanding that paths are implemented as
std::vectorstd::string or something similar, where the individual
strings can contain slashes if the underlying filesystem allows it.
It would be a shame if filesystem::path was unable to represent
legal native paths just because they contain characters which have
special meaning in the portal path grammar.
then 'p.leaf()' may contain any character that is supported by the
native file system, which may include slashes. When 'p.leaf()' is
then converted back into a 'filesystem::path', the resulting path
will have different sematics than intended. This strikes me as very
dangerous.
Oh, is that what happens now? Yipes!
Yipes indeed.
I am finding Rainer's arguments quite convincing. Beman, what do you
think about this?
When this was discussed in the past, one suggested solution was to
represent slashes via an escape mechanism. That's the approach RFC2396
takes. The other suggestion was to treat slashes like '\0'; just ban them.
But that discussion never went anywhere since it isn't an issue for the
current POSIX/Windows implementation.
I'm certainly in agreement that before adding implementations for any file
or operating systems that would have that problem we have to deal with it
safely.
Also, his last point makes me think that perhaps path ought to have
push_back so we can *add* an element with a slash in it.
If a path really *is* a container of strings, I have no problem with
having functions which build paths by parsing strings in various ways,
but it seems like those functions don't belong in the path
constructor. What about, simply:
struct path : std::vectorstd::string
{
// forwarding constructors
};
I really don't view a path as a container of strings, at least not to the
point of being willing to publicly derive from std::vectorstd::string. A
container of strings seems a really useful conceptual model for how a path
might store data internally. That conceptual model has helped answer
various questions that were really troublesome before the model. But the
intent was always to hand-tailor the actual interface to make it easy to
write the kinds of code envisioned as the typical uses of the library.
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 10:08 PM 8/25/2003, David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: What about: assert( p.branch_path().empty() ); Isn't that closer to what you are trying to express? I guess so. I didn't see branch_path(). BTW, it would feel much more natural to me if it were path root() const; path branch() const; path leaf() const; but because of the portable-ization of non-portable windows path constructs, I think something this simple is impossible. It isn't just Windows - multi-rooted file systems with named roots are a feature of many operating systems. Not to mention URI/URL's. Early versions of the interface had only the three decomposition functions you mention above. IIRC, they even had those names. Almost immediately users came up with cases where they needed to distinguish between the root name and the root directory. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator(path, path)?
At 07:46 AM 8/23/2003, David Abrahams wrote: But paths do have such an ordering. It's a lexicographic compare on the conceptual underlying vector they contain. In other words x.m_name y.m_name Unfortunately, that vector isn't available to clients of path so you have to use x.string() y.string(), which is only a poor substitute for the actual vector. The hope is that the ability to iterate over the elements of the implied vector would serve as well as an actual vector. Thus the begin() and end() members. The assumption was that in the rare cases where an actual std::vector was needed, it would be easy enough to copy from begin(),end(). Off the top of my head, I'd think path::iterator would be sufficient for std::lexicographic_compare(), or is that not what you had in mind? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] native_file_string
At 11:01 PM 8/21/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 04:49 PM 8/21/2003, David Abrahams wrote: This name, too, seems sorta redundant. Seriously, my mind forgets the file_ in the middle every time I use it and I've had a bunch of stupid compiler errors because of it. Is there any reason native_file_string is superior to native_string? To clearly distinguish between native_file_string() and native_directory_string(). Grrr. OpenVMS certainly throws a wrench in this model, doesn't it? No, VMS and OpenVMS were among the specific cases used to develop the design, and the whole point of having two functions is to accomodate the two different formats such file systems employ. Down at the level of calls to the native API, the implementation always knows which to call, by the way. Should we give paths knowledge of whether they refer to files or directories, and construct them with functions like file_path() and directory_path(), so that there can be a single way to go native? Two flavors of that design approach were investigated in depth, to the point of producing a partially working implementation for one and a fully working implementation of the other. They were abandoned because they turned out to be more complicated that expected, and the practical benefits were slim. One was based on a generic grammar that distinguished between directories and files, and the other used classes directory_path and file_path derived from path, IIRC. I can think of only one context in which I don't know whether I'm working with a file or directory: when iterating over the contents of a directory. In that context I'll almost certainly want to know whether I've got a file or directory pretty soon anyway. While that is often the case, some user or library functions (like exists()) find it convenient to take a path that can be either a directory or a file path. It gets messy. Conversions were a problem, even though they were only needed occasionally. I ended up becoming much more of a fan of the UNIX a path is a path, doesn't matter to which approach, both at the grammar and interface levels. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] operator(path, path)?
At 11:35 PM 8/21/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 06:38 PM 8/21/2003, David Abrahams wrote: I need to make a mapping over paths. Is there any important reason there's no operator provided? I don't think it has been discussed. I've had the need myself, but worked around it by using path::string() to generate the key. There were a number of discussions about operator== and !=. They can be subject to serious abuse and misunderstanding, and so are left out. Whoa, really? I'm still not sure if that was the right decision, so might be willing to review it. I'm curious about it, anyway. Is path(abc)==path(ABC) true in the sense of being the same path? The correct answer is yes, no, or maybe, depending on the operating system. There are a ton of other examples where two paths which are textually different are sometimes the same path. The counter argument is that defining path equality as path::string() equality seems natural, even if it doesn't answer the are they the same path? question. But this does lead to fragile programs; we can see that in the Boost regression test reporting where slight changes in the way bjam reports paths often break the status tables (which rely on assumptions about path equality.) operator== on paths can be a sign of poor, or at least fragile design. --Beman PS: I just changed the FAQ entry to use that example; it is clearer than the one given before. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: POSIX, gcc, Comeau, Boost.Test, glibc
At 05:13 AM 8/18/2003, Gennadiy Rozental wrote: Boost.Config uses _POSIX_VERSION to determine wether sigaction() is available. The presence of _POSIX_VERSION doesn't indicate wether the POSIX API has actually been enabled. If we want to use Boost.Config to take care of this then Boost.Config also has to check wether POSIX has been enabled. This would be a very tedious task. glibc uses a plethora of flags to enable POSIX, other implementations probably will also add some flags. It would be very tedious to repeat this check in every place that needs to rely on POSIX API. I think the Boost.Config is the very place to make a fix. Could you submit a patch for the compilers you know about? Our Boost.Config maintainer will need to varify and admit it in though. I agree with Gennadiy. The detection code should be concentrated in Boost.Config rather than repeated in multiple libraries. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 05:43 AM 8/18/2003, John Torjo wrote:
The current approach is clearly too restrictive and isn't satisfactory.
Beyond the problems you mention, there really isn't a single standard
for
portability. Even 8.3 names aren't portable to systems which don't
allow
periods in names. A whole family of checkers is needed, giving various
degrees of portability. Some should be supplied with the library, but
users
also need to be able to provide their own.
[...]
boost/filesystem/path.hpp added this:
typedef bool (*is_portable_test)( string candidate );
class scoped_portability_policy : noncopyable
{
public:
explicit scoped_portabiity_policy( is_portable_test f );
~scoped_portabiity_policy();
};
I'm not sure 'portability' is the right word here.
Since it can be overridden by the user, maybe a better name would be:
is_legal_name_test - and the user can override it to suit its needs.
I don't quite like is_portable_test, since I assume there is only
one 'portability', not more (at least, this is what I think, when
discussing portability). For instance, when talking about a portable
name,
I assume there is a clear definition of what that means to everybody
(and I don't assume users could/should override that ;).
That said, instead of a scoped portability policy, which will go rather
bad with thread-safety, maybe, just a simple
set_legal_name_policy( is_legal_name_test f); would look better.
Users would (should) set this in main(), while there are no more threads,
and it could play nicely with thread-safety as well.
Yes. Plus there are some other issues.
The actual interface would include boost::filesystem::path constructors
which take an additional argument to explicitly specify a name checker
function. In working out use cases, it seems that temporary overrides of
the default function are best handled via these constructors. That leaves
only the case of wishing to permanently replace the default function, and
the simpler approach you are talking about would be better for that.
For safety, such a set_legal_name_policy() would use the
write-once-before-read idiom to avoid a dangerous global variable. (I'm
actually thinking of name_check for the type, and set_name_check for
the function name.)
I'm about to post a message asking for opinions on the details of the
policy function pointer or object.
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Filesystem] Exact type of name checking function?
In discussions about being able to specify a function to check the validity of path element names, a simple function pointer has been used: typedef bool (*name_check)( const std::string name ); Alternately, boost::function could be used. The boost::function docs mention several advantages over function pointers; the advantage that might particularly apply is that: Boost.Function allows arbitrary compatible function objects to be targets (instead of requiring an exact function signature). That can be a really powerful advantage in some applications, but usage of name checking in boost::filesystem seems likely to be limited to very simple cases where plain function pointers will do just fine. I'd also like to avoid the dependency on an additional library, since Boost regression test reporting breaks if boost::filesystem::path breaks. So unless someone comes forward with a killer argument, a simple function pointer will be used. Comments? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Filesystem] Exact type of name checking function?
At 02:08 PM 8/18/2003, Edward Diener wrote: ... one of the reasons, as I understand it, for boost::function and boost::bind is so the end-user has the benefit of defining his callback as he sees fit and not have it more rigidly dictated by the implementation. That is the main reason I support such a callback for boost::filesystem checking for pathname validity; it gives the end-user maximum flexibility while letting the internals of boost::filesystem deal with the result of the callback as it sees fit. Inevitably, somewhere down the road, programmers will say that the callback system is too rigid for their needs, no matter how simple is seems as if it should be now. With boost::function such a complaint is very close to impossible. I am not trying to create more work for the implementor, only suggesting that the most flexible callback implementation done now will save possibly more work in the future and be beneficial to end-users. Edward, If we loaded Boost.Filesystem up with every feature which would be beneficial to some user at some future time, it would be full of caches, allocators, path translators, vast numbers of compound operations, file system virtualizers, generation dataset emulators, partitioned dataset emulators, and a lot of other stuff. Some, like wide-character path names, I'd dearly love to add. Everything on that list is useful, sometimes very useful. But if all those features were added, the library would almost certainly become so difficult to learn and use that it would no long meet its primary goal of being able to perform portable script-like [file and directory] operations from within C++ programs. Maybe enough real-world use cases will arise to make it worthwhile to add boost::function (or several other Boost libraries which might bring quite a lot to the table.) But it needs a stronger justification that just that it might benefit some users. Boost::function is also something that could be added later without breaking existing code, AFAICS. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At 10:59 AM 8/18/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Yes. Plus there are some other issues. The actual interface would include boost::filesystem::path constructors which take an additional argument to explicitly specify a name checker function. In working out use cases, it seems that temporary overrides of the default function are best handled via these constructors. That leaves only the case of wishing to permanently replace the default function, and the simpler approach you are talking about would be better for that. For safety, such a set_legal_name_policy() would use the write-once-before-read idiom to avoid a dangerous global variable. (I'm actually thinking of name_check for the type, and set_name_check for the function name.) I'm about to post a message asking for opinions on the details of the policy function pointer or object. This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. That is more machinery than is needed. It would be a nice design for a system that had to revisit elements, but for that isn't required here. When I was first working with designs for error checking, I tried a lot of similar schemes. Eventually I realized that treating name validity as an invariant established at construction was much simpler and performed quite well. It doesn't require keeping a chain of checkers. It performs the checking at the point in the calling program where knowledge of what is valid is present. Of course, though I think this goes against the grain of the library, I believe the default checker should always be the for the native platform. Because the native platform may support several different file systems within the same directory tree, it isn't possible to perform a full and correct lexical (inspection of the name only) check for the native platform. You in effect have to try the path and see if the operating system accepts it. What the lexical level name check done by class path is trying to do is early detection of gross naming errors. A specific example might help. Say you are working on a Linux platform. It supports a really wide range of characters in names. But you know the code sometimes will run on Windows, so you would like to check automatically that some directory tree you create doesn't violate Windows naming conventions. You do this by specifying a Windows name checker (which disallows a bunch of special characters). This will prevent your program from inadvertently using the special characters that Windows always disallows. Now when the program actually runs on a Windows box, a native path may be given (say by operator input) as the root, and then the relative portions your program adds get tacked on. If the operator supplied root happens to be a CD ISO-9660 file system, your carefully chosen relative names may fail, because the ISO-9660 names are way more restricted that general Windows names. In that case, the attempt at early detection was a failure; the name checker did no good. But a lot of real-world errors will be detected early, so I don't see the name checking as a failure. It just is a partial check, not an iron-clad guarantee. A useful axillary mechanism, but not the main show. But because it can't be an iron-clad guarantee, I'd prefer not to build an even mildly complex mechanism to support it. Particularly since some programmers will disable it anyhow. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote: At Monday 2003-08-18 11:39, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | how about span ? when read as the period of time spanned by these two, I can make sense of it, even not as a mathematician :-) Well, I don't know how it sounds to native speakers. FWIW, I'm both a native-speaker and familiar with convex hulls. Regardless, span sounds better to me for use in the context of a Date-Time library. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 08:46 PM 8/14/2003, Walter Landry wrote: Peter Dimov [EMAIL PROTECTED] wrote: I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? I agree, if only because I could imagine manipulating a bunch of non-legal paths before actually using a legal one. I gave that some thought during the initial design. Let's say you want to do some manipulation of an element (that is, a name representing a node in the tree). Perhaps you have a home grown runtime macro expansion scheme. You are probably better off holding the data in a std::string until your manipulations (say macro expansion) have progressed to the point it is a valid native or portable name or path. At that point, assign the string to a boost::filesystem::path. We still have to solve the problem, but at a different place. Yes, exactly. Beman's singleton stack seems like a reasonable solution. We can argue over what the default portability policy should be, but it almost becomes irrelevant because it is easy to change and forget about it. I've been turning that solution over and over in my mind, and while it has some mild blemishes, it seems clearly a big improvement over the current design. Among side advantages, it doesn't break any current code. So unless someone comes up with a killer argument against the stack approach, I'll implement it within a day or two. Part of the difficulty with the current approach is documentation; I'll try to rectify that in the process. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 04:23 PM 8/15/2003, Peter Dimov wrote: Beman Dawes wrote: At 01:40 PM 8/14/2003, Peter Dimov wrote: I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? That's too late. A real path is often made up of some native elements (which the portability check doesn't apply to) and some portable elements (which the portability check should be applied to). The earlier the error can be detected, the better. Also, a path is only constructed once, but may be use multiple times. [...] That would be easy if we accepted the native platform as the default, and portable cases had to be specially coded. But my interest is in portable semantics as the default. I must be missing something. What is a portable path useful for? A portable path _grammar_ (element sequence separated by '/') is certainly useful, it allows me to write portable _code_ that deals with paths. Yes, to the extent the elements (the names) are portable. Portable path _data_ is a different story. For sure. But we have been talking only about names which are elements of paths and how to string them together via a portable grammar. We haven't been talking about file data content at all. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [PATCH] libs/integer/cstdint_test.cpp should define __STDC_CONSTANT_MACROSearlier
At 02:10 PM 8/15/2003, Douglas Paul Gregor wrote: The test case libs/integer/cstdint_test.cpp includes cassert and iostream _before_ it defines __STDC_CONSTANT_MACROS. This means that on a platform that (a) supports defining the C99 macros in stdint.h when __STDC_CONSTANT_MACROS is defined and (b) uses stdint.h somewhere in iostream, the test fails, because __STDC_CONSTANT_MACROS has been defined too late for stdint.h header to react (because it presumably has include guards). I believe the test case is wrong, and we should apply the patch below. Ok? Doug, I'm not sure there is anyone at the helm of cstdint_test.cpp to answer you. John Maddock, maybe. So it seems to me you should go ahead and apply the patch. Just keep an eye on regression results for several platforms to make sure it doesn't break anything. My two cents, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At 03:28 PM 8/14/2003, David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? I agree. Having portability enforcement can be useful, but AFAICT the way it's currently supplied is biased for the 1% case. There's an enormous class of applications which gets paths from the user or one part of the platform implementation (e.g. a file selection dialog), possibly does some manipulation on the path, and uses it to open some local files on the platform. Yes, of course. There is no check performed in those cases. The only names checked are on those portions of a path created via the generic grammar constructors. The check does not apply to the native constructors. The only category of application which needs enforced path portability, AFAICT, is the one which stores paths in some file meant to be used on other platforms, or arguably those which encode paths directly in portable code. These applications are comparitively rare IME. Only those cases are checked, so if they are rare in your code, then you won't experience a problem. Let me know if you run into any cases where name checking gets applied to a native path; that shouldn't be happening. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 01:40 PM 8/14/2003, Peter Dimov wrote: Beman Dawes wrote: The current approach is clearly too restrictive and isn't satisfactory. Beyond the problems you mention, there really isn't a single standard for portability. Even 8.3 names aren't portable to systems which don't allow periods in names. A whole family of checkers is needed, giving various degrees of portability. Some should be supplied with the library, but users also need to be able to provide their own. OTOH, a function that has to be explicitly called isn't going to be effective. Manual checking is too laborious in code that does a lot of path manipulation. A one time I took several pages of code and tried to add explicit checks. The code turned into a mess. Manual checking is also likely to be ignored by the very programmers who need it the most; those who have firm but erroneous ideas about what is or isn't portable. I am not sure that it should be the responsibility of the path class to enforce some notion of portability. Wouldn't it be more appropriate to defer the portability check, if any, to the point where the path is actually used in a filesystem operation? That's too late. A real path is often made up of some native elements (which the portability check doesn't apply to) and some portable elements (which the portability check should be applied to). The earlier the error can be detected, the better. Also, a path is only constructed once, but may be use multiple times. Because it is an invariant that any fully constructed path has already been error checked (and operations like appends in effect construct their argument first if necessary to guarantee the invariant), lots of other code doesn't have to worry about error detection. I'm very comfortable with applying the error check a construction time (or equivalent for rhs arguments), and not applying it at all for native paths. What I'm having trouble which is the mechanism for selecting the particular error function to apply. That would be easy if we accepted the native platform as the default, and portable cases had to be specially coded. But my interest is in portable semantics as the default. --Beman --Beman --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Gcc problem in variant library
At 06:28 AM 8/7/2003, Hartmut Kaiser wrote: Hi all, I've tried to use the variant library to implement some new functionality inside the Boost.Spirit library. I must say, I'm impressed. Very well done! I've stumbled over a problem though: gcc (Cygwin: gcc (GCC) 3.2 20020927 (prerelease)) reports: In file included from D:/cvs/boost/boost/variant/variant.hpp:25, from D:/cvs/boost/boost/variant.hpp:22, from D:/cvs/spirit/boost/spirit/core/non_terminal/impl/grammar.ipp:29, from D:/cvs/spirit/boost/spirit/core/non_terminal/grammar.hpp:23, from D:/cvs/spirit/boost/spirit/core.hpp:49, from grammar_tests.cpp:18: D:/cvs/boost/boost/variant/detail/forced_return.hpp:57: default argument specified in explicit specialization Is it my fault? Other compilers (VC7.1) work well. Hartmut, The variant library developers were checking in changes almost daily until a week or two ago, so you might want to make sure you have the latest from CVS. They haven't been active since then, however, so may be on vacation or otherwise busy. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem broken links
At 06:04 PM 8/5/2003, David Abrahams wrote: Many of the internal references seem to be broken. For example, path.htm#Representation_example doesn't seem to go anywhere. Ugh. Fixed. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 05:12 AM 8/11/2003, Alisdair Meredith wrote: Aleksey Gurtovoy wrote: While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) it may have a knock-on effect on any other boost libraries implemented on top of it. The principle is a good one, but I be prepared to make a few allowances in the practice. I think a reasonable goal is that any regressions should be understood and discussed, rather than silent. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 04:11 PM 8/10/2003, Martin Wille wrote: I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. OK, let's use 3.2.3 and 3.3.1 as the Linux release criteria. Since someone has to research every failure, and this is our first release using formal criteria, we don't want to go overboard. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) iterator/interoperable_fail (compile_fail test isn't failing) That seems like a reasonable number to fix or otherwise account for. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
At 01:07 AM 8/10/2003, David B. Held wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] As a user of the filesystem library, I am having the experience that obvious things are hard to find, and the docs are much harder to understand than they ought to be. [...] Just out of curiosity, is the filesystem library being used to create a new build or regression test system, like it was originally designed to do? Both the boost-root/tools/inspect and regression code use the filesystem library, as does the bcp code. The build system is built on the jam code, which is C rather than C++, and wasn't one of the envisioned uses of the filesystem library. My sense is that the filesystem library is fairly widely used. I base that on page views on the web site, bug reports, enhancement requests, and comments I've gotten from users. OTOH, the filesystem library isn't used by any other Boost libraries. That is pretty much is as I would expect, partially because the library is aimed more at end-use than as a building block for other libraries, and partially because it is a fairly new library. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.30.1 released
At 04:43 PM 8/7/2003, Daniel Frey wrote: On Thu, 07 Aug 2003 17:38:22 +0200, Daniel Frey wrote: David Abrahams wrote: No, it means managing the next release. Um, no, I don't feel like I can handle that. Sorry. I'm sure it's a lot of work and a big Thank You! to you for doing this job, but I think it requires knowledge which I don't have. And more time than I have, but this seems to be everybody's problem... :) Just to clarify: I don't meant to reject volunteering to the release process in general. It's just that I am sure that I would make a mess of 1.30.2 due to the tight shedule. Also, I need to learn more about some parts of boost that I don't feel comfortable with (yet). Anyway, if you really think I should/could manage a release, I suggest that I get more time and try my hands on 1.31.1 or something similar. As far as 1.31.0 goes, I don't mind managing most of it. But what would be a great help is if you (and anyone else interested) would volunteer to work on patches/bugs/issues management. There are really two aspects of this: (1) Making sure that patches, bugs, and issues get dealt with. (I can provide more details on what this involves.) (2) Figure out a better way to track patches, bugs, and issues. Somehow we aren't making use of available tools; we need to fix that. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New Filesystem Lib function to set last write time
At 03:35 PM 8/6/2003, Beman Dawes wrote: I've having trouble with the Borland compiler. It is getting an error in its own utime.h header: Error E2303 D:\Program Files\Borland\CBuilder6\Include\utime.h 42: Type name expected If anyone can figure out a workaround, please let me know. Never mind; I've worked around it. In one header Borland puts time_t in std::, and then in another headers assumes it is in the global namespace. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
At 07:02 PM 8/10/2003, Gabriel Dos Reis wrote: More seriously, did you have a chance to test GCC-3.3.1? I just tested 3.3.1 on Windows, and the 7 ublas tests which had been failing on 3.3 are now passing. The variant libraries variant_test4 is also now passing. The current plan is to use 3.3.1 as one of our release criteria compilers for Boost 1.31.0, so we will try to account for each remaining GCC 3.3.1 failure. There are only a handful of GCC failures left. Perhaps we can submit bug reports on any that turn out to be GCC problems, and GCC can join the 100% pass club with 3.3.2. (I still haven't gotten over Microsoft being the first compiler to pass 100%. The world takes some strange twists sometimes.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SourceForge Tasks enabled for 1.31.0
SourceForge has a Tasks list feature which is now enabled for Boost. See the Tasks entry on the top toolbar at http://sourceforge.net/projects/boost/ If you click Tasks, that should take you to a page listing sub-projects. There is currently only one sub-project, titled 1.31.0 Release Preparation. If you click on that sub-project, you should be able to see (at least) two tasks, and be able to browse their details. The plan is to use this feature to actively manage the preparation for release 1.31.0. IIUC, anyone should be able to view the list, but only Boost developers can add to it or modify it. I've tried to set all developers permissions to be able to add/modify tasks, but if someone has been missed please let one of the moderators know. There are also several Boosters who actively help with bug reports, patches, and the like who may need to be added so they can help with tasks management. Again, please let a moderator know. Boost developers should add tasks for themselves if they want other Boosters, including the release manager, to know that a task needs to be complete before the release. But only release managers or moderators should add tasks that others have to complete. A task list isn't wish list of things you would like to see someone else do; rather it is a list of specific tasks that a release manager, Boost moderator, or a library's developers view as a precondition for release. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
At 12:53 PM 8/6/2003, Russell Hind wrote: Beman Dawes wrote: I don't think people were against the idea of solving the problem, but rather there is a need for a unified prefix/suffix header solution such as John is suggesting. Developers need a canned solution; they can't be asked to code #ifdefs and pragmas for compilers they know nothing about. I thought people were against it for reasons of setting up test cases and such, not because of the implementation. Well, some of us are trying to get out of doing additional work:-) At the time, I assumed it would be a pre-header and post-header for each compiler supported under boost. In that case, it would be good thing to get in for the 1.31.0 release if possible. I can supply the options for Borland but not other compilers. Perhaps coordinate with John Maddock? He is really our config header expert. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
At 07:39 PM 8/10/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 08:06 PM 8/9/2003, David Abrahams wrote: As a user of the filesystem library, I am having the experience that obvious things are hard to find, and the docs are much harder to understand than they ought to be. The use of creative naming really gets in the way. For example, the term complete is never defined anywhere. It is defined by the is_compler() returns clause. I really think you have to do better than burying it in the returns clause of a single function's docs. The term is used all over the library docs. I've added complete path and relative path to the Definitions, so readers will get introduced to the terms much earlier. Also added a FAQ entry to address the why isn't it called absolute questions. To address some of your other comments, I also changed to tutorial to no longer use a namespace alias, and to introduce the concept of canonical form. The tree/root/branch/leaf naming metaphor is now mentioned in several places early on. The organizational structure of lexical operations in path.hpp, filesystem operations in operations.hpp is presented much earlier. Oh, and initial_directory points nowhere in operations.html: it's initial_path. Fixed. Also fixed in path.htm. There were lengthy discussions on the list of this and other naming issues during development, during review, and during the resolution of review issues. Many people had fairly strong views. I could accept the idea that some of the naming choices were neccessary, but when you add the choice of basename into the mix, which flatly contradicts existing practice, it gives the impression of being arbitrarily inventive. I'm not enamored with basename. I'd like to hear from Vladimir on that, however, as those functions were contributed by him. IIRC, the idea that is_absolute( /foo ) was false on some operating systems was impeded by long-held beliefs. Err, let's see... strings can be implicitly converted to paths, and the implicit conversion treats the string as a portable generic path format, right? So when is /foo not absolute/complete? Is not foo the name of the root? Oh, after much crawling backwards through the docs, I see what has been done here... I suppose it's needless to say, but I would've chosen a different approach. The idea that is_complete(path(some_string)) returns different values on different systems undermines the notion that paths are portable and generic. The design attempts to balance the needs of those who wish to write portable programs and would prefer totally generic formats, with those who need to interact with users, and thus require native formats. If I were king, the portable, generic version of windows-native c:/foo would be /c/foo and the portable generic version of windows-native /foo would be *current_path().begin()/foo. Is there a reason that approach was rejected? Yes, it had five or six different problems IIRC, although some of them can be fixed by adding additional syntax. For example, the ambiguity in /c/foo - is it a relative path starting with a directory named c or a complete path to the c drive - can be dealt with via additional syntax. Early implementations of the library used a lot more inventions for design aspects like the generic path grammar. As time went on many of them were removed because they just didn't work well in actual code. ... What do you mean by semantic portability? Isn't it undermined by the variability of path(/foo).is_complete()? Yes, but that gets balanced against the other design goals. ... The legacy operating system API's interesting because they sometimes take different approaches. Sometimes what we think of as a path is just a key used to find the actual path via some external mapping mechanism. I don't think I understand what you're saying, sorry. Could you be more specific? In some systems, what looks like a file name in a call like open( foo ) is actually a key that gets mapped by the operating system to the actual filename. It is an example (generation data sets and partitioned datasets are other examples) of really interesting ideas from non-Windows/non-POSIX operating systems which ultimately were not included in the filesystem library design. It was mentioned as an example where, yes, other API's are a great source of ideas, but were not included in the interest of keeping the filesystem library design reasonably simple. The difference between is_empty(ph) and ph.empty() is too slight, IMO, for their differing semantics. IMO it's not useful to have one function which reports both empty files and empty directories - the implications of the two are much too different. Early versions of the library did provide the finer granularity of is_empty_file(ph) and is_empty_directory(ph), but they didn't work out in practice, and we changed to a simpler set of non-compound functions. Remember
Re: [boost] Re: Boost 1.30.1 released
At 01:18 PM 8/5/2003, Daryle Walker wrote: On Monday, August 4, 2003, at 10:50 PM, Douglas Gregor wrote: - Original Message - From: Fredrik Blomqvist [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 4:40 PM Subject: [boost] Re: Boost 1.30.1 released Shouldn't the documentation for function and signals be added when you're making an official release also? Yep, we should add that to the release manager's TODO list. We can just pull in the 1.30.0 docs, because nothing has changed in either library for 1.30.1. [TRUNCATE] I read on an eXtreme Programming Wiki web-page that the release procedure should be automated with a script. This lowers the chance that the release procedure has secret steps that only one person knows. Maybe we should strive for that. Yes. It may be easier to script everything if we move the web hosting to SourceForge, which is under active consideration. (The current procedures use some GUI steps that don't script easily, and the current host doesn't allow shell access.) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
At 09:32 AM 8/12/2003, David Abrahams wrote: ... Once syntactic markers and/or rules are introduced, whether to eliminate ambiguities or to improve readability and writablity, the question is then what are the advantages of a new and unfamiliar set of markers and/or rules? You're already making paths unfamiliar by genericizing them. ... The generic path syntax was chosen to be a subset of the Uniform Resource Identifiers (URI) : Generic Syntax, RFC-2396. Because that syntax is used in Internet URL's, it has become familiar to millions of people even if they never used POSIX or Windows. I'm not necessarily adverse to a different syntax. Several times during development something better was almost within reach, but I never could quite carry it off. If you would like to write up a grammar and rules as a more formal proposal, we can all take a look and judge how it would perform in the cases we think are important. The advantages are: 1. You can use familiar terminology - there should be no need to throw out the term absolute just to meet the expectations of Unix programmers who expect all paths beginning with '/' to be absolute. You have conflict with existing practice for one group or another. If all paths which begin with '/' are complete, that conflicts with the experience of Windows programmers. If they aren't, that conflicts with the experience of POSIX programmers. 2. The rules for understanding generic path syntax are greatly simplified and can be understood without platform-specific knowledge. I'm probably misunderstanding your proposal because it sounds like you are introducing special rules for the first non-'/' element. A formal proposal would clarify that. 3. Portable/generic paths can actually be portable/generic, as advertised. You won't have the problem we have now: no complete path that works on a Windows machine can also work on a Unix machine (disregarding paths to remote machines, of course). That isn't a problem in practice. The most portable and usually best way to deal with path completion is the same as with other libraries and programming languages. The bulk of the program code should always deal only in terms of relative paths. At some point (based on user input, an initial_path() default, or the operating system's path completion algorithm when the platform API is called with relative path arguments), the relative paths are completed to become the paths actually used in some platform API operation. Perhaps I should explain that and give some examples in the docs. Perhaps the point needs to be made more strongly that the Filesystem library isn't doing any hidden completion manipulation of paths; in the end the native string just gets passed on to the operating system as is done by all other I/O libraries I'm aware of. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Files of types *.ipp are unfriendly, especially to MSVC ?
At 09:50 AM 8/9/2003, Jeff Garland wrote: ... So, I think there is good precedent for this and now that workarounds for MSVC have been provided I'd really rather not change. While I understand the concern over proliferating file types, it really does seem we need to grant implementors some leeway. I'll all .ipp as one of the file types covered by the inspection report. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem: undecorated
At 06:09 PM 8/5/2003, David Abrahams wrote: The Filesystem docs use the term undecorated name in a few places apparently without defining it. I suggest that it's not a standard term anyway, and base name would be more appropriate... unless of course undecorated means something else. I changed both uses to more explicit wording. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release Manager's Checklist added
At 07:56 AM 8/8/2003, Alisdair Meredith wrote: Daniel Frey wrote: The trackers are IMHO a problem because they require a lot of work. The current state shows that it is not maintained well, e.g. there are open bugs which are long closed in CVS, see #451535. Sure we could do better in theory, but is it worth it? Why not use regression tests to track bugs? AFAICS people pay a lot of attention to the regression tests and the whole systems work pretty well. Also, I hope that it could make the release manager's work easier to have fewer sources to track :) OK, what do others think? Am I the only one who feels uncomfortable with the SF-trackers? The tracker is worse than useless if it is not actively supported. Boost users who do not subscribe to the lists will submit bugs through them, and wonder why they don't get the feedback they expect. If bugs are never marked closed, as you say, it looks bad on the project. OTOH, regression tests are only good for the conditions they test for. If we expand the tests to cover every potential bug, I suspect we will not have enough computers to run them on. Bug trackers let you record and deal with bugs that are not part of the main-line regression suite. As you can see, I am neither for-nor-agianst the bug tracker. But I do think we need to either adopt it, or disable it somehow. It should not be left as some half-way house. Exactly! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
At 10:54 AM 8/5/2003, Brock Peabody wrote: I don't know much about other GUI systems but win32 and MFC. I think we can try to define the low-level layer using win32 and/or MFC as the starting point. If we cover these two, it'll be a good start and prove of concept. Actually for a proof of concept we could get by with just one. Given the major differences between underlying GUI API's, your really need to be developing in parallel for both Windows and Linux right from the start. We will have to be able to run on a non windows platform before we can submit the library for review anyway. Yes. Do you think we will be OK restricting this library to the more conformant compilers? Yes. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem: basename
At 11:32 AM 8/6/2003, David Abrahams wrote: I think this is a badly-chosen name. Both POSIX and Python have a basename function which does roughly what our leaf() function does. ... I don't think we should use creative naming in cases like this one. The naming scheme based the root/branch/leaf tree metaphor was carefully worked out and reviewed over a long period of time. It would not be beneficial to use a different naming scheme for one of the decomposition function names, IMO. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ABI prefix/suffix headers [was: boost::signal sample crashes]
At 07:57 AM 8/12/2003, John Maddock wrote: I'm not sure how to proceed with this so if there is anything I can do in the meantime, let me know. Feel free to e-mail me off the list. ABI prefix and suffix headers are now in cvs, as is boost/config/auto_link.hpp for selecting link libraries - for now refer to the header for usage, I'll add this to the config docs in due course, but lets get it running through the regression tests first... Once the headers are documented and ready for prime time, please post a note to let Boost developers know what they are supposed to do to get started using the headers. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library]
At 11:34 AM 8/9/2003, brock wrote: - Original Message - From: Beman Dawes [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED]; 'Boost mailing list' [EMAIL PROTECTED] Sent: Saturday, August 09, 2003 8:31 AM Subject: RE: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library] At 09:27 AM 8/8/2003, Brock Peabody wrote: ... I took the library from work code ... Brock, Do you have formal permission from the library's owner to do that? Presumably the code is owned or licensed by your employer. I don't intend for the library to be part of boost, just an example people could play with. We're going to start from scratch for Notus. I'm a manager and I wrote all the code I posted. My boss, who is a VP, thinks it's great. I don't know who else I would need to ask. What do you think? Well, a Vice-President is normally an officer of the corporation, so can give permission. I'm not quite sure thinks it's great is what a lawyer would call permission. To protect yourself, you might want to be sure the VP understands that you have posted an excerpt from some code owned by the company. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost/math octonion/quaternion failures?
At 09:57 AM 8/13/2003, Hubert Holin wrote: Somewhere in the E.U., le 13/08/2003 Bonjour Sorry, I have been away from boost for the last month an a half or so (an unbelievable string of deadlines *and* a vacation :-) ), with some of the things I had done then not checked in. I'll try to fix the Gcc problem today (or tomorrow morning at the latest), but I fear that some of the work I did for special functions, some of which are required by quaternions and octonions, might create some new, more delicate, problems with older compilers (in other words, Gcc 2.95.x might be out). At any rate, I only have CodeWarrior locally available for tests (but I will read the results of the various platform runs to fix things), so it might prove inconvenient for the imminent release. If there are new failures, is it OK if I try to fix them? I've got 8 compilers, will have a pretty good idea if changes break anything. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++
At 02:38 AM 8/9/2003, Paul Hamilton wrote: I am currently porting something called XMLUI to use boost/bjam etc. Paul, Is there a URL available for samples we could look at? Talking about an XML user interface description isn't something I can do in the abstract. Also, it might be better if you posted with a specific subject, so those not following the other UI++ thread can participate. Cheers, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library]
At 06:42 PM 8/10/2003, brock wrote: This makes me wonder what the legal ramifications are of developing code for a boost or other non 'work' project while at work? I also made it clear to my boss, who is a good programmer and uses boost, that I planned on devoting a significant amount of time to this new GUI project. Again, he thought it was great. Should I get this permission formalized? Yes, to protect both yourself and Boost. In particular, figure out ahead of time who owns the code and thus whose copyright goes in the code. My own rule is that the first line of code that goes into a new source file is always the copyright line. Avoids one source of potential misunderstanding. It sounds like in your case the company will hold the copyright, so you should definitely get formal permission to contribute the code to Boost. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 10:50 PM 8/10/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... iterator/interoperable_fail (compile_fail test isn't failing) That is a compiler bug, which I guess ought to be reported again. Yes. It saves us work in the long run when compilers get fixed. Please do report it. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: swappable user defined types and STLport libraries
At 07:49 PM 8/5/2003, Pavel Vozenilek wrote: Edward Diener [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Beman Dawes wrote: At 09:58 PM 8/4/2003, Alisdair Meredith wrote: There is a problem with the Borland BCB6 compiler... What is the status of the Borland compiler as far as fixes and updates go? Have they announced any plans? Although they have not announced anything further about more BCB6 service packs, it is easy to guess that there will not be any more. All indications are that Borland is working on a BCB7 release but, in true Borland fashion, there is no date given when it will be released until it happens. ... Something is happening right now - announcement and beta invitation is on http://bdn.borland.com/article/0,1410,30279,00.html. OK, sounds good. Thanks for the heads up. I'd like to be sure that some Booster signs up for this beta and starts running the Boost regression tests against it. And then follows up with bug reports to Borland as needed. Any bugs fixed in the compiler before it ships are bugs Boosters don't have to cope with later. Any volunteers:-? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
At 08:45 AM 8/11/2003, Jeff Garland wrote: I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) This is likely due to the posix API call to std::time not providing stable return values. That is, when I sample the time rapidly the second value is less than the previous value. So this is more of a platform / library issue than a compiler issue. This isn't a new problem with this particular configuration... OK, I've added a note to that effect. Consider the failure accounted for. Is there any point to report this to someone? Cygwin? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Files of types *.ipp are unfriendly, especially to MSVC ?
At 05:46 PM 8/9/2003, David Abrahams wrote: Paul A. Bristow [EMAIL PROTECTED] writes: PS Do files of type .ipp get checked for nasties like tabs, dud newlines? I dunno. You can check the scripts as well as I can. .ipp was added recently. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 09:56 AM 8/9/2003, Matthias Troyer wrote: As far as I can see Jens Maurer has updated boost.random to his standards proposal, but not yet the documentation. I believe it would be important to have the random documentation be consistent with the sources, especially since the interface has changed significantly. I've added this to the 1.31.0 task list. See http://sourceforge.net/pm/task.php?group_project_id=30994group_id=7586func=browse Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 07:37 AM 8/11/2003, David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. I worry a little about requiring library authors not to regress on compiler combinations they don't test with. For example, who is going to address the one lexical_cast failure that's plaguing the 1.30.2 release? It's only on intel-7.1 with STLPort and looks for all the world like a config problem. It can be very time consuming to track down the exact reason for failures. Thus we should focus our 1.31.0 effort on a small number of widely used compilers which don't have a lot of problems. For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::random problem
At 12:48 PM 8/12/2003, Hugo Duncan wrote: Trying to use the new random library on borland gives runtime problems. The following program below gives a constant result of 85. I have tracked the problem to variate_generator.hpp, where the internal engine type is computed typedef typename random::detail::engine_helperhave_int, want_int::BOOST_NESTED_TEMPLATE impldecorated_engine, typename Distribution::input_type::type internal_engine_type; In the example program it is using uniform_int_float instead of uniform_01 (engine_helperfalse,true instead of engine_helpertrue,false) I could patch the engine_helper to work using mpl::bool_, but the dependency is probably not wanted? I've had some email with Jens about the Borland compiler. He is aware of the problems caused by compiler bugs, but hasn't had time to figure out workarounds. I'm really hoping he will do some work on documentation (to reflect the new interface) before spending any time on broken compilers. That doesn't really answer your question, but perhaps it help a bit. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library]
At 09:27 AM 8/8/2003, Brock Peabody wrote: ... I took the library from work code ... Brock, Do you have formal permission from the library's owner to do that? Presumably the code is owned or licensed by your employer. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 06:03 AM 8/14/2003, Walter Landry wrote:
Greetings,
I've started using boost::filesystem recently, and I'm mostly very
happy.
Wow! A very happy user. Or at least mostly very happy. That's good news:-)
Seriously, it is a powerful motivator to get that kind of feedback.
One thing bothers me, though. Why does it implement any
restrictions, by default, on what kind of files it allows?
See below.
...
I also noticed that you can't open a directory named . or ..,
though I think ./ and ../ both work.
Hum... I'm not sure that is currently intended.
Files starting or ending with spaces also don't work.
That is intended, although it may change if the portability checking scheme
changes.
I understand that I can (painfully) work around it by using a
different context, but I don't understand why boost::filesystem wants
to restrict me to a set of filenames that are portable. Isn't that a
bit too much handholding? I don't mind having an is_portable()
command or something similar, but it is incredibly annoying to have to
abide by someone else's filename restrictions.
The current approach is clearly too restrictive and isn't satisfactory.
Beyond the problems you mention, there really isn't a single standard for
portability. Even 8.3 names aren't portable to systems which don't allow
periods in names. A whole family of checkers is needed, giving various
degrees of portability. Some should be supplied with the library, but users
also need to be able to provide their own.
OTOH, a function that has to be explicitly called isn't going to be
effective. Manual checking is too laborious in code that does a lot of path
manipulation. A one time I took several pages of code and tried to add
explicit checks. The code turned into a mess. Manual checking is also
likely to be ignored by the very programmers who need it the most; those
who have firm but erroneous ideas about what is or isn't portable.
So it comes down to an interface problem. What is the best way for the user
specify a portability checking function to override the default checking
function?
It would be trivial to add an additional path constructor that takes a
checking function or function object.
But that would kill ease-of-use. It is one thing to require an additional
constructor argument in the fairly limited use native case, but the
portability checking is applied to each and every path object constructed,
including the many path temporaries created by the automatic conversions
from char * and string.
(That kill ease-of-use point might be hard to understand if you haven't
actually written code using the library. The automatic conversions really
do allow script-like programming ease, and are reasonably safe given the
conversion result is class path.)
Also, the portability checking policy often needs to propagate to called
functions such as third party liberties. Adding overloads of functions to
take an additional argument is also too messy, and doesn't provide for
automatic pass-through to lower level functions. In most (but not all)
programs it really would be convenient if portability checking policy was a
global. But of course we all know that global variables are consider
harmful. There are also several valid use cases where a program needs to
switch back and forth between portability policies.
Another approach is to provide a way to tell class path that within a file
scope use a policy other than the default. It would have to be carefully
worked out to avoid ODR violations, and to ensure propagation to called
library functions. I have not been able to come up with a workable version
of this approach.
That was about as far as my thinking had gotten in the past. While
composing this reply, I came up with another possible solution. Let's say
boost/filesystem/path.hpp added this:
typedef bool (*is_portable_test)( string candidate );
class scoped_portability_policy : noncopyable
{
public:
explicit scoped_portabiity_policy( is_portable_test f );
~scoped_portabiity_policy();
};
The effect of constructing a scoped_portability_policy is to push p onto a
stack. The destructor pops the stack. Class path uses the top stack entry
as the current portability checker. The stack is initialized with a default
portability checker.
Most programs which wanted a policy other than the default would just being
something like this:
int main()
{
scoped_portability_policy( posix_portability_check );
...
Although the stack is global, when coupled with scoped_portability_policy,
it is safer than a single global variable (because library functions which
push are guaranteed to pop.)
Of course it can be subverted by static or heap allocation. (Aside: Is
there a reliable way to prevent static or heap allocation?)
I'm curious to hear what others would think of the above scheme.
--Beman
___
Unsubscribe other changes:
Re: [boost] anonymous lock in boost/libs/random/build
At 02:48 AM 8/13/2003, Russell Hind wrote: This lock has been there since I tried updating boost last night (about 8 hours ago). Please report stale locks to SourceForge support. They are the only folks who can fix the problem. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
At 12:31 PM 8/11/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 07:39 PM 8/10/2003, David Abrahams wrote: If I were king, the portable, generic version of windows-native c:/foo would be /c/foo and the portable generic version of windows-native /foo would be *current_path().begin()/foo. Is there a reason that approach was rejected? Yes, it had five or six different problems IIRC, although some of them can be fixed by adding additional syntax. For example, the ambiguity in /c/foo - is it a relative path starting with a directory named c or a complete path to the c drive Read as a generic path according to my system, it is not a relative path because it starts with a slash. That's simple and there should be no confusion assuming you know you're not looking at a native format.. Can that scheme represent paths which are relative to the root directory of an unspecified drive? Relative to the current directory of a specified drive? Can it handle server and share names? And most important, can it do so in a way that is obvious to a human reader or writer? Schemes which don't supply obvious syntactic markers such as : or // for special names are very hard for a human reader or writer to parse correctly. Once syntactic markers and/or rules are introduced, whether to eliminate ambiguities or to improve readability and writablity, the question is then what are the advantages of a new and unfamiliar set of markers and/or rules? The existing operating system syntax and rules are familiar to a large number of programmers. Even programmers who don't ever work with multi-rooted file systems often have a passing familiarity with the Windows rules, which are particularly important as it is the most widely used multi-rooted system. In other words, it isn't enough for some competing scheme to work. It has to have enough advantages to make it worthwhile for programmers to learn any new syntax or rules. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 02:56 PM 8/11/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. In that case, can I release 1.30.2? Yes, as far as I'm concerned. I don't like having the 1.30.1 debacle hanging over my head. Understood. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp missing docs?
At 11:48 AM 8/11/2003, David Abrahams wrote: I'm not sure if this is intentional or not, but cstdint.hpp includes typedefs for things like uint32_t, but they're not documented. If uint32_t is meant to be an unsigned integer with exactly 32 bits, well, I need that and I don't see any other obvious way to get it. That is supposed to be documented by the Exact-width integer types paragraph in boost-root/libs/integer/cstdint.htm. If you think those docs are lacking, please make whatever improvements you think helpful. If questions arise as to the exact specification, the C99 standard (ISO/IEC 9899:1999) is the authority. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: swappable user defined types and STLport libraries
At 04:57 PM 8/6/2003, Alisdair Meredith wrote: That does bring up the question of how the config for the new compiler is published though. What has happened in the past is that config related changes (config headers and build toolsets) start appearing in CVS well before a compiler is actually released. Presumably the knowledge comes from beta compilers, but because of NDA's no mention is made of how the knowledge is acquired. Thus by the time the compiler is released to the public, config changes are often already reflected in Boost releases. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::fs?
At 03:20 PM 8/6/2003, David Abrahams wrote: A namespace alias of fs:: is used in an example on one of the doc pages, and in some of the test and implementation code. Is that a concern? Yes! People will be very confused, IMO. I clearly was. Hum... It really makes the tutorial hard to read if all the fs::'s are replaced with boost::filesystem::. How would you feel about the tutorial giving a using boost::filesystem; and then eliminating the qualification entirely? I was trying to avoid that, as it isn't the best programming practice, but people are used to simplification in tutorials so maybe it is OK. I had thought the use of a namespace alias was the better solution. Ah, I haven't compiled anything yet. ;- Oh:-! Well, that would clear up any confusion pretty quickly. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::fs?
At 03:59 PM 8/5/2003, David Abrahams wrote: Why are we using such a cryptic namespace name? I mean, I can understand wanting to abbreviate template_metaprogramming, but filesystem doesn't seem too bad and you could use filesys; people will use namespace aliases anyway. The Filesystem Library is in namespace boost::filesystem. A namespace alias of fs:: is used in an example on one of the doc pages, and in some of the test and implementation code. Is that a concern? Sorry to complain, but fs has been rubbing me the wrong way since I started using it. Why are you using it then? I just double checked, and it doesn't appear in any of the filesystem headers. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: libs/config/configure screwed up in DOS format in 1.30.1
At 07:58 AM 8/6/2003, John Maddock wrote: Fixed now. I wonder if it really ought to be checked in as binary so this doesn't happen? Personally I think that would cause even more problems (for me at least), note that there are plenty of other files that need the \r's stripping in order for them to work on Unix, in fact some pre-processors (some versions of gcc for example) can't even cope with \r's in header files (if there's a \r between a \ and a \n). The only complete solution is to make sure that all text files have their \r's stripped before producing the tar.gz file. [ footnote - one way to do this is with the new bcp tool - something like: bcp --boost=boost-path --unix-lines --cvs . destination-path will produce a clean copy of all of the boost cvs with \r's stripped from text files - we could probably even write a Jamfile that would automate the release process come to that. -- end footnote ] The way we've been doing it for releases is to do a CVS export with the option for Unix line endings. Once we started with that approach, the complaints stopped. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
At 03:06 PM 8/6/2003, Thomas Witt wrote: The whole point in adapting is that you modify some but not all behaviour/interface of a thing. Ther is nothing a pair provides that can be reused so adaption is pointless. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. I found this separation of usages into iterator_facade and iterator_adaptor to be a vast improvement, FWIW. It seems to have resolved all the frustrations I felt with the old interface. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release date? (was the boost::signal sample crashes)
At 08:00 AM 8/11/2003, John Maddock wrote: I'm not sure how to proceed with this so if there is anything I can do in the meantime, let me know. Feel free to e-mail me off the list. OK, I've got this working pretty well with regex - but as it entails changes to boost.config I'm not sure if I should make the changes now or wait until after the next release - Beman I guess we have a couple of weeks still to run yes? Yes. Target dates haven't been set yet, so you should be OK. [ Footnote - on second thoughts it just means moving code that's in boost.regex now into the central config system it's not new code - so maybe I should go ahead ] Yes. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test Hum... That looks like a CVS problem. It looks like boost-root/libs/filesystem/src/operations_posix_windows.cpp has not been updated to 1.15. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Filesystem: naming, canonical path
At 08:06 PM 8/9/2003, David Abrahams wrote: As a user of the filesystem library, I am having the experience that obvious things are hard to find, and the docs are much harder to understand than they ought to be. The use of creative naming really gets in the way. For example, the term complete is never defined anywhere. It is defined by the is_compler() returns clause. The closest we come is in the following naming rationale. is_complete bool is_complete() const; Returns: For single-root operating systems, has_root_directory(). For multi-root operating systems, has_root_directory() has_root_name(). Naming rationale: The alternate name, is_absolute(), causes confusion and controversy because on multi-root operating systems some people believe root_name() should participate in is_absolute(), and some don't. I'm sorry if this sounds harsh, but I think the cure for someone being confused about the term absolute on multi-root OSes is to pick the definition that allows the term to be meaningful (an absolute path identifies a specific location, and so must include the root) and *add a clarifying note or definition for the corner case*, not to pick some new term which nobody knows about and makes the library hard to approach. The library isn't all that large that people can't just read about each function. There were lengthy discussions on the list of this and other naming issues during development, during review, and during the resolution of review issues. Many people had fairly strong views. IIRC, the idea that is_absolute( /foo ) was false on some operating systems was impeded by long-held beliefs. By giving the function an unfamiliar name, people are forced to actually read the specs instead of just assuming what it does, and that ends up being a good thing, IMO. I suppose if we were to discuss the names all over again we would come up with a different set of names. But unless the new names are markedly superior to the old names, it would just be churn to change them, and might be a real step backwards. --- aside --- Regarding complete paths, is there any guarantee that they are canonical? Is foo/bar/../baz reduced to foo/baz? Yes. That is documented as a postcondition specifying canonical form for all the functions that modify a path. I've just double checked, and it doesn't look like any were missed, but let me know if you spot any way to alter path state that doesn't supply that postcondition. See http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#getCanonicalPath() for an example of the possible semantics. We could learn a lot about what's useful and broadly implementable by studying the libraries of Java and/or Python (yes, I realize that the portability of Java ain't quite what it's cracked up to be). Yes, I often found other libraries helpful, although many of them offer syntactic portability rather than semantic portability. The legacy operating system API's interesting because they sometimes take different approaches. Sometimes what we think of as a path is just a key used to find the actual path via some external mapping mechanism. --- aside --- The formal description of some of the function semantics leaves something to be desired. For example, the docs for remove_all say: unsigned long remove_all( const path ph ); Precondition: !ph.empty() Postcondition: !exists( ph ) Returns: The number of files and directories removed. Throws: if ph.empty(). See empty path rationale. So, what does this do? At first I thought it removed all the directories along the branch described by ph. I think I'm now inferring that if ph is a file, it is the same as remove( ph ) and otherwise it removes all of the files and subdirectories in ph and then removes ph. A plain English description would help a lot here. This applies to many other functions in the library also. Yes, a general prose description for each library would help. I also have some doubts about the validity of the postcondition, since another process can come along and create ph again before remove_all returns. This applies to many other functions in the library also. The docs really weren't clear enough about postcondition/race-condition interactions. I've just added a paragraph to boost-root/libs/filesystem/doc/index.htm#Common_Specifications to make it clear that postcoditions don't hold if race-conditions exist. Because of the race-condition problem, the original docs did not specify postconditions. Someone pointed out how much clearer they because if postconditions were used, and the docs got converted at that point. The difference between is_empty(ph) and ph.empty() is too slight, IMO, for their differing semantics. IMO it's not useful to have one function which reports both empty files and empty directories - the implications of the two are much too different. Early versions of the library did provide the finer granularity of
Re: [boost] Re: Wrong version.hpp in Boost 1.30.1 download
At 01:13 PM 8/5/2003, Daryle Walker wrote: On Monday, August 4, 2003, at 11:27 PM, David Abrahams wrote: Alisdair Meredith [EMAIL PROTECTED] writes: version.hpp still claims to be version 1.30.0 Oh well. I guess there are some details missing from the release manager's responsibilities on the release procedure page. Can you (or Beman, who I think usually does the releases) add these directions to CVS? You may want to ask Beman if there are any other details not yet mentioned in the docs. I'll try to update it. The problem is that the actual checklist I use is quite a bit longer, and a lot of the steps are specific to my environment. For example, it gives the steps needed to run the particular graphical FTP program I use. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release Manager's Checklist added
At 05:58 PM 8/9/2003, David Abrahams wrote: [EMAIL PROTECTED] (Joerg Walter) writes: OK, what do others think? Am I the only one who feels uncomfortable with the SF-trackers? Nope; I dislike them also. That doesn't mean trackers in general are a bad idea. I'm not happy with the S/F trackers either. But like Dave, I definately feel we need some form of tracking. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Hey, I have a replacement test file here! (was: Added new testfile, need help testing)
At 01:32 AM 8/9/2003, Daryle Walker wrote: I uploaded a new test file for the I/O state saving classes over a month ago. How do we get the regression test guys to use the new file instead? Add to or otherwise modify the Jamfile that drives the test? Looks like the io tests are specified in boost-root/status/Jamfile: run libs/io/test/ios_state_test.cpp lib../libs/test/build/boost_test_exec_monitor # sources : # args : # input-files : runtime-linkstatic # requirements (static runtime required by Metrowerks) ; So add another test or change this one. The regression test guys just run bjam against the Jamfile. It is up to library maintainers to make Jamfile changes when needed. When a library grows beyond a single simple test, it becomes worthwhile to set up a test directory with its own Jamfile. Look at say filesystem for how it is done. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Can't get from anonymous CVS
At 11:29 PM 8/7/2003, Victor A. Wagner, Jr. wrote: At Thursday 2003-08-07 17:28, you wrote: cvs server: [11:59:06] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/libs/numeric/mtl/test cvs server: [15:35:09] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/libs/numeric/mtl/test that's been going on every 30 seconds for 5 1/2 hours does anyone know how to fix that problem? [deleted] Ok, so I can't subtract...but it's now cvs server: [20:28:39] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/libs/numeric/mtl/test When a SourceForge CVS lock goes stale you have to put in a request to SourceForge for them to clear the lock. They are pretty prompt about fixing such problems, although it is past all understanding why they don't put some automated fix in place. Numerous project admins have asked for this in the past. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: time_duration bug in Boost 1.30.0
At 05:27 PM 8/7/2003, Bo Persson wrote: Paul A. Bristow [EMAIL PROTECTED] wrote: (And other MS specific unhelpful warnings which could be dealt with by #ifdef _MSC_VER or BOOST_? #pragma warning (disable : 4800) // inefficient bool conversion? #endif As a general point, is there any reason why 'known to be unhelpful' warnings like this cannot be disabled in Boost code? A problem here is that the inefficient bool conversion often actually *is* an inefficient implicit conversion to bool. IME, most of these warnings can be removed by actually producing a bool value. Adding == 0 or != 0 is often all it takes. FWIW, I've done that for years in my own code, and have come to believe that it results in better code. It makes the intent clear to someone reading the code. With an implicit conversion, a reader is unsure whether or not the conversion was intended. To answer Paul's question, some of the toolsets do disable known to be unhelpful warnings. But I agree with Bo that this warning shouldn't be one of them. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
At 07:30 PM 8/6/2003, Joel de Guzman wrote: Beman Dawes [EMAIL PROTECTED] wrote: At 10:54 AM 8/5/2003, Brock Peabody wrote: I don't know much about other GUI systems but win32 and MFC. I think we can try to define the low-level layer using win32 and/or MFC as the starting point. If we cover these two, it'll be a good start and prove of concept. Actually for a proof of concept we could get by with just one. Given the major differences between underlying GUI API's, your really need to be developing in parallel for both Windows and Linux right from the start. And don't forget the Mac ;-) For a proof-of-concept, implementations are needed for enough of the framework to make it obvious it can be make to work with GUI API's that follow the same general model. Particularly the event/callback/other-flow-of-control mechanisms. I know that Windows and X Window are major API's that follow very different flow-of-control models. Is the Mac sufficiently different to be an important proof-of-concept case? Are there others? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test - function::sum_avg_portable - iterator::interoperable_fail (a compile_fail test that fails, probably not a real problem) - math::octonion_test math::quaternion_test - test::errors_handling_test I hope that lists helps. Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Release Manager's Checklist added
I've added a detailed Release Manager's Checklist (boost-root/more/release_mgr_checklist.html). It will take up to 24 hours for this to be reflected on SourceForge's public CVS (although it is available right away for those with write access). There are five items on the checklist that take up the bulk of the release manager's time (see abbreviated descriptions below). The release manager is near exhaustion by the time these are complete. I think we need to figure out a way to delegate this management effort to more people. (There are already quite a number of people helping with bits and pieces of the overall process, but we need to formalize that a bit more, IMO, so the release manager doesn't get lost in the details.) --Beman * Monitor inspection report to verify problems are being dealt with. * Monitor regression tests to verify that errors are dealt with. * Monitor mailing lists to verify that patches are being dealt with. * Monitor mailing lists and bug tracker to verify that bug reports are being dealt with. * Monitor CVS commits to verify content gets committed as planned. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
