Greetings! Mike Thomas <[EMAIL PROTECTED]> writes:
> Hi Camm. > > Some work done - notably cleaning up the Windows GCL-TK config, > inserting some preliminary code to pretend about sigusr1 and fixing a > Windows only TCL/TK initialisation bug; but heaps to go. > Great! Thank you so much! Any word on how Tim is doing with the axiom gcl-tk interface? In any case, as soon as we get this going, I think 2.6.7 is ready. > The sticking point at the moment is as follows: > > By launching gcltkaux in gdb I find that executing connect in > sock_connect_to_name () in guis.c causes GCL to immediately return > from SYSTEM:ACCEPT-SOCKET-CONNECTION, sending the > > "source c:/cvs/head/gcl/gcl-tk/gcl.tcl" > > command to the server and causing an error in GCL before gcltkaux even > gets to check the result returned by connect (), ie well before > running TkX_Wish (): > > ======================================================================= > c:\cvs\head\gcl\gcl-tk>start gdb --args > c:/cvs/head/gcl/gcl-tk/gcltkaux 127.0.0.1 5016 2020 > > 2> (SYSTEM:ACCEPT-SOCKET-CONNECTION (880 . 5016)) > <2 (SYSTEM:ACCEPT-SOCKET-CONNECTION > (("P♥ └⌂→ └⌂→ ► > ╕♂ " > . "127.0.0.1") > 880 . 5016)) > 2> (TK::TK-CONC "source " "c:/cvs/head/gcl/gcl-tk/gcl.tcl") > <2 (TK::TK-CONC "source c:/cvs/head/gcl/gcl-tk/gcl.tcl") > 2> (TK::TK-DO "source c:/cvs/head/gcl/gcl-tk/gcl.tcl") > grab-tk-command , fill pointer 10 > with-tk-command > 3> (TK::CALL-WITH-RESULT-TYPE > " source c:/cvs/head/gcl/gcl-tk/gcl.tcl" STRING) > 4> (SYSTEM:OUR-WRITE > "P♥ └⌂→ └⌂→ ► > ╕♂ " > "♠A♣ & source c:/cvs/head/gcl/gcl-tk/gcl.tcl " 48) > Error in SYSTEM::TRACE-CALL [or a callee]: Connect failure: "" > > Fast links are on: do (use-fast-links nil) for debugging > Broken at SYSTEM:OUR-WRITE. Type :H for Help. > 1 (Continue) Return to top level. > dbl:>> > > ======================================================================= > > Looking at the last few lines of tk::tkconnect: > > ======================================================================= > ... > (if (eql pid -1) > (si::SET-SIGIO-FOR-FD (car (car *tk-connection*)))) > (setf *sigusr1* nil) > (tk-do (tk-conc "source " (namestring > (merge-pathnames "gcl-tk/gcl.tcl" si::*lib-directory*)) ))))) > ======================================================================= > > I see that if pid = -1, SIGIO (whatever that is) should be set for the > fd - on my computer this doesn't happen as pid is not -1 (not that > SIGIO means anything and I have doubts that one could attach GCL's > fake signal system to a C runtime fd anyway). > > Then *sigusr1* is set to nil and tk-do is called on the TCL command to > source "gcl.tcl". SIGIO (kernel signals for io pending) is not set on Linux either, and *sigusr1* is nil. I think this is your problem: { int n = write(sfd->fd,buf,n_to_send); if (n == n_to_send); else if (n < 0) { if (errno == EAGAIN) { goto AGAIN; } else connection_failure(""); } else abort(); } You have to make sure the socket is setup to set errno (or equivalent) to EAGAIN when the socket is not ready for writing. On Linux, this is done with O_NONBLOCK to fcntl or similar. There are several options in nsocket.c/sockets.c, e.g. set-blocking. Apparently Linux uses blocking, but the timing appears to work out. Please let me know if problems persist. Take care, > > This appears to lead ultimately to write1 () in comm.c without any > pauses based on *sigusr1* - I must have missed something (it's getting > late) as I expected somewhere in here to see code which causes the > write1 to hold off until gcltkaux is actually ready to receieve, but I > am not seeing such a mechanism (unless, of course, the SIGIO thing was > really supposed to happen - but I don't understand how GCL could > acquire a PID of -1 here either). > > Have you any advice? > > Cheers > > Mike Thomas. > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel