For point of comparison, my branch now has a Cython and C++ version of
the same thing.
Here's the Cython version:
https://github.com/mdboom/matplotlib/blob/no_cxx/src/_png.pyx
Here's the C++ version:
https://github.com/mdboom/matplotlib/blob/no_cxx/src/_png_wrap.cpp
Some interesting things t
On 12/1/12 12:36 PM, Michael Droettboom wrote:
> I was really hoping by creating this experiment
> that a Cython expert would step up and show the way ;)
There are a lot more Cython experts on the Cython mailing list ;).
Thanks,
Jason
---
Including the Cython-generated C in the tarballs and optionally the git
repository as well can certainly be considered to reduce the need for
Cython for developers and users alike. However, the Cython source
should also be included in the repository for the inevitable times when
it does need t
On Sat, Dec 1, 2012 at 12:28 PM, Michael Droettboom wrote:
> Ok. I'll go ahead and put the workaround in our .travis.yml. Any
> active pull requests that we want to have good Travis results for will
> need to be rebased to get the workaround.
That's better than having no testing at all for Pyth
For the PNG extension specifically, it was creating callbacks that can
be called from C and the setjmp magic that libpng requires. I think
it's possible to do it, but I was surprised at how non-obvious those
pieces of Cython were. I was really hoping by creating this experiment
that a Cython
Ok. I'll go ahead and put the workaround in our .travis.yml. Any
active pull requests that we want to have good Travis results for will
need to be rebased to get the workaround.
Mike
On 11/30/2012 06:20 PM, Damon McDougall wrote:
> Forwarding to list again...
>
>
> -- Forwarded messag
Drat, re-sending on the list.
On 1 December 2012 16:40, Thomas Kluyver wrote:
> On 1 December 2012 14:44, Michiel de Hoon wrote:
>
>> At the same time, to minimize errors, we could use Cython to create the
>> initial Python/C glue code, and then add the generated code to the
>> matplotlib codeb
I'm +1 on Cython. I think its prevalence in the community gives us a larger
potential contributor pool than CXX or hand-coded python C-API. I know using
Cython would open up that part of the code base for me.
Ryan
On Dec 1, 2012, at 8:44, Michiel de Hoon wrote:
>
> In my experience, Benjami
In my experience, Benjamin is right that the C code is rarely touched. This is
even more true for the Python/C glue code, at least from my experience with the
Mac OS X backend. Since the Python/C glue code is modified only very rarely,
there may not be a need for regenerating the Python/C glue
On 12/01/2012 02:32 AM, Benjamin Root wrote:
>
>
> Since when has numpy used Cython? I specifically remember a rather
> involved discussion thread on numpy-discussion about the pros-and-cons
> of including cython. Now, SciPy on the other hand, does utilize Cython
> in some spots IIRC, but does
>> > One package (Pysam) that I use a lot relies on Cython, and requires
>> > users to install Cython before they can install Pysam itself. With Cython,
>> > is that always the case? Will all users need to install Cython? Or is it
>> > sufficient if only matplotlib developers install Cython?
>>
>>
11 matches
Mail list logo
