April 2005 - Boost - lists.preview.boost.org

RE: [boost] Use of Other Languages in Boost Tools
by Martin Bonner 25 Apr '05

25 Apr '05

----Original Message---- From: Allen [mailto:yaozhen@ustc.edu] Sent: 23 April 2005 07:28 To: boost(a)lists.boost.org Subject: [boost] Use of Other Languages in Boost Tools > The obvious two attitudes I can imagine are: > > (1) Prohibit *extensive* use of other programming languages in Boost > tools, for example writing a complex tool in Python completely. > (Convenient and small scripts are acceptable.) For we are establishing > the Best Practice *in* C++ and *for* C++. In addition, the tools can > be extensible and reusable with an API for C++ programmers as > *developers* not just as *end-users*. > > (2) Allow extensive use of any convenient and reasonable programming > languages in Boost tools. Maybe there should be a list for acceptable > languages other than C++, for example shell scripts, Perl, Python, > Ruby, etc. For they are just *tools*, not C++ *libraries*. They are > just black boxes to C++ programmers, and we do *not* provide the > tools as an extensible tool platform/framework with API for C++ > developers/programmers for further extension or reuse. > > I tend to support (1) I tend to support (2). On the other hand we should avoid using TOO many languages (because that is yet another thing to download and install to get the tool running). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

RE: [boost] Re: Proposal: Design by Contract / Pre &Postconditionslibrary
by Brian Braatz 25 Apr '05

25 Apr '05

General 2 cents: About a year ago I built a library for internal use along the lines being discussed in this thread. (for the curious what I did was hook logging and tracing to the Precondition and postcondition) After I got it all done, I said to myself, OK I am now going to USE this code and abide by it's rules. I found that very difficult to do, because of my OWN difficulties in doing that I have shelved this library for our internal usage. (i.e from a practical nature it would be hard to get people (myself included) to continue to use it) I ask the people thinking about this lib, to sit down and try to write 10 or so functions and get a sense for if you would actually USE it. I am not trying to be a downer, more I am sharing my experience. There may be a place for this lib in the same regard as scope guards are used. Scope guards are nice when you need them, but you don't need them everywhere.... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jarl Lindrud > Sent: Sunday, April 17, 2005 11:47 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Proposal: Design by Contract / Pre > &Postconditionslibrary > > Yariv Tal <yariv_tal2003 <at> hotmail.com> writes: > > > > Do you check at compile time that the used gave all of the variables > > participating in the expression or do you just let the user state which > > variables they want to be displayed in the error message? > > The user just states which variables he'd like to see printed, if the > condition > were to fail, and its fine not to specify any variables at all. > > > > > One thing though, I didn't see any handling of disabling testing post > > conditions when > > an exception is thrown. > > Did I miss something? > > No you didn't... guilty as charged :) > > > > > > > > > Since these macros are part of the function implementation, maybe one > > shouldn't > > > borrow the name "Design By Contract", since that implies a contract > > external to > > > the function. Proper DbC contracts need to be stated at the level of > > function > > > declarations, and would apply to overrides in derived classes as well. > > Point taken. > > Originally I was hoping to add invariants etc., but I didn't get to it. > > Of course, even with invariants it will still be more at the function > level. > > In general, I think there's a lot to do (temporal invariants as in > "keystone > > ", for example) > > and since it is so useful (a fact I discover every time a condition in > my > > code is invalidated) > > it think, IMHO, it should be a library for all to use and for many to > > contribute to. > > Agreed. Formalizing the PRECONDITION and POSTCONDITION macros would be > quite > useful, I think. But I wouldn't be too worried about trying to emulate > DbC, > that's a different concept altogether. > > /Jarl. > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Mats, > >Don G wrote: >> Yes. The "generic async library" I keep mentioning is >> where this is handled w/o the user A) being called in >> the wrong thread or B) the user manually doing any >> posting. > > Sorry if this is covered somewhere, but would the user > have any say in what goes down if an async_read and an > async_write on the same socket complete more or less > simultaneously? (In the presence of multiple worker > threads) > > Sometimes the application logic calls for serializing > the callbacks and sometimes it would be better to > allocate each callback to a different thread, > possibly allowing them to run in parallel. In the approach I was describing, yes, each callback can be bound to a different channel. > I have recently had to deal with synchronization/ > starvation issues caused by this kind of design > (simultaneous pending async_read and _write on > the same socket) in an application using Windows' > OverlappedCompletionPort mechanisms. > > If the callbacks for the read and write operations > both race to lock the same resource (e.g. the > session object mutex), one of the completed > operations will obviously have to wait for the > other. This wastes one precious working thread, > because it is just sitting there waiting while it > could be serving other connections instead. It sounds like you would prefer that both go to the same thread in this case? Again, either would be supported using the design I am proposing. > I tried to alleviate this waste by transferring > the "completion-token" to the first thread. Once > the first thread was done with its first callback > (e.g 'on_read'), it would proceed to handle the > transferred callback (e.g 'on_written') before > returning itself to the pool. > > This made the situation much better, but somehow > tended to cluster related operations, since each > thread would do comparatively more work on one > socket before allowing another session's callbacks > to be processed. > > It made better use of the threads, but possibly on > the expense of fairness. I suppose it always will depend on what happens in the callback whether it is best to have lots of threads banging away or serialize them or plod along with a pool of 1/CPU. All are valid, but a library would be unable to chose which is best. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[testing] Buildbot setup status.
by Rene Rivera 25 Apr '05

25 Apr '05

Just a status update for those that care about my Buildbot efforts. My testing setup is working and recently finished it's first full set of tests which can be seen on the meta-comm pages (runner = RSI-SoL). From this point onward I'll try and keep it running continuously. So if you check something in you can go look at the Buildbot status page and watch when your changes get tested. http://build.redshift-software.com:9990/ BuildBot: Boost C++ Libraries I know it's got some minor glitches, like the platform name is incorrect, but just having it running is more important. And I have the "OnDemand" functionality but not an interface to let people request builds. And I won't have time until much later to write up that web interface. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 3

typeof internals document updated
by Arkadiy Vertleyb 25 Apr '05

25 Apr '05

Hi all, A new section, that describes details of template template parameters support, has been added to this document. I thought this information might be usefull during the upcomming review (still have no idea when it's supposed to happen nor whether we go before or after Eric). Regards, Arkadiy

1 1

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Mats, It's good to have someone with experience in non-TCP environments! Glad you're here. > The X.25 API doesn't provide the equivalent to the tcp > listen(2) backlog parameter. To drive an X.25 acceptor > to be capable of accepting incoming calls at a high > rate, one has to implement the backlog oneself. Perhaps this is something that should be part of the impl of the acceptor for X.25. That would make X.25 and TCP the same in this sense (there are no doubt other differences of which this is just one). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 24 Apr '05

24 Apr '05

On Fri, 2005-04-22 at 14:23 +0300, Peter Dimov wrote: > Iain Hanson wrote: > > On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote: > > [ snip ] > > This would give a significant performance hit as there will now be two > > copies of the data. The 1st from kennel space to the library and the > > second in the callback from the library to the user. > > Sometimes, yes, but not always. You don't have to make a copy in the > callback, and for small packets and low bandwidth, the extra copy may not be > significant. Also note the "by default" in the above. I am not against > manual buffer management, just against the absence of automatic buffer > management. > I really don't see this as workable in the general case. The library has to guess the size of the read buffer. It would also prevent reading a complete record on a stream by reading a header up to the length field and then making a 2nd read call for that length with the correct size buffer. It would also add dynamic memory allocation to the library and be a source of runtime errors as a result a user not copying the buffer and trying to use it after its lifetime expired. I know we can't always protect users from themselves but we do try to not make it easy for them to make mistakes. /ikh

4 5

TR2 and Boost fixed_string
by Tanton Gibbs 24 Apr '05

24 Apr '05

With regards to TR2 and Boost, I would like to see a string class that allows a user specified length. For instance boost::fixed_string<100> fs; // synonymn for boost::fixed_basic_string<char, 100> Whether the rest of the class was monolithic like std::string or broken out as proposed by Herb Sutter, I wouldn't care. I often come across uses for this where I don't want to dynamically allocate memory, but I also want the functionality of the string class. Tanton

1 0

Re: [testing] Buildbot setup status.
by Rene Rivera 24 Apr '05

24 Apr '05

Robert Ramey wrote: > It looks like it runs even before I finish getting a whole group of changed > checked in. It's on a 10 minute trigger. So it waits for 10 minutes where it hasn't gotten CVS notifications before proceeding. Looks like you had the commits spaced out in 20, or so, minutes. This is one of those, tweak until we get what's appropriate for Boost development. Should I make that longer? 20, 30, 60 minutes? I don't want to make it feel unresponsive though. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Regression testing and BuildBot discussions
by Beman Dawes 24 Apr '05

24 Apr '05

Dave Abrahams, Doug Gregor, Thomas Witt, and I had a discussion last week at the C++ committee meeting about how to improve Boost regression testing, and the whole process of getting ready for releases. Much of what we talked about has already been discussed on this list, so our conclusions shouldn't be much of a surprise: * Making Boost regression testing as robust, automatic, distributed, and timely as possible is the best way to help developers, release managers, testers, and eventually, users. * BuildBot (http://buildbot.sourceforge.net/) looks like best way to achieve those goals, based on experiments to date. * It would be very helpful if a team coalesces around Rene Rivera to develop BuildBot regression testing for Boost. They will need to stay coordinated with the MetaCommunications folks, of course. The rationale behind the "robust, automatic, and distributed" goals is that many people are willing to volunteer machine resources for Boost regression testing, but they say that other than downloading (and perhaps answering a very few startup wizard questions) they don't have any of their own time available. Thus the vision is of something like the SETI@home project which lets people contribute spare machine cycles without burdening them further. The rationale behind the "timely" goal is that developers will benefit tremendously from faster feedback, both for HEAD and active branches. Automating the feedback will free developers from having to track what is happening on many different platforms. The rationale behind encouraging a team to work on BuildBot regression testing is that this is important to Boost, so it will benefit from a team forming. That should improve and speed development, and ensure that several people understand the system and can maintain the internals. Rene is the logical leader since he has already stepped into that role for BuildBot. --Beman

4 6