unsubscribe On Sat, Apr 18, 2020 at 3:50 PM <cygwin-requ...@cygwin.com> 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-requ...@cygwin.com > > You can reach the person managing the list at > cygwin-ow...@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 (wors...@bellsouth.net) > 4. Re: gfortran 9.3 write format error (wors...@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 <brian.ing...@systematicsw.ab.ca> > 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 <m...@cs.umass.edu > >> <mailto:m...@cs.umass.edu>> 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 > >> <http://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 <wors...@bellsouth.net> > To: cygwin cygwin <cygwin@cygwin.com> > 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: wors...@bellsouth.net > To: cygwin cygwin <cygwin@cygwin.com> > 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: wors...@bellsouth.net > To: cygwin cygwin <cygwin@cygwin.com> > 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 <wors...@bellsouth.net> > To: cygwin cygwin <cygwin@cygwin.com> > 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 <kbr...@cornell.edu> > To: sten.kristian.ivars...@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.ivars...@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; e...@freudenthal.net; (915) 317-6246 - http://robust.cs.utep.edu/~freudent; efreudent...@utep.edu; (915) 747-6954 - calendar: http://www.google.com/calendar/embed?src=eric.freudent...@gmail.com -- 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
