[sane-devel] Ubuntu drivers for HP Scanjet Professional 3000

[nel...@coltrack.com]

Hello someone can send me the drivers for a HP Scanjet Professional 3000 
scanner, please...
 
Best Regards
 
 
Nelson 
 
Bogota Colombia-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] [janitorial] leading whitespace: spaces XOR tabs

[m. allan noah]

1. I routinely use git blame to find out when I changed some line of
code. A massive whitespace commit would wreck that. Yes, there are
other ways to get that info after such a cleanup, but I'm lazy :)

2. I've read a great deal of other people's code over the years, and I
am generally stumped by their logic and lack of comments. Whitespace
is rarely a concern, even when they used a weird layout.

3. There are patches floating around in private repos that may not
apply cleanly after such a change.

Given those, I'm inclined to leave maintained backends untouched. For
unmaintained backends, it certainly makes sense to do such
reformatting when a bugfix is done. Doing it beforehand is
questionable, I don't feel strongly either way. I suppose cleaning up
the unmaintained backends makes it slightly easier for a new
maintainer to step into the code.

allan

On Wed, Jul 12, 2017 at 9:35 AM, Gerhard Jäger  wrote:
> Hi Olaf,
>
> On 12.07.2017 at 14:33 Olaf Meeuwissen wrote:
>>
>> Hi all,
>>
>> I just committed the last compiler warning fixes and made the Debian 9
>> builds "AWARE".  Now any compiler warnings on all 4 Debian builds will
>> bomb the build in question and hence prevent the creation of a new
>> snapshot tarball.
>>
>> I mentioned[1] that the plustek-pp backend's indenting defied me but
>> after some staring at the code I realized it was using a four spaces to
>> the tab convention.  Convincing my editor to do the same made it a lot
>> easier to understand the intended behaviour but fixing the "mess" was
>> still a very delicate affair.  I had to change the mixed use of spaces
>> and tabs used to indent to *exactly* match in order to silence compiler
>> warnings.
>>
>>   [1]
>> https://lists.alioth.debian.org/pipermail/sane-devel/2017-June/035445.html
>
>
> [...]
>
> I obviously ignored you - sorry for that. And yes, I did follow at these old
> days my own rules, not using tabs, but 4 spaces - in an inconsistent way.
> Sorry - 'twas a long time ago ;)
>
>> This whole exercise has made me look at the whole code base in a little
>> more detail and, quite frankly, the use of leading whitespace is a total
>> and utter mess.  Some places are better of than others but on the whole
>> it's pretty pathetic.
>>
>> # Just make your editor visually distinguish spaces and tabs and you'll
>> # see.  I used Emacs' whitespace-mode (in its default configuration) and
>> # it "lit up the place" in a variety of colours.
>>
>> So here's a few "rules" I'd like to apply in order to address this.
>> Each file
>
> [...]
>>
>> # Personally, I would much prefer to uses spaces everywhere the file
>> # format permits (with a minor execption for files used by make, see
>> # above) over the board.
>> # You may find the following blog post of interest ;-)
>> #
>> #
>> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
>>
>> If anyone objects, I'm open to suggestions, including "Why bother? Just
>> use spaces!" ;-)
>>
>> If I hear nothing, the tools/style-check.sh script will be modified to
>> implement these rules and can then be use to check for any "violations"
>> and (recursively) fix them.
>
>
> Are you sure you want to rework the whole code base? Is it a good idea?
> Well maybe for unmaintained backends, but what about the others? In fact
> I have here some long pending patch (64 bit awareness) that most probably
> no longer apply.
>
> Just my two cents,
>  Gerhard
>
> BTE: Thanks for caring anyhow.
>
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-requ...@lists.alioth.debian.org



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] [janitorial] leading whitespace: spaces XOR tabs

[Gerhard Jäger]

Hi Olaf,

On 12.07.2017 at 14:33 Olaf Meeuwissen wrote:

Hi all,

I just committed the last compiler warning fixes and made the Debian 9
builds "AWARE".  Now any compiler warnings on all 4 Debian builds will
bomb the build in question and hence prevent the creation of a new
snapshot tarball.

