zsh-workers
 help / Atom feed
* A serious bug in execution – where to debug?
@ 2019-07-30 17:00 Sebastian Gniazdowski
  2019-07-30 17:05 ` Sebastian Gniazdowski
                   ` (2 more replies)
  0 siblings, 3 replies; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 17:00 UTC (permalink / raw)
  To: Zsh hackers list

Hello,
I have a zle function that shadows the zle builtin. The bug is: the
function exits after a certain function get's called, if the arguments
are: -F {descriptor-#} _gitstatus_process_response_POWERLEVEL9K (I
didn't yet eliminate the second argument's so I'm pasting it as is).

The symptoms are:
- print before the call does output, after the call – doesn't (as
arranged as in here: http://psprint.blinkenshell.org/zle-exit-fun.png)
- the plugin's following zle -F {descriptor-#} call reports error:
--zplg-shadow-zle:zle:64: No handler installed for fd 21
meaning that the execution didn't really reach the point where an
actual builtin zle is being called by the shadowing function.

Now, what's interesting is the certain function that causes the exit
(https://github.com/zdharma/zplugin/blob/1ddc4a2c69adec7895b4acf53e3db837720663ac/zplugin.zsh#L1261-L1264).
If I remove the conditional from its third line, i.e. change the line
to:

ZPLG_REPORTS[_dtrace/_dtrace]+="$2"$'\n'

then the problem disappears. Not that this practically eliminates that
the bug report is something wrong with some other area of the code.

I find this impossible to narrow down, because e.g. doing the zle -F
call from some other, short plugin doesn't cause the problem. This
must be a lucky set of circumstances.

But I can debug it. Where to add debug printfs / breakpoints, what to
check in them?

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 17:00 A serious bug in execution – where to debug? Sebastian Gniazdowski
@ 2019-07-30 17:05 ` Sebastian Gniazdowski
  2019-07-30 17:41 ` Roman Perepelitsa
  2019-07-30 18:27 ` Bart Schaefer
  2 siblings, 0 replies; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 17:05 UTC (permalink / raw)
  To: Zsh hackers list

On Tue, 30 Jul 2019 at 19:00, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Not that this practically eliminates that
> the bug report is something wrong with some other area of the code.

The sentence should be: NotE ...
-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 17:00 A serious bug in execution – where to debug? Sebastian Gniazdowski
  2019-07-30 17:05 ` Sebastian Gniazdowski
@ 2019-07-30 17:41 ` Roman Perepelitsa
  2019-07-30 17:55   ` Sebastian Gniazdowski
  2019-07-30 18:27 ` Bart Schaefer
  2 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 17:41 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 7:01 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> Hello,
> I have a zle function that shadows the zle builtin. The bug is: the
> function exits after a certain function get's called, if the arguments
> are: -F {descriptor-#} _gitstatus_process_response_POWERLEVEL9K (I
> didn't yet eliminate the second argument's so I'm pasting it as is).
>
> The symptoms are:
> - print before the call does output, after the call – doesn't (as
> arranged as in here: http://psprint.blinkenshell.org/zle-exit-fun.png)
> - the plugin's following zle -F {descriptor-#} call reports error:
> --zplg-shadow-zle:zle:64: No handler installed for fd 21
> meaning that the execution didn't really reach the point where an
> actual builtin zle is being called by the shadowing function.

Perhaps because of this?

https://github.com/romkatv/powerlevel10k/blob/f14497918f0a70955f6d227d1e002ad2a3f94cc8/gitstatus/gitstatus.plugin.zsh#L302-L307

Feel free to send me a PR replacing `zle` calls in this file with
`builtin zle`. I suppose you aren't shadowing `builtin` for good
measure?

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 17:41 ` Roman Perepelitsa
@ 2019-07-30 17:55   ` Sebastian Gniazdowski
  2019-07-30 18:12     ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 17:55 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 19:42, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> > - print before the call does output, after the call – doesn't (as
> > arranged as in here: http://psprint.blinkenshell.org/zle-exit-fun.png)
> > - the plugin's following zle -F {descriptor-#} call reports error:
> > --zplg-shadow-zle:zle:64: No handler installed for fd 21
> > meaning that the execution didn't really reach the point where an
> > actual builtin zle is being called by the shadowing function.
>
> Perhaps because of this?
>
> https://github.com/romkatv/powerlevel10k/blob/f14497918f0a70955f6d227d1e002ad2a3f94cc8/gitstatus/gitstatus.plugin.zsh#L302-L307

Nice argument, however this doesn't explain:
- why the actual zle -F isn't called in the later of the prematurely
exited function,
- why changing the meaningless line in the return-causing function
cancels the effect.

> Feel free to send me a PR replacing `zle` calls in this file with
> `builtin zle`. I suppose you aren't shadowing `builtin` for good
> measure?

Yes, implementation of plugin effects withdrawal (i.e. unloading)
bases on this. I saw that your initialization of the prompt is called
from precmd, where the shadowing isn't active. So (today) I've
implemented: on-demand wrapping of any function call with the
shadowing-enabling code, and then after a single call unwrapping. This
way I'm able to unload your plugin.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 17:55   ` Sebastian Gniazdowski
@ 2019-07-30 18:12     ` Roman Perepelitsa
  2019-07-30 18:16       ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 18:12 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 7:55 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Yes, implementation of plugin effects withdrawal (i.e. unloading)
> bases on this. I saw that your initialization of the prompt is called
> from precmd, where the shadowing isn't active. So (today) I've
> implemented: on-demand wrapping of any function call with the
> shadowing-enabling code, and then after a single call unwrapping. This
> way I'm able to unload your plugin.

When you unload plugins, you also remove temporary files and kill
background daemons, right?

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:12     ` Roman Perepelitsa
@ 2019-07-30 18:16       ` Sebastian Gniazdowski
  2019-07-30 18:22         ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 18:16 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 20:12, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 7:55 PM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> > Yes, implementation of plugin effects withdrawal (i.e. unloading)
> > bases on this. I saw that your initialization of the prompt is called
> > from precmd, where the shadowing isn't active. So (today) I've
> > implemented: on-demand wrapping of any function call with the
> > shadowing-enabling code, and then after a single call unwrapping. This
> > way I'm able to unload your plugin.
>
> When you unload plugins, you also remove temporary files and kill
> background daemons, right?
>
> Roman.

No. I guess that the temp-files removal can be easily added – by
shadowing mktemp call. I didn't think about killing of the background
processes. I guess this too can be added, but I suspect that most of
them will be invisible in $jobtexts, i.e. disowned, so it might get
hard. Thanks for the suggestions. How are you running the gitstatus
process in the plugin?

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:16       ` Sebastian Gniazdowski
@ 2019-07-30 18:22         ` Roman Perepelitsa
  2019-07-30 18:53           ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 18:22 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 8:16 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 20:12, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2019 at 7:55 PM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> > > Yes, implementation of plugin effects withdrawal (i.e. unloading)
> > > bases on this. I saw that your initialization of the prompt is called
> > > from precmd, where the shadowing isn't active. So (today) I've
> > > implemented: on-demand wrapping of any function call with the
> > > shadowing-enabling code, and then after a single call unwrapping. This
> > > way I'm able to unload your plugin.
> >
> > When you unload plugins, you also remove temporary files and kill
> > background daemons, right?
> >
> > Roman.
>
> No. I guess that the temp-files removal can be easily added – by
> shadowing mktemp call. I didn't think about killing of the background
> processes. I guess this too can be added, but I suspect that most of
> them will be invisible in $jobtexts, i.e. disowned, so it might get
> hard. Thanks for the suggestions. How are you running the gitstatus
> process in the plugin?

Do you think it's possible to implement clean shutdown and reentrant
initialization for a piece of code as blackbox?

gitstatusd and p10k both have clean shutdown in their public APIs. It
was quite difficult to implement. By using this API you release all
resources and can initialize the plugins once again within the same
shell. However, if you unset internal variables or close file
descriptors, or fail to kill daemons, you are in undefined behavior
land and all bets are off.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 17:00 A serious bug in execution – where to debug? Sebastian Gniazdowski
  2019-07-30 17:05 ` Sebastian Gniazdowski
  2019-07-30 17:41 ` Roman Perepelitsa
@ 2019-07-30 18:27 ` Bart Schaefer
  2019-07-30 18:46   ` Sebastian Gniazdowski
  2 siblings, 1 reply; 33+ messages in thread
From: Bart Schaefer @ 2019-07-30 18:27 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 10:01 AM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> If I remove the conditional from its third line, i.e. change the line
> to:
>
> ZPLG_REPORTS[_dtrace/_dtrace]+="$2"$'\n'
>
> then the problem disappears.

If you change the [[ ... ]] && ... to an if/then, does the behavior change?
If you add a "return" or "return $?" at the end of the function, does it change?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:27 ` Bart Schaefer
@ 2019-07-30 18:46   ` Sebastian Gniazdowski
  2019-07-30 21:02     ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 18:46 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 20:28, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Jul 30, 2019 at 10:01 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > If I remove the conditional from its third line, i.e. change the line
> > to:
> >
> > ZPLG_REPORTS[_dtrace/_dtrace]+="$2"$'\n'
> >
> > then the problem disappears.
>
> If you change the [[ ... ]] && ... to an if/then, does the behavior change?
> If you add a "return" or "return $?" at the end of the function, does it change?

a) yes, the problem cancels with if-then
b) no, adding one of the return's doesn't change the behavior

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:22         ` Roman Perepelitsa
@ 2019-07-30 18:53           ` Sebastian Gniazdowski
  2019-07-30 19:23             ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 18:53 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 20:22, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 8:16 PM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > On Tue, 30 Jul 2019 at 20:12, Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> > >
> > > On Tue, Jul 30, 2019 at 7:55 PM Sebastian Gniazdowski
> > > <sgniazdowski@gmail.com> wrote:
> > No. I guess that the temp-files removal can be easily added – by
> > shadowing mktemp call. I didn't think about killing of the background
> > processes. I guess this too can be added, but I suspect that most of
> > them will be invisible in $jobtexts, i.e. disowned, so it might get
> > hard. Thanks for the suggestions. How are you running the gitstatus
> > process in the plugin?
>
> Do you think it's possible to implement clean shutdown and reentrant
> initialization for a piece of code as blackbox?

What do you mean exactly? As a blackbox - as a regular, repeatable method?

> gitstatusd and p10k both have clean shutdown in their public APIs. It
> was quite difficult to implement. By using this API you release all
> resources and can initialize the plugins once again within the same
> shell. However, if you unset internal variables or close file
> descriptors, or fail to kill daemons, you are in undefined behavior
> land and all bets are off.

This might be a good use case for the proposed unload function
(http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html#unload-fun).
If you would provide a function powerlevel10k_unload_plugin, then I
would call it in Zplugin when unloading the plugin, allowing the
function to close the background process.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:53           ` Sebastian Gniazdowski
@ 2019-07-30 19:23             ` Roman Perepelitsa
  2019-07-30 19:34               ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 19:23 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 8:53 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 20:22, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > Do you think it's possible to implement clean shutdown and reentrant
> > initialization for a piece of code as blackbox?
>
> What do you mean exactly? As a blackbox - as a regular, repeatable method?

In order to implement clean shutdown for a piece of code with
non-trivial capabilities you have to rely on its implementation
details. You cannot implement generic clean shutdown that will work
with any code.

Here's an example. Suppose a plugin you are monitoring spawns a
process. Should you kill it when you unload the plugin? It depends. If
this plugin spawns a process every time it is loaded and kills it
every time you call its public `shutdown` function, then you should
probably kill it to avoid leaking processes. You don't want to have a
horde of stray processes if the plugin is loaded and unloaded multiple
times. On the other hand, if this plugin spawns a one-per-user daemon
(could also be one-per-machine), then another shell might already be
using it, and if you kill the daemon when the plugin is unloaded in
one shell, you can break that same plugin in another shell. Plugins
don't expect that their internal processes will be randomly killed,
files randomly deleted and internal variables randomly unset, so if
you start doing it, things will break. To implement clean shutdown in
this case, you need to check whether this plugin is the last instance
for this user/machine and only then kill the daemon. In other words,
in both cases you need to implement the same logic the plugin already
implements in its shutdown routine. Once you implement it, you have to
keep it in sync with internal implementation changes of the plugin.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 19:23             ` Roman Perepelitsa
@ 2019-07-30 19:34               ` Sebastian Gniazdowski
  2019-07-30 19:41                 ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 19:34 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 21:24, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 8:53 PM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > On Tue, 30 Jul 2019 at 20:22, Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> > >
> > > Do you think it's possible to implement clean shutdown and reentrant
> > > initialization for a piece of code as blackbox?
> >
> > What do you mean exactly? As a blackbox - as a regular, repeatable method?
>
> In order to implement clean shutdown for a piece of code with
> non-trivial capabilities you have to rely on its implementation
> details. You cannot implement generic clean shutdown that will work
> with any code.

Yeah but this is solved by the unload function that I've described in
the previous post.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 19:34               ` Sebastian Gniazdowski
@ 2019-07-30 19:41                 ` Roman Perepelitsa
  2019-07-30 19:59                   ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 19:41 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Tue, Jul 30, 2019 at 9:34 PM Sebastian Gniazdowski <
sgniazdowski@gmail.com> wrote:

> On Tue, 30 Jul 2019 at 21:24, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2019 at 8:53 PM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> > >
> > > On Tue, 30 Jul 2019 at 20:22, Roman Perepelitsa
> > > <roman.perepelitsa@gmail.com> wrote:
> > > >
> > > > Do you think it's possible to implement clean shutdown and reentrant
> > > > initialization for a piece of code as blackbox?
> > >
> > > What do you mean exactly? As a blackbox - as a regular, repeatable
> method?
> >
> > In order to implement clean shutdown for a piece of code with
> > non-trivial capabilities you have to rely on its implementation
> > details. You cannot implement generic clean shutdown that will work
> > with any code.
>
> Yeah but this is solved by the unload function that I've described in
> the previous post.
>

I think we are in agreement. If there is a public function to unload, you
can call it. If there isn't, it's a missing feature that cannot be provided
by anyone other than the code's author. it's not possible to safely unload
code as a blackbox without knowing all of its implementation details.

Both gitstatusd and p10k do provide public functions for unloading. You are
welcome to call them. They guarantee that repeated load+unload won't leak
resources. That is, as long as you don't unset any of their internal
variables. They do leave a handful of global parameters after unloading;
without them they cannot be loaded correctly again.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 19:41                 ` Roman Perepelitsa
@ 2019-07-30 19:59                   ` Sebastian Gniazdowski
  2019-07-30 20:08                     ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 19:59 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 21:42, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 9:34 PM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>>
>> On Tue, 30 Jul 2019 at 21:24, Roman Perepelitsa
>> <roman.perepelitsa@gmail.com> wrote:
> I think we are in agreement. If there is a public function to unload, you can call it. If there isn't, it's a missing feature that cannot be provided by anyone other than the code's author. it's not possible to safely unload code as a blackbox without knowing all of its implementation details.

Yes, but that's in general. I have very positive experiences with
unloading of prompts. Currently in my setup by setting parameter
MYPROMPT=1..8 I can choose the prompt that's active, as described in:
http://zdharma.org/zplugin/site/Multiple-prompts/. In general it is
like you've said, e.g. syntax-highlighting plugin's won't unload
correctly, but only due to a final glitch and as I tested now, it
*did* unload correctly (due to changes in my setup, most probably).
But in general yes, plugins often do not unload fully clean, so I
think that we are in agreement.

> Both gitstatusd and p10k do provide public functions for unloading. You are welcome to call them. They guarantee that repeated load+unload won't leak resources. That is, as long as you don't unset any of their internal variables. They do leave a handful of global parameters after unloading; without them they cannot be loaded correctly again.

Could the function powerlevel10k_unload_plugin() be provided? I could
deduce it from the plugin's name and call it in a general manner.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 19:59                   ` Sebastian Gniazdowski
@ 2019-07-30 20:08                     ` Roman Perepelitsa
  2019-07-30 20:38                       ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 20:08 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Tue, Jul 30, 2019 at 9:59 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 21:42, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2019 at 9:34 PM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> >>
> >> On Tue, 30 Jul 2019 at 21:24, Roman Perepelitsa
> >> <roman.perepelitsa@gmail.com> wrote:
> > I think we are in agreement. If there is a public function to unload, you can call it. If there isn't, it's a missing feature that cannot be provided by anyone other than the code's author. it's not possible to safely unload code as a blackbox without knowing all of its implementation details.
>
> Yes, but that's in general. I have very positive experiences with
> unloading of prompts. Currently in my setup by setting parameter
> MYPROMPT=1..8 I can choose the prompt that's active, as described in:
> http://zdharma.org/zplugin/site/Multiple-prompts/. In general it is
> like you've said, e.g. syntax-highlighting plugin's won't unload
> correctly, but only due to a final glitch and as I tested now, it
> *did* unload correctly (due to changes in my setup, most probably).
> But in general yes, plugins often do not unload fully clean, so I
> think that we are in agreement.

I'm not above some dirty hacks myself but you have to be clear with
your messaging if you are inviting others to use your code. If your
code may or may not work, can leak resources and corrupt files
(corrupting .git is pretty bad), can work today and stop working
tomorrow after an update, -- you might want to mention it.

>
> > Both gitstatusd and p10k do provide public functions for unloading. You are welcome to call them. They guarantee that repeated load+unload won't leak resources. That is, as long as you don't unset any of their internal variables. They do leave a handful of global parameters after unloading; without them they cannot be loaded correctly again.
>
> Could the function powerlevel10k_unload_plugin() be provided? I could
> deduce it from the plugin's name and call it in a general manner.

I have no objections against your providing this function, although I
would prefer that you didn't use "powerlevel10k" prefix to avoid
potential name clashes in the future. As long as it calls only the
public functions of p10k, it won't break when p10k evolves.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 20:08                     ` Roman Perepelitsa
@ 2019-07-30 20:38                       ` Sebastian Gniazdowski
  0 siblings, 0 replies; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 20:38 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Tue, 30 Jul 2019 at 22:09, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> I'm not above some dirty hacks myself but you have to be clear with
> your messaging if you are inviting others to use your code. If your
> code may or may not work, can leak resources and corrupt files
> (corrupting .git is pretty bad), can work today and stop working
> tomorrow after an update, -- you might want to mention it.

The unloading was a tentative, good-natured initiatory and it still
didn't found its full resolution. But it's a tool in the toolbox and
it's already proving its usefulness (e.g. the MYPROMPT=1..8 setup).

> I have no objections against your providing this function, although I
> would prefer that you didn't use "powerlevel10k" prefix to avoid
> potential name clashes in the future. As long as it calls only the
> public functions of p10k, it won't break when p10k evolves.

Follow-up off-list.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 18:46   ` Sebastian Gniazdowski
@ 2019-07-30 21:02     ` Roman Perepelitsa
  2019-07-30 21:38       ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 21:02 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Bart Schaefer, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Tue, Jul 30, 2019 at 11:00 PM Sebastian Gniazdowski <
sgniazdowski@gmail.com> wrote:

> On Tue, 30 Jul 2019 at 20:28, Bart Schaefer <schaefer@brasslantern.com>
> wrote:
> >
> > On Tue, Jul 30, 2019 at 10:01 AM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> > >
> > > If I remove the conditional from its third line, i.e. change the line
> > > to:
> > >
> > > ZPLG_REPORTS[_dtrace/_dtrace]+="$2"$'\n'
> > >
> > > then the problem disappears.
> >
> > If you change the [[ ... ]] && ... to an if/then, does the behavior
> change?
> > If you add a "return" or "return $?" at the end of the function, does it
> change?
>
> a) yes, the problem cancels with if-then
> b) no, adding one of the return's doesn't change the behavior
>

I think Bart solved it. Do you have `emulate -L zsh` in your `zle` function?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 21:02     ` Roman Perepelitsa
@ 2019-07-30 21:38       ` Sebastian Gniazdowski
  2019-07-30 21:45         ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 21:38 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Bart Schaefer, Zsh hackers list

On Tue, 30 Jul 2019 at 23:02, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>> On Tue, 30 Jul 2019 at 20:28, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> > If you change the [[ ... ]] && ... to an if/then, does the behavior change?
>> > If you add a "return" or "return $?" at the end of the function, does it change?
>>
>> a) yes, the problem cancels with if-then
>> b) no, adding one of the return's doesn't change the behavior
>
> I think Bart solved it. Do you have `emulate -L zsh` in your `zle` function?

No, but adding it helps. Any emulation (sh, ksh) does. Aah, so this is
the errreturn option set within your plugin! and the if-then was
setting the return code to 0. A very interesting situation, having
your code called in foreign context, to know what options to defend
from.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 21:38       ` Sebastian Gniazdowski
@ 2019-07-30 21:45         ` Roman Perepelitsa
  2019-07-30 21:54           ` Sebastian Gniazdowski
  2019-07-30 22:18           ` Daniel Shahaf
  0 siblings, 2 replies; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 21:45 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Bart Schaefer, Zsh hackers list

On Tue, Jul 30, 2019 at 11:38 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 23:02, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >> On Tue, 30 Jul 2019 at 20:28, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >> > If you change the [[ ... ]] && ... to an if/then, does the behavior change?
> >> > If you add a "return" or "return $?" at the end of the function, does it change?
> >>
> >> a) yes, the problem cancels with if-then
> >> b) no, adding one of the return's doesn't change the behavior
> >
> > I think Bart solved it. Do you have `emulate -L zsh` in your `zle` function?
>
> No, but adding it helps. Any emulation (sh, ksh) does. Aah, so this is
> the errreturn option set within your plugin! and the if-then was
> setting the return code to 0. A very interesting situation, having
> your code called in foreign context, to know what options to defend
> from.

You should call `emulate -L zsh` from every functions that can be
called by any code other than yours. It's almost impossible to write
code that works the same way with all combinations of options. In my
public code I also unset aliases. These defensive measures reduce the
number of bug reports by *a lot*. People really seem to like creating
global aliases with single-letter names. I'll probably start calling
`disable -f` for all builtins I use.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 21:45         ` Roman Perepelitsa
@ 2019-07-30 21:54           ` Sebastian Gniazdowski
  2019-07-30 22:11             ` Roman Perepelitsa
  2019-07-30 22:18           ` Daniel Shahaf
  1 sibling, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-30 21:54 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Bart Schaefer, Zsh hackers list

On Tue, 30 Jul 2019 at 23:45, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Jul 30, 2019 at 11:38 PM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > On Tue, 30 Jul 2019 at 23:02, Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> > >> On Tue, 30 Jul 2019 at 20:28, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > >> > If you change the [[ ... ]] && ... to an if/then, does the behavior change?
> > >> > If you add a "return" or "return $?" at the end of the function, does it change?
> > >>
> > >> a) yes, the problem cancels with if-then
> > >> b) no, adding one of the return's doesn't change the behavior
> > >
> > > I think Bart solved it. Do you have `emulate -L zsh` in your `zle` function?
> >
> > No, but adding it helps. Any emulation (sh, ksh) does. Aah, so this is
> > the errreturn option set within your plugin! and the if-then was
> > setting the return code to 0. A very interesting situation, having
> > your code called in foreign context, to know what options to defend
> > from.
>
> You should call `emulate -L zsh` from every functions that can be
> called by any code other than yours. It's almost impossible to write

I avoided localoptions for performance – it consumes some time, as it
(probably, but the performance effect is confirmed) allocates a new
table of options and fills it with defaults. So I've decided to write
an option-transparent code. But turns out that this might be hard in
case of such options as errreturn. I'll think about whether to replace
inline conditions with if-then or to do emulate -L.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 21:54           ` Sebastian Gniazdowski
@ 2019-07-30 22:11             ` Roman Perepelitsa
  0 siblings, 0 replies; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 22:11 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Bart Schaefer, Zsh hackers list

On Tue, Jul 30, 2019 at 11:54 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 23:45, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2019 at 11:38 PM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> I avoided localoptions for performance – it consumes some time, as it
> (probably, but the performance effect is confirmed) allocates a new
> table of options and fills it with defaults. So I've decided to write
> an option-transparent code. But turns out that this might be hard in
> case of such options as errreturn. I'll think about whether to replace
> inline conditions with if-then or to do emulate -L.

Keep in mind that 5.4 (I think it was 5.4) had a bug where a false
condition under `if` was causing the function to return if err_return
is set. Same with `while` -- it would return from the function at the
end of iteration. 5.4 is still very popular.

My solution for the performance problem is to call `emulate -L zsh`
only at the points of entry (public API) and then avoid calling too
many small functions.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 21:45         ` Roman Perepelitsa
  2019-07-30 21:54           ` Sebastian Gniazdowski
@ 2019-07-30 22:18           ` Daniel Shahaf
  2019-07-30 22:32             ` Roman Perepelitsa
  1 sibling, 1 reply; 33+ messages in thread
From: Daniel Shahaf @ 2019-07-30 22:18 UTC (permalink / raw)
  To: zsh-workers

Roman Perepelitsa wrote on Tue, 30 Jul 2019 21:46 +00:00:
> You should call `emulate -L zsh` from every functions that can be
> called by any code other than yours. It's almost impossible to write
> code that works the same way with all combinations of options. In my
> public code I also unset aliases. These defensive measures reduce the
> number of bug reports by *a lot*. People really seem to like creating
> global aliases with single-letter names.

z-sy-h also does 'emulate -L' and unsets aliases.  I wonder if there
should be a built-in way to do this, in order to make it easier to write
plugins?  Perhaps a «source -U foo.zsh» syntax, as in autoload?

> I'll probably start calling `disable -f` for all builtins I use.

I wonder if you might be throwing the baby out with the bathwater here.
Aren't there legitimate use-cases for writing shadowing functions?  For
example, what if somebody does «zle() { typeset -p funcstack >&2; zle "$@" }»
for debugging purposes?

(And yes, I'm aware compsys and z-sy-h both use 'command' and 'builtin' in places..)

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 22:18           ` Daniel Shahaf
@ 2019-07-30 22:32             ` Roman Perepelitsa
  2019-07-31  1:30               ` Sebastian Gniazdowski
  2019-07-31  1:42               ` Bart Schaefer
  0 siblings, 2 replies; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-30 22:32 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Wed, Jul 31, 2019 at 12:19 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Roman Perepelitsa wrote on Tue, 30 Jul 2019 21:46 +00:00:
> > You should call `emulate -L zsh` from every functions that can be
> > called by any code other than yours. It's almost impossible to write
> > code that works the same way with all combinations of options. In my
> > public code I also unset aliases. These defensive measures reduce the
> > number of bug reports by *a lot*. People really seem to like creating
> > global aliases with single-letter names.
>
> z-sy-h also does 'emulate -L' and unsets aliases.

By the way, why does it deal with aliases manually instead of
`unsetopt aliases`?

>  I wonder if there
> should be a built-in way to do this, in order to make it easier to write
> plugins?  Perhaps a «source -U foo.zsh» syntax, as in autoload?

The only problem I have with `unsetopt aliases` is that it has to be
done before a function is parsed. This means using one of two
patterns:

1. Remember at the top of the file if `aliases` options is set, then
unset the option. At the bottom of the file, restore aliases.
2. Use two files. The first contains the real meet. The second has an
anonymous function with `emulate -L zsh && unsetopt alizes && source
first.zsh`.

The first is bound to sometimes fail to restore the options, which
causes catastrophic effects. The second requires two files makes
things a bit slower.

I use (2) with large files as it gives me the additional benefit of
being able to prevent extra loads of the file. The small file acts
like a header guard in C. Having the guarantee that my file is sourced
at most once gives many advantages.

> > I'll probably start calling `disable -f` for all builtins I use.
>
> I wonder if you might be throwing the baby out with the bathwater here.
> Aren't there legitimate use-cases for writing shadowing functions?  For
> example, what if somebody does «zle() { typeset -p funcstack >&2; zle "$@" }»
> for debugging purposes?

The flip side is that users often define functions with any name they
feel like and are none the wiser if they are shadowing some obscure
builtin your code needs. If you want to call the builtin, call the
builtin.

I'm on the fence on this issue. As long as I don't get too many bug
reports because of over-ambitious plugin managers, I'm fine. It does
get on my nerves sometimes though. If I could defend against functions
shadowing builtins easily, I would. I just don't know how. If
`builtin`, `disable`, `setopt`, `unsetopt`, `unset` and `unfunction`
are all hidden, escaping the sandbox is tricky.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 22:32             ` Roman Perepelitsa
@ 2019-07-31  1:30               ` Sebastian Gniazdowski
  2019-07-31  7:23                 ` Roman Perepelitsa
  2019-07-31  1:42               ` Bart Schaefer
  1 sibling, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-31  1:30 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, 31 Jul 2019 at 00:39, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:

> I'm on the fence on this issue. As long as I don't get too many bug
> reports because of over-ambitious plugin managers, I'm fine.

So Zplugin is considered an over-ambitious plugin manager by you? :)
I'll take that as a compliment. Besides, isn't your prompt little
over-ambitious too? ;) With the binary, background daemon? ;D

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-30 22:32             ` Roman Perepelitsa
  2019-07-31  1:30               ` Sebastian Gniazdowski
@ 2019-07-31  1:42               ` Bart Schaefer
  1 sibling, 0 replies; 33+ messages in thread
From: Bart Schaefer @ 2019-07-31  1:42 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

On Tue, Jul 30, 2019, 3:33 PM Roman Perepelitsa <roman.perepelitsa@gmail.com>
wrote:

> The only problem I have with `unsetopt aliases` is that it has to be
> done before a function is parsed.
>

That's what autoloading is supposed to be able to avoid.

>

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31  1:30               ` Sebastian Gniazdowski
@ 2019-07-31  7:23                 ` Roman Perepelitsa
  2019-07-31 11:41                   ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-31  7:23 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, Jul 31, 2019 at 3:30 AM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Wed, 31 Jul 2019 at 00:39, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
>
> > I'm on the fence on this issue. As long as I don't get too many bug
> > reports because of over-ambitious plugin managers, I'm fine.
>
> So Zplugin is considered an over-ambitious plugin manager by you? :)

I meant over-ambitious in the specific sense mentioned above --
advertising features that are not and cannot be implemented. There is
no way for users to tell whether unloading is safe to use zplugin to
unload X and what the consequences are if it isn't. Features whose
user-observable behavior cannot be described even in theory, and for
which an honest specification is tightly tied to their implementation
details, are over-ambitious. Saying that zplugin can unload arbitrary
code is inaccurate at best and deceptive at worst. What it can do is
unset parameters/functions/etc set by the code. Note how this refers
to the implementation and not the user-observable behavior. What the
user will actually see is unpredictable.

> Besides, isn't your prompt little
> over-ambitious too? ;) With the binary, background daemon? ;D

