[string algorithms] Failing on HEAD for all platforms
string algorithms is currently failing all tests on all platforms on CVS HEAD. AFAICT, the problem is that the string algo tests call the range library begin/end functions with raw character pointers, I guess looking for this to turn into a range by use of strlen or similar. The range library flags a compile failure trying to form C::const_iterator where C -> char *. I also see the range library has appropriate overloads for fixed-length arrays, and does not handle arrays of unknown size. I don't know if these fails are due to changes in the range library or string algorithms, so I'm not sure what to suggest as a patch yet. Any comments from the library authors appreciated (even if it is simply pointing to a previous discussion I have missed) -- AlisdairM
Hi, AlisdairM wrote:
string algorithms is currently failing all tests on all platforms on CVS HEAD.
AFAICT, the problem is that the string algo tests call the range library begin/end functions with raw character pointers, I guess looking for this to turn into a range by use of strlen or similar.
The range library flags a compile failure trying to form C::const_iterator where C -> char *.
I also see the range library has appropriate overloads for fixed-length arrays, and does not handle arrays of unknown size.
I don't know if these fails are due to changes in the range library or string algorithms, so I'm not sure what to suggest as a patch yet.
Any comments from the library authors appreciated (even if it is simply pointing to a previous discussion I have missed)
This is a known issue. Range library interface have changed, and I didn't find a time to fix the string_algo library yet. I was hoping to fix it after 1.34 comes out. Now I'm not sure if I should not wait a while after I read the ideas to start from 1.34 in the new svn repository. Anyway, it is broken for a very long time already so I will have to fix it soon, no matter what it takes. Regards, Pavol.
Pavol Droba wrote:
This is a known issue. Range library interface have changed, and I didn't find a time to fix the string_algo library yet.
I was hoping to fix it after 1.34 comes out. Now I'm not sure if I should not wait a while after I read the ideas to start from 1.34 in the new svn repository.
Anyway, it is broken for a very long time already so I will have to fix it soon, no matter what it takes.
Thanks. I wonder if there is an easy way to add something to explicit-failures-markup.xml when it is known a library will be 'out-of-use' for extended periods of time? [Downside would be we don't want to encourage this if we want to support more frequent releases] -- AlisdairM
On 2007-06-02, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:
I wonder if there is an easy way to add something to explicit-failures-markup.xml when it is known a library will be 'out-of-use' for extended periods of time?
[Downside would be we don't want to encourage this if we want to support more frequent releases]
I would have thought that the obvious(!) thing to do (after the move to subversion, when such thinhgs will be easier) is to say that when there is a breaking change to an interface that other libraries rely on, then that work *must* be carried out on a branch, and that branch is only a candidate for merging back to the trunk when all affected libraries have been updated. Yes, this might be annoying for the person making the change, but not half as annoying as having releases from the trunk blocked because some maintainer of an affected library is not able to immediately address the issue. (And this should be *expected* to be the case.) phil -- change name before "@" to "phil" for email
Phil Richards wrote:
I would have thought that the obvious(!) thing to do (after the move to subversion, when such thinhgs will be easier) is to say that when there is a breaking change to an interface that other libraries rely on, then that work *must* be carried out on a branch, and that branch is only a candidate for merging back to the trunk when all affected libraries have been updated.
This will effectively block all breaking interface changes. The affected libraries will never be updated if there are no test failures.
On 2007-06-02, Peter Dimov <pdimov@mmltd.net> wrote:
Phil Richards wrote:
I would have thought that the obvious(!) thing to do (after the move to subversion, when such thinhgs will be easier) is to say that when there is a breaking change to an interface that other libraries rely on, then that work *must* be carried out on a branch, and that branch is only a candidate for merging back to the trunk when all affected libraries have been updated.
This will effectively block all breaking interface changes. The affected libraries will never be updated if there are no test failures.
I don't think it needs to be quite that extreme - but I take the point. I suppose my idea ends up requiring that branches have their test results published so that other people can see the breakages, but that isn't going to be practical. Ok, given that this approach is not liked, then *what* approach can be taken that will not result in weeks (or months) of time in which the SVN trunk is unable to be shipped because somebody has changed the API to a low level library? *Something* other than "dump the API changing break on the trunk and leave it to get fixed when possible" needs to exist (IMHO, of course). Otherwise I don't see that boost is going to be in any better position than it is now (well, not true - such problems should have much less frequently). It would be wonderful to think that such changes could be coordinated with all library developers so that breakages could be fixed within days, but, really, is that ever going to be possible? phil -- change name before "@" to "phil" for email
Phil Richards wrote:
On 2007-06-02, Peter Dimov <pdimov@mmltd.net> wrote:
I would have thought that the obvious(!) thing to do (after the move to subversion, when such thinhgs will be easier) is to say that when there is a breaking change to an interface that other libraries rely on, then that work *must* be carried out on a branch, and that branch is only a candidate for merging back to the trunk when all affected libraries have been updated. This will effectively block all breaking interface changes. The affected
Phil Richards wrote: libraries will never be updated if there are no test failures.
I don't think it needs to be quite that extreme - but I take the point. I suppose my idea ends up requiring that branches have their test results published so that other people can see the breakages, but that isn't going to be practical.
Ok, given that this approach is not liked, then *what* approach can be taken that will not result in weeks (or months) of time in which the SVN trunk is unable to be shipped because somebody has changed the API to a low level library?
*Something* other than "dump the API changing break on the trunk and leave it to get fixed when possible" needs to exist (IMHO, of course). Otherwise I don't see that boost is going to be in any better position than it is now (well, not true - such problems should have much less frequently).
It would be wonderful to think that such changes could be coordinated with all library developers so that breakages could be fixed within days, but, really, is that ever going to be possible?
As far as I know, the stable branch is there exactly for this purpose. Trunk will be open to wild development, but only after the changeset is finished, it will be merged to the stable branch. The stable branch should always be in "ship-ready" state. Regards, Pavol.
On 2007-06-03, Pavol Droba <droba@topmail.sk> wrote:
As far as I know, the stable branch is there exactly for this purpose.
Ah, perhaps that's where I'm getting confused - I was viewing "trunk" as "stable", and development being on other branches. I remember there being some discussion recently about what things are likely to look like after the move to SVN in terms of development etc, but is the latest-and-greatest view of the development process visible anywhere? (I checked the unofficial wiki, but that's currently vandalised.)
Trunk will be open to wild development, but only after the changeset is finished, it will be merged to the stable branch.
As long as the "wild development" is in easily cherry-pickable chunks then this is workable, but with something like a core library API change I can't see how multiple streams of development in one branch ("trunk") can work (easily, anyway).
The stable branch should always be in "ship-ready" state.
No disagreement there. phil -- change name before "@" to "phil" for email
Phil Richards wrote:
On 2007-06-02, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:
I wonder if there is an easy way to add something to explicit-failures-markup.xml when it is known a library will be 'out-of-use' for extended periods of time?
[Downside would be we don't want to encourage this if we want to support more frequent releases]
I would have thought that the obvious(!) thing to do (after the move to subversion, when such thinhgs will be easier) is to say that when there is a breaking change to an interface that other libraries rely on, then that work *must* be carried out on a branch, and that branch is only a candidate for merging back to the trunk when all affected libraries have been updated.
Yes, this might be annoying for the person making the change, but not half as annoying as having releases from the trunk blocked because some maintainer of an affected library is not able to immediately address the issue. (And this should be *expected* to be the case.)
Well, as far as I know, there wasn't any "release block" because of the mentioned issued. We were all working towards 1.34 and it was also one of reasons, I haven't pushed the matther harder. The branching you have proposed could get quite nasty. If the dependency tree is large (and there are lot of cases when it is) it would block the development on a large number of libraries. The process would not be very different from a release procedure and I don't see any reason why to create another one. Best regards, Pavol
participants (4)
-
AlisdairM -
Pavol Droba -
Peter Dimov -
Phil Richards