headers
Denis S. Otkidach | 1 Jul 2005 08:55
Picon

Re: Handling exceptions in SIP

On Thu, 30 Jun 2005 17:24:27 +0100
Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:

> > 4) There are several standard exceptions which I always have to catch.
> > Now I have a macro for them:
> >
> > #define CATCH_STD_EXCEPTIONS \
> >     catch (std::bad_alloc&) {\
> >         PyErr_NoMemory(); \
> >         sipIsErr = 1; \
> >     } catch (std::exception &exc) {\
> >         PyErr_SetString(PyExc_RuntimeError, exc.what()); \
> >         sipIsErr = 1; \
> >     } catch (...) {\
> >         PyErr_SetString(PyExc_RuntimeError, "unknown"); \
> >         sipIsErr = 1; \
> >     }
> >
> > used in %MethodCode:
> >
> > %MethodCode
> >     try {
> >         sipRes = someMethod(...);
> >     } CATCH_STD_EXCEPTIONS // sipIsErr - this comment is important hint to
> > SIP! %End
> 
> If your point is the need for the comment, then yes - consider it a feature.

No, I meant these exceptions must be caught almost everywhere.  So I
have to add %MethodCode to almost every method, which is annoying.  The
(Continue reading)

Permalink | Reply | 2 comments |
headers
Denis S. Otkidach | 1 Jul 2005 09:34
Picon

Re: Handling exceptions in SIP

On Thu, 30 Jun 2005 17:24:27 +0100
Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:

> > 1) If sipExceptionRef is not used in RaiseCode we'll get a warning.
> 
> Tonight's snapshot will only generate it if it is used.

Now I get no sipExceptionRef in catch clause even when it's used in
%RaiseCode.

--

-- 
Denis S. Otkidach
http://www.python.ru/      [ru]
Permalink | Reply | 2 comments |
headers
Phil Thompson | 1 Jul 2005 09:54
Picon

Re: Handling exceptions in SIP

On Friday 01 July 2005 8:34 am, Denis S. Otkidach wrote:
> On Thu, 30 Jun 2005 17:24:27 +0100
>
> Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:
> > > 1) If sipExceptionRef is not used in RaiseCode we'll get a warning.
> >
> > Tonight's snapshot will only generate it if it is used.
>
> Now I get no sipExceptionRef in catch clause even when it's used in
> %RaiseCode.

Whoops. Change the argument to the strstr() call that checks for 
"sipExceptionRef" from...

xd->raisecode

...to...

xd->raisecode->frag

Phil
Permalink | Reply | 1 comment |
headers
Denis S. Otkidach | 1 Jul 2005 09:59
Picon

Re: Handling exceptions in SIP

On Fri, 1 Jul 2005 08:54:19 +0100
Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:

> Whoops. Change the argument to the strstr() call that checks for 
> "sipExceptionRef" from...
> 
> xd->raisecode
> 
> ...to...
> 
> xd->raisecode->frag

Now it works fine, thanks.

--

-- 
Denis S. Otkidach
http://www.python.ru/      [ru]
Permalink | Reply | 0 comments |
headers
Phil Thompson | 1 Jul 2005 18:37
Picon

Re: Handling exceptions in SIP

On Friday 01 July 2005 7:55 am, Denis S. Otkidach wrote:
> On Thu, 30 Jun 2005 17:24:27 +0100
>
> Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:
> > > 4) There are several standard exceptions which I always have to catch.
> > > Now I have a macro for them:
> > >
> > > #define CATCH_STD_EXCEPTIONS \
> > >     catch (std::bad_alloc&) {\
> > >         PyErr_NoMemory(); \
> > >         sipIsErr = 1; \
> > >     } catch (std::exception &exc) {\
> > >         PyErr_SetString(PyExc_RuntimeError, exc.what()); \
> > >         sipIsErr = 1; \
> > >     } catch (...) {\
> > >         PyErr_SetString(PyExc_RuntimeError, "unknown"); \
> > >         sipIsErr = 1; \
> > >     }
> > >
> > > used in %MethodCode:
> > >
> > > %MethodCode
> > >     try {
> > >         sipRes = someMethod(...);
> > >     } CATCH_STD_EXCEPTIONS // sipIsErr - this comment is important hint
> > > to SIP! %End
> >
> > If your point is the need for the comment, then yes - consider it a
> > feature.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis S. Otkidach | 1 Jul 2005 18:50
Picon

Re: Handling exceptions in SIP

On Fri, 1 Jul 2005 17:37:44 +0100
Phil Thompson <phil <at> riverbankcomputing.co.uk> wrote:

> If we solve the problem of how to specify "..." then you could define 
> std::bad_alloc, std::exception, and (somehow) "..." using %Exception and 
> then...
> 
> 	void foo() throw (std::bad_alloc, std::exception, ...);
> 
> If this is too much trouble, then I can only suggest implementing something 
> like %DefaultExceptionHandler than contains your code and is applied to 
> anything that has no throw specifier (so long as the -e option is used).

I think we need some more feedback from other SIP users before going farther.

--

-- 
Denis S. Otkidach
http://www.python.ru/      [ru]
Permalink | Reply | 0 comments |
headers
Denis S. Otkidach | 2 Jul 2005 10:19
Picon

Bug in code for wrapped attributes

Below is a code generated for wrapped attribute (PyObject* in original
class, SIP_PYOBJECT in SIP spec):

-->8--
static PyObject *var_MyClass_myAttr(PyObject *sipSelf,PyObject *sipPy)
{
        PyObject * sipVal;
        MyClass *sipCpp = reinterpret_cast<MyClass *>(sipGetCppPtr((sipWrapper *)sipSelf,sipClass_MyClass));

        if (!sipCpp)
                return NULL;

        if (sipPy == NULL)
        {
                sipVal = sipCpp -> myAttr;

                Py_XINCREF(sipVal);

                return sipVal;
        }       

        sipVal = sipPy;

        if (PyErr_Occurred() != NULL)
        {
                sipBadSetType(sipNm_MyModule_MyClass,sipNm_MyModule_myAttr);
                return NULL;
        }

        Py_INCREF(sipVal); // <-- missed increment
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phil Thompson | 2 Jul 2005 13:05
Picon

Re: Bug in code for wrapped attributes

On Saturday 02 July 2005 9:19 am, Denis S. Otkidach wrote:
> Below is a code generated for wrapped attribute (PyObject* in original
> class, SIP_PYOBJECT in SIP spec):
>
> -->8--
> static PyObject *var_MyClass_myAttr(PyObject *sipSelf,PyObject *sipPy)
> {
>         PyObject * sipVal;
>         MyClass *sipCpp = reinterpret_cast<MyClass
> *>(sipGetCppPtr((sipWrapper *)sipSelf,sipClass_MyClass));
>
>         if (!sipCpp)
>                 return NULL;
>
>         if (sipPy == NULL)
>         {
>                 sipVal = sipCpp -> myAttr;
>
>                 Py_XINCREF(sipVal);
>
>                 return sipVal;
>         }
>
>         sipVal = sipPy;
>
>         if (PyErr_Occurred() != NULL)
>         {
>                
> sipBadSetType(sipNm_MyModule_MyClass,sipNm_MyModule_myAttr); return NULL;
>         }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Baz Walter | 2 Jul 2005 18:29

Are QLayout's iterators broken?

Hello List

I've been trying to adjust the layout of a QFileDialog after customising it 
using addWidgets(). I've tried to access the block of widgets at the bottom 
of the dialog using layout iterators, but something seems to be broken. The 
QLayoutItems produced by the iterators are all 'sterile'. That is, their own 
iterators don't produce anything and their layout(), widget(), and 
spacerItem() methods all return None. It's possible to 'cheat' a bit by using 
QObject methods to access child layouts - but this still ends up with the 
useless 'sterile' QLayoutItems at some point.

Here's some sample output to show what I mean:

>>> from qt import *
>>> a = QApplication([])
>>> d = QFileDialog()
>>> d.layout().activate()
>>> ## this is cheating...
... p = d.layout().children()[1]
>>> (isinstance(p,QLayoutItem),isinstance(p,QObject))
(True, True)
>>> print (p.layout(),p.widget(),p.spacerItem())
(<qt.QVBoxLayout object at 0xb7d467ac>, None, None)
>>> ## not cheating...
... c = p.iterator().current()
>>> (isinstance(c,QLayoutItem),isinstance(c,QObject))
(True, False)
>>> print (c.layout(),c.widget(),c.spacerItem())
(None, None, None)
>>> print (c.isEmpty(), c.iterator().current())
(Continue reading)

Permalink | Reply | 0 comments |
headers
Detlev Offenbach | 2 Jul 2005 20:33
Picon
Favicon

Re: Re: [Eric] How to use ipython ?

Am Mittwoch, 1. Juni 2005 14:20 schrieb Diez B. Roggisch:
> > Actually the IPython feature I'm the most missing, if not the only one,
> > is completion. This is a valuable improvement over the standard python
> > interpreter, when in the implementation/testing phase ; that's why it
> > made sense to me to have IPython run "inside" a python IDE...
>
> My eric has tab-completion working in it's interpreter already - in form of
> a window popping up giving me the possible choices. Which is nice, but
> could IMHO enhanced a great deal by implementing in incrementally, like the
> autocompletion in scintill. Any chances we see that coming, Detlev?
>

A shell completion using the scintilla userlist and showing the possible 
completions incrementally will be included in the next snapshot of the eric3 
3.8 development.

Regards,
Detlev
--

-- 
Detlev Offenbach
detlev <at> die-offenbachs.de
Permalink | Reply | 0 comments |

Gmane