On 2020-03-12 16:49, Eliot Moss wrote:
> On 3/12/2020 5:13 PM, Brian Inglis wrote:
>> On 2020-03-11 21:36, Eliot Moss wrote:
>>> On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>>>
There are gcc bugzilla com
On Thu, 12 Mar 2020 19:01:41 -0700
Wayne Davison wrote:
> In recent Cygwin versions I've had gnu screen crash if the parent ssh
> connection closes before an explicit disconnect is performed. If an
> orderly screen disconnect happens first, future closed connections
> (after reconnecting to the scr
On Fri, 13 Mar 2020 10:03:25 +0900
Takashi Yano wrote:
> On Thu, 12 Mar 2020 20:39:39 +0100
> Achim Gratz wrote:
> > I don't really want to imagine how you came up with that observation,
> > but yes, that's the same problem I am facing. This is my current
> > workaround now:
> >
> > 1. Rename /us
In recent Cygwin versions I've had gnu screen crash if the parent ssh
connection closes before an explicit disconnect is performed. If an
orderly screen disconnect happens first, future closed connections
(after reconnecting to the screen session) no longer crash screen.
To reproduce:
I ssh into
On Thu, 12 Mar 2020 20:39:39 +0100
Achim Gratz wrote:
> I don't really want to imagine how you came up with that observation,
> but yes, that's the same problem I am facing. This is my current
> workaround now:
>
> 1. Rename /usr/share/locale to something else, like local.bak.
> 2. Start mintty i
On 3/12/2020 5:13 PM, Brian Inglis wrote:
On 2020-03-11 21:36, Eliot Moss wrote:
On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic t
Am 12.03.2020 um 20:39 schrieb Achim Gratz:
Rainer Emrich writes:
I really don't know if this the same issue. But I had similiar symptom
after upgrade from 3.0.7 to 3.1.4 on Windows 7. The mintty window pops
up, but I got no command prompt. The bash shell used all of one CPU for
ever. I tried
On 2020-03-11 21:36, Eliot Moss wrote:
> On 3/11/2020 12:30 PM, Brian Inglis wrote:
>> On 2020-03-11 00:13, Eliot Moss wrote:
>>> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
>> There are gcc bugzilla comments about requiring gcc to be built with glibc
>> libatomic to guarantee indirect inline func
Thomas Dickey writes:
> It's either recently-broken, or just coincidence :-)
I've looke and it's been introduced into newlib around four years ago,
so I'd tend to favor the coincidence camp. :-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptat
Takashi Yano via Cygwin writes:
> Achim, can you build mintty locally? If so, could you please
> apply attahed patch to mintty 3.1.4 and report the output
> in mintty window?
I guess I can, but it will take time I don't have right now. I'll see
what I can wedge in next week.
What I did figure ou
Rainer Emrich writes:
> I really don't know if this the same issue. But I had similiar symptom
> after upgrade from 3.0.7 to 3.1.4 on Windows 7. The mintty window pops
> up, but I got no command prompt. The bash shell used all of one CPU for
> ever. I tried several things. The solution after hours
On 2020-03-12 16:08, Corinna Vinschen wrote:
On Mar 12 15:44, Corinna Vinschen wrote:
On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
I think the problem is if the number of bytes requested are more than what
To clarify: number of bytes == VMIN?
no number of bytes requested from ReadFile(). A
On 2020-03-12 15:13, Corinna Vinschen wrote:
On Mar 12 14:32, Åke Rehnman via Cygwin wrote:
On 2020-03-12 12:40, Corinna Vinschen wrote:
For a start, can you please strace the problem with a simple
testcase,like this:
$ strace -o serio.trace
and send the source of your testcase as well
On Mar 12 15:44, Corinna Vinschen wrote:
> On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
> > I think the problem is if the number of bytes requested are more than what
>
> To clarify: number of bytes == VMIN?
>
> > is in the buffer it is going to overlap the read function (because of VTIME)
> >
On Thu, 12 Mar 2020 at 10:22, Takashi Yano via Cygwin
wrote:
> On Thu, 12 Mar 2020 12:51:06 +0100
> Corinna Vinschen wrote:
> > > Is there any possibility that http access will be restored?
> >
> > I don't think so, http is a no-no these days. Just change over
> > to https, you can easily fix th
On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
>
> On 2020-03-12 12:40, Corinna Vinschen wrote:
> >
> > I inspected the serial I/O read function and I only see a subtil
> > difference in terms of VMIN/VTIME which doesn't seem to be the culprit
> > at first glance. In O_NONBLOCK mode, the underly
On 2020-03-12 12:40, Corinna Vinschen wrote:
I inspected the serial I/O read function and I only see a subtil
difference in terms of VMIN/VTIME which doesn't seem to be the culprit
at first glance. In O_NONBLOCK mode, the underlying Windows function
ReadFile is called unconditionally. My cur
On Mar 12 14:32, Åke Rehnman via Cygwin wrote:
>
> On 2020-03-12 12:40, Corinna Vinschen wrote:
> >
> > For a start, can you please strace the problem with a simple
> > testcase,like this:
> >
> >$ strace -o serio.trace
> >
> > and send the source of your testcase as well as the serio.trac
On 2020-03-12 12:40, Corinna Vinschen wrote:
For a start, can you please strace the problem with a simple
testcase,like this:
$ strace -o serio.trace
and send the source of your testcase as well as the serio.trace file
here? It may show at which point the error code is generated.
Shou
On Thu, 12 Mar 2020 14:01:50 +0100
Corinna Vinschen wrote:
> I just asked overseers and it seems http access is work-in-progress
> after the switch to the new sourceware server. Only git:// or ssh:
> access work for now.
>
> However, we have a github mirror set up, so you can also just use
> that
On Mar 12 21:29, Takashi Yano via Cygwin wrote:
> On Thu, 12 Mar 2020 12:51:06 +0100
> Corinna Vinschen wrote:
> > > Is there any possibility that http access will be restored?
> >
> > I don't think so, http is a no-no these days. Just change over
> > to https, you can easily fix that in .git/con
On Thu, 12 Mar 2020 12:51:06 +0100
Corinna Vinschen wrote:
> > Is there any possibility that http access will be restored?
>
> I don't think so, http is a no-no these days. Just change over
> to https, you can easily fix that in .git/config.
https access also fails.
git clone https://cygwin.com/
On Mar 12 20:15, Takashi Yano via Cygwin wrote:
> I am not sure where this problem should be reported to, however,
> I can no longer access newlib-cygwin git repository via http.
>
> Both
> git clone http://sourceware.org/git/newlib-cygwin.git
> and
> git clone http://cygwin.com/git/newlib-cygwin.
Hi Åke,
On Mar 11 21:48, Åke Rehnman via Cygwin wrote:
> Hello all,
>
> opening a file (serial port) with O_NONBLOCK and subsequently setting
> termios VMIN and VTIME > 0 makes read() never ever return any data (returns
> EAGAIN indefinitely).
>
> Don't ask my why one would want to do something
I am not sure where this problem should be reported to, however,
I can no longer access newlib-cygwin git repository via http.
Both
git clone http://sourceware.org/git/newlib-cygwin.git
and
git clone http://cygwin.com/git/newlib-cygwin.git
fail with error:
fatal: repository 'http://sourceware.org/
On 2020-03-12 09:05, Thomas Dickey wrote:
If not "correct", it's certainly inconsistent with all other systems.
I noticed it recently:
https://invisible-island.net/ncurses/tack/CHANGES.html#t20200220
https://github.com/cygwinports/tack/issues/1
It's either recently-broken, or just coincidence
On Wed, 11 Mar 2020 20:51:42 +0100
Corinna Vinschen wrote:
> Hi Takashi,
>
> would you mind to take a look? The mutex is only used in
> fhandler_pty_master::pty_master_fwd_thread if the pseudo console is
> used. Unfortunately I don't see the faintest hint in the starce why
> this occurs. It hap
- Original Message -
| From: "Åke Rehnman"
| To: "cygwin"
| Sent: Wednesday, March 11, 2020 4:48:05 PM
| Subject: Setting termios VMIN > 0 and VTIME > 0 on non blocking file
| Hello all,
|
| opening a file (serial port) with O_NONBLOCK and subsequently setting
| termios VMIN and VTIME >
28 matches
Mail list logo
