I notice that there are already a few patches that have gone into the RC_1_33_0 branch, presumably in expectation of a 1.33.1 release? So some questions: 1) Is the release branch now officially open again for patches: I assume that it is now that the release is out. 2) Is there any interest in either a hotfix patch-release or possibly a full 1.33.1 in 4 to 6 weeks time? If yes, then I believe we really need to start a readme file with a list of patches made - this would become the readme for the patch when it's released. Thoughts? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
IMO we ought to wait to see whether there are any problems big enough to warrant doing a 1.33.1. It might be worth while if we could get FOREACH and typeof previews into a patch release, since new libraries don't destabilize anything old (?) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Typeof doesn't modify anything old. However we are planning to do some porting, and refactor our tests before we are ready to release. If the next release is comming sooner than in a couple of month, we may adjust our plans accordingly. Regards, Arkadiy
David Abrahams wrote:
Personally I find adding libraries in a minor release to be confusing - I expect a minor version essentially to be patching bugs, rather than adding features. I would be in favour of shorter release cycles though, as new libraries come through the review queue. Regular releases like this would probably keep the mainline more stable avoid some of the problems seen trying to get the last 2 releases out the door. [all credit to respective release managers for finally wrestling these beasts into submission!] -- AlisdairM
From: "AlisdairM" <alisdair.meredith@uk.renaultf1.com>
That's not how most software handles version numbers. Applications regularly add features in minor version upgrades. Dramatic additions of functionality or reworking of existing functionality normally indicate a major version number bump. Patches usually only address bugs, security issues, etc.
That's come up before. The question is how to effect it. Library developers need some time to insert new functionality and changes to existing functionality between releases. When that happens with multitudinous libraries, the compounding of problems leads to long release cycles. The only thing I can think of to address this is for each library to have its own branch for development. Then, when it is deemed ready, that branch is promoted to an integration branch. If it fails there, the promotion is rolled back until the library is changed, gets required changes in another library, etc. Eventually, all libraries compile and test fine in the integration branch and the whole set can be promoted to a release branch. IOW, promotion for integration should be happening throughout the year, but only when a given library is ready to do so. A release is nothing more than taking a timely snapshot of the integration branch. That also means that those that don't want bleeding edge changes, but want more than was in the last release, can get the latest integrated set of libraries from the integration branch. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
Yes. The trunk should be ready-to-release at all times, as far as possible. If you want to make breaking changes, do it on a branch, make it work, and then integrate to the trunk. Preferably, branches should be as shortlived as possible. Has anyone got the resources to run a continuous integration build machine? Is this what the kind people who supply the resources for the release regression tests do already? Anthony -- Anthony Williams Software Developer
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> writes:
How confusing? Would it take more than a moment to come to grips with?
I expect a minor version essentially to be patching bugs, rather than adding features.
No new features would be added to existing libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Jonathan Turkanis wrote:
1.33.0's shared_ptr appears to have a bug on CW/PPC with inlining on: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256121&group_id=7586 and a fix that's been suggested by Howard Hinnant is already on the branch, so that's one more argument in favor of 1.33.1.
Johnathan, Would you mind changing the access of two sections in class indirect_streambuf from private to protected? I want to specialize two functions in this class and as it currently stands I need to replace practically the entire iostreams library to do it. Regards, George. template<typename T, typename Tr, typename Alloc, typename Mode> class indirect_streambuf : public linked_streambuf<BOOST_DEDUCED_TYPENAME char_type_of<T>::type, Tr> { public: typedef typename char_type_of<T>::type char_type; BOOST_IOSTREAMS_STREAMBUF_TYPEDEFS(Tr) --private: ++protected: typedef typename category_of<T>::type category; [...] void* component_impl() { return component(); } --private: ++protected: //----------Accessor functions--------------------------------------------// wrapper& obj() { return *storage_; }
Johnathan,
What are you trying to do? <
I believe that we have already discussed this. But since you ask: template<typename T, typename Tr, typename Alloc, typename Mode> class normalized_indirect_streambuf : public boost::iostreams::detail:: indirect_streambuf<T, Tr, Alloc, Mode> { public: typedef boost::iostreams::detail:: indirect_streambuf<T, Tr, Alloc, Mode> base_type; normalized_indirect_streambuf(void) : base_type() { } protected: std::streamsize _Xsgetn_s(char_type* _Ptr, size_t _Ptr_size, std::streamsize _Count); int_type underflow() { buffer_type& buf = in(); if((buf.size() - pback_size_) == 0) return traits_type::eof(); return base_type::underflow(); } }; template<typename T, typename Tr, typename Alloc, typename Mode> std::streamsize normalized_indirect_streambuf<T, Tr, Alloc, Mode>:: _Xsgetn_s(char_type* s, size_t _Ptr_size, std::streamsize n) { using namespace std; buffer_type& buf = in(); if (!gptr() && buf.size() > 0) init_get_area(); streamsize total = 0; do { // Fill request from buffer. if (streamsize avail = std::min(n, static_cast<streamsize>(egptr() - gptr()))) { traits_type::copy(s, gptr(), avail); gbump((int) avail); total += avail; s += avail; n -= avail; } else { // Read from source. streamsize to_read = buf.size() - pback_size_; if(to_read <= n) { //if(to_read == 0) to_read = n; if(streamsize amt = obj().read(s, to_read, next_)) { s += amt; n -= amt; total += amt; if(amt < to_read) break; // probably EOF } else { // Something is screwed. Get out of dodge. break; } } else { if(traits_type::eq_int_type(traits_type::eof(), underflow())) break; } } } while(n > 0); return total; } The implementation avoids excessive copying by bypassing, under carefully defined circumstances, internal buffering and performing the read operation in-place.
I'm not sure how this helps; component_impl() returns a void*. What am I supposed to do, cast it? :-( Regards, George.
George M. Garner Jr. wrote:
<snip>
This is not an appropriate customization point for indirect_streambuf. The correct way to customize the buffering policy would be through a template parameter. Even better, if you can show that your implementation is superior to the current one, I can simply use yours instead. I'll have to review the old messages to remember what the sticking points were. I seem to remember there was a problem with STLPort requiring a larger putback buffer than other libraries.
It means that you can currently do whatever you would be able to do if I made it protected.
component_impl() returns a void*. What am I supposed to do, cast it? :-(
Of course ;-) What else can you do with a void*?
Regards,
George.
Jonathan
Johnathan,
I must have missed that day in OOP design class. :-) And I don't see what that get's me even assuming that I cast it. The branch in the execution path that I want to intercept occurs in basic_streambuf<>::_Xsgetn_s() (Microsoft SL v8.0) or basic_streambuf<>::xgetn() (other SL). Even assuming that I cast your void pointer I won't get a chance to do so unless I replace _Xsgetn_s/xsgetn in the basic_streambuf<> vtable. The only (legitimate) way to do that is by derivation. Derivation is still a respectable means of specialization so far as I know.
Even better, if you can show that your implementation is superior to the current one, I can simply use yours instead. <
Well you could do that of course. But what happens in 6 months when I want to specialize something else? I don't see what advantage there is to making the typedefs private rather than protected. You could provide an accessor for pback_size_. I don't see why that shouldn't be provided in any case.
After some subsequent testing I found that I didn't need to modify that part of the code. Regards, George.
George M. Garner Jr. wrote:
I'm not following this. I thought you wanted me to make component_impl() protected so you could override it. My only point was that you can already do this.
Because it relies on implementation details. How would you know what invariants to maintain? How would I know what aspects of the implementation I'm free to change in later versions? Instead of making all this internal machinery accessible -- which implies that I have to document it and promise to keep it stable -- why not encapsulate the buffering policy in a template parameter? As I said before, the reason I didn't do this is that I wasn't convinced that there wasn't a single best buffering policy; however, I'll be glad to look at any data you have.
Okay.
Regards,
George.
Jonathan
John Maddock wrote:
I notice that there are already a few patches that have gone into the RC_1_33_0 branch, presumably in expectation of a 1.33.1 release?
There are a few post-1.33 minor bug fixing patches for Boost.Build v2 already in the trunk branch. I also have a pending important patch for BBv2 ("lib" library prefixes aren't added) and some performance improvement patches for tokenizer and date_time.
2) Is there any interest in either a hotfix patch-release or possibly a full 1.33.1 in 4 to 6 weeks time?
I don't feel a need for the release, but if we are going to release it soon, I have some patches to be integrated. Andrey
And I have some regex fixes that could be integrated as well. OK, how do folks feel about a hotfix release (just the files that have changed) in a few weeks time? Note: only simple fixes should go into such a release, it's a chance to clear up any minor niggles, nothing more at this stage. John.
John, Would you mind including this regex fix: file: basic_regex.hpp. bool BOOST_REGEX_CALL empty()const { --return (m_pimpl.get() ? 0 != m_pimpl->status() : 0); ++return (m_pimpl.get() ? 0 != m_pimpl->status() : 1); } Reason: empty() currently returns false (0) when the result of get() is NULL. Regards, George. "John Maddock" <john@johnmaddock.co.uk> a écrit dans le message de news: 00f201c5a182$373f8fa0$ba4e0352@fuji...
On 8/16/05 2:11 PM, "George M. Garner Jr." <gmgarner@erols.com> wrote:
If "status" returns a built-in (i.e. "operator !=" can't be overridden), then could we change the final "1" to a "true"? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (12)
-
AlisdairM -
Andrey Melnikov -
Anthony Williams -
Arkadiy Vertleyb -
Bronek Kozicki -
Daryle Walker -
David Abrahams -
George M. Garner Jr. -
John Maddock -
Jonathan Turkanis -
Peter Dimov -
Rob Stewart