wow, i didnt even realize that numpy had such an engine. Thanks!
-Chris
On Tue, Feb 16, 2010 at 4:34 PM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
> On Feb 16, 2010, at 1:05 PM, Lisandro Dalcin wrote:
>
> > On 16 February 2010 17:35, Dag Sverre Seljebotn
>
Hey all,
When coding for the scikits.image project, we are making extensive use of
Cython. It would be nice to have algorithms that work on multiple datatypes
(numpy dtypes) without having to hand code everything. So, i've been toying
around with how a simple templating syntax might look.
I've th
I forgot a disclaimer:
This is all to the best of my knowledge. I'm sure one of the awesome
Cython devs will jump in and correct me ;)
On Sun, Nov 15, 2009 at 3:04 AM, Chris Colbert wrote:
> AH I see ok. I should have read more carefully (a little late here).
>
> When you com
AH I see ok. I should have read more carefully (a little late here).
When you commented out the INCREF on the datat, did you also comment
out PyArray_Set_BASE? If not, that may have been causing the problem.
If you set the base without INCREF'ing the data, then numpy will
DECREF that data when pyt
e python data
object, or else you leak a reference, and the memory will never get
freed.
Cheers,
Chris
On Sun, Nov 15, 2009 at 2:31 AM, Matthew Brett wrote:
> Hi,
>
> On Sat, Nov 14, 2009 at 5:13 PM, Chris Colbert wrote:
>> AFAIK, you only have to INCREF the dtype. And only f
AFAIK, you only have to INCREF the dtype. And only for numpy array
creation routines that take a dtype object as an argument (they
"steal" a dtype reference, which is why you have to incref it).
On Sun, Nov 15, 2009 at 2:09 AM, Matthew Brett wrote:
> Hi,
>
> I've been spending some time with Cyt
I noticed you just changed the version signature too:
Version < 0.12
Does that mean we can't turn that off in >= 0.12, or must we just
explicitly declare it?
On Mon, Nov 9, 2009 at 7:54 PM, Robert Bradshaw
wrote:
> On Nov 9, 2009, at 10:45 AM, Chris Colbert wrote:
>
>&g
is there an error in that table:
'''
cdivision True/False Version >= 0.12
If set to True, Cython will adjust the remainder and quotient
operators C types to match those of Python ints (which differ when the
operands have opposite signs) and raise a ZeroDivisionError when the
right operand is
What was the rationality behind having to explicitly declare C
division, versus explicitly declaring python division?
Just curious.
Cheers!
On Mon, Nov 9, 2009 at 5:40 PM, Dag Sverre Seljebotn
wrote:
>> Hi all,
>>
>> Why is it necessary to decorate a pure "cdef" with
>> @cython.cdivision(True
#--
# foo.py
#--
from decorator import docdeco
@docdeco('''docstring goes here''')
def bar():
pass
On Thu, Oct 29, 2009 at 1:32 PM, Chris Colbert wrote:
> Hi,
>
> I didn't get a response on Cython-users, so i thought I might tr
Hi,
I didn't get a response on Cython-users, so i thought I might try here.
I tried modifying the docstrings of cythonized "def" functions via a
function decorator.
While it passes cython compilation, I get a run-time error that says
the docstring cannot be modified in place.
Is there a special
On Tue, Oct 27, 2009 at 10:16 PM, Sturla Molden wrote:
> Stéfan van der Walt skrev:
>>
>> As a side note, it may be safer to use the definitions of npy_intp and
>> npy_uintp from the numpy header, rather than Py_ssize_t and Py_size_t.
>> In some earlier versions of Python (e.g., 2.4), these were
line 317 in numpy.pxd for Cython 11.3
bint PyArray_ISISCONTIGUOUS(ndarray m)
double "IS" in that definition.
Cheers,
Chris
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Ok, I gotcha. My lack of formal programming training is on display today :)
Thanks Sturla and Robert!
Chris
On Mon, Oct 12, 2009 at 10:12 PM, Robert Kern wrote:
> On 2009-10-12 15:00 PM, Chris Colbert wrote:
>> so I have this function: (the print statements are just for debugging)
&
Ah, that would explain it.
Thanks!
On Mon, Oct 12, 2009 at 10:11 PM, Sturla Molden wrote:
> Chris Colbert skrev:
>> i cant for the life of me, figure out where the error is coming in?
>>
>> Does anyone see it?
>>
> You are returning a pointer to local arrays. The
so I have this function: (the print statements are just for debugging)
cdef np.npy_intp* clone_array_shape(np.ndarray arr):
# the proper way to do this would be to use malloc
# to create a new npy_intp* array of the proper size
# but then we would have to track it and make a call to fr
I can't connect from germany.
just an FYI
Cheers,
Chris
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Thanks for the clarification Dag.
Cheers!
On Sat, Oct 10, 2009 at 4:38 PM, Dag Sverre Seljebotn
wrote:
> Chris Colbert wrote:
>> for example if I have something like this:
>>
>> cimport numpy as np
>>
>> cdef void foo(np.ndarray arr):
>>
for example if I have something like this:
cimport numpy as np
cdef void foo(np.ndarray arr):
def bar(np.ndarray arr):
foo(arr)
is arr getting passed by value or by reference?
When I wrap other C libraries, I have to do a foo(&cobject) to pass
cobject by reference and h
duly noted.
Thank you.
On Fri, Oct 9, 2009 at 10:48 AM, Dag Sverre Seljebotn
wrote:
> Chris Colbert wrote:
>> Fantastic!
>>
>> Thanks!
>> On Fri, Oct 9, 2009 at 8:17 AM, David Warde-Farley
>> wrote:
>>> On 8-Oct-09, at 7:38 PM, Chris Colbert wrote:
&g
Fantastic!
Thanks!
On Fri, Oct 9, 2009 at 8:17 AM, David Warde-Farley wrote:
>
> On 8-Oct-09, at 7:38 PM, Chris Colbert wrote:
>
>> Since I have a "cimport numpy as np" at the top of my cython file,
>>
>> array1.shape == array2.shape
>>
>> is on
Since I have a "cimport numpy as np" at the top of my cython file,
array1.shape == array2.shape
is only true if array1 IS array2 because .shape return the npy_intp*
pointer to the shape array.
Is there a way for me check if the values in the shape array are equal
(ala python) without having to d
o cytypestest.c
$python
>>> import cytypestest
1255008817
On Thu, Oct 8, 2009 at 3:05 PM, Chris Colbert wrote:
> Ok, tried both of those methods, and they pass cython compilation, but
> then I get this error from gcc:
>
> brucewa...@broo:~/Desktop$ gcc -shared -pthread -fPIC -fwrapv
’:
cytypestest.c:707: error: subscripted value is pointer to function
Cheers!
Chris
On Thu, Oct 8, 2009 at 2:35 PM, Dag Sverre Seljebotn
wrote:
> Dag Sverre Seljebotn wrote:
>> Chris Colbert wrote:
>>> Given our previous conversation, it will probably be easier to use
>
Given our previous conversation, it will probably be easier to use
ctypes to get the function handles for dynamically loaded libraries
and *somehow* get that function pointer into Cython.
My attempt is like so (for a simple example) but Cython is complaining
during compilation:
from ctypes impor
at 7:58 PM, Dag Sverre Seljebotn
wrote:
> Chris Colbert wrote:
>> using something similar to ctypes dlopen?
>>
>> I would like to be able to create a wrapper for a library that can
>> built on the client machine without the necessity of the target
>> libraries bei
using something similar to ctypes dlopen?
I would like to be able to create a wrapper for a library that can
built on the client machine without the necessity of the target
libraries being present.
Then, upon import of the library, the library would check for the
presence of the .so's and raise a
unfortunately in that statement, the (e2/e1) power is applied to the
sum of inner terms, so I can't condense it any further than this:
(fabs(f1)**(2/e2) + fabs(f2)**(2/e2))**(e2/e1) + fabs(f3)**(2/e1)
On Wed, Sep 30, 2009 at 1:52 AM, Robert Bradshaw
wrote:
> On Sep 29, 2009, at 12:03 P
Actually, yes. The exponents are done specifically in that way to
force the sign of the end value.
I suppose i could just call abs() on it though
- Chris
On Tue, Sep 29, 2009 at 8:58 PM, Robert Bradshaw
wrote:
> On Sep 29, 2009, at 10:05 AM, Sturla Molden wrote:
>
>> Chris C
.
Cheers,
Chris
On Tue, Sep 29, 2009 at 7:11 PM, Chris Colbert wrote:
> my big issue here is that these two lines of code, are taking more
> time to execute than the entire function as a pure numpy
> implementation. And numpy is using the same calls to pow in the
> background...
>
&g
Molden wrote:
> Chris Colbert skrev:
>> No, the python ** gets translated to a pow statement by cython.
>>
>> I think the issue is that for some reason, i'm getting stuck in the
>> gcc slow pow function
>>
>> if i let e2 and e1 be 1 and replace f*
tried that already...
no difference...
On Tue, Sep 29, 2009 at 6:33 PM, Robert Kern wrote:
> On 2009-09-29 11:21 AM, Chris Colbert wrote:
>> or better yet, which pow function is numpy using?
>
> double pow(double, double) from math.h .
>
> --
> Robert Kern
>
> &q
08 µs per loop
over 6x improvement just by avoid a few measly pow statements...
anyone know why i'm stuck in slowpow?
On Tue, Sep 29, 2009 at 6:15 PM, Sturla Molden wrote:
> Sturla Molden skrev:
>> Chris Colbert skrev:
>>
>>> and within that loop it is these stateme
or better yet, which pow function is numpy using?
On Tue, Sep 29, 2009 at 6:21 PM, Chris Colbert wrote:
> No, the python ** gets translated to a pow statement by cython.
>
> I think the issue is that for some reason, i'm getting stuck in the
> gcc slow pow function
>
>
57 PM, Chris Colbert wrote:
> I just verified that the loop is consuming 96% of the execution time...
>
> weird... the loop gets converted to very basic C code... I would think
> it would be much faster...
>
> perhaps its my compilation step?
>
> my setup.py looks li
s:
gcc -shared -pthread -fPIC -fwrapv -O2 -Wall -fno-strict-aliasing
-I/usr/local/lib/python2.6/dist-packages/numpy/core/include/numpy
-I/usr/include/python2.6 -o superquadricfit.so superquadricfit.c
they both yield the same result
On Tue, Sep 29, 2009 at 4:46 PM, Chris Colbert wrote:
Dag,
HTML was too big to attach to the list email, so I sent it to your
personal email.
Thanks for taking a look!
Chris
On Tue, Sep 29, 2009 at 4:42 PM, Chris Colbert wrote:
> Dag,
>
> Html is attached, all that garbage at the bottom in commented out via
> a docstring (i was u
Normally, when I'm hitting a road block with numpy performance, I port
that section to cython and typically see an order of magnitude
increase in speed. (this is without disabling bounds checking) In my
current case, I'm seeing a slowdown of 2x (with boundschecking
disabled) and I'm pretty sure eve
I'm getting the following error when import a simple cython extension module:
ImportError: dynamic module does not define init function
(initcythonsuperquadricfit)
the following is how i built the module... doesnt seem there is a problem:
brucewa...@broo:~/Desktop/object_reconstruction$ cython
Ah, I'm having a stupid day.
I need to use the same name for the .so as the source file. Doh!
Chris
On Tue, Sep 29, 2009 at 3:15 PM, Chris Colbert wrote:
> I'm getting the following error when import a simple cython extension module:
>
> ImportError: dynamic module d
wait, scratch that idea, that would throw python syntax errors all
over the place.
I was too quick on the send button...
On Tue, Aug 25, 2009 at 5:49 PM, Chris Colbert wrote:
> with regards to replacing weave, would it be possible to just use a
> function decorator?
>
> i.e so
with regards to replacing weave, would it be possible to just use a
function decorator?
i.e something like:
@cythonize
def trivial_func(int i):
cdef int j
j = i + 1
return j
I particularly like the thought of this over weave so that I don't
have to "switch gears" in brain from
I'm no expert, but I would type your input arguments and use the float
versions of the math.h functions since your dtypes are floats.
On Tue, Aug 25, 2009 at 11:19 AM, Adam
Ginsburg wrote:
>> From: Robert Bradshaw
>> Subject: Re: [Cython] Linking error - 64 bit problem?
>>
>> On Aug 22, 2009, at
ython},
url= {http://www.cython.org},
year = 2009
}
On Mon, Aug 24, 2009 at 4:13 PM, Robert
Bradshaw wrote:
> On Mon, 24 Aug 2009, Chris Colbert wrote:
>
>> I'm working on a paper and need to include a citation for Cython, is
>> there a preferred ci
I'm working on a paper and need to include a citation for Cython, is
there a preferred citation, or should I use this entry I found in the
sage archives?
@manual{cython,
> Author = {Stefan Behnel, Robert Bradshaw, and Dag Sverre Seljebotn },
> Title = {Cython: C-Extensions for Python},
> note =
did you link to libc? (i think that's where time.h is implemented)
On 8/16/09, Christian wrote:
> Hello,
>
> I am trying to import the time function from time.h as following:
>
> cdef extern from "time.h" nogil:
> ctypedef long time_t
> time_t time(time_t*)
>
>
> I am using MinGW as compi
Well, I have a dreamhost server just sitting around. It only hosts my
blog (which is mostly non-existant), but I have ample bandwidth and
space.
It is however, on a shared box so the performance isnt stellar.
The Cython list seems to be lightweight however, so if you want to
give it a try (and wa
+1
On Fri, Jul 24, 2009 at 11:21 AM, Lisandro Dalcin wrote:
> On Fri, Jul 24, 2009 at 8:53 AM, Robert
> Bradshaw wrote:
>> This feels a lot like C++ operator overloading...
>>
>> I'm not a fan of _as_parameter_, but maybe an "as foo_t" kind of
>> attribute that it would use every time it needed to
I'd just like so input as to whether I have the right idea.
I would like to subclass numpy's ndarray (on the python side), this new
class will call functions in a C library that expects an array type that's
defined in its own library.
This library also uses a strided array model.
So my idea is to
Thanks Stefan!
On Thu, Jul 2, 2009 at 12:32 AM, Stefan Behnel wrote:
> Hi,
>
> Chris Colbert wrote:
>> I'm thinking this may be what the new array type is for, but i'm not sure.
>>
>> say I have a C struct which I wrap as a class:
>>
>>
>&g
I'm thinking this may be what the new array type is for, but i'm not sure.
say I have a C struct which I wrap as a class:
#mycfile.h
struct Foo
{
int* data[32];
};
#my_dec_file.pxd
cdef exter from "mycfile.h":
cdef struct Foo:
int* data[32]
#my_cy_file.pxd
cimport my_de
] == (vertex)])
should I just implement this as a python function, or is there a way
to wrap it?
I would wrapping wouldn't be possible since the type isn't determined
till runtime...
On Wed, Jul 1, 2009 at 3:53 PM, Chris Colbert wrote:
> Thanks Lisandro,
>
> I may just end up decla
Thanks Lisandro,
I may just end up declaring each struct like this with a 'pass'
and then implementing the fields on the python side (this is how ctypes does it)
Cheers!
On Wed, Jul 1, 2009 at 3:01 PM, Lisandro Dalcin wrote:
> On Wed, Jul 1, 2009 at 3:24 PM, Chris Colbert wrote:
i just saw this line in the docs:
6. If the header file defines a function using a macro, declare it as
though it were an ordinary function, with appropriate argument and
result types.
So i'll start there.
Sorry for the bogus post.
On Wed, Jul 1, 2009 at 1:52 PM, Chris Colbert wrote:
In wrapping a C library, I come across many #define statements that I
need to use elsewhere. When they simply define a constant, I use an
anonymous enum and all is well.
But how would I wrap something like this that shown up in a header
file that i'm cdef extern'ing from:
#define CV_TREE_NODE_FIE
; On Mon, Jun 29, 2009 at 9:23 PM, Lisandro Dalcin wrote:
>> Now send me the results of the cmd line below, :-)
>>
>> $ grep -ir "CV_STDCALL" *
>>
>>
>> On Mon, Jun 29, 2009 at 7:08 PM, Chris Colbert wrote:
>>>>>
>>>>
>
>>
>
> Just to be sure... if you look at all the OpenCV headers, can you see
> "__stdcall" somewhere?
>
>
here's the results of a grep:
brucewa...@broo:/usr/local/include/opencv$ grep -ir "__stdcall" *
cxtypes.h:#define CV_STDCALL __stdcall
highgui.h:#define CV_STDCALL __stdcall
ml.h:
Chris
On Thu, May 28, 2009 at 10:50 PM, Chris Colbert wrote:
> Just to clarify, I've never used keyword arguments with this function.
> Chris
>
> On Thu, May 28, 2009 at 10:46 PM, Chris Colbert wrote:
>>
>> Robert,
>> That's correct. Of course I had to r
I think because he was cross compiling these extensions for windows
while working in MacOSX or Linux
On Wed, Jun 10, 2009 at 10:30 AM, Lisandro Dalcin wrote:
> Just a couple of comments/questions regarding Windows, an OS I really
> do not know well :-)...
>
> 1) Why did you need Wine?
>
> 2) Why d
to code like this:
>
>
> # foo.pyx
>
> cdef int Foo_count = 0
>
> cdef class Foo:
>
>def __cinit__(self):
>global Foo_count
>Foo_count += 1
>
>
>
>
> On Tue, Jun 2, 2009 at 1:36 PM, Chris Colbert wrote:
> > you have to de
you have to declare the attribute as public.
http://docs.cython.org/docs/extension_types.html
Cheers,
Chris
On Tue, Jun 2, 2009 at 11:17 AM, Juha Salo wrote:
> Unfortunately that didn't seem to work. I got the following error after the
> change:
> >>> a = Foo()
> Traceback (most recent call l
I never mind being corrected/updated/put-in-my-place with such a great
answer.
So there you have it :)
Cheers!
On Mon, Jun 1, 2009 at 3:09 PM, Dag Sverre Seljebotn <
da...@student.matnat.uio.no> wrote:
> Chris Colbert wrote:
> > python strings are automagically converted to
python strings are automagically converted to char* by cython.
You can also look at a wrapper i'm building for the OpenCV library.
cython-opencv at google code.
Chris
On Mon, Jun 1, 2009 at 6:38 AM, Amit Sethi wrote:
>
> hi ,
> I guess this needs to go on cython-users but i did not see any such
Just to clarify, I've never used keyword arguments with this function.
Chris
On Thu, May 28, 2009 at 10:46 PM, Chris Colbert wrote:
> Robert,
> That's correct. Of course I had to remove all the checks related to Keyword
> args in the body of the function before it would exec
obert Bradshaw <
rober...@math.washington.edu> wrote:
> On May 28, 2009, at 9:16 AM, Chris Colbert wrote:
>
> > Alright, I "fixed" the problem by hacking the Cython generated C file.
> >
> > I removed everything in the IF clause that determined whether the
>
Alright, I "fixed" the problem by hacking the Cython generated C file.
I removed everything in the IF clause that determined whether the Python
Arguments were keyword argument or not and left only the PyTuple_GET_ITEM
statements.
I then changed the PyMethodDef line like so:
old entry: {__Pyx_NAM
Many of the numpy functions (dot in particular) already execute as compiled
C extensions. Functions that execute mostly in Python (histogramdd for
example) can see a speedup by using Cython. That said, you would be better
off building numpy from source against lapack and atlas, this will give you
t
. I'll try that next if we can't figure this out.
Cheers,
Chris
On Thu, May 28, 2009 at 1:29 AM, Lisandro Dalcin wrote:
> On Thu, May 28, 2009 at 2:00 AM, Chris Colbert
> wrote:
> >
> > So, I think I've ruled out a compiler issue. Any pointers on where to
> l
I should note in the last code example, I manually change the integer and
the recompile. i.e. the python arguments passed to the function are
irrelevant.
Chris
On Thu, May 28, 2009 at 1:00 AM, Chris Colbert wrote:
> I think I'm starting to narrow it down.
>
> I made the fo
I think I'm starting to narrow it down.
I made the following python extension module by hand and it works. I can
pass any value (0, 1, 2, or 3) to the function exttest.test() in python and
they all work properly.
#- exttest.c -#
#include "Python.h"
#include "highg
Dag,
I've listed the code below and added the memory cleanup to the Cython file.
Behavior is the same.
#---the pure C code which doesnt crash---#
#include "highgui.h"
#include "cv.h"
#include "cxcore.h"
#include "cxtypes.h"
int main(void)
{
IplImage* img, *img2;
img = cvLoad
n Wed, May 27, 2009 at 3:09 PM, Chris Colbert
> wrote:
> > Lisandro,
> >
> > Unfortunately, I'm on a windows machine and thus can't use valgrind.
> >
>
> Wow... Well, not in a good position to help you... Anyway, Did you
> build OpenCV with
I agree, I think a Cython-users is a great idea.
You all have a been a great help to me in learning Cython, but I feel
horrible having to ask such newbie questions all the time, and fear I will
one day wear out my welcome.
So +1 for a Cython-users list.
Chris
On Wed, May 27, 2009 at 3:54 PM, Da
>
>
> Quick note: By linker bug I really meant a bug in your make system, not in
> the linker itself :-) But I guess that's how you interpreted it.
>
> Dag Sverre
>
> ___
>
Here is a pure cython example that exhibits the same behavior. The cimports
are
> a) Boil down the Cython code as much as possible. Make sure a simple cdef
> function with no Python types or operations exhibit the crash.
> b) Open the generate C file and replace the body of said cdef function
> with the code that works.
> c) If that doesn't work, it's likely a linker bug, stra
we can't figure it out here.
Do you think posting the Cython generated code will help?
Cheers!
Chris
On Wed, May 27, 2009 at 12:21 PM, Lisandro Dalcin wrote:
> On Wed, May 27, 2009 at 1:03 PM, Chris Colbert
> wrote:
> > I've never used valgrind before. Any pointers?
&
ython code for that function and I
cant see anything wrong. You have any ideas I could try?
Thanks!
Chris
On Wed, May 27, 2009 at 10:49 AM, Lisandro Dalcin wrote:
> On Wed, May 27, 2009 at 11:36 AM, Chris Colbert
> wrote:
> > sometimes the docs are a bit dated. But nonetheles
stants in Cython code (likely in some pxd), you can do this:
>
> cdef extern from :
>
>enum: CV_INTER_NN
>enum: CV_INTER_LINEAR
>enum: CV_INTER_AREA
>enum: CV_INTER_CUBIC
>
>
>
> On Wed, May 27, 2009 at 12:57 AM, Chris Colbert
> wrote:
> &
So I'm wrapping the OpenCV library in Cython and its coming along quite
nicely (thanks to everyone here for getting me up to speed!), but today I've
run across a strange issue where a wrapped function fails for certain values
of integer arguments, but a pure c implementation testing the same thing
cdef c_cxcore.CvArr* handle(IplImage)
/* .pxy */
cdef class CvArr:
cdef c_cxcore.CvArr* handle(self):
return self.dummyptr
On Fri, May 22, 2009 at 12:20 PM, Chris Colbert wrote:
> alright I figured it out.
>
> Lisandro, your method worke
alright I figured it out.
Lisandro, your method worked perfect. the problem was in my function
prototype in the .pxd file.
I had to change it to this (fixed the argument types):
/* .pxd ***/
cimport c_cxcore
cimport c_highgui
cdef class CvArr:
cdef c_cxcore.CvArr* handle(CvA
e 1062 in cyopencv.c */
__pyx_1 = __Pyx_Import(__pyx_kp_cy_cxcore, ((PyObject *)__pyx_t_1)); if
(unlikely(!__pyx_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 2;
__pyx_clineno = __LINE__; goto __pyx_L1_error;}
I don't know why its saying the object is unlikely the right type..
9 at 11:05 AM, Chris Colbert wrote:
> Ok, I get what your saying. that's a good idea and I think it's a little
> cleaner than casting during the call.
>
> Thanks!
>
> Chris
>
>
> On Fri, May 22, 2009 at 10:17 AM, Lisandro Dalcin wrote:
>
>> On Fri, May
Ok, I get what your saying. that's a good idea and I think it's a little
cleaner than casting during the call.
Thanks!
Chris
On Fri, May 22, 2009 at 10:17 AM, Lisandro Dalcin wrote:
> On Fri, May 22, 2009 at 1:49 AM, Chris Colbert
> wrote:
> > is 'handle()' a
lol, OK thanks!
Just for my own education which parts of this will translate to C and which
will remain Python after Cython compilation?
Chris
> Worse:
>
> def exposedPythonFunc(image):
> if isinstance(image, IplImage):
>c_lib.cFunction((image).thisptr)
> elif isinstance(ima
so if I have:
cdef class IplImage:
cdef c_lib.IplImage* thisptr
cdef class CvMat:
cdef c_lib.CvMat* thisptr
then I can just do this?
def exposedPythonFunc(image): where image can be an IplImage or CvMat
c_lib.cFunction(image.thisptr) since I know thisptr exists
o
;def c_CvArr* handle(self):
> return self.image
>
> cdef class CvMat(CvArr):
>cdef c_CvMat *cvmat
>def c_CvArr* handle(self):
> return self.cvmat
>
>
> Mmm... just a use case for "cdef properties" managed by calling
> get/setters in t
ssing, casting, or void pointers
I would greatly appreciate any insight one could give..
Thanks and Cheers!
Chris
On Thu, May 21, 2009 at 7:05 PM, Chris Colbert wrote:
> I have certain functions that should accept types of IplImage or CvMat
>
> I have the two types declared as inh
I have certain functions that should accept types of IplImage or CvMat
I have the two types declared as inheriting from a generic CvArr as such
cdef class CvArr:
cdef void* thisptr
cdef class IplImage(CvArr):
.
cdef class CvMat(CvArr):
and a function declared like
Hi,
I'm trying to write a wrapper for a C library.
The C header from which I am making declaration has this:
struct Foo
{
int blah;
union
{
int Bar;
} data;
}
can this be wrapped in Cython?
I've tried:
cdef extern from "c.h":
ctypedef struct Foo:
want to be able to do, is have all of my multiple .pyx and .pxd files
compiled and built into a single .pyd
Is that possible?
Chris
On Wed, May 20, 2009 at 8:35 PM, Greg Ewing wrote:
> Chris Colbert wrote:
>
> > Is there a way to properly compile everything into a single .pyd,
>
&
Ok, so compiling each .pyx file into an individual .pyd worked.
Is there a way to properly compile everything into a single .pyd, or should
I create a dummy module at the end that imports each individual module when
called from python?
Chris
___
Cython-
Hi,
I have this definition file:
cy_cvtypes.pxd #
cimport c_cxcore
cimport c_highgui
cdef class IplImage:
cdef c_cxcore.IplImage* thisptr
cdef int needs_free
###
and the corresponding implementation:
cy_cvtypes.pxy ##
cimport c_cxcore
cimpo
of reference count mechanism? If it do, you sould rely on
> that to implement Image.__dealloc__() ... If not, how do you track
> ownership of your C handles in a pure-C code ??
>
>
> On Tue, May 19, 2009 at 11:42 PM, Chris Colbert
> wrote:
> >
> >
> >
Any chance that cvQueryFrame() returns an image that you should not
> free??
>
> that's exactly it (i feel really dumb for having missed it)
>
> the first img is likely garbage-collected. Perhaps your
> Image.__dealloc__ is not doing the right thing in this case?
would you suggest setting a pri
oops, sorry, I wrote the wrong things (it's getting late : )
i'm actually erring on this
# typdef
cdef class CvCapture:
cdef c_highgui.CvCapture* thisptr
# convienience functions
def queryFrame(self):
# get and return an IplImage from from a capture source
Lisandro,
Once again, thank you!
I think I finally have a tricky question for you now however:
I have the OpenCV IplImage class wrapped as so:
cdef class IplImage:
cdef c_cxcore.IplImage* thisptr
#Convienience Functions
def show(self):
#
erhaps follow option 2, I mean, define some
> factory @classmethod's you call from Python side to create images from
> the many sources...
>
>
>
>
> On Tue, May 19, 2009 at 6:22 PM, Chris Colbert
> wrote:
> > True, but it seems a little "off" to prog
I know that Cython does an implicit conversion from char* to Python string,
but do I need to somehow specify the length of the string?
I ask because I have a data buffer of known size (7854000 bytes uint8) but
when i pass the pointer to that buffer into python, my string length is only
4617.
this
>
> Once you get used to code
> Cython, and assuming you have some C/C++ background, I bet you will
> stop using ctypes ;-) ..
>
I think you are right :). In an afternoon, I've got a decent amount of what
I need wrapped :)
Cheers!
Chris
___
Cython-dev
1 - 100 of 125 matches
Mail list logo
