Here's the double lock I'm afraid of:
1. Embedding program invokes some Python code with its embedded interpreter
2. The embedded interpreter, through running that code, ends up executing
some code actually in the embedded program's environment.
3. This code back in the embedded program has anothe
Oh I understand that. When they got the Dynamic Language Runtime down,
they opened up the gates for that. That being said, Python.NET choked up
on that test too. I don't think it's using the DLR though.
Really I only give it as something of a final acceptance test for being
able to work between
On Tue, Dec 25, 2012 at 5:52 AM, John Zwinck wrote:
>
> Yes, the main point is to provide a reasonably safe, RAII-style mechanism
> for releasing the GIL around long-running C++ functions. But in addition
> to a class for releasing (and later reacquiring, hence RAII), I made a
> class for acquir
Is the particular focus of your code on getting the GIL released during
longer method invocations? I don't have any sway with Boost or anything,
so I'm just asking out of my own personal curiosities. When I first saw
the message, without seeing the code, I was wondering if you might have
coincide
The object was declared in the class and instantiated when an instance of
that object is created. It wasn't a pointer I failed to construct. I
managed to screw around with the Python documentation awhile and get
something like this working:
boost::python::handle<>
mainHandle(boost::python::b
I wanted to provide an instance of a particular object I'm using for
Stackless Python state management. I'm trying to take over the green
thread management so I can do my own scheduling--but that's only context.
In the attached code, I'm trying to do some of life's more simple things.
I have the
peed to its minimum. If it doesn't trip,
> you have a timing race.
>
> If you can build on Linux, try valgrind.
>
> Oh, you mentioned bits you weren't locking when destroying. I'd lock
> those and see what happens.
>
> Niall
>
> On 26 May 2012 at 13:19, A
This might be one for the main Python lists but since I have a whole lot of
stuff wrapped in Boost floating about this problem, I wanted to try the
C++-sig for starters. I run my little game experiment for anywhere between
15 and 60 seconds, where it's sending a lot of events and messages around
b
on taking and returning a void *, you could use this to
> make any arbitrary wrapped C++ object "appear" in python.
>
> Niall
>
> On 6 May 2012 at 15:01, Adam Preble wrote:
>
> > I'm running into my old friend the GIL when it comes time to destroy an
> > o
I'm running into my old friend the GIL when it comes time to destroy an
object I've wrapped using boost::python::wrapper. The object is being
bandied around as a shared pointer, and it's refcount is ending at the time
I want. Unfortunately, I get the old "PyThreadState_Get: no current
thread" err
I am pondering trying to eliminate some usages of shared pointers in my
code since I have finally completed enough of it that I have good ownership
rules for things in place. I still have one spot, which is basically the
main door to the C++ runtime, where I have a problem. I've been creating
ins
aul Kroitor
>
> ** **
>
> *From:* cplusplus-sig-bounces+paul=kroitor...@python.org [mailto:
> cplusplus-sig-bounces+paul=kroitor...@python.org] *On Behalf Of *Adam
> Preble
> *Sent:* April-06-12 10:03 AM
> *To:* Development of Python/C++ integration
> *Subject:* Re: [C+
For my stuff, under Linker->Input, I explicitly listed my Boost.Python lib
and the Python lib. Like so:
libboost_python-vc100-mt-gy-1_47.lib
python26_d.lib
Actual names for yours will vary. By chance are you new to Visual Studio
generally?
On Fri, Apr 6, 2012 at 8:50 AM, Payam Shiva wrote:
>
Now that you have the binaries, you should be ready to use them. There
should be no need to configure jam files. If you start pointing to those
libraries in your Visual Studio project, they should link with your code.
This assumes the binaries you're using mate up with how you'd building
your Vi
For what it's worth, here's what I have when I did a 32-bit debugging build
of Stackless Python. Note that I have turned on debugging and stuff like
that. You don't need that, but it should give you an idea:
user-config.jam
using python : 2.6 :
D:\\temp\\stackless_src\\python-2.6.5-stackless\\PC
On Tue, Apr 3, 2012 at 4:12 AM, Payam Shiva wrote:
> Hi,
>
> I have trouble compiling the simplest examples with Boost.Python. I
> hope you could help me find out what I'm doing wrong.
> I am using Microsoft Visual C++ 2010 on 64-bit Windows 7. I use 64-bit
> version of Python 2.7.2 from Enthough
On Sat, Mar 17, 2012 at 1:44 PM, Niall Douglas wrote:
> If by "Python side" you mean Boost.Python, then I agree: BPL has no
> support for GIL management at all, and it really ought to. This was
> one of the things that was discussed in the BPL v3 discussions on
> this list a few months ago.
>
>
He
Well the current design does have a problem, but I think it's more to do
with the Python side than the sum of the whole thing. Most of my threads
are basically subsystems in their own rights, and whatever that subsystem
manage is encapsulated inside it. I get into this little spats when I need
to
11:59 PM, Adam Preble wrote:
> I discovered recently that during callbacks to Python objects, sometimes
> the interpreter would try to do stuff at the same time, despite the fact I
> made a call to ensure the GIL. I read the solution for that kind of thing
> I'm
I discovered recently that during callbacks to Python objects, sometimes
the interpreter would try to do stuff at the same time, despite the fact I
made a call to ensure the GIL. I read the solution for that kind of thing
I'm doing is calling PyEval_InitThreads(). This worked at first, but like
m
Do have a way to unregister the callback? When I was using a shared_ptr
originally, I was trying to use that, yet the objects still hung around. I
was thinking that I properly didn't completely unregister it from all
listeners, but I wonder now if I actually managed to cover all my tracks.
I'm w
On Tue, Mar 6, 2012 at 3:47 AM, Holger Brandsmeier wrote:
> Adam,
>
> You probably have a function like this
>
> void addCallback(share_ptr<> arg) {
> callbacks.push_back(weak_ptr<>(arg);
> }
>
>
That's pretty much what I have happening.
>
> So, before the function exits your object `arg` exists
I am trying to break a smart pointer cycle in my application. There is an
interface that can be implemented in both c++ and Python, and it is used
for messaging callbacks. I can contain a list of these as shared pointers,
but it only makes sense for cases where the owner of the container has
excl
five of us that have ever wanted to
do this.
On Tue, Feb 28, 2012 at 3:18 PM, Dave Abrahams wrote:
>
> Please read:
>
> http://www.boost.org/doc/libs/1_49_0/libs/python/doc/building.html#python-debugging-builds
>
> HTH,
> Dave
>
> on Wed Feb 15 2012, Adam Preble wrote:
It looks like PyObject_IsSubClass is working (!), but I wanted to follow up
on the boost::python::object stuff:
On Fri, Feb 24, 2012 at 9:56 PM, Jim Bosch wrote:
> On 02/24/2012 02:31 AM, Adam Preble wrote:
>
>> Jim,
>>
>> I'll top post since I think this
Jim,
I'll top post since I think this might get messy nice and fast otherwise.
I found I couldn't get to a method wrapped to type a PyTypeObject* and
only PyObject* would do. Despite all this, I managed to twist your advice
around just enough to birth this abomination:
bool ContainsImplementabl
pass in some kind of type information and
be able to positively identify if something in that container matches the
type?
On Tue, Feb 21, 2012 at 2:03 AM, Adam Preble wrote:
> It'll compile and and I'll get that Remove method fine. Except I can't
> seem to cram someth
I am using Boost 1.47
I have these class methods:
void Remove(const std::type_info &type);
void Remove(const boost::python::type_info type);
I tried wrapping them both in Boost.Python:
void (Entity::*Remove1)(const std::type_info&) = &Foo::Remove;
void (Entity::*Remove2)(const boost::python::ty
I previously posted about runtime oddness when switching to a debug build
of python. I figured I needed to rebuild Boost.Python. The build process
is fixated on using the normal python.exe and python.lib paths, rather than
python_d.exe and python_d.lib. I have put those files in my Python26
dire
I am trying to use Python with debug symbols so I can peak into it when I
get runtime errors related to Boost.Python wrappers. I can't seem to get
this to work. I think this is more a building thing than anything else so
I figure I'd share what I've done:
1. Acquire the source for Stackless Pyth
On Feb 5, 2012 10:15 AM, "Jim Bosch" wrote:
>
> On 02/05/2012 12:56 AM, Adam Preble wrote:
>>
>>
>> On Sat, Feb 4, 2012 at 8:48 PM, Jim Bosch > <mailto:tallji...@gmail.com>> wrote:
>>
>>Oh, you're right. I was confusing the ma
On Sat, Feb 4, 2012 at 8:48 PM, Jim Bosch wrote:
> Oh, you're right. I was confusing the manual way of doing Python-side
> polymorphism (derived-class holders) with the more automatic (and better)
> way you're doing it (with wrapper). Your original code was fine in that
> regard.
>
> Anyhow, lo
On Sat, Feb 4, 2012 at 10:46 AM, Jim Bosch wrote:
> If I understand your intend correctly, I think your class_ definition
> needs to be:
>
> class_,**noncopyable>
>
> (right now you have class_)
>
>
>
Something like this?
class_,
boost::noncopyable>("Communicatable")
I get burnt by the compiler
I am trying to run this on Win32, using Stackless Python 2.6, and Boost
1.47.
I am having a problem with passing a shared_ptr of a C++ object
implementing a C++ interface to a wrapper of a Python object implementing a
C++ interface. That's a mouthful, so I thought I'd simplify the code. The
thin
I have opted to have my C++ main call an autoexec.py script by default when
compiled to support the interpreter. Ultimately, I will want to run some
Python code w/o user intervention to do it. I have come up with this
somewhat naive implementation:
http://pastebin.com/NTytF6iQ
It starts the scr
I'm using boost 1.47 on Windows Vista, with Visual Studio 2010.
My situation is something like this:
1. I have a base interface in C++ to which I've exposed a wrapper in Python.
2. In the C++ source, I have a class that contains multiple instantiations
of said interface. We can call it Foo. Foo
n the proper way to handle the inheritance construction in
Python. Is this kind of the normal rigors when subclassing in Python
normally, or is this something I must particularly pay attention to when
using Boost?
On Sat, Nov 12, 2011 at 1:02 PM, Nat Goodspeed wrote:
> On Nov 12, 2011, at 11:34
I am seeing this come up in many variations, with people doing slightly
different things. I haven't yet seen an example doing something in this
exact progression. I apologize here because I feel like I'm repeating a
topic that has come up on the list before--even just a few weeks back.
Here's wha
38 matches
Mail list logo
