[darktable-dev] heads-up : delicate changes in master
Hi, Just a note that I'll merge three PRs very soon (in the coming hours) that are a bit tricky but will bring a new feature and remove an old hack specific to the lens correction module. The new code will add support for: - Copy/Paste of default/auto-init parameters https://github.com/darktable-org/darktable/pull/13450 - Create/Edit/Apply style with default/auto-init parameters https://github.com/darktable-org/darktable/pull/13492 - Migrate legacy lens hack in styles to default/auto-init parameters https://github.com/darktable-org/darktable/pull/13504 An auto-init parameters is a parameter which has a default depending on the image it is applied. For example color-calibration (needs WB from camera), lens (needs maker/lens). There is already support in master for presets that are auto- initialized: https://github.com/darktable-org/darktable/pull/13432 The three PRs above extend this to copy/paste, style and clean-up of a hack. So, now you're warned, if something goes wrong do not hesitate to report on GitHub. And only use the master version if you have proper backup or ready to work on some degraded environment. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://photos.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://photos.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Code reformatting...
On 01.02.23 06:13, Bruce Guenter wrote: On Mon, Jan 23, 2023 at 11:19:52PM +0100, Pascal Obry wrote: This has nothing to do with display size. Do you know why news paper has small columns? Because it is faster to read, that is, the time to go from the end of line to the start of the new is far easier if the width is not too large. Actually, that's a bit of an urban legend. Actually, it isn't. I studied typography and worked professionally in the field for a decade. Just take my word for it. :) Newspapers have small columns because wider columns have more unused space, which means less space for other features and, most importantly, advertisements. I dunno how newspapers entered this. Take any book, scientific publication, etc. They all stick to this rules despite the complete lack of advertising space constraints. Recent studies point to reading speed going up as line lengths increase, though the effect is not huge. https://www.usability.gov/get-involved/blog/2006/08/line-length-and-onscreen-reading.html I call that BS until you show me a meta-study with overall non-contestable sample size and age distribution. 20 college students? Yeah, right. I would say there isn't a bigger age bias to be had than that. And the sample size ... let's not go there. ;) Beers, .mm ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Code reformatting...
On 01.02.23 23:04, Mark Feit wrote:
I don't contribute code to darktable often, but I do follow this list
closely and feel the need to comment on this. Take it or leave it as
you wish.
Dito. Let me just clarify some perceived misunderstandings re. my
previous comments. :)
The darktable source code isn't prose and isn't consumed like it. I can
all but guarantee that formatting it according to _all_ of the rules for
typesetting text and forcing people to work with it would result in a
lot of screaming.
That's sad and if it were true I'd consider it rather as an indicator of
what could improved than a counter argument to what I said.
Google 'code as prose'. ;)
A great example is the source to the 'Physically Based Rendering' book(s).
See https://practicaltypography.com/line-length.html
From that page:
"If you plan to use indenting to distinguish sections or hierarchies
within your document, take this into account when setting up the initial
line length. [...]
I agree, this is important.
A good code formatter will have option to make sure that foremost the
part of the line after the indentation counts towards the line length
and the indentation either not at all or by some some function of its width.
Modernity doesn't really make a difference here. Rust didn't invent
bringing a formatter along with the language and it certainly didn't
introduce forced formatting for commits.
I don't recall saying it did in either instance so I'm not sure why you
mentioned this.
Nor what difference to the validity of what I said it would make in
regards of whether language X or Y was first or shipped a formatter as
part of the default toolchain (which is pretty much non-existent for C/C++).
Formatting for comments is off by default in rustfmt btw.
Most C does just fine constrained to 80. Most parts of darktable I've
browsed through probably would, too. But... In 35 years of writing C
and seeing C code in the wild, I've run into code bases where formatters
constrained to short lines made them awkward and difficult to read.
Constraining darktable's C code base to whatever length some other code
base in some other language uses as standard is dogma-driven design and
it's not helpful.
I think Rust and C are very comparable in this regard indeed. After
almost 35 years of C, 25 of C++ and three of Rust I feel eligible to be
opinionated here. :)
Especially since Rust encourages heavy code reuse through crates
('libs') and it is common practice to not omit the namespace when using
such imported functions/types/methods.
I.e. the 'identifiers may be somewhat long' issue is not uncommon in
Rust code as well.
The pragmatic approach would be to find something that works for *this*
code base and *these* developers.
I didn't mean to suggest anything else. I was merely pointing out that
the reasoning Matthias used is flawed.
As I am a lurker on this list and do not have to touch C code, from
darktable or otherwise, at all or very often any more, I better shut up
now. :]
Beers,
.mm
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
