August 2004 - Boost - lists.boost.org

Re: Boost Mathematicians
by Michael Stevens 05 Aug '04

05 Aug '04

Hi Dave, hi all, I read with interest you plans for reviving MTL. It is certainly a shame that development of MTL was been stagnant for so long. It certainly had many interesting design features and I used it for all my work for many years. That said I switched to using and developing uBLAS long ago and it has an excellent design. On Saturday 05 June 2004 13:53, David Abrahams wrote: > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > > David Abrahams wrote: > >> Tom Brinkman <reportbase(a)yahoo.com> writes: > >>> In short, lets tell the world that this is the > >>> premiere place for advanced mathmatical library > >>> development, as I believe that it could be. > >>> > >>> Comments? > >> > >> 1. I think oonumerics.org has the jump on us here, though the site > >> seems to be douwn at this moment. > >> > >> 2. I will be starting work on a rewrite of MTL (the Matrix > >> Template Library) for linear algebra soon. > > > > What do you plan for MTL? How is it different than ublas? > > MTL is aimed at linear algebra, whereas IIUC ublas is not. Well the L and A in uBLAS certainly stand for Linear Algebra! Of course the B stands for Basic and uBLAS's primary aim is to provide the standard set of BLAS functions in a modern C++ environment. Of course as it stands the complete uBLAS library is more then just the BLAS functions and includes some common Linear Algebra algorithms and many useful types. That said I think it is important to separate BLAS functions from domain specific linear algebra algorithm development. This is something that proved itself since the seventies. > There's a lot more to what's in the current plan than I can lay out > here, but the focus will be on support for different kinds of matrices > with combinations of these aspects > > o Shape > o Orientation > o Symmetry > o Sparsity > o Blocking > o Upper / Lower storage > o Unit diagonal Other then the many forms of blocking (other then banded) uBLAS supports all these in its design. This really is its strength! To a large extent they can even be combine these properties where it makes mathematical sense. For example you can wrap up one of a number of sparse matrix types in a symmetric adaptor. > > and operations like: > > o scalar-vector (vector-scalar) multiplication > o vector addition (and subtraction) > o apply linear operator (left) > o norm > o inner product > o triangular solve Other then 'apply linear operator' these are all in uBLAS! > with expression templates, and of course, zero abstraction penalty ;-) Of course uBLAS does this all with ET, but the abstraction penalty may not be zero :-) Other then the lack of ET in the current MTL the big difference between the two libraries is the definition of iterators. Neither design seems to be perfect with regard to efficiency. Since uBLAS is already in Boost and has a well established and clean user syntax it would seem strange to ignore it. For the perspective of building further Linear Algebra algorithms it would not be too hard to use the syntax sufficiently portably so that a future MTL with expression templates could not be used interchangeably. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

13 20

Boost.Test fails to build on IRIX/mipspro
by Aleksey Gurtovoy 05 Aug '04

05 Aug '04

See http://www.meta-comm.com/engineering/boost-regression/developer/test.html -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Boost License future considerations
by Michael Glassford 05 Aug '04

05 Aug '04

Thinking about the problems we're having now contacting people to get permission to switch to the Boost license, I got to wondering what would happen if at some point in the future the Boost license needed to be changed (for instance, due to some legal challenge). I assume the possibility of it changing was considered; after all, usually if you give something a 1.0 version number you leave open the possibility of a version 1.1 or 2.0. What could we do to avoid even worse problems if that ever happens? Would it make sense to have people add their names to a blanket permissions file (or add explicit permission in their submissions) that would allow the copyright for their submissions to be updated under certain circumstances in the event that they could not be contacted for permission? What legal issues would be involved in such a case? Just a thought, Mike

5 12

Review Wizard Status Report
by Tom Brinkman 05 Aug '04

05 Aug '04

