Re: core.async go-loop questions

You could probably move setting the atom and calling my-wait-loop inside the try. (defn test-mailer [] (async/thread (try (do (reset! mailer-status (mailer/send-speaker-confirmation-notification 1 " http://localhost";)) (my-wait-loop)) (catch Excep

Re: core.async go-loop questions

I'm a little uncertain exactly what your code is trying to do, but I believe you're trying to notify a bunch of connections after your speaker notification emails are sent. In which case, I'd do something like this: (defn send-notifications [] (try (mailer/send-speaker-confirmation-notifica

Re: core.async go-loop questions

Part of what makes core.async great is that you don't have to use atoms to communicate between threads in every case. For your case, I don't see what using an atom gets you. It seems like you could replace the atom with a channel, and put values on the channel whenever mail is sent. Your code will

core.async go-loop questions

I'd like to implement a thread that will send an email, then send a response via websocket to the client when the send completes. (defn my-wait-loop [] (async/go-loop [status (async/http://localhost";) (catch Exception e (println (.getMessage e "Suc

Re: Clojure Style Guide

Protip: you already can. From my .emacs: (define-clojure-indent (defroutes 'defun) (GET 2) (POST 2) (PUT 2) (DELETE 2) (HEAD 2) (ANY 2) (context 2) (for-all 1) (such-that 1) (let-routes 1) (run-db 2) (defspec 'defun)) Reid On 12/20/14 16:28, John Jacobsen wrote: Great

Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library

Hi Leon, So the reason for rx bindings not being default is really quite simple - freactive is not a macro framework but uses pure functions and I preferred giving more power to the user rather than doing something "auto-magically" that may not always be desired. One could write a simple macro tha

Re: Contrats to Cursive!!!

Thanks Marcus! That was great to see. Some of my earliest beta testers are at ThoughtWorks, it's nice to see so much Clojure adoption over there. As was mentioned the other day, there's lots of Clojure goodness on the latest radar - Gorilla REPL, Om, Reagent, Core Async and of course Clojure itsel

Re: Clojure Style Guide

Thanks for bringing this up here and linking to the issue I raised on GH. I wanted to start a discussion here as well but have not yet found time. My concerns and worries are less about the style-guide in general and more about the indentation change regarding assoc introduced as default in cl

Re: Clojure Style Guide

Great to see this discussion on the mailing list, rather than just comments to PRs on GitHub. And a big thanks to Bozhidar for shepherding the current style guide. I came to Clojure from Python which has a strict standard (PEP-8) and a linting tool which enforces a standard -- it's been my exp

Re: ANN Cassaforte 2.0 is released

On 20 December 2014 at 19:33:23, Michael Klishin (michael.s.klis...@gmail.com) wrote: > Cassaforte [1] is a modern Clojure client for Apache Cassandra > and DataStax Enterprise. > > 2.0 is a major release with breaking API changes. Release notes: > http://blog.clojurewerkz.org/blog/2014/12/2

Contrats to Cursive!!!

Hey Colin, contrats to Cursive for making it into the “Trial” section of the 1/2015 Tools section of ThoughtWorks Technology Radar! Nice work! http://www.thoughtworks.com/radar/tools Best, Marcus Marcus Blankenship \\\ Problem Solver, Linear Thinker \\\ 541.805.2736 \ @justzeros \ skype:marc

Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library

Hi Aaron, I am currently experimenting with freactive. I find it quite awesome to begin with. Here are some questions that I found unanswered: - Why are rx-bindings not the default? It feels a bit redundant to wrap forms in (rx ...) all the time. - What is the rationale behind the second a

ANN: Grimoire 0.4

Grimoire, http://conj.io, hosts documentation of Clojure and other libraries indexed for quick reference by myself and Andy F. This release brings the addition of a JSON/EDN API, http://conj.io/api, the addition of documentation for 1.7 and huge internal refactor to make Grimoire more stable,

ANN: Om 0.8.0-beta4

The main change is getting back in sync with React 0.12.2 plus a few small enhancements. Feedback welcome! https://github.com/swannodette/om David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegro

Re: atoms, memoize, future-s and CAS

Hi, Thanks for all suggestions. It all encouraged me to deep dive into atom-s code which turns out to be a simple wrapper over Java java.util.concurrent.atomic.AtomicReference which essentially is a spinlock. Knowing how it works under the hood makes so easier to use it ... Below piece (hopefully

Re: Clojure Style Guide

On Saturday, December 20, 2014 12:53:41 PM UTC-5, Jonathan Irving wrote: > > It's not a docstring then, just the first expression in the body. > Leading to the interesting question: is the compiler smart enough to optimize it away? A string literal has no side effects so if its return value is u

Re: Clojure Style Guide

Hi, I realized recently that cohesive pretty formatting LISP programs is a very difficult problem to solve in the first place due to its homoiconicity. There could be some nice approximations but the devil is in the details. That all made me so grateful for what we have and I stopped complaining :

Re: Clojure Style Guide

That's true. I'm just saying I've accidentally done that before in single arity functions with no penalty. But if you count on cider or similar picking up docstrings from your own functions you'll want to do it the official way. --Ashton Sent from my iPhone > On Dec 20, 2014, at 10:53 AM, J I

Re: Clojure Style Guide

It's not a docstring then, just the first expression in the body. On Sat, Dec 20, 2014 at 12:05 PM, Ashton Kemerling < ashtonkemerl...@gmail.com> wrote: > > You can put the docstring after the args, but the tooling won't pick it > up. > > --Ashton > > Sent from my iPhone > > On Dec 20, 2014, at 10

Re: Clojure Style Guide

On Saturday, December 20, 2014 12:01:31 PM UTC-5, Eli Naeher wrote: > > Does anyone here know why in Clojure it was decided to move the docstring > from its traditional-in-Lisp location after the argument list? > In a nutshell, arity-overloading. -- You received this message because you are sub

Re: Clojure Style Guide

You can put the docstring after the args, but the tooling won't pick it up. --Ashton Sent from my iPhone > On Dec 20, 2014, at 10:01 AM, Eli Naeher wrote: > >> On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge >> wrote: >> >> And on a client project recently, it was decided (when I wasn'

Re: Clojure Style Guide

On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge wrote: > And on a client project recently, it was decided (when I wasn't around) > that the arguments to a function should always be on a newline: > > (defn foo > [x] > (+ x x)) > > Instead of: > > (defn foo [x] > (+ x x)) > Like you I pr

ANN Cassaforte 2.0 is released

Cassaforte [1] is a modern Clojure client for Apache Cassandra and DataStax Enterprise. 2.0 is a major release with breaking API changes. Release notes: http://blog.clojurewerkz.org/blog/2014/12/20/cassaforte-2-dot-0-0-is-released/ 1. http://clojurecassandra.info  -- @michaelklishin, github.co

Re: Clojure Style Guide

Defaults only please. There are more pressing needs from dev tools than this sort of thing. Diversity is what makes us well... different. Our minds are not formatted the same either. What may look readable to someone may look like garbage to someone else, the context may also influence comprehe

Re: Clojure Style Guide

On Saturday, December 20, 2014 9:30:47 AM UTC-5, tbc++ wrote: > > I recently browsed parts of that guide and was surprised how many bits I > disagreed with. Especially around the "one space in these rare cases" bits. > Not that that is a bad thing it's just my personal opinion that everything >

Re: Clojure Style Guide

Sure, Tim, I also remember having disagreed with a fair amount of rules, and the very prescriptive style. The idea of just agreeing on same defaults for editors seems sufficient. Given sufficient lazy users like me, this one single rule of default values should be sufficient to help spread a comm

Re: Clojure Style Guide

I recently browsed parts of that guide and was surprised how many bits I disagreed with. Especially around the "one space in these rare cases" bits. Not that that is a bad thing it's just my personal opinion that everything should always use two space indentation. And on a client project recently,

Re: Clojure Style Guide

A way to hint indentation to the tooling would be nice. Perhaps a metadata on vars such as {:body-indent #{then-clause else-clause}} that could tell tools to indent an "if" this way: (if condition then-clause else-clause) instead of this way: (if condition then-clause else-clause)

ANN Buffy 1.0

Buffy [1] is a Clojure library for working with binary data. Release notes: http://blog.clojurewerkz.org/blog/2014/12/19/buffy-reaches-1-dot-0/ -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to

Re: Clojure Style Guide

Let's start the list ! :-) 2014-12-20 10:57 GMT+01:00 Colin Fleming : > Yes, perhaps just agreeing on sane defaults is a more achievable goal. > Cursive currently does not indent everything exactly according to the guide > by default. I would also not like to see tools' ability to implement more

Re: Clojure Style Guide

Yes, perhaps just agreeing on sane defaults is a more achievable goal. Cursive currently does not indent everything exactly according to the guide by default. I would also not like to see tools' ability to implement more sophisticated formatting hampered by an overly restrictive guide either, since

Re: Clojure Style Guide

s/sale/same Le samedi 20 décembre 2014, Laurent PETIT a écrit : > I agree that if all tools could agree on sale out of the box defaults, > this would be very valuable to users and clojure in general. > > Maybe a less ambitious goal than getting the whole community agree on > standards could be t

Re: Clojure Style Guide

I agree that if all tools could agree on sale out of the box defaults, this would be very valuable to users and clojure in general. Maybe a less ambitious goal than getting the whole community agree on standards could be tool authors to agree on shared defaults. Which of course doesn't prevent the

Re: Clojure Style Guide

My view on this is very much along the line of discussions about whitespace. While I have opinions about these matters, for the most part I don't want to think about it--I have more pressing concerns. What's important to me is consistency within a code base. Just like with whitespace, I don'

Clojure Style Guide

Hi everyone, There's been a bit of discussion recently on a couple of clojure-mode tickets that I thought were worth discussing here. The tickets are #265 and #266 , and they later