Hi, Well, heads up. I'm doing lots of refactorizations. It all started with the include dependency bug noted by John Maddock. There's a nasty cyclic dependency happening somewhere that I tried to track. Along the way, I caught unwanted dependencies that stem from violations of the modular design of fusion that allows (by protocol) only acyclic module relationships. A bit of refactorizations after, the new layer/module hierarchy is (hight to low): mpl algorithm | functional container | view | adapted | tuple sequence iterator support This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Hi,
Well, heads up. I'm doing lots of refactorizations. It all started with the include dependency bug noted by John Maddock. There's a nasty cyclic dependency happening somewhere that I tried to track. Along the way, I caught unwanted dependencies that stem from violations of the modular design of fusion that allows (by protocol) only acyclic module relationships. A bit of refactorizations after, the new layer/module hierarchy is (hight to low):
mpl algorithm | functional container | view | adapted | tuple sequence iterator support
This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there.
The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+. Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries. Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch. Thanks, --Beman
Beman Dawes wrote:
This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there.
The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+.
Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries.
Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch.
Right, and TR1 fails with: compile-c-c++ ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug \threading-multi\test_tr1_include.obj test_tr1_include.cpp ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include file: 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory Which in turn causes most of Boost.Math to fail :-( So... what do we do to fix this? Obviously I could point to the new header (if you tell me where it is!) but then if we merged to the release branch without *first* merging fusion then it would break all over again - but on the release branch this time. Double :-( Ideas? John.
John Maddock wrote:
Beman Dawes wrote:
This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there. The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+.
Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries.
Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch.
Right, and TR1 fails with:
compile-c-c++ ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug \threading-multi\test_tr1_include.obj test_tr1_include.cpp ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include file: 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory
Which in turn causes most of Boost.Math to fail :-(
So... what do we do to fix this? Obviously I could point to the new header (if you tell me where it is!) but then if we merged to the release branch without *first* merging fusion then it would break all over again - but on the release branch this time.
Double :-(
Ideas?
Joel, this sounds bad. If you don't have an immediate fix, please revert you changes. --Beman
Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+.
Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries.
Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch. Right, and TR1 fails with:
compile-c-c++ ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug \threading-multi\test_tr1_include.obj test_tr1_include.cpp ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include file: 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory
Which in turn causes most of Boost.Math to fail :-(
So... what do we do to fix this? Obviously I could point to the new header (if you tell me where it is!) but then if we merged to the release branch without *first* merging fusion then it would break all over again - but on the release branch this time.
Double :-(
Ideas?
Joel, this sounds bad. If you don't have an immediate fix, please revert you changes.
I intend to fix all the affected libraries, but I reverted anyway. Sorry for messing the build :( Tell me how to proceed. Is the window for change already closed? If so, I'm sorry I wasn't aware of it. There are no changes to the code, just superficial header moves. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Beman Dawes wrote:
John Maddock wrote:
Beman Dawes wrote:
The changes seem to have broken a lot of other libraries tests. Failures on VC++ 8.0, for example, went from 16 to 150+.
Math and Xpressive where hit hard. This may be tough on John and Eric because both are actively working on their libraries.
Please do whatever is necessary to resolve these problems quickly. Otherwise it would be a lot better to develop on a branch. Right, and TR1 fails with:
compile-c-c++ ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug \threading-multi\test_tr1_include.obj test_tr1_include.cpp ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include file: 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory
Which in turn causes most of Boost.Math to fail :-(
So... what do we do to fix this? Obviously I could point to the new header (if you tell me where it is!) but then if we merged to the release branch without *first* merging fusion then it would break all over again - but on the release branch this time.
Double :-(
Ideas? Joel, this sounds bad. If you don't have an immediate fix, please revert you changes.
I intend to fix all the affected libraries, but I reverted anyway. Sorry for messing the build :(
Tell me how to proceed. Is the window for change already closed? If so, I'm sorry I wasn't aware of it.
The window isn't closed for run-of-the-mill code fixes, but it is closed for changes that break other libraries. Breaking changes should be made on a branch. The other affected libraries should also be changed on that branch, and then when local testing looks good the set can be committed to trunk as a single change. That way the trunk remains stable.
There are no changes to the code, just superficial header moves.
From the standpoint of release management, something that causes a platform's error count to jump from 16 to 154 doesn't look "superficial". The point isn't to shutdown major changes to libraries, but rather to use the cheap copies (aka branching) of subversion to keep the trunk stable yet allow change to happen, albeit on a branch. It is to be expected that some changes will be made to the trunk that unexpectedly break other libraries. Part of the rationale for running the smoke tests is to be able to quickly fix (or revert, if appropriate) such breakages. There have been a couple of such cases in the past week where changes broke far more than expected. But I tried not to growl too much at those developers because they quickly fixed whatever the problem was. And there have been a couple of cases where changes broke far more than expected, and the developers didn't seem to be reacting quickly to the breakage. Those are the cases where reverting seemed appropriate, so overall progress could continue while the specific issues got straightened out. --Beman --Beman
Beman Dawes wrote:
The window isn't closed for run-of-the-mill code fixes, but it is closed for changes that break other libraries. Breaking changes should be made on a branch. The other affected libraries should also be changed on that branch, and then when local testing looks good the set can be committed to trunk as a single change. That way the trunk remains stable.
Done.
There are no changes to the code, just superficial header moves.
From the standpoint of release management, something that causes a platform's error count to jump from 16 to 154 doesn't look "superficial".
Understood. I should have been more careful.
The point isn't to shutdown major changes to libraries, but rather to use the cheap copies (aka branching) of subversion to keep the trunk stable yet allow change to happen, albeit on a branch.
Ok.
It is to be expected that some changes will be made to the trunk that unexpectedly break other libraries. Part of the rationale for running the smoke tests is to be able to quickly fix (or revert, if appropriate) such breakages.
There have been a couple of such cases in the past week where changes broke far more than expected. But I tried not to growl too much at those developers because they quickly fixed whatever the problem was.
And there have been a couple of cases where changes broke far more than expected, and the developers didn't seem to be reacting quickly to the breakage. Those are the cases where reverting seemed appropriate, so overall progress could continue while the specific issues got straightened out.
I'm hoping my revert a few hours ago was quick enough. I understand the frustration and I can assure you that I won't commit the same mistake again. At any rate, I've done everything on a branch and tests are looking good on all libraries that use Fusion (testing done locally). Now, I need to know what to do next. I'd really rather have this in but I can understand if it's no longer possible at this point. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Hi,
Well, heads up. I'm doing lots of refactorizations. <snip>
This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there.
This change has totally broken xpressive, and it *must* be backed out. Besides, not all Fusion headers have corresponding .hpp files in the fusion/include directory (e.g., cons.hpp), so I have no reliable way to fix this on my end. <rant> C'mon people, this is not the time to be making major changes to libraries. This is the time to be making small changes to fix bugs exposed by the regression tests. You've had *ages* to make your big, breaking changes on HEAD. That time has passed. </rant> -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Joel de Guzman wrote:
Hi,
Well, heads up. I'm doing lots of refactorizations. <snip> This might still change a bit after odds and ends fall into place. If you want something stable, now, there's this new "include" directory that is a flat, MPL like, repository of include files that forward to the proper files (e.g. boost/fusion/include/vector.hpp will always point to where fusion::vector is). I highly recommend users to use it and for developers (Dan and Tobias etc.) to put all relevant forward headers there.
This change has totally broken xpressive, and it *must* be backed out. Besides, not all Fusion headers have corresponding .hpp files in the fusion/include directory (e.g., cons.hpp), so I have no reliable way to fix this on my end.
<rant> C'mon people, this is not the time to be making major changes to libraries. This is the time to be making small changes to fix bugs exposed by the regression tests. You've had *ages* to make your big, breaking changes on HEAD. That time has passed. </rant>
Sorry, Eric. I should have done the changes to affected libraries first to not cause disruption. Reverted. I'll work on a branch. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (4)
-
Beman Dawes -
Eric Niebler -
Joel de Guzman -
John Maddock