On Jun 29, 2009, at 5:45 AM, Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> On Jun 27, 2009, at 1:02 AM, Dag Sverre Seljebotn wrote: >> >>> Just a quick note that in the gsoc-kurt branch I've implemented >>> this: >>> >>> from UtilityCode import CythonUtilityCode >>> >>> ... >>> env.use_utility_code(foo) # only on env. currently, not code. >>> >>> >>> foo = CythonUtilityCode(u""" >>> >>> class __Pyx_UtilClass: >>> pass >>> >>> cdef int __Pyx_UtilityFunction(int arg): >>> return arg * 2 >>> >>> """) >>> >>> Now, this will cause __Pyx_UtilityFunction to be dumped into the >>> final C >>> file, and the type descriptor to be called __Pyx_UtilClass (i.e. >>> name >>> mangling is dropped in some important cases). >>> >>> The details might change around a bit, this is just a note to say >>> I've >>> done it, so that noone else starts on something similar. >> >> I'm not opposed to this. >> >> Eventually we may want to consider grouping such code into a central >> Cython module, or at least .h file (for multi-file compilation) as >> there is a lot of redundancy between modules with all the utility >> code produced. > > The same thoughts did indeed occur to me. However it is strictly > orthogonal to this -- utility code written in C has the same problem.
Yes, completely orthogonal, but it's a related idea that I had in my head so I figured I'd throw it out there. > And we can just set up another pipeline to have Cython dump such an .h > file from existing utility code declarations. (Another completely > orthogonal thing would be to move utility code to resource files for > easier editing.) > > As for whether it should be done -- do you know if e.g. Sage builds > are > IO bound? Not sure, but that's certainly a big component. > If not then a header file itself won't help, you need to > change the build (seperately compiled .c file, or preprocessed header > files). Even if it's IO bound, writing to a single .h file rather than to all 300 .c files should make a difference. Same with the .c compiler reading (the single .h file will be "hot"). > A "Cython standard library" Python module is an interesting thought, > however I think the versioning problems are too big at the moment. I'm certainly viewing something re-built every time alongside the .c files to skirt that issue (in the short term at least). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
