two mysteries

two mysteries

[Ray Andrews]

Deep in my butcherings of Sebastian's code:

     START_IDX=1+((idx-1)/page_hight)*page_hight

... it will work fine for days, then one Tuesday 'START_IDX' starts 
throwing 'divide by zero' errors, and it turns out that it's been 
transmuted from an integer to a string.  There aughta be a law:

     typeset -I number ... 'number' is an integer for ever and ever.

     START_IDX=$(( 1+((idx-1)/page_hight)*page_hight ))

... fixes it, but I recall weeks back that that fix introduced other 
bugs, tho I'd not stake anything on that, and it works on Wednesdays 
anyway. But most days the variable remains an integer regardless of the 
fix. God knows why a 'divide by zero' error would be thrown when zsh 
considers the thing to be a string anyway.  If it really must convert my 
integers to strings, then tell me "You are trying to do arithmetic on a 
string, dolt".

2nd mystery:

I have this little helper, you put it into code:

    ...
    echo this
    foo='that'
    varis foo line123 5
    code
    code
    ...

Outputs:

     line123 5: evaluated: "foo" is: that

... to /dev/pts/5. It pointedly takes the variable name without any '$' 
so that the name of the variable can be reported along with it's 
'evaled' value.  Very helpful. The strange thing is that, now that I'm 
playing with associative arrays, yesterday I had to single quote:

      varis 'array[value]' line456 5

... but only with arrays--scalars were fine--or I got a message to the 
effect that 'no values were matched'. AND ... now that I get around to 
typing this the next day, the problem is gone, so I can't report the 
message :-(

As the vaguest of probably unanswerable questions, what might possibly 
have been different yesterday? Some option being changed in the 
background perhaps? I've tried keeping an eye on that, but nothing.  As 
with mystery #1 above, this must be explicable but I don't know where to 
begin looking.

In the same vein, if one of these 'zcurses' functions crashes, what the 
docs say about the terminal being in a unstable state sure is true. 
Things look fine, but, for example, history recall goes screwy.  I've 
learned to kill and restart the terminal--just restarting zsh isn't good 
enough.  It would be helpful if zcurses could report: "Please restart 
this xterm" or something. Anyway, these strange, ghostly haunted house 
things sure are bothersome. There's a skeleton buried somewhere, if I 
could find it.

Re: two mysteries

[Bart Schaefer]

On Nov 4, 10:12am, Ray Andrews wrote:
}
}      START_IDX=1+((idx-1)/page_hight)*page_hight
} 
} ... it will work fine for days, then one Tuesday 'START_IDX' starts 
} throwing 'divide by zero' errors

This would be because page_hight (sic) is zero, not because the type
of START_IDX has changed.

}      START_IDX=$(( 1+((idx-1)/page_hight)*page_hight ))
} 
} ... fixes it

I suspect not really.  Something else changed so that the "page" is
no longer empty, or whatever.

} playing with associative arrays, yesterday I had to single quote:
} 
}       varis 'array[value]' line456 5
} 
} ... but only with arrays--scalars were fine--or I got a message to the 
} effect that 'no values were matched'.

Without the quotes, array[value] is being treated as a file glob, and is
looking for a file named one of arrayv, arraya, arrayl, arrayu, arraye.
The "no matches found" error is because none of those files exists.

} In the same vein, if one of these 'zcurses' functions crashes, what the 
} docs say about the terminal being in a unstable state sure is true. 
} Things look fine, but, for example, history recall goes screwy.

"stty sane" will often fix you up in this situation.  It might also work
to use "ttyctl -f" in your startup file (i.e., before any zcurses stuff
is run) but I'm not sure that handles the case where a zsh builtin has
itself messed up the terminal state.

Re: two mysteries

[Ray Andrews]

On 11/04/2015 12:35 PM, Bart Schaefer wrote:
> This would be because page_hight (sic) is zero, not because the type
> of START_IDX has changed.

I spell it wrong on purpose.
> }      START_IDX=$(( 1+((idx-1)/page_hight)*page_hight ))
> }
> } ... fixes it
>
> I suspect not really.  Something else changed so that the "page" is
> no longer empty, or whatever.

