Re: coreutils-{6,7} will not compile on AIX 6.1

[Jim Meyering]

"Jeremy Olexa"  wrote:
> New subscriber here and I would like to get some help with this issue
> on AIX 6.1.
>
> Here is the relevant code snippet:
> depbase=`echo getloadavg.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> powerpc-ibm-aix6.1.0.0-gcc -std=gnu99  -I.  -g -O2 -MT
> getloadavg.o -MD -MP -MF $depbase.Tpo -c -o getloadavg.o getloadavg.c
> &&\
> mv -f $depbase.Tpo $depbase.Po
> In file included from /usr/include/sys/corral.h:25,
>  from /usr/include/libperfstat.h:28,
>  from getloadavg.c:410:
> /usr/include/netinet/in6_var.h:65: error: array type has incomplete element 
> type
> make[4]: *** [getloadavg.o] Error 1
>
>>From my research I have found that the line 65 in in6_var.h is a
> invalid type for gcc (maybe as of gcc-4 or newer - not exactly sure).
> Line 65 is:
> extern  CONST struct protosw inet6sw[];

Thanks for the report.
AIX 6.1 appears to have libperfstat, so is using this code:

# if defined HAVE_LIBPERFSTAT
#  include 
#  include 
#  ifndef SBITS
#   define SBITS 16
#  endif
# endif

>From the looks of that diagnostic, some new header should
be included before one of those two, in order to get the
declaration of "struct protosw".

Please see if there is a man page for libperfstat.
It may tell which headers must be included there.
Once we know that we should be able to fix it.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] remove duplicate inclusion of

[Jim Meyering]

No big deal, but...

Ok, Bruno?


>From 24cb49400d1349f29f745e74979b5ce45022288f Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Sun, 30 Nov 2008 17:08:33 +0100
Subject: [PATCH] remove duplicate inclusion of 

---
 tests/test-fprintf-posix.c   |1 -
 tests/test-printf-posix.c|1 -
 tests/test-snprintf-posix.c  |1 -
 tests/test-sprintf-posix.c   |1 -
 tests/test-vasprintf-posix.c |1 -
 tests/test-vfprintf-posix.c  |1 -
 tests/test-vprintf-posix.c   |1 -
 tests/test-vsnprintf-posix.c |1 -
 tests/test-vsprintf-posix.c  |1 -
 9 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/tests/test-fprintf-posix.c b/tests/test-fprintf-posix.c
index 12e57fe..be65079 100644
--- a/tests/test-fprintf-posix.c
+++ b/tests/test-fprintf-posix.c
@@ -22,7 +22,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-printf-posix.c b/tests/test-printf-posix.c
index d90fd42..04705e8 100644
--- a/tests/test-printf-posix.c
+++ b/tests/test-printf-posix.c
@@ -21,7 +21,6 @@
 #include 

 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-snprintf-posix.c b/tests/test-snprintf-posix.c
index 4c095ed..eee434f 100644
--- a/tests/test-snprintf-posix.c
+++ b/tests/test-snprintf-posix.c
@@ -22,7 +22,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-sprintf-posix.c b/tests/test-sprintf-posix.c
index 2f69252..be35fe1 100644
--- a/tests/test-sprintf-posix.c
+++ b/tests/test-sprintf-posix.c
@@ -22,7 +22,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-vasprintf-posix.c b/tests/test-vasprintf-posix.c
index f8314f4..2f287fc 100644
--- a/tests/test-vasprintf-posix.c
+++ b/tests/test-vasprintf-posix.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-vfprintf-posix.c b/tests/test-vfprintf-posix.c
index 262ba17..deb3e37 100644
--- a/tests/test-vfprintf-posix.c
+++ b/tests/test-vfprintf-posix.c
@@ -22,7 +22,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-vprintf-posix.c b/tests/test-vprintf-posix.c
index 441551f..766749f 100644
--- a/tests/test-vprintf-posix.c
+++ b/tests/test-vprintf-posix.c
@@ -22,7 +22,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-vsnprintf-posix.c b/tests/test-vsnprintf-posix.c
index 00c8006..23f3be2 100644
--- a/tests/test-vsnprintf-posix.c
+++ b/tests/test-vsnprintf-posix.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tests/test-vsprintf-posix.c b/tests/test-vsprintf-posix.c
index ba6d813..959412f 100644
--- a/tests/test-vsprintf-posix.c
+++ b/tests/test-vsprintf-posix.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--
1.6.1.302.gccd4d


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: pathchk info page should mention other leading brand

[jidanni]

OK, but I would still say "By portability we are not talking about
portability to other operating systems!"


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] remove duplicate inclusion of

[Jim Meyering]

Jim Meyering  wrote:
> No big deal, but...
...
>  tests/test-fprintf-posix.c   |1 -
>  tests/test-printf-posix.c|1 -
>  tests/test-snprintf-posix.c  |1 -
...

I've just reposted this to bug-gnulib.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Jim Meyering]

"Vitali Lovich"  wrote:
> I've read the proposed patches that have been batted around on the mailing
> list (after coming up with my own implementation :D of course).  My proposed
> solution is less generic, but I believe more robust, than the other
> approaches.
>
> I've proposed my reasoning below, but I've posted it as a bug on launchpad
> to track this issue 313152 .  The
> patch is against 6.10 instead of trunk mainly because I was too lazy to get
> the build-system set up on Ubuntu.  That being said, I'm pretty sure the
> patch should still work against the trunk.  In any case, if it's necessary,
> I could also do the diff against the trunk.
>
> Code review?
> What would I need to do to get this mainlined (aside from adding the
> documentation changes)?
>
> REASONING:
>
> One of my major assumption is that all the numbers are well formatted.
>
> In other words, there's an explicit demarcation in the number line (at least
> internal to the input being sorted) after which the suffix increases and the
> number starts again near 0.  For instance, if M represents 1050 Kilobytes,
> then there's no 1051K - it's represented as 1.001M or something along those
> lines.  Again, this would only rely on the input being internally consistent
> - sort needs no knowledge or hints of what those suffixes represent.

Thanks for the patch and for writing up your assumptions.

The above requirement is key... and perhaps too restrictive.
I.e., it makes it sound like your sort could mishandle
sizes printed by a mix of output from du -h and du --si runs,
not to mention numbers generated manually or by other tools.

However, this assumption might be acceptable (other opinions welcome),
on the condition that the code behind this option diagnoses any violation.

One of the first tasks for getting such an option into upstream is
to describe and reach agreement on what the input grammar should be.
I.e., is the "Gi" suffix allowed?  What about "GB" and "GiB"?
If "Gi" is allowed, is it treated differently from "G"?

As to what else would be required, see the guidelines in HACKING.
E.g., you'd need to add many tests of this new feature.

> Also, there can be no exponential numbers when in this mode mainly because
> it's unclear whether an `E' represents the beginning of the exponent or an
> exabyte.  Since both would be uncommon as use cases.  Exabytes are really

