September 2004 - Boost - lists.preview.boost.org

Still problems with current cvs (libs/python/src/converter/type_id.cpp)
by Neal Becker 16 Sep '04

16 Sep '04

gcc-3.3.3 (linux): In file included from /usr/local/src/boost.cvs/libs/python/src/converter/type_id.cpp:7: /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp: In function `boost::python::detail::decorated_type_info boost::python::detail::decorated_type_id(boost::type<T>*)': /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:40: error: syntax error before `>' token /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:42: error: syntax error before `>' token

2 1

IOStreams endianness filter
by Tony Juricic 15 Sep '04

15 Sep '04

Just a thought. My tests so far were too limited to write a review (maybe reviews could last a little longer?), but in the process I stumbled on one image file in big-endian format and thought it may deserve to be mentioned here. Tony

2 4

Aaron's Informal Proposal for a Universal Demultiplexor for Boost
by Aaron W. LaFramboise 15 Sep '04

15 Sep '04

Well here it is. This is a very sketchy "brain dump" of the general form of demultiplexor I have been referring to. I think that it might be a basis for something eventually acceptable as a general demultiplexor for Boost. The general concept comes from a demultiplexor library that I have implemented privately (perhaps it could now be considered a prototype). I've tried to introduce the library design from a standpoint of rationale. This description is quite vague, but hopefully it will be a sufficient starting point. As always, comments of all kinds are appreciated. Aaron's Informal Proposal for a Universal Demultiplexor for Boost <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing…> Aaron W. LaFramboise

6 18

behond IOStreams
by Carlo Wood 15 Sep '04

15 Sep '04

Hiya all. I already briefly discussed this with Jonathan Turkan and I understood he is interested to continue on a new project when IOStreams is accepted. I'd like to work together with him in this new project. In the past week I've done some "research" (between quotes because I still very new to this, can't call myself knowledgable yet). I'd start an early kick-off with this post ;). IOStreams can be seen as a library that allows one to define the following: Source --> filter --> filter --> Sink The relationship between the types involved can be delayed till runtime, but each individual type above has to be coded before that. It makes most sense to look at the above as instances instead of classes therefore (cause I did draw in the relationships between the different types already): Source_instance --> filter_instance --> filter_instance --> Sink_instance But for brevity I will not type the '_instance' part anymore. Obviously, we can have multiple Sources and Sinks at the same time: Source --> Sink Source --> filter --> filter --> Sink Source --> filter --> filter --> filter --> Sink Source --> filter --> Sink ... Each of these Sources will need to be handled by the Operating System; for example if they are sockets. In order to make an application work one will need "event demultiplexing" like forinstance is provided by select() or poll(). In order to write a framework that can "connect" the Sources and Sinks to this event demultiplexor in a flexible, portable and efficient way - a lot of design decisions need to be taken. Below I have made a list of a few topics that we can discuss, one by one - in order to make progress with these decisions. I am aware that there has been made a beginning with a design for such a framework already with boost in mind (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket) This design mainly considers sockets, but I think that a much wider approach is necessary (as we can discuss by following the points below). But of course we will use anything of this project that is useful. Another important source of experience is libACE. Although libACE provides everything we might need, it doesn't 'connect' well to boost; it has a lot of interfaces that are already done in boost but in another way. Also, I think that libACE is doing more than we need and not everything that we might want. If it were possible to write a more 'native' event demultiplexing library for boost then that will definitely add useful and additional functionality for the open source community. Apart from that, there is the license issue. I believe that the boost libraries are more 'free' then ACE, so in some cases ACE might not even be an option. ========================================================== Follows: Topics that can be discussed. I'd like to urge to stick to one Topic per thread. 1. Is there a need for this library? Should be a new effort like proposed or do we have to revive 'boost Sockets' and only build upon that without throwing things away? If "yes - there is a need for it and we might as well start with a clean plate": For the below I have chosen to phrase the topics as statements that I believe I can give sufficient argumentation for (if needed). 2. It is unavoidable that this library uses threads. 3. User programs compiled for platform A, and linking with a shared versions of this library - do not need to be able to run on platform B (with same architecture) without recompilation. 4. It is unacceptable that we would depend on other libraries (libevent, libACE) for this, except standard libraries (libc, libstdc++, socket, ws2_32, etc). 5. We should heavily lean on the expertise that is condensed in libACE for things like the following: There must be a concept "Event Handler" (the 'call back'). There must be a concept "Acceptor", "Connector" and "Handle" types. 6. The ideas about I/O filtering as discussed for Apache (see http://www.serverwatch.com/tutorials/article.php/1129721) need to be analyzed and probably implemented in IOStreams before we can really design the demultiplexor library. I will start a thread for each of these topics. Please reply to the first subject that you do not agree with (yet) only: it makes no sense to participate in discussions with a higher number if you disagree with the statement of one with a lower number :) Regards, -- Carlo Wood <carlo(a)alinoe.com>

10 54

Re:Re: [boost] serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

Matthias Troyer wrote: >Shall I get you an account on a machine with that compiler? Latest test results seem to show this to be resolved. Thanks to whomever addressed. I'm sure it wasn't me. Robert Ramey

1 0

Re: Re: Re: IOStreams formal review -- extended
by Jonathan Turkanis 15 Sep '04

15 Sep '04

"Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:... > (i) buffering will be omitted, since it's hard to do correctly. > (ii) buffering will be provided, but mistakes in pointer arithmetic will cause > subtle errors > (iii) sub-optimal algorithms will be used. > > Note that two of Daryle's stream buffers suffer from defect (i). I didn't mean to imply that Daryle omitted buffering because it was hard -- I assume he had some other reason. Jonathan

1 0

Current cvs build broken (/boost/python/detail/signature.hpp)
by Neal D. Becker 15 Sep '04

15 Sep '04

/usr/local/src/boost.cvs/boost/python/detail/signature.hpp: In static member function `static const boost::python::detail::signature_element* boost::python::detail::signature_arity<11>::impl<Sig>::elements()': /usr/local/src/boost.cvs/boost/python/detail/signature.hpp:34: error: syntax error before `;' token...interrupted .

2 1

serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

There are a group of test failures of the serialization library on intel 8.0 on linux. See http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html These are all associated with serialization of collections. I would guess that these are probably all variant manifestations of the same problem. Other interesting facts are: a) intel 7.1 passes on linux and win32 b) intel 8.0 passes on win32 Is there someone who has an interest in this platform would like to look into this? It would be very helpful. Robert Ramey

2 1

spirit 1.8 / vc 8.0 test results
by Robert Ramey 15 Sep '04

15 Sep '04

Spirit 1.8 with vc 8.0 is showing some test failures which impact the serialization library. In particular, the chest test is failing. Is this going to be addressed? Perhaps the vc 8.0 compiler being used for the test should be updated to the latest version if it hasn't been already. I think this would be very useful. Robert Ramey

3 2

problems with serialization regression tests
by Bronek Kozicki 15 Sep '04

15 Sep '04

I have a problem when running regression tests on Comeau compiler (toolset como- win32- 4.3.3- vc7.1) . Three tests: test_set_text_archive test_set_binary_archive test_set_xml_archive are taking above 1.5GB memory when running, thus my machine is slowing to crawl due to memory trashing (I have only 1GB RAM). I think there's something wrong with these tests? B.

1 0