timedata-org / old-timedata

Time arts data - high-performance color processing in C++ and Python.
7 stars 3 forks source link

Reorganize directories. #65

Closed rec closed 8 years ago

rec commented 8 years ago

https://github.com/rec/tada/issues/64 https://github.com/rec/tada/issues/61

rec commented 8 years ago

I need to do this now, because grepping through the source directory now gets mostly generated file hits.

Sketching it out:

build/
    genfiles/
        timedata/
            color/ 
                color.gen.pyx
src/
    cpp/
        timedata/
            color/
                color.h
    pyx/
        timedata/
            color/
                wrapper.pyx
                color.template.pyx
    py/
        timedata_test/
        timedata_build/

Yes, the Python is now buried. I'm still debating this point, to be honest, and I'll do that last. I am expecting to play with PYTHONPATH and/or sys.path to make this work.

rec commented 8 years ago

https://groups.google.com/forum/#!topic/cython-users/OSN7j7LaDS4

rec commented 8 years ago

And the idea is that even grepping from src/ would give useful results, or else you could dig down one directory to get "all of one type of source" - but never see generated files in any case.

rec commented 8 years ago

And one more comment - because this screws up most git tools to some extent, I want to make sure we have just one rename and we can keep this naming strategy forever.

There is already talk of a Javascript interface, and having separate hierarchies for each language and for generated files seems to be the only way to really keep this from going crazy in the future!

adammhaile commented 8 years ago

Javascript interface?? Oh wait... that was me. Damnit :P

On Fri, Jun 24, 2016 at 1:18 PM, Tom Swirly notifications@github.com wrote:

And one more comment - because this screws up most git tools to some extent, I want to make sure we have just one rename and we can keep this naming strategy forever.

There is already talk of a Javascript interface, and having separate hierarchies for each language and for generated files seems to be the only way to really keep this from going crazy in the future!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rec/timedata/issues/65#issuecomment-228406126, or mute the thread https://github.com/notifications/unsubscribe/AA6a6hnvu-99qFVcMyAjDTxzsvtxsh8Nks5qPBF9gaJpZM4I0vXv .

ChrisBarker-NOAA commented 8 years ago

A suggestion:

I'm still not sure what your goals are, but you should probably start with a python package structure in mind, then go from there.

https://packaging.python.org/en/latest/distributing/

With Cython, it's easiest to keep your cyton files (Pyx) in line with the python package structure, so, for a simple package:

project_dir/
    setup.py
    README
    etc, etc....
    package/
        __init__.py
        a_module.py
        a_cython_module.pyx  

yes, this does mean that cython is going to dump its generated C code in that pacakge dir :-( -- but that's not SO bad, is it?

and if you want to keep your cython separate from your python (which you might if this is big), you can do something like:

    package/
        __init__.py
        a_module.py
        cy_modules/
            __init__.py
            a_cython_module.pyx
            b_cython_module.pyx 

then put imports into that top level init.py so you can get the code from one place.

rec commented 8 years ago

:-) Too late!

But actually, for the moment I have a very flat hierarchy defined - right now there are six rather featureful generated classes, Color, Color255 and Color256, and then ColorList, ColorList255, ColorList256, all in the timedata namespace.

In the future we're likely to deprecate either the 255 or the 256 depending on response, but then there will be other color models - ColorHSV, ColorYIV, etc. and then other types of data entirely. We'll probably organize these as if they are in fact in different namespaces but they're all generated from the same significantly smaller body of code.

So it's all organized using (C++ style) include and not (Python-style) import.

rec commented 8 years ago

Oh, and thanks for the input! At some point I'll be going back to doing more Pythonic stuff and not just "one big blob of very neat code" and now I know how...

ChrisBarker-NOAA commented 8 years ago

So it's all organized using (C++ style) include and not (Python-style) import.

Well, just know that you'll be swimming upstream with python...

But whatever works...

-CHB

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rec/timedata/issues/65#issuecomment-228913597, or mute the thread https://github.com/notifications/unsubscribe/AA38YBu5jnZSdtTYTtSvJIXOm8IUYl1Cks5qQGejgaJpZM4I0vXv .