On 19.09.2012, 11:07:14 Phil Thompson wrote:
> On Mon, 17 Sep 2012 22:25:59 +0200, mathias.b...@gmx.de wrote:
>> On 17.09.2012, 22:14:49 Phil Thompson wrote:
>>> On Mon, 27 Aug 2012 12:10:23 -0700, Matt Newell
> wrote:
>
> The difference is the access to the (not necessarily present)
> ob
On 17.09.2012, 22:14:49 Phil Thompson wrote:
> On Mon, 27 Aug 2012 12:10:23 -0700, Matt Newell wrote:
>>>
>>> The difference is the access to the (not necessarily present) objects.
>>> How
>>> are you getting these?
>>>
>>> Phil
>>
>> Here's the patch against a quite old hg checkout.
> After s
On Mon, 27 Aug 2012 12:10:23 -0700, Matt Newell wrote:
>>
>> The difference is the access to the (not necessarily present) objects.
>> How
>> are you getting these?
>>
>> Phil
>
> Here's the patch against a quite old hg checkout.
After several more iterations (ok, rewrites) the implementation
On 27.08.2012, 14:34:10 Phil Thompson wrote:
> On Sun, 26 Aug 2012 22:22:40 +0200, mathias.b...@gmx.de wrote:
>> On 26.08.2012, 16:07:52 Phil Thompson wrote:
>>> On Sun, 26 Aug 2012 14:30:32 +0200, mathias.b...@gmx.de wrote:
On 26.08.2012, 16:46:24 Phil Thompson wrote:
> On Wed, 15 Aug 201
On Mon, 27 Aug 2012 10:18:08 -0700, Matt Newell wrote:
>>
>> In current hg...
>>
>> %VirtualErrorCode is a new sub-directive of the %Module directive.
>>
>> all_throw_cpp_exception replaced by all_use_VirtualErrorCode.
>>
>> /ThrowsCppException/ replaced by /UsesVirtualErrorCode/.
>>
>> /NoTh
>
> In current hg...
>
> %VirtualErrorCode is a new sub-directive of the %Module directive.
>
> all_throw_cpp_exception replaced by all_use_VirtualErrorCode.
>
> /ThrowsCppException/ replaced by /UsesVirtualErrorCode/.
>
> /NoThrowsCppException/ replaced by /NoUsesVirtualErrorCode/.
>
> Remo
On Sun, 26 Aug 2012 22:22:40 +0200, mathias.b...@gmx.de wrote:
> On 26.08.2012, 16:07:52 Phil Thompson wrote:
>> On Sun, 26 Aug 2012 14:30:32 +0200, mathias.b...@gmx.de wrote:
>>> On 26.08.2012, 16:46:24 Phil Thompson wrote:
On Wed, 15 Aug 2012 15:54:11 +0200, mathias.b...@gmx.de wrote:
>
On 26.08.2012, 16:07:52 Phil Thompson wrote:
> On Sun, 26 Aug 2012 14:30:32 +0200, mathias.b...@gmx.de wrote:
>> On 26.08.2012, 16:46:24 Phil Thompson wrote:
>>> On Wed, 15 Aug 2012 15:54:11 +0200, mathias.b...@gmx.de wrote:
...
> Should all be fixed in current hg and tonight's snapshot.
> T
On Sun, 26 Aug 2012 14:30:32 +0200, mathias.b...@gmx.de wrote:
> On 26.08.2012, 16:46:24 Phil Thompson wrote:
>> On Wed, 15 Aug 2012 15:54:11 +0200, mathias.b...@gmx.de wrote:
>>> Phil,
>>>
>>> sip can already propagate C++ exceptions into Python in cases
>>> where Python calls a C++ function whic
On 26.08.2012, 16:46:24 Phil Thompson wrote:
> On Wed, 15 Aug 2012 15:54:11 +0200, mathias.b...@gmx.de wrote:
>> Phil,
>>
>> sip can already propagate C++ exceptions into Python in cases
>> where Python calls a C++ function which throws an exception.
>>
>> However, if I extend a C++ class in Pyth
On Wed, 15 Aug 2012 15:54:11 +0200, mathias.b...@gmx.de wrote:
> Phil,
>
> sip can already propagate C++ exceptions into Python in cases
> where Python calls a C++ function which throws an exception.
>
> However, if I extend a C++ class in Python and call a corresponding
> (Python-)method in C++
Phil,
sip can already propagate C++ exceptions into Python in cases
where Python calls a C++ function which throws an exception.
However, if I extend a C++ class in Python and call a corresponding
(Python-)method in C++ via the wrapper, the sip generated
wrapper code checks for a Python exception
12 matches
Mail list logo