I was using an extension that traverses the GC heap, and it crashed when it
got to the sipVariableDescr_Type object, because it never gets initialized
via PyType_Ready.
The fix is easy; just an extra PyType_Ready for sipVariableDescr_Type in the
PyMODINIT_FUNC in siplib.c
Thanks!
- Kevin
__
I updated to a newish SIP snapshot and was playing around with using
/Supertype=sip.simplewrapper/ when possible.
The note in the docs about simplewrapper objects being unable to take
part in ownership transfer is good, but it might be even more useful for
SIP to warn or fail when you have a s
> Anyway, I'm looking into using sipconfig so I'll end up with lots of little
> files instead of one big one.
It sounds like some new algorithm made your big-oh a little a bigger--splitting
things up might improve things quite a bit. I'd also take the time to figure
out how to make g++ do precomp
> I'm still at Akademy, but I'll try to get this checked into KDE's SVN
> some time this weekend along with all of my changes. (Probably in
> kdesupport. I'm not sure if I can keep the change history though.)
+1 on interest in seeing this! Especially the autodocs-from-doxygen support.
_
Turns out (one) of my problems was %GCClearCode that was being invoked
after a C++ object's destructor.
There's a note in sipWrapper_dealloc about calling sipWrapper_clear
after td_dealloc:
Now that the C++ object no longer exists we can tidy up the Python
object. We used to do this first but
I've got random sporadic crashes that look like memory corruption. From
some googling around it looks similar to problems others have had when
they're not obtaining the GIL before calling Python code.
I've sifted through my .sip files looking for trouble spots with no
luck.
Is there some trick t
> You could look at the call to PyObject_GC_UnTrack() in
> sipWrapper_dealloc(). I don't think it's the same problem, but there may be
> similarities.
As far as I can tell, PyObject_GC_UnTrack just says that the GC shouldn't call
the traverse functions while you're destructing the object--but what
I've got a sporadic crash in my app (not PyQT) and I think I have it
narrowed down.
1) Main thread creates a Flub object.
2) Main thread releases all references to the Flub object, but there's a
cycle,
so the object isn't collected immediately.
3) Worker thread does some unrelated work, during wh
> '0xc135'
> Stop.
Google says that could mean nmake can't find cl.exe. Did you make sure to start
your command prompt via the "Visual Studio 200x Command Prompt" shortcut?
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcom
> It should be fixed in tonight's SIP snapshot. It was just a Py_DECREF()
> that got dropped.
Thanks--the fix looks good in my tests.
Although I'm still a bit confused about the long comment for when there's a
callable (not a CFunction and not a PyMethod) in the slot. There's still no
Py_DECREF i
> > Anyone lucky enough to be using Visual Studio for their SIP projects have
> > any
> > advice on the Python stack trace issue?
>
> Not that I know of, but please let me know if you find out something.
The best I could come up with was to wrap my main loop in an SEH block
(lookup __try and __e
> The workaround makes my skin crawl. :| I hope you'll be able to whip up
> a fix, Kevin.
I tried, but I screwed up attribute access in a way I didn't understand yet.
Disabling the method cache altogether proved a workable temporary fix
for me--but I won't want to ship it :) Phil, any suggest
Sundance ierne.eu.org> writes:
> This class behaves like weakref.ref, only for callables.
We use a variant of this idea in our app for observable callbacks:
class bound_ref(object):
def __init__(self, method, cb = None):
self.object = weakref_ref(method.im_self, cb)
self.fun
There's a comment in siplib.c:5300ish in the sip_api_is_py_method
function that I'll reproduce here:
/*
* Note that the callable is never garbage collected. The main
* reason for this is that it's not possible to get hold of the
* method cache without make incompatible changes to the SIP
* AP
Phil Thompson riverbankcomputing.com> writes:
>
> On Thursday 12 June 2008 3:50:00 pm Kevin Watters wrote:
> > I noticed /NewThread/ on QThread and QRunnable in the PyQT source-- and
> > a peek at the source code shows SIP creating thread local structures for
> > pend
I noticed /NewThread/ on QThread and QRunnable in the PyQT source-- and
a peek at the source code shows SIP creating thread local structures for
pending objects.
My app creates threads, but only through Python's threading module.
Do I need to use /NewThread/, or call something like api_new_thread
I was profiling my SIP extension, seeing that I allocate lots and lots
of a certain class of small objects, whose ownership is never
transferred to C++. I remembered reading a section from the Python C API
manual on memory management, here:
http://docs.python.org/api/memoryOverview.html -- the re
In the docs for %ConvertToSubClassCode, there's a mention about class
hierarchies over multiple modules:
>> Note that if a class hierarchy extends over a number of modules then
>> this directive should be used in each of those modules to handle the
>> part of the hierarchy defined in that module.
Yikes! SIP ran out of memory because of this typo:
class MyClass : MyClass
{
};
(As a side note, Mac OS X deals with out of memory situations much more
gracefully than Vista.)
I'd imagine there's a fix to be somewhere in the superclass: part of parser.y ;)
_
> As far as I can see SIP embeds the manifest in the executable so it is not
> necessary to install it. If I don't run mt on the exe then it fails to run.
> If I do then it runs - irrespective of whether the manifest is installed or
> not.
I second this--I had to add the following post-build st
I've got a couple quick questions about SIP's handling of object destruction.
The docs for sip.setdeleted says
setdeleted(obj)
This marks the C++ instance or C structure as having been destroyed or
returned to the heap so that future references to it raise an exception rather
than cause a pro
Phil Thompson riverbankcomputing.com> writes:
> It should be fixed in tonight's snapshot.
Thanks! This fixed every single one of my related failing test cases.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/m
I think I found a bug with rich comparison operators. I have a simple class
like this:
class point
{
public:
point();
point(int x, int y);
int x;
int y;
%ConvertToTypeCode
/* (convert sequences with 2 ints to points) */
%End
bool operator==(const p
> old_init = MyClass.__init__ def new_init(self, foo, bar=5, meep=13):
> old_init(self, foo, bar, meep) MyClass.__init__ = new_init
>
> assert MyClass.__init__ is new_init # FAIL
Oops. That should be
old_init = MyClass.__init__
def new_init(self, foo, bar=5, meep=13):
old_init(self, foo, bar
SIP is working great for me so far, enough so that I'm coming to the question
of what to do with keyword arguments. I've got a fairly large code base, part
of which makes calls to GUI control constructors using keyword arguments.
It's actually a fairly limited subset of methods, so my initial thou
For future reference, my forked SIP with auto-generated properties is here:
http://github.com/kevinwatters/wxpy/tree/master
Just use %SIPOptions (AutoProperties)
There's also (as of this posting) an option to strip "wx" from the beginning of
any PyNames. This hack is enabled with %SIPOptions (Ren
I want to make an option for SIP to autogenerate properties (i.e., GetTitle and
SetTitle just become Title).
I've been reading through transform.c, trying to get a feel for how this might
happen, but I think I'm lacking the "big picture" when it comes to how SIP
implements methods and attribute lo
> you will find a cache implementation for PyQt4's configure.py (search > for
"manage_cache"). ... > > You might grab that code and integrate it within your
setup.py. >
This was exactly what I was looking for, and is work great! Thanks!
> > 6) The docs show show no comparisons with similar tools.
I just started looking into SIP this weekend (I'm trying to wrap the wxWidgets
library--has this been attempted before?), and I had a couple thoughts and
questions.
1) The docs make no mention of the fact that you cannot use keyword arguments
when calling C functions. This was a surprising limitat
29 matches
Mail list logo