Spawning long-lived background processes that opt-out of job control
isn't uncommon among zsh themes and plugins. Powerline, p10k, p9k,
zinc, pure all do it. So does zplugin, I believe. The level of
daemonization and sharing differ: powerline detaches its child process
and shares it among multiple shells; p10k and everything else using
gitstatusd double-forks and creates a new session with setsid; pure
and zplugin leave their processes as children. Technical differences
in background process management make it impossible to implement clean
shutdown for these themes/plugins externally but they don't make them
over-ambitious. Powerline does what it claims to do -- give you a
prompt with lots of colors and ornaments. No leaky abstractions, no
deception.

Having said that, I have no illusions about the utility of my public
zsh code. If all zsh plugins and themes would disappear overnight, I
don't know if the world would be better or worse off. This ecosystem
feeds on customization addiction after all.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31  7:23                 ` Roman Perepelitsa
@ 2019-07-31 11:41                   ` Sebastian Gniazdowski
  2019-07-31 12:40                     ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-31 11:41 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, 31 Jul 2019 at 09:23, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 3:30 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > On Wed, 31 Jul 2019 at 00:39, Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> wrote:
> >
> > > I'm on the fence on this issue. As long as I don't get too many bug
> > > reports because of over-ambitious plugin managers, I'm fine.
> >
> > So Zplugin is considered an over-ambitious plugin manager by you? :)
>
> I meant over-ambitious in the specific sense mentioned above --
> advertising features that are not and cannot be implemented.
> ...
> Features whose
> user-observable behavior cannot be described even in theory, and for
> which an honest specification is tightly tied to their implementation
> details, are over-ambitious.

I'm not sure if this will not be "honest specification" (that is) "is
tightly tied to their implementation
details", but somewhat user-observable effects of zplugin unload
procedure "described in theory" are:

1. Withdrawal of any bindkey call, i.e. if a plugin did bindkey ^T
widget, then the binding will be deleted (restoring of previous
binding is a TODO), including range bindings (bindkey -R).
2. Deletion of created keymaps (bindkey -N) and unlinking of the main
keymap (bindkey -A).
3. Withdrawal of any zstyles (again, only deletion).
4. Withdrawal (i.e. deletion) and restoration (i.e. set up of the
previous value) of aliases, including suffix and global aliases.
5. Withdrawal of zle created widgets (zle -N) – restoration and deletion.
6. Restoration of changed options.
7. Removal of added PATH and FPATH elements (adding of removed element
is ready to be implemented, yet it wasn't needed)
8. Deletion of created functions
9. Removal of any added hooks
10. Unset of created global parameters (restoration of previous type's
is a niche TODO).

> Saying that zplugin can unload arbitrary
> code is inaccurate at best and deceptive at worst.

Maybe.. I think that it's an untold common truth shared by any user
that Zplugin cannot be that smart to withdraw *any* sophisticated
effect of a potential plugin. Claiming in an straightforward manner
"Zplugin can unload plugins" is like a statement that encourages to
acknowledge that *some serious* unloading is possible, that the shell
isn't a black hole where things undergo untracked, in one direction
only. Didn't you revise your opinion a little on unloading of plugins
after reading the list from the previous paragraph?

> What the user will actually see is unpredictable.
I think that it's actually possible to predict to a large extent by
looking at the list of unload-actions.

> Spawning long-lived background processes that opt-out of job control
> isn't uncommon among zsh themes and plugins.

To be clear: I like the sophistication of the theme and see it as the
right path.

> Powerline, p10k, p9k,
> zinc, pure all do it. So does zplugin, I believe.

Zplugin forks (if you're talking about the `services' feature) or
loads a binary zshell module zplugin.so.

> Technical differences
> in background process management make it impossible to implement clean
> shutdown for these themes/plugins externally but they don't make them
> over-ambitious.

Ok, agreed.

> Powerline does what it claims to do -- give you a
> prompt with lots of colors and ornaments. No leaky abstractions, no
> deception.

I hope that by the second paragraph I've lessen the "deception"
argument to a significant degree.

> Having said that, I have no illusions about the utility of my public
> zsh code. If all zsh plugins and themes would disappear overnight, I
> don't know if the world would be better or worse off. This ecosystem
> feeds on customization addiction after all.
>
> Roman.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 11:41                   ` Sebastian Gniazdowski
@ 2019-07-31 12:40                     ` Roman Perepelitsa
  2019-07-31 13:10                       ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-31 12:40 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, Jul 31, 2019 at 1:41 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> I'm not sure if this will not be "honest specification" (that is) "is
> tightly tied to their implementation
> details", but somewhat user-observable effects of zplugin unload
> procedure "described in theory" are:
>
> [...]

When users are told they can unload plugins without restarting ZSH,
they hear the following story. Normally, to disable a plugin you must
remove it from your ~/.zshrc and restart ZSH. But if you are using
zplugin you can achieve the same result without restarting your ZSH
simply by typing a command.

This is an easy-to-understand feature. If it could be implemented, it
would be mildly useful. Unfortunately, it cannot be implemented even
for simple plugins.

Suppose I have three plugins specified in ~/.zshrc called foo, bar and
baz, and they are loaded in the specified order. I want to unload foo.
That is, I want to get the same shell state that I would get if I
removed foo from ~/.zshrc and restarted ZSH. While loading, foo
defined an alias for grep: alias grep='grep --color=auto'. When foo is
unloaded, this alias is unset, and this causes two unexpected
consequences. The first is that when I type `grep` in my prompt I get
output without colors. The second is that calling a function from bar
produces colorful output. Once I restart zsh with just bar and baz in
~/.zshrc, these cases swap: interactive grep is colorful while a
function in bar isn't.

How is this possible?

  foo.zsh:  alias grep='grep --color=auto'
  bar.zsh:  function bar() { grep hello <<<hello }
  baz.zsh  alias grep='grep --color=auto'

You can get the same problems when reverting changes to any resource
with a shared name: aliases, traps, options, widgets. All code that
ran after the plugin you are attempting could've been affected by the
value you are reverting.

Removing widgets is very likely to break your prompt due to the way
widgets are commonly hooked. When a decent plugin wants to hook a zle
widget, it will copy the previous widget and install its own. The
installed widget will do something and call the previous widget. Now,
if *this* widget gets wrapped too, and you remove it, the chain of
hooks is broken. All plugins that have wrapped that widget before
won't be called. Plugins that have wrapped the widget after will spew
errors.

> I think that it's actually possible to predict to a large extent by
> looking at the list of unload-actions.

You can predict which aliases will be unset and which widgets removed
but you cannot predict how it will affect shell. Things can break a
little or a lot. Things may look OK but do damage behind the scenes.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 12:40                     ` Roman Perepelitsa
@ 2019-07-31 13:10                       ` Sebastian Gniazdowski
  2019-07-31 13:34                         ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-31 13:10 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, 31 Jul 2019 at 14:40, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> ...
> How is this possible?
>
>   foo.zsh:  alias grep='grep --color=auto'
>   bar.zsh:  function bar() { grep hello <<<hello }
>   baz.zsh  alias grep='grep --color=auto'

Thanks for bringing this up into the light. It's a good example of the
problems with unloading. It also hints an extension to zplugin – to
test whether the alias' value is the one expected to be and hold the
unsetting/restoration of the alias if it isn't. So, if baz would set
alias grep='grep -B1 --color=auto', then things would work as
expected. And that's how it is with the unloading – it *often* works,
sometimes doesn't. But still, it's an useful tool that can be often
used.

> You can get the same problems when reverting changes to any resource
> with a shared name: aliases, traps, options, widgets. All code that
> ran after the plugin you are attempting could've been affected by the
> value you are reverting.

Ok, but the unloading can still be useful. For example, besides the
MYPROMPT=1..8 use case, I'm also using it often when developing a
plugin, instead of the shell restart. It allows for a quick
unfunction/redeclaration of autoload functions, for example.

> Removing widgets is very likely to break your prompt due to the way
> widgets are commonly hooked. When a decent plugin wants to hook a zle
> widget, it will copy the previous widget and install its own.
> ...
> if *this* widget gets wrapped too, and you remove it, the chain of
> hooks is broken.

This particular case will be solved if the plugin will use
add-zle-hook-widget instead of wrapping (support for this isn't yet in
zplugin, but it'll be there soon).

> > I think that it's actually possible to predict to a large extent by
> > looking at the list of unload-actions.
>
> You can predict which aliases will be unset and which widgets removed
> but you cannot predict how it will affect shell. Things can break a
> little or a lot. Things may look OK but do damage behind the scenes.

To sum up, your opinion is a mathematical-like proof that:

* You cannot implement an unloading that just works as expected.

While my opinion is a practical-view -like point that:

* You can often get good results with unloading, just try & test it
first with the plugin that you need to unload.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 13:10                       ` Sebastian Gniazdowski
@ 2019-07-31 13:34                         ` Roman Perepelitsa
  2019-07-31 13:40                           ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-31 13:34 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, Jul 31, 2019 at 3:10 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> This particular case will be solved if the plugin will use
> add-zle-hook-widget instead of wrapping (support for this isn't yet in
> zplugin, but it'll be there soon).

Unfortunately, using add-zle-hook-widget is no-no. If you use it while
other plugins are still wrapping widgets old-school, you can cause
infinite loops. All plugins have to be switched to add-zle-hook-widget
at the same time, which is pretty much impossible. Hopefully someone
will care enough to fix add-zle-hook-widget but the benefits are
difficult to see. Wrapping widgets works fine. It breaks zplugin's
unloading code but the same can be said about pretty much everything.

> To sum up, your opinion is a mathematical-like proof that:
>
> * You cannot implement an unloading that just works as expected.
>
> While my opinion is a practical-view -like point that:
>
> * You can often get good results with unloading, just try & test it
> first with the plugin that you need to unload.

Both statements are true.

What I don't like is the implication of offering a
maybe-works-maybe-doesn't unloading mechanism. It creates an
expectation that plugins must be unloadable not via their public APIs
but through brutal and unceremonious deletion of their internal
parameters, widgets and so on. If something breaks during unloading,
users may not even realize they've grown to rely on hacks and that
their shell configuration is unsupported. They can reasonably reach
out to the "malfunctioning" plugin's developers and ask them to fix
the "issue". It's like selling rocks as a tool to turn off TV sets.
Just throw a rock at the TV and it'll turn off! If it breaks your TV,
please don't complain to your TV manufacturer.

I also have intense emotional reaction to this kind of unloading. It
just feels rude to modify internal implementation details of software.
It's one thing to do it with code that only you yourself use, or to
apply this sort of dirty patching to a product you are intimately
familiar with, but it's quite another to distribute this crude tool as
a feature. It's disrespectful to the developers whose code is
brutalized, and it causes extra strain on them due to bug reports by
the affected users.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 13:34                         ` Roman Perepelitsa
@ 2019-07-31 13:40                           ` Sebastian Gniazdowski
  2019-07-31 14:11                             ` Roman Perepelitsa
  0 siblings, 1 reply; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-31 13:40 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, 31 Jul 2019 at 15:34, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> a feature. It's disrespectful to the developers whose code is
> brutalized, and it causes extra strain on them due to bug reports by
> the affected users.

I see. For me the topic isn't associated with brutalization. It's a
removal of plugin's widget together with its binding, so that it's not
exposed anymore. A simple withdrawal of plugin's presence.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 13:40                           ` Sebastian Gniazdowski
@ 2019-07-31 14:11                             ` Roman Perepelitsa
  2019-07-31 17:56                               ` Sebastian Gniazdowski
  0 siblings, 1 reply; 33+ messages in thread
From: Roman Perepelitsa @ 2019-07-31 14:11 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

On Wed, Jul 31, 2019 at 3:40 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Wed, 31 Jul 2019 at 15:34, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> > a feature. It's disrespectful to the developers whose code is
> > brutalized, and it causes extra strain on them due to bug reports by
> > the affected users.
>
> I see. For me the topic isn't associated with brutalization. It's a
> removal of plugin's widget together with its binding, so that it's not
> exposed anymore. A simple withdrawal of plugin's presence.

Once upon a time there lived Jack -- the sole designer and
manufacturer of TV sets that bore his name. He took pride in the
functional and aesthetic properties of his product. Jack TVs had a
slick screen that looked almost weightless, and a nice remote for
turning the TV on and off. Then one day an enterprising distributor
showed up in town and started bundling Jack TV together with other
home appliances and advertising rocks as a general tool for turning
off electronic devices. "It often works", he said. Jack shook his head
every time he saw a scratched or broken screen with his name on the
frame. He no longer told people he made those TVs as it became
difficult to look at the brutalized hunks of steel and glass with
pride. "I'm not brutalizing this TV set, I'm just throwing rocks at
it", one customer was heard to say. He didn't know there was a remote.
The distributor didn't tell him.

Roman.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: A serious bug in execution – where to debug?
  2019-07-31 14:11                             ` Roman Perepelitsa
@ 2019-07-31 17:56                               ` Sebastian Gniazdowski
  0 siblings, 0 replies; 33+ messages in thread
From: Sebastian Gniazdowski @ 2019-07-31 17:56 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh hackers list

On Wed, 31 Jul 2019 at 16:11, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> Once upon a time there lived Jack -- the sole designer and
> manufacturer of TV sets that bore his name. He took pride in the
> functional and aesthetic properties of his product. Jack TVs had a
> slick screen that looked almost weightless, and a nice remote for
> turning the TV on and off. Then one day an enterprising distributor
> showed up in town and started bundling Jack TV together with other
> home appliances and advertising rocks as a general tool for turning
> off electronic devices. "It often works", he said. Jack shook his head
> ...

Once upon a time there was Garry that had been the designer of the
Hi-Fi that worn his name. He was providing his users with a remote for
the Hi-Fi. Then an enterprising distributor showed up in town and
started bundling Garry Hi-Fi together with a remote, that had a
special function: it allowed to record the music to a pendrive
provided that the hour was even. Each new user at the beginning was
little puzzled with the feature:

1. It provided an amount of uncertainty – some customers when holding
the remote in their hands had small but causing discomfort part of
their minds focused on the question: "Is the hour odd or even?"
2. It caused disappointments when user wanted to record the music
currently being played, but the hour was odd.
3. The user's were questioning the meaningfulness of such feature
(side note: this recalls me the reactions to Intel's hyperthreading,
the "not full hardware threads")

However, over the time, point (1) basically dropped. The anxiety
simply dispersed. The point (2) resolved with "it's not that big of a
deal, with calm attitude all I need to do is simply wait approx 1 hour
to record". (3) resolved with "the feature is a must-have, it allows
me to effectively move my music to the computer or mp3 player". Who
would today want to resign from hyperthreads?


--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, back to index

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-30 17:00 A serious bug in execution – where to debug? Sebastian Gniazdowski
2019-07-30 17:05 ` Sebastian Gniazdowski
2019-07-30 17:41 ` Roman Perepelitsa
2019-07-30 17:55   ` Sebastian Gniazdowski
2019-07-30 18:12     ` Roman Perepelitsa
2019-07-30 18:16       ` Sebastian Gniazdowski
2019-07-30 18:22         ` Roman Perepelitsa
2019-07-30 18:53           ` Sebastian Gniazdowski
2019-07-30 19:23             ` Roman Perepelitsa
2019-07-30 19:34               ` Sebastian Gniazdowski
2019-07-30 19:41                 ` Roman Perepelitsa
2019-07-30 19:59                   ` Sebastian Gniazdowski
2019-07-30 20:08                     ` Roman Perepelitsa
2019-07-30 20:38                       ` Sebastian Gniazdowski
2019-07-30 18:27 ` Bart Schaefer
2019-07-30 18:46   ` Sebastian Gniazdowski
2019-07-30 21:02     ` Roman Perepelitsa
2019-07-30 21:38       ` Sebastian Gniazdowski
2019-07-30 21:45         ` Roman Perepelitsa
2019-07-30 21:54           ` Sebastian Gniazdowski
2019-07-30 22:11             ` Roman Perepelitsa
2019-07-30 22:18           ` Daniel Shahaf
2019-07-30 22:32             ` Roman Perepelitsa
2019-07-31  1:30               ` Sebastian Gniazdowski
2019-07-31  7:23                 ` Roman Perepelitsa
2019-07-31 11:41                   ` Sebastian Gniazdowski
2019-07-31 12:40                     ` Roman Perepelitsa
2019-07-31 13:10                       ` Sebastian Gniazdowski
2019-07-31 13:34                         ` Roman Perepelitsa
2019-07-31 13:40                           ` Sebastian Gniazdowski
2019-07-31 14:11                             ` Roman Perepelitsa
2019-07-31 17:56                               ` Sebastian Gniazdowski
2019-07-31  1:42               ` Bart Schaefer

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox