Hi,
I know that it's possible to run the Swank server on an android device, and connect to it from the PC (people did this successfully).
Unfortunately it doesn't work for me...
I enabled swank:*log-events*; attached you find 2 log files:
- swank-events-log-1.txt: this one works (connecting locally) - swank-events-log-2.txt: this fails trying to connect to swank on android
I tried many times, it always fails at the exact same point. I even tried using ssh, with the same result.
Could anybody knowing the swank internals look into this, please?
Thanks,
Paul
P.S. I'm trying this with the EQL5-Android REPL example, which can run (from same sources) both on the desktop and on android; so the logs mentioned above use the same application;
update: after investigating myself, I noticed some strange behavior in the network communication (using "wireshark" to log the single packets).
So, it basically seems a network communication problem.
(to be continued...)
Paul
2017-08-22 12:57 GMT+02:00, PR polos.ruetz@gmail.com:
Hi,
I know that it's possible to run the Swank server on an android device, and connect to it from the PC (people did this successfully).
Unfortunately it doesn't work for me...
I enabled swank:*log-events*; attached you find 2 log files:
- swank-events-log-1.txt: this one works (connecting locally)
- swank-events-log-2.txt: this fails trying to connect to swank on android
I tried many times, it always fails at the exact same point. I even tried using ssh, with the same result.
Could anybody knowing the swank internals look into this, please?
Thanks,
Paul
P.S. I'm trying this with the EQL5-Android REPL example, which can run (from same sources) both on the desktop and on android; so the logs mentioned above use the same application;
On Wed, Aug 23, 2017 at 2:49 PM, PR polos.ruetz@gmail.com wrote:
So, it basically seems a network communication problem.
Looking at the event log doesn't seem to yield much of a clue. Perhaps you can try setting swank::*debug-on-swank-protocol-error* to t. If that doesn't help, you could try to place a break at the start of swank::close-connection% to see what's triggering it.
HTH, Luís
2017-08-23 23:36 GMT+02:00, Luís Oliveira luismbo@gmail.com:
you could try to place a break at the start of swank::close-connection% to see what's triggering it
Thank you very much, I'm closer now (although it doesn't work normally yet).
If I put a break at the start of swank::close-connection%, Emacs shows the debugger right after I connect to swank; then (and this is strange), after a few seconds, the REPL shows up in the other half of Emacs, and it works!!
So, I have now the debugger open, and a functioning REPL (until I continue from the break); but the open debugger doesn't stop the REPL from functioning, and on conditions on the REPL, another debugger instance will show, so I can fully use the REPL.
Now I'll need to examine the backtrace carefully...
Thanks again,
Paul
HTH, Luís
Heh, that's quite bizarre. Keep us posted.
Luís
On Thu, Aug 24, 2017, 10:42 PR polos.ruetz@gmail.com wrote:
2017-08-23 23:36 GMT+02:00, Luís Oliveira luismbo@gmail.com:
you could try to place a break at the start of swank::close-connection% to see what's triggering it
Thank you very much, I'm closer now (although it doesn't work normally yet).
If I put a break at the start of swank::close-connection%, Emacs shows the debugger right after I connect to swank; then (and this is strange), after a few seconds, the REPL shows up in the other half of Emacs, and it works!!
So, I have now the debugger open, and a functioning REPL (until I continue from the break); but the open debugger doesn't stop the REPL from functioning, and on conditions on the REPL, another debugger instance will show, so I can fully use the REPL.
Now I'll need to examine the backtrace carefully...
Thanks again,
Paul
HTH, Luís
2017-08-24 13:40 GMT+02:00, Luís Oliveira luismbo@gmail.com:
Heh, that's quite bizarre. Keep us posted.
ok, here the next update:
I wasn't really correct with my previous description, so I will be more precise here:
- I start swank on android (the REPL uses ECL) - now I connect from the pc, which breaks into the Slime debugger, as expected (caused by 'break') - as soon as I click on any function of the "Backtrace:" list, the Slime REPL is shown with its usual prompt (here: "EQL-USER>")
The Slime REPL is fully functioning. Now if I provoke a condition, e.g. (/ 0), the debugger just adds 2 more restarts (as usual), and if I select the top most ABORT, the REPL keeps functioning.
Of course if I select to abort from 'break' (for the record: set by me at the start of swank::close-connection%), then I lose the connection to swank.
Attached you find the fully expanded backtrace. The only condition is from the inserted break (I clicked on all of the listed ones; it always says "Break" after FORMAT-CONTROL, (see top of attached file).
In function close-connection (from backtrace), the condition simply says NIL.
I really have no clue so far...
Luís
On Thu, Aug 24, 2017, 10:42 PR polos.ruetz@gmail.com wrote:
2017-08-23 23:36 GMT+02:00, Luís Oliveira luismbo@gmail.com:
you could try to place a break at the start of swank::close-connection% to see what's triggering it
Thank you very much, I'm closer now (although it doesn't work normally yet).
If I put a break at the start of swank::close-connection%, Emacs shows the debugger right after I connect to swank; then (and this is strange), after a few seconds, the REPL shows up in the other half of Emacs, and it works!!
So, I have now the debugger open, and a functioning REPL (until I continue from the break); but the open debugger doesn't stop the REPL from functioning, and on conditions on the REPL, another debugger instance will show, so I can fully use the REPL.
Now I'll need to examine the backtrace carefully...
Thanks again,
Paul
HTH, Luís
On Thu, Aug 24, 2017 at 1:10 PM, PR polos.ruetz@gmail.com wrote:
I really have no clue so far...
Did you try to set swank::*debug-on-swank-protocol-error* to t as well?
If that doesn't help, then perhaps try to sprinkle swank::simple-serve-requests and swank::with-connection (maybe define your own version of with-connection because that's used elsewhere, namely in the REPL) with breaks and/or traces to see where it's failing.
BTW, it now occurs to me that you have a working REPL because swank-repl.lisp opens a dedicated socket for REPL requests.
Cheers, Luís
2017-08-24 15:29 GMT+02:00, Luís Oliveira luismbo@gmail.com:
On Thu, Aug 24, 2017 at 1:10 PM, PR polos.ruetz@gmail.com wrote:
I really have no clue so far...
Did you try to set swank::*debug-on-swank-protocol-error* to t as well?
setting swank::*debug-on-swank-protocol-error* to t didn't change anything, sorry.
I couldn't find something useful so far, and handling with android (where everything is slow and nothing directly accessible) is quite tedious...
As soon as I get some new and useful information, I will update you, of course.
Thanks for your patience,
Paul
If that doesn't help, then perhaps try to sprinkle swank::simple-serve-requests and swank::with-connection (maybe define your own version of with-connection because that's used elsewhere, namely in the REPL) with breaks and/or traces to see where it's failing.
BTW, it now occurs to me that you have a working REPL because swank-repl.lisp opens a dedicated socket for REPL requests.
Cheers, Luís
2017-08-24 19:41 GMT+02:00, PR polos.ruetz@gmail.com:
As soon as I get some new and useful information, I will update you, of course.
ok, I could track it down: the error happens in function 'swank::simple-repl', in
'(handler-case (read) ...'.
I added a form '(error (err) ...', in order to print the error, and it says:
#<a SWANK::END-OF-REPL-INPUT>
"Unexpected end of file on #<input file "stdin">
Any hint what I could try next? Thanks.
If that doesn't help, then perhaps try to sprinkle swank::simple-serve-requests and swank::with-connection (maybe define your own version of with-connection because that's used elsewhere, namely in the REPL) with breaks and/or traces to see where it's failing.
BTW, it now occurs to me that you have a working REPL because swank-repl.lisp opens a dedicated socket for REPL requests.
Cheers, Luís
Just to close this thread appropriately:
- recent ECL supports the :SPAWN style (recommended) - unfortunately it doesn't currently work on android (yet) - Luis O. offered a possible solution (a new :LOOP style for Swank) - my personal problem here was that 'stdin' is not available in my android app (please see ECL mailing list for a trivial patch)
But I don't want to hide that I've currently given up on Swank on Android: for my personal use case, it's simply not worth the trouble (because there are some more problems, not directly related to Slime/Swank).
Paul
2017-08-25 15:30 GMT+02:00, PR polos.ruetz@gmail.com:
sorry, what I reported above seems nonsense; please ignore...
2017-09-03 1:59 GMT+02:00, PR polos.ruetz@gmail.com:
Just to close this thread appropriately:
One last thing: it's only the Slime REPL freezing sometimes, completely blocking both the android app and Emacs.
But if I only use a scratch file, using 'C-M x' for evaluation (never touching the Slime REPL), it works without problems. So, there's still hope!
Paul
On Sun, Sep 3, 2017 at 9:58 AM, PR polos.ruetz@gmail.com wrote:
One last thing: it's only the Slime REPL freezing sometimes, completely blocking both the android app and Emacs.
The REPL uses a dedicated thread. That issue might might be related to whatever issues the :SPAWN style had with less recent versions of ECL.
For the record, the :LOOP style implementation lives here: https://github.com/luismbo/slime/tree/simpler-communication-style. I'm inclined to not push it to master unless a more compelling motivation shows up. And if it does, I might instead try (again) to figure out how to make the NIL style handle a closed stdin more gracefully.
Cheers,
-
Luís Oliveira -
PR