- Boost - lists.boost.org

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

27 Aug '04

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

5 4

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

27 Aug '04

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

1 0

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

27 Aug '04

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

6 7

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

27 Aug '04

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

2 1

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

27 Aug '04

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

4 10

Seialization library current status
by Robert Ramey 26 Aug '04

26 Aug '04

Here is short summary of the current status of the serialization library. Its based on tests on my own machine and others. In some cases I'm anticipating results of next tests. Linux - 100 % passing all compilers Except intel 8.0 - problem with serialization some collections - list, map, set, and array. Darwin - 100 * passsing Except - one test of demo fail Windows Mingw - 100 % of all char archives 0 % of wchar_t archives. Apparently mingw doesn't support wchar_t. Itel 100 % all versions Borland - mostly passing - this is the best I can do here VC <= 7.0 - mostly passing - this is the best I can do here VC 7.1 - 100% VC 8.0 - 0% - I don't know the status of this compiler. Library fails to build due to syntax error compiling spirit headers. I'm not prepared to address this. Commeau - 100 % EXCEPT archives which use wide characters. I believe it would be easy to find if I could figure out a way to debug this. Metrowerks CodeWarrior - This is a little confusing. One tester shows 100% success. The best I have is all pass EXCEPT tests which use export facility or wchar_t archives. Another tester has the same result I do. All tests that fail have unexpected linker warnings. I suspect a build issue but have been unable to find it. So that's it I could use help with Intel 8.0 array, list, set and map. Its probably one error in collection loading. Comeau - problems with wchar_t. Very likely related to codecvt facit usage Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which use utf8_codecvt_facet and which use export. Export seems to fail due to an over zealous link time optimizer eliminating what might look like dead code. Robert Ramey

3 3

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

26 Aug '04

>"Robert Ramey" <ramey(a)rrsd.com> writes: >> Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which >> use utf8_codecvt_facet and which use export. Export seems to fail due to an >> over zealous link time optimizer eliminating what might look like dead code. >?? CW doesn't support export ?? Export refers to one of the features of the serialization library - not to be confused with all the other ways we use this word. Sorry if there is any confusion here. >Are you aware that some of the facet stuff is only supported in the >*statically-linked* version of the MW standard library? ><runtime-link>static might be a requirement of these tests. I'm certainly not aware of that. I looked carefully through all the information I could find and didn't see anything like that. However, that would explain at least test failures associated with utf8 codecvt. I'll try this. Robert Ramey

2 1

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Beman Dawes 26 Aug '04

26 Aug '04

At 09:33 AM 8/25/2004, Bennett, Patrick wrote: > If I can't write a >portable (to at least Linux and Windows), internationalizable >application with boost::filesystem then it's of no use to (at least) me. And a lot of other people. I'd like to see the library become part of std::tr2, and lack of internationalization is the main impediment to that. I've spent a lot of time for the last two years looking into the issues, and am pretty close to being ready to make a detailed proposal. >This is why I suggested that UTF-8 be used as boost::filesystem's >encoding. It can be passed through as-is or converted as needed on each >platform and it would be backwards compatible with existing >boost::filesystem code. For standardization (and I don't have any interest in internationalization except in the context of standardization) I don't think any proposal will fly unless it is in sync with current standard library internationalization. That means that the internal encodings must be char, wchar_t, or a template parameter charT. Once the Unicode TR being worked on is accepted, then those character types will be presumably be added. Just as with strings, presumably there will be path and wpath typedefs, and then Unicode typedefs when they evolve. As far as external encodings go, there will be a program default (which defaults to the platform default, but can be set to a user specified encoding), but individual paths can be constructed using a user-supplied external encoding if desired. Translation issues between encodings are messy, to say the least. Note that there has to be a way to pass strings in the operating system's external encoding on to (at the lowest level) file open functions, and that the current standard does not provide this. Bill Plauger has proposed the addition of this functionality to the standard, so that aspect is moving forward. --Beman

1 0

[filesystem] issue with path::iterator
by Martin Wille 26 Aug '04

26 Aug '04

Hello, a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this: using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++; That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j: error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested I suspect the change was caused by a recent change to iterator adaptors. Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me. Regards, m

5 15

xtime_get unsafe on Windows for IA64
by Ben Hutchings 26 Aug '04

26 Aug '04

The implementation of the boost::xtime_get() function in libs/thread/src/xtime.cpp includes the following code for Windows: #if defined(BOOST_HAS_FTIME) FILETIME ft; ... const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = ((boost::uint64_t)27111902UL << 32) + (boost::uint64_t)3577643008UL; xtp->sec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET) / 10000000); xtp->nsec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET - ((__int64)xtp->sec * (__int64)10000000)) * 100); return clock_type; #elif ... (This is reformatted slightly so that Outlook doesn't screw it up.) The pointer casts are not safe because although the representations of FILETIME and __int64 are compatible, FILETIME is only 32-bit- aligned whereas __int64 must be 64-bit-aligned on IA64 (in some processor modes). One can instead use union { FILETIME ft; __int64 i64; } and read out i64, though I'm not sure this code should be unconditionally using __int64 anyway. There is a longer explanation at <http://weblogs.asp.net/oldnewthing/archive/2004/08/25/220195.aspx>. Ben.

2 1