That sounds reasonable.

> really big right now, and exponents would be meaningless since they could
> only be used for extremely small numbers or numbers that are bigger than a Y
...


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: pathchk info page should mention other leading brand

[Jim Meyering]

Pádraig Brady  wrote:
...

Thanks!  That looks fine.
Minor nits in log message:

>>From fbe9201e5e2812bfc112ea05c317b194c98bb4f9 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?P=C3=A1draig=20Brady?= 
> Date: Sun, 4 Jan 2009 01:06:10 +
> Subject: [PATCH] doc: pathchk description enhancements
>
> * doc/coreutils.text (pathchk invocation): Mention pathchk

s/text/texi/

> checks validity (for current system) as well as portability.
> Say messages go to stderr, and reorder description of checks
> done for the -p option, to match that done in code.

s/that/(those|what's)/

> * src/pathchk.c (usage): Mention pathchk checks name validity.
> Suggested clarifications were from Dan Jacobson.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Sun, Jan 4, 2009 at 5:35 AM, Jim Meyering  wrote:
>
> "Vitali Lovich"  wrote:
>
> Thanks for the patch and for writing up your assumptions.
>
> The above requirement is key... and perhaps too restrictive.
> I.e., it makes it sound like your sort could mishandle
> sizes printed by a mix of output from du -h and du --si runs,
> not to mention numbers generated manually or by other tools.
Well as I stated in the assumptions - as long as the numbering is
internally consistent, my tool will handle this case.  However,
there's no tool that can really handle a mix of output from du -h & du
--si in the same stream, since there would be no way to identify when
the suffix represents 1000 & when it represents 1024.  Any solution
for this would have to have support for rule-based ways of figuring
out (i.e. every other line or all lines after the 5th) - but this is
obviously far too complicated for a tool like sort.  That use case
would require the use of far more complicated shell scripts to get the
correct behavior (although I'm unconvinced that this represents even
an uncommon use case).

The only behavior I'm insure of right now is when there are spaces
separating the suffix & the number.  Currently, the implementation
takes the first letter after the number ignoring spaces - which I just
realized is the incorrect behavior.  I'm thinking the suffix has to
follow the number immediately (no spaces) and have a space after it.
There's all sorts of ways that additional configuration options could
be added (i.e. support for spacing between # & suffix), but I'm
thinking that those use cases are better handled by having the user
write that logic in awk or whatever (i.e. my_utility | awk '{print
$3$4}' | sort -h if there are spaces between the suffix & number).

>
> However, this assumption might be acceptable (other opinions welcome),
> on the condition that the code behind this option diagnoses any violation.
>
> One of the first tasks for getting such an option into upstream is
> to describe and reach agreement on what the input grammar should be.
> I.e., is the "Gi" suffix allowed?  What about "GB" and "GiB"?
> If "Gi" is allowed, is it treated differently from "G"?
The current grammar is the letter [K, M, G, T, P, E, Z, Y] following
the number with no space (I'm going to patch the fix for the spacing
issue as soon as I get some free time).  My reasoning is that at least
with support for this sorting option, all the other use cases become
trivial through the use of other utilities.  Want GiB?  Simply pass
the output through sed and replace GiB with G.  I would do this, but,
especially with C-strings, it's much trickier to do the string &
comparison, and I'm unconvinced (but easily persuaded ;D) about the
utility of supporting more complicated suffix representations.

>
> As to what else would be required, see the guidelines in HACKING.
> E.g., you'd need to add many tests of this new feature.
Ok - I'll read over that document - I missed it the first time around.

Thanks for the feedback.
Vitali


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Sun, Jan 4, 2009 at 5:35 AM, Jim Meyering  wrote:

> However, this assumption might be acceptable (other opinions welcome),
> on the condition that the code behind this option diagnoses any violation.

Sorry - I missed responding to this part in the previous e-mail.
Could you please clarify - what violation is the code supposed to
diagnose?  There's really no way to do so because my implementation
doesn't attempt to understand the input that it's being given: garbage
in, garbage out.  Since my implementation doesn't know how you've
defined your suffixes, so it can't really say - error - you're trying
to use a suffix, but the number line has a demarcation at 1024.  For
instance, maybe to make it nicer to display, you make 0.8 the
demarcation of when to switch to using the next suffix e.g. 800 KB/s
is actually represented as 0.8MB/s.

However, I could look at adding an option (probably not a short option
because it's use should also be discouraged since it's a debugging
flag) that would allow the user to specify the size of suffixes (i.e.
each additional suffix is an additional multiplication by 1024).
However, this would make things slightly more complicated because then
that number would have to be converted to a string to be compared
against both strings in human_compare (to avoid the issues of
converting a string to a number).  This is a trivial feature - is this
what you were thinking of (and once detected, perhaps after the sort
print some kind of warning/error that the input was not internally
consistent)?.

On a side note - additional human-based units (i.e. KB/s) could be
trivially supported through the use of sed (something along the lines
of `| sed 's/KB\/s/K/' | sort -h | sed 's/K/KB\/s/'`, but more
generic).


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Sun, Jan 4, 2009 at 4:30 PM, Vitali Lovich  wrote:
> On Sun, Jan 4, 2009 at 5:35 AM, Jim Meyering  wrote:
>>
>> "Vitali Lovich"  wrote:
>>
>> Thanks for the patch and for writing up your assumptions.
>>
>> The above requirement is key... and perhaps too restrictive.
>> I.e., it makes it sound like your sort could mishandle
>> sizes printed by a mix of output from du -h and du --si runs,
>> not to mention numbers generated manually or by other tools.
> Well as I stated in the assumptions - as long as the numbering is
> internally consistent, my tool will handle this case.  However,
> there's no tool that can really handle a mix of output from du -h & du
> --si in the same stream, since there would be no way to identify when
> the suffix represents 1000 & when it represents 1024.  Any solution
> for this would have to have support for rule-based ways of figuring
> out (i.e. every other line or all lines after the 5th) - but this is
> obviously far too complicated for a tool like sort.  That use case
> would require the use of far more complicated shell scripts to get the
> correct behavior (although I'm unconvinced that this represents even
> an uncommon use case).
>
> The only behavior I'm insure of right now is when there are spaces
> separating the suffix & the number.  Currently, the implementation
> takes the first letter after the number ignoring spaces - which I just
> realized is the incorrect behavior.  I'm thinking the suffix has to
> follow the number immediately (no spaces) and have a space after it.
> There's all sorts of ways that additional configuration options could
> be added (i.e. support for spacing between # & suffix), but I'm
> thinking that those use cases are better handled by having the user
> write that logic in awk or whatever (i.e. my_utility | awk '{print
> $3$4}' | sort -h if there are spaces between the suffix & number).
Sorry - my mistake.  I misremembered the implementation I wrote.  My
code requires the suffix to follow the number immediately.  I'm adding
an additional check to ensure that there is a space after the suffix,
and as soon as my desktop gets an internet connection (sometimes
wifi-only sucks :D), I'll upload it to launchpad (do people here mind,
or is it better form if I post the patches to the mailing list?)

Vitali


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Vitali Lovich on 1/4/2009 3:41 PM:
> I'll upload it to launchpad (do people here mind,
> or is it better form if I post the patches to the mailing list?)

I'd much rather review an inline patch sent via this list than fire up my
browser (or use wget in a terminal) to go hunting for the patch.  Not to
mention that the list archives are easier to browse when all patches go
through the list.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklhQrgACgkQ84KuGfSFAYALjACgo9Am6BHbdVarm2UUTbLEPv4s
yPAAnRl9K+EafYGP83llMMFhynf91xBi
=8MOl
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: pathchk info page should mention other leading brand

[Pádraig Brady]

jida...@jidanni.org wrote:
> OK, but I would still say "By portability we are not talking about
> portability to other operating systems!"

OK, I just pushed the previous patch with the additional
tweak of amending "portable file name character set" to
"POSIX portable file name character set".

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Jim Meyering]

"Vitali Lovich"  wrote:
...
> I'll upload it to launchpad (do people here mind,
> or is it better form if I post the patches to the mailing list?)

Please post change-sets to this mailing list.
To keep ubuntu folks in the list, you could give them
a link to this mailing list thread:

  http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15464


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Support in sort for human-readable numbers

[Vitali Lovich]

Will do.  I'm probably going to pick-up an intel wireless card
tomorrow, so I'll be able to get the latest patch off of my desktop.

On Mon, Jan 5, 2009 at 1:04 AM, Jim Meyering  wrote:
> "Vitali Lovich"  wrote:
> ...
>> I'll upload it to launchpad (do people here mind,
>> or is it better form if I post the patches to the mailing list?)
>
> Please post change-sets to this mailing list.
> To keep ubuntu folks in the list, you could give them
> a link to this mailing list thread:
>
>  http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15464
>


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils