Hi there, I am also not a developer but leaving a few more comments in the code might already help a lot.
I tried to make sense of a few things and I saw very little annotations/comments, which made it quite hard to understand what was going on. Just as an example, the function that calculates the bin height in the histogram starts its loop at 4 instead of 0 in some cases and there is unfortunately no explanation in the code for that :/ Similarly, the name of a function is not always enough to explain what it does and a comment could help a lot to explain what functions such as dt_histogram_max_helper() and dt_histogram_helper() do. @Paul: Do you think that adding more comments would cover at least some of your concerns regarding maintainability? Best, Jan On 07.06.21 16:02, johannes hanika wrote: > thanks moritz. > > and btw i was really very happy to hear about openexr being ported to c :) > > i share the maintainability concerns, so at some point i took some > time for an experiment and rewrote parts of dt in vulkan/glsl > (https://github.com/hanatos/vkdt <https://github.com/hanatos/vkdt>). > sorry but if anything it's even more c than the original. but yes, > fresh rewrites are always easy to make very clean.. but all the ifdefs > for architectures etc will come back in a mature product, don't worry. > at least i tried to remove all unnecessary dependencies (glib, gtk, > ..) and processing language layers (i386, sse/avx, openmp, opencl). > > cheers, > jo > > > On Sun, Jun 6, 2021 at 7:10 PM Moritz Moeller <virtualr...@gmail.com > <mailto:virtualr...@gmail.com>> wrote: > > Hello Paul. > > You raise some good points imho. > > However, what I am replying to here is solely the suggestion of > using C++. > > You may of course choose to ignore my reply as I'm not a DT developer. > I do have 25+ years of professional experience writing software for > image processing/generation though. Most of it in C++. So maybe I'm > worth listening to. > > Before I start: I think the choice of C was excellent one of > Johannes – > at the time. > > Today I would probably choose Rust for any sort of > refactoring/architecture/API improvements of any C code base I can > think > of. Including that of DT. > > C++ – I do not even know where to start how bad an idea I'd > consider that. > > But to add some context: There is an ongoing effort from people in > the > Academy of Motion Pictures Software Association (ASWF) to expose all > functionality as C APIs. > One reason is that all the libs ASWF hosts will be wrapped in safe > Rust > APIs. > What's more: core OpenEXR, just for example, is just being > refactored in > C (current codebase is C++). > > These are people relying on such software like OIIO, OCIO, OSL, > etc. to > generate millions of images for motion pictures and series. They are > turning their backs on C++. It's early days but ... go figure. > > My suggestion would be: make a nice, safe RUst API to allow people > writing modules in that language. > > Then, if people really feel the need, refactor DT, bit by bit, > into Rust. > Starting with the most hard to read parts of the codebase that > someone > new may want to contribute to. > > > Just my two c. > > Beers, > > .mm > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