1) Proposed Library Review Schedule We have eight very interesting libraries to consider for inclusion into boost the next few months. If there are no objections, I will schedule reviews for next four libraries, as follows: (please contact me for adjustments to this schedule) More IO - Daryle Walker August 18, 2004 Iostreams - Jonathan Turkanis August 28, 2004 Output Formatters - Reece Dunn September 7, 2004 Pointer Containers - Thorsten Ottosen September 17, 2004 Named Params - David Abrahams & Daniel Wallin To be Determined Wave - Hartmut Kaiser To be Determined Policy Pointer - David Held To be Determined Finite State Machine (FSM) - Andreas Huber To be Determined 2) Algorithm Mini-Reviews If there are no objections, I will also schedule a mini-review of some of the algorithms from wiki starting September15, 2004. The format of the boost algorithms review has yet to be established and will evolve over time. Please contact me if you have any suggestions as to how this first boost algorithms review proceeds. 3) Review Managers Needed Please contact me if you would like to serve as a review manager for a library under consideration for inclusion into boost. It would be greatly appreciated and is a great way for you to network with other boost users. Tom Brinkman Boost Review Wizard __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

4 3

RE: [boost] Review Wizard Status Report
by Rozental, Gennadiy 04 Aug '04

04 Aug '04

> 2) Algorithm Mini-Reviews > > If there are no objections, I will also schedule a > mini-review of some of the algorithms from wiki > starting September15, 2004. The format of the boost > algorithms review has yet to be established and will > evolve over time. > > Please contact me if you have any suggestions as to > how this first boost algorithms review proceeds. Does my submission get into this picture? > 3) Review Managers Needed > > Please contact me if you would like to serve as a > review manager for a library > under consideration for inclusion into boost. It > would be greatly appreciated > and is a great way for you to network with other boost > users. I am ready to help, though it's subject to schedule conflicts resolution. > > Tom Brinkman > Boost Review Wizard Gennadiy.

1 0

Re:[boost] [serialization] CW8 status...
by Robert Ramey 04 Aug '04

04 Aug '04