You're probably right.  It's very hard to track.  However there's no 
question that the type changes from integer when it happens, I've used 
the (t) flag to check.
>
> } playing with associative arrays, yesterday I had to single quote:
> }
> }       varis 'array[value]' line456 5
> }
> } ... but only with arrays--scalars were fine--or I got a message to the
> } effect that 'no values were matched'.
>
> Without the quotes, array[value] is being treated as a file glob, and is
> looking for a file named one of arrayv, arraya, arrayl, arrayu, arraye.
> The "no matches found" error is because none of those files exists.

Ah, that makes sense.  Yet sometimes the issue isn't there.  I'll look 
more intelligently.
>
> } In the same vein, if one of these 'zcurses' functions crashes, what the
> } docs say about the terminal being in a unstable state sure is true.
> } Things look fine, but, for example, history recall goes screwy.
>
> "stty sane" will often fix you up in this situation.  It might also work
> to use "ttyctl -f" in your startup file (i.e., before any zcurses stuff
> is run) but I'm not sure that handles the case where a zsh builtin has
> itself messed up the terminal state.
>
Ok, things to try, many thanks.

Re: two mysteries

[Bart Schaefer]

On Nov 4,  4:38pm, Ray Andrews wrote:
}
} You're probably right.  It's very hard to track.  However there's no 
} question that the type changes from integer when it happens, I've used 
} the (t) flag to check.

I suspect further that you're not examining the same variable after the
error as before.  The divide-by-zero is a fatal error, e.g.:

torch% () { integer x; x=foo/bar; print ${(t)x} }
(anon): division by zero
torch% 

Note that the "print" statement was never executed.  If I bring it up
to top level:

torch% integer x
torch% x=foo/bar
zsh: division by zero
torch% print ${(t)x}
integer
torch% 

Re: two mysteries

[Ray Andrews]

On 11/06/2015 10:44 AM, Bart Schaefer wrote:
> On Nov 4,  4:38pm, Ray Andrews wrote:
> }
> } You're probably right.  It's very hard to track.  However there's no
> } question that the type changes from integer when it happens, I've used
> } the (t) flag to check.
>
> I suspect further that you're not examining the same variable after the
> error as before.  The divide-by-zero is a fatal error, e.g.:

Yup, it always crashes.
>
>
> Note that the "print" statement was never executed.  If I bring it up
> to top level:
>
> torch% integer x
> torch% x=foo/bar
> zsh: division by zero
> torch% print ${(t)x}
> integer
> torch%
>

But what ended up happening is that the type check reported it as (can't 
recall) no longer integer, and I did the check just before the fatal 
division,  so something had changed it previous to that. Anyway it 
hardly ever happens, and hasn't for quite some time so I can't do any 
more poking at it until it happens again.  But the divisor in that case 
was 'page_hight' which is the terminal hight and (God willing) is never 
zero. But maybe there's a subterfuge there, with some de novo variable, 
as you suggest.  Hard to keep an eye on these things.  With several 
arrays sloshing around, some rogue value could pop up.  But my 
experiments with Sebastian's stuff has been a real education.  I've cut 
it to 2/3 the size while doubling speed and adding a few features and 
fixing a few bugs.  But it's too big for zsh--one misses the rigorous 
control of variables.

Speaking of integers, re: my ranting about the type changing. I had a 
general purpose 'tmp' variable, which I dutifully declared 'integer', 
and absent mindedly tried to use for a string. and zsh vigorously 
denounced the effort, which was much appreciated.  So at least in that 
case it wasn't going to entertain any type change. Didn't I read that 
there's a difference between 'typeset -i' and 'integer'?

Re: two mysteries

[Bart Schaefer]

On Nov 6,  2:22pm, Ray Andrews wrote:
}
} But what ended up happening is that the type check reported it as (can't 
} recall) no longer integer, and I did the check just before the fatal 
} division,  so something had changed it previous to that.

My only guess is that in some cases the assignment occurs before the
declaration:

torch% START_IDX=1+((idx-1)/page_hight)*page_hight
torch% print ${(t)START_IDX}
scalar
torch% integer START_IDX
zsh: division by zero
torch% print ${(t)START_IDX}
integer
torch% 

The value currently in the scalar $START_IDX is evaluated when the type
changes to integer, which causes the division by zero.

