Re: [PATCH] circular buffer + hash for jobs.c:bgpids
On 4/17/15 4:55 PM, John Fremlin wrote: Did some benchmarks, for the while true; do (:) (:); done simple example this goes from 215 to 313 iterations/s, and changes sys+user CPU from 152% to 45% Any long running bash script will tend to exhibit this issue -- I disagree that `any' long-running bash script will create thousands of asychronous jobs and never call `wait' with no arguments. It's not clear that your example above is realistic. Let's see what happens with your patch to change bash to save statuses of asynchronous jobs instead of all jobs before we see whether another change is warranted. Thanks for your work investigating this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: read() returns positive numbers in BSD systems, which make: bash / valid.
On 4/17/15 2:43 PM, Eduardo A. Bustamante López wrote: In the BSDs, doing a read on a directory doesn't return a negative value. Thanks for the investigation and report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: associative arrays and [[ -v
On 4/17/15 6:45 PM, isabella parakiss wrote: This seems the way to go, but I'm not sure I understand why: $ declare -A arr=([a]=b) $ [[ -v arr['$var'] ]]; echo $? 1 $ declare -A arr=(['*']=x) $ [[ -v arr['$var'] ]]; echo $? 0 What's happening? Well, as I said before, `*' is special: it expands to all elements of the array, in the same way as $*. So you have to protect it through all word expansions. First, each word in the conditional expression is expanded as described in the manual page tilde expansion, parameter and variable expansion, arithmetic expansion, command substitution, process substitution, and quote removal are performed. That leaves the word as 'arr[$var]' (without the quotes, of course). The subscript in an associative array reference also undergoes expansions, the same ones as the rhs of an assignment statement (pretty much the same as above). That expands the $var, leaving arr[*]. Since the check for `*' or `@' as a subscript happens before expansion, the shell looks for the `*' as an element of the array. In the first case, it doesn't find it; in the second, it does. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [Help-bash] make function local
On 4/17/15 6:27 PM, Linda Walsh wrote: Eduardo A. Bustamante López wrote: Well, if your scripts are so simple, why use local functions at all? --- Cleanliness, Hygiene... Please, let's not have this argument again. I think you're all using the term `local function' to mean different things. You seem to be using the term to describe one-time-use functions (they're almost lambdas, but they have names). If you define a function within another function's body, have it unset itself when it executes, and call it only from within the function where it's defined, you have something very close to one-time-use functions with function-only scope. However you use them, they share the name namespace as every other defined function, regardless of whether or not they are defined as part of the body of another function. If you had a function defined in the global scope with the same name as your one-time-use function, it would be removed when the one-time-use function was declared. I think this is what Greg and Eduardo mean, and in this sense they are correct: bash doesn't have local functions with separate namespaces from other defined functions. That's the difference: if you're careful with naming and rigorous about your calling conventions, your one-time-use functions are about as close as you can get to local functions in bash, but you have to pay attention to the declaration's side effects. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: readline-6.3: update config.h.in
On 4/19/15 2:00 PM, Andreas Schwab wrote: The config.h.in file in the standalone readline distribution is missing a lot of templates. It should really be generated by autoheader. --- readline-6.3/config.h.in.~1~ 2012-01-18 16:22:13.0 +0100 +++ readline-6.3/config.h.in 2015-04-19 19:39:13.215290092 +0200 @@ -6,6 +6,14 @@ #undef _FILE_OFFSET_BITS +#undef __EXTENSIONS__ +#undef _ALL_SOURCE +#undef _GNU_SOURCE +#undef _POSIX_SOURCE +#undef _POSIX_1_SOURCE +#undef _POSIX_PTHREAD_SEMANTICS +#undef _TANDEM_SOURCE + Readline configure.ac doesn't call AC_USE_SYSTEM_EXTENSIONS. Maybe it should, but until it does, these should probably not be changed from whatever the build system defines them. /* Define if the `S_IS*' macros in sys/stat.h do not work properly. */ @@ -71,6 +81,12 @@ /* Define if you have the mbrtowc function. */ #undef HAVE_MBRTOWC +/* Define if you have the mbscmp function. */ +#undef HAVE_MBSCMP + +/* Define if you have the mbsnrtowcs function. */ +#undef HAVE_MBSNRTOWCS + /* Define if you have the mbsrtowcs function. */ #undef HAVE_MBSRTOWCS @@ -118,6 +134,9 @@ /* Define if you have the wcscoll function. */ #undef HAVE_WCSCOLL +/* Define if you have the wcsdup function. */ +#undef HAVE_WCSDUP Readline doesn't actually call any of these functions, and even though BASH_CHECK_MULTIBYTE tests for them, it doesn't matter whether or not it finds them. #undef HAVE_GETPW_DECLS -#undef STRUCT_DIRENT_HAS_D_INO +#undef HAVE_STRUCT_DIRENT_D_INO -#undef STRUCT_DIRENT_HAS_D_FILENO +#undef HAVE_STRUCT_DIRENT_D_FILENO These have already been changed, thanks. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
readline-6.3: update config.h.in
The config.h.in file in the standalone readline distribution is missing a lot of templates. It should really be generated by autoheader. --- readline-6.3/config.h.in.~1~2012-01-18 16:22:13.0 +0100 +++ readline-6.3/config.h.in2015-04-19 19:39:13.215290092 +0200 @@ -6,6 +6,14 @@ #undef _FILE_OFFSET_BITS +#undef __EXTENSIONS__ +#undef _ALL_SOURCE +#undef _GNU_SOURCE +#undef _POSIX_SOURCE +#undef _POSIX_1_SOURCE +#undef _POSIX_PTHREAD_SEMANTICS +#undef _TANDEM_SOURCE + /* Define if on MINIX. */ #undef _MINIX @@ -27,6 +35,8 @@ #undef PROTOTYPES +#undef __PROTOTYPES + #undef __CHAR_UNSIGNED__ /* Define if the `S_IS*' macros in sys/stat.h do not work properly. */ @@ -71,6 +81,12 @@ /* Define if you have the mbrtowc function. */ #undef HAVE_MBRTOWC +/* Define if you have the mbscmp function. */ +#undef HAVE_MBSCMP + +/* Define if you have the mbsnrtowcs function. */ +#undef HAVE_MBSNRTOWCS + /* Define if you have the mbsrtowcs function. */ #undef HAVE_MBSRTOWCS @@ -118,6 +134,9 @@ /* Define if you have the wcscoll function. */ #undef HAVE_WCSCOLL +/* Define if you have the wcsdup function. */ +#undef HAVE_WCSDUP + /* Define if you have the wctype function. */ #undef HAVE_WCTYPE @@ -244,9 +263,9 @@ #undef HAVE_GETPW_DECLS -#undef STRUCT_DIRENT_HAS_D_INO +#undef HAVE_STRUCT_DIRENT_D_INO -#undef STRUCT_DIRENT_HAS_D_FILENO +#undef HAVE_STRUCT_DIRENT_D_FILENO #undef HAVE_BSD_SIGNALS -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Multiple patches to fix compiler warnings
On 4/17/15 2:03 PM, Eduardo A. Bustamante López wrote: 0001-Fix-spacing-issues-in-tests-to-make-it-easier-to-tra.patch 0002-Fix-unclosed-double-quote.patch 0004-Fix-declare-regression.patch 0003-Remove-compiler-warnings.-Does-that-really-need-to-b.patch 0005-Make-the-compiler-happy-remove-volatile.patch 0006-Remove-unused-variables-and-functions-make-CFLAGS-Wa.patch 0007-Make-the-compiler-happy.patch Thanks, I'll take a look. In these cases, I want the `volatile' there, even if it causes warnings, since I'm not really interested in whether the function takes a volatile parameter -- I want the compiler's guarantees about volatile variables in the function where they're declared. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [Help-bash] make function local
Hi Chet,
Eduardo A. Bustamante López wrote:
Well, if your scripts are so simple, why use local functions at all?
---
Cleanliness, Hygiene...
Please, let's not have this argument again. I think you're all using the
term `local function' to mean different things.
You seem to be using the term to describe one-time-use functions (they're
almost lambdas, but they have names). If you define a function within
another function's body, have it unset itself when it executes, and call
it only from within the function where it's defined, you have something
very close to one-time-use functions with function-only scope.
However you use them, they share the name namespace as every other defined
function, regardless of whether or not they are defined as part of the body
of another function. If you had a function defined in the global scope
with the same name as your one-time-use function, it would be removed when
the one-time-use function was declared. I think this is what Greg and
Eduardo mean, and in this sense they are correct: bash doesn't have local
functions with separate namespaces from other defined functions.
That's the difference: if you're careful with naming and rigorous about
your calling conventions, your one-time-use functions are about as close
as you can get to local functions in bash, but you have to pay attention
to the declaration's side effects.
There is at least a runtime overhead for having too many unused
functions that are supposed to be local or in your word lambda.
Despite that one can rename supposedly internal functions to names
that are unlikely to cause name collision via good naming convention,
it still can incur a significant performance overhead.
In this sense, I think that it is still necessary to consider make the
supposedly internal function local so that they would not slow down
function search in the global namespace.
~$ cat main_many.sh
#!/usr/bin/env bash
n=$1
for i in $(seq -w $n)
do
eval function f$i { echo '$i'; }
done
function g {
for i in $(seq -w $n | head -n 1000)
do
f$i /dev/null
done
}
time g
~$ ./main_many.sh 1000
real 0m0.032s
user 0m0.020s
sys 0m0.010s
~$ ./main_many.sh 1
real 0m0.040s
user 0m0.029s
sys 0m0.011s
~$ ./main_many.sh 10
real 0m0.490s
user 0m0.461s
sys 0m0.031s
--
Regards,
Peng
