Yes, middleware runs exactly once so you can't redefine it. In the example with fill-background you can redefine fill-backgfound:
(def fill-background [draw-fn] (draw-fn)) Which essentially makes it identify. So that's would be my recommendation: put all logic to fill-background and let fill-background-middleware be just a wrapper like it is now. On Wednesday, March 22, 2017 at 8:22:59 PM UTC-7, Jay Porcasi wrote: > > 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.
