[procps] Re: backporting
- From: Sami Kerola <kerolasa@xxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 7 Dec 2011 22:52:22 +0100
On Wed, Dec 7, 2011 at 15:01, Jim Warner <james.warner@xxxxxxxxxxx> wrote:
> On Dec 7, 2011, at 7:02 AM, Sami Kerola wrote:
>> setlocale (LC_ALL, "");
>> bindtextdomain(PACKAGE, LOCALEDIR);
>> textdomain(PACKAGE);
>
> The bindtextdomain is technically optional but protects against
> non-standard install locations. Do you think ours could/should be
> controlled by a configure option rather than hard coded?
Perhaps someone has a reason to relocate locales, and letting that to
be possible does not seem to add complexity or other maintenance
burden.
>> Do you mean usage() outputs and for instance diskheader() in
>> vmstat? I would argue the usage() is fine, but headers could
>> better indeed.
>
> Most usage could be output in a single fprintf. Not only is that
> more efficient, but it's much better for the translator I should
> think.
I thought that as well, until I saw this.
https://github.com/karelzak/util-linux/commit/e0c97cdcf83c4ccda94ebd4c440cf30eb94a6f61
Knowing that the patch was wrote by translator there has to be reason
why that is preferred. Unfortunately I do not know the reason. My
guess is that smaller chunks are preferred because they tend to
change less frequently than usage as whole. Additionally my hunch is
that translating long table more tricky than a line or few at a time.
I can only guess so perhaps it is reasonable to make a full usage
table, few lines per chunk and all lines separated test.
>> True. Some guidance could help. How about getting obvious things
>> to fixed, such as the header words to strings, and then I'll do
>> Finnish translation. While doing the translation I'll try to
>> catch anything which is unclear/difficult.
>
> That's an excellent idea. Why don't you establish a Finish branch
> that I could look at too. My own testing just fudged some
> meaningless Chinese and Australian English.
I'll do that after obvious brokenness is fixed.
>>> Finally, you have inexplicably eliminated important functionality
>>> in some programs that is sure to upset numerous users.
>>
>> If I did that was unintentional. Do we have test(s) which
>> highlight such?
>
> Last time I looked, much error feedback was gone from sysctl and
> pkill provided no confirmation of success. There was some missing
> help output too, but I've lost track.
>
>> I proposed something
>> ...
>> so perhaps you could write the README patch which would indicate
>> you agree as well.
>
> Sorry Sami, but I haven't begun to analyze those suggestions and
> libabc yet. You're a hard guy to keep up with, and I'm just a
> plodder.
I recon that is good. Touching the lib now would be so brave I do not
have guts to do that, or to put that other way if we start 'fixing'
libproc-ng too early the possible outcome likely to be very confusing
and harmful mess.
I really think getting commands to up to date (no known bugs), and
flushing everyone's change buffers to empty before touching the lib is
a requirement. Otherwise we end up shooting moving targets which is
bound to be difficult.
> One thing I will try to protect is Albert's investment in
> the library and ps. That represents an effort beyond most folks
> ability.
>
> I'll try to begin that analysis.
Assuming we agree on refactoring the lib, changing interfaces,
documenting it all and writing unit test to all functions I am not
expecting old code to disappear. AFAIK the lib mostly work, and that
is not the problem.
The real issue is that sometimes the library surprises, I'm sure you
remember certain free() backfiring beyond anyone's expectation. That
sort of dirtiness in library will drive it's users to crazy,
especially when there is no documentation.
That said I expect the refactoring to be pretty lengthy process.
>> Having for example program_invocation_short_name dealt somewhere
>> once to me sounds much better than writing that code segment to
>> every single program file. That's essentially why headers &
>> libraries exist, right.
>
> Two lines of code would allow each program to determine its own
> name. And a future programmer doesn't have to wonder what the heck
> that obscure, lengthy variable really contains.
The variable name is lengthy indeed. It is set by glibc so I think it
is superior to two custom lines. Perhaps you are talking more about
unnecessary portability. Drawing a line somewhere, like Varnish guys
have done...
https://www.varnish-cache.org/docs/trunk/phk/platforms.html
...might be good idea. Unfortunately I don't have enough experience
about this package to do that.
>> In all honesty there are few things in `c.h' which may be subject
>> to clean up. For example TRUE & FALSE definition may not be
>> needed. I this one my thinking is that it's better to do
>> something, even it would go wrong, rather than trying to be always
>> right & perfect and get nothing done.
>
> I'll still argue strongly against using any of those util_linux
> headers. To me it makes no sense to rely on a non-standard BSD
> header extension, only to have to plug the gap if configure doesn't
> find it. It would be much easier/cleaner/simpler to fail the
> configure step with a missing *standard* header.
Again question of portability expectations while some other headers
make life easier. For example I really don't want to check malloc
every single time separately. One extreme is not to use private
libraries at all, and at other end of scale is gnulib. Somewhere in
between sounds right to me.
Thank you Jim for comments.
--
Sami Kerola
http://www.iki.fi/kerolasa/
Other related posts:
