Closed Profpatsch closed 10 years ago
I'm not completely sure, but it seems to me signal handlers depend on things in sun.* packages which are not available on Android devices. Without them it is not possible to stop execution via Ctrl-C and stuff like that. I will give it another look, but it's not so drastic. And I can't change it to Warning because it's REPLy who prints it, not lein-droid.
Is it normal to land on reply.eval-modes.nrepl=>
?
What about that VerifyError?
I can’t seem to switch to my app’s namespace, too:
reply.eval-modes.nrepl=> (all-ns)
([…] #<Namespace de.profpatsch.droidtest.main> #<Namespace clojure.template>)
reply.exports=> (in-ns de.profpatsch.droidtest.main)
CompilerException java.lang.ClassNotFoundException: de.profpatsch.droidtest.main, compiling:(NO_SOURCE_PATH:1)
reply.exports=>
in-ns
is a function and takes symbol as an argument. You should use (in-ns 'de.profpatsch.droidtest.main)
. It is mentioned in the tutorial.
As for REPLy errors I didn't focus much on them as they don't seem to hamper anything.
Oh look. I made an idiot out of myself again…
Ok, off to learning Clojure well.
Don't take it too close, everyone has to start somewhere ;)
I'll keep the issue open, so I don't forget to look into the handlers message one more time.
As of REPLy 0.2.1, only Unable to set signal handlers.
message persists. As mentioned earlier, this is due to Android lacking sun.*
packages, and REPLy relying on them to set signal handlers for terminal interaction.
Landing into reply.eval-modes.nrepl=>
no longer happens, as user
namespace is being successfully created and switched into.
I close this issue as wontfix because implementing custom signal handlers in REPLy exclusively for Android isn't worth the trouble, and the error message is absolutely harmless.
Every time I run the REPL, it says
From issue https://github.com/alexander-yakushev/lein-droid/issues/21#issuecomment-15830050 I get that everything is working as it should and this message is displayed every time, yet I thought it is some critical error until I found the post above.
What is the cause of this message about signal handlers? Does it matter to me at all? If not it would be sensible to give it a
Warning:
prefix imho.And with the VerifyError, it looks like I’m thrown to the
reply.eval-modes.nrepl
namespace. I don’t know if this is normal behavior, since I haven’t been able to get it running yet.