On Wed, May 27, 2009 at 1:03 PM, Chris Colbert <[email protected]> wrote:
> I've never used valgrind before. Any pointers?
>

Just run

$ valgrind python somescript.py

You may get a lot of junk warnings because of Python's mem allocator
implementation. There is a way to suppress them,

$ valgrind --suppressions=/path/to/valgrind-python.supp python somescript.py

You may have valgrind-python.supp installed somewhere (from package
python-devel), for example, in my Fedora 10 box, it is at.

/usr/share/doc/python-devel-2.5.2/valgrind-python.supp

Perhaps a good idea (I'm doing that) is to add an executable shell
script in your $HOME/bin (assuming that dir in on $PATH), like this:

$ cat $HOME/bin/valgrind-py
#!/bin/sh
valgrind --suppressions=$HOME/lib/valgrind-python.supp $@

Then I run Python under Valgrind like this:

$ valgrind-py python somescript.py

You could even modify the script to add 'python' before the $@, I do
not do that just because I want to use it against many Python
versions. But perhaps this is not an issue for you.



> I went back to the Cython generated C source and explicitly included the
> appropriate header file and explicitly passed CV_INTER_LINEAR (defined as 1)
> to the C function call. Same story, it crashes.
>
> I've gone line by line now through the Cython 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 <[email protected]> wrote:
>>
>> On Wed, May 27, 2009 at 11:36 AM, Chris Colbert <[email protected]>
>> wrote:
>> > sometimes the docs are a bit dated. But nonetheless, those constants are
>> > just integers defines in the header files and is where I got the values
>> > 0-4,
>> > I used the integers in the example just to make it a bit more clear. But
>> > 0-4
>> > are valid constants for the call, as they worked in the pure C example.
>>
>> Mmm... they I have no idea what's going on... Did you try to run under
>> valgrind? That usually works for me...
>>
>> > What you showed for exposing the constants however, is interesting, I
>> > have
>> > been just defining the constants as module level python integers so they
>> > can
>> > be used from python. If defined as an enum as you show, will they
>> > be accessible from python?
>> >
>>
>> No, you have to explicitly expose them. If you declared them in some
>> pxd, let say "mycvdefs.pxd", you can write in "mycvmodule.pyx"
>>
>> CV_SOME_CONSTANT = mycvdefs.CV_SOME_CONSTANT
>>
>>
>>
>>
>>
>> > Chris
>> >
>> > On Wed, May 27, 2009 at 9:40 AM, Lisandro Dalcin <[email protected]>
>> > wrote:
>> >>
>> >> According to the docs,
>> >>
>> >>
>> >> http://opencv.willowgarage.com/wiki/CvReference#Sampling.2CInterpolationandGeometricalTransforms,
>> >> There are 4 possible values (you mention 5). Is that OpenCV
>> >> documentation dated? IMHO, you should use them. To expose these
>> >> constants 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 <[email protected]>
>> >> 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
>> >> > with the same arguments works.
>> >> > Here is the code excerpts im using:
>> >> > #---------- .pyx ------------------#
>> >> > def cvResize(cy_cvtypes.CvArr src, cy_cvtypes.CvArr dst,
>> >> > interpolation):
>> >> >     cdef c_cxcore.CvArr* c_src = src.handle()
>> >> >     cdef c_cxcore.CvArr* c_dst = dst.handle()
>> >> >     cdef int c_interpolation = interpolation
>> >> >     with nogil:
>> >> >         c_cv.cvResize(c_src, c_dst, c_interpolation)
>> >> > #-------- c_cv.pxd -----------------#
>> >> > cdef extern from "cv.h":
>> >> >     void cvResize(CvArr* src, CvArr* dst, int interpolation) nogil
>> >> >
>> >> > #--------- test.py -----------------#
>> >> > from cyopencv import *
>> >> > if __name__=='__main__':
>> >> >     img = cvLoadImage('2.bmp')
>> >> >     img2 = cvCreateImage((640, 480), img.depth, img.nChannels)
>> >> >     cvResize(img, img2, 3)
>> >> >     img2.show()
>> >> >
>> >> >
>> >> > #--------- pureC.c -----------#
>> >> > #include "highgui.h"
>> >> > #include "cv.h"
>> >> > #include "cxcore.h"
>> >> > #include "cxtypes.h"
>> >> > int main(void)
>> >> > {
>> >> >     IplImage* img, *img2;
>> >> >     img = cvLoadImage("2.bmp", 1);
>> >> >     img2 = cvCreateImage(cvSize(640, 480), img->depth,
>> >> > img->nChannels);
>> >> >     cvResize(img, img2, 3);
>> >> >     cvNamedWindow("test", 1);
>> >> >     cvShowImage("test", img2);
>> >> >     cvWaitKey(0);
>> >> >     cvDestroyAllWindows();
>> >> >     cvReleaseImage(&img);
>> >> >     cvReleaseImage(&img2);
>> >> > }
>> >> >
>> >> >
>> >> > valid integers for the argument 'interpolation' are 0, 1, 2, 3, 4 (as
>> >> > tested
>> >> > with the C function). My Cython wrapper fails with a Python crash for
>> >> > integer values 1 & 2.  Values of 0,1,4 work properly and the output
>> >> > image
>> >> > matches the output image of the C test function under the same
>> >> > conditions.
>> >> > I've looked at the generated Cython code and everything seems in
>> >> > order,
>> >> > I
>> >> > just can't think of what could be causing this behavior.
>> >> > Any thoughts?
>> >> > Cheers!
>> >> > Chris
>> >> >
>> >> > _______________________________________________
>> >> > Cython-dev mailing list
>> >> > [email protected]
>> >> > http://codespeak.net/mailman/listinfo/cython-dev
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Lisandro Dalcín
>> >> ---------------
>> >> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>> >> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>> >> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>> >> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>> >> Tel/Fax: +54-(0)342-451.1594
>> >> _______________________________________________
>> >> Cython-dev mailing list
>> >> [email protected]
>> >> http://codespeak.net/mailman/listinfo/cython-dev
>> >
>> >
>> > _______________________________________________
>> > Cython-dev mailing list
>> > [email protected]
>> > http://codespeak.net/mailman/listinfo/cython-dev
>> >
>> >
>>
>>
>>
>> --
>> Lisandro Dalcín
>> ---------------
>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>> Tel/Fax: +54-(0)342-451.1594
>> _______________________________________________
>> Cython-dev mailing list
>> [email protected]
>> http://codespeak.net/mailman/listinfo/cython-dev
>
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
>
>



-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to