- Boost - lists.boost.org

[multi_index] regression in gcc-3.1-linux --seeminlgy MPL-related
by JOAQUIN LOPEZ MU?Z 08 Nov '04

08 Nov '04

Currently, one of the tests of Boost.MultiIndex is failing for GCC 3.1 under Linux: http://tinyurl.com/638oh The ICE happens inside boost/mpl/aux_/at_impl.hpp. This test used to work OK against the RC branch a couple of days ago. Any idea? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Auto-linking and getting started docs.
by John Maddock 08 Nov '04

08 Nov '04

I've added a section on auto-linking with MS-Windows compilers in the getting started docs, in the main branch only (No URL yet, cvs hasn't cycled it through yet, but it'll be at http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/more/getting_s… eventually). If it looks OK, I'll commit to the release branch as well. John.

5 6

Re: [boost] [multi_index] regression in gcc-3.1-linux --seeminlgyMPL-related
by JOAQUIN LOPEZ MU?Z 08 Nov '04

08 Nov '04

----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Domingo, Noviembre 7, 2004 7:15 pm Asunto: Re: [boost] [multi_index] regression in gcc-3.1-linux -- seeminlgyMPL-related > JOAQUIN LOPEZ MU?Z wrote: > > Currently, one of the tests of Boost.MultiIndex > > is failing for GCC 3.1 under Linux: > > > > http://tinyurl.com/638oh > > > > The ICE happens inside boost/mpl/aux_/at_impl.hpp. > > > > This test used to work OK against the RC branch > > a couple of days ago. Any idea? > > Neither CVS head, nor the RC branch have been tested > against gcc 3.1 under Linux. I (re)added this compiler > because I had spare CPU time. > > I don't think gcc 3.1 is something one has to worry > about too much. I doubt it is much in use. (Either > people still stick to the even more broken gcc 3.1 > or they use gcc 3.3 or even 3.4) You're absolutely right, even my docs state that GCC 3.1 is not supported by Boost.MultiIndex. Sorry for the noise. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: GUI Library Proposal for a Proposal
by Reece Dunn 08 Nov '04

08 Nov '04

Russell Hind wrote: >Edward Diener wrote: >> >>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go >>there, or have anything to do with supporting any other GUI >>implementation. > >Also, wxWindows is a huge library. If we were to introduce something in >boost, I'd very much like it to be as small and light weight (as win32gui >is supposed to be), not a collection of multi-megabyte dlls required, just >to wrap win32 or what ever the underlying library is. I am in the process of writing a platform-independant GUI (available at: http://uk.geocities.com/msclrhd/gui/gui.zip) that aims to be small and lightweight. This code is stll in the early stages and currently targets Win32/64 with minimal Cocoa/PalmOS support. >If people want more powerful components, they can be added afterwards, but >the underlying library around core OS controls should be as small as >possible. In my library, I am working on: * gui::event_handler supporting lightweight "windowless" controls * gui::window supporting windows like the main frame, MDI child frames, etc. * gui::form (i.e. a frame with controls/layout set by an external designer referenced by ID) that includes dialog boxes in Win32. I do not have an implementation of gui::form yet. * gui::control supporting controls/widgets like buttons within a window or form These 4 classes should then make it possible to derive your own classes to support edit controls, property sheets, MDI windows, etc. I do not explicitly implement any of these extra UI components because they are platform dependant and will add to the complexity of the framework. This is especially true for things like "splitter" windows and floating/docking toolbars. Also, other components can be added at a later stage if necessary. As for the event processing mechanism, I have decided to use a std::map< event_id, void ( gui::event_handler::* )( gui::event * ) > that allows: class main_frame: public gui::window { public: void ev_destroy( gui::event * ); void EvDraw( gui::event * ); main_frame( gui::string name ): gui::window( ... ) { set_handler( WM_DESTROY, &main_frame::ev_destroy ); set_handler( WM_PAINT, &main_frame::EvDraw ); } }; At the moment, this does not support chaining of handlers (something on my todo list). The main event loop is controlled via gui::event_loop that does support filtering of events (e.g. processing keyboard shortcuts). There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that make use of properties allowing window positions to be handled in a platform-independant manner, e.g.: void main_frame::resizing( gui::event * ) { area a = get_client_area(); a.deflate( gui::size( 5, 5 )); pane -> move( a ); } At the moment, you need to register Win32/64 window classes using: gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE ); but I am looking to abstract this. I am all for getting a group of people together from the boost mailing list interested in GUI and developing a general GUI framework. It may be useful to have at least one person from the C++ standards committee to get input from the standards people. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

10 26

how to compile regression tests
by Roland Schwarz 07 Nov '04

07 Nov '04

Sorry for this possibly naive question. But I can't figure out how to compile the regression tests. So far I found cd'ing into a specific libs/test directory and invoking bjam on it compiles the test for a specific library. But how can I compile all? I cannot find a rule like stage or install in the root Jamfile. Isn't it possible to recurse through all directories? Then I cannot manage to get a results page using the description in http://www.boost-consulting.com/boost/more/regression.html Instead I get: > C:\Programme\boost>SET PYTHON_ROOT=C:\Programme\Python23 > > C:\Programme\boost>SET BOOST_ROOT=C:\Programme\boost > > C:\Programme\boost>SET TOOLS=vc-7_1 > > C:\Programme\boost>ECHO ON > > C:\Programme\boost>cd C:\Programme\boost\status > > C:\Programme\boost\status>bjam --dump-tests test 1>bjam.log 2>&1 > > C:\Programme\boost\status>REM start notepad bjam.log > > C:\Programme\boost\status>process_jam_log 0<bjam.log > Usage: bjam [bjam-args] | process_jam_log [--echo] [locate-root] > locate-root is the same as the bjam ALL_LOCATE_TARGET > parameter, if any. Default is boost-root. > boost_root: C:/Programme/boost/status/.. > locate_root: C:/Programme/boost/status/.. > no errors detected > > C:\Programme\boost\status>compiler_status C:\Programme\boost cs-win32.html > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>rem Specify links file, even though it will > be overwritten, so report html includes links > > C:\Programme\boost\status>rem This works because the generated > bookmark names are the same regardless of other settings > > > C:\Programme\boost\status>compiler_status --ignore-pass --no-warn > C:\Programme\boost cs-win32-fail.html cs-win32-links.h > tml > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>compiler_status --ignore-pass > C:\Programme\boost cs-win32-warn-or-fail.html cs-win32-links.htm > l > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>compiler_status C:\Programme\boost > cs-win32-full.html cs-win32-links.html > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status> I am using vc7.1 on W2 with the latest CVS MAIN. I currently assume this should work under windows, doesn't it? Thank you for help, Roland

1 0

build / install in 1.32
by John Maddock 07 Nov '04

07 Nov '04

Should the following messages be generated during an install? They are rather alarming IMO, there are a huge number of them, and I predict will generate queries along the lines of "is this right, did my build succeed?" HardLink stage\lib\boost_thread-vc71-mt.lib Could Not Find c:\data\boost\release\boost\stage\lib\boost_thread-vc71-mt.lib HardLink stage\lib\libboost_thread-vc71-mt-sgd.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-sgd.lib HardLink stage\lib\libboost_thread-vc71-mt-s.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-s.lib Thanks, John.

3 2

Getting the reference out of boost::any
by Mikhail Glushenkov 06 Nov '04

06 Nov '04

I became interested in subj and quickly found a discussion on boost mailing list dated Jan 2003 (http://lists.boost.org/MailArchives/boost/msg42284.php) where the majority seemed to agree on changing current semantics of boost::any_cast to allow getting the reference to held object. However, these changes never made it to the CVS. Was it by intent or was this issue banally forgotten?

1 0

Unicode strings update
by Erik Wien 06 Nov '04

06 Nov '04

Hi. I just thought I would post a little update on what's happpening with the Unicode library I started a thread about a little while ago. (I apologize for not replying as much as I should have done in that thread, but I have been completely buried in work lately, and simply haven't had the time. =\ ) My college (HiG) has now basically approved the project as a bachelors thesis (at least for the time being), and it is looking very likely that we will go through with it. There's one little snag though. HiG would like to have one person from the boost community functioning as a "contact person" for the project. I'm not sure exactly what kind of workload that imply for such a person (I will try to find out very soon), but I am fairly certain it will just be a matter of answering a few e-mails from them from time to time. After all, the main development will be done in collaboration with the community as a whole, and not that single person. What I basically want to know is, would anyone out there like to take on that resposibillity? I don't think this is an absolute requirement for final approval, but it sure would help! =) Let me just finish off by thanking for all comments you guys made in my first thread. I'm in the process of compiling a list of all the things you pointed out there, and I will most certainly take everything said into concideration when the development (hopefully) gets on the way. As always... Any comments are welcome! ;) Regards - Erik

7 12

usage of uniform_int
by Masaki Nomura 06 Nov '04

06 Nov '04

Dear all: Would anyone let me know the usage of the boost::uniform_int combined with the one argument operator() of the variate_generator? I'd like to change the maximum parameter of the distribution at every step. #include <iostream> #include <boost/random.hpp> int main( void ) { boost::variate_generator< boost::mt19937, boost::uniform_int< std::size_t > > gen( boost::mt19937( 3 ), boost::uniform_int< std::size_t >() ); for ( std::size_t i(1); i < 100; ++i ) std::cout << gen( i ) << std::endl; return 0; } The gcc aborted the compile with the following errors: /usr/include/boost/random/variate_generator.hpp: In member function `typename Distribution::result_type boost::variate_generator<Engine, Distribution>::operator()(T) [with T = unsigned int, Engine = boost::mt19937, Distribution = boost::uniform_int<size_t>]': uniform_int.cpp:9: instantiated from here /usr/include/boost/random/variate_generator.hpp:107: error: no match for call to `(boost::uniform_int<size_t>) ( boost::random::detail::pass_through_engine<boost::random::detail::pass_through_engine<boost::mt19937> >&, unsigned int&)' With regards, Masaki Nomura

2 2

Re: [boost] Re: 1.32 documentation issue
by JOAQUIN LOPEZ MU?Z 06 Nov '04

06 Nov '04

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Martes, Noviembre 2, 2004 9:06 pm Asunto: Re: [boost] Re: 1.32 documentation issue > At 12:39 PM 11/2/2004, Robert Ramey wrote: > > >Actually after poking around in other pages - specifically the > spirit >documentation I find that its not uncommon for links to > point to > >www.boost.org rather than have a relative path that would keep > the > session > >in the same documentation tree. This would seem to conflict > with the > idea > >that boost should be usable as a CDROM distribution. > > > >I don't know if there's time for this but the inspect should be > enhanced > to > >check for this and all the offending global links should be > altered to > >relative ones. > > We tried to do that at one time, but gave up because it is a bit > tricky. > Some absolute www.boost.org references are correct, such as to the > LICENSE > file, so it isn't as simple as just searching for "www.boost.org/" > in .htm? > files. > > I've just taken a look (using grep) at the CVS RC (not the > tarball) and it > seems that while the problem does happen, particularly in spirit > and graph > libraries, it isn't really horrible. > > I'd say we can wait until after the release ships, then see if we > can come > up with some logic that doesn't generate a lot of false positives. > Automatic detection aside, would it be possible to fix the offending links manually before release? Maybe it's not that straightforward, if those links are generated from BoostBook source. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2