Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bbolker opened this issue Jan 4, 2016 · 4 comments
Open

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

bbolker opened this issue Jan 4, 2016 · 4 comments

Comments

@bbolker
Copy link

bbolker commented Jan 4, 2016

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
Copy link
Owner

yihui commented Jan 5, 2016

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
Copy link
Author

bbolker commented Jan 6, 2016

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
Copy link
Owner

yihui commented Jan 13, 2016

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants