This is not entirely true:
Symptoms of increasing memory usage are either because
a) you are keeping too much data around in user accessable memory
(likely)
b) you are creating self-referential structures that are not garbage
collected (also likely)
c) You have memory leaks in underlying C
{
PyErr_SetString(PyExc_TypeError,not a list);
return NULL;
}
}
--
http://mail.python.org/mailman/listinfo/python-list
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bronner, Gregory
Sent: 11 March 2008 20:52
To: Michael Wieher; python-list@python.org; [EMAIL PROTECTED
I'd strongly disagree.
SWIG is very useful for wrapping large scale projects in a
non-interfering manner. If you have to generate bindings for 1000+
classes, it is by far the easiest way to do things.
It isn't clear what you are doing that requires the PyObject*, or which
one you'd like.
In
I haven't seen much on this for a few years:
I'm working on a GUI application that has lots of callbacks. Testing it
is very slow and quite boring, as every time I find an error, I have to
exit it, restart it, and repeat the series of clicks. It would be really
amazing if python supported a
I haven't seen much on this for a few years:
I'm working on a GUI application that has lots of callbacks. Testing it
is very slow and quite boring, as every time I find an error, I have to
exit it, restart it, and repeat the series of clicks. It would be really
amazing if python supported a
I'm trying to create a type-safe subclass of int (SpecialInt) such that
instances of the class can only be compared with
ints, longs, and other subclasses of SpecialInt -- I do not want them to
be compared with floats, bools, or strings, which the native int
implementation supports.
Obviously, I
I'm trying to create a type-safe subclass of int (SpecialInt) such that
instances of the class can only be compared with ints, longs, and other
subclasses of SpecialInt -- I do not want them to be compared with
floats, bools, or strings, which the native int implementation supports.
Obviously, I
The operator= stuff is usually innocuous.
The compiler died because it couldn't find 'vector', which is reasonable, since
it thought it was compiling a C file.
Probably because you swigged the file without the magic -c++ option -- I'm
not sure how distutils passes arguments to swig, but if you
Since nobody has responded to this:
I know nothing about PIL, but you can do this using numpy and scipy
fairly easily, and you can transform PIL arrays into Numpy arrays pretty
quickly as well.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday,
I've done this the rather old-fashioned way.
Basically, what I do is:
Step 1:
Embed Python:
if(!::getenv(PYTHONHOME))
{
::putenv(PYTHONHOME=Whatever);
}
if(!::getenv(PYTHONPATH))
{
::putenv(PYTHONPATH=.);
}
Py_SetProgramName(leaktester);
Py_InitializeEx(0);
On the off chance that anyone is still following this:
I've got a relatively simple example of a program that loads 100
interpreters (sequentially) which all load the same swig module, do
something trival, and exit.
Each cycle leaks (or loses) 132k, which is a significant hit -- in my
real
What objects need to be shared across interpreters?
My thought was to add an interpreter number to the PyThreadState structure, to
increment it when Py_NewInterpreter is called, and to keep track of the
interpreter that creates each object. On deletion, all memory belonging to
these objects
I have an application that simultaneously extends and embeds the python
interpreter.
It is threaded, but all python calls are performed in one thread.
Several interpreters are running simultaneously -- the application
receives an event, activates a particular interpreter, and calls some
python
13 matches
Mail list logo
