Terry's idea works also for evaluating generated Julia code, too, by just
pasting the commands to the REPL window. We only need to mark the end of
the computation with printing a special character (e.g. of ASCII code 250)
and then the code below copies the result to the clipboard:
# for tests: put these to ".juliarc.jl"
# last pasted command: print('·') copies data to clipboard, resets data
collection
STDOUT0 = STDOUT
rd,wr = redirect_stdout()
redirect_stderr(STDOUT) # warnings OK, error messages fail!
pushdisplay(TextDisplay(wr))
@async begin
c = ""
while true
d = readavailable(rd) # blocks loop until there is data in rd
c *= string(d) # collects pieces of result
write(STDOUT0, d) # sends output to console (via original STDOUT)
flush(STDOUT0)
if search(c,'·') > 0
clipboard(c)
c = ""
end
end
end
Only the problem with error messages remain. The recent nightly builds of
Julia don't seem to write the error messages to STDERR, and so redirecting
it does not help.
On Friday, July 4, 2014 1:38:17 PM UTC-6, Laszlo Hars wrote:
>
> >(Terry) Typing commands in the REPL, I can see output on the screen and
> it's also logged in the julia-stdout.txt file.
> Thanks!. Your code does log normal output. We have to extend it a little
> to log also error messages, but warnings are logged correctly.
>
> >(Stefan) reading and writing to a REPL by reading and writing unframed
> inputs and output over a UNIX-style stream pair is fundamentally broken.
> I don't see, why it has to be fundamentally broken. If the REPL was
> written with print() calls, instead of display(), we would not have a
> problem. Or, if display() sent data to STDOUT like print(). We can live
> with a few unsupported features, like triple-quoted strings, but handling
> no output or catching error messages are easy. Even if I just enter "1)",
> which is unrepairable. The code I write and use myself does not have to be
> perfect, just good enough. The simple solution I posted last works for me
> 99.9% of the time, which I cannot claim for most commercial software.
>
