headers
Gennadiy Rozental | 1 Sep 04:47
Picon

Re: windows timeout implementation

vicente.botet <vicente.botet <at> wanadoo.fr> writes:

> 
> Hi,
> 
> ----- Original Message ----- 
> From: "Gennadiy Rozental" <rogeeff <at> gmail.com>
> To: <boost <at> lists.boost.org>
> Sent: Monday, August 31, 2009 9:13 AM
> Subject: [boost] windows timeout implementation
> 
> > 
> > Hi,
> > 
> > I have windows timeout support implemented for boost::execution monitor. 
> 
> What do you mean by windows timeout support?

At the moment function execution timeout only available where SIGALRM is. I am
looking to extend support for this feature.

Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Haoyu Bai | 1 Sep 06:19
Picon

[GSoC] Boost.Python py3k support project final report

Hi,

As GSoC is officially finished, this is the final report of the
Boost.Python py3k(Python 3) support project. The goal of this project
is to provide seamless support for Python 2 and 3 in Boost.Python. So
extension modules using Boost.Python can be easily migrated to Python
3.

The SVN branch is located at:
https://svn.boost.org/svn/boost/sandbox-branches/bhy/py3k/

Status
=====

Currently, all the BPL test cases passed when running under Python 3,
and there are almost no change for most of the test cases. To support
the Python 3 unicode string, some of the default converts between
PyString and C/C++ strings are changed to convert between PyUnicode
and C/C++ strings. Support for py3k in Boost.Build is done. Also, a
piece of document is written in the "News" part of BPL document.

API Changes
==========

There are some minor API changes:

1) Introduced object.contains where x.contains(y)  is equivalent to
Python code y in x. Now dict.has_key is just a wrapper of
object.contains.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vladimir Prus | 1 Sep 07:12

Re: [GSoC] Boost.Python py3k support project final report

Haoyu Bai wrote:

> Hi,
> 
> As GSoC is officially finished, this is the final report of the
> Boost.Python py3k(Python 3) support project. The goal of this project
> is to provide seamless support for Python 2 and 3 in Boost.Python. So
> extension modules using Boost.Python can be easily migrated to Python
> 3.

...

> Currently, all the BPL test cases passed when running under Python 3,
> and there are almost no change for most of the test cases.

...

> I'm going to merge the py3k branch back to trunk. After the merge,
> more tests can be done to check is there any regression, also some
> people may want to start to use it to make your projects run on Python
> 3. Then I can get some bug report and feedback, thus more improvement
> is expected.

Haoyu,

not being involved in this, I naturally cannot comment on details, but from
a distance this looks like very good project. You have taken on a clearly
delineated task and then completed it to the degree of trunk-ready. This
is a very concrete improvement, and I'm sure many Boost users will benefit
from it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
jon_zhou | 1 Sep 08:17
Favicon

[interprocess]message_queue is a block & sync ?

Hi there,
Does message_queue run in block and sync mode?

i.e. will the MQ->recv() be blocked if the receiving buffer is empty?

Regards,
rui

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Jeffrey Hellrung | 1 Sep 08:50
Favicon

Re: Formal Review: Boost.Polygon starts today August 24, 2009

Barend Gehrels wrote:
>> The formal review of the Boost.Polygon library by Lucanus Simonson 
>> starts today, August 24, 2009 and will finish September 2, 2009.
...
> Expectations: I think a templated Boost.Polygon library should at least:
> 1) support most of the basic polygon geometry algorithms
> 2) have a performance comparable to other libraries
> 3) support both integer and floating point coordinate types
...
> 3) Boost.Polygon supports integer but does not support double for 
> boolean operations.

+1; I'm generally sympathetic to Barend's concerns, especially the 
(apparent?) lack of direct floating point support.  A generic geometry 
or polygon library could be a component in some fracture simulation 
research software I plan to eventually write, but imprecision associated 
with converting to integer types, and hence the associated inexact 
constructions of intersection points, makes the proposed Boost.Polygon 
unuseable for that purpose, in my opinion.

