reloading protocols causes problems

[Jeff Rose]

Hi,

  I'm wondering if people might have advice on how to deal with the issue of reloading protocol definitions.  Currently in Overtone things break when we reload some namespaces because once a defprotocol form is re-evaluated the existing types that implement that protocol are no longer valid because they refer to the old protocol, even when it hasn't changed.  Our current fix is to wrap all protocols in a defonce form, but this isn't the prettiest solution ever.  Is it crazy to imagine that protocols could remain the same after a reload unless they have changed, so that this problem would only be caused by actually changing a protocol rather than just re-evaluating a defprotocol form?  I don't know enough about the underlying machinery in terms of java class types and compilation to know if this is a reasonable thing to do.  Otherwise, maybe there is another way to handle the issue?

Thanks,
Jeff

[Phil Hagelberg]

Protocols necessarily make some unfortunate dynamicity trade-offs in the name of self-hosting. If you value interactive development over execution efficiency perhaps they are not the right choice.

-Phil

[David Nolen]

On Tue, Jun 19, 2012 at 10:49 AM, Phil Hagelberg <ph...@hagelb.org> wrote:

Protocols necessarily make some unfortunate dynamicity trade-offs in the name of self-hosting. If you value interactive development over execution efficiency perhaps they are not the right choice.

-Phil

Depending on what Clojure implementation you are using of course. ClojureScript doesn't have this problem ;)

Given my understanding of how protocols are currently implemented on Clojure JVM (partially backed by very static Java interfaces), I don't think you can achieve what you want. Perhaps JVM invokedynamic can help one day?

David 

[Sam Aaron]

It seems that guarding the protocol declarations inside of a defonce does the job nicely, although it is a big fugly. It's not too bad a trade-off though, because we rarely, if ever, want to change a protocol definition live. My main concern is that it wasn't obvious what was breaking Overtone during reloads, and it took some real trial and error discovery to figure that it was the protocol declarations. Perhaps Phil is right, and they're not the best choice for the job - perhaps multimethods might be a better fit for our needs.

I think that at least the documentation could be improved to warn people that defprotocol and namespace reloading don't play well together. This thread will already act as a start in this area :-)

David, it's cool that ClojureScript doesn't suffer from this issue though!

Sam

---
http://sam.aaron.name

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[David Nolen]

On Tue, Jun 19, 2012 at 12:14 PM, Sam Aaron <sama...@gmail.com> wrote:

It seems that guarding the protocol declarations inside of a defonce does the job nicely, although it is a big fugly. It's not too bad a trade-off though, because we rarely, if ever, want to change a protocol definition live. My main concern is that it wasn't obvious what was breaking Overtone during reloads, and it took some real trial and error discovery to figure that it was the protocol declarations. Perhaps Phil is right, and they're not the best choice for the job - perhaps multimethods might be a better fit for our needs.

I think that at least the documentation could be improved to warn people that defprotocol and namespace reloading don't play well together. This thread will already act as a start in this area :-)

David, it's cool that ClojureScript doesn't suffer from this issue though!

Sam

---
http://sam.aaron.name

Looking forward to an Overtone API over WebAudio (http://chromium.googlecode.com/svn/trunk/samples/audio/index.html) :)

David

[Jeff Rose]

On Tuesday, June 19, 2012 5:53:41 PM UTC+1, David Nolen wrote:

Looking forward to an Overtone API over WebAudio (http://chromium.googlecode.com/svn/trunk/samples/audio/index.html) :)

David

This has been discussed briefly, but it would be a serious undertaking to develop something approximating the functionality of the SuperCollider synthesis engine we currently use.  That said, our instruments are just functions, so it might be feasible to use a lot of the music making capabilities of Overtone on top of a fresh synthesis layer done using WebAudio...  Someday maybe.

-Jeff

[Jeff Rose]

Sure, but if the protocol hasn't changed, does a new type need to be generated?  Maybe this is too much to ask, but I would imagine that the compiler could inspect the current protocol of the same name and compare it with the newly evaluated one, and then only generate a new type when necessary.  I don't know how this machinery works currently so this could be a naive or incorrect way of thinking about it, but if possible it would really improve protocols for use in dynamic development.

-Jeff