Menu
▾
▴
clisp-devel
|
From: <cli...@li...> - 2011-04-10 12:04:39
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp: article (cli...@li...) 2. clisp: * modules/syscalls/calls.c (POSIX:SERVICE): fix non-missing (cli...@li...) 3. clisp: * modules/bindings/glibc/linux.lisp (wait, waitpid): rest... (cli...@li...) 4. clisp: (c)year (cli...@li...) 5. clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some machines S... (cli...@li...) ---------------------------------------------------------------------- Message: 1 Date: Sun, 10 Apr 2011 03:13:07 +0000 From: cli...@li... Subject: clisp: article To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/47959c01195d changeset: 15331:47959c01195d9287854cab858b83656a7617bd9f user: Sam Steingold <sd...@po...> date: 2011-04-09 23:01:26 -0400 description: article diffstat: modules/syscalls/syscalls.xml | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) ------------------------------ Message: 2 Date: Sun, 10 Apr 2011 03:13:09 +0000 From: cli...@li... Subject: clisp: * modules/syscalls/calls.c (POSIX:SERVICE): fix non-missing To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d1a83213df63 changeset: 15332:d1a83213df63d83039147478bca8949bee8c9d7f user: Sam Steingold <sd...@po...> date: 2011-04-09 23:10:52 -0400 description: * modules/syscalls/calls.c (POSIX:SERVICE): fix non-missing protocol handling (bug#3280915) diffstat: modules/syscalls/calls.c | 23 ++++++++++++----------- modules/syscalls/test.tst | 3 ++- src/ChangeLog | 5 +++++ src/NEWS | 1 + 4 files changed, 20 insertions(+), 12 deletions(-) ------------------------------ Message: 3 Date: Sun, 10 Apr 2011 05:16:42 +0000 From: cli...@li... Subject: clisp: * modules/bindings/glibc/linux.lisp (wait, waitpid): rest... To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9b07b4621357 changeset: 15333:9b07b4621357723310bb3a43bc67f2d4248448a0 user: Sam Steingold <sd...@po...> date: 2011-04-10 00:45:44 -0400 description: * modules/bindings/glibc/linux.lisp (wait, waitpid): restore (revert the 2011-03-23 patch); recommend POSIX:WITH-SUBPROCESSES in comments diffstat: modules/bindings/glibc/linux.lisp | 16 ++++++++++++++-- src/ChangeLog | 5 +++++ src/NEWS | 8 +++++--- 3 files changed, 24 insertions(+), 5 deletions(-) ------------------------------ Message: 4 Date: Sun, 10 Apr 2011 05:16:44 +0000 From: cli...@li... Subject: clisp: (c)year To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/13d99049da1c changeset: 15334:13d99049da1cf66dc67228672396ed5e5e92a3fd user: Sam Steingold <sd...@po...> date: 2011-04-10 01:04:49 -0400 description: (c)year diffstat: src/clhs.lisp | 2 +- src/condition.lisp | 2 +- src/io.d | 2 +- src/lispbibl.d | 2 +- src/sequence.d | 2 +- src/spvw.d | 2 +- src/stream.d | 2 +- src/unixaux.d | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) ------------------------------ Message: 5 Date: Sun, 10 Apr 2011 05:16:45 +0000 From: cli...@li... Subject: clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some machines S... To: cli...@li... Message-ID: <hg....@vz...> Content-Type: text/plain; charset="us-ascii" details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7 changeset: 15335:83c307059ea7b1348a7c2d62e981e902e4af7bf7 user: Sam Steingold <sd...@po...> date: 2011-04-10 01:13:42 -0400 description: * tests/socket.tst (ECONNRESET/EPIPE): on some machines SOCKET-STATUS after ECONNRESET returns :EOF and on others it returns :APPEND diffstat: tests/ChangeLog | 5 +++++ tests/socket.tst | 10 ++++------ 2 files changed, 9 insertions(+), 6 deletions(-) ------------------------------ ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 59, Issue 7 **************************************** |
|
From: <don...@is...> - 2011-04-10 16:54:28
|
This is the case where a third output value similar to eof would be useful. The result should encode the fact that neither input nor output can be done on this stream ever again. The closest value we have now would be eof, I guess, since append indicates that write would work immediately. Which machines return which values? Is this test supposed to fail in one case and succeed in the other? [BTW, I now see that the diffs can be viewed by doing hg log -v -p |more ] > Message: 5 > Date: Sun, 10 Apr 2011 05:16:45 +0000 > From: cli...@li... > Subject: clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some > machines S... > To: cli...@li... > Message-ID: > <hg....@vz...> > Content-Type: text/plain; charset="us-ascii" > > details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7 > changeset: 15335:83c307059ea7b1348a7c2d62e981e902e4af7bf7 > user: Sam Steingold <sd...@po...> > date: 2011-04-10 01:13:42 -0400 > description: > * tests/socket.tst (ECONNRESET/EPIPE): on some machines SOCKET-STATUS > after ECONNRESET returns :EOF and on others it returns :APPEND > > diffstat: > > tests/ChangeLog | 5 +++++ > tests/socket.tst | 10 ++++------ > 2 files changed, 9 insertions(+), 6 deletions(-) |
|
From: Sam S. <sd...@gn...> - 2011-04-10 17:28:09
|
> * Don Cohen <qba...@vf...> [2011-04-10 09:54:25 -0700]: > > This is the case where a third output value similar to eof would be > useful. http://www.cygwin.com/acronyms/#PTC > The result should encode the fact that neither input nor > output can be done on this stream ever again. I thought that :ERROR was for that. That's what I expected. Actually, the fact that select() does not set the error bit for the socket appears to indicate that the socket is not completely and terminally dead after ECONNRESET. > Which machines return which values? :APPEND ubuntu 10.10 Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux :EOF CentOS release 5.5 (Final) Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux what do your machines do? > Is this test supposed to fail in one case and succeed in the other? all tests are always expected to succeed. > [BTW, I now see that the diffs can be viewed by doing > hg log -v -p |more > ] you can also click on > > details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7 -- Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid) X http://mideasttruth.com http://jihadwatch.org http://memri.org http://ffii.org http://palestinefacts.org http://thereligionofpeace.com XML is like violence. If it doesn't solve the problem, use more. |
|
From: <don...@is...> - 2011-04-11 17:31:15
|
Sam Steingold writes: > > * Don Cohen <qba...@vf...> [2011-04-10 09:54:25 -0700]: > > > > This is the case where a third output value similar to eof would be > > useful. > > http://www.cygwin.com/acronyms/#PTC This seems to be closely related to the next msg about error return from socket-status and doc. My first suggested patch would be to move this statement close to the top of the doc. This is the interface to select (on some platforms, poll) ... Then to change We define status for a SOCKET:SOCKET-SERVER or a SOCKET:SOCKET-STREAM to be :ERROR if any i/o operation will cause an ERROR. to Socket-status returns :error if select finds an exceptional condition pending on any of the argument streams. (or some other version of that statement that is actually true - this is how I interpreted your reply to the doc complaint). http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful here. It says If a socket has a pending error, it shall be considered to have an exceptional condition pending. Otherwise, what constitutes an What counts as a pending error? RST? EOF? exceptional condition is file type-specific. For a file descriptor for use with a socket, it is protocol-specific except as noted below. For other file types it is implementation-defined. And then below: A socket shall be considered to have an exceptional condition pending if [... out-of-band data is pending] (I don't think I've ever even heard of the OOB feature being used.) Other circumstances under which a socket may be considered to have an exceptional condition pending are protocol-specific and implementation-defined. So I still have no ideas how to cause socket-status to return :error other than possibly trying to send OOB data. If any are known or discovered, I'd appreciate some mention of them in impnotes, and if none are known, it might be worth mentioning that as well. Also, it occurs to me to ask about this statement: Additionally, for a SOCKET:SOCKET-STREAM, we define status in the given direction (one of :INPUT, :OUTPUT, and :IO) to be Does all this apply as well to other (non-socket) streams? If you're just calling select, I'd expect so. In which case the statement should be generalized. Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens if the SOCKET:SOCKET-STREAM receives an RST packet, see tests/econnreset.lisp. This seems weird. After the reset I get: [45]> (socket-status s) [../src/stream.d:6196] *** - UNIX error 104 (ECONNRESET): Connection reset by peer The following restarts are available: ABORT :R1 Abort main loop but then Break 1 [46]> (socket-status s) :APPEND ; 1 Break 1 [46]> I'd have expected that the two successive calls (with no activity on the socket in between) would have acted the same. I guess this is related to the fact that if I try to read this stream then I get ECONNRESET the first time and EOF the second time, which I also find weird. Does the term "pending error" have something to do with whether the error has been reported by setting errno before? > > The result should encode the fact that neither input nor > > output can be done on this stream ever again. > > I thought that :ERROR was for that. > That's what I expected. I guess that depends on what select does in this case, and that seems depend on what it means for a socket to have a pending error, or else to be implementation defined. > Actually, the fact that select() does not set the error bit for the > socket appears to indicate that the socket is not completely and > terminally dead after ECONNRESET. Is "completely and terminally dead" supposed to be a technical term? It is clear that after a reset you can't get more input or send more output on the stream. But the lisp stream is still open, so in that sense it's not completely dead. > > Which machines return which values? > > :APPEND ubuntu 10.10 > Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux > > :EOF CentOS release 5.5 (Final) > Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux > > what do your machines do? The append result above comes from fedora 14. I've not yet tried the older linux version. > > Is this test supposed to fail in one case and succeed in the other? > all tests are always expected to succeed. 2.26 -(:OUTPUT "foo" :OUTPUT STREAM-ERROR :EOF ERROR :EOF END-OF-FILE) 2.27 +(:OUTPUT "foo" :OUTPUT STREAM-ERROR NIL ERROR NIL END-OF-FILE) What does this mean in terms of whether append is considered successful? > > [BTW, I now see that the diffs can be viewed by doing > > hg log -v -p |more > > ] > > you can also click on > > > > details: http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7 Thanks. |
|
From: Sam S. <sd...@gn...> - 2011-04-11 18:04:10
|
> * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]: > > My first suggested patch would be to move this statement close to the > top of the doc. > This is the interface to select (on some platforms, poll) ... we specify the underlying posix call at the _end_ of the docs for each function. > http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful > here. It says > > If a socket has a pending error, it shall be considered to have an > exceptional condition pending. Otherwise, what constitutes an > What counts as a pending error? RST? EOF? RST is an error; EOF is not. > exceptional condition is file type-specific. For a file descriptor for > use with a socket, it is protocol-specific except as noted below. For > other file types it is implementation-defined. > And then below: > A socket shall be considered to have an exceptional condition > pending if [... out-of-band data is pending] > (I don't think I've ever even heard of the OOB feature being used.) > Other circumstances under which a socket may be considered to have > an exceptional condition pending are protocol-specific and > implementation-defined. > > So I still have no ideas how to cause socket-status to return :error > other than possibly trying to send OOB data. > If any are known or discovered, I'd appreciate some mention of them > in impnotes, and if none are known, it might be worth mentioning that > as well. This is best discussed on comp.protocols.tcp-ip Please _do_ take this discussion there, and report back with your findings. > Also, it occurs to me to ask about this statement: > Additionally, for a SOCKET:SOCKET-STREAM, we define status in the > given direction (one of :INPUT, :OUTPUT, and :IO) to be > Does all this apply as well to other (non-socket) streams? > If you're just calling select, I'd expect so. In which case the > statement should be generalized. we already say at the end of the doc that this is applicable to any FD-based stream. > Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens > if the SOCKET:SOCKET-STREAM receives an RST packet, see > tests/econnreset.lisp. > This seems weird. > After the reset I get: > [45]> (socket-status s) > > [../src/stream.d:6196] > *** - UNIX error 104 (ECONNRESET): Connection reset by peer > The following restarts are available: > ABORT :R1 Abort main loop > > but then > Break 1 [46]> (socket-status s) > :APPEND ; > 1 > Break 1 [46]> > > I'd have expected that the two successive calls (with no activity on > the socket in between) would have acted the same. again, comp.protocols.tcp-ip is your friend. the translation for them: - why does select() return -1 and set errno=ECONNRESET instead of returning the socket in the errorfds set? > > Actually, the fact that select() does not set the error bit for the > > socket appears to indicate that the socket is not completely and > > terminally dead after ECONNRESET. > > Is "completely and terminally dead" supposed to be a technical term? what I mean is that no communication will ever be possible over the socket. > It is clear that after a reset you can't get more input or send more > output on the stream. It is not obvious to me. RFC793 describes situations when the recipient of RST goes into LISTEN and not ABORT states. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://dhimmi.com http://ffii.org http://palestinefacts.org http://pmw.org.il http://iris.org.il http://www.memritv.org You can have it good, soon or cheap. Pick two... |
|
From: <don...@is...> - 2011-04-11 20:08:45
|
Sam Steingold writes: > > * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]: > > > > My first suggested patch would be to move this statement close to the > > top of the doc. > > This is the interface to select (on some platforms, poll) ... > > we specify the underlying posix call at the _end_ of the docs for > each function. The meaning of :error is hard to describe without referring to select. Are forward references allowed? > > http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful > > here. It says > > > > If a socket has a pending error, it shall be considered to have an > > exceptional condition pending. Otherwise, what constitutes an > > What counts as a pending error? RST? EOF? > > RST is an error; EOF is not. In that case, rst should cause socket-status to return :error, right? > > exceptional condition is file type-specific. For a file descriptor for > > use with a socket, it is protocol-specific except as noted below. For > > other file types it is implementation-defined. > > And then below: > > A socket shall be considered to have an exceptional condition > > pending if [... out-of-band data is pending] > > (I don't think I've ever even heard of the OOB feature being used.) > > Other circumstances under which a socket may be considered to have > > an exceptional condition pending are protocol-specific and > > implementation-defined. > > > > So I still have no ideas how to cause socket-status to return :error > > other than possibly trying to send OOB data. > > If any are known or discovered, I'd appreciate some mention of them > > in impnotes, and if none are known, it might be worth mentioning that > > as well. > > This is best discussed on comp.protocols.tcp-ip > Please _do_ take this discussion there, and report back with your findings. I don't think this is a tcp question. I think it's more like posix. Or perhaps even more specific, linux, windows, etc. > > Also, it occurs to me to ask about this statement: > > Additionally, for a SOCKET:SOCKET-STREAM, we define status in the > > given direction (one of :INPUT, :OUTPUT, and :IO) to be > > Does all this apply as well to other (non-socket) streams? > > If you're just calling select, I'd expect so. In which case the > > statement should be generalized. > > we already say at the end of the doc that this is applicable to any > FD-based stream. That's not a good excuse for the text above to be misleadingly over specific. > > Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens > > if the SOCKET:SOCKET-STREAM receives an RST packet, see > > tests/econnreset.lisp. > > This seems weird. > > After the reset I get: > > [45]> (socket-status s) > > > > [../src/stream.d:6196] > > *** - UNIX error 104 (ECONNRESET): Connection reset by peer > > The following restarts are available: > > ABORT :R1 Abort main loop > > > > but then > > Break 1 [46]> (socket-status s) > > :APPEND ; > > 1 > > Break 1 [46]> > > > > I'd have expected that the two successive calls (with no activity on > > the socket in between) would have acted the same. > > again, comp.protocols.tcp-ip is your friend. > the translation for them: > - why does select() return -1 and set errno=ECONNRESET instead of > returning the socket in the errorfds set? Again, this is not related to tcp (or ip), but to the OS interface. BTW, is windows supposed to be posix compliant? (I assume linux is?) > > > Actually, the fact that select() does not set the error bit for the > > > socket appears to indicate that the socket is not completely and > > > terminally dead after ECONNRESET. > > > > Is "completely and terminally dead" supposed to be a technical term? > > what I mean is that no communication will ever be possible over the > socket. > > > It is clear that after a reset you can't get more input or send more > > output on the stream. > > It is not obvious to me. > RFC793 describes situations when the recipient of RST goes into LISTEN > and not ABORT states. Perhaps we should not use the term "socket" here but "connection". When you go into listen state you're looking for requests to start new connections. Another request to start a connection on the same socket may succeed, even from the same port on the same peer ip address, but it will be a new connection. You're supposed to send a reset for a connection when that connection, as far as you are concerned, is already dead, or never existed to begin with. |
|
From: Sam S. <sd...@gn...> - 2011-04-11 20:21:31
|
> * Don Cohen <qba...@vf...> [2011-04-11 13:08:45 -0700]: > > Sam Steingold writes: > > > * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]: > > > > > > My first suggested patch would be to move this statement close to the > > > top of the doc. > > > This is the interface to select (on some platforms, poll) ... > > > > we specify the underlying posix call at the _end_ of the docs for > > each function. > > The meaning of :error is hard to describe without referring to select. > Are forward references allowed? yes, this is lisp, not ML. > > > What counts as a pending error? RST? EOF? > > RST is an error; EOF is not. > In that case, rst should cause socket-status to return :error, right? I agree. > > This is best discussed on comp.protocols.tcp-ip > > Please _do_ take this discussion there, and report back with your findings. > > I don't think this is a tcp question. I think it's more like posix. > Or perhaps even more specific, linux, windows, etc. Whatever. This is certainly not a clisp question. I am sure comp.protocols.tcp-ip people will either answer the question straight away, or tell you where to ask. > > again, comp.protocols.tcp-ip is your friend. > > the translation for them: > > - why does select() return -1 and set errno=ECONNRESET instead of > > returning the socket in the errorfds set? > Again, this is not related to tcp (or ip), but to the OS interface. make your choice. > BTW, is windows supposed to be posix compliant? yes, if you buy a posix compatibility layer :-) > > RFC793 describes situations when the recipient of RST goes into LISTEN > > and not ABORT states. > > Perhaps we should not use the term "socket" here but "connection". > When you go into listen state you're looking for requests to start > new connections. Another request to start a connection on the same > socket may succeed, even from the same port on the same peer ip > address, but it will be a new connection. You're supposed to send a > reset for a connection when that connection, as far as you are > concerned, is already dead, or never existed to begin with. Ah, this is highly illuminating. Thanks! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://www.PetitionOnline.com/tap12009/ http://palestinefacts.org http://memri.org http://jihadwatch.org http://mideasttruth.com Live Lisp and prosper. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X