- Boost - lists.preview.boost.org

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

Javascript Tree Control [was: Serialization Menu]
by Jonathan Turkanis 31 Jul '04

31 Jul '04

Dear All, There was a discussion a couple weeks ago about the javascript menu in Robert Ramey's serialization docs. I suggested making a menu component available Boost-wide and testing it on a large number of browsers to address portability issues. I've written a preliminary version, documented here: http://tinyurl.com/6a9ym and downloadable from here (its a bit large because it contains a bunch of screenshots): http://tinyurl.com/6w56v (tree_control.zip) You can see the control in action here: http://tinyurl.com/6tdvy I've verified that it works -- with varying levels of functionality -- on 26 browsersincluding some antiques such as IE3.02.

8 25

typeof: automatic ID generation and GCC problems
by Arkadiy Vertleyb 31 Jul '04

31 Jul '04

Hi everybody, I modified the code to automatically generate IDs of registration groups. The registration now is as simple as: #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(...); BOOST_TYPEOF_REGISTER_TEMPLATE(...); ... I also added some tests that should cause the ODR violation (see odr.hpp, odr1.cpp, odr2.cpp). VC7.1 is fine with them, however I can't make GCC 3.3 to compile this, and it stops much before the ODR could be diagnosed. Looks like this compiler totally can't handle the case when I try to use typeof (native or not) inside a template. When I force the typeof emulation, I am getting: "sorry, unimplemented: `method_call_expr' not supported by dump_expr" on every attempt to use my encoding/decoding stuff inside a template. From searching the web it looks like this is some kind of known bug related to improper handeling of sizeof(). Since sizeof() is the central part of all this, I don't really know how to work it around... This would probably be OK, since GCC has the native typeof support. However, when I use the native support, I run into a different problem that can be illustrated by the following code: template<class T, class U> typeof(T() + U()) sum(const T& t, const U& u) { return t + u; } main() { sum(5, 3.14); // this is line 9 return 0; } The compile of this code fails with following message: a.cpp:9: internal compiler error: in write_type, at cp/mangle.c:1555 GCC appears to be fine when the native typeof is used inside _class_ templates, though. I would really appreciate if anybody shed some light on any of these problems... The code is in the Spirit CVS and at: http://groups.yahoo.com/group/boost/files/typeof.zip Again, eveything is working fine in VC7.1. If anybody could try any other compiler (to build main.cpp, odr1.cpp, and odr2.cpp together), I would really appreciate this. Thanks, Arkadiy

5 6

Boost.Python -- Works With Qt?
by Robert Bell 30 Jul '04

30 Jul '04

Hi boosters- I have some Qt widgets that I need exported to Python for use with PyQt. I've been looking into sip, but I'm also curious if boost.python is up to the task. Has anyone tried this? Bob

2 2