Open clojens opened 10 years ago
Thanks for pointing this out.
Would it make sense to remove the reliance on directly importing overtone.live
from leipzig.live
? If I assume that the user has already booted Supercollider in whatever way makes sense for them, then perhaps I can avoid the problem altogether.
In the meantime, I've added a note to the README.md as you suggested.
Great, thanks. To be honest, I don't have the exact difference between internal vs external boot clear. If it doesn't matter too much, it seems one might be able to drop the overtone.live
reference in favor of overtone.core
and suffice or, as additional measure (perhaps its already implemented) check against a running sc server instance and in case absent, call (boot-external-server)
? But again, I'm not sure when to favor one over the other and what the majority use is. Pure console based REPL (isn't that what overtone.live is supposed to support?) seems to me to be a really big hassle during overtone development, and that's pretty much the main thing: imho overtone (et al) doesn't make sense without either emacs or lighttable as IDE to support it. At least what my common sense tells me and if the notion .live is for REPL server boot is correct.
I just had a quick peek (duh) and seems to be the case that https://github.com/overtone/overtone/blob/master/src/overtone/live.clj is to support a form of automatic bootstrapping when disconnected. The JNA makes it easy to access native libraries, so it is probably used to hook the dll and use internal check if supercollider is running and if not, boot the server. One could work around that in a bit hacky way without using the SC API by using getRuntime()
to execute the task list. In order for this, you'd need to know the name and although probably uniform throughout Windows installations (the supercollider executable name that is).
Process p =Runtime.getRuntime().exec(System.getenv("windir") +"\\system32\\"+"tasklist.exe");
But does a running supercollider equal a running server? I don't think so and this might be the culprit for taking the JNA road in the first place.
Its that or, as you mentioned already, assume that the user is aware and has already booted the server. Another option can think of, is that (boot-external-server)
might already have a graceful fallback system in place which allows you to call it regardless of running instance or not (I should check).
Throws, you could handle it I guess or indeed drop it.
java.lang.Exception: Can't boot as a server is already connected/connecting!
connection.clj:341 overtone.sc.machinery.server.connection/boot[fn]
connection.clj:340 overtone.sc.machinery.server.connection/boot
server.clj:135 overtone.sc.server/boot-external-server
server.clj:133 overtone.sc.server/boot-external-server
server.clj:132 overtone.sc.server/boot-external-server
Var.java:375 clojure.lang.Var.invoke
Inclusion of the overtone.core
library will print
Please boot a server to start making noise:
* (boot-server) ; boot default server (honours config)
* (boot-internal-server) ; boot an internal server
* (boot-external-server) ; boot an external server
* (connect-external-server) ; connect to an existing external server
Which would tell anyone able to read the output enough I guess
Any news om this? I'm on NixOS, and I seem to be only able to connect to an external server, not even boot one.
Hi,
Just to inform you, something I faced a bit earlier when trying to setup Overtone in LightTable on Windows (8) 64bit. Normally I run a ArchLinux setup in virtualbox guest on this machine but due to a cracking sound, I had to switch back to the host Win. The problem I faced was
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.NativeLong
exceptions thrown and the solution was found in https://groups.google.com/forum/#!topic/overtone/orbm9ZEtZaE group.Basically what it boils down to, from what I understand, is that
overtone.live
can't be used/called in Windows 64bit. It is not just limited to LightTable,lein repl
throws the same. Falling back toovertone.core
and then using(boot-external-server)
everything run smoothly though and, from what I read, seems to be the prefered method of dealing with this issue.Perhaps something to take into account for leipzig as I noticed you made use of it in
leipzig.live
and mention it in the how-to of the README file.