hey, On Thu, Jan 17, 2013 at 10:12 AM, Pascal Obry <[email protected]> wrote: > > Johannes, > >> oh, also a not on module versions. >> >> first, you're including headers for separately compiled modules in the >> main compilation unit (libclipping.so and libdarktable.so have now >> some overlap). >> >> this will totally crash if a module increases it's version, changes >> the parameters, and is just copied into the /usr/lib/darktable/plugins >> directory (as it happens all the time when switching back and forth >> between git/released version). > > I'm probably missing an important design point then :( > > My thinking was that this conversion is done once based on the "current" > iop parameters. We never read them, just set them for the current iop. > > So for example take clipping.h: > >> typedef struct dt_iop_clipping_params_t >> { >> float angle, cx, cy, cw, ch, k_h, k_v; >> float kxa, kya, kxb, kyb, kxc, kyc, kxd, kyd; >> int k_type, k_sym; >> int k_apply, crop_auto; >> } >> dt_iop_clipping_params_t; > > This is the current version.
no, that's the version you compiled libdarktable.so (including lightroom.c) with. the rest of the code using clipping params will be libclipping.c, compiled separately, and every so often even coming from another version of dt (because you forgot to clean up the directory or whatever). from a design standpoints, it's just a nice thing to have code cleanly separated (you don't like cropping? delete one file!). so even though we could from a practical view just statically compile in all our modules, we don't, because it's a nice modular separation of the mess we usually create while coding. especially in an open source project with such a ton of people working on it, that's the only design point i really care about.. that features are encapsulated in self-contained files in separate compilation units as much as possible. > If a new parameter is added, it will be > added there. clipping.c will be changed to use this new parameter and > will probably bump version number: > >> DT_MODULE(4) > > Then lightroom.c will also need to be adapted. yes, but the way to make sure this happens is to at least include a check if the versions line up (and not crash in case someone forgot to clean up all relevant places). which brings be back to my original point. how do you now know/remember all the places that are affected by a parameter change in the module. not quite as simple as `all in this file only' anymore. i guess as you're in darkroom mode doing this (right?), you could just find the module and check module->version() for the hardcoded version your current code supports. that way at least it would rot gracefully :) -jo > If a parameter is removed > it will not compiled. Fine, code will be hacked. If a parameter is added > but not used by lightroom.c, no problem either as not used (no meaning > for lightroom import). > > Does that makes sense? Or did I missed something? > > -- > Pascal Obry / Magny Les Hameaux (78) > > The best way to travel is by means of imagination > > http://v2p.fr.eu.org > http://www.obry.net > > gpg --keyserver keys.gnupg.net --recv-key F949BD3B ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
