What kind of language limitations (if any) do we want to place on implementations??
i.e. Do we want to standardize how we will implement the functionality in the Image Kit or are we free to use whatever tools we are familiar with? Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only? I guess this kind of similar to the discussion on dependencies, but still maybe deserves its own attention... Cheers, Chris
On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert <sccolbert@gmail.com> wrote:
i.e. Do we want to standardize how we will implement the functionality in the Image Kit or are we free to use whatever tools we are familiar with?
Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only?
Code already exists in scikits.image which depends on Cython. Damian
would you mind pointing it out to me? I scanned through the entire source tree here: http://github.com/stefanv/scikits.image but didn't see anything... Sorry if I'm just not seeing it.... -Chris On Sun, Oct 4, 2009 at 12:33 AM, Damian Eads <eads@soe.ucsc.edu> wrote:
On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert <sccolbert@gmail.com> wrote:
i.e. Do we want to standardize how we will implement the functionality in the Image Kit or are we free to use whatever tools we are familiar with?
Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only?
Code already exists in scikits.image which depends on Cython.
Damian
I attended the scikits.image sprint and we agreed to let Cython be dependency. At the sprint, I wrote integral image and morphology code available, which is available here http://github.com/deads/scikits.image/tree/master/scikits/image/filter/ http://github.com/deads/scikits.image/tree/master/scikits/image/morphology/ Stefan has been trying to get me to merge it back in but I haven't had the time to figure out how to do this with GIT. Damian On Sat, Oct 3, 2009 at 11:38 PM, Chris Colbert <sccolbert@gmail.com> wrote:
would you mind pointing it out to me?
I scanned through the entire source tree here: http://github.com/stefanv/scikits.image
but didn't see anything...
Sorry if I'm just not seeing it....
-Chris
On Sun, Oct 4, 2009 at 12:33 AM, Damian Eads <eads@soe.ucsc.edu> wrote:
On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert <sccolbert@gmail.com> wrote:
i.e. Do we want to standardize how we will implement the functionality in the Image Kit or are we free to use whatever tools we are familiar with?
Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only?
Code already exists in scikits.image which depends on Cython.
Damian
-- ----------------------------------------------------- Damian Eads Ph.D. Candidate University of California Computer Science 1156 High Street Machine Learning Lab, E2-489 Santa Cruz, CA 95064 http://www.soe.ucsc.edu/~eads
2009/10/4 Chris Colbert <sccolbert@gmail.com>:
Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only?
Like Damian mentioned, we had a discussion on this at the sprint and decided that Cython is a good way to go for optimising extensions. I am a bit allergic to C++ (especially given the compiler mess it has caused in SciPy), so unless we have a very good reason I'd prefer to stick to C. I'd be very glad if someone could provide a robust setup.py file to automatically build Cython extensions! Setuptools and Cython don't play all that nicely together, and setuptools changed its output directories for .so files during in-place builds when using Python 2.6. Since I'm on the topic of build systems: we may just as well put the infrastructure in place now to build with scons + numscons, David Cournapeau's new build system for NumPy and SciPy. Cheers Stéfan
On 3-Oct-09, at 7:54 PM, Stéfan van der Walt wrote:
Like Damian mentioned, we had a discussion on this at the sprint and decided that Cython is a good way to go for optimising extensions. I am a bit allergic to C++ (especially given the compiler mess it has caused in SciPy), so unless we have a very good reason I'd prefer to stick to C.
It should be noted that Cython needn't be a *dependency*, as such. Release tarballs can include the generated C files and thus not require Cython to build. I think this is ideal to make it easy to build from source but not tether developers to writing in raw C all the time. David
participants (4)
-
Chris Colbert -
Damian Eads -
David Warde-Farley -
Stéfan van der Walt