hi Nikita thank you so much for your explanation, it's very clear (and a bit surprising to learn that partial and anonymous functions have a slightly different semantics)
i am able to get the live coding behaviour when i redefine fill-background (as per your example, and that's great that it is possible) however it seems not possible to get a live coding behaviour when redefining fill-background-middleware (the middleware function itself) for example i would love if i could evaluate: (def fill-background-middleware identity) and see the background reverting to what it was before (that's just an example) but this seems not possible because that middleware runs just once, when the sketch is initialized do i understand correctly? and is it something that would not be achievable by any other means? (one more level of indirection perhaps? :-) Jay On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote: > > Hi Jay > > Yes, draw and update functions support live coding out-of-box. It's > trickier with middleware. The main thing is that middleware run once, when > initializing sketch. The goal of middleware is to take user provided > settings (like draw and update funcitons), optionally wrap some of them in > another functions and return new settings. It depends on your middleware > implementation whether it supports live coding. As a simple example let's > say you have a simple middleware that fills background with some color > before each draw. Here is how you can do it so it supports live reloading: > > (defn fill-background [draw-fn] > (q/background 255) > (draw-fn)) > > (defn fill-background-middleware [options] > (let [user-draw (:draw options)] > (assoc options > :draw #(fill-background user-draw)))) > > (q/defsketch abc > :draw ... > :middleware [fill-background-middleware]) > > If you try changing 'fill-background', for example change color from 255 > to 200, then you should see effect immediately. The trick is on line > > :draw #(fill-background user-draw)))) > > Here we say that new draw function is an anonymous function that calls > fill-background. So on each draw invocation it will lookup fill-background > function by name. If you reload this function - name will stay the same, > but implementation changes and interpreter pick ups new function. On the > other hand if you do following: > > :draw (partial fill-background user-draw) > > Then you won't get live reloading. Even though these 2 approaches > essentially do the same, the second approach actually "remembers" original > version of fill-background. If you try changing that function it won't have > effect as interpreter no longer looks up function by name. > > I'm probably not explaining it very well but I hope it's still helpful. If > you still have problems with your middleware - feel free to post the code > in this thread and I'll take a look. > > Nikita > > On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote: >> >> hello, i hope this is the place to discuss questions about Quil (i >> couldn't find a dedicated forum) >> >> and first of all, kudos to Nikita for this incredible library, which i >> find even better than the original Processing >> it's not just a matter of using a different syntax than java, but Nikita >> actually created something more powerful and flexible than Processing >> >> i'm particularly fond of the middleware functionality, which is a stroke >> of genius: so simple in retrospect and so powerful, opening a whole new way >> of possibilities of structuring one's own work in a modular fashion >> >> so i have one question regarding live coding and middleware >> >> if i redefine a function that i associate to :setup, :update or :draw >> keys, i can see my running sketch changing on the fly, reflecting the new >> definitions >> >> this is not the case however if i redefine a function that i use as a >> middleware >> >> is it an intrinsic limitation? would it be possible to extend the live >> coding behaviour to middlewares as well? >> >> thanks and long live Quil, >> Jay >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
