[ANNOUNCEMENT] Updated: mintty 3.1.6

[ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

I have uploaded mintty 3.1.6 with the following changes:

Window handling
   * Fixed resource leak when displaying images (#995).
   * Fixed crash condition on keyboard auto-repeat (#996). (Apologies 
for this one.)

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

------
Thomas

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Takashi Yano]

Hi Thomas,

On Thu, 21 May 2020 19:41:27 +0200
Thomas Wolff wrote:
> I have uploaded mintty 3.1.6 with the following changes:
> 
> Window handling
>    * Fixed resource leak when displaying images (#995).
>    * Fixed crash condition on keyboard auto-repeat (#996). (Apologies 
> for this one.)
> 
> The homepage is at http://mintty.github.io/
> It also links to the issue tracker.

After v3.1.5, the key repeat rate becomes almost halfened.
Is this behaviour by design?

The key repeat rate is about 30 chars/sec in v3.1.4, but
it is 15 chars/sec in v3.1.5 and v3.1.6.

It is little bit flustrating in editor cursor movement.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

Hi Takashi,

Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
> Hi Thomas,
>
> On Thu, 21 May 2020 19:41:27 +0200
> Thomas Wolff wrote:
>> I have uploaded mintty 3.1.6 with the following changes:
>>
>> Window handling
>>     * Fixed resource leak when displaying images (#995).
>>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
>> for this one.)
>>
>> The homepage is at http://mintty.github.io/
>> It also links to the issue tracker.
> After v3.1.5, the key repeat rate becomes almost halfened.
> Is this behaviour by design?
>
> The key repeat rate is about 30 chars/sec in v3.1.4, but
> it is 15 chars/sec in v3.1.5 and v3.1.6.
>
> It is little bit flustrating in editor cursor movement.
>
I've uploaded a commit: keyboard auto-repeat handling is now unaffected 
by default
Explanation: the new auto-repeat rate limitation with a maximum of 30 
cps (following the DECARR sequence of VT520) was effectively slowing 
down keyboards; I had the impression 30 would be enough... sorry
Thomas

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Takashi Yano]

On Fri, 22 May 2020 12:14:43 +0200
Thomas Wolff wrote:
> Hi Takashi,
> 
> Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
> > Hi Thomas,
> >
> > On Thu, 21 May 2020 19:41:27 +0200
> > Thomas Wolff wrote:
> >> I have uploaded mintty 3.1.6 with the following changes:
> >>
> >> Window handling
> >>     * Fixed resource leak when displaying images (#995).
> >>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> >> for this one.)
> >>
> >> The homepage is at http://mintty.github.io/
> >> It also links to the issue tracker.
> > After v3.1.5, the key repeat rate becomes almost halfened.
> > Is this behaviour by design?
> >
> > The key repeat rate is about 30 chars/sec in v3.1.4, but
> > it is 15 chars/sec in v3.1.5 and v3.1.6.
> >
> > It is little bit flustrating in editor cursor movement.
> >
> I've uploaded a commit: keyboard auto-repeat handling is now unaffected 
> by default
> Explanation: the new auto-repeat rate limitation with a maximum of 30 
> cps (following the DECARR sequence of VT520) was effectively slowing 
> down keyboards; I had the impression 30 would be enough... sorry

I also think 30 cps would be enough, however, the key repeat rate
is not as setting by ESC[n-p sequence. Measured results in v3.1.6
are as follows. Actual key repeat rate does not increase linearly.

^[[1-p  : 1 cps
^[[2-p  : 2 cps
^[[3-p  : 3 cps
^[[5-p  : 4.7cps
^[[10-p : 8.2cps
^[[20-p : 14.8cps
^[[30-p : 16.3cps

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Takashi Yano]

On Fri, 22 May 2020 20:01:31 +0900
Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> On Fri, 22 May 2020 12:14:43 +0200
> Thomas Wolff wrote:
> > Hi Takashi,
> > 
> > Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
> > > Hi Thomas,
> > >
> > > On Thu, 21 May 2020 19:41:27 +0200
> > > Thomas Wolff wrote:
> > >> I have uploaded mintty 3.1.6 with the following changes:
> > >>
> > >> Window handling
> > >>     * Fixed resource leak when displaying images (#995).
> > >>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> > >> for this one.)
> > >>
> > >> The homepage is at http://mintty.github.io/
> > >> It also links to the issue tracker.
> > > After v3.1.5, the key repeat rate becomes almost halfened.
> > > Is this behaviour by design?
> > >
> > > The key repeat rate is about 30 chars/sec in v3.1.4, but
> > > it is 15 chars/sec in v3.1.5 and v3.1.6.
> > >
> > > It is little bit flustrating in editor cursor movement.
> > >
> > I've uploaded a commit: keyboard auto-repeat handling is now unaffected 
> > by default
> > Explanation: the new auto-repeat rate limitation with a maximum of 30 
> > cps (following the DECARR sequence of VT520) was effectively slowing 
> > down keyboards; I had the impression 30 would be enough... sorry
> 
> I also think 30 cps would be enough, however, the key repeat rate
> is not as setting by ESC[n-p sequence. Measured results in v3.1.6
> are as follows. Actual key repeat rate does not increase linearly.
> 
> ^[[1-p  : 1 cps
> ^[[2-p  : 2 cps
> ^[[3-p  : 3 cps
> ^[[5-p  : 4.7cps
> ^[[10-p : 8.2cps
> ^[[20-p : 14.8cps
> ^[[30-p : 16.3cps

Revising code in wininput.c as follows resolve this problem.

static LONG last_key_time = 0;
static LONG last_message_time = 0;

  LONG message_time = GetMessageTime();
  LONG last_key_time_new = message_time;
  if (repeat) {
#ifdef auto_repeat_cursor_keys_option
    switch (key) {
      when VK_PRIOR ... VK_DOWN: do not return...;
    }
#endif
    if (!term.auto_repeat)
      return true;
    if (message_time - last_message_time < 2*1000/term.repeat_rate)
      /* Key repeat seems to be continued. */
      last_key_time_new = last_key_time + 1000/term.repeat_rate;
    last_message_time = message_time;
    if (message_time - last_key_time < 1000/term.repeat_rate)
      return true;
  }
  last_key_time = last_key_time_new;

^[[1-p   : 1 cps
^[[2-p   : 2 cps
^[[3-p   : 3 cps
^[[5-p   : 5 cps
^[[10-p  : 9.7cps
^[[20-p  : 19.4cps
^[[30-p  : 29.0cps

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Takashi Yano]

On Fri, 22 May 2020 21:58:00 +0900
Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> On Fri, 22 May 2020 20:01:31 +0900
> Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> > On Fri, 22 May 2020 12:14:43 +0200
> > Thomas Wolff wrote:
> > > Hi Takashi,
> > > 
> > > Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
> > > > Hi Thomas,
> > > >
> > > > On Thu, 21 May 2020 19:41:27 +0200
> > > > Thomas Wolff wrote:
> > > >> I have uploaded mintty 3.1.6 with the following changes:
> > > >>
> > > >> Window handling
> > > >>     * Fixed resource leak when displaying images (#995).
> > > >>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> > > >> for this one.)
> > > >>
> > > >> The homepage is at http://mintty.github.io/
> > > >> It also links to the issue tracker.
> > > > After v3.1.5, the key repeat rate becomes almost halfened.
> > > > Is this behaviour by design?
> > > >
> > > > The key repeat rate is about 30 chars/sec in v3.1.4, but
> > > > it is 15 chars/sec in v3.1.5 and v3.1.6.
> > > >
> > > > It is little bit flustrating in editor cursor movement.
> > > >
> > > I've uploaded a commit: keyboard auto-repeat handling is now unaffected 
> > > by default
> > > Explanation: the new auto-repeat rate limitation with a maximum of 30 
> > > cps (following the DECARR sequence of VT520) was effectively slowing 
> > > down keyboards; I had the impression 30 would be enough... sorry
> > 
> > I also think 30 cps would be enough, however, the key repeat rate
> > is not as setting by ESC[n-p sequence. Measured results in v3.1.6
> > are as follows. Actual key repeat rate does not increase linearly.
> > 
> > ^[[1-p  : 1 cps
> > ^[[2-p  : 2 cps
> > ^[[3-p  : 3 cps
> > ^[[5-p  : 4.7cps
> > ^[[10-p : 8.2cps
> > ^[[20-p : 14.8cps
> > ^[[30-p : 16.3cps
> 
> Revising code in wininput.c as follows resolve this problem.
> 
> static LONG last_key_time = 0;
> static LONG last_message_time = 0;
> 
>   LONG message_time = GetMessageTime();
>   LONG last_key_time_new = message_time;
>   if (repeat) {
> #ifdef auto_repeat_cursor_keys_option
>     switch (key) {
>       when VK_PRIOR ... VK_DOWN: do not return...;
>     }
> #endif
>     if (!term.auto_repeat)
>       return true;
>     if (message_time - last_message_time < 2*1000/term.repeat_rate)
>       /* Key repeat seems to be continued. */
>       last_key_time_new = last_key_time + 1000/term.repeat_rate;
>     last_message_time = message_time;
>     if (message_time - last_key_time < 1000/term.repeat_rate)
>       return true;
>   }
>   last_key_time = last_key_time_new;
> 
> ^[[1-p   : 1 cps
> ^[[2-p   : 2 cps
> ^[[3-p   : 3 cps
> ^[[5-p   : 5 cps
> ^[[10-p  : 9.7cps
> ^[[20-p  : 19.4cps
> ^[[30-p  : 29.0cps

The simplified following code also work as expected.
Protection for division by 0 is added as well.

static LONG last_key_time = 0;

  LONG message_time = GetMessageTime();
  if (repeat) {
#ifdef auto_repeat_cursor_keys_option
    switch (key) {
      when VK_PRIOR ... VK_DOWN: do not return...;
    }
#endif
    if (!term.auto_repeat)
      return true;
    if (term.repeat_rate &&
        message_time - last_key_time < 1000 / term.repeat_rate)
      return true;
  }
  if (term.repeat_rate &&
      message_time - last_key_time < 2*1000 / term.repeat_rate)
    /* Key repeat seems to be continued. */
    last_key_time += 1000 / term.repeat_rate;
  else
    last_key_time = message_time;

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Takashi Yano]

On Fri, 22 May 2020 22:54:05 +0900
Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> On Fri, 22 May 2020 21:58:00 +0900
> Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> > On Fri, 22 May 2020 20:01:31 +0900
> > Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> > > On Fri, 22 May 2020 12:14:43 +0200
> > > Thomas Wolff wrote:
> > > > Hi Takashi,
> > > > 
> > > > Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
> > > > > Hi Thomas,
> > > > >
> > > > > On Thu, 21 May 2020 19:41:27 +0200
> > > > > Thomas Wolff wrote:
> > > > >> I have uploaded mintty 3.1.6 with the following changes:
> > > > >>
> > > > >> Window handling
> > > > >>     * Fixed resource leak when displaying images (#995).
> > > > >>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> > > > >> for this one.)
> > > > >>
> > > > >> The homepage is at http://mintty.github.io/
> > > > >> It also links to the issue tracker.
> > > > > After v3.1.5, the key repeat rate becomes almost halfened.
> > > > > Is this behaviour by design?
> > > > >
> > > > > The key repeat rate is about 30 chars/sec in v3.1.4, but
> > > > > it is 15 chars/sec in v3.1.5 and v3.1.6.
> > > > >
> > > > > It is little bit flustrating in editor cursor movement.
> > > > >
> > > > I've uploaded a commit: keyboard auto-repeat handling is now unaffected 
> > > > by default
> > > > Explanation: the new auto-repeat rate limitation with a maximum of 30 
> > > > cps (following the DECARR sequence of VT520) was effectively slowing 
> > > > down keyboards; I had the impression 30 would be enough... sorry
> > > 
> > > I also think 30 cps would be enough, however, the key repeat rate
> > > is not as setting by ESC[n-p sequence. Measured results in v3.1.6
> > > are as follows. Actual key repeat rate does not increase linearly.
> > > 
> > > ^[[1-p  : 1 cps
> > > ^[[2-p  : 2 cps
> > > ^[[3-p  : 3 cps
> > > ^[[5-p  : 4.7cps
> > > ^[[10-p : 8.2cps
> > > ^[[20-p : 14.8cps
> > > ^[[30-p : 16.3cps
> > 
> > Revising code in wininput.c as follows resolve this problem.
> > 
> > static LONG last_key_time = 0;
> > static LONG last_message_time = 0;
> > 
> >   LONG message_time = GetMessageTime();
> >   LONG last_key_time_new = message_time;
> >   if (repeat) {
> > #ifdef auto_repeat_cursor_keys_option
> >     switch (key) {
> >       when VK_PRIOR ... VK_DOWN: do not return...;
> >     }
> > #endif
> >     if (!term.auto_repeat)
> >       return true;
> >     if (message_time - last_message_time < 2*1000/term.repeat_rate)
> >       /* Key repeat seems to be continued. */
> >       last_key_time_new = last_key_time + 1000/term.repeat_rate;
> >     last_message_time = message_time;
> >     if (message_time - last_key_time < 1000/term.repeat_rate)
> >       return true;
> >   }
> >   last_key_time = last_key_time_new;
> > 
> > ^[[1-p   : 1 cps
> > ^[[2-p   : 2 cps
> > ^[[3-p   : 3 cps
> > ^[[5-p   : 5 cps
> > ^[[10-p  : 9.7cps
> > ^[[20-p  : 19.4cps
> > ^[[30-p  : 29.0cps
> 
> The simplified following code also work as expected.
> Protection for division by 0 is added as well.
> 
> static LONG last_key_time = 0;
> 
>   LONG message_time = GetMessageTime();
>   if (repeat) {
> #ifdef auto_repeat_cursor_keys_option
>     switch (key) {
>       when VK_PRIOR ... VK_DOWN: do not return...;
>     }
> #endif
>     if (!term.auto_repeat)
>       return true;
>     if (term.repeat_rate &&
>         message_time - last_key_time < 1000 / term.repeat_rate)
>       return true;
>   }
>   if (term.repeat_rate &&
>       message_time - last_key_time < 2*1000 / term.repeat_rate)
>     /* Key repeat seems to be continued. */
>     last_key_time += 1000 / term.repeat_rate;
>   else
>     last_key_time = message_time;

Sorry again and again. After all, the code above doesn't work
as expected. I would like to propose the code below.

static LONG last_key_time = 0;

  LONG message_time = GetMessageTime();
  if (repeat) {
#ifdef auto_repeat_cursor_keys_option
    switch (key) {
      when VK_PRIOR ... VK_DOWN: do not return...;
    }
#endif
    if (!term.auto_repeat)
      return true;
    if (term.repeat_rate &&
        message_time - last_key_time < 1000 / term.repeat_rate)
      return true;
  }
  if (term.repeat_rate && repeat &&
      message_time - last_key_time < 2*1000 / term.repeat_rate)
    /* Key repeat seems to be continued. */
    last_key_time += 1000 / term.repeat_rate;
  else
    last_key_time = message_time;

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

Am 22.05.2020 um 16:56 schrieb Takashi Yano via Cygwin:
> On Fri, 22 May 2020 22:54:05 +0900
> Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
>> On Fri, 22 May 2020 21:58:00 +0900
>> Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
>>> On Fri, 22 May 2020 20:01:31 +0900
>>> Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
>>>> On Fri, 22 May 2020 12:14:43 +0200
>>>> Thomas Wolff wrote:
>>>>> Hi Takashi,
>>>>>
>>>>> Am 22.05.2020 um 11:22 schrieb Takashi Yano via Cygwin:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> On Thu, 21 May 2020 19:41:27 +0200
>>>>>> Thomas Wolff wrote:
>>>>>>> I have uploaded mintty 3.1.6 with the following changes:
>>>>>>>
>>>>>>> Window handling
>>>>>>>      * Fixed resource leak when displaying images (#995).
>>>>>>>      * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
>>>>>>> for this one.)
>>>>>>>
>>>>>>> The homepage is at http://mintty.github.io/
>>>>>>> It also links to the issue tracker.
>>>>>> After v3.1.5, the key repeat rate becomes almost halfened.
>>>>>> Is this behaviour by design?
>>>>>>
>>>>>> The key repeat rate is about 30 chars/sec in v3.1.4, but
>>>>>> it is 15 chars/sec in v3.1.5 and v3.1.6.
>>>>>>
>>>>>> It is little bit flustrating in editor cursor movement.
>>>>>>
>>>>> I've uploaded a commit: keyboard auto-repeat handling is now unaffected
>>>>> by default
>>>>> Explanation: the new auto-repeat rate limitation with a maximum of 30
>>>>> cps (following the DECARR sequence of VT520) was effectively slowing
>>>>> down keyboards; I had the impression 30 would be enough... sorry
>>>> I also think 30 cps would be enough, however, the key repeat rate
>>>> is not as setting by ESC[n-p sequence. Measured results in v3.1.6
>>>> are as follows. Actual key repeat rate does not increase linearly.
>>>>
>>>> ^[[1-p  : 1 cps
>>>> ^[[2-p  : 2 cps
>>>> ^[[3-p  : 3 cps
>>>> ^[[5-p  : 4.7cps
>>>> ^[[10-p : 8.2cps
>>>> ^[[20-p : 14.8cps
>>>> ^[[30-p : 16.3cps
>>> Revising code in wininput.c as follows resolve this problem.
>>>
>>> static LONG last_key_time = 0;
>>> static LONG last_message_time = 0;
>>>
>>>    LONG message_time = GetMessageTime();
>>>    LONG last_key_time_new = message_time;
>>>    if (repeat) {
>>> #ifdef auto_repeat_cursor_keys_option
>>>      switch (key) {
>>>        when VK_PRIOR ... VK_DOWN: do not return...;
>>>      }
>>> #endif
>>>      if (!term.auto_repeat)
>>>        return true;
>>>      if (message_time - last_message_time < 2*1000/term.repeat_rate)
>>>        /* Key repeat seems to be continued. */
>>>        last_key_time_new = last_key_time + 1000/term.repeat_rate;
>>>      last_message_time = message_time;
>>>      if (message_time - last_key_time < 1000/term.repeat_rate)
>>>        return true;
>>>    }
>>>    last_key_time = last_key_time_new;
>>>
>>> ^[[1-p   : 1 cps
>>> ^[[2-p   : 2 cps
>>> ^[[3-p   : 3 cps
>>> ^[[5-p   : 5 cps
>>> ^[[10-p  : 9.7cps
>>> ^[[20-p  : 19.4cps
>>> ^[[30-p  : 29.0cps
>> The simplified following code also work as expected.
>> Protection for division by 0 is added as well.
>>
>> static LONG last_key_time = 0;
>>
>>    LONG message_time = GetMessageTime();
>>    if (repeat) {
>> #ifdef auto_repeat_cursor_keys_option
>>      switch (key) {
>>        when VK_PRIOR ... VK_DOWN: do not return...;
>>      }
>> #endif
>>      if (!term.auto_repeat)
>>        return true;
>>      if (term.repeat_rate &&
>>          message_time - last_key_time < 1000 / term.repeat_rate)
>>        return true;
>>    }
>>    if (term.repeat_rate &&
>>        message_time - last_key_time < 2*1000 / term.repeat_rate)
>>      /* Key repeat seems to be continued. */
>>      last_key_time += 1000 / term.repeat_rate;
>>    else
>>      last_key_time = message_time;
> Sorry again and again. After all, the code above doesn't work
> as expected. I would like to propose the code below.
>
> static LONG last_key_time = 0;
>
>    LONG message_time = GetMessageTime();
>    if (repeat) {
> #ifdef auto_repeat_cursor_keys_option
>      switch (key) {
>        when VK_PRIOR ... VK_DOWN: do not return...;
>      }
> #endif
>      if (!term.auto_repeat)
>        return true;
>      if (term.repeat_rate &&
>          message_time - last_key_time < 1000 / term.repeat_rate)
>        return true;
>    }
>    if (term.repeat_rate && repeat &&
>        message_time - last_key_time < 2*1000 / term.repeat_rate)
>      /* Key repeat seems to be continued. */
>      last_key_time += 1000 / term.repeat_rate;
>    else
>      last_key_time = message_time;
Thank you, I've uploaded that version.
Thomas

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[David Dombrowsky]

This version now coredumps on my machine.  This is on a 32-bit
machine.  Is this the final nail in the coffin for 32-bit?

[2000] davek@davek-win:~>mintty
*** stack smashing detected ***: terminated
Aborted (core dumped)
Stack trace:
Frame     Function  Args
0022C2CC  610239CC (0000023C, 0000EA60, 000000A4, 0022C33C)
0022C3FC  6110247A (0022C41C, 002FBFE0, 00000012, 0000000D)
0022C418  6112C582 (0000028E, 000303E9, 00000000, 00000000)

[2006] davek@davek-win:~/winhome/Desktop>mintty --version
mintty 3.1.6 (i686-pc-cygwin)
© 2013/2019 Andy Koppe / Thomas Wolff
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.

On Thu, May 21, 2020 at 2:28 PM Thomas Wolff <towo@towo.net> wrote:
>
> I have uploaded mintty 3.1.6 with the following changes:
>
> Window handling
>    * Fixed resource leak when displaying images (#995).
>    * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> for this one.)
>
> The homepage is at http://mintty.github.io/
> It also links to the issue tracker.
>
> ------
> Thomas
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple



-- 
David Dombrowsky, Senior Software Engineer
email: davek@6thstreetradio.org
Cell: 518-374-3204
https://www.linkedin.com/in/david-dombrowsky-94334415
http://6thstreetradio.org/

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

Am 26.05.2020 um 16:30 schrieb David Dombrowsky via Cygwin:
> This version now coredumps on my machine.  This is on a 32-bit
> machine.  Is this the final nail in the coffin for 32-bit?
Of course not. Mintty actually still runs on Windows XP and even Windows 
2000.
However, bugs happen and I guess you're running Windows 7 where 3.1.6 
would crash. Fixed in the repository already.
Thomas

> [2000] davek@davek-win:~>mintty
> *** stack smashing detected ***: terminated
> Aborted (core dumped)
> Stack trace:
> Frame     Function  Args
> 0022C2CC  610239CC (0000023C, 0000EA60, 000000A4, 0022C33C)
> 0022C3FC  6110247A (0022C41C, 002FBFE0, 00000012, 0000000D)
> 0022C418  6112C582 (0000028E, 000303E9, 00000000, 00000000)
>
> [2006] davek@davek-win:~/winhome/Desktop>mintty --version
> mintty 3.1.6 (i686-pc-cygwin)
> © 2013/2019 Andy Koppe / Thomas Wolff
> License GPLv3+: GNU GPL version 3 or later
> There is no warranty, to the extent permitted by law.
>
> On Thu, May 21, 2020 at 2:28 PM Thomas Wolff <towo@towo.net> wrote:
>> I have uploaded mintty 3.1.6 with the following changes:
>>
>> Window handling
>>     * Fixed resource leak when displaying images (#995).
>>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
>> for this one.)
>>
>> The homepage is at http://mintty.github.io/
>> It also links to the issue tracker.
>>
>> ------
>> Thomas
>> --
>> Problem reports:      https://cygwin.com/problems.html
>> FAQ:                  https://cygwin.com/faq/
>> Documentation:        https://cygwin.com/docs.html
>> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
>
>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Randall Nutz]

I have had issues with 3.1.6 core dump crashes on Win7 32b, Win7 64bit &
Win10 both 32 & 64. I fought this all weekend. I ended up rolling back to
3.1.4 (3.1.5 also dumped) all this with Cygwin 32bit.
Unfortunately, we have an application that depends on 32 bit Cygwin.

On Tue, May 26, 2020 at 10:05 AM Thomas Wolff <towo@towo.net> wrote:

> Am 26.05.2020 um 16:30 schrieb David Dombrowsky via Cygwin:
> > This version now coredumps on my machine.  This is on a 32-bit
> > machine.  Is this the final nail in the coffin for 32-bit?
> Of course not. Mintty actually still runs on Windows XP and even Windows
> 2000.
> However, bugs happen and I guess you're running Windows 7 where 3.1.6
> would crash. Fixed in the repository already.
> Thomas
>
> > [2000] davek@davek-win:~>mintty
> > *** stack smashing detected ***: terminated
> > Aborted (core dumped)
> > Stack trace:
> > Frame     Function  Args
> > 0022C2CC  610239CC (0000023C, 0000EA60, 000000A4, 0022C33C)
> > 0022C3FC  6110247A (0022C41C, 002FBFE0, 00000012, 0000000D)
> > 0022C418  6112C582 (0000028E, 000303E9, 00000000, 00000000)
> >
> > [2006] davek@davek-win:~/winhome/Desktop>mintty --version
> > mintty 3.1.6 (i686-pc-cygwin)
> > © 2013/2019 Andy Koppe / Thomas Wolff
> > License GPLv3+: GNU GPL version 3 or later
> > There is no warranty, to the extent permitted by law.
> >
> > On Thu, May 21, 2020 at 2:28 PM Thomas Wolff <towo@towo.net> wrote:
> >> I have uploaded mintty 3.1.6 with the following changes:
> >>
> >> Window handling
> >>     * Fixed resource leak when displaying images (#995).
> >>     * Fixed crash condition on keyboard auto-repeat (#996). (Apologies
> >> for this one.)
> >>
> >> The homepage is at http://mintty.github.io/
> >> It also links to the issue tracker.
> >>
> >> ------
> >> Thomas
> >> --
> >> Problem reports:      https://cygwin.com/problems.html
> >> FAQ:                  https://cygwin.com/faq/
> >> Documentation:        https://cygwin.com/docs.html
> >> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
> >
> >
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

Am 26.05.2020 um 17:15 schrieb Randall Nutz:
> I have had issues with 3.1.6 core dump crashes on Win7 32b, Win7 64bit 
> & Win10 both 32 & 64. I fought this all weekend.
Please report the Windows 10 versions on which you experience this: cmd 
/c ver

> I ended up rolling back to 3.1.4 (3.1.5 also dumped) all this with 
> Cygwin 32bit.
> Unfortunately, we have an application that depends on 32 bit Cygwin.
Don't worry, there are no plans to neglect 32-bit support in mintty.
For your application, however, consider that cygwin 32-bit support seems 
to be fading in general as cygwin 32-bit is said to be less stable (due 
to library address conflicts), so it may be worth considering an upgrade 
of the application.


> On Tue, May 26, 2020 at 10:05 AM Thomas Wolff <towo@towo.net 
> <mailto:towo@towo.net>> wrote:
>
>     Am 26.05.2020 um 16:30 schrieb David Dombrowsky via Cygwin:
>     > This version now coredumps on my machine.  This is on a 32-bit
>     > machine.  Is this the final nail in the coffin for 32-bit?
>     Of course not. Mintty actually still runs on Windows XP and even
>     Windows
>     2000.
>     However, bugs happen and I guess you're running Windows 7 where 3.1.6
>     would crash. Fixed in the repository already.
>     Thomas
>
>     > [2000] davek@davek-win:~>mintty
>     > *** stack smashing detected ***: terminated
>     > Aborted (core dumped)
>     > Stack trace:
>     > Frame     Function  Args
>     > 0022C2CC  610239CC (0000023C, 0000EA60, 000000A4, 0022C33C)
>     > 0022C3FC  6110247A (0022C41C, 002FBFE0, 00000012, 0000000D)
>     > 0022C418  6112C582 (0000028E, 000303E9, 00000000, 00000000)
>     >
>     > [2006] davek@davek-win:~/winhome/Desktop>mintty --version
>     > mintty 3.1.6 (i686-pc-cygwin)
>     > © 2013/2019 Andy Koppe / Thomas Wolff
>     > License GPLv3+: GNU GPL version 3 or later
>     > There is no warranty, to the extent permitted by law.
>     >
>     > On Thu, May 21, 2020 at 2:28 PM Thomas Wolff <towo@towo.net
>     <mailto:towo@towo.net>> wrote:
>     >> I have uploaded mintty 3.1.6 with the following changes:
>     >>
>     >> Window handling
>     >>     * Fixed resource leak when displaying images (#995).
>     >>     * Fixed crash condition on keyboard auto-repeat (#996).
>     (Apologies
>     >> for this one.)
>     >>
>     >> The homepage is at http://mintty.github.io/
>     >> It also links to the issue tracker.
>     >>
>     >> ------
>     >> Thomas
>     >> --
>     >> Problem reports: https://cygwin.com/problems.html
>     >> FAQ: https://cygwin.com/faq/
>     >> Documentation: https://cygwin.com/docs.html
>     >> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>     >
>     >
>
>     --
>     Problem reports: https://cygwin.com/problems.html
>     FAQ: https://cygwin.com/faq/
>     Documentation: https://cygwin.com/docs.html
>     Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Thomas Wolff]

[including CC to the list again to catch-up for the discussion there; 
and please remember not to "top-post" if you respond there]

Am 26.05.2020 um 18:53 schrieb Randall Nutz:
> I made several attempts on different installations.
> One is Version 10.0.10240 (32bit) On this one, right after reading 
> your post indicating the repo was updated, I re-ran setup to update 
> Mintty to the latest which shows to be 3.1.6-1.  This version still 
> dumped.
Repository refers to the github home of mintty 
(https://github.com/mintty/mintty/), it's not yet a cygwin package.
You could download from there and compile a version.

> The other is Version 10.0.15063 (64bit).
Thanks for the info. Both versions are really *very* outdated. Yet it's 
valuable to know certain things don't work there. Mintty will be adapted.

> I am unable to play around in this instance as I have an active user 
> on it with a deadline.
> If/when I have time today, I'll create another one with this OS 
> version and test it.
> /Randall
>
> On Tue, May 26, 2020 at 10:31 AM Thomas Wolff <towo@towo.net 
> <mailto:towo@towo.net>> wrote:
>
>     Am 26.05.2020 um 17:15 schrieb Randall Nutz:
>>     I have had issues with 3.1.6 core dump crashes on Win7 32b, Win7
>>     64bit & Win10 both 32 & 64. I fought this all weekend.
>     Please report the Windows 10 versions on which you experience
>     this: cmd /c ver
>
>>     I ended up rolling back to 3.1.4 (3.1.5 also dumped) all this
>>     with Cygwin 32bit.
>>     Unfortunately, we have an application that depends on 32 bit Cygwin.
>     Don't worry, there are no plans to neglect 32-bit support in mintty.
>     For your application, however, consider that cygwin 32-bit support
>     seems to be fading in general as cygwin 32-bit is said to be less
>     stable (due to library address conflicts), so it may be worth
>     considering an upgrade of the application.
>
>
>>     On Tue, May 26, 2020 at 10:05 AM Thomas Wolff <towo@towo.net
>>     <mailto:towo@towo.net>> wrote:
>>
>>         Am 26.05.2020 um 16:30 schrieb David Dombrowsky via Cygwin:
>>         > This version now coredumps on my machine.  This is on a 32-bit
>>         > machine.  Is this the final nail in the coffin for 32-bit?
>>         Of course not. Mintty actually still runs on Windows XP and
>>         even Windows
>>         2000.
>>         However, bugs happen and I guess you're running Windows 7
>>         where 3.1.6
>>         would crash. Fixed in the repository already.
>>         Thomas
>>
>>         > [2000] davek@davek-win:~>mintty
>>         > *** stack smashing detected ***: terminated
>>         > Aborted (core dumped)
>>         > Stack trace:
>>         > Frame     Function  Args
>>         > 0022C2CC  610239CC (0000023C, 0000EA60, 000000A4, 0022C33C)
>>         > 0022C3FC  6110247A (0022C41C, 002FBFE0, 00000012, 0000000D)
>>         > 0022C418  6112C582 (0000028E, 000303E9, 00000000, 00000000)
>>         >
>>         > [2006] davek@davek-win:~/winhome/Desktop>mintty --version
>>         > mintty 3.1.6 (i686-pc-cygwin)
>>         > © 2013/2019 Andy Koppe / Thomas Wolff
>>         > License GPLv3+: GNU GPL version 3 or later
>>         > There is no warranty, to the extent permitted by law.
>>         >
>>         > On Thu, May 21, 2020 at 2:28 PM Thomas Wolff <towo@towo.net
>>         <mailto:towo@towo.net>> wrote:
>>         >> I have uploaded mintty 3.1.6 with the following changes:
>>         >>
>>         >> Window handling
>>         >>     * Fixed resource leak when displaying images (#995).
>>         >>     * Fixed crash condition on keyboard auto-repeat
>>         (#996). (Apologies
>>         >> for this one.)
>>         >>
>>         >> The homepage is at http://mintty.github.io/
>>         >> It also links to the issue tracker.
>>         >>
>>         >> ------
>>         >> Thomas
>>         >> --
>>         >> Problem reports: https://cygwin.com/problems.html
>>         >> FAQ: https://cygwin.com/faq/
>>         >> Documentation: https://cygwin.com/docs.html
>>         >> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>>         >
>>         >
>>
>>         --
>>         Problem reports: https://cygwin.com/problems.html
>>         FAQ: https://cygwin.com/faq/
>>         Documentation: https://cygwin.com/docs.html
>>         Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>>
>

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Maarten Hoes]

On Tue, May 26, 2020 at 7:36 PM Thomas Wolff <towo@towo.net> wrote:

> and please remember not to "top-post" if you respond there]
>
>
[not aimed at you specifically, but ]

Owwwh, for the love of ***, can 'we' be at least a little more lenient
about this ? I fully realize that people have their clear preferences here,
but [like the 'indent by spaces or tabs' discussion]:

The eighties called, and they want they're discussion back.


- Maarten

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Marco Atzeri]

On 26.05.2020 21:16, Maarten Hoes via Cygwin wrote:
> On Tue, May 26, 2020 at 7:36 PM Thomas Wolff  wrote:
> 
>> and please remember not to "top-post" if you respond there]
>>
>>
> [not aimed at you specifically, but ]
> 
> Owwwh, for the love of ***, can 'we' be at least a little more lenient
> about this ? I fully realize that people have their clear preferences here,
> but [like the 'indent by spaces or tabs' discussion]:
> 
> The eighties called, and they want they're discussion back.
> 
> 
> - Maarten

Hi Marteen,
in reality, now we are very lenient and mild

We had in old times much stronger enforcement of netiquette rules

Regards
Marco

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Maarten Hoes]

On Tue, May 26, 2020 at 9:58 PM Marco Atzeri via Cygwin <cygwin@cygwin.com>
wrote:

> On 26.05.2020 21:16, Maarten Hoes via Cygwin wrote:
> > On Tue, May 26, 2020 at 7:36 PM Thomas Wolff  wrote:
> >
> >> and please remember not to "top-post" if you respond there]
> >>
> >>
> > [not aimed at you specifically, but ]
> >
> > Owwwh, for the love of ***, can 'we' be at least a little more lenient
> > about this ? I fully realize that people have their clear preferences
> here,
> > but [like the 'indent by spaces or tabs' discussion]:
> >
> > The eighties called, and they want they're discussion back.
> >
> >
> > - Maarten
>
> Hi Marteen,
> in reality, now we are very lenient and mild
>
> We had in old times much stronger enforcement of netiquette rules
>
>
Hi,

Thanks for the kind response. I just thought that in this day and age, we
had better issues to discuss and/or argue over than things like 'indent
tabs/spaces' or 'top/bottom posting'.

 I'll crawl back under my rock now,


- Maarten

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Brian Inglis]

On 2020-05-26 13:16, Maarten Hoes via Cygwin wrote:
> On Tue, May 26, 2020 at 7:36 PM Thomas Wolff wrote:
>> and please remember not to "top-post" if you respond there]
> [not aimed at you specifically, but ]
> Owwwh, for the love of ***, can 'we' be at least a little more lenient
> about this? I fully realize that people have their clear preferences here,
> but [like the 'indent by spaces or tabs' discussion]:
> The eighties called, and they want they're discussion back.

[Please trim email addresses from bodies so they do not appear in archives!]

Outlook TOFU email posting style is manageable for a one-on-one personal email
thread, but it's a mess when you have posters providing minimal information in
each response to requests for more info, from multiple volunteer respondents who
would like to understand enough to help, or multiple subthreads with followups
in different directions.

Some maintainers are extremely busy with limited time to either respond here, or
upgrade or diagnose and fix problems with packages, so just won't respond to
TOFU, posters who provide insufficient information, or think there is a company
or employees providing Cygwin products and support, rather than all being
volunteers, and who expect or demand immediate "mystical" support in response to
a message like "something broke and we think it might be Cygwin".

Others here will try to pry enough information from posters to point them in a
useful direction, or provide enough comprehensible information in a format that
busy maintainers can quickly read and address an issue with a package.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: mintty 3.1.6

[Maarten Hoes]

On Tue, May 26, 2020 at 10:43 PM Brian Inglis

> On 2020-05-26 13:16, Maarten Hoes via Cygwin wrote:
> > On Tue, May 26, 2020 at 7:36 PM Thomas Wolff wrote:
> >> and please remember not to "top-post" if you respond there]
> > [not aimed at you specifically, but ]
> > Owwwh, for the love of ***, can 'we' be at least a little more lenient
> > about this? I fully realize that people have their clear preferences
> here,
> > but [like the 'indent by spaces or tabs' discussion]:
> > The eighties called, and they want they're discussion back.
>
> [Please trim email addresses from bodies so they do not appear in
> archives!]
>
> Outlook TOFU email posting style is manageable for a one-on-one personal
> email
> thread, but it's a mess when you have posters providing minimal
> information in
> each response to requests for more info, from multiple volunteer
> respondents who
> would like to understand enough to help, or multiple subthreads with
> followups
> in different directions.
>
> Some maintainers are extremely busy with limited time to either respond
> here, or
> upgrade or diagnose and fix problems with packages, so just won't respond
> to
> TOFU, posters who provide insufficient information, or think there is a
> company
> or employees providing Cygwin products and support, rather than all being
> volunteers, and who expect or demand immediate "mystical" support in
> response to
> a message like "something broke and we think it might be Cygwin".
>
> Others here will try to pry enough information from posters to point them
> in a
> useful direction, or provide enough comprehensible information in a format
> that
> busy maintainers can quickly read and address an issue with a package.
>
>
Hi,

(I honestly did not mean to hijack this thread, but unintentionally seem to
have done so anyway, sorry for that).

Although I fully understand all of these points (like but not limited to
[unrealistically] expecting there to be fully paid support personal
responding to posts like 'cygwin does not wrk! please fix asap!)'

My only remark was about; does it really matter if:

top posters do :
this is my reaction
> this was the original post

or:
> this was the original post
this is my reaction


That's all folks.


- Maarten