[ANN] co-dependency in stuartsierra/component
*co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component#customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/tangrammer/co-dependency -- 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.
Re: perform action after events stop for some period
In the general case, side effects within the swap! function are a bad idea because of the optimistic locking. In your first code snippet, if there is any contention on the atom (and maybe in your app you know there is none because it's only ever accesses by the same single thread), you run the risk of having orphaned futures. As far as I know there should be no such problem with the agent version. I'm not really sure about the nesting of send-off calls though; that might be the source of your stack overflow. I seem to remember that this was not supported up until 1.4 or 1.5; not sure what the current semantics is. Depending on how many different event types you're watching for (and how many differet actions you need to take), it might be worth having a single thread managing the queue. Somethin along the line of having a single atom containing a priority queue (or a sorted map?) with, for each event type, the last time the event was observed. At some interval, that event thread could check the queue and run the required handlers based on the current time. When an event arrives, it resets the time associated to its type in the queue. Whether this is better will depend on your usage pattern. I would just like to point out that creating a future has some non trivial overhead as it also creates a thread (at least, the last time I checked, futures where not created out of a limited thread pool). On Tuesday, 2 December 2014, Erik Price e...@zensight.co wrote: Coincidentally, we recently wrote code to do something very similar. The following function will invoke f after period milliseconds, unless a value is sent on events-ch, in which case the timeout is reset (and starts counting down again): (defn invoke-after-uninterrupted-delay ([period events-ch f] (invoke-after-uninterrupted-delay period events-ch f [])) ([period events-ch f args] (async/go-loop [] (let [[_ p] (async/alts! [(async/timeout period) events-ch])] (if (= p events-ch) (recur) (apply f args)) e On Mon, Dec 1, 2014 at 6:50 PM, Brian Craft craft.br...@gmail.com javascript:_e(%7B%7D,'cvml','craft.br...@gmail.com'); wrote: That version has the unfortunate behavior that (func) can be interrupted if (event) is called while it is running. Here's another version using an agent: (defn queue-with-delay2 [period func] (let [q (agent nil)] (fn [] (send-off q (fn [t] (when t (future-cancel t)) (future (Thread/sleep period) (send-off q (fn [_] (func) nil Running with a sleep to see that (func) is not canceled by subsequence (event) calls: (def event (queue-with-delay2 2000 #(do (println running) (Thread/sleep 2000) (println ending Oddly, if calling (event) between running and ending messages, the repl will stack-overflow on the return value. No idea what that's about. But, running like this is fine: (do (event) nil) On Monday, December 1, 2014 1:37:56 PM UTC-8, Brian Craft wrote: I have need to perform an action when a series of events is quiet for some period. That is, if one event arrives an action is queued to execute after some timeout. If a second event arrives the timeout is reset, and so-forth. The following code seems to work, however I'm wondering if calling 'future' from 'swap!' is a bad idea (side effecting), and if there's a better way. (defn queue-with-delay [period func] (let [f (atom nil)] (fn [] (when @f (future-cancel @f)) (swap! f (fn [_] (future (Thread/sleep period) (func))) Use like (def event (queue-with-delay 2000 #(println running))) (event) (event) (event) ; pause 2 sec running -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- 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 javascript:_e(%7B%7D,'cvml','clojure@googlegroups.com'); Note that posts from new members are moderated - please be patient with your first post. To unsubscribe
Re: [ANN] co-dependency in stuartsierra/component
Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz juanantonio...@gmail.com wrote: *co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component#customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/tangrammer/co-dependency -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: [ANN] co-dependency in stuartsierra/component
Hi Atamert, I realised too the discouraged note https://github.com/stuartsierra/component#disadvantages-of-the-component-model about cyclic dependencies but although your closed parent-child component relations is logically perfect on start your system, when system is ready to work it's very useful to open the door to child-parent relation too, so the child component can communicate with parent component. Here a couple of examples that you could find this reverse relation: * routing (router and webservices). webservice could need to know which other webservices are connected to its parent router to construct urls ( modular/bidi https://github.com/juxt/modular/tree/master/modules/bidi) * templating (menu and menu-items). Menu-items could need to know which others menu-items are used/displayed on the menu component to adapt their renderer Does this explanation make sense to you? Thanks for reviewing Juan El martes, 2 de diciembre de 2014 12:55:42 UTC+1, Atamert Ölçgen escribió: Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz juanant...@gmail.com javascript: wrote: *co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component#customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/tangrammer/co-dependency -- 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 javascript: 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 javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: Richelieu: a library for advising functions
Looks nice. It's pretty similar to Robert Hooke though -- which is more of an advice library than a hook library despite it's name. Edwin Watkeys e...@poseur.com writes: Hello, Richelieu, a library for advising functions, is in something resembling announcement-worthy shape. It's available at the following URL: http://github.com/thunknyc/richelieu During my experience writing thunknyc/profile and the associated CIDER support, I realized that advising or decorating functions is something that's been getting reinvented over and over. I wanted to put an end to that. Richelieu supports advising functions as well as vars and namespaces. Multiple advise functions can be associated with a function, and advise functions have access to the underlying var or function this is being decorated. Below is an edited sample from the README that shows how to implement tracing advice using the library. I hope this may be useful to one or more people out there. I plan on modifying thunknyc/profile to use Richelieu as part of a push to implement additional profiling modalities. Regards, Edwin (require '[richelieu.core :refer [advice advise-ns *current-advised* defadvice]]) ;;; Here are some simple functions. (defn add [ xs] (apply + xs)) (defn mult [ xs] (apply * xs)) (defn sum-squares [ xs] (apply add (map #(mult % %) xs))) ;;; This tracing advice shows how to get the current advised object, ;;; which can either be a var or a function value, depending on the ;;; context in which the advice was added. (def ^:dynamic *trace-depth* 0) (defn- ^:unadvisable trace-indent [] (apply str (repeat *trace-depth* \space))) (defadvice trace Writes passed arguments and passes them to underlying function. Writes resulting value before returning it as result. [f args] (printf %s %s %s\n (trace-indent) *current-advised* args) (let [res (binding [*trace-depth* (inc *trace-depth*)] (apply f args))] (printf %s %s %s\n (trace-indent) *current-advised* res) res)) (advise-ns 'user trace) (sum-squares 1 2 3 4) ;;; The above invocation produces the following output: ;; #'user/sum-squares (1 2 3 4) ;; #'user/mult (1 1) ;; #'user/mult 1 ;; #'user/mult (2 2) ;; #'user/mult 4 ;; #'user/mult (3 3) ;; #'user/mult 9 ;; #'user/mult (4 4) ;; #'user/mult 16 ;; #'user/add (1 4 9 16) ;; #'user/add 30 ;; #'user/sum-squares 30 -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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.
Re: Richelieu: a library for advising functions
Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Edwin Watkeys * 917-324-2435 * http://poseur.com/ http://poseur.com/ On Dec 2, 2014, at 8:08 AM, Phillip Lord phillip.l...@newcastle.ac.uk mailto:phillip.l...@newcastle.ac.uk wrote: Looks nice. It's pretty similar to Robert Hooke though -- which is more of an advice library than a hook library despite it's name. Edwin Watkeys e...@poseur.com mailto:e...@poseur.com writes: Hello, Richelieu, a library for advising functions, is in something resembling announcement-worthy shape. It's available at the following URL: http://github.com/thunknyc/richelieu http://github.com/thunknyc/richelieu During my experience writing thunknyc/profile and the associated CIDER support, I realized that advising or decorating functions is something that's been getting reinvented over and over. I wanted to put an end to that. Richelieu supports advising functions as well as vars and namespaces. Multiple advise functions can be associated with a function, and advise functions have access to the underlying var or function this is being decorated. Below is an edited sample from the README that shows how to implement tracing advice using the library. I hope this may be useful to one or more people out there. I plan on modifying thunknyc/profile to use Richelieu as part of a push to implement additional profiling modalities. Regards, Edwin (require '[richelieu.core :refer [advice advise-ns *current-advised* defadvice]]) ;;; Here are some simple functions. (defn add [ xs] (apply + xs)) (defn mult [ xs] (apply * xs)) (defn sum-squares [ xs] (apply add (map #(mult % %) xs))) ;;; This tracing advice shows how to get the current advised object, ;;; which can either be a var or a function value, depending on the ;;; context in which the advice was added. (def ^:dynamic *trace-depth* 0) (defn- ^:unadvisable trace-indent [] (apply str (repeat *trace-depth* \space))) (defadvice trace Writes passed arguments and passes them to underlying function. Writes resulting value before returning it as result. [f args] (printf %s %s %s\n (trace-indent) *current-advised* args) (let [res (binding [*trace-depth* (inc *trace-depth*)] (apply f args))] (printf %s %s %s\n (trace-indent) *current-advised* res) res)) (advise-ns 'user trace) (sum-squares 1 2 3 4) ;;; The above invocation produces the following output: ;; #'user/sum-squares (1 2 3 4) ;; #'user/mult (1 1) ;; #'user/mult 1 ;; #'user/mult (2 2) ;; #'user/mult 4 ;; #'user/mult (3 3) ;; #'user/mult 9 ;; #'user/mult (4 4) ;; #'user/mult 16 ;; #'user/add (1 4 9 16) ;; #'user/add 30 ;; #'user/sum-squares 30 -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk mailto:phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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 mailto: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 mailto:clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/ycw4pZQBFfs/unsubscribe https://groups.google.com/d/topic/clojure/ycw4pZQBFfs/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- 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
Re: [ANN] co-dependency in stuartsierra/component
Thanks for the explanation. Yes, it makes sense. Without this library I would do something similar myself. You are using deref (pragmatic clojure) and the relationship is explicit (in system map), both are advantages. It is possible to design around it though; separate the common parts, say the container of webservices in your first example (as :c) and then make both :a and :b depend on :c, and :b to depend on :a too for instance. A component doesn't have to be immutable, or has to be initialized all at once (during start). I imagine it can have other life-cycle event and change its state. Anyways I see myself as a potential user of your library. I'm just sharing my thoughts. On Tue, Dec 2, 2014 at 8:33 PM, JUAN ANTONIO Ruz juanantonio...@gmail.com wrote: Hi Atamert, I realised too the discouraged note https://github.com/stuartsierra/component#disadvantages-of-the-component-model about cyclic dependencies but although your closed parent-child component relations is logically perfect on start your system, when system is ready to work it's very useful to open the door to child-parent relation too, so the child component can communicate with parent component. Here a couple of examples that you could find this reverse relation: * routing (router and webservices). webservice could need to know which other webservices are connected to its parent router to construct urls ( modular/bidi https://github.com/juxt/modular/tree/master/modules/bidi) * templating (menu and menu-items). Menu-items could need to know which others menu-items are used/displayed on the menu component to adapt their renderer Does this explanation make sense to you? Thanks for reviewing Juan El martes, 2 de diciembre de 2014 12:55:42 UTC+1, Atamert Ölçgen escribió: Hi Juan, I thought co-dependencies ought to be designed out. Could you give a use case for co-dependency? On Tue, Dec 2, 2014 at 7:16 PM, JUAN ANTONIO Ruz juanant...@gmail.com wrote: *co-dependency* is a library that lets you use *cyclic* dependencies in stuartsierra/component systems In other words, :a depends-on :b, :b (co-)depends-on :a Although I used cyclic word, this co-dependency library is designed on the idea that components don't need co-dependencies to start as normal dependencies. co-dependency follows the pattern described in stuartsierra/component# customization https://github.com/stuartsierra/component#customization to accomplish this cyclic feature You can find all the details about this lib on https://github.com/ tangrammer/co-dependency -- 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 --- 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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: Richelieu: a library for advising functions
I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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.
Re: is any work done to draw sequence diagrams with drcode/vijual ?
AFAIK there's several libraries for interfacing with graphviz, all coming from a slightly different angle - drcode/vijual https://github.com/drcode/vijual - Emphasis on ascii graphics, alternately output to graphviz - daveray/dorothy https://github.com/daveray/dorothy - Generating graphviz graphs using hiccup like syntax - ztellman/rhizome https://github.com/ztellman/rhizome - Graphviz rendering through transformation functions on Clojure data structures - aysylu/loom/io.clj https://github.com/aysylu/loom/blob/master/src/loom/io.clj - Visualizing loom graphs through Graphviz, very limited output options Aside from Graphviz integration, there's also numerous other Java graph visualization libraries that could be used. What parts of Vijual or the other libraries have your interest ? On Monday, December 1, 2014 6:03:51 PM UTC+1, JUAN ANTONIO Ruz wrote: Hi guys, I'm trying to guess in which state is drcode/vijual https://github.com/drcode/vijual or which would be the better fork to start working on this drawing sequence diagrams feature... It's a really shame that this so cool tool seems to not be maintained any more :( Any advises or any references to start with? thanks in advance Juan -- 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.
Re: ring-transit issue
Hi,
After quite a bit of trying various things I got this working now:
(ns trans.core.handler
(:require [compojure.core :refer :all]
[compojure.route :as route]
[compojure.handler :as handler]
[ring.util.response :as ring-response]
[ring.middleware.transit :as trans :only [wrap-transit-response
wrap-transit-params]]))
(defn get-data []
(ring-response/response {:a 1 :b 2}))
(defroutes app-routes
(GET / [] Hello World)
(GET /test [] (get-data))
(route/not-found Not Found))
(def app
(- app-routes
(handler/site)
(trans/wrap-transit-params)
(trans/wrap-transit-response)))
The change that made the difference seems to the the ring-response/response
call in the get-data function.
I hope that this helps other people and a big thank you to Ahmad for a hint
in the right direction.
Thomas
--
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.
Re: perform action after events stop for some period
The nested send-off call doesn't happen on the same thread (it's in a future). Seems like that would be the same as if an unrelated thread called send-off while the outer send-off was running. It does seem like a single-thread solution would be better, not creating so many futures. Polling seems pretty crude, but I don't see another way of doing it with clojure abstractions. Maybe a pure java solution. On Tuesday, December 2, 2014 3:47:58 AM UTC-8, Gary Verhaegen wrote: In the general case, side effects within the swap! function are a bad idea because of the optimistic locking. In your first code snippet, if there is any contention on the atom (and maybe in your app you know there is none because it's only ever accesses by the same single thread), you run the risk of having orphaned futures. As far as I know there should be no such problem with the agent version. I'm not really sure about the nesting of send-off calls though; that might be the source of your stack overflow. I seem to remember that this was not supported up until 1.4 or 1.5; not sure what the current semantics is. Depending on how many different event types you're watching for (and how many differet actions you need to take), it might be worth having a single thread managing the queue. Somethin along the line of having a single atom containing a priority queue (or a sorted map?) with, for each event type, the last time the event was observed. At some interval, that event thread could check the queue and run the required handlers based on the current time. When an event arrives, it resets the time associated to its type in the queue. Whether this is better will depend on your usage pattern. I would just like to point out that creating a future has some non trivial overhead as it also creates a thread (at least, the last time I checked, futures where not created out of a limited thread pool). On Tuesday, 2 December 2014, Erik Price er...@zensight.co javascript: wrote: Coincidentally, we recently wrote code to do something very similar. The following function will invoke f after period milliseconds, unless a value is sent on events-ch, in which case the timeout is reset (and starts counting down again): (defn invoke-after-uninterrupted-delay ([period events-ch f] (invoke-after-uninterrupted-delay period events-ch f [])) ([period events-ch f args] (async/go-loop [] (let [[_ p] (async/alts! [(async/timeout period) events-ch])] (if (= p events-ch) (recur) (apply f args)) e On Mon, Dec 1, 2014 at 6:50 PM, Brian Craft craft.br...@gmail.com wrote: That version has the unfortunate behavior that (func) can be interrupted if (event) is called while it is running. Here's another version using an agent: (defn queue-with-delay2 [period func] (let [q (agent nil)] (fn [] (send-off q (fn [t] (when t (future-cancel t)) (future (Thread/sleep period) (send-off q (fn [_] (func) nil Running with a sleep to see that (func) is not canceled by subsequence (event) calls: (def event (queue-with-delay2 2000 #(do (println running) (Thread/sleep 2000) (println ending Oddly, if calling (event) between running and ending messages, the repl will stack-overflow on the return value. No idea what that's about. But, running like this is fine: (do (event) nil) On Monday, December 1, 2014 1:37:56 PM UTC-8, Brian Craft wrote: I have need to perform an action when a series of events is quiet for some period. That is, if one event arrives an action is queued to execute after some timeout. If a second event arrives the timeout is reset, and so-forth. The following code seems to work, however I'm wondering if calling 'future' from 'swap!' is a bad idea (side effecting), and if there's a better way. (defn queue-with-delay [period func] (let [f (atom nil)] (fn [] (when @f (future-cancel @f)) (swap! f (fn [_] (future (Thread/sleep period) (func))) Use like (def event (queue-with-delay 2000 #(println running))) (event) (event) (event) ; pause 2 sec running -- 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. -- You received this
Re: Richelieu: a library for advising functions
Phillip, Of Robert Hooke's features, I think the ability to suppress advice temporarily (its `with-hooks-disabled`) as well to advise a function within a particular dynamic scope (`with-scope`) are most relevant to Richelieu. Since one of the major goals of Richelieu is to serve as a generic basis for advising, I'll probably implement a `with-advice-disabled` form that takes a sequence of advisedf-and-advicef-set values to temporarily suppress. R.H. and Richelieu, while they do much the same thing, seem to be orthogonal to each other in terms of intent: Richelieu exists to allow folks to write arbitrary advice-based facilities that are oblivious to each others' existences, decorating functions that weren't written with being advised in mind—think tracing and profiling. Phil, on the other hand, focused on providing a facility for developers who anticipate that their code might be advised à la the Emacs hooks mechanism. Or not. I'm totally speculating. As for the name, I guess I'm willing to overlook some semantic quibbles—especially since something very similar to Emacs's normal hooks could easily built atop R.H.—in pursuit of a charming allusion. Edwin On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com javascript: writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk javascript: School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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.
Re: perform action after events stop for some period
On Tue, Dec 2, 2014 at 12:22 PM, Brian Craft craft.br...@gmail.com wrote: It does seem like a single-thread solution would be better, not creating so many futures. Polling seems pretty crude, but I don't see another way of doing it with clojure abstractions. Maybe a pure java solution. FWIW, the core.async-based solution satisfies both the criteria of being single-threaded and non-polling. e -- 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.
Re: perform action after events stop for some period
Cool. I haven't used core.async before, and am a bit reluctant to pull in another dependency just for this. But maybe it's the right solution. On Tuesday, December 2, 2014 10:03:54 AM UTC-8, Erik Price wrote: On Tue, Dec 2, 2014 at 12:22 PM, Brian Craft craft...@gmail.com javascript: wrote: It does seem like a single-thread solution would be better, not creating so many futures. Polling seems pretty crude, but I don't see another way of doing it with clojure abstractions. Maybe a pure java solution. FWIW, the core.async-based solution satisfies both the criteria of being single-threaded and non-polling. e -- 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.
Re: Richelieu: a library for advising functions
At a very superficial glance, it looks like dire also sort of fits into the same space: https://github.com/MichaelDrogalis/dire On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote: Phillip, Of Robert Hooke's features, I think the ability to suppress advice temporarily (its `with-hooks-disabled`) as well to advise a function within a particular dynamic scope (`with-scope`) are most relevant to Richelieu. Since one of the major goals of Richelieu is to serve as a generic basis for advising, I'll probably implement a `with-advice-disabled` form that takes a sequence of advisedf-and-advicef-set values to temporarily suppress. R.H. and Richelieu, while they do much the same thing, seem to be orthogonal to each other in terms of intent: Richelieu exists to allow folks to write arbitrary advice-based facilities that are oblivious to each others' existences, decorating functions that weren't written with being advised in mind—think tracing and profiling. Phil, on the other hand, focused on providing a facility for developers who anticipate that their code might be advised à la the Emacs hooks mechanism. Or not. I'm totally speculating. As for the name, I guess I'm willing to overlook some semantic quibbles—especially since something very similar to Emacs's normal hooks could easily built atop R.H.—in pursuit of a charming allusion. Edwin On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk School of Computing Science,http://homepages.cs.ncl.ac. uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- 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.
[ANN] silc - a tiny entity database for clojure (games)
I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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.
Re: [ANN] silc - a tiny entity database for clojure (games)
A pure entity database would have been useful for a game I was working on last month. I'll try it out for the next one. Thanks for publishing it! On Tuesday, December 2, 2014 2:37:06 PM UTC-8, dan.sto...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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.
Re: [ANN] stateful-check 0.1.0 - test stateful systems with test.check
On Sat, Nov 29, 2014 at 11:34:37AM -0800, tcrayford wrote: Nice! I wrote a sketch of this idea the day after I watched the talk: https://github.com/tcrayford/laundromat, but never pursued it much further (though I do use it in my test suite). Thanks for laundromat. I shamelessly stole the idea to use namespaced keywords to differentiate between the model and reality. -- 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. signature.asc Description: Digital signature
[ANN] stateful-check 0.2.0 - test stateful systems with test.check
On Fri, Nov 28, 2014 at 11:43:56AM +1100, Carlo Zancanaro wrote: I've been working on a library for a little bit which I'm calling stateful-check (at least for now). It's mainly my attempt to work towards the sort of stateful testing that I first saw in John Hughes' talk Testing the Hard Stuff and Staying Sane[1]. https://github.com/czan/stateful-check https://clojars.org/org.clojars.czan/stateful-check I've just released version 0.2.0 to clojars. The main things it fixes are my frustrations at two things: 1. not being able to use `(:key state)` in `:model/next-state` 2. not being able to access the result of the setup function in actual commands, leading to needing a dummy command which has to be run first before any others (which reduces the effectiveness of shrinking) I've also made some keys more consistent in their model/ and real/ prefixes. This means it's not backwards compatible, but it's a simple keyword replacement to fix anything that's broken. Carlo [1]: https://www.youtube.com/watch?v=zi0rHwfiX1Q -- 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. signature.asc Description: Digital signature
Re: [ANN] silc - a tiny entity database for clojure (games)
Cool project! Did you try using the pldb built into core.logic? I have a similar system built atop pldb backing one of my side projects and I'm very happy with it. Reid On 12/02/2014 04:37 PM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: Richelieu: a library for advising functions
Just a small suggestion; I would make :unadvisable namespaced since it's richelieu specific. On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen gary.verhae...@gmail.com wrote: At a very superficial glance, it looks like dire also sort of fits into the same space: https://github.com/MichaelDrogalis/dire On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote: Phillip, Of Robert Hooke's features, I think the ability to suppress advice temporarily (its `with-hooks-disabled`) as well to advise a function within a particular dynamic scope (`with-scope`) are most relevant to Richelieu. Since one of the major goals of Richelieu is to serve as a generic basis for advising, I'll probably implement a `with-advice-disabled` form that takes a sequence of advisedf-and-advicef-set values to temporarily suppress. R.H. and Richelieu, while they do much the same thing, seem to be orthogonal to each other in terms of intent: Richelieu exists to allow folks to write arbitrary advice-based facilities that are oblivious to each others' existences, decorating functions that weren't written with being advised in mind—think tracing and profiling. Phil, on the other hand, focused on providing a facility for developers who anticipate that their code might be advised à la the Emacs hooks mechanism. Or not. I'm totally speculating. As for the name, I guess I'm willing to overlook some semantic quibbles—especially since something very similar to Emacs's normal hooks could easily built atop R.H.—in pursuit of a charming allusion. Edwin On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk School of Computing Science,http://homepages.cs.ncl.ac. uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: [ANN] silc - a tiny entity database for clojure (games)
This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: [ANN] silc - a tiny entity database for clojure (games)
Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen mu...@muhuk.com wrote: This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: Richelieu: a library for advising functions
I think you're right; I was going back and forth on that. -- Edwin Watkeys, 917-324-2435 On Dec 2, 2014, at 20:52, Atamert Ölçgen mu...@muhuk.com wrote: Just a small suggestion; I would make :unadvisable namespaced since it's richelieu specific. On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen gary.verhae...@gmail.com wrote: At a very superficial glance, it looks like dire also sort of fits into the same space: https://github.com/MichaelDrogalis/dire On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote: Phillip, Of Robert Hooke's features, I think the ability to suppress advice temporarily (its `with-hooks-disabled`) as well to advise a function within a particular dynamic scope (`with-scope`) are most relevant to Richelieu. Since one of the major goals of Richelieu is to serve as a generic basis for advising, I'll probably implement a `with-advice-disabled` form that takes a sequence of advisedf-and-advicef-set values to temporarily suppress. R.H. and Richelieu, while they do much the same thing, seem to be orthogonal to each other in terms of intent: Richelieu exists to allow folks to write arbitrary advice-based facilities that are oblivious to each others' existences, decorating functions that weren't written with being advised in mind—think tracing and profiling. Phil, on the other hand, focused on providing a facility for developers who anticipate that their code might be advised à la the Emacs hooks mechanism. Or not. I'm totally speculating. As for the name, I guess I'm willing to overlook some semantic quibbles—especially since something very similar to Emacs's normal hooks could easily built atop R.H.—in pursuit of a charming allusion. Edwin On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote: I think yours might be nicer, to be honest, though, although Robert Hooke has some features yours doesn't. Advising entire namespaces is an interesting addition for sure. I still don't understand why Robert Hooke has this name though. I can't have been the only person expecting it to implements hooks. Phil Edwin Watkeys e...@poseur.com writes: Phillip, I’d cry if it weren’t so funny; I’ve just begun to make my way through the lastest Read Eval Print λove and the first page or two dwells on reinvention. At least mine wasn’t intentional. Edwin -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/ycw4pZQBFfs/unsubscribe. To unsubscribe from this group and all its
help with my inefficient instaparse grammar
Hi Everybody,
https://gist.github.com/cced1cf377ed49005704 *instaparse_question.clj*
https://gist.github.com/anonymous/cced1cf377ed49005704#file-instaparse_question-clj
Raw
https://gist.github.com/anonymous/cced1cf377ed49005704/raw/220ff32218839db388261fd8e2489288a0093606/instaparse_question.clj
12345678910111213141516171819202122232425
(ns lua-map-parser.instaparse-question
(:require [instaparse.core :as insta]))
(let [parser (insta/parser
lua-file = {map-decl|return-statement}
map-decl = 'local' identifier '=' '{' {
map-entry} '}' ;
identifier = #'[a-zA-Z\\_][0-9a-zA-Z\\-\\_]*' ;
map-entry = '[' (string|number) ']' '='
(string|number) ;
string = '\\\' #'([^\]|.)*' '\\\' ;
number = integer | decimal ;
decimal = #'-?[0-9]+\\.[0-9]+' ;
integer = #'-?[0-9]+' ;
return-statement = 'return' identifier
:auto-whitespace :comma)]
(defn lua-map-parser [str]
(parser str)))
(lua-map-parser local CTRData = {
[1]=2 ,
[\3\]=4 }
local MYData = { [\hello\] = \world\
[\sunil\] = 1 [\satish\] = \office\
[\dad\]=\home\ }
return CTRData
)
The above grammar simply parses a map in lua-syntax. It works for the above
case. However, when I try to use it on a file that is about 1 MB in size,
it fails(not sure didn't wait longer than 2 minutes). I would love to hear
if there is something that is grossly inefficient in the way I have
represented my grammar. The lua interpreter loads the file in no time (well
0.06 sec) . I would love any feedback on improving the grammar. Thanks
Sunil.
--
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.
Dynamic args in delayed function calls
Hi All, I was working on a music notation issue with my music libraries Pink and Score and came upon a solution I thought was curious. It certainly solved a real problem I had with delayed function calls, and I thought maybe others might find a use for it too. The scenario I had is that in writing events, I needed to find a way to have certain arguments be dynamic at the time of application of the function, rather than the time of event creation. For example: [fm 2.5 0.3 (env [0.0 500 0.5 1000]) 0.3] when processed by Score and Pink, would yield an event data structure where the 3rd argument to the fm function would be a stateful function generated by (env ...). That would be fine if that the event was used once, but if the event was reused (i.e. I want to listen to that block of score again...), the function returned by (env) would have already been processed. The code I came up with is at [1]. It allowed so that I could use: [fm 2.5 0.3 (!*! env [0.0 500 0.5 1000]) 0.3] and everytime the fm was applied, the code within the !*! was run at apply time. This ends up using the apply!*! function from [1] instead of apply to resolve that argument when applying the fm function. I found this curious as it meant that I didn't have to write a new wrapper function just to dynamically create arguments to call the fm function, such as: [#(fm 0.3 (env [0.0 500 0.5 1000]) 0.3) 0.25] which seemed a bit more noisy and less clear to the intent of the event code. I tried to think of a more general scenario where this might be useful. I came up with two examples, the first was composing a logging function: user= (def logger (partial apply!*! println [ (!*! #(str (new java.util.Date))) ])) #'user/logger user= (logger testing2) [ Tue Dec 02 22:22:44 EST 2014 ] testing2 nil user= (logger testing3) [ Tue Dec 02 22:22:50 EST 2014 ] testing3 Not too exciting, I know. On the other hand, I thought about FRP, and came up with: user= (defn r!*! [func args] #_= (reify IDeref #_= (deref [_] (apply!*! func args))) #_= ) #'user/r!*! user= (def a (atom 45)) #'user/a user= (def b (r!*! * (!*! deref a) 10)) #'user/b user= @a 45 user= @b 450 user= (reset! a 50) 50 user= @b 500 user= (def c (r!*! + (!*! deref b) 6)) #'user/c user= @c 506 user= (reset! a 10) 10 user= @a 10 user= @b 100 user= @c 106 I thought the notation of the r!*! reactive cells above looked nice to write, and using IDeref captured a bit of the idea of working with time-varying values. That could also be a little clearer with: user= (def sig (partial !*! deref)) #'user/sig user= (def c (r!*! + (sig b) 6)) #'user/c user= @c 106 The code at [1] is pretty small, but seemed to open up a number of interesting ways to express things that I hadn't thought about before in terms of apply-time of functions. Any feedback/comments/advice very welcome! Thanks! steven [1] - https://github.com/kunstmusik/pink/blob/master/src/pink/util.clj#L9-L29 -- 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.
Re: [ANN] silc - a tiny entity database for clojure (games)
Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) https://www.google.com/search?q=youtube+gangnam+overflow -- 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.
Re: [ANN] silc - a tiny entity database for clojure (games)
I don't feed trolls. On Wed, Dec 3, 2014 at 10:10 AM, Atamert Ölçgen mu...@muhuk.com wrote: Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen mu...@muhuk.com wrote: This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.stone16...@gmail.com wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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.
Re: help with my inefficient instaparse grammar
The file I tried it on is here
https://gist.github.com/8c0daef5b832b58c86fa
On Wed, Dec 3, 2014 at 10:28 AM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hi Everybody,
https://gist.github.com/cced1cf377ed49005704 *instaparse_question.clj*
https://gist.github.com/anonymous/cced1cf377ed49005704#file-instaparse_question-clj
Raw
https://gist.github.com/anonymous/cced1cf377ed49005704/raw/220ff32218839db388261fd8e2489288a0093606/instaparse_question.clj
12345678910111213141516171819202122232425
(ns lua-map-parser.instaparse-question
(:require [instaparse.core :as insta]))
(let [parser (insta/parser
lua-file = {map-decl|return-statement}
map-decl = 'local' identifier '=' '{' { map-entry}
'}' ;
identifier = #'[a-zA-Z\\_][0-9a-zA-Z\\-\\_]*' ;
map-entry = '[' (string|number) ']' '='
(string|number) ;
string = '\\\' #'([^\]|.)*' '\\\' ;
number = integer | decimal ;
decimal = #'-?[0-9]+\\.[0-9]+' ;
integer = #'-?[0-9]+' ;
return-statement = 'return' identifier
:auto-whitespace :comma)]
(defn lua-map-parser [str]
(parser str)))
(lua-map-parser local CTRData = {
[1]=2 ,
[\3\]=4 }
local MYData = { [\hello\] = \world\
[\sunil\] = 1 [\satish\] = \office\
[\dad\]=\home\ }
return CTRData
)
The above grammar simply parses a map in lua-syntax. It works for the
above case. However, when I try to use it on a file that is about 1 MB in
size, it fails(not sure didn't wait longer than 2 minutes). I would love
to hear if there is something that is grossly inefficient in the way I have
represented my grammar. The lua interpreter loads the file in no time (well
0.06 sec) . I would love any feedback on improving the grammar. Thanks
Sunil.
--
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.