Interestingly, bash allows integers to have non-integer values, so
this is not an error there:

$ foo='1/0'
$ typeset -i foo
$ echo $foo
1/0
$ typeset -p foo
declare -i foo="1/0"
$ 

This is because bash does all the arithmetic only at assignment time.

} Didn't I read that 
} there's a difference between 'typeset -i' and 'integer'?

Read where ...?  Doc:

integer [ {+|-}Hghlprtux ] [ {+|-}LRZi [ N ] ] [ NAME[=VALUE] ... ]
     Equivalent to typeset -i, except that options irrelevant to
     integers are not permitted.

Re: two mysteries

[Ray Andrews]

On 11/07/2015 01:55 AM, Bart Schaefer wrote:
> My only guess is that in some cases the assignment occurs before the
> declaration:
>
> torch% START_IDX=1+((idx-1)/page_hight)*page_hight
> torch% print ${(t)START_IDX}
> scalar
> torch% integer START_IDX
> zsh: division by zero
> torch% print ${(t)START_IDX}
> integer
> torch%
>
> The value currently in the scalar $START_IDX is evaluated when the type
> changes to integer, which causes the division by zero.
>
I think you bagged it.  The type is changed *even* when the assignment 
fails, that didn't even occur to me.  And yes, the logic is sound--it 
*has* to be an integer for 'division by zero' to be a relevant message.  
I think where I went off the rails is that this was part of  my trying 
to pass arrays (as we discussed) rather than flocks of independent 
values, and whereas I had at one time:

     integer page_hight

this became:

     files[page_hight]

... and (so far) I don't know how to typeset an element of an array so 
it was a bloody scalar and became an integer even when it failed to be 
assigned--so tweedle-dum was in fact tweedle-dee and I had the right 
issue but the bassackwards interpretation. And, as the clouds part, I 
now think I know how I fixed it:

     files[page_hight]=$files_frame[page_hight]

     files[page_hight]=$(( files_frame[page_hight] ))

... because when I forced it to be integer all the arithmetic ducks 
lined up ... or something very much like that.  It's actually a long 
chain of arithmetics, but I'll be primed for this next time something 
like that happens.  I'm hunting ducks holding my shotgun backwards.  
Geez, I wish we had in inviolable integer.

} Didn't I read that
} there's a difference between 'typeset -i' and 'integer'?

Read where ...?  Doc:

I dunno, I just vaguely recall something, thought I'd ask. Something in 1st Peter, I think--some subtlety ... nevermind.

Masterful, Sensei.

Re: two mysteries

[Bart Schaefer]

On Nov 7,  7:19am, Ray Andrews wrote:
}
} I think where I went off the rails is that this was part of  my trying 
} to pass arrays (as we discussed) rather than flocks of independent 
} values [...]
} 
} ... and (so far) I don't know how to typeset an element of an array so 

You can't typeset an element of an array.  Array elements (including
associative array elements) are presently always scalar.  There is
some room in the implementation for associative array elements to be
differently-typed, but arrays are stored internally as literal (char**).

Incidentally "typeset -i -A foo" is not rejected as an error, but the -i
flag always wins and you get an integer rather than an array.

Re: two mysteries

[Ray Andrews]

On 11/07/2015 09:19 AM, Bart Schaefer wrote:
> On Nov 7,  7:19am, Ray Andrews wrote:
> }
> } I think where I went off the rails is that this was part of  my trying
> } to pass arrays (as we discussed) rather than flocks of independent
> } values [...]
> }
> } ... and (so far) I don't know how to typeset an element of an array so
>
> You can't typeset an element of an array.  Array elements (including
> associative array elements) are presently always scalar.

That's my understanding.
>    There is
> some room in the implementation for associative array elements to be
> differently-typed, but arrays are stored internally as literal (char**).
>
> Incidentally "typeset -i -A foo" is not rejected as an error, but the -i
> flag always wins and you get an integer rather than an array.

Yeah, I tried that and got a rude surprise. Shouldn't it be an error? So 
it boils down to using $(( )) to make sure things are correct.  There 
were bound to be pitfalls trying to convert the whole data show to 
arrays, but it was educational and I think probably the right thing for 
organizational reasons.  It didn't hurt speed.  zsh with Cish data 
handling would be an awesome thing.
>