I mentioned[1] that the plustek-pp backend's indenting defied me but
after some staring at the code I realized it was using a four spaces to
the tab convention.  Convincing my editor to do the same made it a lot
easier to understand the intended behaviour but fixing the "mess" was
still a very delicate affair.  I had to change the mixed use of spaces
and tabs used to indent to *exactly* match in order to silence compiler
warnings.

  [1] https://lists.alioth.debian.org/pipermail/sane-devel/2017-June/035445.html


[...]

I obviously ignored you - sorry for that. And yes, I did follow at these old
days my own rules, not using tabs, but 4 spaces - in an inconsistent way.
Sorry - 'twas a long time ago ;)


This whole exercise has made me look at the whole code base in a little
more detail and, quite frankly, the use of leading whitespace is a total
and utter mess.  Some places are better of than others but on the whole
it's pretty pathetic.

# Just make your editor visually distinguish spaces and tabs and you'll
# see.  I used Emacs' whitespace-mode (in its default configuration) and
# it "lit up the place" in a variety of colours.

So here's a few "rules" I'd like to apply in order to address this.
Each file

[...]

# Personally, I would much prefer to uses spaces everywhere the file
# format permits (with a minor execption for files used by make, see
# above) over the board.
# You may find the following blog post of interest ;-)
#
#  
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

If anyone objects, I'm open to suggestions, including "Why bother? Just
use spaces!" ;-)

If I hear nothing, the tools/style-check.sh script will be modified to
implement these rules and can then be use to check for any "violations"
and (recursively) fix them.


Are you sure you want to rework the whole code base? Is it a good idea?
Well maybe for unmaintained backends, but what about the others? In fact
I have here some long pending patch (64 bit awareness) that most probably
no longer apply.

Just my two cents,
 Gerhard

BTE: Thanks for caring anyhow.

--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org

[sane-devel] [janitorial] leading whitespace: spaces XOR tabs

[Olaf Meeuwissen]

Hi all,

I just committed the last compiler warning fixes and made the Debian 9
builds "AWARE".  Now any compiler warnings on all 4 Debian builds will
bomb the build in question and hence prevent the creation of a new
snapshot tarball.

I mentioned[1] that the plustek-pp backend's indenting defied me but
after some staring at the code I realized it was using a four spaces to
the tab convention.  Convincing my editor to do the same made it a lot
easier to understand the intended behaviour but fixing the "mess" was
still a very delicate affair.  I had to change the mixed use of spaces
and tabs used to indent to *exactly* match in order to silence compiler
warnings.

 [1] https://lists.alioth.debian.org/pipermail/sane-devel/2017-June/035445.html

This whole exercise has made me look at the whole code base in a little
more detail and, quite frankly, the use of leading whitespace is a total
and utter mess.  Some places are better of than others but on the whole
it's pretty pathetic.

# Just make your editor visually distinguish spaces and tabs and you'll
# see.  I used Emacs' whitespace-mode (in its default configuration) and
# it "lit up the place" in a variety of colours.

So here's a few "rules" I'd like to apply in order to address this.
Each file

 - uses either spaces or tabs for *all* of its leading whitespace
   This is *not* on a per line basis, this applies to the *whole* file.
 - if using tabs, these tabs may be followed by up to 7 spaces
   This is to accommodate n-space indent policies (where n mod 8 != 0)
   and assumes eight spaces to the tab.
 - if using tabs, uses eight spaces to the tab
 - if to be used by `make`, an initial whitespace character shall be
   a tab, independent of whether its on a continuation line or not

Note, this says absolutely nothing about whitespace use after the first
non-whitespace.  That can still be a mess.

The "rules" above are inspired by a combination of consistency, ease of
checking/fixing and giving developers some leeway in applying their own
preferences to their code.

Whether to use spaces or tabs for each file will be decided on the basis
of a count of tabs and spaces (and in case of doubt comparison with any
related files so as to keep some kind of consistency between them).  The
criterion will be a majority of one over the other (taking into account
the number of spaces to a tab).  So, with n spaces to the tab, the
larger value of n*number_of_leading_tabs and number_of_leading_spaces
will decide the leading whitespace policy for a file.

# Personally, I would much prefer to uses spaces everywhere the file
# format permits (with a minor execption for files used by make, see
# above) over the board.
# You may find the following blog post of interest ;-)
#
#  
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

If anyone objects, I'm open to suggestions, including "Why bother? Just
use spaces!" ;-)

If I hear nothing, the tools/style-check.sh script will be modified to
implement these rules and can then be use to check for any "violations"
and (recursively) fix them.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org