Re: Regression in development version of bash w.r.t. associative hashes

2013-05-06 Thread Stefano Lattarini 
On 05/06/2013 10:00 PM, Chet Ramey wrote:
> On 5/3/13 5:48 AM, Stefano Lattarini wrote:
>> [+cc bug-gnulib, see below for a reason]
>>
>> Minimal reproducer of the regression:
>>
>>   $ cat foo.bash
>>   echo "$BASH_VERSION"
>>   declare -A hash
>>   echo ${hash[a/b]}
>>   echo $?
>>
>>   $ /bin/bash foo.bash
>>   4.2.45(1)-release
>>
>>   0
>>
>>   $ ~/bleeding/bin/bash foo.bash
>>   4.3.0(1)-alpha
>>   foo.bash: line 3: a/b: division by 0 (error token is "b")
>>   1
>>
>> Notice that the new behaviour breaks the gnulib-tool script
>> (that's how I noticed this regression).
> 
> You're just not bleeding-edge enough. :-)
> 
> That problem was fixed several weeks ago as part of the ongoing cleanup
> of `invisible placeholder' variables (variables with attributes but no
> values, which are technically unset).
>
Indeed, I had forgotten to "git pull". Everything seems to work fine with
the latest 'devel' branch.

Thanks, and sorry for the noise,
  Stefano

Re: Regression in development version of bash w.r.t. associative hashes

2013-05-06 Thread Chet Ramey 
On 5/3/13 5:48 AM, Stefano Lattarini wrote:
> [+cc bug-gnulib, see below for a reason]
> 
> Minimal reproducer of the regression:
> 
>   $ cat foo.bash
>   echo "$BASH_VERSION"
>   declare -A hash
>   echo ${hash[a/b]}
>   echo $?
> 
>   $ /bin/bash foo.bash
>   4.2.45(1)-release
> 
>   0
> 
>   $ ~/bleeding/bin/bash foo.bash
>   4.3.0(1)-alpha
>   foo.bash: line 3: a/b: division by 0 (error token is "b")
>   1
> 
> Notice that the new behaviour breaks the gnulib-tool script
> (that's how I noticed this regression).

You're just not bleeding-edge enough. :-)

That problem was fixed several weeks ago as part of the ongoing cleanup
of `invisible placeholder' variables (variables with attributes but no
values, which are technically unset).

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: Development version of bash is very slow in running autoconf-generated scripts

2013-05-06 Thread Stefano Lattarini 
On 05/06/2013 12:33 PM, Andreas Schwab wrote:
> Stefano Lattarini  writes:
> 
>> Four times slower, yikes.  Any idea where these numbers might be coming
>> from?
> 
> Try building without debugging options (make DEUBG= MALLOC_DEBUG=)
>
Thanks!  This solved the issue (after s/DEUBG/DEBUG/).  So it was a
PEBKAC after all :-)

Best regards,
  Stefano

Re: Development version of bash is very slow in running autoconf-generated scripts

2013-05-06 Thread Andreas Schwab 
Stefano Lattarini  writes:

> Four times slower, yikes.  Any idea where these numbers might be coming
> from?

Try building without debugging options (make DEUBG= MALLOC_DEBUG=)

Andreas.

-- 
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."

Development version of bash is very slow in running autoconf-generated scripts

2013-05-06 Thread Stefano Lattarini 
Compared with Bash 4.2, the development version of bash is very slow
in running autoconf-generated configure scripts (or, to be more
precise, that's where I noticed the slowness; it might very well be
more generalized, but I haven't checked for that).

Some numbers:

  $ /bin/bash -c 'echo "$BASH_VERSION"'
  4.2.45(1)-release

  $ time CONFIG_SHELL=/bin/bash /bin/bash \
  >   ./configure CONFIG_SHELL=/bin/bash
  ...
  real  1m10.935s
  user  0m29.738s
  sys   0m12.669s


  $ $HOME/bleeding/bin/bash -c 'echo "$BASH_VERSION"'
  4.3.0(1)-alpha
  $ time CONFIG_SHELL=$HOME/bleeding/bin/bash $HOME/bleeding/bin/bash \
  >   ./configure CONFIG_SHELL=$HOME/bleeding/bin/bash
  ...
  real  4m45.671s
  user  4m22.744s
  sys   0m17.753s


Four times slower, yikes.  Any idea where these numbers might be coming
from?

Regards,
  Stefano