From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) by sourceware.org (Postfix) with ESMTPS id 1C5643858D31 for ; Sun, 19 Apr 2020 05:45:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1C5643858D31 Received: by mail-vs1-xe41.google.com with SMTP id t189so3874998vst.7 for ; Sat, 18 Apr 2020 22:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=lJGor6PxlBGEWFNVwuSFngmsz05x1YlS/zr49I5tGI4=; b=FNFvUudDfhhBW825tKhlErB3PYzpoLlgJBzjyuzPfwbUfmkE2E+t5IYXXRTq6ZKMvS rkDyjv/MrKK4TaR/BjDAyqSj5X4i4g/pmlbZUF+1enQsRyUmVUcllLR8GMnfatlqNs79 FNjLdrl2RCRMDVYovaFfdjJ20kM38IcxXXMF7ZXc/47as2j97d++fIwc+COJLPM6+gDf DrYhlLBrZaLPKMv703MNp72Qft9heSDxTOxDl2rmk9Pp3QdvLvJ3F/y463B6Z6yqt3J8 b2OaqNzOIuOVEWzjDJ5d+y6HgGI0PTGRSkeDLeA9aLHGxsfbpZKIuGQQ6ZtYgM8tLXl8 2+4w== X-Gm-Message-State: AGi0PuamLX8gJcfIak0X2/Y7c4f8f6h7mJXQ9fJg7Z7MDHVlnW5fNohw E7hvRWCf4M/LTYGOzuMCtpfmxTlGSupJBjMw8OXA/zxi X-Google-Smtp-Source: APiQypIEqWiuIGJLy+8gPX87B3XaTq2RAX/+MfcWiGKFzwxRIZUYNnB7bfogtANyvvcBO6UMWFqV91ujXATKwnimFCk= X-Received: by 2002:a67:7c50:: with SMTP id x77mr7839578vsc.187.1587275148145; Sat, 18 Apr 2020 22:45:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: eric@freudenthal.net From: Eric Freudenthal Date: Sat, 18 Apr 2020 23:45:34 -0600 Message-ID: Subject: unsubscribe To: cygwin@cygwin.com X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_2, HTML_MESSAGE, KAM_BADIPHTTP, KAM_UNSUB1, NUMERIC_HTTP_ADDR, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2020 05:45:51 -0000 unsubscribe On Sat, Apr 18, 2020 at 3:50 PM wrote: > Send Cygwin mailing list submissions to > cygwin@cygwin.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://cygwin.com/mailman/listinfo/cygwin > or, via email, send a message with subject or body 'help' to > cygwin-request@cygwin.com > > You can reach the person managing the list at > cygwin-owner@cygwin.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cygwin digest..." > Today's Topics: > > 1. Re: katomic and atomix will not run (Brian Inglis) > 2. Re: gfortran 9.3 write format error (Charles Russell) > 3. Re: gfortran 9.3 write format error (worsafe@bellsouth.net) > 4. Re: gfortran 9.3 write format error (worsafe@bellsouth.net) > 5. Re: gfortran 9.3 write format error (Charles Russell) > 6. Re: open write descriptor on named pipe sometime results in > ENOENT (Ken Brown) > > > > ---------- Forwarded message ---------- > From: Brian Inglis > To: cygwin@cygwin.com > Cc: > Bcc: > Date: Sat, 18 Apr 2020 11:15:22 -0600 > Subject: Re: katomic and atomix will not run > On 2020-04-18 10:20, Eliot Moss wrote: > > On 4/18/2020 11:40 AM, Phoenix Soul wrote: > >> No, I haven't. What is it and how do I run one? > >> > >> On Fri, Apr 17, 2020 at 3:23 PM Eliot Moss >> > wrote: > >> > >> On 4/17/2020 5:16 PM, Phoenix Soul via Cygwin wrote: > >> > I decided that I was going to get katomic and atomix for cygwin, > and > >> > selected the most recent version listed. > >> > atomix refuses to run and says: > >> > Unable to init server: Could not connect to 127.0.0.1 > >> : Connection refused > >> > > >> > (atomix:1495): Gtk-WARNING **: cannot open display: > >> > katomic says: > >> > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > >> > '/tmp/runtime-warri_000' > >> > qt.qpa.screen: QXcbConnection: Could not connect to display > >> > Could not connect to any X display. > >> > I have already tried using source as well. I have already pinged > 127.0.0.1 > >> > (localhost) to ensure that it does exist. What must be done to > fix it. > >> > Windows version is 8.1, and this is a no admin installation. > >> > >> ... and you have an X server already running? Maybe some details > >> about that end of things will help folks help you ... > > Shouldn't those apps also be in X11 categories to be clear? > > > Well that explains your error messages :-) ... > > > > An X server deals with the screen, and X windows applications, such as > the > > ones you're trying to run, connect to it to get their stuff displayed. > > > > The guide to X on Cygwin may be found at https://x.cygwin.com/docs/ug/. > > I also find the XLaunch program to be helpful. Maybe someone else has a > > short cookbook list of things to do or can direct you to particular > > sections of the guide ... > > They could be run against a non-Cygwin Xserver anywhere. > I think the Cygwin minimal package list for X is to install package xinit > to > pull in everything else needed for a local multi-window X server. > > -- > 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. > > > > > ---------- Forwarded message ---------- > From: Charles Russell > To: cygwin cygwin > Cc: > Bcc: > Date: Sat, 18 Apr 2020 13:13:30 -0500 > Subject: Re: gfortran 9.3 write format error > On 4/18/2020 11:23 AM, Brian Inglis wrote: > what compiler version are you using on Debian > > $ gfortran --version > GNU Fortran (Debian 8.3.0-6) 8.3.0 > > When support ended for g77 I feared for my collection of old fortran > code, but it all worked fine under gfortran after a few trivial changes > that I made years ago. (BLOCK DATA had to be rewritten, but I had used > that only once.) The gfortran developers must intend to keep viable all > that netlib code that has been widely used and thoroughly debugged. No > problems with the above gfortran version, which is newer than the most > recent one for Cygwin. So I doubt that the error message comes from > intentional compiler changes. > > Like you, I can't understand why a syntax error should appear at run > time. gfortran is good at finding syntax errors at compile time. > > I'm still using fortran 77 because it meets my needs, I know where the > bugs hide, and that is the language of most netlib code and of all my > old tools. gfortran handles it well. > > > > > ---------- Forwarded message ---------- > From: worsafe@bellsouth.net > To: cygwin cygwin > Cc: > Bcc: > Date: Sat, 18 Apr 2020 13:45:11 -0500 > Subject: Re: gfortran 9.3 write format error > Error in my last message - the current debian gfortran (8.3.0) is in > fact older than the current cygwin fortran (9.3.0). So I'll try > downgrading to 8.3.0 in cygwin. > > > > > > > ---------- Forwarded message ---------- > From: worsafe@bellsouth.net > To: cygwin cygwin > Cc: > Bcc: > Date: Sat, 18 Apr 2020 13:52:35 -0500 > Subject: Re: gfortran 9.3 write format error > There was an error in my last message In fact, the current cygwin > gfortran is 9.3.0, the current debian compiler is 8.3.0. I'll have to > reflect upon that. > > > > > > ---------- Forwarded message ---------- > From: Charles Russell > To: cygwin cygwin > Cc: > Bcc: > Date: Sat, 18 Apr 2020 15:12:20 -0500 > Subject: Re: gfortran 9.3 write format error > Problem solved (probably). > > When setting out to downgrade gfortran, I found that there was a slight > upgrade available - 9.3.0.1 to 9.3.0.2. I upgraded, ran "make clean" and > "make test". This time it ran to completion with no error message. > > Seems unlikely this minor upgrade fixed a major problem. More likely, > reinstalling gfortran was what fixed it. > > I was having similar problems with other programs, not just this one, > and time will tell whether upgrading fixed everything. > > > > > ---------- Forwarded message ---------- > From: Ken Brown > To: sten.kristian.ivarsson@gmail.com, cygwin@cygwin.com > Cc: > Bcc: > Date: Sat, 18 Apr 2020 17:48:48 -0400 > Subject: Re: open write descriptor on named pipe sometime results in ENOENT > On 4/18/2020 11:24 AM, sten.kristian.ivarsson@gmail.com wrote: > > Hey all > > > > > > We're trying to nail down some issues with using named pipes > > > > The issue we're getting is deterministic (ENXIO) but it is not this one, > but > > we think this issue is worth reporting anyway > > > > > > We're using the branch topic/fifo > > > > > > > > The program explained in short is: > > > > > > - One main (parent) pipe that lives through the whole execution > > > > - The main process forks 'children' child-processes that creates their > own > > (unique) named pipes > > > > - Each child forks 'children' grans-child-processes that just writes some > > bogus messages back to the unique child pipe > > > > - Each child writes a bogus message back to the main process > > > > - Every process creates a write and a read descriptor, but the write > > descriptor is just a dummy descriptor (to somehow keep the pipe alive > > without being bombarded with signals) > > > > - This iterates a few times > > > > > > Some of the constructs may be a bit confusing and maybe not relevant to > this > > issue, but I left them in the test-program anyway > > > > > > > > > > Issue #1 sometimes occurs in line 35 (printed as 36) we get ENOENT (No > such > > file or directory) despite that the pipe was just created and the read > > descriptor successfully was opened > > > > *wfd = open(name, O_WRONLY); > > > > > > Issue #2 sometimes occurs in line 73 (printed as 74) we get EBUSY > (Device or > > resource busy) when attempting to open a non blocking descriptor > > > > const int wfd = open(name, O_WRONLY | O_NONBLOCK); > > > > > > Issue #3 sometimes occurs somewhere unknown and the main process just get > > stuck (I've failed to reproduced that with strace or so) and to not have > any > > more input so maybe this should be left out ? > > > > > > > > I hope this is well described and hopefully it's enough to reproduce the > > issue(s) and hopefully is not due to a fault test case ;-) > > I'm just in the middle of fixing some bugs that are probably related. I > hope to > have some fixes in the next day or two, as well as better error codes. > (The > error codes are mostly translated from NTSTATUS codes and often don't > reflect > the real problem.) > > By the way, I really appreciate all your testing and bug reports. The > FIFO code > is fairly new and hasn't gotten any intense testing up to now, especially > in the > non-blocking case. > > Ken > > -- > 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 > -- Eric Freudenthal, Associate Professor, UTEP Department of Computer Science - http://www.freudenthal.net; eric@freudenthal.net; (915) 317-6246 - http://robust.cs.utep.edu/~freudent; efreudenthal@utep.edu; (915) 747-6954 - calendar: http://www.google.com/calendar/embed?src=eric.freudenthal@gmail.com