hashes (or something) prepended to output from python chunks?

[bbolker]

Don't know if this should go as a knitr or a runr issue, but ... I'm using a fresh install of runr (devtools::install_github(yihui/runr), packageVersion("runr") == 0.0.7)

Every python output chunk seems to have some kind of hash value prepended to it ... ? I would try to dig in further, but I'm having a hard time getting far enough into the guts of knitr to debug it ...

I have a minimal example posted here (the output is here)

FWIW it seems to happen with both python and python3 ...

any quick thoughts ... ?

[yihui]

I probably need to change this S3 method to knit_print.runr_results: https://github.com/yihui/runr/blob/master/R/utils.R#L27

[bbolker]

I think it has something to do with whether the port that runR is listening on is open somewhere else. My current hypothesis is that depending on its exact state I get one or more of the following ...

Bind failed. Error Code : 98; Message: Address already in use

or

Error in socketConnection(port = port, open = "r+", blocking = TRUE, server = FALSE) : 
  cannot open the connection
Calls: <Anonymous> ... engine -> <Anonymous> -> <Anonymous> -> socketConnection
In addition: Warning message:
In socketConnection(port = port, open = "r+", blocking = TRUE, server = FALSE) :
  localhost:6011 cannot be opened

or those weird strings in the output. The clue was that it seemed to work OK when I was running interactively but not from a Makefile. My guess is that when I was running it non-interactively I had a socket already open from a previous py$start() invocation in an interactive session that was open at the same time ... The part that seems like magic is that (apparently) the result of having an open socket might be to trigger some extra junk in the result of py$exec() rather than giving a straightforward error message ... ??

This suggests that if runR is widely used it might be worth trying to check whether the port is already open and return an informative error message? I guess there's not a port equivalent of tempfile() ...

Anyway, I think you can probably close this -- I'll try to be careful to make sure I don't have a process already listening at the specified port ...

[yihui]

I do not really like the current implementation based on socket connections. If I take it seriously, I should use a better backend like rPython/rJython (they may be difficult for Windows users to install, though).

[flammy0530]

I ran into rPython today and was really excited about using the idea to support Python code more seamlessly in knitr. But, I guess you already knew. 😓 If you need help implementing this idea, I will be happy to contribute.