headers
OvermindDL1 | 1 Dec 2009 02:02
Picon

Re: Numpy ndarray as argument or return value using boost python

On Mon, Nov 30, 2009 at 1:34 PM, Nyiro Gergo <gergo.nyiro <at> gmail.com> wrote:
> - Hide quoted text -
> - Show quoted text -
> <http://groups.google.com/group/boost-list/browse_thread/thread/b491f5eb8cc836c5?hide_quotes=no#msg_a69011d99e445aef>
>
> On Mon, Oct 12, 2009 at 7:09 AM, Pim Schellart <p.schell...
> <http://groups.google.com/groups/unlock?_done=/group/boost-list/browse_thread/thread/b491f5eb8cc836c5&msg=a69011d99e445aef> <at> gmail.com>
> wrote:
>>> Hi Everyone,
>
>>> I tried to find a good example for this but after spending two days on
>>> google and one day getting pyublas to compile I decided to call for
>>> help.
>>> I want to give a numpy ndarray as an argument to a c++ method,
>>> calculate something and return the output as an ndarray to Python.
>>> I would prefer not to use another library (such as PyUblas) for this
>>> so I do not have to add another dependency to my program.
>>> Since the latest information on boost python is quite outdated (uses
>>> numeric) I would like to know the following.
>
>>> 1. Is boost python still maintained or should I switch to another tool.
>>> 2. Is numpy supported, and if so,
>>> 3. can someone give me a basic example of how to use it.
>
>> 1. Yes, Boost.Python is still maintained and works find.
>> 2. Yes, Boost.Python supports any and all libraries that communicate
>> through python, you would just use the ndarray just like any other
>> Python Object.
>> 3. Give an example of how you use it in Python and we can give you an
>> example of how you would do it from the C++ side, it is a pretty
(Continue reading)

Permalink | Reply | 0 comments |
headers
dutchman1 | 1 Dec 2009 01:58
Picon

How to get rid of compiler version in library names?


Hi,

I just installed Boost and noticed the library names all have the
compiler/boost version in the file name, e.g. gcc41. 
libboost_date_time-gcc41-mt-1_39.a                   

The program I'm trying to compiler only looks for the library name, e.g.
libboost_date_time-mt.a. 
My error:
error: Unable to find file or target named
error:     '/usr/lib/libboost_date_time-mt.a'
error: referred from project at
error:     '.'

How can I make boost install using the library names without compiler
name/boost version?

Thanks!

--

-- 
View this message in context: http://old.nabble.com/How-to-get-rid-of-compiler-version-in-library-names--tp26503467p26503467.html
Sent from the Boost - Users mailing list archive at Nabble.com.
Permalink | Reply | 2 comments |
headers
Steven Watanabe | 1 Dec 2009 04:26
Picon

Re: How to get rid of compiler version in library names?

AMDG

dutchman1 wrote:
> I just installed Boost and noticed the library names all have the
> compiler/boost version in the file name, e.g. gcc41. 
> libboost_date_time-gcc41-mt-1_39.a                   
>
> The program I'm trying to compiler only looks for the library name, e.g.
> libboost_date_time-mt.a. 
> My error:
> error: Unable to find file or target named
> error:     '/usr/lib/libboost_date_time-mt.a'
> error: referred from project at
> error:     '.'
>
> How can I make boost install using the library names without compiler
> name/boost version?
>   

Compile Boost with --layout=tagged.

In Christ,
Steven Watanabe
Permalink | Reply | 1 comment |
headers
Vladimir Prus | 1 Dec 2009 07:28

Re: How to get rid of compiler version in library names?

Steven Watanabe wrote:

> AMDG
> 
> dutchman1 wrote:
>> I just installed Boost and noticed the library names all have the
>> compiler/boost version in the file name, e.g. gcc41.
>> libboost_date_time-gcc41-mt-1_39.a
>>
>> The program I'm trying to compiler only looks for the library name, e.g.
>> libboost_date_time-mt.a.
>> My error:
>> error: Unable to find file or target named
>> error:     '/usr/lib/libboost_date_time-mt.a'
>> error: referred from project at
>> error:     '.'
>>
>> How can I make boost install using the library names without compiler
>> name/boost version?
>>   
> 
> Compile Boost with --layout=tagged.

And use Boost 1.41, I think. This option is not available in 1.39

- Volodya
Permalink | Reply | 0 comments |
headers
Roland Bock | 1 Dec 2009 09:29
Picon

Re: thread_group::interrupt_all is not reliable

Stonewall Ballard wrote:
> I think I found the cause of this problem. It seems that the caller of interrupt_all should be holding the
mutex associated with the condition on which the threads are waiting.
> 
> This gave me the clue to try that:
> <http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_broadcast.html>
>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or
not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait()
have associated with the condition variable during their waits; however, if predictable scheduling
behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal().
> 
> thread::interrupt() calls pthread_cond_broadcast in pthread/thread.cpp.
> 
> Although "predictable scheduling" doesn't seem like it should include a failure to wake up, taking the
mutex around the call to thread_pool::interrupt_all() appears to be 100% reliable.
> 
> I can patch my app to do that, but I don't think there's a general solution. The documentation should
include a note that thread::interrupt() isn't reliable unless the caller is holding the mutex
associated with the condition variable on which the interrupted thread is waiting.
> 
> Of course, this could be a bug in the OS X pthreads implementation as well.

