freenode/#lisp - IRC Chatlog
Search
2:11:44
LdBeth
Unfortunately when a language is referred as xxx for children, nobody really thinks it can be used in production
2:16:11
loke
LdBeth: if you that was true. Unfortuantely people use Python in production all the time.
6:07:17
no-defun-allowed
I wouldn't be sure they're ready. Don't you know how many lines you have to read?
6:07:24
seok
Previous code I had hanged when it reached the end of output, waiting for the next output
6:08:37
no-defun-allowed
If it closes the output when it's done, (loop for line = (read-line output nil) until (null line) do (write-line line))
6:09:25
no-defun-allowed
Is there really no indication of when the output will be done? No line count or anything?
6:10:36
no-defun-allowed
Great. Maybe then you could try to wait a short time (eg 0.1 second) for a result in that case.
6:11:57
no-defun-allowed
(loop named read-loop do (loop for i = 0 to 10 do (if (listen output) (return) (sleep 0.1) finally (return-from read-loop)) do (write-line (read-line output))) is the best I can think of immediately
6:15:19
no-defun-allowed
The inner sleep loop is so that it doesn't burn CPU cycles waiting for LISTEN.
6:18:25
no-defun-allowed
Not in a tight loop like that. If you have a SLEEP form, the CL system gives up its CPU time so it's more likely the subprocess gets to be run, and in the millions of LISTEN calls the CL process will do, only a few will result in T in your case.
6:38:46
pjb
seok: listen only guarantees one character on the stream. So you can use only read-char, unless you accept to be blocked again.
6:40:35
pjb
seok: and when reading from a file or frmo a terminal, you will probably have buffering from the system or the drivers (eg. line buffering on terminals), listening on a character will stop at the end of the line, so you cannot listen to characters until you type RET in the terminal.
6:41:54
pjb
seok: if the terminal is in raw mode (no buffering), then something like (loop while (listen *terminal-io*) collect (read-char *terminal-io*)) will probably return only one character, since the user cannot type fast enough for listen to return true the second time.
6:42:49
pjb
seok: some timing may also depend on the program and its options. See for example grep --line-buffered
6:44:57
pjb
If you look at the source of slurp-stream-lines, you will see it just loops on read-line.
8:20:37
no-defun-allowed
Would anyone know if Sussman's HACKER program (from his thesis) is available to look at anywhere?