From: SourceForge.net <no...@so...> - 2010-10-28 01:55:47
|
Bugs item #3097011, was opened at 2010-10-28 01:55 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wayne Iba () Assigned to: Bruno Haible (haible) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |
From: SourceForge.net <no...@so...> - 2010-10-28 16:25:24
|
Bugs item #3097011, was opened at 2010-10-27 21:55 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp >Group: ANSI compliance issue >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Wayne Iba () >Assigned to: Sam Steingold (sds) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: 1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html 2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions. when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |
From: SourceForge.net <no...@so...> - 2010-10-28 18:21:45
|
Bugs item #3097011, was opened at 2010-10-28 01:55 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Wayne Iba () Assigned to: Sam Steingold (sds) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- >Comment By: Wayne Iba () Date: 2010-10-28 18:21 Message: Yes, it seems the problem is that CLISP reads the CRLF pair as #\Newline, but somehow listen doesn't get the message and reports that there is more to be read. But attempting to read then hangs because both the #\Return and #\Linefeed have been consumed. At least, that's my theory. To replicate (w/ GNU CLISP 2.44.1 Ubuntu 10.04) [23]> (setf gak (concatenate 'string "four" (string #\Return) (string #\Linefeed))) "four " [25]> (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) (#\f #\o #\u #\r #\Return #\Newline) [26]> So things are OK so far, at least with reading from the string. Create socket to another CLISP process. Send the string, gak, to the client. [28]> (format sockstream* "~A" gak) NIL [29]> On the client, attempting the similar read hangs: [5]> (loop while (listen sockstream*) collect (read-char sockstream*)) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [6]> And if we try again with a more cautious reading gives the following but (listen sockstream) still reports T but hangs when read-char [14]> (loop for i below 5 collect (read-char sockstream*)) (#\f #\o #\u #\r #\Newline) [15]> (listen sockstream*) T [16]> (read-char sockstream*) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [17]> Using SBCL as the client (but still CLISP as the server), I can drain the socket getting the list (#\f #\o #\u #\r #\Return #\Newline) I apologize if this is not a CLISP problem, but instead a problem with my sockets implementation. I'm using CLOCC (with both CLISP and SBCL). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 16:25 Message: 1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html 2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions. when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 16:25 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |
From: SourceForge.net <no...@so...> - 2010-10-28 19:16:50
|
Bugs item #3097011, was opened at 2010-10-27 21:55 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Wayne Iba () Assigned to: Sam Steingold (sds) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2010-10-28 15:16 Message: your code works just fine for me with the current clisp. it is quite possible that the bug you are reporting have been fixed since 2.44 was released a few years ago. please upgrade to clisp 2.49. ---------------------------------------------------------------------- Comment By: Wayne Iba () Date: 2010-10-28 14:21 Message: Yes, it seems the problem is that CLISP reads the CRLF pair as #\Newline, but somehow listen doesn't get the message and reports that there is more to be read. But attempting to read then hangs because both the #\Return and #\Linefeed have been consumed. At least, that's my theory. To replicate (w/ GNU CLISP 2.44.1 Ubuntu 10.04) [23]> (setf gak (concatenate 'string "four" (string #\Return) (string #\Linefeed))) "four " [25]> (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) (#\f #\o #\u #\r #\Return #\Newline) [26]> So things are OK so far, at least with reading from the string. Create socket to another CLISP process. Send the string, gak, to the client. [28]> (format sockstream* "~A" gak) NIL [29]> On the client, attempting the similar read hangs: [5]> (loop while (listen sockstream*) collect (read-char sockstream*)) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [6]> And if we try again with a more cautious reading gives the following but (listen sockstream) still reports T but hangs when read-char [14]> (loop for i below 5 collect (read-char sockstream*)) (#\f #\o #\u #\r #\Newline) [15]> (listen sockstream*) T [16]> (read-char sockstream*) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [17]> Using SBCL as the client (but still CLISP as the server), I can drain the socket getting the list (#\f #\o #\u #\r #\Return #\Newline) I apologize if this is not a CLISP problem, but instead a problem with my sockets implementation. I'm using CLOCC (with both CLISP and SBCL). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: 1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html 2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions. when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |
From: SourceForge.net <no...@so...> - 2010-10-28 21:38:58
|
Bugs item #3097011, was opened at 2010-10-28 01:55 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Wayne Iba () Assigned to: Sam Steingold (sds) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- >Comment By: Wayne Iba () Date: 2010-10-28 21:38 Message: Thanks! It works for me with 2.49. Any idea why Ubuntu bundles such an old release in 10.04? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 19:16 Message: your code works just fine for me with the current clisp. it is quite possible that the bug you are reporting have been fixed since 2.44 was released a few years ago. please upgrade to clisp 2.49. ---------------------------------------------------------------------- Comment By: Wayne Iba () Date: 2010-10-28 18:21 Message: Yes, it seems the problem is that CLISP reads the CRLF pair as #\Newline, but somehow listen doesn't get the message and reports that there is more to be read. But attempting to read then hangs because both the #\Return and #\Linefeed have been consumed. At least, that's my theory. To replicate (w/ GNU CLISP 2.44.1 Ubuntu 10.04) [23]> (setf gak (concatenate 'string "four" (string #\Return) (string #\Linefeed))) "four " [25]> (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) (#\f #\o #\u #\r #\Return #\Newline) [26]> So things are OK so far, at least with reading from the string. Create socket to another CLISP process. Send the string, gak, to the client. [28]> (format sockstream* "~A" gak) NIL [29]> On the client, attempting the similar read hangs: [5]> (loop while (listen sockstream*) collect (read-char sockstream*)) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [6]> And if we try again with a more cautious reading gives the following but (listen sockstream) still reports T but hangs when read-char [14]> (loop for i below 5 collect (read-char sockstream*)) (#\f #\o #\u #\r #\Newline) [15]> (listen sockstream*) T [16]> (read-char sockstream*) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [17]> Using SBCL as the client (but still CLISP as the server), I can drain the socket getting the list (#\f #\o #\u #\r #\Return #\Newline) I apologize if this is not a CLISP problem, but instead a problem with my sockets implementation. I'm using CLOCC (with both CLISP and SBCL). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 16:25 Message: 1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html 2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions. when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 16:25 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |
From: SourceForge.net <no...@so...> - 2010-10-29 01:07:43
|
Bugs item #3097011, was opened at 2010-10-27 21:55 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: ANSI compliance issue Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Wayne Iba () Assigned to: Sam Steingold (sds) Summary: read over socket confuses CR/LF Initial Comment: When reading over a socket, clisp reads a carriage-return/line-feed character _pair_ as a #\Newline character (single). After returning the #\Newline, (listen mysock) still reports T even when there is nothing left to return. This does not happen if reading from a string directly. ;;set up (setq foo (concatenate 'string "any thing here" (string (code-char 13)) (string (code-char 10)))) ;; then, (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) ;; reports correctly, but if you send gak over a socket and read from the socket, it will read a #\Newline (skipping over the #\Return) but (listen sock) will report T ;; with the result that any read hangs waiting for input which is not there although listen indicated there was something. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2010-10-28 21:07 Message: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504514 https://bugs.launchpad.net/ubuntu/+source/clisp/+bug/603313 ---------------------------------------------------------------------- Comment By: Wayne Iba () Date: 2010-10-28 17:38 Message: Thanks! It works for me with 2.49. Any idea why Ubuntu bundles such an old release in 10.04? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 15:16 Message: your code works just fine for me with the current clisp. it is quite possible that the bug you are reporting have been fixed since 2.44 was released a few years ago. please upgrade to clisp 2.49. ---------------------------------------------------------------------- Comment By: Wayne Iba () Date: 2010-10-28 14:21 Message: Yes, it seems the problem is that CLISP reads the CRLF pair as #\Newline, but somehow listen doesn't get the message and reports that there is more to be read. But attempting to read then hangs because both the #\Return and #\Linefeed have been consumed. At least, that's my theory. To replicate (w/ GNU CLISP 2.44.1 Ubuntu 10.04) [23]> (setf gak (concatenate 'string "four" (string #\Return) (string #\Linefeed))) "four " [25]> (with-input-from-string (is gak) (loop while (listen is) collect (read-char is))) (#\f #\o #\u #\r #\Return #\Newline) [26]> So things are OK so far, at least with reading from the string. Create socket to another CLISP process. Send the string, gak, to the client. [28]> (format sockstream* "~A" gak) NIL [29]> On the client, attempting the similar read hangs: [5]> (loop while (listen sockstream*) collect (read-char sockstream*)) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [6]> And if we try again with a more cautious reading gives the following but (listen sockstream) still reports T but hangs when read-char [14]> (loop for i below 5 collect (read-char sockstream*)) (#\f #\o #\u #\r #\Newline) [15]> (listen sockstream*) T [16]> (read-char sockstream*) ^C *** - Ctrl-C: User break The following restarts are available: ABORT :R1 Abort main loop Break 1 [17]> Using SBCL as the client (but still CLISP as the server), I can drain the socket getting the list (#\f #\o #\u #\r #\Return #\Newline) I apologize if this is not a CLISP problem, but instead a problem with my sockets implementation. I'm using CLOCC (with both CLISP and SBCL). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: 1. reading from a socket CRLF --> #\Newline: http://clisp.sourceforge.net/impnotes/clhs-newline.html 2. listen returning T and read-char hanging: cannot reproduce, please give detailed instructions. when one clisp writes foo to a socket, the other reads (#\a #\n #\y #\Space #\t #\h #\i #\n #\g #\Space #\h #\e #\r #\e #\Newline) from it, as expected. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2010-10-28 12:25 Message: This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you - the reporter - act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3097011&group_id=1355 |