- Boost-users - lists.preview.boost.org

Re: Boost-users Digest, Vol 378, Issue 4
by Yarden Livnat 23 Nov '04

23 Nov '04

no, the problem persist in build 1671... :-( compiling with --without-serialization temporarily solve the problem though (if you can call it 'solving' :-) Yarden On Nov 23, 2004, at 2:02 PM, boost-users-request(a)lists.boost.org wrote: > > Message: 4 > Date: Tue, 23 Nov 2004 11:07:31 -0800 > From: Thomas Costa <oohrah(a)mac.com> > Subject: Re: [Boost-users] compiling 1_32 in release mode brings the > computer to its knees (Modified by Yarden Livnat) > To: boost-users(a)lists.boost.org > Message-ID: <ECC0A694-3D82-11D9-84B9-00039303FB26(a)mac.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Are these problems maybe fixed with Apple's updated gcc 3.3 build 1671 > that got posted to the Apple developer site recently? > > On Nov 23, 2004, at 10:19 AM, Chris Little wrote: > >> on 11/23/04 9:32 AM, Glen Simmons at gsimmons(a)macdev.itg.ti.com wrote: >> >>> On 23 Nov, 2004, at 12:17 AM, Mail Delivery Subsystem wrote: >>> >>>> >>>> Hi, >>>> >>>> I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 >>>> 20030304 (Apple Computer, Inc. build 1666) >>>> however, while the debug version compile in just a few minutes, the >>>> 'release' start trashing on : >>>> libs/serialization/src/xml_grammar.cpp >>>> libs/serialization/src/xml_wgrammar.cpp >>>> >>>> in effect the compilation takes all the memory and then pages >>>> endlessly for hours, bringing the machine down to its knees. >>>> >>>> my compile command is: >>>> >>>> sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi >>>> <define>BOOST_SIGNALS_NAMESPACE=Signals " install >>>> >>>> where the <define> is for Qt, >>>> >>>> >>>> Anybody has a clue why this is happaning and how to get the >>>> compilation to complete (other then copy the two .o from the debug >>>> tree into the release tree ? >>> >>> The same thing happened to me. Since I'm not using the serialization >>> library, I used the --without-serialization option. Not an ideal >>> solution, especially if you need the serialization lib, but a >>> workaround if you don't. >>> >>> HTH, >>> Glen Simmons >> >> On the main list Troy Straszheim post about this problem also. Troy >> found >> that it is a compiler bug. If you remove the -O flag from the build >> options >> then everything is fine. Troy filed a bug with Apple. >> >> Chris >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users > > >

1 0

Re: [Boost-users] IMPORTANT: yahoogroups admin rights problem
by Daniel L Elliott 23 Nov '04

23 Nov '04

Hello all, Where can I find the uBLAS license? What does rewrite uBLAS mean? Toon: Thank you for working on these issues! Thank you, dan elliott ------------------------------ Message: 6 Date: Tue, 23 Nov 2004 12:42:02 +0100 From: Toon Knapen <toon.knapen(a)fft.be> Subject: [Boost-users] IMPORTANT: yahoogroups admin rights problem To: ublas <ublas-dev(a)yahoogroups.com>, Michael Stevens <Michael.Stevens(a)epost.de>, boost-users(a)lists.boost.org, boost <boost(a)lists.boost.org> Message-ID: <41A3220A.7060104(a)fft.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello ALL, As many of you might know, currently we are unable to add new members to the ublas-ml. The problem is that only Joerg has the rights to add members to the list but Joerg does not respond anymore. Could some of you try to contact Joerg or give me his telephone number that I talk to him about this. If we do not have a solution by end of November I will create a new project on yahoogroups (and we all have to switch). Additionally we need to contact Joerg and Mathias (again!) about applying the Boost Software License. I currently have the impression that they are not willing to change ublas to the BSL. In that case IMO, we will have to rewrite uBLAS to not get thrown out of boost. Again his phone-number would be handy if you have it available. Please contact the ml or me asap about the above issues or we will need to take drastic actions. toon ------------------------------

2 1

Re: [Boost-users] Gregorian 1.32 still has VC71 warnings like 1.31
by jkharris7＠comcast.net 23 Nov '04

23 Nov '04

> most of the warnings have been L4, but unless I'm mis-reading you are set to > L3? Also, are you sure all of these were in 1.31 -- there were changes in Yes, it's set to Level 3, and no--you're right to point it out--I'm not sure whether the warnings are exactly the same as in 1.29. They were the same code (4244), because I ended up using the same suppression pragma. Everything is a plain vanilla VC71 setup, generated from the wizard, except with "Detect 64-bit Portability Issues" set to FALSE, and I tested using no other headers, just to be sure. jh

1 0

Using program_options with other options methods
by Allen Bierbaum 23 Nov '04

23 Nov '04

I have recently started using the program_options library, and I find it very useful. Unfortunately I can't seem to figure out how to allow it to work with other option parsers/handlers at the same time. For example, right now I am writing an application that uses a library that has its own set of common options that are process internally. So I end up needing to write code similar to the following: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); custom_lib::options opts; opts.process(ac, av); Then when I run this application: ./app --my_opt=10 --liboption=custom The problem is that I get an exception from program_options: error: unknown option --liboption Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers? -Allen

1 0

Gregorian 1.32 still has VC71 warnings like 1.31
by jkharris7＠comcast.net 23 Nov '04

23 Nov '04

Do I have some incorrect options here? I would've thought these would go away, but they were the same in 1.31. I can't find others reporting the same warnings. With this at the beginning of my source: #include <boost/date_time/gregorian/gregorian.hpp> #include <boost/date_time/posix_time/posix_time.hpp> #include <boost/date_time/date_generators.hpp> ...on VC71, boost 1.32 with all defaults during build of boost, with these compiler options: /Od /I "..\..\..\Vendor\Boost\1_32_0\include\boost-1_32" /I "..\..\..\Vendor\ace\5_4\dev" /I "..\..\..\Vendor\Apache\Xerces_C\2_6_0\dev" /I "..\\" /D "WIN32" /D "_DEBUG" /D "_LIB" /D "_MBCS" /Gm /EHsc /RTC1 /MDd /GS /Fo"Debug/" /Fd"c:\my_lib\/lib/my_libD.pdb" /W3 /c /Zi /TP .\MyFile.cpp ...and getting these warnings: ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\time_system_coun ted.hpp(57) : warning C4244: 'initializing' : conversion from 'boost::date_time::counted_time_rep<config>::int_type' to 'boost::date_time::gregorian_calendar_base<ymd_type_,date_int_type_>::date_int_t ype', possible loss of data with [ config=boost::posix_time::millisec_posix_time_system_config ] and [ ymd_type_=boost::gregorian::greg_year_month_day, date_int_type_=boost::date_time::int_adapter<unsigned long>::int_type ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\time_system_coun ted.hpp( 52) : while compiling class-template member function 'boost::date_time::counted_time_rep<config>::date_type boost::date_time::counted_time_rep<config>::date(void) const' with [ config=boost::posix_time::millisec_posix_time_system_config ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\time_system_coun ted.hpp( 111) : see reference to class template instantiation 'boost::date_time::counted_time_rep<config>' being compiled with [ config=boost::posix_time::millisec_posix_time_system_config ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\time.hpp(52) : see reference to class template instantiation 'boost::date_time::counted_time_system<time_rep>' being compiled with [ time_rep=boost::posix_time::int64_time_rep ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\posix_time\ptime .hpp(32) : see reference to class template instantiation 'boost::date_time::base_time<T,time_system>' being compiled with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\date_parsing.hpp (211) : warning C4244: 'argument' : conversion from 'std::allocator<_Ty>::value_type' to 'char', possible loss of data with [ _Ty=wchar_t ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\date_parsing.hpp (253) : see reference to function template instantiation 'date_type boost::date_time::from_stream_type<date_type,std::basic_string<_Elem,_Traits,_Ax >::iterator>( iterator_type &,iterator_type &,wchar_t)' being compiled with [ date_type=boost::gregorian::date, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t>, iterator_type=std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator < wchar_t>>::iterator ] ..\..\..\vendor\boost\1_32_0\include\boost-1_32\boost\date_time\gregorian\parser s.hpp(78) : see reference to function template instantiation 'boost::date_time::period<point_rep,duration_rep> boost::date_time::from_simple_string_type<boost::gregorian::date,wchar_t>(const std::basic_string<_Elem,_Traits,_Ax> &)' being compiled with [ point_rep=boost::gregorian::date, duration_rep=boost::gregorian::date_duration, _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Ax=std::allocator<wchar_t> ]

2 1

IMPORTANT: yahoogroups admin rights problem
by Toon Knapen 23 Nov '04

23 Nov '04

Hello ALL, As many of you might know, currently we are unable to add new members to the ublas-ml. The problem is that only Joerg has the rights to add members to the list but Joerg does not respond anymore. Could some of you try to contact Joerg or give me his telephone number that I talk to him about this. If we do not have a solution by end of November I will create a new project on yahoogroups (and we all have to switch). Additionally we need to contact Joerg and Mathias (again!) about applying the Boost Software License. I currently have the impression that they are not willing to change ublas to the BSL. In that case IMO, we will have to rewrite uBLAS to not get thrown out of boost. Again his phone-number would be handy if you have it available. Please contact the ml or me asap about the above issues or we will need to take drastic actions. toon

1 0

Memory leak reported using threads library
by gast128 23 Nov '04

23 Nov '04

Dear all, Downloading and using the 1.32 version was probably not such a good idea... Now I get a mem-leak reported by the debug crt of VC 7.1. The report is located in 'init_threadmon_mutex' where a global object is allocated but never deleted. Before we start a discussion of what is a memory leak or not, in our production code we do not accept any leak reported by VC. The past has learned us that if you accept one leak, programmers/colleaques start to ignore them and in the end you have 200 leaks, instead of this one. I guess it wouldn't be difficult to resolve this one, on process exit it can be deallocated. And yes I am aware of the (phoenix) singleton discussions in Alexandrescu/Meyers, but really this kind of reinit of singletons after atexit calls won't happen too much. Wkr, me

3 4

boost 1.32 - uBlas - bug in symmetric_matrix::resize()
by Thomas Lemaire 23 Nov '04

23 Nov '04

When resizing a symmetric matrix with the preserve tag to "true", I got: before P: [6,6]((0,0,0,0,0,0),(0,0,0,0,0,0),(0,0,0,0,0,0),(0,0,0,0,0,0),(0,0,0,0,0,0),(0,0,0,0,0,0)) after P: [9,9]((5.54836e-321,-NaN,7.57149e-96,7.57149e-96,7.57149e-96,0,3.06321e-322,0,0),(-NaN,5.75348e+140,4.10451e-115,7.56598e-96,4.10451e-115,0,1.92686e-322,0,0),(7.57149e-96,4.10451e-115,7.57149e-96,7.57149e-96,7.57149e-96,3.31031e-311,6.57819e-313,0,0),(7.57149e-96,7.56598e-96,7.57149e-96,2.34163e-110,0,1.10492e-317,0,3.07265e-311,0),(7.57149e-96,4.10451e-115,7.57149e-96,0,0,5.00601e-308,0,1.10498e-317,0),(0,0,3.31031e-311,1.10492e-317,5.00601e-308,4.99745e-308,0,5.00601e-308,0),(3.06321e-322,1.92686e-322,6.57819e-313,0,0,0,0,4.99745e-308,0),(0,0,0,3.07265e-311,1.10498e-317,5.00601e-308,4.99745e-308,3.06321e-322,0),(0,0,0,0,0,0,0,0,0)) Notice the NaN and others strange things... I am using solaris 9 with gcc 3.3.3 -- thomas

1 0

difference between .output and .run files
by TC MA 23 Nov '04

23 Nov '04

After bjam is executed, both .output and .run files are executed. However, they are the same in content. Why not just use one file, why need both .output and .run files? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

dijkstra_shortest_paths performance problem
by Gustavo Sÿffffe1nchez 23 Nov '04

23 Nov '04

Hello, all We are doing a algorithm based on the graph boost library. Actually, it will be a Dinamic Link Library(dll). Our problem is when we execute it in console mode, it costs 12 seconds to finish, while it costs 120 seconds more or less when we are calling it as a DLL from Visual Basic. We have traced into the source code and found that is the dijkstra_shortest_paths function from the boost library which costs us 10 times more in the dll than the console mode. We call the dijkstra_shortest_paths like this: dijkstra_shortest_paths(g,s,predecessor_map(&p[0]).distance_map(&d[0]). visitor(make_dijkstra_visitor(_buscaVia(g,on_finish_vertex(),vinfo,edge_comp,via,p) ))); ///////below is the codes for visitor template <class Graph, class Tag> struct buscaVia : public boost::base_visitor<buscaVia<Graph, Tag> > { typedef Tag event_filter; buscaVia(typename property_map<Graph, vertex_info_t>::type & vinfo_, property_map<UGraph, edge_component_t>::type & ecomp,Vertex & _via,vector<Vertex> &p) :vinfo(vinfo_),encontrada(false),_ecomp(ecomp),via(_via),_p(p){} template <class Vertex, class Graph> void operator() (Vertex v, Graph& g){ bool hay_comp=false; Vertex a=v; if( vinfo[v].is_via && ! encontrada ){ while(_p[a]!=a){// mientras no hayamos llegado al origen if( _ecomp[edge(a,_p[a],g).first]->isComponentCaerTension() ){hay_comp=true; break;} else a=_p[a]; //pasamos al anterior } if(hay_comp==false){ // encontramos la via de la bobina DEBUG_CODE(cout << " via encontrada: " << vinfo[v].vertex_name << endl;) via = v; encontrada=true; } } DEBUG_CODE(else cout << "pasamos por vertice: " << vinfo[v].vertex_name << endl;) } private: typename property_map<Graph, vertex_info_t>::type & vinfo; property_map<UGraph, edge_component_t>::type & _ecomp; bool encontrada; Vertex & via; vector<Vertex> &_p; }; template<class Graph, class Tag> inline buscaVia<Graph,Tag> _buscaVia(Graph &g, Tag,typename property_map<Graph, vertex_info_t>::type & vinfo, property_map<UGraph, edge_component_t>::type & ecomp, Vertex & _via, vector<Vertex> &p){ return buscaVia<Graph,Tag>(vinfo,ecomp,_via,p); } ///////end of codes for visitor We appreciate your kind help! Yang ---------------------------------

2 1