Rene Rivera wrote: >A quick summary of what your recent changes did for CW8, in case the >metacomm tests don't soon: >* test_delete_pointer pass. >* test_demo_auto_ptr pass. >* test_deque pass. >* test_diamond pass. >* test_map pass. >* test_non_default_ctor pass. >* test_non_intrusive pass. >* test_optional pass. >* test_private_ctor pass. >* test_split pass. >* test_vector pass. >I only tested the previous failures. And for some the metacomm tests >show a failure for things were previously fixed. Also it looks like some >of the failures are now different, meaning you fixed something only to >have it fail on something else. Oh yeah - sometimes you get more than one issue per test - sort of a free bonus. Several compilers/platforms/combinations have problems with wide character i/o. These are CW, Comeau, Darwin/GCC. I'm looking at this - I believe it may be an error in the utf8 codecvt facet. (interestingly, this doesn't occur with the column marked "CW" hmmmm) I have a problem with my own cwpro9 installation in that for some programs I get multiply defined symbols at link time. The resulting exectutable goes kind of haywire. The column marked "CW" doesn't show this problem and I hopeful that it will pass almost 100% on the next round of tests. I suspect there is issue with build/jamfile for cwpro8/9. Test_list has an issue with slist.hpp and iterators of all things. This effects all CW versions. Its possible its an slist issue on all platforms for all I know. As far as CW is concerned - I'm smelling blood and feel that I'm closing in on final victory. Anyone who wants to take a look at any of the above issues is free to do so. Robert Ramey

1 0

RE: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Reece Dunn 04 Aug '04

04 Aug '04

Vladimir Prus wrote: >Reece Dunn wrote: > >>I also wonder if it makes sense to sumbit just "dll" library, or some > >>additional plugin support need to be developed first. > > > > What sort of plugin support are you looking for? Do you mean something > > like COM/CORBA support or wrapper, e.g. something that can target both > > (and others like them) in one implementation? > >I'm not CORBA expert, but I think it's entirely different beast. To use >CORBA object you use stub generated from IDL, how it's related to plugins? >While there are some ways to find object dynamically, it's different >mechanism from shared libraries, isn't it? I am not sure how CORBA works. COM generally uses a different mechanism to load COM objects via CoCreateInstance, although DirectX exposes creation functions that circumvent this. I was thinking about being able to use COM/CORBA as a platform for object lifetime and dll lifetime management (as well as things like interface extension, etc.). >I though more about at least some kind of map<string, BasePlugin*> which is >updated automatically when you load new DLLs. So the dll implements some function: __declspec(dllexport) BasePlugin * GetMyPlugin(); so you can do something like: void load_plugins( map< string, BasePlugin * > & pi ) { for( map< string, BasePlugin * >::iterator i = pi.begin(); i != pi.end(); ++i ) { boost::dll plugin(( *i ).first ); ( *i ).second = plugin.import< ... >( "GetMyPlugin" ); } } It is possible to keep the DLL in memory until all instances of a class (or set of classes) by incrementing/decrementing a global object count variable on construction/deconstruction as is done when using COM. You then check this variable in the DllCanUnload function. You may need some reference counting mechanism to keep the plugin alive, but this is not necessary if you load all plugins on startup and release them at the end of the run. It should be possible to implement these facilities in a library, e.g.: class object_counter { private: static int objectCount = 0; public: inline int get_object_count(){ return( objectCount ); } public: inline object_counter(){ ++objectCount; } // make MT aware inline ~object_counter(){ --objectCount; } // make MT aware }; class reference_counter { private: int refCount; public: inline void add_ref(){ ++refCount; } // make MT aware inline void dec_ref() { if( --refCount == 0 ) // make MT aware { delete this; } } public: inline reference_counter( int rc ): refCount( rc ){} inline ~reference_counter(){} }; allowing: class plugin: public object_counter, public reference_counter, public BasePlugin { // ... }; __declspec(dllexport) BOOL DllCanUnload() { return( object_counter::get_object_count() == 0 ); } I'm not sure what the Linux equivalent would be. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

5 6

range & mpl
by Rob Lievaart 04 Aug '04

04 Aug '04

Hi All, The workaround test of the range library is failing for gcc 3.2 and 3.3 and for mingw with gcc 3.2. This seams to be caused by an incorrect placement of some macro's in mpl/if.hpp However, I do not know the correct placement. I've tried a few locations, but they all result in other errors, so I do not know what the right place is. mpl/if.hpp contains the follwoing code: ...snip... #if !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) BOOST_MPL_AUX_AGLORITHM_NAMESPACE_BEGIN ...snip... #else // no partial class template specialization ...snip... #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION BOOST_MPL_AUX_AGLORITHM_NAMESPACE_END ...snip... The value of BOOST_MPL_AUX_AGLORITHM_NAMESPACE_XXX depends on wheter we are using gcc ( >=3) or not. So the _BEGIN is set inside the #if and the and the _END outside. I tried putting the begin before the #if but that din't work, and the _END inside before the #else but that didn't work either. Looking at the other mpl files it seems things are not as simple as that :-(, but I have no idea how the mpl works, so I do not know what the correct solution is. Rob Lievaart.

2 1

RE: [boost] Re: Windows MSVC thread exit handler for staticly linkedBoost.Threadn
by Richard_Cox＠Dell.com 04 Aug '04

04 Aug '04

> -----Original Message----- > From: Aaron W. LaFramboise [mailto:aaronrabiddog51@aaronwl.com] > Sent: Tuesday, August 03, 2004 4:20 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Windows MSVC thread exit handler for > staticly linkedBoost.Threadn > The only concern I have--I don't know how important this is--is that > when a thread is killed with TerminateThread, I think neither TLS > callbacks nor DllMain()s will be called. This would cause > the TLS count > to never reach zero, and for TlsFree to never be called. > > These threads might not even be associated with the Boost TSS at all. > For example, another third party library in some DLL might be using > TerminateThread, and the application programmer may not even > know about > this, so it may be suprising to him when the reference count never > reaches zero for apparently no good reason. > I don't think cleanup after a TerminateThread would make any sense. TerminateThread does zero cleanup to start with (e.g. the threads is not freed). It would be inconsistent if any TLS cleanup was done in this case). Richard All opinions are mine and do not represent in any way the position of Dell Corporation.

1 0

RE: [boost] [build_monitor] again
by Rob Lievaart 04 Aug '04

04 Aug '04

Oops, it looks like I spoke to soon. _Assuming_ the ftp server is reporting file times in local time somewhere in the (middle of) the US, then the regression script did upload the results. In that case, the failing tests were stopped and it was just the error message that hung around. Wat remains is that monitor kills other windows that have error in the name on Windows 200 SP5. Other reports were from XP IIRC. I do not have nay problem with long lived processes being killed when they shouldn't be. Kind regards, Rob Lievaart. > I am having some trouble with the build monitor, it works fine > most of the time, but: > 1) Yesterday I locked the screen of the computer, this morning > when I returned the division by 0 errors were showing, and they > were not killed build_monitor, so the tests blocked. > > 2) As reported earlier, any window with error in the title is killed. > > This is on Windows 2000, SP5.

1 0