nullcone has quit [Quit: Connection closed for inactivity]
makomo has joined #slime
<makomo>
hello. why does, using sbcl for example, (interactive-stream-p *standard-input*) return nil when using slime, but return t when using sbcl's repl (with sbcl started outside of emacs)?
<makomo>
shouldn't slime's standard input count as interactive as well?
<pjb>
makomo: perhaps, but it's a swank/gray::slime-input-stream
<pjb>
Is there a way in gray streams to mark a stream as interactive?
<makomo>
i'm not sure, but i think it might have to do with the underlying sbcl streams perhaps?
<pjb>
that said nothing guarantees that the data coming into a swank/gray::slime-input-stream swank/gray::slime-input-stream comes from an interative source.
<makomo>
in my .swank.lisp i have a little bit of code which captures the original io variables' values before swank applies its global redirections
<pjb>
The stream itself can be said to be non-interactive, since it doesn't depend on the user, but on another process.
<makomo>
running (i-s-p *old-standard-input*) return nil as well
<makomo>
returns*
<pjb>
Again, check it's value and type!
<pjb>
s/it's/its/
<makomo>
mhm, i did. it's a #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {1000025923}>
<pjb>
I bet SB-SYS:*STDIN* is interactive.
<makomo>
nope, sadly not :(
<makomo>
just tested it
<makomo>
but surely (i-s-p *old-standard-input*) wouldn't return nil if the underlying stream was interactive
<makomo>
pjb: what do you mean it depends on another process? does it depend on the user sitting at the slime repl at the very end of the chain?
<makomo>
doesn't*
<pjb>
"The precise meaning of an interactive stream is implementation-defined, and may depend on the underlying operating system."a
<pjb>
makomo: the interactive process is the emacs process!
<pjb>
makomo: the CL process has a socket stream connected to the emacs process.
<pjb>
how can the CL implementation know that this socket stream is connected to an emacs process that will interact with the user and not to some random blind process?
<makomo>
hmm, that's a very good point actually
<makomo>
i think that might be it
<pjb>
Granted, we want to know if we can do "interactive querying". So basically, if writing to the stream, flushing, then reading from the stream should give some meaningful "user" interaction.
<makomo>
mhm
<pjb>
but this is hard to determine in general cases. Again, as a gray stream, we could specify it, but in actually, it would depend on slime, not on swank/gray…
<pjb>
We could specify if the gray stream specifications allows it (I don't know), and if the CL implementation correctly used this indicator.
<pjb>
21.1.1.1.3 Interactive Streams
<pjb>
You can use your own predicate, and test for (or swank/gray::slime-input-stream swank/gray::slime-output-stream).
<pjb>
Also, not that they're separate input and output streams, not IO streams *terminal-io* can be interactive, but we don't expect *standard-input* and *standard-output* to be. This is why we must use *query-io* for interactive I/O.
<pjb>
In the case of swank, it would be nice if it provided a *query-io* specific IO stream, with some specific interaction in slime\emacs. Eg. opening a new buffer, inserting the output, and prompting for the input (then killing the buffer).
<makomo>
pjb: what do you mean we don't expect *s-i* and *s-o* to be interactive? do we expect *terminal-io* to be interactive? the standard says that *t-io* might or might not be interactive
<makomo>
mhm, i agree with the *q-i* swank stream. that'd be nice
<pjb>
gray streams don't allow to define io streams or interactive. You can just inherit multiply from input and output streams…
<pjb>
makomo: I meant "we expect it to be *possibly* interactive".
<pjb>
So we'd have to define a gray-stream/version-2 specfication…
adlai has quit [Quit: unintentionally unlogged conversations considered marginally irrelevant]
nullcone has joined #slime
nicktick has joined #slime
<ullbeking>
I wish I had enough time to learn CL just so I could have an excuse to use SLIME as part of my dev workflow