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

Using inf-clojure-eval-buffer stucks the repl #292

Open
saikyun opened this issue Aug 12, 2018 · 9 comments
Open

Using inf-clojure-eval-buffer stucks the repl #292

saikyun opened this issue Aug 12, 2018 · 9 comments
Assignees
Labels

Comments

@saikyun
Copy link
Contributor

saikyun commented Aug 12, 2018

Using Emacs the repl sometimes gets stuck when using inf-clojure-eval-buffer. This is new behaviour since the recent update to Unity 2018.

I'm using Emacs 25.3.3 on a Macbook Air (early 2014) on (non-High) Sierra. I also use the hotfix described here: #131 (comment) I've tried both 500kb and 2500kb with no difference in behaviour.

Steps to reproduce:

  1. Start an Arcadia project.
  2. Open Assets/Arcadia/Source/arcadia/repl.clj (other files works as well, but it has to be a certain size I think).
  3. Run inf-clojure-eval-buffer.
  4. After a while it gets stuck (on #'arcadia.repl/start-server for me), then you can just write anything in the repl and press enter, and it will finish executing.
@timsgardner
Copy link
Contributor

Yeah, sometimes the repl gets a little gummed up until you press enter or eval something. Definitely a bug, but endurable for now, so this probably won't be prioritized for a little while.

@saikyun
Copy link
Contributor Author

saikyun commented Aug 28, 2018 via email

@timsgardner timsgardner added the bug label Oct 1, 2018
@sogaiu
Copy link

sogaiu commented Nov 15, 2018

Yeah, sometimes the repl gets a little gummed up until you press enter or eval something.

This happens here pretty much every new session right after running inf-clojure-eval-buffer on the typical cannonical core.clj for a project. So I typically evaluate (+ 1 1).

So pretty much what Saikyun said :)

@sogaiu
Copy link

sogaiu commented Jan 13, 2019

Used wireshark today to observe network traffic resulting from use of inf-clojure-eval-buffer.

It seems clear from the captured traffic that nothing has been received beyond what is showing up in emacs.

FWIW, pressing enter alone doesn't appear to cause additional things to arrive. However, a single '1' followed by enter does.

@sogaiu
Copy link

sogaiu commented Jan 13, 2019

IIUC, inf-clojure-load-file works by arranging for a file to be loaded by sending something along the lines of:

(load-file ".../game/core.clj")

This typically doesn't result in much output -- may be that is of some relevance to this issue? I guess there is another difference in that the size of what is sent is also significantly smaller.

Perhaps it is obvious, but for the sake of clarity :)

@sogaiu
Copy link

sogaiu commented Jan 13, 2019

Tried some further experiments with printing debug output and tracing.

It seems that when the "stuck" state is in effect, arcadia.internal.socket-repl/data-available? is returning false, even though there is more to process.

For reference, I came across the following possibly related info:

https://stackoverflow.com/questions/4261365/tcpclient-getstream-dataavailable-returns-false-but-stream-has-more-data

@sogaiu
Copy link

sogaiu commented Jan 13, 2019

It seems possible that #288 is related.

@saikyun
Copy link
Contributor Author

saikyun commented Jan 13, 2019

Yeah, if you want something to compare to it works as intended when you use the standard read-function (I believe I've said that before... :P). Good find on the data-available? issue.

@sogaiu
Copy link

sogaiu commented Jan 13, 2019

I tried sending some text via inf-clojure that caused the "stuck" state via telnet to port 37220. The result was no "stuck" state. Perhaps the whitespace issue with inf-clojure mentioned in #288 is a factor in this issue too.

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

No branches or pull requests

3 participants