Hi,

FWIW, I ran that test of yours several times with varying parameters on 
my machine (quad core, 64bit, linux) and it did not show a single 
failure. Of course, since it is not a deterministic effect even on your 
machine, failure to reproduce does not really mean much, but well, I 
thought you might like to hear anyway :-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
gast128 | 1 Dec 2009 11:56
Picon
Favicon

Re: serialization library leaks memory in its globalobject

Robert Ramey <ramey <at> rrsd.com> writes:

> Note that this weekend I addressed one report of a memory leak
> which was detected upon application exit.  It's checked into the
> trunk.  You might want to check to see if that addresses the
> problem.

Thx, but could u be more specific? From the Trunk I see a lot of changes. Trac 
item 3412 adressess a memory leak but this is already solved in 1.41
Permalink | Reply | 0 comments |
headers
Igor R | 1 Dec 2009 12:33
Picon

Re: Mac OSX - gcc crash

Thanks, I'll try to ask there.
Permalink | Reply | 0 comments |
headers
Stephen Nuchia | 1 Dec 2009 15:20
Favicon

Re: Boost Program Options: Just curiosity, why double dashes ?

The reasons given are sufficient but perhaps not as informative as they
could have been.

The "old way" is a single dash with single-letter options.  When
multiple options are given it is conventional to accept them all strung
together after one dash.  So
	ls -lrt
means the same thing as
	ls -l -r -t

In some cases, optional parameters were introduced using a dash, a
letter, and then a symbol or file name (fragment) as in
	cc -lm foo.c
where the "m" is the name of a library (the math funcitons of the
standard C library).

So when you've run out of letters or gotten tired of explaining the ones
that don't make sense and you want to go to words or phrases as options,
what do you do?  The answer chosen to that question is that we double
the dashes.

-swn
Permalink | Reply | 0 comments |
headers
Peter Dimov | 1 Dec 2009 15:50
Favicon

Re: thread_group::interrupt_all is not reliable

Stonewall Ballard wrote:
> I think I found the cause of this problem. It seems that the caller
> of interrupt_all should be holding the mutex associated with the
> condition on which the threads are waiting.

This looks like a classic CV pitfall when using "atomic" predicates that are 
not protected by the mutex used for the wait. The basic outline is that 
thread A does a CV wait on an atomic boolean variable, and thread B sets 
this variable and does a notify. There exists a race in which A sees false, 
is preempted, B stores true, does notify, waking up nobody, and then A 
continues with the wait. The cure is to insert an empty lock+unlock of A's 
mutex in B between the store and the notify; it doesn't need to encompass 
the store, and it doesn't need to encompass the notify call, either.

I can't read the boost.thread code well enough to be able to diagnose the 
problem, but from a cursory look, it looks possible to me that 
condition_variable::wait may perform its interruption check, be preempted, 
the interrupt can proceed with setting interrupt_requested and doing a 
broadcast, and then condition_variable::wait to block on its 
pthread_cond_wait.

Your workaround does prevent it, but I think that boost.thread should take 
care of that internally, by storing a mutex pointer in the thread data, 
along with the cv pointer.
Permalink | Reply | 5 comments |
headers
Stonewall Ballard | 1 Dec 2009 15:53

Re: thread_group::interrupt_all is not reliable


On Dec 1, 2009, at 3:29 AM, Roland Bock wrote:

> Stonewall Ballard wrote:
>> I think I found the cause of this problem. It seems that the caller of interrupt_all should be holding the
mutex associated with the condition on which the threads are waiting.
>> This gave me the clue to try that:
>> <http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_broadcast.html>
>>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether
or not it currently owns the mutex that threads calling pthread_cond_wait() or
pthread_cond_timedwait() have associated with the condition variable during their waits; however, if
predictable scheduling behavior is required, then that mutex shall be locked by the thread calling
pthread_cond_broadcast() or pthread_cond_signal().
>> thread::interrupt() calls pthread_cond_broadcast in pthread/thread.cpp.
>> Although "predictable scheduling" doesn't seem like it should include a failure to wake up, taking the
mutex around the call to thread_pool::interrupt_all() appears to be 100% reliable.
>> I can patch my app to do that, but I don't think there's a general solution. The documentation should
include a note that thread::interrupt() isn't reliable unless the caller is holding the mutex
associated with the condition variable on which the interrupted thread is waiting.
>> Of course, this could be a bug in the OS X pthreads implementation as well.
> 
> Hi,
> 
> FWIW, I ran that test of yours several times with varying parameters on my machine (quad core, 64bit,
linux) and it did not show a single failure. Of course, since it is not a deterministic effect even on your
machine, failure to reproduce does not really mean much, but well, I thought you might like to hear anyway :-)

Thanks, but this doesn't surprise me. Since the reliability drops rapidly as I add threads, I suspect it has
something to do with running this on an 8-core (16 hyperthread) machine. I also suspect that it's a Mac OS bug.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane