- Boost - lists.boost.org

[serialization] use of iterator_facade, CW8 build fixed.
by Rene Rivera 31 Jul '04

31 Jul '04

In another painfully hunt to fix the problems with the seriazation lib issues in CW8... I tracked the problem down to another instance of: static_cast<const&>(x) where x is a template with template ctors. The problem was in iterator_facade, and not directly in the serialization lib which made it even harder to find :-( Anyway, I applied this change (figured since this is a known problem by now with an easy portable solution it would not be a problem)... =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/iterator_facade.hpp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iterator_facade.hpp 31 Jul 2004 18:10:00 -0000 1.26 +++ iterator_facade.hpp 31 Jul 2004 22:56:49 -0000 1.27 @@ -814,8 +814,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - static_cast<Derived1 const&>(lhs) \ - , static_cast<Derived2 const&>(rhs) \ + *static_cast<Derived1 const*>(&lhs) \ + , *static_cast<Derived2 const*>(&rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } =================================================================== After that the serialization lib builds, and tests run. Of course not all tests pass ;-) VC7.1 and Mingw behave as before also. PS. There was one other minor change to the libs/serialization/test/Jamfile to account for locale requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[Graph] New branch for graph library development (graph_devel)
by Doug Gregor 31 Jul '04

31 Jul '04

I've started a new branch for further development of the graph library, graph_devel. At the moment it contains only a small amount of work (Brandes' algorithm for betweenness centrality and the Kamada-Kawai spring layout for undirected graphs), but it will be used for more aggressive development as well. Algorithms will be merged to mainline so long as we _aren't_ planning a release in the next few days, but any infrastructure changes will remain on the branch for a bit longer. I've only branched the boost/graph and libs/graph directories. Doug

1 0

[thread] barrier.cpp don't compile with msvc60 & stlport]
by Sven Johannsen 31 Jul '04

31 Jul '04

Hi, with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60. I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3" and get the following errortext: ...\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero."); because the StlPort defines invalid_argument as: class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif }; With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc") Sven

5 10

Boost-wide report -- explicit failure markup not working?
by Jeff Garland 31 Jul '04

31 Jul '04

Looking at the boost-wide reports today, testmicrosec_time_clock is marked as failing red on a whole series of compilers. However, they should be 'green' (and have been in past reports) as they have been explicitly marked as failing: http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… <test name="testmicrosec_time_clock"> <mark-failure> <toolset name="msvc"/> <toolset name="vc7"/> <toolset name="vc7.1"/> <toolset name="cwpro8"/> <toolset name="borland-5.6.4"/> <toolset name="gcc"/> <toolset name="borland"/> <toolset name="mingw"/> <toolset name="meta-como-win32-4.3.3-msvc"/> <note author="B. Garst" refid="22"/> </mark-failure> </test> Seems like there is something amiss in the results reporting... Jeff

5 5

Re: [boost] Re: Boost-wide reports: Time to join in!
by JOAQUIN LOPEZ MU?Z 31 Jul '04

31 Jul '04

----- Mensaje original ----- De: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> Fecha: Jueves, Julio 29, 2004 7:52 pm Asunto: Re: [boost] Re: Boost-wide reports: Time to join in! > > > >I'd be extremely grateful if you could run MSVC 8.0 tests to > >check a fix I just commited, even if you don't upload the results to > >the Boost-wide reports page (of course, if you do that too so much > >the better.) > > I just started a rerun my testing > Big thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 8

RE: [boost] Re: Re: Re: Javascript Tree Control [was: SerializationMenu]
by Reece Dunn 31 Jul '04

31 Jul '04

Jonathan Turkanis wrote: > > If we do this, then it should be possible to do something like: > > > > <span onclick = "follow_link(1.5)">Chapter 1.5</span> > >This would be embedded in an anchor element, to allow links to work on >no-script browsers? I think this should work. I'll see if I can get frames/tree_control working in Boost.Book and start experimenting with the code. > > With regards to the page refreshing, this happens when you select >"sync" > > anyway. > >Yes, but I was thinking that "sync" would be used relatively >infrequently, whereas following links within a page is common. Sure. > > Is it possible to use '#' instead of '?', so the browsers won't > > refresh the docs. > >If we use Rene's idea of displaying the tree in the content frame, >then yes (I think). Otherwise, the url with the correct fragement >identifier won't be displayed in the address bar. Okay. >Including the tree in the content frame is a big problem, though. When >I replied to Rene I was mostly worried about download times when >viewing the docs online. But if a large part of the docs eventually >use trees, it could unnecessarily increase the size of the Boost >distribution. We could use iframes, but this won't work for old >browsers. Sure. It would be a good idea to have a working XSLT for Boost.Book/tree_control first so we can try out the various ideas. >I'd like to focus on: > > 1. Providing a tree control which library authors can add to >hand-written docs > 2. Allowing docs generated with Boost.Book to have a built-in tree >control, with automatic synchronization if possible > >1) is basically done, unless someone has an idea how to eliminate the >need for [sync] >2) is doable, with hitch that linking within a page causes a reload >(unless I misunderstood your suggestion) The main steps for writing the Boost.Book XSLT code are: 1. Disabling section ToC's; 2. Overriding the default ToC mechanism in favour of the tree control menu; 3. Providing "chunks" for the main frame page and the ToC page; 4. Iterating over the various sections and extracting the names of the "chunks" to use as the links; 5. Modifying the way sections are generated if necessary to accommodate the new control; 6. Anything I've forgotten. >I think only time will tell whether it's more annoying to have to >manually [sync] the documentation or to reload the docs when linking >within a page. So I'd say two variants of 2) should be pursued: one >which produces docs using the existing tree component, and one which >produces auto-syncing docs. Once the code is written it should be possible to play around with what it generates to test the ideas that you and Rene are suggesting. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] White cells
by Rozental, Gennadiy 31 Jul '04