I would like to see at least a framework to be able to support floating 
point types and exact constructions.  CGAL does this, I believe.  I'm 
not familiar with their framework.

Or a change in the library from Polygon to IntegerPolygon or something 
to indicate it's intended scope, with "Polygon" reserved for a more 
general library encompassing floating point types and a broader class of 
operations.

I'm now interested in comparing the proposed Boost.Polygon with Berand's
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ion Gaztañaga | 1 Sep 09:32
Picon

Re: [interprocess]message_queue is a block & sync ?

jon_zhou <at> agilent.com escribió:
> Hi there,
> Does message_queue run in block and sync mode?
> 
> i.e. will the MQ->recv() be blocked if the receiving buffer is empty?
> 

Yes, but you have try and timed functions.

Ion
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
klaus triendl | 1 Sep 10:12
Picon

compile-time for-loop

I wonder whether a compile-time for-loop is useful enough so that it would
get included in the mpl library;
it's very similar to what fold does but it can be used for computations with
types other than sequence
containers.

The loop construct takes a start value, a loop condition and a
function calculating the next start value for the next loop recursion and
additionally a state together with a binary operation serving as loop
body:

namespace boost { namespace mpl {

template<
      typename Start, typename UnaryLoopTest, typename BinaryNext
    , typename State, typename BinaryOp
>
struct for_:
    eval_if<
        // loop as long as the loop condition yields true
        typename apply<
            UnaryLoopTest,
            typename Start::type
        >::type,
        // next loop iteration: recursive call
        for_<
            // calculate next loop value
            typename apply<
                BinaryNext,
                State,
(Continue reading)

Permalink | Reply | 602 comments |
headers
joel | 1 Sep 10:25
Picon
Gravatar

Re: compile-time for-loop

klaus triendl wrote:
> I wonder whether a compile-time for-loop is useful enough so that it would
> get included in the mpl library;
> it's very similar to what fold does but it can be used for computations with
> types other than sequence containers.
>   
Well, fold is far more generic than for. I can't see, in a 
meta-programming context where side-effects don't occur, when having for_
is needed when we have fold_.

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Frédéric Bron | 1 Sep 11:30
Gravatar

Re: [type_traits] adding is_less_comparable<T>, etc.

> I think is_greater_than can be less restrictive than it is.  std::greater() provides an operator that
permits comparing unrelated types as T's.  Therefore, I wonder if this would work:
>
>   template <class T, class U = T>
>   struct is_greater_comparable;
>
> Then, is_greater_comparable<int, float> would inherit from true_type.

I have tried to do that but cannot understand why it does not work.
Can you try this example and tell me why it does not give false each
time?

Frédéric

#include <iostream>
#include <boost/type_traits/remove_cv.hpp>
#include <boost/type_traits/integral_constant.hpp>

namespace boost {
namespace detail {

// This namespace ensures that ADL doesn't mess things up.
namespace is_less_comparable_impl {

// a type returned from comparison operator when no such operator is
found in the
// type's own namespace
struct tag { } ;

// any soaks up implicit conversions and makes the following
(Continue reading)

Permalink | Reply | 1 comment |
headers
Larry Evans | 1 Sep 12:00

Re: compile-time for-loop

On 09/01/09 03:12, klaus triendl wrote:
> I wonder whether a compile-time for-loop is useful enough so that it would
> get included in the mpl library;
> it's very similar to what fold does but it can be used for computations with
> types other than sequence
> containers.
> 
> 
> The loop construct takes a start value, a loop condition and a
> function calculating the next start value for the next loop recursion and
> additionally a state together with a binary operation serving as loop
> body:
[snip]
This sounds like while_recur found here:

  https://svn.boost.org/trac/boost/attachment/ticket/3044/while_recur.cpp

This was part of a proposed patch to mpl's  iter_fold_if to solve
a problem another booster had:

http://article.gmane.org/gmane.comp.lib.boost.devel/190874/match=or_seq

However, for some reason (people too busy or maybe there's some
bug someone's seen in while_recur), the topic's cooled off since
there's no posts since 6/10/2009 :(

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 602 comments |

Gmane