- Boost - lists.boost.org

best way to serialize a GIL image
by Tom Brinkman 26 Mar '09

26 Mar '09

int width = 200; int height = 200; rgb8_image_t img(width,height); unsigned char* buffer = interleaved_view_get_raw_data(view(img)); FILE* fd = fopen(path,"wb"); fprintf(fd, "P6\n# CREATOR: unknown\n%d %d\n255\n",width,height); fwrite(buffer,1,width*height*3,fd); fclose(fd); GIL is just a wrapper around your buffer. No direct serialization support is provided nor needed.

4 4

[proto] switch_ with a policy
by troy d. straszheim 25 Mar '09

25 Mar '09

In some situations you're limited by the fact that proto::switch_ matches on tag type. For instance, if you have a bunch of these things: namespace tag { struct exp {}; struct log {}; // lots more, say 50 of them } Expression<terminal<tag::exp>::type> const exp = {{}}; Expression<terminal<tag::log>::type> const log = {{}}; // 50 more And you try to write a transform with switch_ that handles theses, you're stymied by the fact that switch_ will only tell you the tag of what has matched. Here's an attempt at the switch: struct UnaryFunctionCases { template <typename Tag, int i=0> struct case_ : not_<_> { }; template <int i> struct case_<VEY, i> : when<proto::function<...>, DoSomethingClever(...)> { }; }; struct UnaryFunctionSwitch : proto::switch_<UnaryFunctionCases> { }; the VEY above is going to be proto::tag::function for all of these terminals if you're trying to transform an expression like exp(7); (If I remember correctly... I havent looked at this code in a while). You can add a policy to the stock switch_ that makes this easy to handle (sorry if my mailer borks some newlines here): namespace boost { namespace proto { template<typename Cases, template <class> class Policy = boost::proto::tag_of> struct switch_ : proto::transform<switch_<Cases, Policy> > { typedef switch_<Cases, Policy> proto_base_expr; template<typename Expr, typename State, typename Data> struct impl : Cases::template case_< typename Policy<Expr>::type >::template impl<Expr, State, Data> { }; template<typename Expr, typename State, typename Data> struct impl<Expr &, State, Data> : Cases::template case_< typename Policy<Expr>::type >::template impl<Expr &, State, Data> { }; }; namespace detail { template<typename Expr, typename Cases, template <class> class Policy> struct matches_<Expr, switch_<Cases, Policy> > : matches_< Expr , typename Cases::template case_< typename Policy<Expr>::type >::proto_base_expr > { }; } } } Which I believe behaves identically to the stock switch_, and you can handle the example scenario like this: namespace detail { // metafunction extracts the thing we want to match on template <typename Expr> struct fncall2fntag { typedef typename Expr::proto_child0 child0; typedef typename proto::result_of::value<child0>::type value; typedef typename boost::remove_reference<value>::type noref; typedef typename boost::remove_const<noref>::type noconst; typedef noconst type; }; } struct UnaryFunctionCases { template <typename Tag, int _=0> struct case_ : proto::not_<proto::_> { }; template <int _> struct case_<tag::exp,_> : proto::when< proto::function<proto::terminal<tag::exp>, Array>, UnaryFunctionDispatch(tag::exp(), ...) > { }; // etc }; struct UnaryFunctionSwitch : proto::switch_<UnaryFunctionCases, detail::fncall2fntag> { }; Thoughts? -t

3 4

[fusion][map] default construction semantics
by Rutger ter Borg 25 Mar '09

25 Mar '09

Please see attached an example of constructing a fusion map, of which I would expect to give identical results. Or, does fusion deviate from the common expression for default construction in this case? Kind regards, Rutger ter Borg

2 2

"[gsoc] Thread scheduler support for boost"
by Indradip Ghosh 25 Mar '09

25 Mar '09

Hi Phil and Mathias, I completely appreciate the portability issues involved in making such an extension in which case it has to come with a portability clause and disclaimer which would become a deterrent in including such a facility in the library. However, I thought of your suggested extension of threadpool class exploiting processor affinity techniques and it sounds very interesting as well but I guess we would run into the same portability issues with regard to availability of the lower level API exposing the hooks to be able to develop such a facility. Another issue would be to qualify and justify how much improvement would this type of parallelism enable on top of the instruction level parallelism already in place for all modern processors. Although, I would still like to find out if you have any concrete lead in mind. I know for sure that there are those hard engineering problems in high performance computing domain to ensure QOS guarantees to distributed real-time embedded systems. They look into processor utilization optimizations in the face of uncertainty of computational load on the system. These usually require some kind of mathematical validation of the scheme for the system under construction. I guess that would be beyond the scope of the GSOC project, given the time frame. M:N type of models would also have the same portability issue as it requires changing kernel code as well as the userland code in thread library. Please let me know if you can think of a any non trivial portable addition that you can think of an I can work on it. In fact, I don't mind doing a big project even if it goes beyond the time frame of GSOC if we can see value in it. Please let me know. Thanks, Indradip. ____________________________________________________________________________ > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: boost(a)lists.boost.org > Message-ID: <gq97h5$dbk$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Indradip Ghosh wrote: > >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Are you suggesting a N:M threading model where you can specify the > userland scheduler? > > > Hi Indradip, I have previously looked at passing POSIX thread attributes (i.e. priority and policy) and it's not much work; presumably it could now be done using the native handle in the proposed std::thread and new version of boost::thread. How close to the POSIX semantics does Windows come? Boost generally prefers to implement portable stuff (although that's not something I need!) and choosing to work in an area where the different platforms have little common ground will make things more difficult for you, unless you're already familiar with how this stuff works on both POSIX and Windows systems. Beyond that there's the area of processor affinity, where as far as I know POSIX has nothing to say. Linux has some APIs for this but I doubt they have much in common with any other platforms. Maybe the Intel TBB library has already solved all of this? I'm wondering how something like a thread pool would be extended to exploit processor affinity, if the lower-level API offered it. Do you have a motivating application? Phil. On Tue, Mar 24, 2009 at 5:09 AM, <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ > > Today's Topics: > > 1. Re: Re quest interest in Bloom filters (Phil Endecott) > 2. [asio] basic_datagram_socket::send_to (Miroslav Berani? ml.) > 3. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 4. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Sebastian Redl) > 5. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 6. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Sebastian Redl) > 7. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Simonson, Lucanus J) > 8. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Schrader, Glenn) > 9. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Mathias Gaunard) > 10. [GSOC] 10 Day student application period begins today > (troy d. straszheim) > 11. Re: How to build 32 bits boost library on a 64 bits platform > (Qihong Wang) > 12. Re: "[gsoc] Thread scheduler support for boost" (Phil Endecott) > 13. [interprocess] locked mutex and process killed (vicente.botet) > 14. Re: "[gsoc] Thread scheduler support for boost" (Mathias Gaunard) > 15. has_operator_new (Robert Ramey) > 16. BOOST_NO_INTRINSIC_INT64_T (Robert Ramey) > 17. Re: Can a Boost library use a component like GMP and mfpr > that have a LGPL license ? (Barend Gehrels) > 18. Boost with ICU on AIX - Patch (solar(a)rootdirectory.de) > 19. Re: has_operator_new (John Maddock) > 20. Re: [interprocess] locked mutex and process killed (Edouard A.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Mar 2009 16:15:01 +0000 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] Re quest interest in Bloom filters > To: <boost(a)lists.boost.org> > Message-ID: <1237824901397(a)dmwebmail.dmwebmail.chezphil.org> > Content-Type: text/plain; format="flowed" > > Vicente Botet Escriba wrote: >> Phil Endecott-48 wrote: >>> >>> vicente.botet wrote: >>>> I need for my application bloom filters. Do you know of a good boostified >>>> generic implementation? >>>> Is there any interest in such a generic bloom filters library in Boost? >>> >>> Hi Vicente, >>> >>> I have a simple generic Bloom filter here: >>> >>> http://svn.chezphil.org/libpbe/trunk/include/bloom_filter.hh > >>> I seem to have lost the example code > > Now found and checked in here: > > http://svn.chezphil.org/libpbe/trunk/examples/spellcheck.cc > >> The hard part (the hash functions) is left out quite elegantly. I was >> thinking about defining some hash traits wich will allow the user to set the >> hash functions in a independent way. Something like >> >> template <template T, size_t N> struct hash_traits; >> >> template <> hash_traits<SpecificUserType,0> { >> static unsigned hash(T& value) { >> // specific code >> } >> } >> >> BTW, besides the tr1::hash function, are there other hash generic functions >> in Boost? > > You can use Boost.CRC. What sort of key do you have? I once did some > investigation of hash functions for strings for use with unordered > containers; I was considering using a degenerate hash that only looks > at the first N characters. > > Something I didn't mention before is that if you need, say, 10-bit hash > values then a 32-bit CRC could give you three of them. In this case > your hash_traits would presumably compute the same CRC three times and > extract different portions each time, which is not ideal. > >> I would need also the union and intersection functions. I'm wondering if >> replacing the tr1::array by a boost::dynamic_bitset should make eassier >> this. > > Well it's not exactly difficult with the array. I've never used > dynamic_bitset and being dynamic is not a requirement here. I was > concerned (as normal) about getting a fast implementation and the > simple bit manipulation in my code is probably about as fast as you can get. > > > Cheers, Phil. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Mar 2009 17:54:14 +0100 > From: Miroslav Berani? ml. <miroslav.beranic(a)mibesis.si> > Subject: [boost] [asio] basic_datagram_socket::send_to > To: boost(a)lists.boost.org > Message-ID: > <c62cccb70903230954g7020c4c0w30664ae62556b6f(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Greetings, > > will method basic_datagram_socket::send_to flush data immediately to > the endpoint or will first fill its internal buffer and than flush > data to endpoint? I would like to make sure, data gets flushed to > endpoint when this method is called. > > Is there any other way to flush data to endpoint? > Does any socket::set_option(option); makes difference to behaviour of > send_to method ? > Why isn't it possible to set buffer size lower than 1024 (low-level > restriction?), with method (basic_datagram_socket::send_buffer_size()) > > > There is no documentation about this. > > > Best regards, > ----- > Miroslav Berani? ml. > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Mar 2009 09:58:20 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B25DDF48C(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >>>> >>>> AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is >>>> no problem in using them in commercial products, even closed source >>>> applications (provided a copy of the license is distributed with >>>> said product), so I don't think there should be any restriction on >>>> allowing Boost libs to depend on LPGL libs. >>> >>> The LGPL requires you to construct your code in such a way that you >>> can relink with a new library. It also requires you to allow users >>> to reverse engineer the code for debugging. Commercial users of >>> Boost may not like those terms. >> >> My company, for example, would be interested in the BGL, but quite >> unable >> to include an LGPL library, since our copy protection mechanism kills >> the application if it detects a debugger. This would be a license >> violation. (We probably wouldn't need bignum functionality. As long >> as the BGL can be used without the bignum libraries, we'd probably be >> happy.) >> > > Huh, they basically exclude copy protection in the terms of their license? I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake? > > Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. That can be performed with 64 bit unsigned integer if you keep track of the sign seperately. The only other places where I need high precision are the computation of the sweep-line intercept for comparing the y coordinates of segments that intersect the sweep-line and the actual computation of intersection points. Instead of using mp rational I could provide robust calculations "by hand" if I implement enough of what is in a multi-precision rational to get by or come up with some tricks. Long double only barely fails in my pseudo-exhasutive testing of line intersection computation. Since its result is only off by a small margin I could potentially detect these errors and handle them specially. The impor > tant aspect of the intersection computation is that when it snaps to the the integer grid both line segments must intersect that integer grid box. This check can be performed with point on-above-or-below line segment based degree-2 predicates (on-above-or-below can be implemented with slope comparison) that don't need multi-precision or rationals and then I can search adjacent grid boxes for one that meets the criteria for correctness if the check fails for the one computed by floating point approximation. Happily I have the ability to validate such fancy (read error-prone) code against the known correct big-num reliant implementation I already have. > > Luke > > ------------------------------ > > Message: 4 > Date: Mon, 23 Mar 2009 19:01:29 +0100 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C7CE79.10607(a)getdesigned.at> > Content-Type: text/plain; charset=ISO-8859-1 > > Simonson, Lucanus J wrote: >> Sebastian Redl wrote: >> >>> My company, for example, would be interested in the BGL, but quite >>> unable >>> to include an LGPL library, since our copy protection mechanism kills >>> the application if it detects a debugger. This would be a license >>> violation. (We probably wouldn't need bignum functionality. As long >>> as the BGL can be used without the bignum libraries, we'd probably be >>> happy.) >>> >>> >> >> Huh, they basically exclude copy protection in the terms of their license? > They require that it is still possible to debug the LGPLed library in > the context of the combined work. If there's a debugger killer as part > of the copy protection (and every effective CP needs one), that's > obviously not possible. >> I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake? >> > Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry > libraries called that? >> Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. > I'm fairly certain that I don't need that. So it's a question of how > modular the library is. > > Sebastian > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Mar 2009 11:16:01 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B262115D3(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >> Simonson, Lucanus J wrote: >>> Sebastian Redl wrote: >>> >>>> My company, for example, would be interested in the BGL, but quite >>>> unable to include an LGPL library, since our copy protection >>>> mechanism kills the application if it detects a debugger. This >>>> would be a license violation. (We probably wouldn't need bignum >>>> functionality. As long as the BGL can be used without the bignum >>>> libraries, we'd probably be happy.) >>>> >>>> >>> >>> Huh, they basically exclude copy protection in the terms of their >>> license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. >>> I didn't trust the LGPL when I read it because it was obviously >>> written by a lawyer. Did you mean GTL and type BGL by mistake? >>> >> Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry >> libraries called that? > > I think it's called ggl, generic geometry library. Boost geometry library would be confusing. > >>> Ideally I'd like to eliminate dependence on big-num for robustness, >>> for performance reasons if not license concerns, but this requires >>> some fancy programming. For instance, the degree-2 predicate of >>> slope comparison requires 65 bits when the input is 32 bit >>> coordinates. >> I'm fairly certain that I don't need that. So it's a question of how >> modular the library is. >> > Well, I have no explicit dependency on big num, just provide the ability to override non-robust arithmetic by specifying a big num data type. I have no direct code dependency on any external library, only the stl. > > What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information. > > Thanks, > Luke > > ------------------------------ > > Message: 6 > Date: Mon, 23 Mar 2009 19:23:06 +0100 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C7D38A.8080506(a)getdesigned.at> > Content-Type: text/plain; charset=ISO-8859-1 > > Simonson, Lucanus J wrote: >> What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information. >> > It's pretty vague at this time. We've been doing without, and looking at > it to optimize some algorithms that currently work on rasters. We're > mostly looking for quickly doing many, many polygon intersections in a > huge floating point coordinate system. (Transformed to integer rasters > at a given resolution.) The whole thing is about geographic data. > > Sebastian > > > ------------------------------ > > Message: 7 > Date: Mon, 23 Mar 2009 11:30:38 -0700 > From: "Simonson, Lucanus J" <lucanus.j.simonson(a)intel.com> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <26E9B811E137AB4B95200FD4C950886B262115F7(a)orsmsx507.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Sebastian Redl wrote: >> It's pretty vague at this time. We've been doing without, and looking >> at >> it to optimize some algorithms that currently work on rasters. We're >> mostly looking for quickly doing many, many polygon intersections in a >> huge floating point coordinate system. (Transformed to integer rasters >> at a given resolution.) The whole thing is about geographic data. >> > Do you need map overlay, or is polygon intersection enough? I have both, but most other libraries only provide intersection. > > Luke > > ------------------------------ > > Message: 8 > Date: Mon, 23 Mar 2009 14:38:15 -0400 > From: "Schrader, Glenn" <gschrad(a)ll.mit.edu> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Message-ID: > <57F5948627B03042A29E70F4AABB446A9311073C9D(a)LLE2K7-BE01.mitll.ad.local> > > Content-Type: text/plain; charset="us-ascii" > > > >> -----Original Message----- >> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] >> On Behalf Of Sebastian Redl >> Sent: Monday, March 23, 2009 2:01 PM >> To: boost(a)lists.boost.org >> Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr >> that have a LGPL license ? > >> > >> > Huh, they basically exclude copy protection in the terms of their >> license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. > > I assume you are referring to the "Combined Works" section of the LPGL. This is the only paragraph I can find containing the string "debug". > > * > * 4. Combined Works. > * You may convey a Combined Work under terms of your choice that, > * taken together, effectively do not restrict modification of the > * portions of the Library contained in the Combined Work and > * reverse engineering for debugging such modifications, if you > * also do each of the following: > * > > The term "Library" means "the library that is licensed under the LGPL". Note that the wording says >debugging< and NOT a >debugger<. Debugging can be carried out in different ways. For instance, the library can be instrumented using printf/cout. While the ability to run a debugger is certainly convenient, I fail to see how this mandates it. Some may object to the reverse engineering clause but its only an issue if reverse engineering is actually needed. If you say up front how you use the library then there should be no need to reverse engineer anything. > >> >> Sebastian >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > Message: 9 > Date: Mon, 23 Mar 2009 19:51:31 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <gq8lnj$ii0$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Sebastian Redl wrpte: > >>> Huh, they basically exclude copy protection in the terms of their license? >> They require that it is still possible to debug the LGPLed library in >> the context of the combined work. If there's a debugger killer as part >> of the copy protection (and every effective CP needs one), that's >> obviously not possible. > > In the case of DRM, the law in some countries requires to provide > information for interoperability on demand anyway, so what the LGPL > requires is actually required for any software in those countries. > > > > ------------------------------ > > Message: 10 > Date: Mon, 23 Mar 2009 15:48:17 -0400 > From: "troy d. straszheim" <troy(a)resophonic.com> > Subject: [boost] [GSOC] 10 Day student application period begins today > To: boost(a)lists.boost.org > Message-ID: <49C7E781.1070600(a)resophonic.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > The window is open another week and a half or so. Deadline: April 3. > > Our first student proposal (py3k support for boost python) arrived > within moments of the start of the application period. > > Don't be shy, keep discussing your ideas, and make some proposals. You > can't get accepted if you don't apply. > > -t > > > > ------------------------------ > > Message: 11 > Date: Mon, 23 Mar 2009 16:48:04 -0400 > From: Qihong Wang <qihongwang(a)gmail.com> > Subject: Re: [boost] How to build 32 bits boost library on a 64 bits > platform > To: boost(a)lists.boost.org > Message-ID: > <cf7fc54c0903231348n7bb3b585k8ac4a71aabbb84d0(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > It works for me. If I just specify address-mode, the library is still 64 > bits. I have to specify both. Before I tried this, I also tried to specify > gcc version and compileFlag and linkFlag as -m32 according to document. That > doesn't work either. > > Thanks Fr?d?ric and Alexander. > > On Mon, Mar 23, 2009 at 4:16 AM, Alexander Arhipenko <arhipjan(a)gmail.com>wrote: > >> On Sat, Mar 21, 2009 at 10:58 PM, Qihong Wang <qihongwang(a)gmail.com> >> wrote: >> > Hello, >> > >> > My platform is a 64 bits Linux with gcc. My program needs to link a 32 >> bits >> > library without source code and other >> > libraries with source code. I wrote a script to build those libraries >> with >> > source code by >> > >> > ./configure --prefix=$install_prefix CFLAGS="-g -O2 -Wall -m32" >> > CPPFLAGS=-m32 CXXFLAGS="-g -O2 -m32" >> > make install >> > >> > Then start to build my executable through Makefile with -m32 flag either. >> > The configure and make install work for other libraries but not work for >> > boost. The boost libraries were compiled and >> > installed but still 64 bits. Linker refused to link it. Is there any >> simple >> > approach to build 32 bits boost on 64 bits Linux? >> > >> > Thanks, >> > >> > Qihong >> > >> >> Passing 'address-model=32 architecture=x86' arguments to bjam works fine >> for me. >> >> Regards >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > ------------------------------ > > Message: 12 > Date: Mon, 23 Mar 2009 21:05:06 +0000 > From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: <boost(a)lists.boost.org> > Message-ID: <1237842306073(a)dmwebmail.dmwebmail.chezphil.org> > Content-Type: text/plain; format="flowed" > > Indradip Ghosh wrote: >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Hi Indradip, > > I have previously looked at passing POSIX thread attributes (i.e. > priority and policy) and it's not much work; presumably it could now be > done using the native handle in the proposed std::thread and new > version of boost::thread. How close to the POSIX semantics does > Windows come? Boost generally prefers to implement portable stuff > (although that's not something I need!) and choosing to work in an area > where the different platforms have little common ground will make > things more difficult for you, unless you're already familiar with how > this stuff works on both POSIX and Windows systems. > > Beyond that there's the area of processor affinity, where as far as I > know POSIX has nothing to say. Linux has some APIs for this but I > doubt they have much in common with any other platforms. Maybe the > Intel TBB library has already solved all of this? > > I'm wondering how something like a thread pool would be extended to > exploit processor affinity, if the lower-level API offered it. > > Do you have a motivating application? > > > Phil. > > > > > > ------------------------------ > > Message: 13 > Date: Mon, 23 Mar 2009 23:57:19 +0100 > From: "vicente.botet" <vicente.botet(a)wanadoo.fr> > Subject: [boost] [interprocess] locked mutex and process killed > To: <boost(a)lists.boost.org> > Message-ID: <D12CA6DE6C6E4902B1170C7ED7F2AD8D@viboes1> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > what happens when a process owning interprocess::mutex is killed? is the mutex unlocked before the process dies? > > Thanks, > Vicente > > ------------------------------ > > Message: 14 > Date: Tue, 24 Mar 2009 00:55:18 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: boost(a)lists.boost.org > Message-ID: <gq97h5$dbk$1(a)ger.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Indradip Ghosh wrote: > >> I would like to get suggestions on developing a thread scheduler API for >> supporting users having specific needs in prioritizing threads >> running on SMP / Multi-Core processors. Please let me know the >> viability of including such an API in generic boost distribution and >> whether anyone would volunteer to mentor this effort as a GSOC >> project. > > Are you suggesting a N:M threading model where you can specify the > userland scheduler? > > > > ------------------------------ > > Message: 15 > Date: Mon, 23 Mar 2009 21:22:06 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] has_operator_new > To: boost(a)lists.boost.org > Message-ID: <gq9n29$dr4$1(a)ger.gmane.org> > > I've made a TRAK item to request a new type traits feature - > has_operator_new. I've included an implementation and a test - both > type_traitsified. Hope you can see fit to check it out, and if it's OK, > check it in. Let me know when you do this. Once this is in, I can clear a > dependent feature request TRAK item from the serialization library. > > Robert Ramey > > > > > > ------------------------------ > > Message: 16 > Date: Mon, 23 Mar 2009 21:38:54 -0800 > From: "Robert Ramey" <ramey(a)rrsd.com> > Subject: [boost] BOOST_NO_INTRINSIC_INT64_T > To: boost(a)lists.boost.org > Message-ID: <gq9o1p$fkm$1(a)ger.gmane.org> > > boost config includes BOOST_NO_INTRINSIC_WCHAR_T. > > boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T > appear in the near future? > > Robert Ramey > > > > > > ------------------------------ > > Message: 17 > Date: Tue, 24 Mar 2009 10:18:25 +0100 > From: Barend Gehrels <barend(a)geodan.nl> > Subject: Re: [boost] Can a Boost library use a component like GMP and > mfpr that have a LGPL license ? > To: boost(a)lists.boost.org > Message-ID: <49C8A561.7010709(a)geodan.nl> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > Fernando Cacciola wrote: >> >> A different and much less ambitious goal could be to come up with a >> good C++ *interface* to *those* libraries. That is, C++ number types >> specifically designed to be implementable on top of a C API like that >> of GMP and MPFR. > This is the approach we planned to take. In our geometry library (GGL) > we want to optionally calculate with large number types as GMP or CLN. > The GGL (or other geometry libraries who might take the same approach) > is completely independant from GMP and from their license. It can just > work together. > > We will work this out in the upcoming preview of GGL. We realize that it > is not applicable for geometry alone, so we make it independant from it > and might submit it as a separate, small, header-only library. The > sample (link below) shows a numeric_adaptor, having a policy of either > gmp, or just ieee types, or other big number types as cln (not worked > out). Other policies might elaborate adaptive precision. > > See > http://geometrylibrary.geodan.nl/num/numeric_adaptor.html > > Details might change of course, such as the place of the member variable > in either adaptor or policy, but the sample will give the general idea. > > Regards, > Barend Gehrels, Amsterdam > Bruno Lalande, Paris > > > > > > > ------------------------------ > > Message: 18 > Date: Tue, 24 Mar 2009 09:08:19 +0100 (CET) > From: solar(a)rootdirectory.de > Subject: [boost] Boost with ICU on AIX - Patch > To: boost(a)lists.boost.org > Message-ID: <20090324080819.1361134C4B8(a)mail.lcube.de> > Content-Type: text/plain; charset="ISO-8859-1" > > Hi there, > > while trying to get Boost 1.34.1 to work on an AIX machine, I > found a bug that still persists in 1.38.0. You might want to fix > this... > > In boost/regex/icu.hpp: > > 314c314 > < typedef std::vector<UCHAR32> vector_type; > --- >> typedef std::vector<UChar32> vector_type; > 318,319c318,319 > < v.push_back((UCHAR32)(*i)); > < ++a; > --- >> v.push_back((UChar32)(*i)); >> ++i; > > It should be obvious once you look at the source environment - > the UCHAR32 is probably a typo, and the ++a is copy-and-paste > work. This has obviously never been test-compiled on a real > machine. Surprising that this has not been caught earlier (since > it's been in there since 1.33)... > > Anyway, with that patch (and a backport of another one on > vacpp.jam that's been included in later versions of Boost), v1.34.1 > compiles cleanly with ICU-support on AIX. > > Regards, > > Martin Baute > > > > > > ------------------------------ > > Message: 19 > Date: Tue, 24 Mar 2009 09:52:36 -0000 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: Re: [boost] has_operator_new > To: <boost(a)lists.boost.org> > Message-ID: <0993906E24C64887BD216A8DA04492EC@acerlaptop> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > >> I've made a TRAK item to request a new type traits feature - >> has_operator_new. I've included an implementation and a test - both >> type_traitsified. Hope you can see fit to check it out, and if it's OK, >> check it in. Let me know when you do this. Once this is in, I can clear >> a dependent feature request TRAK item from the serialization library. > > I'll look into it: did you test out the is_virtual_base in SVN type_traits > Trunk BTW? > > John. > > > > ------------------------------ > > Message: 20 > Date: Tue, 24 Mar 2009 11:08:59 +0100 > From: "Edouard A." <edouard(a)fausse.info> > Subject: Re: [boost] [interprocess] locked mutex and process killed > To: boost(a)lists.boost.org > Message-ID: <04ab3291f101326aab20f6b7c4b7253b(a)127.0.0.1> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 23 Mar 2009 23:57:19 +0100, "vicente.botet" > <vicente.botet(a)wanadoo.fr> wrote: >> Hi, >> >> what happens when a process owning interprocess::mutex is killed? is the >> mutex unlocked before the process dies? > > After a quick look at the source code: > > inline void interprocess_mutex::lock() > { > if (pthread_mutex_lock(&m_mut) != 0) > throw lock_exception(); > } > > The answer to your question is "an exception will be thrown" since the call > will return "EOWNERDEAD". > > Generally speaking when a thread terminates while holding a mutex, the > mutex is considered abandoned and shared resources protected by the mutex > are in an undetermined state. Hope you like quantum physics. ;) > > -- > > EA > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 2497, Issue 1 > ************************************** >

2 1

[graph] how to enable GraphML support on Cygwin
by Peter 25 Mar '09

25 Mar '09

Hi When compiling boost 1.38, I get the warning: Graph library does not contain optional GraphML reader I know that I can ignore that warning, but I would like to use the GraphML reader. What do I have to do to install and use it ? Thanks for your help Peter

1 0

[interprocess] locked mutex and process killed
by vicente.botet 25 Mar '09

25 Mar '09

Hi, what happens when a process owning interprocess::mutex is killed? is the mutex unlocked before the process dies? Thanks, Vicente

6 13

A problem of Regex with ICU support
by Qihong Wang 25 Mar '09

25 Mar '09

Hi, I build my regex with icu support on Linux machine as follows ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install The warning message from bjam shows icu is enabled. I checked regex libraies were built. They are dependend on icu library. So I believed HAVE_ICU took effect. But look at the regex head files created, #define BOOST_HAS_ICU is comment. Sounds like icu is not enabled in head files. I compiled icu_example from boost.regex source code mannually, with the BOOST_HAS_ICU enable. g++ -L/home/qhwang/mylibs/boost/lib/ -L/home/qhwang/mylibs/icu/lib/ -I/home/qhwang/mylibs/boost/include/boost-1_38 -I/home/qhwang/mylibs/icu/include -DBOOST_HAS_ICU -lboost_regex-gcc41-mt -licudata -licuuc -licui18n -o icu_example icu_example.cpp The compiler reported error when compile UnicodeString text = L"Some where in \x0391\x039D\x0395\x0398\x0391 2004"; and assert(greek == L"\x0391\x039D\x0395\x0398\x0391 2004"); The error messages are: In function âint main()â: icu_example.cpp:155: error: conversion from âconst wchar_t [25]â to âicu_4_0::UnicodeStringâ is ambiguous /home/qhwang/mylibs/icu/include/unicode/unistr.h:2695: note: candidates are: icu_4_0::UnicodeString::UnicodeString(UChar32) <near match> /home/qhwang/mylibs/icu/include/unicode/unistr.h:2688: note: icu_4_0::UnicodeString::UnicodeString(UChar) <near match> icu_example.cpp:157: error: conversion from âconst wchar_t [11]â to âconst icu_4_0::UnicodeStringâ is ambiguous I don't know how to pass the compiliation. Any idea? Thanks, Qihong

2 1

Stop on first error
by Vladimir Prus 25 Mar '09

25 Mar '09

Presently, when building Boost, the build process does not stop if an error has occurred. This is behaviour we inherited, and it differs from every other build system out there. We had quite a number of users confused where build ends with "failed N targets", with the original error scrolled away -- it is not apparent what has caused the error, and often, the error is not even available from console program history. While experienced users might prefer being able to kick a build, go to lunch, and then fix a couple of failures in the middle of the build, ordinary users don't like it so much. So, how about we do what the rest of the world does, and stop build of C++ Boost on the first error? Comments? - Volodya

14 15

BoostCon 2009 Schedule Now Live
by David Abrahams 24 Mar '09

24 Mar '09

The official schedule is now live at http://www.boostcon.com/program! A few highlights of the "mouth-watering content" (in the words of one enrollee) are: * A keynote address from Andrei Alexandrescu called "Iterators Must Go." It's sure to be provocative! * Troy Straszheim's presentations on how high-energy physicists are using Boost to process massive datasets as they go "Icefishing for Neutrinos" and on Kamasu, his library for offloading computation to your machine's GPU. * Two hands-on sessions where we'll start recoding parts of Boost for C++0x, applying rvalue references, variadic templates, decltype, and advanced SFINAE capabilities using the latest GCC. * "Practical C++ Test-Driven Development with Boost.Test and Bmock," by Asher Sterkin * A session on compiler construction using Boost.Spirit v2, from Hartmut Kaiser and Joel de Guzman The complete list of sessions covers a wide range of other Boost and C++-related topics. It is available at http://www.boostcon.com/program/sessions. Please have a look, and please, sign up for the conference! Remember, registration for the whole week is just $599 before April 1st. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[tr1] shared_count failing on several release branch tests
by Beman Dawes 24 Mar '09

24 Mar '09

shared_count is also failing more-or-less across the board on the trunk tests. Could someone (John M?) please take a look at this test? Thanks, --Beman

2 1