31 Jul '04

> > - test: ifstream_line_iterator_test > > Commented out by the author -- > http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/test/te st/Jamfile?r1=1.23&r2=1.24 > I'm not sure whether this is a good practice. I'd say that if the test > failure indicates a real issue with the library on a particular set of > compilers -- even if that set includes most of them -- then marking it up as an "expected failure" with a corresponding note would be more fair. > Michael? Gennadiy? Above test actually should pass on almost all compilers (as it does locally). For some reason it fails during regression test. Something about couldn't find pattern file. So, because 1. I do not know how to fix that. 2. Nobody responded on my request 3. This test is not critical for this release 4. We have enough on our plates already I decided to comment it out for now. I plan to reinclude it after release. Gennadiy.

2 1

RE: [boost] Re: Re: Javascript Tree Control [was: Serialization Menu]
by Reece Dunn 31 Jul '04

31 Jul '04

Jonathan Turkanis wrote: >"Rene Rivera" <grafik.list(a)redshift-software.com> wrote in message >news:410B0839.1030106@redshift-software.com... > > Jonathan Turkanis wrote: > > > > I'd love synchronization to be automatic but I just don't see how > > > to do it. > > > > It's possible but only if you invert the relation between the frames and > > the documents. If instead of making a frameset with the tree and the > > document you could instead make the document inline the tree frame > > inside the document page and hence the URL would always be direct > > (using iframe tag). This might be contrary to one of the intrusion > > principles, but it would solve the problem. > >I've thought a bit more about this, and it occured to me that if the >tree is displayed in the same frame as the content, it's state will >not be preserved when a link is followed unless this info is added to >the url. So it appears this idea suffers from the same problems as >Reece's suggestion. The question here is: are we going to place the emphasis on auto-generated docs? If we do this, then it should be possible to do something like: <span onclick = "follow_link(1.5)">Chapter 1.5</span> With regards to the page refreshing, this happens when you select "sync" anyway. Is it possible to use '#' instead of '?', so the browsers won't refresh the docs. This might require a standard naming scheme for <a name = "..."/> marked sections, but this would be easier to do if the docs are auto-generated. For older docs that want to keep their HTML structure but move over to the treeview control, it should be easy to do if: 1. They are compatible with XHTML (i.e. they can be loaded in an XML client and manipulated via an XSLT stylesheet, e.g. using xsltproc). NOTE: This should be trivial if the HTML has been run through htmltidy. 2. The section format follows a regular pattern, e.g. h1 elements for level 1, h2 for level 2, etc. This would allow you to: 1. Insert and generate the treeview control by making a pass over the hN tags. 2. Clean up sections of the form: <a name = "..."/><hN>...</hN> Issues would be: 1. Do we remove the ToC provided in the HTML doc (can we detect and remove/use it?) 2. Have we detected the document structure correctly? 3. Other issues I've missed. Regards, Reece Dunn _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: Threads Rewrite?
by Tonko Juricic 31 Jul '04

31 Jul '04

> Dayton wrote: > ... I tend to think in the similar direction. Threads class happens to be the first one that I tried to use as a newcomer to boost++ so I ended up 'complaining' here. In particular, losing features that one learns to take for granted on some platforms (like thread stop, suspended start) is not motivating. Also, relying on OS notifications (like DLL_THREAD_DETACH on Win32) for TLS cleanup, and extra code required to support boost threads static library on Win32 is not my favourite, despite a rather ingenious implementation. I think it would be best if we can completely avoid using Win32 DLL process/thread notifications and make TLS cleanup part of the thread function object. I already expressed, somewhat radical I guess, opinion that, at least on Win32, TLS functionality is probably not worth the trouble of existing cleanup support code. Tony __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

9 24

Threads Rewrite?
by David Abrahams 31 Jul '04

31 Jul '04

Hi Boosters, I've tried several times to contact Bill Kempf about moving forward with threads, even leaving him messages on his home answering machine. I've had no reply. It's important that we make an effort to move Boost towards a uniform licensing scheme, and the threads library is an especially important one to do that for. We've been talking about significant restructuring in this library; is it likely that we'll get to a point where the original code can be thrown out? That may be the only way we'll be able to change the license. IMO the docs really *need* to be thrown out and re-done, even if the design were to stay substantially the same. Thoughts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

15 40