- Boost - lists.boost.org

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

release status?
by Pavol Droba 31 Jul '04

31 Jul '04

Hi, What is the current status of the release? I have just returned from vacation and I can't find out what is happening. Thanks, Pavol

2 1

Re: [Spirit-devel] Re: Spirit: Some more regressions
by Joel de Guzman 31 Jul '04

31 Jul '04

David Abrahams wrote: > Joel de Guzman <joel(a)boost-consulting.com> writes: > > >>2) VC8: http://tinyurl.com/3jmem > > > VC8 isn't released yet so problems there can't be considered > regressions. > > Also, I think you can download a free public beta so you the compiler > need not remain inaccessible to you. Ok, thanks. I downloaded it and I am using it for testing now. AFAICT, there's no problem with Spirit code and the errors above (which is ok on all compilers, including Comeau) seem to be VC8.0 bugs. For that matter, wouldn't it make sense for VC8.0 in the test reports be named as VC8.0 Beta to avoid confusion? << Now I notice more and more compilers added in the reports. Cool! Yet... arghhh! More yellows!!! >> Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Range/workaround test: SFINAE defect on EDG?
by Stefan Slapeta 31 Jul '04

31 Jul '04

First of all, the most important question: Why do we test workarounds for partial spezialization on compiler which don't need these workarounds? I've isolated the problem with the failing range/workaround testcase on Intel 8. IMO it's a compiler defect because the function template in is_array should be disabled by SFINAE. This code fails to compile with the current comeau release, too. template <class T> struct wrap {}; // this one should disabled because it's not allowed to return an array: template< typename T > T(* is_array_tester1(wrap<T>) )(wrap<T>); char is_array_tester1(...); void f() { sizeof(is_array_tester1(wrap<int[42]>()); } Shall a submit a DR? Stefan

5 5

White cells
by Stefan Slapeta 31 Jul '04

31 Jul '04

Please could anybody explain me what the reason for white cells in the regression tests is and why these tests are not executed? Concrete examples are: - test: ifstream_line_iterator_test - numeric/ublas: test7 Thanks, Stefan

2 1