Observing lags or never ending processes

Observing lags or never ending processes

[Jean Louis]

I am observing never ending processes or lags, usually I observe it
when I run some command I did not run before.

How can I capture or understand what is going on?

Is there is some command to inspect back which function was run?


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Sun, 11 Sep 2022 09:59:31 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> I am observing never ending processes or lags, usually I observe it
> when I run some command I did not run before.
> 
> How can I capture or understand what is going on?
> 
> Is there is some command to inspect back which function was run?

What do you mean by "never ending processes or lags"?  Please describe
in more detail what you do and what you see.  Also what version of
Emacs is that.

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-11 10:10]:
> What do you mean by "never ending processes or lags"?  Please describe
> in more detail what you do and what you see.  Also what version of
> Emacs is that.

Version is GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.6, Xaw3d scroll bars)
 of 2022-09-06, Repository revision:
 eaca6378d2c4b94bc70a7979642502a80bfacd11

And I observe that since months.

Basically on invokation of a command, something starts happening in
background, preventing command to run straight, and I know that it
would kind of finish execution and my command would run, but it takes
long time. Almost always I interrupt it with C-g multiple times, then
I try again.

It can also happen during writing or normal operations. I am watching
CPU load, so I see CPU load increasing.

Just before minutes, I was doing M-% replacement and then it finds one
term, I answer with `y' and then it finds another one, and so on, then
in middle of that all findings, then something starts in background,
preventing me to do the work.

My timers:

       -1d 23h 59m 51.6s           1m battery-update-handler
       -1d 23h 59m 51.9s         5.0s proced-auto-update-timer
       -1d 23h 59m 59.1s            - undo-auto--boundary-timer
              26.9s           1m display-time-event-handler
           2m 51.6s           5m persistent-scratch-save
           2m 53.7s           5m savehist-autosave
           2m 54.0s           1h url-cookie-write-file
   *           0.1s            t show-paren-function
   *           0.5s      :repeat blink-cursor-start
   *           0.5s            t #f(compiled-function () #<bytecode 0x12c5e160b85c7bfa> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
   *           1.0s            t pabbrev-short-idle-timer
   *           1.0s            t which-key--update
   *           5.0s            t pabbrev-idle-timer-function

I see that pabbrev timers are there even if global-pabbrev-mode is
off, maybe turning off that mode should remove timers as well.

Maybe it is some of them. I will try turning them off one by one
during longer periods to observe and maybe find that out.



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Sun, 11 Sep 2022 15:36:02 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> Basically on invokation of a command, something starts happening in
> background, preventing command to run straight, and I know that it
> would kind of finish execution and my command would run, but it takes
> long time. Almost always I interrupt it with C-g multiple times, then
> I try again.
> 
> It can also happen during writing or normal operations. I am watching
> CPU load, so I see CPU load increasing.
> 
> Just before minutes, I was doing M-% replacement and then it finds one
> term, I answer with `y' and then it finds another one, and so on, then
> in middle of that all findings, then something starts in background,
> preventing me to do the work.

I suggest to begin by saying

  M-x set-variable RET garbage-collection-messages RET t RET

and then see if, when "something starts in the background", you see
the telltale "Garbage collecting..." message in the echo area.

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-11 16:18]:
> I suggest to begin by saying
> 
>   M-x set-variable RET garbage-collection-messages RET t RET
> 
> and then see if, when "something starts in the background", you see
> the telltale "Garbage collecting..." message in the echo area.

I will try with this.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Jean Louis]

I have observed it now, after pressing ^ to go up the directory in
Dired. Long time passed, I was watching movie, came into Emacs and
pressed ^ -- it took many seconds until Emacs became responsive.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-11 16:18]:
> > Date: Sun, 11 Sep 2022 15:36:02 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > Basically on invokation of a command, something starts happening in
> > background, preventing command to run straight, and I know that it
> > would kind of finish execution and my command would run, but it takes
> > long time. Almost always I interrupt it with C-g multiple times, then
> > I try again.
> > 
> > It can also happen during writing or normal operations. I am watching
> > CPU load, so I see CPU load increasing.
> > 
> > Just before minutes, I was doing M-% replacement and then it finds one
> > term, I answer with `y' and then it finds another one, and so on, then
> > in middle of that all findings, then something starts in background,
> > preventing me to do the work.
> 
> I suggest to begin by saying
> 
>   M-x set-variable RET garbage-collection-messages RET t RET

I see now garbage collection about 1 time of 5 when the lag is taking
place.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Sun, 11 Sep 2022 23:21:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > I suggest to begin by saying
> > 
> >   M-x set-variable RET garbage-collection-messages RET t RET
> 
> I see now garbage collection about 1 time of 5 when the lag is taking
> place.

What is the VM size of that Emacs session, and how much VM does the
system on which it runs have?

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-12 05:27]:
> > Date: Sun, 11 Sep 2022 23:21:46 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > I suggest to begin by saying
> > > 
> > >   M-x set-variable RET garbage-collection-messages RET t RET
> > 
> > I see now garbage collection about 1 time of 5 when the lag is taking
> > place.
> 
> What is the VM size of that Emacs session, and how much VM does the
> system on which it runs have?

What is VM? 

How do I find VM?

I cannot find that term in Emacs Lisp manual.

I have 3298 buffers now. Session is 5 days 11 hours 39 minutes.

$ free

               total        used        free      shared  buff/cache   available
Mem:         7936724     6804608      399896      213864      732220      528252
Swap:        8388604     3557448     4831156

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Jean Louis]

With 8 GB of memory, I would like to optimize garbage collection in
these variables below. 

Is there some recommendation based on memory size?

Hide Gc Cons Percentage: Floating point number: 0.1
   [ State ]: CHANGED outside Customize.
   Portion of the heap used for allocation. Hide
   Garbage collection can happen automatically once this portion of the heap
   has been allocated since the last garbage collection.
   If this portion is smaller than ‘gc-cons-threshold’, this is ignored.

Hide Gc Cons Threshold: Integer: 800000
   [ State ]: STANDARD.
   Number of bytes of consing between garbage collections. Hide


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Mon, 12 Sep 2022 08:53:41 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > What is the VM size of that Emacs session, and how much VM does the
> > system on which it runs have?
> 
> What is VM? 

Virtual Memory.

> How do I find VM?

One way is "M-x proced RET", then look at the line of the Emacs
process to see its current memory footprint.

> I cannot find that term in Emacs Lisp manual.

There are many terms that aren't in the Emacs manual.  That doesn't
mean they cannot be used in discussions here.

> I have 3298 buffers now. Session is 5 days 11 hours 39 minutes.
> 
> $ free
> 
>                total        used        free      shared  buff/cache   available
> Mem:         7936724     6804608      399896      213864      732220      528252
> Swap:        8388604     3557448     4831156

Doesn't look too bad to me, but how much of the "used" part is taken
by Emacs?  Use proced to find out.

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Mon, 12 Sep 2022 10:50:57 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> With 8 GB of memory, I would like to optimize garbage collection in
> these variables below. 
> 
> Is there some recommendation based on memory size?

You will have to try-and-err, because the optimal values depend not
only on the memory of your system, but on your Emacs use patterns.  In
fact, the latter is probably much more important than the former.

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-12 14:26]:
> One way is "M-x proced RET", then look at the line of the Emacs
> process to see its current memory footprint.

  admin  8279  2.8 26.5 Sep  6 03:46:55 emacs --bg-daemon

> There are many terms that aren't in the Emacs manual.  That doesn't
> mean they cannot be used in discussions here.

Of course yes, I was thinking that VM could be virtual machine or
virtual memory and that it is related to some memory variable.

> > I have 3298 buffers now. Session is 5 days 11 hours 39 minutes.
> > 
> > $ free
> > 
> >                total        used        free      shared  buff/cache   available
> > Mem:         7936724     6804608      399896      213864      732220      528252
> > Swap:        8388604     3557448     4831156
> 
> Doesn't look too bad to me, but how much of the "used" part is taken
> by Emacs?  Use proced to find out.

See above, 26.5% 

M-x memory-report  -- never ends, it just stays there "Gathering
data..."


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-11 16:18]:
> I suggest to begin by saying
> 
>   M-x set-variable RET garbage-collection-messages RET t RET
> 
> and then see if, when "something starts in the background", you see
> the telltale "Garbage collecting..." message in the echo area.

I have observed it and I think that sometimes garbage collection is
invoked without message being visible, or maybe it wanted to show
itself but I missed it.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Fri, 16 Sep 2022 22:06:28 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2022-09-11 16:18]:
> > I suggest to begin by saying
> > 
> >   M-x set-variable RET garbage-collection-messages RET t RET
> > 
> > and then see if, when "something starts in the background", you see
> > the telltale "Garbage collecting..." message in the echo area.
> 
> I have observed it and I think that sometimes garbage collection is
> invoked without message being visible

I don't believe this is possible.

But if GC is responsible for those "lags", then it's normal Emacs
operation, and you should look into changing your use patterns and
packages you load so as to make the memory footprint of your Emacs
sessions smaller, preferably so that it is never swapped out of
physical memory.  If you customized the GC threshold to a much higher
value, lower it.  Or maybe you have some other memory-intensive
programs on your system that create situations where some of Emacs's
memory is swapped out.  These are all reasons for GC being much slower
than it's supposed to be.

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-17 09:02]:
> > Date: Fri, 16 Sep 2022 22:06:28 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2022-09-11 16:18]:
> > > I suggest to begin by saying
> > > 
> > >   M-x set-variable RET garbage-collection-messages RET t RET
> > > 
> > > and then see if, when "something starts in the background", you see
> > > the telltale "Garbage collecting..." message in the echo area.
> > 
> > I have observed it and I think that sometimes garbage collection is
> > invoked without message being visible
> 
> I don't believe this is possible.
> 
> But if GC is responsible for those "lags", then it's normal Emacs
> operation, and you should look into changing your use patterns and
> packages you load so as to make the memory footprint of your Emacs
> sessions smaller, preferably so that it is never swapped out of
> physical memory.  If you customized the GC threshold to a much higher
> value, lower it.  Or maybe you have some other memory-intensive
> programs on your system that create situations where some of Emacs's
> memory is swapped out.  These are all reasons for GC being much slower
> than it's supposed to be.

How exactly can I change use patterns?

I am human, and I cannot calculate memory and what. Does Emacs have
limit option to not load packages over specific memory?

Today I was waiting 1 hour for garbage collection, two times, before I
killed Emacs.

And M-x memory-report never returns as well.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Mon, 19 Sep 2022 21:43:57 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > But if GC is responsible for those "lags", then it's normal Emacs
> > operation, and you should look into changing your use patterns and
> > packages you load so as to make the memory footprint of your Emacs
> > sessions smaller, preferably so that it is never swapped out of
> > physical memory.  If you customized the GC threshold to a much higher
> > value, lower it.  Or maybe you have some other memory-intensive
> > programs on your system that create situations where some of Emacs's
> > memory is swapped out.  These are all reasons for GC being much slower
> > than it's supposed to be.
> 
> How exactly can I change use patterns?

How should I know?  I don't even know what are your present use
patterns, which packages you routinely load, which ones you use
frequently, how many buffers are typically present in your session,
etc. etc.

> Today I was waiting 1 hour for garbage collection, two times, before I
> killed Emacs.

Did you change the GC thresholds?  (I asked that above, but you didn't
answer.)

Re: Observing lags or never ending processes

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Today I was waiting 1 hour for garbage collection, two times, before I
> killed Emacs.

Sounds like a bug either in Emacs or in one of the packages you use
(leading to really excessive memory use).
What is the memory size of the process when it gets stuck this way?


        Stefan

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-19 22:02]:
> > How exactly can I change use patterns?
> 
> How should I know?  I don't even know what are your present use
> patterns, which packages you routinely load, which ones you use
> frequently, how many buffers are typically present in your session,
> etc. etc.

I will try to monitor it, and minimize buffers. Some buffers remain
open and it accumulates to 4000 buffers.

> > Today I was waiting 1 hour for garbage collection, two times, before I
> > killed Emacs.
> 
> Did you change the GC thresholds?  (I asked that above, but you didn't
> answer.)

For now I keep the default.

Hide Garbage Collection Messages: Boolean: [Toggle]  on (non-nil)
   [ State ]: SAVED and set.
   Non-nil means display messages at start and end of garbage collection.

Hide Gc Cons Percentage: Floating point number: 0.1
   [ State ]: SAVED and set.
   Portion of the heap used for allocation. More

Hide Gc Cons Threshold: Integer: 800000
   [ State ]: STANDARD.
   Number of bytes of consing between garbage collections. More


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Emanuel Berg]

Jean Louis wrote:

> I will try to monitor it, and minimize buffers. Some buffers
> remain open and it accumulates to 4000 buffers.

Should automate that, often when that happens it isn't that
you have 4000 buffers in general but instead there are 2-3 bad
guys that produce the bulk of them, so those are the ones you
should identify and have them explicitely kill buffer when
they are done with whatever they are doing.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Tue, 20 Sep 2022 07:42:24 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > > Today I was waiting 1 hour for garbage collection, two times, before I
> > > killed Emacs.
> > 
> > Did you change the GC thresholds?  (I asked that above, but you didn't
> > answer.)
> 
> For now I keep the default.

Then I very much doubt that those long waiting periods are due to GC.
It's something else.

The way to find out what Emacs does when it hangs like that is to
attach a debugger and produce a backtrace.

Re: Observing lags or never ending processes

[Emanuel Berg]

Eli Zaretskii wrote:

>>>> Today I was waiting 1 hour for garbage collection, two
>>>> times, before I killed Emacs.
>>> 
>>> Did you change the GC thresholds? (I asked that above, but
>>> you didn't answer.)
>> 
>> For now I keep the default.
>
> Then I very much doubt that those long waiting periods are
> due to GC. It's something else.
>
> The way to find out what Emacs does when it hangs like that
> is to attach a debugger and produce a backtrace.

Or you can use your intuition ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Observing lags or never ending processes

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2022-09-22 16:15]:
> Jean Louis wrote:
> 
> > I will try to monitor it, and minimize buffers. Some buffers
> > remain open and it accumulates to 4000 buffers.
> 
> Should automate that, often when that happens it isn't that
> you have 4000 buffers in general but instead there are 2-3 bad
> guys that produce the bulk of them, so those are the ones you
> should identify and have them explicitely kill buffer when
> they are done with whatever they are doing.

Having those buffers is convenient. Imagine list of people like
customers, then you click on one and review history, then you kill
that buffer, that is why you come back to previous one. It is
convenient.

Otherwise, I would need to pass function with arguments to newly
generated buffer to be able to remember how to construct the previous
one.

I would say, one could make some buffer function to kill the buffer if
it was not re-visited in some specific time. It would mean to install
timer for it.

Is there function which can sense that user switched to some buffer?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Jean Louis]

* Jean Louis <bugs@gnu.support> [2022-09-23 07:30]:
> * Emanuel Berg <incal@dataswamp.org> [2022-09-22 16:15]:
> > Jean Louis wrote:
> > 
> > > I will try to monitor it, and minimize buffers. Some buffers
> > > remain open and it accumulates to 4000 buffers.
> > 
> > Should automate that, often when that happens it isn't that
> > you have 4000 buffers in general but instead there are 2-3 bad
> > guys that produce the bulk of them, so those are the ones you
> > should identify and have them explicitely kill buffer when
> > they are done with whatever they are doing.
> 
> Having those buffers is convenient. Imagine list of people like
> customers, then you click on one and review history, then you kill
> that buffer, that is why you come back to previous one. It is
> convenient.
> 
> Otherwise, I would need to pass function with arguments to newly
> generated buffer to be able to remember how to construct the previous
> one.
> 
> I would say, one could make some buffer function to kill the buffer if
> it was not re-visited in some specific time. It would mean to install
> timer for it.
> 
> Is there function which can sense that user switched to some buffer?

I wish to ask if there is function that can tell that user did not
view the buffer for longer time? It is about self destruction if
unused for some time.

Then the buffer could delete itself by using timer.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Thu, 22 Sep 2022 23:30:00 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> I would say, one could make some buffer function to kill the buffer if
> it was not re-visited in some specific time. It would mean to install
> timer for it.

You are describing what midnight.el already does (if you activate it).

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-23 09:27]:
> > Date: Thu, 22 Sep 2022 23:30:00 +0300
> > From: Jean Louis <bugs@gnu.support>
> > 
> > I would say, one could make some buffer function to kill the buffer if
> > it was not re-visited in some specific time. It would mean to install
> > timer for it.
> 
> You are describing what midnight.el already does (if you activate it).

That is interesting, I read it here.

Though I do not see if midnight understands if buffer was viewed or
not. I would like to kill buffer only if it was not re-visited for
some time. 

I would not like killing buffers at midnight just because they match
some regexp. 

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Eli Zaretskii]

> Date: Fri, 23 Sep 2022 11:17:31 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > You are describing what midnight.el already does (if you activate it).
> 
> That is interesting, I read it here.
> 
> Though I do not see if midnight understands if buffer was viewed or
> not. I would like to kill buffer only if it was not re-visited for
> some time. 
> 
> I would not like killing buffers at midnight just because they match
> some regexp. 

Are you sure you've read the commentary and the doc strings in that
package carefully enough?

Re: Observing lags or never ending processes

[Emanuel Berg]

Jean Louis wrote:

> Having those buffers is convenient. Imagine list of people
> like customers, then you click on one and review history,
> then you kill that buffer, that is why you come back to
> previous one. It is convenient.

If some problem has arrived because (?) you have too many
buffers, there is no way around it but to reduce the number
of buffers.

If you want the data but cannot have the buffers, the data has
to be moved and stored somewhere else before you kill
the buffers.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Observing lags or never ending processes

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-09-23 13:45]:
> > Date: Fri, 23 Sep 2022 11:17:31 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > You are describing what midnight.el already does (if you activate it).
> > 
> > That is interesting, I read it here.
> > 
> > Though I do not see if midnight understands if buffer was viewed or
> > not. I would like to kill buffer only if it was not re-visited for
> > some time. 
> > 
> > I would not like killing buffers at midnight just because they match
> > some regexp. 
> 
> Are you sure you've read the commentary and the doc strings in that
> package carefully enough?

I was handling delirium stages due to malaria and despite that
reworked my code without sleep for 2 nights. No wonder I did not see
all what is in midnight.el

It is perfect for my needs, so I have enabled it now.



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Observing lags or never ending processes

[Emanuel Berg]

Jean Louis wrote:

> I was handling delirium stages due to malaria and despite
> that reworked my code without sleep for 2 nights.

Programmers at work!

-- 
underground experts united
https://dataswamp.org/~incal