[sane-devel] Possible to rename network scanner?

Aaron Muir Hamilton aaron at correspondwith.me
Sun May 21 14:51:05 UTC 2017


Some of these misleading indentation errors also look like genuine bugs.
Here's one gem from backends/genesys_gl847.c which turned into a
misleading indent when I ran it through clang-format:

660    while (val8 & REG41_FEBUSY);
661      {
662        usleep (10000);
663        status = sanei_genesys_get_status (dev, &val8);
664      };

Pay close attention to the semicolons.

As an aside, this is probably why the 1TBS is superiour to GNU-style.


Aaron Muir Hamilton <aaron at correspondwith.me> writes:

> Olaf Meeuwissen <paddy-hack at member.fsf.org> writes:
>
>> Hi All(an),
>>
>> m. allan noah writes:
>>
>>> The fujitsu backend includes the serial number of the scanner in the
>>> device name. The users would have to memorize that number. Anything
>>> more would be a code change. The best place to make such a change
>>> would probably be in saned itself, so that all backends could benefit.
>>> Unfortunately, many backends use a dynamically generated device name,
>>> so saned might see different device names after the host reboots. So,
>>> the easiest place to solve this would likely be in the fujitsu backend
>>> itself. We could potentially replace the serial number with a
>>> user-specified device name. This requires more thought.
>>
>> I don't think this is something that should be addressed by a SANE
>> backend.  It should also not be addressed by a SANE frontend.  It should
>> be addressed by SANE, eh, "middleware".  Not unlike the sanei_* stuff
>> but not linked statically into whatever backend happens to use it.
>>
>> I've been doing Node.js web application/service development at the
>> office for the last year and in that field they also use the terms
>> frontend and backend.  At the same time, there's middleware all over
>> the place, to the point where there's middleware for middleware ;-), but
>> it all just gets sandwiched between the frontend and the backend.
>>
>> I realize that SANE "middleware" is not something we can deliver now or
>> anytime soon (seeing that the SANE 2 draft has been stuck so long that I
>> can't recall the year any more precisely than 200x) but it is something
>> that we may consider for discussion after 1.0.26 (or 1.0.27 ;-)
>>
>> # So many ideas, so little time ... but I might just start a SANE-R
>> # discussion after the release.  Solliciting ideas for the meaning of
>> # the R already!
>> # Then there's also the issue of Alioth -> GitLab.com that's been near
>> # the forefront of my mind for a while already and refuses to go away.
>> # Never even mind Fedora 26 and Debian 9 on the horizon which'll trigger
>> # a small "tsunami" of compiler warning fixes and autotools updates ...
>
> It's ugly work, but maybe it's time we normalize the formatting in some
> of the files (especially ones which are abandoned-ish and don't have
> open patches). A lot of the compiler warnings I see (I run Arch Linux,
> so I'm on bleeding-edge-ish GCC most of the time) are things like
> misleading indentation warnings. We don't need to invest in any
> infrastructure for formatting IMHO, we could just do a once-over with
> clang-format on some of the files.
>
> Just my $0.024298 CAD
>
>> # but that's all for after our upcoming sane-backends release.
>>
>> Just my two yen,
>> --
>> Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
>>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>>  Support Free Software                        https://my.fsf.org/donate
>>  Join the Free Software Foundation              https://my.fsf.org/join



More information about the sane-devel mailing list