Re: [ANN] clafka 0.1.0 - a clojure kafka client focusing on the SimpleConsumer and KafkaProducer.
Great work! Thanks for sharing! On Tue, Jun 9, 2015 at 10:19 AM, dan.stone16...@gmail.com wrote: I am pleased to announce the release of the initial version of our new kafka library! I see this library as useful for people that want to... a. Read some data from their kafka logs worry free (no consumer groups, no state etc) b. Implement a new kind of consumer, as their needs are not met by the default zookeeper consumer in kafka (like us!) c. Use a clojure wrapper for the new KafkaProducer api (including broker acknowledgement) Source and docs here: https://github.com/mixradio/clafka Questions, comments and contributions very welcome! Regards, 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. -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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: Actually using component.
I think the most important rule when using component is to only use local
state like Timothy stated, i.e. nothings gets def-ed. You could write an
application that a -main function that starts the system and you would
never need a global reference to the system.
In practise however, you do make references to the current system to
support working in the REPL (see README here
https://github.com/stuartsierra/component/#reloading) and I also use
references to the system to inspect db state etc in tests, but for that
`let` blocks also work well.
I would recommend to continue playing with the bare metal component for a
while to get an understanding of the concept, after a while I think you
will want something smarter. We're using system-graph
https://github.com/RedBrainLabs/system-graph that helps to stop thinking
and managing dependencies and recently we have a built a small layer on top
of that so we even have flexible graphs in a convenient way.
On Tue, Jun 9, 2015 at 8:33 AM, Atamert Ölçgen mu...@muhuk.com wrote:
On Tue, Jun 9, 2015 at 6:12 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:
Stuart addresses two anti-patterns in your PRs. Perhaps I can help
explain them.
Let's say we have a system that looks like this:
(defrecord DBConnection [])
(defrecord DBLayer [db-connection])
(defrecord AppLayer [db-layer])
We can construct a system thusly:
{:db-connection (-DBConnection ...)
:db-layer (-DBLayer ...)
:app-layer (-AppLayer ...)}
And start it up:
(def my-system (start-system system-map))
First of all, what you need to recognize is that every component now has
it's dependencies assoc'ed into the component. So each component should
only deal with it's local view of the system:
(defrecord AppLayer [db-layer]
IDoStuff
(do-stuff [this]
(print-data (get-data db-layer)
(get-data2 (:db-layer this)))
What should not happen is that the AppLayer should do this:
(print-data (:db-layer my-system))
If a component does this it now has access to the entire system, and that
circumvents one of the reasons component was created, to help improve
separation of concerns.
In your other example you're doing something like this:
(defrecord AppLayer [db-layer]
IDoStuff
(do-stuff [this]
(run-query (:db-conn db-layer) select foo from bar)))
The problem with this is that AppLayer is assuming that the db-layer has
a connection to the db. This also violates the separation of concerns.
Instead AppLayer should include a db-connection as a dependency if it is
needed by the app layer code.
This is also known as The Law of Demeter. (
http://en.wikipedia.org/wiki/Law_of_Demeter)
- Each unit should have only limited knowledge about other units: only
units closely related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
So that sums up Stuart's two replies. a) don't touch the system from
inside a component, the system map is only for starting and stopping the
system, and to provide an entry point. b) don't reach into other components
from a component
Timothy
On Mon, Jun 8, 2015 at 9:35 PM, James Reeves ja...@booleanknot.com
wrote:
My recommendation is to use a closure. So I'd write your example as:
(defn username-endpoint [{:keys [db]}]
(routes
(GET /:username [username]
(let [user (users/get-user db username)]
(str h1Hello (:name user) /h1)
So you pass your configuration map into the endpoint function, which
returns a handler.
You can then wrap this in a component:
(defrecord EndpointComponent [build-routes]
component/Lifecycle
(start [component]
(if (:routes component)
component
(assoc component :routes (build-routes component
(stop [component]
(dissoc component :routes)))
Incidentally, the above code is taken directly from Duct
https://github.com/weavejester/duct, a template and small supporting
library I've written for building component-based web apps.
I've also written a blog article
https://www.booleanknot.com/blog/2015/05/22/structuring-clojure-web-apps.html
around
general best practice for this type of style.
- James
On 8 June 2015 at 22:51, Dru Sellers d...@drusellers.com wrote:
So, I guess I am a bit lost, how does someone actually use component? I
have an application all set up with it and it seems to be working as I
would expect but Stuart seems to be steering me in a different direction.
https://github.com/stuartsierra/component/pull/35
https://github.com/stuartsierra/component/issues/34
So I'll try and paint a full picture.
https://gist.github.com/drusellers/8109dce4b9fb19c14ebb
I know compojure and component / reloaded may not play well, but I'm
trying to figure out how to best use the system var. Am I close, I'd love
to give back a decent PR to the README.md of the component repo to help
others as they come along.
-d
--
[ANN] clafka 0.1.0 - a clojure kafka client focusing on the SimpleConsumer and KafkaProducer.
I am pleased to announce the release of the initial version of our new kafka library! I see this library as useful for people that want to... a. Read some data from their kafka logs worry free (no consumer groups, no state etc) b. Implement a new kind of consumer, as their needs are not met by the default zookeeper consumer in kafka (like us!) c. Use a clojure wrapper for the new KafkaProducer api (including broker acknowledgement) Source and docs here: https://github.com/mixradio/clafka Questions, comments and contributions very welcome! Regards, 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: I created a new macro if-let-all
Where does if-let-all serve people best? Can anyone help me find the right clojure project to contribute to? On Friday, June 5, 2015 at 2:44:22 PM UTC+9, crocket wrote: The macro below is called if-let-all. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) You can use it as (if-let-all [a 2 b 3] (+ a b) oh no!!). false-case doesn't have access to local bindings. -- 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.
Problem with loading protocols dynamically from checkouts
Hi everyone, I have a mutli-project set-up using Leiningen checkouts. I have a protocols project where I store all my needed protocols and another project depends on this project. I linked the project folder to the checkout folder of the project that depends on the protocols. However, when I change a protocol in the protocols project, I have to call a lein install, re-start REPL to see the effects of this in the dependent project. As far as I understood, Protocols are dynamically built and, therefore, I don't need to restart and reload it. Do you have any idea what I might be doing wrong? Or is this an expected behavior and I'm missing something? Thanks in advance. Regards, Timur -- 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.
Where should 'if-let-all' macro go?
It evaluates true-case only if every local binding evaluates to true values. false-case has no access to local bindings. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) I think this macro could benefit people if I found the right project where it should reside. Can anyone help me find the right project for if-let-all? -- 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: Actually using component.
On Tue, Jun 9, 2015 at 6:12 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:
Stuart addresses two anti-patterns in your PRs. Perhaps I can help explain
them.
Let's say we have a system that looks like this:
(defrecord DBConnection [])
(defrecord DBLayer [db-connection])
(defrecord AppLayer [db-layer])
We can construct a system thusly:
{:db-connection (-DBConnection ...)
:db-layer (-DBLayer ...)
:app-layer (-AppLayer ...)}
And start it up:
(def my-system (start-system system-map))
First of all, what you need to recognize is that every component now has
it's dependencies assoc'ed into the component. So each component should
only deal with it's local view of the system:
(defrecord AppLayer [db-layer]
IDoStuff
(do-stuff [this]
(print-data (get-data db-layer)
(get-data2 (:db-layer this)))
What should not happen is that the AppLayer should do this:
(print-data (:db-layer my-system))
If a component does this it now has access to the entire system, and that
circumvents one of the reasons component was created, to help improve
separation of concerns.
In your other example you're doing something like this:
(defrecord AppLayer [db-layer]
IDoStuff
(do-stuff [this]
(run-query (:db-conn db-layer) select foo from bar)))
The problem with this is that AppLayer is assuming that the db-layer has a
connection to the db. This also violates the separation of concerns.
Instead AppLayer should include a db-connection as a dependency if it is
needed by the app layer code.
This is also known as The Law of Demeter. (
http://en.wikipedia.org/wiki/Law_of_Demeter)
- Each unit should have only limited knowledge about other units: only
units closely related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
So that sums up Stuart's two replies. a) don't touch the system from
inside a component, the system map is only for starting and stopping the
system, and to provide an entry point. b) don't reach into other components
from a component
Timothy
On Mon, Jun 8, 2015 at 9:35 PM, James Reeves ja...@booleanknot.com
wrote:
My recommendation is to use a closure. So I'd write your example as:
(defn username-endpoint [{:keys [db]}]
(routes
(GET /:username [username]
(let [user (users/get-user db username)]
(str h1Hello (:name user) /h1)
So you pass your configuration map into the endpoint function, which
returns a handler.
You can then wrap this in a component:
(defrecord EndpointComponent [build-routes]
component/Lifecycle
(start [component]
(if (:routes component)
component
(assoc component :routes (build-routes component
(stop [component]
(dissoc component :routes)))
Incidentally, the above code is taken directly from Duct
https://github.com/weavejester/duct, a template and small supporting
library I've written for building component-based web apps.
I've also written a blog article
https://www.booleanknot.com/blog/2015/05/22/structuring-clojure-web-apps.html
around
general best practice for this type of style.
- James
On 8 June 2015 at 22:51, Dru Sellers d...@drusellers.com wrote:
So, I guess I am a bit lost, how does someone actually use component? I
have an application all set up with it and it seems to be working as I
would expect but Stuart seems to be steering me in a different direction.
https://github.com/stuartsierra/component/pull/35
https://github.com/stuartsierra/component/issues/34
So I'll try and paint a full picture.
https://gist.github.com/drusellers/8109dce4b9fb19c14ebb
I know compojure and component / reloaded may not play well, but I'm
trying to figure out how to best use the system var. Am I close, I'd love
to give back a decent PR to the README.md of the component repo to help
others as they come along.
-d
--
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
Re: [ANN] Onyx 0.6.0
Michael, Excellent news. Congrats to everyone working on it! cheers, Bruce On Tue, Jun 9, 2015 at 3:37 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Congrats! On Tue, Jun 9, 2015 at 10:35 PM, Michael Drogalis madrush...@gmail.com wrote: I'm happy to announce that Onyx 0.6.0 is officially out! Blog post: http://michaeldrogalis.github.io/jekyll/update/2015/06/08/Onyx-0.6.0:-Going-Faster.html GitHub: https://github.com/onyx-platform/onyx Website: www.onyxplatform.org Chat: https://gitter.im/onyx-platform Thanks to all the contributors that helped make this happen! -- 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. -- 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: Where should 'if-let-all' macro go?
There are several 'utility' libraries for Clojure that may have something like this already, or their authors might be willing to add such a thing: https://github.com/Prismatic/plumbing https://github.com/amalloy/useful Andy On Tue, Jun 9, 2015 at 5:00 AM, crocket crockabisc...@gmail.com wrote: It evaluates true-case only if every local binding evaluates to true values. false-case has no access to local bindings. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) I think this macro could benefit people if I found the right project where it should reside. Can anyone help me find the right project for if-let-all? -- 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.
[ANN] clasew 0.1.10
https://github.com/FrankC01/clasew *clasew *- Clojure AppleScriptEngine Wrapper *Intent* - clasew provides an idiomatic Clojure wrapper for Java ScriptManager: specifically apple.AppleScriptManager, as well as providing scriptable applications HOF DSLs. Realizing that the audience for such capability may be minimal, others may find this a useful addition to the 'niche' library. *General changes in 0.1.10* - Added support for Apple's Numbers spreadsheets (numbers.clj) - Refactor generic spreadsheet ops to new namespace (spreads.clj) *Changes* - All changes details: https://github.com/FrankC01/clasew/blob/master/CHANGES.md Feedback (+/-) and comments (+/-) are always welcome and appreciated. Enjoy Frank V. Castellucci -- 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] Onyx 0.6.0
Congrats! On Tue, Jun 9, 2015 at 10:35 PM, Michael Drogalis madrush...@gmail.com wrote: I'm happy to announce that Onyx 0.6.0 is officially out! Blog post: http://michaeldrogalis.github.io/jekyll/update/2015/06/08/Onyx-0.6.0:-Going-Faster.html GitHub: https://github.com/onyx-platform/onyx Website: www.onyxplatform.org Chat: https://gitter.im/onyx-platform Thanks to all the contributors that helped make this happen! -- 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.
[ANN] Onyx 0.6.0
I'm happy to announce that Onyx 0.6.0 is officially out! Blog post: http://michaeldrogalis.github.io/jekyll/update/2015/06/08/Onyx-0.6.0:-Going-Faster.html GitHub: https://github.com/onyx-platform/onyx Website: www.onyxplatform.org Chat: https://gitter.im/onyx-platform Thanks to all the contributors that helped make this happen! -- 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: Where should 'if-let-all' macro go?
Dunaj has support for multiple bindings in if-let since version 0.5. http://www.dunaj.org/dunaj.flow.api.html#if_let Related design page that discusses possible approaches is at https://github.com/dunaj-project/dunaj/wiki/Conditionals Jozef On Tuesday, June 9, 2015 at 4:00:35 PM UTC+2, Lars Andersen wrote: I actually wish this was how the if-let macro in core worked. Once in a blue moon I end up writing nested if-let statements or an if-let with a nested let. Both of these cases look so ridiculous I often re-write the the code just avoid it. On Tuesday, June 9, 2015 at 2:00:53 PM UTC+2, crocket wrote: It evaluates true-case only if every local binding evaluates to true values. false-case has no access to local bindings. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) I think this macro could benefit people if I found the right project where it should reside. Can anyone help me find the right project for if-let-all? -- 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.
Single-atom update ordering guarantees
This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? -- 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: Single-atom update ordering guarantees
I am not sure why Atamert says No. If the (swap! a inc) and (swap! a dec) are executed in different threads, and they can occur in either order because there is no synchronization between those threads that prevents one of the two possible orders from occurring, then another thread *could* see a value of 0, if and when the (swap! a dec) occurs first. If the (swap! a inc) and (swap! a dec) are executed sequentially in a single thread, and no other thread is modifying a, then by normal sequential execution the atom should change from 1 to 2, then from 2 back to 1. Andy On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote: On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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 www.olcgen.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. -- 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: Single-atom update ordering guarantees
On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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 www.olcgen.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.
[ANN] Satellite, Two Sigma's Monitoring, Alerting, and Self-Healing Application for Apache Mesos
We are pleased to announce that Two Sigma is open-sourcing Satellite, a Mesos monitoring and alerting application with self-healing capabilities. Satellite makes it easy to continuously monitor your cluster, automatically add and remove slaves, and alert you via email or PagerDuty if your cluster becomes unresponsive. Satellite is able to do this by embedding Riemann, leveraging its powerful and simple stream processing DSL. We are releasing Satellite under Apache v2.0. Full source and documentation is on Github: https://github.com/twosigma/satellite. We welcome comments and contributions! You can contact us through this thread, email tsos-satell...@twosigma.com, or Twitter @sabraham. Sunil Abraham Two Sigma Open Source, LLC -- 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: [Job Spam] Looking for a clojure devs
Hi, Thanks to everyone who showed interest and responded to the post, however the startup has already closed the positions and is no longer looking for devs. I would have liked to, but have not been able to respond to each one personally, thus sending in this reply. Thanks to everyone again ! Murtaza On Thursday, June 4, 2015 at 1:15:44 PM UTC+5:30, Murtaza Husain wrote: Hi, A friend's startup is looking for couple of clojure devs. Its a startup and the stack they are using is reagent / clojure / datomic. They are looking for experienced developers with / without clojure experience, however with enthusiasm to learn and excel at the clojure stack. If interested please email me your resume on murtaz...@gmail.com, and I will forward it across. They currently have a remote team working in different time zones, and these positions will also be remote and can be based in any time zone. Thanks, Murtaza -- 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: Single-atom update ordering guarantees
I'm talking about a scenario where a single thread does inc, followed shortly by dec. Obviously from that thread's perspective, the value will never be zero, but what about as seen by other threads? My understanding of Java's memory model is that instructions within a single thread *can* get reordered, and Java only guarantees that they will *appear* to have executed in order from the perspective of the executing thread. Other threads might see those instructions as executing out-of-order. What I'm wondering is whether atoms are subject to this as well. On Jun 9, 2015, at 10:16 AM, Andy Fingerhut andy.finger...@gmail.com wrote: I am not sure why Atamert says No. If the (swap! a inc) and (swap! a dec) are executed in different threads, and they can occur in either order because there is no synchronization between those threads that prevents one of the two possible orders from occurring, then another thread *could* see a value of 0, if and when the (swap! a dec) occurs first. If the (swap! a inc) and (swap! a dec) are executed sequentially in a single thread, and no other thread is modifying a, then by normal sequential execution the atom should change from 1 to 2, then from 2 back to 1. Andy On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote: On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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 www.olcgen.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. -- 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.
Re: Single-atom update ordering guarantees
swap! is implemented using Java's AtomicReference class and its compareAndSet method. I haven't dug into the Java source code implementing that class, but you can read the Java documentation for all Atomic* Java classes here: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html The summary there is that all accesses to Atomic* classes should have similar memory model guarantees as Java fields declared volatile. I don't have a good authoritative link handy for Java documentation on volatile, but the basic idea is that they should not be cached locally by individual threads, but be visible to all. Andy On Tue, Jun 9, 2015 at 11:33 AM, Michael Gardner gardne...@gmail.com wrote: I'm talking about a scenario where a single thread does inc, followed shortly by dec. Obviously from that thread's perspective, the value will never be zero, but what about as seen by other threads? My understanding of Java's memory model is that instructions within a single thread *can* get reordered, and Java only guarantees that they will *appear* to have executed in order from the perspective of the executing thread. Other threads might see those instructions as executing out-of-order. What I'm wondering is whether atoms are subject to this as well. On Jun 9, 2015, at 10:16 AM, Andy Fingerhut andy.finger...@gmail.com wrote: I am not sure why Atamert says No. If the (swap! a inc) and (swap! a dec) are executed in different threads, and they can occur in either order because there is no synchronization between those threads that prevents one of the two possible orders from occurring, then another thread *could* see a value of 0, if and when the (swap! a dec) occurs first. If the (swap! a inc) and (swap! a dec) are executed sequentially in a single thread, and no other thread is modifying a, then by normal sequential execution the atom should change from 1 to 2, then from 2 back to 1. Andy On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote: On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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 www.olcgen.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. -- 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
Re: Single-atom update ordering guarantees
Thanks. That does appear to provide the guarantee I was looking for. On Jun 9, 2015, at 12:14 PM, Andy Fingerhut andy.finger...@gmail.com wrote: swap! is implemented using Java's AtomicReference class and its compareAndSet method. I haven't dug into the Java source code implementing that class, but you can read the Java documentation for all Atomic* Java classes here: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html The summary there is that all accesses to Atomic* classes should have similar memory model guarantees as Java fields declared volatile. I don't have a good authoritative link handy for Java documentation on volatile, but the basic idea is that they should not be cached locally by individual threads, but be visible to all. Andy On Tue, Jun 9, 2015 at 11:33 AM, Michael Gardner gardne...@gmail.com wrote: I'm talking about a scenario where a single thread does inc, followed shortly by dec. Obviously from that thread's perspective, the value will never be zero, but what about as seen by other threads? My understanding of Java's memory model is that instructions within a single thread *can* get reordered, and Java only guarantees that they will *appear* to have executed in order from the perspective of the executing thread. Other threads might see those instructions as executing out-of-order. What I'm wondering is whether atoms are subject to this as well. On Jun 9, 2015, at 10:16 AM, Andy Fingerhut andy.finger...@gmail.com wrote: I am not sure why Atamert says No. If the (swap! a inc) and (swap! a dec) are executed in different threads, and they can occur in either order because there is no synchronization between those threads that prevents one of the two possible orders from occurring, then another thread *could* see a value of 0, if and when the (swap! a dec) occurs first. If the (swap! a inc) and (swap! a dec) are executed sequentially in a single thread, and no other thread is modifying a, then by normal sequential execution the atom should change from 1 to 2, then from 2 back to 1. Andy On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote: On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote: This might be blindingly obvious to some, but I can't find any discussion about it. Let's say I have code like the following: (def a (atom 1)) ... (swap! a inc) (swap! a dec) Is there any possibility of another thread seeing a=0? If not, what provides this guarantee? No. Not if those two swap! calls are made from different threads. -- 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 www.olcgen.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. -- 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
Re: Where should 'if-let-all' macro go?
At least based on my uses, I agree that this would likely bring the most use of the now unused binding space in cores if-let. I can't think of any useful alternatives. Syntactically though, one could worry that the additional bindings would be read as regular let bindings and worry about the language clarity. I don't have the distance of a naive Clojure reader to position myself there. I remember, that when I started learning Clojure, I thought that I could just use the vector for additional regular let bindings. I think that I read the doc string first which would explain why I expected conditional evaluation only for the first binding. The other problem is that design wise, it opens up the possibility to abuse the vector for regular let bindings, a la These exprs are going to evaluate to logical truth anyways, as long as I have other things to worry about, they will get their own let later. Clojures design often helps writing clean code and this limitation could be seen as (very small) part of that. I must also say that I have rarely used or seen more than two nested if-lets. In such a case one should usually consider refactoring. On Wednesday, June 10, 2015 at 12:23:40 AM UTC+2, Fluid Dynamics wrote: There's a variant of this in one of my projects as well. If this is in several utility libraries *and* half the world keeps Greenspunning versions of it in their own projects, then it might be something that belongs in core ... -- 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: Single-atom update ordering guarantees
On Tuesday, June 9, 2015 at 4:24:16 PM UTC-4, Michael Gardner wrote: Thanks. That does appear to provide the guarantee I was looking for. On Jun 9, 2015, at 12:14 PM, Andy Fingerhut andy.fi...@gmail.com javascript: wrote: swap! is implemented using Java's AtomicReference class and its compareAndSet method. I haven't dug into the Java source code implementing that class, but you can read the Java documentation for all Atomic* Java classes here: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html The summary there is that all accesses to Atomic* classes should have similar memory model guarantees as Java fields declared volatile. I don't have a good authoritative link handy for Java documentation on volatile, but the basic idea is that they should not be cached locally by individual threads, but be visible to all. My own recollection jibes with this: atom changes are memory-barriered. OTOH, if the atom is swap!ped concurrently by other threads, all bets are off. Some other thread might dec it in between your thread's inc and dec of it. If you need to guard against that as well, then you need refs and dosync and to inc and then dec within a transaction. Then the whole sequence of events of ... inc ... dec ... becomes atomic from the perspective of other threads, and not just the inc and the dec, separately. -- 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: Actually using component.
On 9 June 2015 at 23:16, Dru Sellers d...@drusellers.com wrote:
@James do you only have one component that has all of your routes? or do
you have each component supply its own routes? If you imagine a component
providing its own routes, I'd love to see a duct example with two routes
set up.
I believe that would be multiple endpoint components.
Looking at
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj#L7
I'm guessing that duct only expects one endpoint-component - is that
correct?
No, you can have as many endpoint components as you want.
Duct has a handler component that looks for endpoint components in its
dependencies, and combines their routes together using
compojure.core/routes.
One of the ideas in Duct is to group routes together by purpose, to achieve
the modularity of micro-service architecture without the overhead.
For example, let's say you have endpoints foo, bar and baz. Then your
system builder in Duct would look like:
(defn new-system [config]
(let [config (meta-merge base-config config)]
(- (component/system-map
:http (jetty-server (:http config))
:app (handler-component (:app config))
:foo (endpoint-component foo-endpoint)
:bar (endpoint-component bar-endpoint)
:baz (endpoint-component baz-endpoint))
(component/system-using
{:http [:app]
:app [:foo :bar :baz]}
- James
--
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: Actually using component.
@James do you only have one component that has all of your routes? or do
you have each component supply its own routes? If you imagine a component
providing its own routes, I'd love to see a duct example with two routes
set up.
I believe that would be multiple endpoint components.
Looking
at
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj#L7
I'm guessing that duct only expects one endpoint-component - is that
correct?
-d
On Monday, June 8, 2015 at 8:36:36 PM UTC-5, James Reeves wrote:
My recommendation is to use a closure. So I'd write your example as:
(defn username-endpoint [{:keys [db]}]
(routes
(GET /:username [username]
(let [user (users/get-user db username)]
(str h1Hello (:name user) /h1)
So you pass your configuration map into the endpoint function, which
returns a handler.
You can then wrap this in a component:
(defrecord EndpointComponent [build-routes]
component/Lifecycle
(start [component]
(if (:routes component)
component
(assoc component :routes (build-routes component
(stop [component]
(dissoc component :routes)))
Incidentally, the above code is taken directly from Duct
https://github.com/weavejester/duct, a template and small supporting
library I've written for building component-based web apps.
I've also written a blog article
https://www.booleanknot.com/blog/2015/05/22/structuring-clojure-web-apps.html
around
general best practice for this type of style.
- James
On 8 June 2015 at 22:51, Dru Sellers d...@drusellers.com javascript:
wrote:
So, I guess I am a bit lost, how does someone actually use component? I
have an application all set up with it and it seems to be working as I
would expect but Stuart seems to be steering me in a different direction.
https://github.com/stuartsierra/component/pull/35
https://github.com/stuartsierra/component/issues/34
So I'll try and paint a full picture.
https://gist.github.com/drusellers/8109dce4b9fb19c14ebb
I know compojure and component / reloaded may not play well, but I'm
trying to figure out how to best use the system var. Am I close, I'd love
to give back a decent PR to the README.md of the component repo to help
others as they come along.
-d
--
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.
--
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: Where should 'if-let-all' macro go?
There's a variant of this in one of my projects as well. If this is in several utility libraries *and* half the world keeps Greenspunning versions of it in their own projects, then it might be something that belongs in core ... -- 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: About transients no longer being safe in 1.7-alpha2
Yes -- 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: Prevayler in Clojure
Nice job, so much in a few lines of code. Thanks, Dennis Op zaterdag 30 mei 2015 22:58:23 UTC+2 schreef Klaus Wuestefeld: Prevalence is the fastest possible and third simplest ACID persistence technique, combining the two simplest ones. https://github.com/klauswuestefeld/prevayler-clj -- 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: PersistentTreeMap, seqFrom, subseq and range queries
I think the subset and submap would be a nice addition! Op maandag 15 februari 2010 16:23:22 UTC+1 schreef Rich Hickey: On Mon, Feb 15, 2010 at 8:45 AM, George . cloju...@gmail.com javascript: wrote: Currently, if you want to perform a range query on a sorted-seq (AKA PersistentTreeMap), you are are advised to use the subseq wrapper for seqFrom. For instance, let's say your keys are dollar values you could do (subseq my-map 30) to get all entries with keys greater than 30 or (subseq my-map 30 100) to get all entries with keys that range between 30 and 11. The former case is O(logN) as it is entirely delegated to the logarithmic seqFrom method. However, the latter example has worst case O(N) behavior since subseq is doing a take-while after .seqFrom. Is there any plan to support upper bounds directly within seqFrom in order to make the worst-case behavior logarithmic all around? If not, would such a patch even be considered or is the simplicity of implementation an overriding factor? I'm confused. Do you want something other than a seq of values in range as a result? Because if there are K things in range, there is no way to consume them in complexity less than O(K). That cost won't be incurred until you consume them, due to take-while being lazy. OTOH, if what you want is a subset or submap, or, from them, a constant-time count, well, that's a different function altogether. I'm not opposed to subset or submap proposals. Rich -- 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: Problem with loading protocols dynamically from checkouts
Reloading a protocol definition invalidates any instances of objects which implement the protocol. This may be the problem you are seeing. After reloading a protocol definition, you must also reload any code with `deftype`, `defrecord`, or `reify` which implements the protocol, THEN re-evaluate any code which creates instances of those types. For more discussion of this issue, see the tools.namespace docs under Warnings for Protocols: https://github.com/clojure/tools.namespace#warnings-for-protocols –S On Tuesday, June 9, 2015 at 6:42:31 AM UTC-4, Timur wrote: Hi everyone, I have a mutli-project set-up using Leiningen checkouts. I have a protocols project where I store all my needed protocols and another project depends on this project. I linked the project folder to the checkout folder of the project that depends on the protocols. However, when I change a protocol in the protocols project, I have to call a lein install, re-start REPL to see the effects of this in the dependent project. As far as I understood, Protocols are dynamically built and, therefore, I don't need to restart and reload it. Do you have any idea what I might be doing wrong? Or is this an expected behavior and I'm missing something? Thanks in advance. Regards, Timur -- 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: Problem with loading protocols dynamically from checkouts
Thanks for the answer Stuart. I was receiving an error when I reload deftype, the error was saying that I cannot define a method of a protocol which is not defined in the protocol although I could even see the method in the protocol map. I just discovered the error: I forgot the :aot field referring to this specific namespace in my lein configuration and as far as I understood the aot compiled classes in the local maven cache have priority, therefore, it needed me to do a lein install each time. Regards, Timur On Tuesday, June 9, 2015 at 2:10:59 PM UTC+2, Stuart Sierra wrote: Reloading a protocol definition invalidates any instances of objects which implement the protocol. This may be the problem you are seeing. After reloading a protocol definition, you must also reload any code with `deftype`, `defrecord`, or `reify` which implements the protocol, THEN re-evaluate any code which creates instances of those types. For more discussion of this issue, see the tools.namespace docs under Warnings for Protocols: https://github.com/clojure/tools.namespace#warnings-for-protocols –S On Tuesday, June 9, 2015 at 6:42:31 AM UTC-4, Timur wrote: Hi everyone, I have a mutli-project set-up using Leiningen checkouts. I have a protocols project where I store all my needed protocols and another project depends on this project. I linked the project folder to the checkout folder of the project that depends on the protocols. However, when I change a protocol in the protocols project, I have to call a lein install, re-start REPL to see the effects of this in the dependent project. As far as I understood, Protocols are dynamically built and, therefore, I don't need to restart and reload it. Do you have any idea what I might be doing wrong? Or is this an expected behavior and I'm missing something? Thanks in advance. Regards, Timur -- 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: Where should 'if-let-all' macro go?
On Jun 9, 2015, at 3:51 PM, Leon Grapenthin grapenthinl...@gmail.com wrote: Syntactically though, one could worry that the additional bindings would be read as regular let bindings and worry about the language clarity. One of the main points that I seem to recall from previous discussions has been around the actual behavior of this sort of code (if it was allowed): (if-let [a (some-a-fn) b (some-b-fn) c (some-c-fn)] (some-t-fn) (some-f-fn)) Should it short-circuit as soon as one of `a`, `b`, or `c` is falsey? Should it evaluate all three and require all three to be truthy? Should it evaluate all three and base the test on just the last one (a reasonable alternative semantic)? If `a` is truthy and `b` is falsey, why shouldn’t `a` be available in the false arm of the `if`? And, related, should the `b` and `c` expressions have access to the (truthy) values of `a`? There are arguments in favor of (and against) each position and thus no clear consensus on what to choose. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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.
reduce-kv and java.util.Map
Hi all, Looking at IKVReduce I see it is only implemented for the clojure.lang data structures, whereas CollReduce is implemented in terms of Iterables. Is there a reason IKVReduce isn't extended to cover java.util.Map? It seems it would be natural to call .entrySet(), get an iterator, and loop over that, and for each element calling .getKey() and .getValue() to pass to a function. If this isn't already on some feature branch somewhere, I'd be happy to take a crack at adding it. Thanks! -- 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: Where should 'if-let-all' macro go?
I actually wish this was how the if-let macro in core worked. Once in a blue moon I end up writing nested if-let statements or an if-let with a nested let. Both of these cases look so ridiculous I often re-write the the code just avoid it. On Tuesday, June 9, 2015 at 2:00:53 PM UTC+2, crocket wrote: It evaluates true-case only if every local binding evaluates to true values. false-case has no access to local bindings. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) I think this macro could benefit people if I found the right project where it should reside. Can anyone help me find the right project for if-let-all? -- 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: Where should 'if-let-all' macro go?
this if-let-all do not support destructure, I writed a improved https://gist.github.com/gfZeng/8e8e18f148d5742b064c On Tuesday, June 9, 2015 at 8:00:53 PM UTC+8, crocket wrote: It evaluates true-case only if every local binding evaluates to true values. false-case has no access to local bindings. (defmacro if-let-all if-let-all evaluates every local binding sequentially and evaluates true-case only if every local binding is a truthy value. true-case has access to all local bindings, but false-case doesn't have access to local bindings. [bindings true-case false-case] (let [pairs (partition 2 bindings) names (mapv first pairs) exprs (map second pairs) exprs-in-if-let (fn self [[name1 more-names] [expr1 more-exprs]] `(if-let [~name1 ~expr1] ~(if more-names (self more-names more-exprs) names))) things (exprs-in-if-let names exprs)] `(if-let [~names ~things] ~true-case ~false-case))) I think this macro could benefit people if I found the right project where it should reside. Can anyone help me find the right project for if-let-all? -- 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.
