Re: clojure.algo.monads - no tests for monadic laws

[Leonardo Borges]

No real reason - probably lack of time. For what it's worth, I've written
such tests for my imminent library here:
https://github.com/theleoborges/imminent/blob/master/test/imminent/laws_test.clj
- could be useful.


Leonardo Borges
@theleoborges <https://twitter.com/theleoborges>
www.leonardoborges.com


On Wed, Mar 31, 2021 at 11:56 AM Rostislav Svoboda <
rostislav.svob...@gmail.com> wrote:

> Hi, the test_monads.clj contains test cases for some arbitrary values but
> no test cases against monadic laws. I wonder why is it so? It's not really
> necessary to have them (everything works), but it won't hurt to have them
> around, I'd say. At least for learning purposes.
> What do you think?
>
> Thanks
>
> Direct link:
> https://github.com/clojure/algo.monads/blob/master/src/test/clojure/clojure/algo/test_monads.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAEtmmeyLhh-CaBu4npbApDpDffMzgNsEbr1j4dtF%2B5u%2BskRqHw%40mail.gmail.com
> <https://groups.google.com/d/msgid/clojure/CAEtmmeyLhh-CaBu4npbApDpDffMzgNsEbr1j4dtF%2B5u%2BskRqHw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAOMx-_j3HJCvyDHOQLwKZaFwXrPG1B6-SVAFEvaPQ_qX_qez6Q%40mail.gmail.com.

Re: how to be notified when a Future is realized?

[Leonardo Borges]

I created imminent for this purpose :
https://github.com/leonardoborges/imminent

It's based on Java's completable futures. I've written an extensive README
in the repo. Have a look, it might be useful for your case.

Cheers,
Leonardo Borges


On 3 Aug. 2017 7:19 am, "Justin Smith"  wrote:

for this sort of logic, I use core.async go blocks containing a call to
core.async/thread, doing some other operation asynchronously with the value
in the channel it returns

(go
  (let [result (https://gist.github.com/noisesmith/02ee2ee5dcb8c0290bd8004c4c4d36aa

On Wed, Aug 2, 2017 at 2:09 PM  wrote:

> I stumbled across this old post by Tomasz Nurkiewicz:
>
> http://www.nurkiewicz.com/2013/03/promises-and-futures-in-clojure.html
>
> He writes:
>
> "And here is where the greatest disappointment arrives: neither future
> <http://clojuredocs.org/clojure_core/clojure.core/future> nor promise
> <http://clojuredocs.org/clojure_core/clojure.core/promise> in Clojure
> supports listening for completion/failure asynchronously. The API is pretty
> much equivalent to very limited java.util.concurrent.Future
> <http://nurkiewicz.blogspot.com/2013/02/javautilconcurrentfuture-basics.html>.
> We can create future, cancel it
> <http://clojuredocs.org/clojure_core/clojure.core/future-cancel>, check
> whether it is realized? (resolved)
> <http://clojuredocs.org/clojure_core/clojure.core/realized_q> and block
> waiting for a value. Just like Future in Java, as a matter of fact the
> result of future function even implements java.util.concurrent.Future.
> As much as I love Clojure concurrency primitives like STM and agents,
> futures feel a bit underdeveloped. Lack of event-driven, asynchronous
> callbacks that are invoked whenever futures completes (notice that
> add-watch <http://clojuredocs.org/clojure_core/clojure.core/add-watch> doesn't
> work futures - and is still in alpha) greatly reduces the usefulness of a
> future object. "
>
> That was written in 2013. I think since then the community has found other
> ways to achieve the same goals? I'm curious what patterns have become
> common? Would it be correct to say that for most of the use cases where one
> would otherwise want a notification of completion on a Future, people
> nowadays instead use something like core.async or a library such as
> Manifold?
>
>
>
>
>
>
>
>
> --
> 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: Attempt At Futures

[Leonardo Borges]

Something like imminent might be useful here. In particular the section
about combinators: https://github.com/leonardoborges/imminent#combinators


On Sat, Apr 9, 2016 at 9:33 PM Gary Verhaegen 
wrote:

> You could:
>
> * Create all futures *without* deref'ing them, so they all start in
> parallel;
> * Loop through the futures, asking them if they have finished, and print
> those that have (and remove them from the list)
>
> But if you want to get each result as it comes back, it's probably a
> better fit for core.async than plain futures. I would suggest creating a
> channel with multiple producers and a single consumer, where each producer
> gets a site and the consumer prints the result. That way, you get the
> results as they come.
>
> Here is a rough draft:
>
> (ns cjr-http-test.core
>   (:require [clj-http.client :as client]
>
>
> [clojure.core.async :as async :refer [!!]]))
> (defn get-heads
>   [sites]
>   (mapv (fn [site] (future {:head (client/head site)
> :url site}))
> sites))
> (def sites ["http://www.google.com";
> "http://www.yahoo.com";
> "http://www.bing.com";])
> (defn use-futures
>   []
>   (let [head-requests (get-heads sites)]
> (loop [to-check head-requests checked []]
>   (cond (and (empty? checked) (empty? to-check))
> :finished
>
> (empty? to-check)
> (recur checked [])
>
> (realized? (first to-check))
> (do (-> to-check first deref :url println)
> (recur (rest to-check) checked))
>
> :else (recur (rest to-check) (cons (first to-check) checked))
> (defn use-async
>   []
>   (let [ch (async/chan)
> producers (mapv (fn [site]
>   (doto (Thread. #(>!! ch {:head (client/head site)
>:url site}))
> (.start)))
> sites)
> close-chan (doto (Thread. (fn []
> (mapv #(.join %) producers)
> (async/close! ch)))
>  (.start))]
> (loop [v (   (if (nil? v) :finished
> (do (-> v :url println)
> (recur (
> --
> 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] bouncer 1.0.0

[Leonardo Borges]

bouncer is a validation library for Clojure apps


Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer


The main change with 1.0.0 is that all validators are now optional by
default. This fixes pre-existing API inconsistencies. bouncer now works
with Clojurescript! - thanks Robin(@Skinney)!

Additionally, since this is a breaking change, I bumped the version to
1.0.0 and will be using Semantic Versioning (http://semver.org/) from now
on.

Full CHANGELOG:
https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md


Enjoy! :)


Leonardo Borges
www.leonardoborges.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: Processing futures and promises asynchronously

[Leonardo Borges]

Hi Daniel,

Since you're used to Scala futures, you might find this library easy to get
started with:

https://github.com/leonardoborges/imminent (A composable Futures library
for Clojure)

The next release will also include ClojureScript support.

Cheers,
Leonardo Borges
www.leonardoborges.com

On Tue, Oct 27, 2015 at 9:46 AM Daniel Hinojosa 
wrote:

> I am looking for a functional, non-blocking way to process the return of a
> future. In the Scala world, you can use map, flatMap, and foreach to
> process the return values of a future asynchronously.  In Clojure,
> dereferencing blocks, so that makes it kind of rough since we have to set
> up our constructs.  If anyone can steer me on the "Functional Clojure way"
> to process futures and promises that would be greatly appreciated. ;)
>
> --
> 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: [ANN][Book] Clojure Recipes published and for sale on Amazon

[Leonardo Borges]

Congratulations Julian! I'll share this around!

On Thu, Oct 22, 2015 at 9:51 PM Julian  wrote:

> My book Clojure Recipes just got published and is for sale on Amazon!
> http://clojurerecipes.net/
>
> http://www.amazon.com/Clojure-Recipes-Developers-Library-Julian/dp/0321927737/
>
> I've been working on it for about 2.5 years - I hope you find it useful!
> (Or even better - I hope you know a friend that might find it useful.)
>
> A little context in the form of Q&A below.
>
> Cheers
> Julian
>
> *Q&A*
> *Haven't we got enough Clojure books already?*
> I asked this of Stuart Sierra when he was in down under 2 years ago. He
> responded "we have enough 'introduction to Clojure books' but there is room
> for other types of books".
>
> *Who is it for?*
> This is a book for people who 'learn by doing'. It's for that guy in the
> office who is interested in Clojure, and wants to use it to hack on a
> project this weekend. (The assumption is you're familiar with Lisp-style
> parens, but not much more.)
>
> The book contains 'starter projects' for various use-cases of a
> small-to-medium size - it will hold your hand enough to get you started,
> and then free you up to take your project as you choose. Each one is
> self-contained, and assumes little Clojure knowledge, and explains the code
> as you go.
>
> *What? Clojure Recipes? Isn't there already a Clojure book in this format?*
> I signed the contract in December 2012 with Pearson. At that time there
> wasn't a Clojure book in this genre.
>
> Then Ryan Neufeld announced he was writing a Clojure book in 2013. I got
> in touch with Ryan and Justin Gehtland about the situation. They were both
> amazingly generous and supportive, and clarified they could see differences
> in the books intended purpose and content. I caught up with Ryan last year
> at the Clojure Conj and he was warm and encouraging.
>
> I came away feeling really positive about the Clojure community. Everyone
> wants to 'grow the pie' of involved people.
>
> --
> 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: Paper on Immutable Persistent Data Structures

[Leonardo Borges]

The best resource I know of is Chris Okasaki's book (and thesis) on purely
functional data structures: http://amzn.to/UcIidh

The book isn't Clojure specific so unfortunately familiarity with either ML
or Haskell is mandatory.

I've written a couple of posts translating some implementations to Clojure
but haven't had the time to write more. In case that's sitill useful, I've
done Leftist Heaps and Red-Black Trees:
http://www.leonardoborges.com/writings/tags/functional-data-structures/

Lastly, Mohit Thatte's talk from this year's EuroClojure is also a great
resource on the subject for Clojure developers:
https://www.youtube.com/watch?v=7BFF50BHPPo

Cheers,
Leonardo Borges

On Tue, Jul 21, 2015 at 10:46 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

>  Jean Niklas L'orange has some posts about it at
> http://hypirion.com/musings/understanding-persistent-vector-pt-1 (there's
> more throughout his blog if you search).
>
> On Tue, Jul 21, 2015 at 11:44 AM JvJ  wrote:
>
>> Does anyone know if there exists a paper/web page describing in detail
>> how each of Clojure's data structures are implemented?
>>
>> --
>> 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.
>>
> --
> --
> Daniel
>
> --
> 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: Opinion on core.async vs callbacks in abstract APIs?

[Leonardo Borges]

For people interested in using the 'futures' approach, this might be of
interest: https://github.com/leonardoborges/imminent


It's a library that implements composable futures for Clojure on top of
JVM's ForkJoin framework. It allows you to attach callbacks as well as
apply combinators such as map etc...


On 2 Jun 2015 3:04 pm, "Timothy Baldridge"  wrote:

> The problem with futures is that you can't attach callbacks to them, you
> can only block a thread waiting on them. So futures interface quite poorly
> with async libraries, hence the reason core.async was created in the first
> place.
>
> Core.async is a dependency, but it's hardly one that changes fast. The
> last breaking change was about a year and a half ago (Jan 2014). Besides
> that, all changes are additional "opt-in" features. That's a lot less
> change than most libraries in the Clojure ecosystem.
>
> Timothy
>
> On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin 
> wrote:
>
>> As for the core.async, I think it is too personal and has too much raw
>> power, to be all that restricted in some logical bottleneck upon results
>> return from the third-party lib.
>> Not counting the fact it is a (a) dependency that (b) changes fast.
>>
>> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote:
>>
>>> Greetings
>>>
>>> I imagine most of us here would rather use core.async channels over
>>> callbacks in their application code, particularly with more complicated
>>> applications. But is it okay/preferable for Clojure libraries to force
>>> their users to use core.async channels as part of an API (an event channel,
>>> for example)?
>>>
>>> As much as I love core.async, I can't help but wonder whether sticking
>>> with callbacks for an API isn't a simpler/better design strategy. It's easy
>>> enough to drop messages on a channel in a callback, and this let's users
>>> opt-in. But if one expects core.async channels are what most would prefer
>>> anyway, is it okay to foist them upon everyone?
>>>
>>> As a follow up, does your opinion on the matter change if
>>> implementations of an API become simpler using core.async channels?
>>>
>>>
>>> Looking forward to your thoughts :-)
>>>
>>> Chris Small
>>>
>>>
>>>
>>> PS I'm asking because I'm working on a physical computing API (
>>> https://github.com/clj-bots/pin-ctrl) and debating between using
>>> channels vs callbacks for the edge detection functionality (if you're not
>>> familiar, edge detection let's you asynchronously handle changes in pin
>>> state, such as button pushes). If you're interested in this question as it
>>> applies specifically to this application, feel free to join the discussion
>>> on our gitter channel: https://gitter.im/clj-bots/chat
>>>
>>  --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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...@googlegroup

Re: Relational mapping - turning an sql query result into array of hashes (with joins)

[Leonardo Borges]

It's interesting how this question pops up every now and again. I find
that, for the types of projects I work with, I'm perfectly happy writing
little combinators to work with result sets myself.

At one project though, a standard RESTful web application with a
traditional relational model, I ended up writing code to parse SQL result
sets into Clojure maps. Just enough code to make simple cases like this
work:

;; Usage

(def authors-parser
  (partial parse-result-set {:relation-prefix :authors
 :relation-pk :id
 :associations [[:posts :one-to-many]
[:address :one-to-one]]}))

(authors-parser sample-result)

;; ({:address {:street "Atchison St"},
;;   :posts
;;   ({:title "Title 2", :id 1, :name "Leo"}
;;{:title "Title New", :id 1, :name "Leo"}),
;;   :id 1,
;;   :name "Leo"}
;;  {:address {:street "Pitt St"},
;;   :posts ({:title "The Book", :id 2, :name "Enif"}),
;;   :id 2,
;;   :name "Enif"})


This worked reasonably well for what I needed.

But then I also got sucked in into implementing the reverse. That is,
generating the sql from a Clojure map. I got it working to the point where
a simple case like this successfully persisted changes - though I never
used this part of it in the project I mentioned above:

(def leo (first (select authors :include [posts])));; {:posts;;
({:title "Title 1", :id 20, :content "whaaa wh"};;   {:title
"Title 2", :id 21, :content "whooo wh"}),;;  :name "Leonardo
Borges",;;  :id 1}
(-> leo
(t/assoc :name "Leo")
(t/assoc :posts [{:title "Title New", :content "I'm totally new!"}
 {:title "Title 2", :id 21, :content "whooo wh"}])
t/save!)

(first (select authors :include [posts]))
;; {:posts;;  ({:title "Title 2", :id 21, :content "whooo wh"};;
{:title "Title New", :id 22, :content "I'm totally new!"}),;;  :name
"Leo",;;  :id 1}


The amount of work required to turn this into a decent open source library
though isn't small - if nothing else I might finish it one day as an
exercise.

Unless other people are genuinely interested in seeing this out in the
wild. A lot of the time this is overkill though.

Cheers,

On Tue, May 26, 2015 at 9:45 AM Sean Corfield  wrote:

> On May 25, 2015, at 3:19 PM, Sam Roberton  wrote:
>
> On Tuesday, 26 May 2015 06:43:18 UTC+10, Krzysiek Herod wrote:
>>
>> Sean, maybe my use case is specific to web applications. In REST API's
>> it's common to respond with something like "Example Result" here:
>> https://dev.twitter.com/rest/reference/get/statuses/mentions_timeline I
>> completely agree with you about ORMs, but in case of REST API's one just
>> needs to somehow map the queryset to a structure of hashes and arrays (not
>> necessarily objects), and this task is much heavier than I thought in the
>> beginning, from choosing between making many queries to fill in the hash of
>> related objects vs making JOINs, to complexity of extracting data from a
>> set of rows with potential repetitions, rows of null values (like Daniel
>> said happens for instance in case of LEFT JOINS), and different kinds of
>> relations (has-one, has-many, belongs-to).
>>
>
> I found myself needing this for a REST API as well, so I implemented an
> 'unjoin' function which sounds like what you're looking for.
>
> Here's a gist, including test case (not necessarily a hugely comprehensive
> test case, but better than nothing):
> https://gist.github.com/samroberton/d72cedaf225526d9007a
>
>
> Yup, and that’s exactly what I meant by:
>
> "Any structural grouping semantics you want to apply are up to your
> application"
>
> In order to correctly "unjoin" your result set for your application, you
> need to apply structural grouping based on knowledge of the application
> domain (parent / child keys in desired result set) — which doesn't
> necessarily map 1:1 onto the SQL used to create the result set.
>
> 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 ema

Re: [ANN][book] Clojure Reactive Programming

[Leonardo Borges]

Thanks Pieter,

I hope you enjoy it!

Cheers,
Leo

On Thursday, April 30, 2015 at 9:35:01 PM UTC+10, Pieter Vallen wrote:
>
> Thanks for writing the book. Just bought it (before the "marketing 
> discussion";-)) and really like what I've read so far!
>
> Cheers,
> Pieter
>
> Op dinsdag 24 maart 2015 15:26:02 UTC+1 schreef Leonardo Borges:
>>
>> Hi all,
>>
>> Some of you may know that I have been working on a book for the better 
>> part of last year.
>>
>> I'm happy to announce it has finally been published! Here's the link: 
>> https://www.packtpub.com/web-development/clojure-reactive-programming
>>
>> I hope you find it useful! I've had a great time putting it together!
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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][book] Clojure Reactive Programming

[Leonardo Borges]

On Saturday, April 11, 2015 at 7:21:21 AM UTC+10, Shaun Mahood wrote:
>
> Finished my first read-through last night, I really enjoyed the book and 
> thought it was an excellent and informative read. Best resource I've read 
> yet for understanding reactive programming as a whole. Thanks for writing 
> it!


That is great to hear! I'm extremely glad you enjoyed the book! :)

Cheers,

 

-- 
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][book] Clojure Reactive Programming

[Leonardo Borges]

I promise this was no marketing stunt!

Not a planned one anyway :p
On 27/03/2015 11:35 pm, "Jeremy Heiler"  wrote:

> Congrats, Leonardo!
>
> On Tue, Mar 24, 2015 at 10:25 AM, Leonardo Borges <
> leonardoborges...@gmail.com> wrote:
>
>> Hi all,
>>
>> Some of you may know that I have been working on a book for the better
>> part of last year.
>>
>> I'm happy to announce it has finally been published! Here's the link:
>> https://www.packtpub.com/web-development/clojure-reactive-programming
>>
>> I hope you find it useful! I've had a great time putting it together!
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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: [ANN][book] Clojure Reactive Programming

[Leonardo Borges]

Thanks everyone for the kind words! 

It makes it all worth it :)

Cheers,
Leonardo

On Thursday, March 26, 2015 at 11:44:27 AM UTC-3, Shaun Mahood wrote:
>
> Just thought I would leave a quick note for anyone interested in the book 
> (and hopefully get the thread back on topic). I'm about 1/3 through the 
> book and have found it really well written and interesting so far. It's an 
> excellent introduction to reactive programming in general and for clojure 
> specifically, and is easy to follow for a relative beginner in both clojure 
> and reactive programming. If you have any interest at all in the topic I 
> highly recommend picking it up. 
>
> Thanks for writing it Leonardo!
>
> On Tuesday, March 24, 2015 at 8:26:02 AM UTC-6, Leonardo Borges wrote:
>>
>> Hi all,
>>
>> Some of you may know that I have been working on a book for the better 
>> part of last year.
>>
>> I'm happy to announce it has finally been published! Here's the link: 
>> https://www.packtpub.com/web-development/clojure-reactive-programming
>>
>> I hope you find it useful! I've had a great time putting it together!
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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][book] Clojure Reactive Programming

[Leonardo Borges]

Hi all,

Some of you may know that I have been working on a book for the better part
of last year.

I'm happy to announce it has finally been published! Here's the link:
https://www.packtpub.com/web-development/clojure-reactive-programming

I hope you find it useful! I've had a great time putting it together!

Cheers,
Leonardo Borges
www.leonardoborges.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: Rationale behind the naming and semantics for agents.

[Leonardo Borges]

>
>
> (as opposed to the combined state+behavior version of agents that one sees
> elsewhere)
>
>
Did you mean to say actors? Actor is the abstraction that bundles state and
behaviour together.

Agents are different and in fact, Akka, a popular JVM actor library,
provides agents in addition to actors themselves:
http://doc.akka.io/docs/akka/snapshot/scala/agents.html

Cheers,
Leonardo Borges

-- 
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] bouncer 0.3.2

[Leonardo Borges]

bouncer is a validation library for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

The main change with 0.3.2 is that bouncer now works with Clojurescript! -
thanks Robin(@Skinney)!

New validators have also been added. You can read more about the changes in
the CHANGELOG:
https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md

Enjoy! :)

Leonardo Borges
www.leonardoborges.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: OT: Github Alternatives

[Leonardo Borges]

I can't speak for price but I've worked in a couple of clients who used
Stash [1], which is Atlassian's internal version of Bitbucket. I had no
issues while using that.

[1]: https://www.atlassian.com/software/stash
[2]: https://bitbucket.org/

Leonardo Borges
www.leonardoborges.com


On Mon, Jun 30, 2014 at 12:34 PM, Adrian Mowat 
wrote:

> Hi All,
>
> Sorry for the off topic thread but my company is looking at alternatives
> to gihub that are a) hosted internally and b) cheaper (!)
>
> I was wondering what everyone else is using out there?  The features we
> use most on github are easy creation and navigation of repos, commit/diff
> browsing and user/team management facilities
>
> Many Thanks
>
> Adrian
>
> --
> 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: lazy list comprehension

[Leonardo Borges]

Try using map :

(map str '(my-list-of-crap) (iterate inc 0))

-- 
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: use :only in ns

[Leonardo Borges]

>
> This will make available the whole seesaw.chooser namespace available via
> prefixed notation, with the bonus that choose-file which will be accessible
> without a namespace prefix. If just a couple vars are needed, then the :use
> :only is a preferable solution.
>

Ah good point. I tend to forget about ':only' as I use :require/:refer most
of the time. Though as Linus points out, you can also use :only with
:require so that's quite convenient.

-- 
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: use :only in ns

[Leonardo Borges]

I believe you want:

(ns providence.core
  (:gen-class)
  (:require [seesaw.chooser :refer [choose-file]]))


Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Jun 5, 2014 at 4:08 PM, Glen Rubin  wrote:

> In my ns i am using a couple of libraries, e.g.
>
> (ns providence.core
>   (:gen-class)
>   (:use seesaw.chooser))
>
>
> However, I only want to use 1 or 2 commands from these libraries, for
> example (choose-file) from the above seesaw.chooser.  How do I specify only
> a single library?  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.
>

-- 
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: The future of CongoMongo?

[Leonardo Borges]

>
> I'd like to see CongoMongo's API completely overhauled, to remove 
> dependencies on dynamic global variables etc, so this would be introduce a 
> new API, and deprecate the old API.
>

I've used both libraries but since I haven't worked with Mongo
extensively from Clojure I still don't have a strong preference.

For what's worth however, I would like to see the dependency in
dynamic vars removed. It's a good design goal to have.

-- 
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/groups/opt_out.

Re: liberator video, compression question

[Leonardo Borges]

beat me to it.

But yes, that's also what I got from the talk.

Leonardo Borges
www.leonardoborges.com


On Sun, Jan 19, 2014 at 12:40 PM, Brian Craft  wrote:

> http://www.youtube.com/watch?v=OEZZOz6__CY
>
> At about 30 min he mentions that gzip, etc. aren't so interesting here
> because we can use, um.. something transfer, proxies... don't know what
> he's saying. Anyone know what he's talking about?
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

[ANN] bouncer 0.3.1-beta1 released

[Leonardo Borges]

bouncer is a validation DSL for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

TL;DR; of version 0.3.1-beta1:

You can now customise error messages however you like:

(def person {:name "Leo" :age "NaN"})

(defn custom-message-fn [{:keys [path value metadata]}]
  (format "'%s' in field %s should be a %s" value path (:validator
metadata)))

(b/validate custom-message-fn
person
:name v/required
:age  v/number)

;; [{:age ("'NaN' in field [:age] should be a :bouncer.validators/number")}
;;  {:age "NaN",
;;   :name "Leo",
;;   :bouncer.core/errors
;;   {:age
;;("NaN in field [:age] should be a :bouncer.validators/number")}}]

To learn more about this new feature please have a look at the section
"Internationalization and advanced error messages"* in the
README<https://github.com/leonardoborges/bouncer/blob/master/README.md#internationalization-and-advanced-error-messages>
.

Hats off to Vadim Platonov (https://github.com/dm3) for this pull request.

This feature is backwards compatible so existing code will be unaffected.

A 
CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>is
also available.

Feedback welcome.

Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: [ANN] bouncer 0.3.0

[Leonardo Borges]

Just a quick note to let people know I've released bouncer 0.3.0 final.

The only extra change was this pull request:

- Merge [PR #18](https://github.com/leonardoborges/bouncer/pull/18):
"Minor readme change to not make it seem a strange design decision was
taken, and very minor (somewhat random) syntax change"

Happy new year!

Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Aug 15, 2013 at 11:01 PM, Leonardo Borges
 wrote:
> Hi all,
>
> bouncer is a validation library for Clojure apps
>
> Github: https://github.com/leonardoborges/bouncer
> Clojars: https://clojars.org/bouncer
>
> Version 0.3.0-alpha1 has undergone major, breaking changes:
>
> - My original design made heavy use of macros for a nicer, more natural DSL
> at the expense of composition;
> - This turned out not to be the best option as I received a few bug reports
> related to issues composing validations;
> - As a result I removed almost all macros in favour of functions
>
> In a nutshell what this means is that where once you wrote this:
>
> (b/validate {:postcode -1}
>   :postcode [(v/required :message "required") (v/number :message
> "number")])
>
> You will now write this:
>
> (b/validate {:postcode -1}
>   :postcode [[v/required :message "required"] [v/number :message
> "number"]])
>
> The difference is minimal, but the gains are great as I was able to
> completely eliminate the defvalidatorset macro in favour of clojure maps:
>
> (def address-validations {:postcode [v/required v/number]})
>
> (b/validate {} address-validations)
>
> Please check out the README for updated docs as well as the CHANGELOG for
> details.
>
> Feedback on this version and the new API is greatly appreciated.
>
> Cheers,
> Leonardo Borges
> www.leonardoborges.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/groups/opt_out.

Re: Comparing core.async and Reactive Extensions

[Leonardo Borges]

Thought not specifically about Rx, this thread talks about core.async
and FRP (of which Rx is an implementation):
https://groups.google.com/forum/#!topic/clojure/jHhwufCjrR8

-- 
-- 
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/groups/opt_out.

Re: Comments on first function

[Leonardo Borges]

Hi,

Good inital effort. Only a couple of things to comment on:

- You're not closing the stream after you're done with it

This is a very common bug and for that reason clojure provides a macro
- with-open - that takes care of closing the resource for you.

- As you're using a string as the accumulator, you're creating a new
string object at each iteration:

A better approach might be using a StringBuffer to accumulate the
result without wasteful object allocation.

In fact, both of these points are addressed by a core clojure function
called 'slurp'. Here's its source and sample usage:

(defn slurp
  ([f & opts]
 (let [opts (normalize-slurp-opts opts)
   sb (StringBuilder.)]
   (with-open [#^java.io.Reader r (apply jio/reader f opts)]
 (loop [c (.read r)]
   (if (neg? c)
 (str sb)
 (do
   (.append sb (char c))
   (recur (.read r)


(println (slurp "http://google.com";))


You can read more about with-open in this link:
http://clojuredocs.org/clojure_core/clojure.core/with-open

Cheers,
Leonardo Borges
www.leonardoborges.com


On Mon, Nov 18, 2013 at 2:00 PM,   wrote:
> Hi everyone,
>
> I'm new to Clojure, and after a lot of reading I wrote a couple of
> functions.
> They are working and doing what they are supposed to, but I was wondering if
> the way I wrote the functions was optimal and if I made any conceptual
> errors which advanced programmers avoid.
> Basically: Are they what they call the "clojure" way?
>
> (defn download-source [url]
>   (let [stream (java.io.BufferedReader. (java.io.InputStreamReader. (..
> (java.net.URL. url) openStream)))]
> (loop [b (.readLine stream), acc ""]
>   (if (= b nil) acc
> (recur (.readLine stream) (str acc b))
>
> (println (download-source "http://google.com";))
>
> This function for example downloads the source of a webpage and returns it
> as a string.
> Could this have been written in a better way?
> I want to get a feeling of what is considered good practice/design in
> clojure.
>
> Nice Regards
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Leonardo Borges]

Thanks for that reference.

I'll give it a try.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Nov 13, 2013 at 8:46 PM, Ryan Spangler  wrote:
> Hi Leonardo,
>
> It seems that on certain default java installs keys are restricted to 16
> bytes:
> http://stackoverflow.com/questions/6900542/java-security-invalidkeyexception-illegal-key-size
>
> I just released a version that creates 16 byte keys for the cookie store.
> Try that!  (or edit the key in your src/{project-name}/core.clj and drop
> half the chars).
>
>
> On Wednesday, November 13, 2013 1:20:18 AM UTC-8, Leonardo Borges wrote:
>>
>> Hi Ryan,
>>
>> Love the website and the idea. Gave it a try but it gives me this when
>> trying to browse to the app:
>>
>> java.security.InvalidKeyException: Illegal key size
>>
>> It's coming from ring's cookie store. It seems the generated key isn't
>> valid.
>>
>> I had a similar problem recently where I had to base64 decode the
>> string before passing it to the cookie-store. Not sure this is the
>> case here.
>>
>> FWIW, I'm running Java 1.7 and Lein 2.3.3
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.com
>>
>>
>> On Wed, Nov 13, 2013 at 5:25 PM, Ryan Spangler 
>> wrote:
>> > Justin,
>> >
>> > As far as I know, Immutant is not a dependency, but an option.  Let me
>> > know
>> > if that is not true however.
>> >
>> >
>> > On Tuesday, November 12, 2013 10:13:17 PM UTC-8, Justin Smith wrote:
>> >>
>> >> Typically my first step making a caribou app is to remove the immutant
>> >> dependency. It's pretty straightforward to take it out.
>> >>
>> >> On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:
>> >>>
>> >>> This is really cool. Very easy to get up and running for first try. I
>> >>> have a few questions on the architecture.
>> >>>
>> >>> Why Immutant instead of plain ring as the default? I think the number
>> >>> of
>> >>> dependencies could be much lower with it.
>> >>>
>> >>> I know it's only alpha.. but I'm asking this on behalf of others who
>> >>> might be thinking the same.
>> >>> And, are there plans for NoSQL database support, like MongoDB, MapDB
>> >>> (http://www.mapdb.org/ - I just found out about it myself but this is
>> >>> the
>> >>> only decent in-memory NoSQL solution other than Berkeley DB)?
>> >>>
>> >>> On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:
>> >>>>
>> >>>> Hello Clojure,
>> >>>>
>> >>>> Excited to announce today the release of Caribou!
>> >>>> http://let-caribou.in/
>> >>>>
>> >>>> We have been building web sites and web applications with it for over
>> >>>> two years now and improving it every day.  Currently we have four
>> >>>> people
>> >>>> working on it and another ten using it to build things, so it is
>> >>>> getting a
>> >>>> lot of real world testing.
>> >>>>
>> >>>> It has been designed as a collection of independent libraries that
>> >>>> could
>> >>>> each be useful on their own, but which come together as a meaningful
>> >>>> whole.
>> >>>>
>> >>>> We have been spending the last couple months getting it ready for a
>> >>>> full
>> >>>> open source release, and I am happy to say it is finally ready.
>> >>>> Funded and
>> >>>> supported by Instrument in Portland, OR:  http://weareinstrument.com/
>> >>>> We
>> >>>> have four projects using it in production, and several more about to
>> >>>> be
>> >>>> launched (as well as over a dozen internal things).
>> >>>>
>> >>>> Documentation is here:
>> >>>> http://caribou.github.io/caribou/docs/outline.html
>> >>>>
>> >>>> Source is here:  http://github.com/caribou/caribou (use this for
>> >>>> issues,
>> >>>> you don't actually need the source as it is installed through a lein
>> >>>> template).
>> >>>>
>> >>>> Some of the independent

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Leonardo Borges]

Hi Ryan,

Love the website and the idea. Gave it a try but it gives me this when
trying to browse to the app:

java.security.InvalidKeyException: Illegal key size

It's coming from ring's cookie store. It seems the generated key isn't valid.

I had a similar problem recently where I had to base64 decode the
string before passing it to the cookie-store. Not sure this is the
case here.

FWIW, I'm running Java 1.7 and Lein 2.3.3

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Nov 13, 2013 at 5:25 PM, Ryan Spangler  wrote:
> Justin,
>
> As far as I know, Immutant is not a dependency, but an option.  Let me know
> if that is not true however.
>
>
> On Tuesday, November 12, 2013 10:13:17 PM UTC-8, Justin Smith wrote:
>>
>> Typically my first step making a caribou app is to remove the immutant
>> dependency. It's pretty straightforward to take it out.
>>
>> On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:
>>>
>>> This is really cool. Very easy to get up and running for first try. I
>>> have a few questions on the architecture.
>>>
>>> Why Immutant instead of plain ring as the default? I think the number of
>>> dependencies could be much lower with it.
>>>
>>> I know it's only alpha.. but I'm asking this on behalf of others who
>>> might be thinking the same.
>>> And, are there plans for NoSQL database support, like MongoDB, MapDB
>>> (http://www.mapdb.org/ - I just found out about it myself but this is the
>>> only decent in-memory NoSQL solution other than Berkeley DB)?
>>>
>>> On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:
>>>>
>>>> Hello Clojure,
>>>>
>>>> Excited to announce today the release of Caribou!
>>>> http://let-caribou.in/
>>>>
>>>> We have been building web sites and web applications with it for over
>>>> two years now and improving it every day.  Currently we have four people
>>>> working on it and another ten using it to build things, so it is getting a
>>>> lot of real world testing.
>>>>
>>>> It has been designed as a collection of independent libraries that could
>>>> each be useful on their own, but which come together as a meaningful whole.
>>>>
>>>> We have been spending the last couple months getting it ready for a full
>>>> open source release, and I am happy to say it is finally ready.  Funded and
>>>> supported by Instrument in Portland, OR:  http://weareinstrument.com/  We
>>>> have four projects using it in production, and several more about to be
>>>> launched (as well as over a dozen internal things).
>>>>
>>>> Documentation is here:
>>>> http://caribou.github.io/caribou/docs/outline.html
>>>>
>>>> Source is here:  http://github.com/caribou/caribou (use this for issues,
>>>> you don't actually need the source as it is installed through a lein
>>>> template).
>>>>
>>>> Some of the independently useful libraries Caribou is built on are:
>>>>
>>>> * Polaris -- Routing with data (not macros) and reverse routing! :
>>>> https://github.com/caribou/polaris
>>>> * Lichen -- Image resizing to and from s3 or on disk:
>>>> https://github.com/caribou/lichen
>>>> * Schmetterling -- Debugging Clojure processes from the browser:
>>>> https://github.com/prismofeverything/schmetterling
>>>> * Antlers -- Useful extensions to mustache templating (helpers and
>>>> blocks, among other things):  https://github.com/caribou/antlers
>>>> * Groundhog -- Replay http requests:
>>>> https://github.com/noisesmith/groundhog
>>>>
>>>> And many others.
>>>>
>>>> Basically this is an Alpha release, and I am announcing it here first in
>>>> order to get as much feedback from the community as possible.  We have made
>>>> it as useful as we can for our purposes and recognize that for it to 
>>>> improve
>>>> from here, we really need as many people using it and building things with
>>>> it as possible.  The documentation also needs to be put through its paces:
>>>> we need to see how well people are able to use it who know nothing about 
>>>> it,
>>>> based only on the existing docs.
>>>>
>>>> All feedback welcome!
>>>>
>>>> Thanks for reading!  I hope you find it useful.
>
> --
> --
> You re

Re: How to go about 'proving' why dynamically typed languages are better

[Leonardo Borges]

There's a link to his presentation there actually:
http://www.infoq.com/presentations/data-types-issues?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013

However is says this:

*Thank you for attending Strange Loop 2013*
This is a restricted presentation that can only be viewed by Strange Loop
2013 attendees!

Maybe Alex can comment on whether it's possible for those who didn't attend
to watch this video at all.

I'd be very keen.

Leonardo Borges
www.leonardoborges.com


On Tue, Oct 8, 2013 at 2:11 AM, gaz jones  wrote:

> Martin Odersky gave a keynote at Strangeloop this year called "The Trouble
> With Types" (https://thestrangeloop.com/sessions/the-trouble-with-types)
> which made me never want to use a type system again (probably the exact
> opposite of his intention). The video should be coming out on infoq at some
> point: (http://www.infoq.com/conferences/strangeloop2013/). I've never
> looked at Scala before and I'm pretty sure I never will after sitting
> through that...
>
>
> On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro wrote:
>
>> Thanks for the link! I really liked the interview, it was interesting and
>> fun to watch.
>>
>> J
>>
>> On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote:
>>>
>>> > zcaudate  Oct 05 08:35PM -0700
>>> > I'm a little bit miffed over this current craze of `types` and
>>> > `correctness` of programs. It smells to me of the whole `object` craze
>>> of
>>> > the last two decades. I agree that types (like objects) have their
>>> uses,
>>> > especially in very well defined problems, but they have got me in
>>> trouble
>>> > over and over again when I am working in an area where the goal is
>>> unclear
>>> > and requirements are constantly changing.
>>>
>>> Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell
>>> http://www.infoq.com/**interviews/armstrong-peyton-**
>>> jones-erlang-haskell<http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell>
>>>
>>> This interview covers some of the strong-types vs flexible development
>>> (apparent) dichotomy, but in a playful, open and non-dogmatic way.
>>> (catmatic?)
>>>
>>> Simon Peyton Jones is one of the Haskell leaders, yet admits to
>>> being envious of type-free generics.  Joe Armstrong of Erlang fame
>>> also sees the benefit to thinking in and annotating types.
>>> These two are both leaders of typed or dynamic cults but have
>>> a pleasant friendly and frank conversation about the issues.
>>> (Erlang's Dialyzer sounds somewhat like core.typed)
>>>
>>> A sample:
>>>
>>> SPJ: So, I've told you what I most envy about Erlang. What do you most
>>> envy
>>> about Haskell?
>>>
>>> JA: All the types. I mean they're very nice. I wish we had them. On the
>>> other
>>> hand, wouldn't you love to have all these generic turn-to-binary, these
>>> sort
>>> of things? How can you live without them?
>>>
>>> SPJ: I have a little bit of residual envy about generics.
>>>
>>> JA: You just take anything and compare it to the serializer and then
>>> send it?
>>>
>>> SPJ: That's sinfully easy, and shouldn't be allowed.
>>>
>>>
>>> So if these two can agree that there's strengths and weaknesses in both
>>> approaches, that settles it for me.  It's a matter of knowing your
>>> trade-offs and choosing your tools appropriately.
>>>
>>> My suspicion is that type affinity is related to some trait of
>>> personality,
>>> and so trying to "prove" superiority is a likely to work as "proving"
>>> you
>>> are right in any other clash of personalities.
>>>
>>> Brad
>>>
>>>  --
>> --
>> 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

Re: [ANN] core.typed 0.2.5, News

[Leonardo Borges]

Thanks for all your work ambrose! Core.typed is quite a feat.

And I can confirm ambrose is amazingly responsive on freenode. Every time I
bug him, it works :)
On 10/09/2013 9:57 PM, "Ambrose Bonnaire-Sergeant" <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> Pushing another release of core.typed,
> mostly bug/documentation fixes.
>
> We now push a "slim" jar which does not include AOT file. See the README
> for dependency information.
>
> See the CHANGELOG for specific changes.
>
> I'm also starting to provide functions that will help integrate core.typed
> with IDE's. eg. 
> check-form-info
>  returns
> a map of data summarising the results of type checking, including type
> errors. This is towards Counterclockwise 
> support
> .
>
> I'm planning to fix a bunch of things that have proven problematic with
> the type syntax. I'll be adding to this design 
> wikiif you 
> want to follow along, or contribute. These may end up being breaking
> changes.
>
> Also, recursive deftype and protocols have proven to be tricky. 
> Hereare my 
> thoughts.
>
> Finally, I wrote a blog 
> postexplaining
>  how core.typed understands assertions.
>
> Enjoy!
> Ambrose
>
> PS. If you have questions, try #typed-clojure on Freenode!
>

-- 
-- 
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/groups/opt_out.

Re: Improving a nested if, or How to use multimethods the right way.

[Leonardo Borges]

You could use pattern matching with core.match
On 05/09/2013 6:57 AM, "Bruno Kim Medeiros Cesar" 
wrote:

> I'm writing (another) basic graph library, and would like to treat inputs
> depending on the type of the graph. A graph can be
>
>- Directed, in which case edges are vectors. Otherwise, edges are sets;
>- Looped, allowing edges from a node to itself;
>- Pseudo (or multi), allowing multiples edges between the same
>endpoints; and
>- Hyper, allowing edges with more than two vertices.
>
> To illustrate better these characteristics you can think of a scientific
> publication network as a directed, looped, pseudo-hypergraph. Vertices are
> authors, and edges are articles containing multiple researchers (hyper) who
> can publish alone (looped). There are multiple articles between the same
> researchers (pseudo) and in some contexts author order matters (directed).
>
> Now, I've created a flowchart  to decide if an
> edge should be conjed in a graph :edges entry, that leads to the following
> straightforward function:
> (defn add-edge
>   ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
>   ([graph edge]
>   (if (and (multi? graph) (not= 2 (count edge)))
> graph
> (if (and (looped? graph) (not (distinct? edge)))
>   graph
>   (let [e (if (directed? edge) (vec edge) (set edge))]
> (update-in graph [:edges] conj e))
>
> That looks ugly and a pattern that could propagate in a codebase. So I
> tried to factor out multimethods from it, and ended with the following:
>
> (defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
> (defmulti ^:private add-edge1 (fn [g e] (looped? g)))
> (defmulti ^:private add-edge2 (fn [g e] (directed? g)))
> (defn ^:private add-edge3 [g e]
>   (update-in g [:edges] conj e))
>
> (defmethod add-edge0 :hyper [g e] (add-edge1 g e))
> (defmethod add-edge0 :default [g e] (if (= 2 (count e))
>   (add-edge1 g e)
>   g))
> (defmethod add-edge1 :looped  [g e] (add-edge2 g e))
> (defmethod add-edge1 :default [g e] (if (distinct? e)
>   (add-edge2 g e)
>g))
> (defmethod add-edge2 :directed [g e] (add-edge3 g (vec e)))
> (defmethod add-edge2 :default  [g e] (add-edge3 g (set e)))
>
> (defn add-edge
>   ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
>   ([g edge]   (add-edge0 g edge)))
>
> That doesn't look much better, as the amount of boilerplate increased, but
> at least the concerns for each type are separated.
>
> Do you have any suggestions on how to improve this design? Thanks for any
> consideration!
>
> Bruno Kim Medeiros Cesar
> Engenheiro de Computação
> Pesquisador em Redes Complexas
> www.brunokim.com.br
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Sorting a collection on multiple fields

[Leonardo Borges]

Would this help?

(sort-by (juxt :key1 :key2) your-list-of-maps)

On 31/08/2013 7:57 PM, "ulsa"  wrote:

> I wanted to sort a sequence of maps using a spec consisting of an ordered
> map of key and order, like this:
>
> (array-map :name 1 :age -1)
>
> I couldn't find a ready-made solution, so I rolled my own. I ended up with
> three functions with a total of 10 lines of code. Two of them are generic,
> and one is specific to my problem.
>
> First a comparator-generator, that is fed a collection of comparators:
>
> (defn compare-many [comps]
>   (fn [xs ys]
> (if-let [result (first (drop-while zero? (map (fn [f x y] (. f
> (compare x y))) comps xs ys)))]
>   result
>   0)))
>
> It uses the same trick as sort-by does, namely the fact that all
> functions implement Comparator. This means that I can pass in a predicate
> instead of a comparator, if it makes sense:
>
> user=> ((compare-many [> compare]) [4 "beta"] [4 "alpha"])
> 1
> user=> ((compare-many [> compare]) [4 "beta"] [3 "gamma"])
> -1
>
> Next, a convenience function that takes a collection of keyfns,
> a collection of comparators (or predicates), and a collection to sort,
> passing it to sort-by:
>
> (defn sort-by-many [keyfns comps coll] (sort-by (apply juxt keyfns)
> (compare-many comps) coll))
>
> It's called like this:
>
> user=> (sort-by-many [:a :b] [> compare] [{:a 4 :b "beta"} {:a 4 :b
> "alpha"} {:a 3 :b "gamma"} {:a 5 :b "delta"}])
> ({:a 5, :b "delta"}
>  {:a 4, :b "alpha"}
>  {:a 4, :b "beta"}
>  {:a 3, :b "gamma"})
>
> And finally a function specific to my problem domain. It takes a sort
> order map and the collection to sort (note that I use (comp - compare) to
> get the inverse sort order):
>
> (defn sort-by-map [m coll]
>   (sort-by-many (keys m)
>(map #(case % 1 compare -1 (comp - compare) (throw
> (Exception. "1 or -1"))) (vals m))
>coll))
>
> It's called like this:
>
> user=> (sort-by-map (array-map :name 1 :age -1)
>  [{:name "zack" :age 25} {:name "amanda" :age 19} {:name "zack"
> :age 20} {:name "zack" :age 21}])
> ({:age 19, :name "amanda"}
>  {:age 25, :name "zack"}
>  {:age 21, :name "zack"}
>  {:age 20, :name "zack"})
>
> The collection doesn't have to contain maps:
>
> user=> (sort-by-map (array-map first 1 second -1) [["zack" 25] ["amanda"
> 19] ["zack" 20] ["zack" 21]])
> (["amanda" 19]
>  ["zack" 25]
>  ["zack" 21]
>  ["zack" 20])
>
> Is there anything that I've missed? Improvements?
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Model validation - exceptions as side-effects?

[Leonardo Borges]

On 18/08/2013 2:00 PM, "Alexandr Kurilin"  wrote:

>
> I'd love to know your expert opinion on this, since you wrote Bouncer: say
> you're in the situation I listed above, where you don't care about nice
> error handling, you just want to give the caller a 400 if the input is
> incorrect. Would you still go the route where the validator function
> returns a list of errors? My concern is that now I have to have additional
> checks in place in my controller for whether the model save returned a list
> of errors, which will regardless ultimately result in a 400 status code.
>

Hi Alexandr,

I see your point now and I completely agree your API should leak "as little
as possible, but no less".

By that I mean your API should try and help it users - as Christian pointed
out.

To me, the types of information you would not want leaked are: database
names, table names, server host names, software versions etc.

Validation errors on the other hand are, in my opinion, crucial when using
an API. It's very frustrating to make a request to an API I'm learning and
get a 400 back that tells me nothing about what went wrong - making me go
read the docs - so the information you're trying to hide would still be
available - only in a different medium.

In regards to your question though, about how to handle the validations if
you don't care about the actual messages, I'd approach it in one of two
ways - this is assuming bouncer as the validation library:

The first one is the same as before but highlighting you don't care about
the validation results:
(defn my-fn [my-map]
  (match (validate my-map)
  [nil original-map] (send-400)
  [_ original-map] (save original-map)))
;; bouncer returns nil as the first element of the vector if the validation
is successful



For the second one, I'll use the function 'valid?' , also from bouncer,
which simply returns a boolean - it's meant for the cases where you don't
care about the messages:

(defn my-fn [my-map]
  (if (valid? my-map)
  (save original-map)
  (send-400)))

I hope this is helpful - but I'd encourage you to think about the scenarios
where sending back validation errors could be helpful for your API clients


>
> Thanks!
>
> (BTW, your blog is great, great content)
>

Thank you for the kind words :)

Cheers,
Leonardo Borges

-- 
-- 
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/groups/opt_out.

Re: Model validation - exceptions as side-effects?

[Leonardo Borges]

I would prefer not throwing an exception in the case of a validation.

Say your validation function returns a vector or the first argument
contains validation errors if any and the second contains the original map:

(validate my-map) ;; returns [{:errors '("blah")} original-map]


Then a neat way to write your function, taking advantage or core.match[1],
would be this:

(defn my-fn [my-map]
  (match (validate my-map)
  [{:errors errors} original-map] (handle-errors)
  [_ original-map] (save original-map)))

This is my personal preference. It's concise, elegant and idiomatic in
languages that support pattern matching.

If you'd rather not use core.match for whatever reason, I'd still opt out
of throwing an exception. The function would just need a little bit more
code to simulate the behaviour above.

[1]: https://github.com/clojure/core.match

Leonardo Borges
www.leonardoborges.com


On Sat, Aug 17, 2013 at 12:08 PM, Alexandr Kurilin  wrote:

> Let's hypothetically say I have a Ring application and I'm performing some
> validation on the input map I receive as part of a POST request. The
> validate function throws an exception if anything's wrong with the input.
> The exception is caught in the middleware and turned into a 400 code
> response.
>
>  I could do either:
>
> (-> input
>  validate
>  save)
>
> or I could do:
>
> (do
>   (validate input)
>   (save input))
>
> The former doesn't really buy me anything, since a new version of input
> would never be returned by validate. It is however "side-effect free" in a
> way?
> The latter is probably less idiomatic, but makes it obvious that input is
> not changing as part of the evaluation.
>
> What would be the more elegant way of handling this? Is the do block
> approach somehow inferior?
>
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] bouncer 0.2.4-alpha1 [breaking changes]

[Leonardo Borges]

and of course by prefix I meant suffix!

Ok. Time for bed.

Leonardo Borges
www.leonardoborges.com


On Fri, Aug 16, 2013 at 12:41 AM, Leonardo Borges <
leonardoborges...@gmail.com> wrote:

> Sold.
>
> I've released it as "0.3.0-alpha1". I kept the alpha prefix as I'm the
> only one using this version now. Will release the final package after a few
> people have used it.
>
> Please do not use "0.2.4-alpha1" - I opened a ticket [1] with clojars to
> delete that version.
>
> [1]: https://github.com/ato/clojars-web/issues/163
>
> Thanks
>
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Fri, Aug 16, 2013 at 12:26 AM, Joseph Smith wrote:
>
>> I like releasing it as 0.3.0.
>>
>>---
>> Joseph Smith
>> j...@uwcreations.com
>> @solussd
>>
>>
>>
>>
>>
>>
>> On Aug 15, 2013, at 9:20 AM, Leonardo Borges 
>> wrote:
>>
>> Hi Moritz,
>>
>> Thanks for the suggestion. You're right and I missed this.
>>
>> I'll make sure I take this into account for the next release - I could
>> release it as 0.3.0-alpha1 but then I'd like to remove 0.2.4-alpha1 from
>> Clojars which doesn't seem to be a trivial thing to do.
>>
>>
>>
>> Leonardo Borges
>> www.leonardoborges.com
>>
>>
>> On Fri, Aug 16, 2013 at 12:13 AM, Moritz Ulrich wrote:
>>
>>>
>>> Just a small suggestion: Bugfix releases (z in x.y.z) are usually
>>> considered to be non-breaking, so breaking changes in such releases
>>> might cost people time when they assume they can upgrade without
>>> changing their code.
>>>
>>> It's nicer to introduce breaking changes to minor- or major-releases (x
>>> or
>>> y in x.y.z).
>>>
>>> Leonardo Borges writes:
>>>
>>> > Hi all,
>>> >
>>> > bouncer is a validation library for Clojure apps
>>> >
>>> > Github: https://github.com/leonardoborges/bouncer
>>> > Clojars: https://clojars.org/bouncer
>>> >
>>> > Version 0.2.4-alpha1 has undergone major, breaking changes:
>>> >
>>> > - My original design made heavy use of macros for a nicer, more
>>> natural DSL
>>> > at the expense of composition;
>>> > - This turned out not to be the best option as I received a few bug
>>> reports
>>> > related to issues composing validations;
>>> > - As a result I removed almost all macros in favour of functions
>>> >
>>> > In a nutshell what this means is that where once you wrote this:
>>> >
>>> > (b/validate {:postcode -1}
>>> >   :postcode [(v/required :message "required") (v/number
>>> > :message "number")])
>>> >
>>> > You will now write this:
>>> >
>>> > (b/validate {:postcode -1}
>>> >       :postcode [[v/required :message "required"] [v/number
>>> > :message "number"]])
>>> >
>>> > The difference is minimal, but the gains are great as I was able to
>>> > completely eliminate the defvalidatorset macro in favour of clojure
>>> maps:
>>> >
>>> > (def address-validations {:postcode [v/required v/number]})
>>> >
>>> > (b/validate {} address-validations)
>>> >
>>> > Please check out the
>>> > README<https://github.com/leonardoborges/bouncer/blob/master/README.md
>>> >for
>>> > updated docs as well as the
>>> > CHANGELOG<
>>> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
>>> > for
>>> > details.
>>> > Feedback on this version and the new API is greatly appreciated.
>>> >
>>> > Cheers,
>>> > Leonardo Borges
>>> > www.leonardoborges.com
>>> >
>>> > --
>>>
>>>
>>> --
>>> Moritz Ulrich
>>>
>>> --
>>> --
>>> 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.g

Re: [ANN] bouncer 0.2.4-alpha1 [breaking changes]

[Leonardo Borges]

Sold.

I've released it as "0.3.0-alpha1". I kept the alpha prefix as I'm the only
one using this version now. Will release the final package after a few
people have used it.

Please do not use "0.2.4-alpha1" - I opened a ticket [1] with clojars to
delete that version.

[1]: https://github.com/ato/clojars-web/issues/163

Thanks

Leonardo Borges
www.leonardoborges.com


On Fri, Aug 16, 2013 at 12:26 AM, Joseph Smith  wrote:

> I like releasing it as 0.3.0.
>
> ---
> Joseph Smith
> j...@uwcreations.com
> @solussd
>
>
>
>
>
>
> On Aug 15, 2013, at 9:20 AM, Leonardo Borges 
> wrote:
>
> Hi Moritz,
>
> Thanks for the suggestion. You're right and I missed this.
>
> I'll make sure I take this into account for the next release - I could
> release it as 0.3.0-alpha1 but then I'd like to remove 0.2.4-alpha1 from
> Clojars which doesn't seem to be a trivial thing to do.
>
>
>
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Fri, Aug 16, 2013 at 12:13 AM, Moritz Ulrich wrote:
>
>>
>> Just a small suggestion: Bugfix releases (z in x.y.z) are usually
>> considered to be non-breaking, so breaking changes in such releases
>> might cost people time when they assume they can upgrade without
>> changing their code.
>>
>> It's nicer to introduce breaking changes to minor- or major-releases (x or
>> y in x.y.z).
>>
>> Leonardo Borges writes:
>>
>> > Hi all,
>> >
>> > bouncer is a validation library for Clojure apps
>> >
>> > Github: https://github.com/leonardoborges/bouncer
>> > Clojars: https://clojars.org/bouncer
>> >
>> > Version 0.2.4-alpha1 has undergone major, breaking changes:
>> >
>> > - My original design made heavy use of macros for a nicer, more natural
>> DSL
>> > at the expense of composition;
>> > - This turned out not to be the best option as I received a few bug
>> reports
>> > related to issues composing validations;
>> > - As a result I removed almost all macros in favour of functions
>> >
>> > In a nutshell what this means is that where once you wrote this:
>> >
>> > (b/validate {:postcode -1}
>> >   :postcode [(v/required :message "required") (v/number
>> > :message "number")])
>> >
>> > You will now write this:
>> >
>> > (b/validate {:postcode -1}
>> >   :postcode [[v/required :message "required"] [v/number
>> > :message "number"]])
>> >
>> > The difference is minimal, but the gains are great as I was able to
>> > completely eliminate the defvalidatorset macro in favour of clojure
>> maps:
>> >
>> > (def address-validations {:postcode [v/required v/number]})
>> >
>> > (b/validate {} address-validations)
>> >
>> > Please check out the
>> > README<https://github.com/leonardoborges/bouncer/blob/master/README.md
>> >for
>> > updated docs as well as the
>> > CHANGELOG<
>> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
>> > for
>> > details.
>> > Feedback on this version and the new API is greatly appreciated.
>> >
>> > Cheers,
>> > Leonardo Borges
>> > www.leonardoborges.com
>> >
>> > --
>>
>>
>> --
>> Moritz Ulrich
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>
> --
> --
> 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 em

Re: [ANN] bouncer 0.2.4-alpha1 [breaking changes]

[Leonardo Borges]

Hi Moritz,

Thanks for the suggestion. You're right and I missed this.

I'll make sure I take this into account for the next release - I could
release it as 0.3.0-alpha1 but then I'd like to remove 0.2.4-alpha1 from
Clojars which doesn't seem to be a trivial thing to do.



Leonardo Borges
www.leonardoborges.com


On Fri, Aug 16, 2013 at 12:13 AM, Moritz Ulrich wrote:

>
> Just a small suggestion: Bugfix releases (z in x.y.z) are usually
> considered to be non-breaking, so breaking changes in such releases
> might cost people time when they assume they can upgrade without
> changing their code.
>
> It's nicer to introduce breaking changes to minor- or major-releases (x or
> y in x.y.z).
>
> Leonardo Borges writes:
>
> > Hi all,
> >
> > bouncer is a validation library for Clojure apps
> >
> > Github: https://github.com/leonardoborges/bouncer
> > Clojars: https://clojars.org/bouncer
> >
> > Version 0.2.4-alpha1 has undergone major, breaking changes:
> >
> > - My original design made heavy use of macros for a nicer, more natural
> DSL
> > at the expense of composition;
> > - This turned out not to be the best option as I received a few bug
> reports
> > related to issues composing validations;
> > - As a result I removed almost all macros in favour of functions
> >
> > In a nutshell what this means is that where once you wrote this:
> >
> > (b/validate {:postcode -1}
> >   :postcode [(v/required :message "required") (v/number
> > :message "number")])
> >
> > You will now write this:
> >
> > (b/validate {:postcode -1}
> >   :postcode [[v/required :message "required"] [v/number
> > :message "number"]])
> >
> > The difference is minimal, but the gains are great as I was able to
> > completely eliminate the defvalidatorset macro in favour of clojure maps:
> >
> > (def address-validations {:postcode [v/required v/number]})
> >
> > (b/validate {} address-validations)
> >
> > Please check out the
> > README<https://github.com/leonardoborges/bouncer/blob/master/README.md
> >for
> > updated docs as well as the
> > CHANGELOG<
> https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
> > for
> > details.
> > Feedback on this version and the new API is greatly appreciated.
> >
> > Cheers,
> > Leonardo Borges
> > www.leonardoborges.com
> >
> > --
>
>
> --
> Moritz Ulrich
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

[ANN] bouncer 0.2.4-alpha1 [breaking changes]

[Leonardo Borges]

Hi all,

bouncer is a validation library for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

Version 0.2.4-alpha1 has undergone major, breaking changes:

- My original design made heavy use of macros for a nicer, more natural DSL
at the expense of composition;
- This turned out not to be the best option as I received a few bug reports
related to issues composing validations;
- As a result I removed almost all macros in favour of functions

In a nutshell what this means is that where once you wrote this:

(b/validate {:postcode -1}
  :postcode [(v/required :message "required") (v/number
:message "number")])

You will now write this:

(b/validate {:postcode -1}
  :postcode [[v/required :message "required"] [v/number
:message "number"]])

The difference is minimal, but the gains are great as I was able to
completely eliminate the defvalidatorset macro in favour of clojure maps:

(def address-validations {:postcode [v/required v/number]})

(b/validate {} address-validations)

Please check out the
README<https://github.com/leonardoborges/bouncer/blob/master/README.md>for
updated docs as well as the
CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
for
details.
Feedback on this version and the new API is greatly appreciated.

Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: [ANN] bouncer 0.2.3-beta4

[Leonardo Borges]

Hi All,

I just pushed 0.2.3 final to Clojars. There are no changes since beta4
below.

As always, feedback is welcome.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Jul 17, 2013 at 10:12 AM, Leonardo Borges <
leonardoborges...@gmail.com> wrote:

> Hi all,
>
> bouncer is a validation DSL for Clojure apps
>
> Github: https://github.com/leonardoborges/bouncer
> Clojars: https://clojars.org/bouncer
>
> New in version 0.2.3-beta4:
>
> - Validator sets can now be used at the top level call to validate and
> valid?
> - Added tests and a doc section around validation pipelining. It was an
> undocumented assumption.
> - Initial support for inter-field validation via validator pre-conditions
> (alpha)
> - Bug fixes
>
> Please have a look at the 
> CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md> 
> for
> details.
>
> As always, feedback is welcome.
>
> Cheers,
> Leonardo Borges
> www.leonardoborges.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/groups/opt_out.

Re: Domain-specific language design books

[Leonardo Borges]

Then something more generic might be helpful, such as Fowler's DSL book:
http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-ebook/dp/B003ZUYJ3G/ref=sr_1_1?ie=UTF8&qid=1374198990&sr=8-1&keywords=domain+specific+languages

It's a bit dense - 600+ pages - but I've heard good things about it. Maybe
that'd be of help?

Leonardo Borges
www.leonardoborges.com


On Fri, Jul 19, 2013 at 11:51 AM, JvJ  wrote:

> Thanks.  Mostly, I'm looking for something that's about design principles
> rather than a "how-to".  I figure I might as well get educated before I
> just dive blindly in.
>
>
> On Thursday, 18 July 2013 13:30:06 UTC-7, JvJ wrote:
>>
>> Does anyone know of any good books on DSL design, in Clojure or any other
>> Lisp?
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Domain-specific language design books

[Leonardo Borges]

Every time you write a macro, you're writing a domain specific language.

To that end, I have found Let Over Lambda most valuable.

Cheers
On 19 Jul 2013 06:30, "JvJ"  wrote:

> Does anyone know of any good books on DSL design, in Clojure or any other
> Lisp?
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

[ANN] bouncer 0.2.3-beta4

[Leonardo Borges]

Hi all,

bouncer is a validation DSL for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

New in version 0.2.3-beta4:

- Validator sets can now be used at the top level call to validate and
valid?
- Added tests and a doc section around validation pipelining. It was an
undocumented assumption.
- Initial support for inter-field validation via validator pre-conditions
(alpha)
- Bug fixes

Please have a look at the
CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
for
details.

As always, feedback is welcome.

Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

ANN: rx-cljs, A ClojureScript wrapper for Reactive Extensions

[Leonardo Borges]

Hey guys,

Given some recent work I've been doing with RxJS [1], I ended up writing a
small Clojurescript wrapper for it.

The idea of being familiar with a common API in multiple environments
(Java, Javascript and Clojurescript) is what triggered this approach.

The README contains sample snippets and a link to an example app, as well
as a list of what's been implemented.
But be warned: it's very early days and this wrapper is still very much
incomplete.

I'm keen on spending more time on it if there is enough interest - at the
moment I've only implemented what I needed.

Where to find it:

Github: https://github.com/leonardoborges/rx-cljs
Clojars: https://clojars.org/com.leonardoborges/rx-cljs

[1]: https://github.com/Reactive-Extensions/RxJS


Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: New Relic installation on Heroku

[Leonardo Borges]

Are you using lein with "lein trampoline"?

If so, your app is running on a separate JVM, so you need to add this to
your project.clj:

  :jvm-opts ["-javaagent:newrelic/newrelic.jar"]

That was the bit missing for me. Hope this helps.

Cheers,

Leonardo Borges
www.leonardoborges.com


On Wed, May 8, 2013 at 11:09 PM, Jonathon McKitrick wrote:

> I should add... when the idle dyno spins up, I *do* see that in the
> instance chart on New Relic.  But none of the other stats show any activity.
>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: memorize-clj

[Leonardo Borges]

As a matter of fact Clojure core has it :)

Check it out: http://clojuredocs.org/clojure_core/clojure.core/memoize

Leonardo Borges
www.leonardoborges.com


On Mon, Apr 29, 2013 at 1:51 PM, Jorge Urdaneta wrote:

> Hi,
>
> I started a library called memorize-clj https://github.com/jorgeu/**
> memorize-clj <https://github.com/jorgeu/memorize-clj>
> It provides a function "memorize" that take a function and cache its
> results using
> guava cache. Of course the function must be pure and the parameters should
> be
> easy to compare and get a hashcode.
>
> Maybe I'm reinventing the wheel here but it was fun to build anyway.
> I saw this feature in Groovy and couldn't found anything equivalent for
> Clojure.
>
> --
> Jorge Urdaneta
>
> --
> --
> 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+unsubscribe@**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 the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Memoization in clojure

[Leonardo Borges]

or you can also store it in a var:

(defn fib [n]
   (if  (or (zero? n) (= n 1))
   1
   (+  (fib (dec n) )  (fib (- n 2)

(time (fib 30)) ;; "Elapsed time: 265.472 msecs"

(def fib-memo (memoize fib))

(time (fib-memo 30)) ;; "Elapsed time: 222.122 msecs"

(time (fib-memo 30)) ;; "Elapsed time: 0.058 msecs"

(time (fib-memo 30)) ;; "Elapsed time: 0.042 msecs"
Leonardo Borges
www.leonardoborges.com


On Sat, Apr 13, 2013 at 4:46 PM, Cedric Greevey  wrote:
> To get the benefit of memoization, you need to store the memoized function
> and use it again. (memoize fib-nocur) returns a function that contains an
> internal memory of past results. If you call (memoize fib-nocur) again you
> get a second function with an (empty!) internal memory. If you don't use the
> first one more than once you don't see any benefit from its memory.
>
> So, try this:
>
> (let [f (memoize fib-nocur)]
>   (time (f 30))
>   (time (f 30))
>   (time (f 30)))
>
> and see if the second and third times are much shorter than the first one.
>
>
> On Sat, Apr 13, 2013 at 12:52 AM, Liao Pengyu  wrote:
>>
>> Hi, there. I have a question about the memoization in clojure.
>> I compare two functions to test the performance improvement of
>> memoization:
>> (defn fib [n]
>>(if  (or (zero? n) (= n 1))
>>1
>>   (+  (fib (dec n) )  (fib (- n 2)
>>
>> (time (fib 30))
>> get the result:
>> "Elapsed time: 316.65 msecs"
>> 1346269
>>
>> And then test for memoization:
>> user> (time ((memoize fib-nocur) 30))
>> "Elapsed time: 308.729 msecs"
>> 1346269
>> user> (time ((memoize fib-nocur) 30))
>> "Elapsed time: 314.942 msecs"
>> 1346269
>> user> (time ((memoize fib-nocur) 30))
>> "Elapsed time: 308.657 msecs"
>> 1346269
>>
>> Seems no effect. Since I just test it in nrepl and have no experience
>> about using clojure in project, I wander was the memoization really works?
>> Look forward to your responses
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

[ANN] bouncer 0.2.3-beta1

[Leonardo Borges]

bouncer is a validation DSL for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

New in version 0.2.3-beta1:

- Validator sets can now be used at the top level call to validate and
valid?
- Added tests and a doc section around validation pipelining. It was an
undocumented assumption.
- Initial support for inter-field validation via validator pre-conditions
(alpha)

Please have a look at the
CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
for
details.

As always, feedback is welcome.

Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: with-redefs for vars in a different namespace for tests (midje facts)

[Leonardo Borges]

Hi,

So I got a working test and it looks like this:


(facts "sets a value for the given key in redis"
   (with-redefs [redis/with-conn (constantly "Ok")]
 (require '[com.leonardoborges.cache :as cache] :reload)
 (fact "with no ttl "
   (cache/set "key" "value") => "Ok"
   (provided
(redis/set "key" "value") => irrelevant

Note the 'require ... :reload' function call - it doesn't work without
that line.


My theory behind why this works is that when I reload the cache
namespace it recompiles it - and at that point, the new var binding is
available.

Is this the case? More importantly, is this how I should be doing this?

The source for cache/set is the same as before.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Mon, Feb 18, 2013 at 10:07 AM, Leonardo Borges
 wrote:
> Hi,
>
> I have some caching code that relies on a macro called 'with-redis' so
> while writing my tests I'd like to redef this macro to bypass all of
> it's redis connection machinery and just execute a function that does
> nothing instead.
>
> Something like this works:
>
> (with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
>  (cache/with-redis (do "stuff")))
> ;; "body called"
>
> But this doesn't:
> (with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
>  (cache/set "key" "value"))
>
> It actually attempts to talk to redis and doesn't run the dummy function at 
> all.
>
> For reference, cache/set is defined as follows, in my cache namespace:
>
> (defn set [key value]
>   (with-redis
> (let [key (cache-key key)]
>   (redis/set key value))))
>
>
> It would seem that 'with-redefs' doesn't work if the var your
> 'redefining' is being used in the body of a function you're calling?
>
> Or hopefully I'm just doing something wrong.
>
>
> Has anyone seen this before?
>
> Thanks,
> Leonardo Borges
> www.leonardoborges.com
Leonardo Borges
www.leonardoborges.com


On Mon, Feb 18, 2013 at 10:07 AM, Leonardo Borges
 wrote:
> Hi,
>
> I have some caching code that relies on a macro called 'with-redis' so
> while writing my tests I'd like to redef this macro to bypass all of
> it's redis connection machinery and just execute a function that does
> nothing instead.
>
> Something like this works:
>
> (with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
>  (cache/with-redis (do "stuff")))
> ;; "body called"
>
> But this doesn't:
> (with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
>  (cache/set "key" "value"))
>
> It actually attempts to talk to redis and doesn't run the dummy function at 
> all.
>
> For reference, cache/set is defined as follows, in my cache namespace:
>
> (defn set [key value]
>   (with-redis
> (let [key (cache-key key)]
>   (redis/set key value
>
>
> It would seem that 'with-redefs' doesn't work if the var your
> 'redefining' is being used in the body of a function you're calling?
>
> Or hopefully I'm just doing something wrong.
>
>
> Has anyone seen this before?
>
> Thanks,
> Leonardo Borges
> www.leonardoborges.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/groups/opt_out.

with-redefs for vars in a different namespace for tests (midje facts)

[Leonardo Borges]

Hi,

I have some caching code that relies on a macro called 'with-redis' so
while writing my tests I'd like to redef this macro to bypass all of
it's redis connection machinery and just execute a function that does
nothing instead.

Something like this works:

(with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
 (cache/with-redis (do "stuff")))
;; "body called"

But this doesn't:
(with-redefs [cache/with-redis (fn [& body] (prn "body called"))]
 (cache/set "key" "value"))

It actually attempts to talk to redis and doesn't run the dummy function at all.

For reference, cache/set is defined as follows, in my cache namespace:

(defn set [key value]
  (with-redis
(let [key (cache-key key)]
  (redis/set key value


It would seem that 'with-redefs' doesn't work if the var your
'redefining' is being used in the body of a function you're calling?

Or hopefully I'm just doing something wrong.


Has anyone seen this before?

Thanks,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error

[Leonardo Borges]

Hi Timothy,

I should have mentioned I'm using lein2. Heroku performs AOT
compilation for you by default when that's the case.

Cheers,


Leonardo Borges
www.leonardoborges.com


On Thu, Feb 14, 2013 at 1:30 PM, Timothy Licata
 wrote:
> Hi Leonardo,
>
> I ran into something similar a while ago.  To get around it, I setup
> :aot compilation.
>
> heroku config:add LEIN_BUILD_TASK="compile :all"
>
> However, in order for config vars to work, I had to install the labs plugin
> and enable user_env_compile.
>
> heroku plugins:install http://github.com/heroku/heroku-labs.git
> heroku labs:enable user_env_compile -a 
>
> I am not sure if this info is up-to-date or if it applies to your
> situation, but I thought I'd mention it.
>
> Tim
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error

[Leonardo Borges]

Hi Michael,

Will definitely reach support - just wanted to hear if someone else in
the community had issues.

The only external dependency I have is Redis - but doesn't doesn't get
connected until after startup.

Could it be related to new relic? That's the only external service -
besides downloading jars - that the app tries to reach upon starting
up.

I'll look into that as well.
Leonardo Borges
www.leonardoborges.com


On Thu, Feb 14, 2013 at 12:35 PM, Michael Gorsuch
 wrote:
> Hi Leonardo,
>
> IIRC, this error comes about when an app takes too long to launch.  If you 
> are doing anything "interesting" during startup, perhaps you can shave some 
> time off of it to increase your chances of success.
>
> I highly recommend that you reach out to support and let them know about what 
> you are experiencing.  This seems like something they'd like to squash if 
> this is happening on a regular basis.
>
> Best,
>
> Michael Gorsuch
> http://twitter.com/michaelgorsuch
>
> On Feb 13, 2013, at 7:29 PM, Leonardo Borges  
> wrote:
>
>> Hi all,
>>
>> This one goes to people using heroku for their production Clojure apps.
>>
>> Heroku says that Dynos will be restarted at least once every day -
>> that doesn't seem like a big issue, however this morning I noticed my
>> web dyno has crashed with the aforementioned error (R10).
>>
>> I tried restarting it a couple of times, getting the same error each
>> time - sad panda.
>>
>> Then, with no changes on my part, the web dynos restarted cleanly and
>> have been running now for a couple of hours. This is just scary :(
>>
>> I don't seem to have any guarantees that my app boot won't timeout
>> next time a dyno restarts - what has been your experience with it?
>>
>> Anyone else hitting this problem?
>>
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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/groups/opt_out.
>>
>>
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Clojure, Heroku and the dreaded R10 Boot Timeout Error

[Leonardo Borges]

Hi all,

This one goes to people using heroku for their production Clojure apps.

Heroku says that Dynos will be restarted at least once every day -
that doesn't seem like a big issue, however this morning I noticed my
web dyno has crashed with the aforementioned error (R10).

I tried restarting it a couple of times, getting the same error each
time - sad panda.

Then, with no changes on my part, the web dynos restarted cleanly and
have been running now for a couple of hours. This is just scary :(

I don't seem to have any guarantees that my app boot won't timeout
next time a dyno restarts - what has been your experience with it?

Anyone else hitting this problem?


Cheers,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: multiple nrepl sessions in emacs

[Leonardo Borges]

Excellent!

Thanks, will give it a shot soon!

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Feb 13, 2013 at 11:23 AM, Hugo Duncan  wrote:
> Leonardo Borges  writes:
>
>> Is there an efficient way to work with multiple nrepl sessions in
>> emacs? I hope I'm just missing something obvious.
>
> nrepl.el master has support for this [1].  Should be available via
> MELPA.
>
>
> Hugo
>
> [1] https://github.com/kingtim/nrepl.el/pull/238
> [2] https://github.com/kingtim/nrepl.el#installation
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

multiple nrepl sessions in emacs

[Leonardo Borges]

Hi all,

I tried googling this info but came up with nothing.

I often find myself working in at least two different Clojure projects
daily so I have one repl for each constantly running on my terminal.

What doesn't seem optimal is that I have to disconnect one nrepl
session in emacs before connecting to the next repl - otherwise nrepl
creates a  buffer but sends my evaluation commands to the
original  buffer.

Is there an efficient way to work with multiple nrepl sessions in
emacs? I hope I'm just missing something obvious.

Thanks,
Leonardo Borges
www.leonardoborges.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/groups/opt_out.

Re: Clojure/West (Portland, Mar 18-20) - Mission Kontrol, unsessions, lightning talks

[Leonardo Borges]

ah now that makes sense. I'll watch the twittersphere :)
Leonardo Borges
www.leonardoborges.com


On Thu, Feb 7, 2013 at 7:07 PM, Rich Morin  wrote:
> On Feb 6, 2013, at 21:07, Leonardo Borges wrote:
>> Where can we find more about this datomic hack session?
>
> Sorry, it appears that I only posted about this to the Datomic list:
>
>   There will be some unconference sessions Monday evening, so I'll try to
>   schedule something then for Codeq / Datomic.  However, those sessions
>   will be pretty short, so I'm still planning to do a hack session Sunday
>   afternoon from 3-6 (or so :-).
>
>   I probably won't have a specific location until Sunday afternoon, so my
>   plan is to leave some cookie crumbs lying about.
>
>   *  a relevant tweet, eg:
>
>The #datomic hack session at #clojurewest is located at ___.
>Look for the ___.
>
>   *  a note on a message board and/or front desk, eg:
>
>Datomic hack session, 3-6 pm, ___
>
>   This is a good-sized hotel, so I'm pretty sure we'll be able to find a
>   spot to hang out (eg, in the main lobby).  Worst case, a few of us can
>   meet in my hotel room.  After the session, I'll lead a dinner run.
>
> If anyone is arriving earlier and wants to help with logistics, contact me
> (off-list) so we can coordinate...
>
> -r
>
>  --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: Clojure/West (Portland, Mar 18-20) - Mission Kontrol, unsessions, lightning talks

[Leonardo Borges]

Hey Rich,

Where can we find more about this datomic hack session?
Leonardo Borges
www.leonardoborges.com


On Thu, Feb 7, 2013 at 4:03 PM, Rich Morin  wrote:
> On Feb 6, 2013, at 18:27, Alex Miller wrote:
>> If you're coming in the night before the conference, we've got Mission 
>> Kontrol,
>> the arcade wonderland reserved with FREE PLAY on all games from 7-9 pm.  It's
>> just a couple blocks from the hotel.
>
> And, if you think real computers are more fun to play with than video games,
> drop by the Datomic Hack Session, starting at ~3 pm...
>
> -r
>
>  --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] oauth-clj

[Leonardo Borges]

Thanks for the answer Roman!

In the end I went with Matt's lib purely based on the number of stars
and forks - so far so good.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Feb 6, 2013 at 3:25 AM, r0man  wrote:
> When I started this library I wanted something that was based on
> clj-http and the concept of middleware. At that time Matt's
> library was not based on clj-http yet. But this has changed ...
>
> On Tuesday, February 5, 2013 6:37:13 AM UTC+1, Leonardo Borges wrote:
>>
>> Nobody ever replied to this and I'm now wondering the same.
>>
>> Any opinions one way or the other?
>>
>> On Tuesday, January 24, 2012 5:08:44 PM UTC+11, Dave Sann wrote:
>>>
>>> Hi r0man,
>>>
>>> I am curious as to similarities/differences of your library to:
>>> https://github.com/mattrepl/clj-oauth
>>>
>>> Dave
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] oauth-clj

[Leonardo Borges]

Nobody ever replied to this and I'm now wondering the same.

Any opinions one way or the other?

On Tuesday, January 24, 2012 5:08:44 PM UTC+11, Dave Sann wrote:
>
> Hi r0man,
>
> I am curious as to similarities/differences of your library to: 
> https://github.com/mattrepl/clj-oauth
>
> Dave
>

-- 
-- 
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/groups/opt_out.

Re: Clojure - Python Style suggestion

[Leonardo Borges]

Honestly I find myself missing S-Expressions in other languages now.
The structure they provide is extremely useful in my opinion -
especially when writing macros.

Also, syntax is only one of the many facets of Clojure - if all the
benefits and features Clojure provides doesn't cut it for newcomers, I
doubt a python-like syntax will do. In the end, Syntax is just that.
Syntax. People get over it. (Even thought I still think S-Expressions
ARE a feature.)

In the end, have newcomers program in a bastardised version of
lisp/clojure to only then have them deal with S-Expressions misses the
entire point.

my 2c.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Tue, Feb 5, 2013 at 10:50 AM, Mikhail Kryshen  wrote:
> The problem of readability of S-expressions has been discussed since the
> beginnings of Lisp.
>
> Some known alternative notations:
> http://en.wikipedia.org/wiki/M-expression
> http://readable.sourceforge.net/
>
>
> On Mon, 4 Feb 2013 22:01:30 +0200
> Sergey Didenko  wrote:
>
>> Hi,
>>
>> For us as Clojure community it is easy to see how Clojure benefits
>> from being a Lisp. Homoiconity, extreme conciseness, esoteric look and
>> feel, etc.
>>
>> However it is hard to see from the inside how Clojure as ecosystem
>> (probably) suffer from being a Lisp. Please don't throw rotten eggs at
>> me, I mean only the part of Lisp that is ... parentheses.
>>
>> I remember a number of people that mention parentheses as obstacles to
>> the wider Clojure adoption, in the Clojure space - in the Clojure
>> related discussions, even on this mailing list IIRC.
>>
>> But the number of people thinking this way outside the Clojure groups
>> is even bigger! We probably don't notice it because got immune to this
>> famous argument "it has too many parentheses" early when diving into
>> Clojure.
>>
>> I suggest there are a big number of people that could gain interest in
>> clojure if we provide them with parentheses-lite Clojure syntax. For
>> example we can steal Python way of intending blocks.
>>
>> For example the following quicksort implementation
>>
>> (defn qsort [[pivot & xs]]
>>   (when pivot
>> (let [smaller #(< % pivot)]
>>   (lazy-cat (qsort (filter smaller xs))
>>   [pivot]
>>   (qsort (remove smaller xs))
>>
>> could be written as
>>
>> (set! python-style-op-op true)
>>
>> defn qsort [[pivot & xs]]
>>   when pivot
>> let [smaller #(< % pivot)]
>>   lazy-cat
>> qsort
>>   filter smaller xs
>>   [pivot]
>>   qsort
>>   remove smaller xs
>>
>> What do you think?
>>
>> Isn't is less complex?
>>
>>
>> P.S. Ok, I must confess, the mention of the C-Word in the last
>> sentence was just a desperate way to get Rich's attention.
>>
>> P.P.S. Actually I would also love to see Clojure community making
>> video clip "Clojure - Python Style" as a remix for "G... Style", but
>> this idea is probably way ahead of its time.
>>
>>
>> Regards, Sergey.
>
> Mikhail
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: Performance issue with hashing records

[Leonardo Borges]

Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
got results similar to yours.

In Clojure 1.4, I get this:

user> (time (dotimes [n 1000] (hash {:x "a" :y 3})))
"Elapsed time: 5993.331 msecs"
nil
user>  (time (dotimes [n 1000] (hash (A. "a" 3
"Elapsed time: 3144.368 msecs"

No clue as to the reason though - but it seems something might have
changed from 1.4 to 1.5?


Leonardo Borges
www.leonardoborges.com


On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg  wrote:
> I just went through the process of converting my map-based program over to
> records, hoping it would improve speed.  Much to my dismay, it actually
> slowed my program down substantially.  With some profiling, I discovered
> that one possible explanation is that (at least in RC4) hashing of records
> is about 60x slower than their map-based counterpart.
>
> (defrecord A [x y])
> => (time (dotimes [n 1000] (hash {:x "a" :y 3})))
> "Elapsed time: 90.631072 msecs"
> => (time (dotimes [n 1000] (hash (A. "a" 3
> "Elapsed time: 5549.788311 msecs"
>
> Any thoughts about why this is the case?
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: How to use pmap over a partition-all list of list?

[Leonardo Borges]

this works:

(apply pmap + (partition-all 5 (range 1 20)))

And then reducing the overall result:

(reduce + (apply pmap + (partition-all 5 (range 1 20


Leonardo Borges
www.leonardoborges.com


On Sun, Feb 3, 2013 at 12:35 AM, Leandro Moreira
 wrote:
> Hi Jim,
>
> Thanks for your help & time, how do I apply instead of reduce?
>
> I was looking the documentation of pmap and it says
>
> (pmap fn coll & colls)
>
> So I think we can use pmap this way:
>
> (pmap + '(1 2 3) '(4 5 6) '(7 8 9) )
>
> Which gives us the result: (12 15 18)
>
> My intention it's only to use range and partition to substitute that, but I
> think partition-all doesn't work like separated argument as list, instead.
> When we type:
>
> (partition-all 5 (range 1 20))
> Results in this:
> ((1 2 3 4 5) (6 7 8 9 10) ...
>
> There is any way of transforming (maybe a macro or destruct way) this "list"
> in several colls argument as expected by pmap signature (fn coll & colls)?
>
>
> On Saturday, February 2, 2013 11:10:35 AM UTC-2, Jim foo.bar wrote:
>>
>> Use this:
>>
>> (pmap #(reduce + %) (partition-all 5 (range 1 20)))
>>
>> OR as you yourself said you can use 'apply' instead of reduce
>>
>> Jim
>>
>>
>>
>> On 02/02/13 12:31, Leandro Moreira wrote:
>>
>> Hi there,
>>
>> I have this:
>>
>> user=> (partition-all 5 (range 1 20))
>> ((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))
>>
>> And I would like to apply the pmap over the partitions, something like:
>> (the line bellow doesn't work)
>> user=> (pmap + (partition-all 5 (range 1 20)))
>>
>> I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 14
>> 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 10) (11 12
>> 13 14 15) (16 17 18 19)))
>>
>> How can I apply pmap over a partition-all result?
>> If it's possible, by doing that am I distributing the load better than if
>> I used the pmap with the whole list?
>>
>> Thanks
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: blank? implementation

[Leonardo Borges]

This is interesting. We can get quite a huge performance boos by type 
hinting that impl.

Times on my system running Clojure 1.4.0:

user=> (defn s-blank? [s] (every? #(Character/isWhitespace %) s))
user=> (time (dotimes [n 2] (s-blank? "asdf")))
"Elapsed time: 247.252 msecs"

Now if we type hint s-blank, here's what I get:

(defn s-blank? [^CharSequence s] (every? (fn [^Character c] 
(Character/isWhitespace c)) s))

user=> (time (dotimes [n 2] (s-blank? "asdf")))
"Elapsed time: 9.122 msecs"

Not bad :) Especially when compared to clojure's blank? :

user=> (time (dotimes [n 2] (clojure.string/blank? "asdf")))
"Elapsed time: 2.62 msecs"

Is it still slower? Absolutely! But we didn't have to give up the 
functional approach to boost performance - a little type hinting in this 
case provided a huge benefit.

On Wednesday, January 16, 2013 7:35:07 AM UTC+11, Thomas wrote:
>
> I think I just answered my own question...
>
> user=> (time (dotimes [n 2] (s-blank? "asdf")))
> "Elapsed time: 2481.018 msecs"
> nil
> user=> (time (dotimes [n 2] (blank? "asdf")))
> "Elapsed time: 14.347 msecs"
> nil
> user=> 
>
> Quite a difference I have to say. 
>
> 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

[ANN] bouncer 0.2.2 released

[Leonardo Borges]

bouncer is a validation DSL for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

Highlights of version 0.2.2:

- Use of a qualified keyword for storing the validation results
- The defvalidator macro allows defining validators with an arbitrary
number of arguments
- New validators
- Better docs
- minor bug fixes
- more...

Please have a look at the
CHANGELOG<https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md>
for
details.

As always, feedback is welcome.

Cheers,
Leonardo Borges
www.leonardoborges.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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Excellent.

I'll push 0.2.2 final to clojars soon - as soon as I get the ANN email out.

Thanks for the help.

Cheers

Leonardo Borges
www.leonardoborges.com


On Wed, Jan 16, 2013 at 4:37 AM, Gary Johnson  wrote:

> Worked like a charm. Thanks.
>
>
> On Tuesday, January 15, 2013 12:33:26 PM UTC-5, Gary Johnson wrote:
>>
>> Right, I was testing against 1.5.0-RC1 and 1.5.0-RC2. Same problem
>> occurred both times. I should have reported that in my initial bug report.
>> Sorry about that. Also, thanks for the quick turnaround. I'll pull it and
>> test it out.
>>
>>   ~Gary
>>
>> On Monday, January 14, 2013 7:16:29 PM UTC-5, Leonardo Borges wrote:
>>>
>>> Sean pointed me to it in the other thread. I read the ticket and
>>> discussion - I personally don't feel it's abuse. To me it feels as natural
>>> a use of destructuring as any other.
>>>
>>> just my 2c.
>>>
>>> Leonardo Borges
>>> www.leonardoborges.com
>>>
>>>
>>> On Tue, Jan 15, 2013 at 11:14 AM, Toby Crawley wrote:
>>>
>>>> This issue has already been reported and filed:
>>>> http://dev.clojure.org/jira/**browse/CLJ-1140<http://dev.clojure.org/jira/browse/CLJ-1140>
>>>>
>>>> There's been some discussion around that issue on clojure-dev@ as to
>>>> whether this is a regression or an abuse of destructuring.
>>>>
>>>> Leonardo Borges writes:
>>>>
>>>> > Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure
>>>> whether this
>>>> > is a regression or intended behaviour so I'll send a separate email
>>>> to the
>>>> > list about that.
>>>> >
>>>>
>>>>
>>>> --
>>>> Toby Crawley
>>>> http://immutant.org | http://torquebox.org
>>>>
>>>> --
>>>> 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<http://groups.google.com/group/clojure?hl=en>
>>>>
>>>
>>>  --
> 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 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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Sean pointed me to it in the other thread. I read the ticket and discussion
- I personally don't feel it's abuse. To me it feels as natural a use of
destructuring as any other.

just my 2c.

Leonardo Borges
www.leonardoborges.com


On Tue, Jan 15, 2013 at 11:14 AM, Toby Crawley  wrote:

> This issue has already been reported and filed:
> http://dev.clojure.org/jira/browse/CLJ-1140
>
> There's been some discussion around that issue on clojure-dev@ as to
> whether this is a regression or an abuse of destructuring.
>
> Leonardo Borges writes:
>
> > Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure whether
> this
> > is a regression or intended behaviour so I'll send a separate email to
> the
> > list about that.
> >
>
>
> --
> Toby Crawley
> http://immutant.org | http://torquebox.org
>
> --
> 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 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

Re: map destructuring mismatch between Clojure 1.4.0 and 1.5.0-RC1

[Leonardo Borges]

Thanks!

Leonardo Borges
www.leonardoborges.com


On Tue, Jan 15, 2013 at 11:08 AM, Sean Corfield wrote:

> See http://dev.clojure.org/jira/browse/CLJ-1140
>
> On Mon, Jan 14, 2013 at 3:57 PM, Leonardo Borges
>  wrote:
> > Hi all,
> >
> > A user reported a bug in my library and after tracking it down it turned
> our
> > to only happen on Clojure 1.5.0-RC1.
> >
> > Here's the behaviour in 1.4.0:
> >
> > (let [{:keys [message] :or {message "foo"}} '()] message)
> > ;; "foo"
> >
> > And here's what happens in 1.5.0-RC1:
> >
> > (let [{:keys [message] :or {message "foo"}} '()] message)
> > IllegalArgumentException No value supplied for key: null
> > clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
> >
> >
> > I worked around it by doing the destructuring in two steps in my library
> but
> > I'm wondering is this is intended behaviour?
> >
> > And if so, I'm sure it's been discussed somewhere - maybe JIRA? - if
> someone
> > would be so kind as to point me to the ticke, that'd be much appreciated.
> >
> > Cheers,
> > Leonardo Borges
> > www.leonardoborges.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
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "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 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

map destructuring mismatch between Clojure 1.4.0 and 1.5.0-RC1

[Leonardo Borges]

Hi all,

A user reported a bug in my library and after tracking it down it turned
our to only happen on Clojure 1.5.0-RC1.

Here's the behaviour in 1.4.0:

(let [{:keys [message] :or {message "foo"}} '()] message)
;; "foo"

And here's what happens in 1.5.0-RC1:

(let [{:keys [message] :or {message "foo"}} '()] message)
IllegalArgumentException No value supplied for key: null
 clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)


I worked around it by doing the destructuring in two steps in my library
but I'm wondering is this is intended behaviour?

And if so, I'm sure it's been discussed somewhere - maybe JIRA? - if
someone would be so kind as to point me to the ticke, that'd be much
appreciated.

Cheers,
Leonardo Borges
www.leonardoborges.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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure whether this
is a regression or intended behaviour so I'll send a separate email to the
list about that.

In the meantime I've applied a fix and pushed [bouncer "0.2.2-RC2"]

With this change I'm also using lein profiles to run the tests against
Clojure 1.3, 1.4 and 1.5-RC1 - The README has a build status indicator from
travis.ci. This should prevent version bugs like this one from appearing in
the future.

Thanks for the report,
Cheers

Leonardo Borges
www.leonardoborges.com


On Tue, Jan 15, 2013 at 9:51 AM, Leonardo Borges <
leonardoborges...@gmail.com> wrote:

> Hi Gary,
>
> Thanks for the bug report.
>
> Which version of Clojure causes the issue? I've been using Clojure 1.4 and
> the exact snippet you posted works flawlessly. As well as bouncer, given I
> have test cases around validators with no explicit messages.
>
>
> Cheers,
>
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Tue, Jan 15, 2013 at 7:52 AM, Gary Johnson  wrote:
>
>> Hey Leonardo,
>>
>>   There's a critical bug in 0.2.2-RC1 in the bouncers.core/wrap function.
>> An IllegalArgumentException is triggered whenever a validator is not passed
>> an explicit :message field. It looks like this was introduced in the
>> process of trying to allow validators to take an arbitrary number of input
>> args (a very good thing IMO). Here's a minimum case for replicating this
>> error at your repl:
>>
>> (let [{:keys [message] :or {message "foo"}} '()] message)
>> IllegalArgumentException No value supplied for key: null
>> clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
>>
>> This is being triggered in your wrap function when you apply map
>> destructuring to the right-hand result of (split-with (complement keyword?)
>> args). Anyway, here is a patched version of wrap that should fix the
>> problem. FWIW, I also fixed the docstring typo "erros" -> "errors".
>>
>> (defn wrap
>>   "Wraps pred in the context of validating a single value
>>
>>   - `acc`  is the map being validated
>>
>>   - `pred` is a validator
>>
>>   - `k`the path to the value to be validated in the associative
>> structure acc
>>
>>   - `args` any extra args to pred
>>
>>   It only runs pred if:
>>
>>   - the validator is optional *and* there is a non-nil value to be
>> validated (this information is read from pred's metadata)
>>
>>   - there are no previous errors for the given path
>>
>>   Returns `acc` augmented with a namespace qualified ::errors keyword
>> "
>>   [acc [pred k & args]]
>>   (let [pred (h/resolve-or-same pred)
>> k (if (vector? k) k [k])
>> error-path (cons ::errors k)
>> {:keys [default-message-format optional]} (meta pred)
>> [args message-kv] (split-with (complement keyword?) args)
>> message (get (apply hash-map message-kv) :message
>> default-message-format)
>> pred-subject (get-in acc k)]
>> (if (or (and optional (nil? pred-subject))
>> (not (empty? (get-in acc error-path)))
>> (apply pred pred-subject args))
>>   acc
>>   (update-in acc error-path
>>  #(conj % (format message (name (peek k
>>
>> Cheers,
>>   ~Gary
>>
>>
>>
>> On Sunday, January 13, 2013 8:03:36 PM UTC-5, Leonardo Borges wrote:
>>
>>> Thanks, really appreciate the kind words.
>>>
>>> I just pushed [bouncer "0.2.2-RC1"] so feel free to give that a go :)
>>>
>>> Cheers,
>>> Leo
>>>
>>> Leonardo Borges
>>> www.leonardoborges.com
>>>
>>>
>>> On Fri, Jan 11, 2013 at 3:44 PM, faenvie  wrote:
>>>
>>>>
>>>> i took a look at it. bouncers DSL seems smart inside and out.
>>>> Has an excellent Documentation too. Thanks for sharing it.
>>>>
>>>>  --
>>>> 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
>>>> ht

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Hi Gary,

Thanks for the bug report.

Which version of Clojure causes the issue? I've been using Clojure 1.4 and
the exact snippet you posted works flawlessly. As well as bouncer, given I
have test cases around validators with no explicit messages.


Cheers,

Leonardo Borges
www.leonardoborges.com


On Tue, Jan 15, 2013 at 7:52 AM, Gary Johnson  wrote:

> Hey Leonardo,
>
>   There's a critical bug in 0.2.2-RC1 in the bouncers.core/wrap function.
> An IllegalArgumentException is triggered whenever a validator is not passed
> an explicit :message field. It looks like this was introduced in the
> process of trying to allow validators to take an arbitrary number of input
> args (a very good thing IMO). Here's a minimum case for replicating this
> error at your repl:
>
> (let [{:keys [message] :or {message "foo"}} '()] message)
> IllegalArgumentException No value supplied for key: null
> clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
>
> This is being triggered in your wrap function when you apply map
> destructuring to the right-hand result of (split-with (complement keyword?)
> args). Anyway, here is a patched version of wrap that should fix the
> problem. FWIW, I also fixed the docstring typo "erros" -> "errors".
>
> (defn wrap
>   "Wraps pred in the context of validating a single value
>
>   - `acc`  is the map being validated
>
>   - `pred` is a validator
>
>   - `k`the path to the value to be validated in the associative
> structure acc
>
>   - `args` any extra args to pred
>
>   It only runs pred if:
>
>   - the validator is optional *and* there is a non-nil value to be
> validated (this information is read from pred's metadata)
>
>   - there are no previous errors for the given path
>
>   Returns `acc` augmented with a namespace qualified ::errors keyword
> "
>   [acc [pred k & args]]
>   (let [pred (h/resolve-or-same pred)
> k (if (vector? k) k [k])
> error-path (cons ::errors k)
> {:keys [default-message-format optional]} (meta pred)
> [args message-kv] (split-with (complement keyword?) args)
> message (get (apply hash-map message-kv) :message
> default-message-format)
> pred-subject (get-in acc k)]
> (if (or (and optional (nil? pred-subject))
> (not (empty? (get-in acc error-path)))
> (apply pred pred-subject args))
>   acc
>   (update-in acc error-path
>  #(conj % (format message (name (peek k
>
> Cheers,
>   ~Gary
>
>
>
> On Sunday, January 13, 2013 8:03:36 PM UTC-5, Leonardo Borges wrote:
>
>> Thanks, really appreciate the kind words.
>>
>> I just pushed [bouncer "0.2.2-RC1"] so feel free to give that a go :)
>>
>> Cheers,
>> Leo
>>
>> Leonardo Borges
>> www.leonardoborges.com
>>
>>
>> On Fri, Jan 11, 2013 at 3:44 PM, faenvie  wrote:
>>
>>>
>>> i took a look at it. bouncers DSL seems smart inside and out.
>>> Has an excellent Documentation too. Thanks for sharing it.
>>>
>>>  --
>>> 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<http://groups.google.com/group/clojure?hl=en>
>>>
>>
>>  --
> 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 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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Thanks, really appreciate the kind words.

I just pushed [bouncer "0.2.2-RC1"] so feel free to give that a go :)

Cheers,
Leo

Leonardo Borges
www.leonardoborges.com


On Fri, Jan 11, 2013 at 3:44 PM, faenvie  wrote:

>
> i took a look at it. bouncers DSL seems smart inside and out.
> Has an excellent Documentation too. Thanks for sharing it.
>
>  --
> 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 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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

I just pushed [bouncer "0.2.2-RC1"] - would appreciate if you could give
that a go.

You can check the changelog to see what's new:
https://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md#022-unreleased

But the big changes include:

- a qualified keyword for the errors entry and;
- a short-circuit mechanism as suggested by Gary

If everything looks good or I don't hear back, I'll push 0.2.2 final to
clojars tomorrow and send a full ANN post.

Cheers and thanks for the great feedback.

Leo.

Leonardo Borges
www.leonardoborges.com


On Fri, Jan 11, 2013 at 10:35 AM, Leonardo Borges <
leonardoborges...@gmail.com> wrote:

> Hi Gary,
>
> First off, I wanna thank you for you thorough review and feedback of
> bouncer - it's very much appreciated.
>
> Please see my comments inline.
>
>
> On Fri, Jan 11, 2013 at 2:35 AM, Gary Johnson  wrote:
> > Also, I agree with Stathis that there is a problem including the errors
> map
> > in the original data structure under an unqualified keyword. Of course,
> if
> > you change validate to not modify the input map that is being validated,
> > then you no longer need a state monad to model the validation workflow.
> This
> > could just as easily be done with a simple reduce. In this instance, I'd
> > guess that just qualifying the ::errors keyword would probably stick
> closest
> > to your original model. Maybe I'm totally missing the mark here though.
> >
>
> Sold. You're the second person to mention this so I believe it's worth
> considering.
>
> My original thinking was to use the errors key as a convention for
> validation errors but
> given the multitude of domains this could be applied to, that might
> have been a bit too selfish.
>
> I'll add a qualified error keyword to the next release.
>
> >
> > So basically what I'm suggesting as an enhancement to your library is
> that
> > whenever a field is being tested with a multi-validator vector, the first
> > test to fail should prevent any other tests (to its right in the vector)
> > from running. This would be similar in spirit to the behavior of the -?>
> and
> > -?>> thread-maybe macros in clojure.core.incubator.
> >
>
> This makes sense. Thanks for the code snippets - they illustrated your
> point brilliantly.
>
> The current design shifts that onus to the validators and in cases
> such as the one
> demonstrated by your second code snippet, this is far from ideal.
>
> I've put your code in the test suite which means I now have a broken
> build I need to fix :)
>
> This would be a great addition to bouncer. I'll take some time to go
> over a couple of implementation
> options but I'm keen on adding it in.
>
> > Okay, constructive criticism and all that aside, great work on this
> library
> > again. Looking forward to the next release soon.
> >
> >   ~Gary
> >
>
> I'm glad you enjoyed the lib - stay tuned, I'll probably have news
> over the weekend.
>
> Cheers,
> Leo.
>

-- 
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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Leonardo Borges
www.leonardoborges.com
On Jan 11, 2013 3:44 PM, "faenvie"  wrote:

>
> i took a look at it. bouncers DSL seems smart inside and out.
> Has an excellent Documentation too. Thanks for sharing it.
>
> --
> 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 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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Hi Gary,

First off, I wanna thank you for you thorough review and feedback of
bouncer - it's very much appreciated.

Please see my comments inline.


On Fri, Jan 11, 2013 at 2:35 AM, Gary Johnson  wrote:
> Also, I agree with Stathis that there is a problem including the errors map
> in the original data structure under an unqualified keyword. Of course, if
> you change validate to not modify the input map that is being validated,
> then you no longer need a state monad to model the validation workflow. This
> could just as easily be done with a simple reduce. In this instance, I'd
> guess that just qualifying the ::errors keyword would probably stick closest
> to your original model. Maybe I'm totally missing the mark here though.
>

Sold. You're the second person to mention this so I believe it's worth
considering.

My original thinking was to use the errors key as a convention for
validation errors but
given the multitude of domains this could be applied to, that might
have been a bit too selfish.

I'll add a qualified error keyword to the next release.

>
> So basically what I'm suggesting as an enhancement to your library is that
> whenever a field is being tested with a multi-validator vector, the first
> test to fail should prevent any other tests (to its right in the vector)
> from running. This would be similar in spirit to the behavior of the -?> and
> -?>> thread-maybe macros in clojure.core.incubator.
>

This makes sense. Thanks for the code snippets - they illustrated your
point brilliantly.

The current design shifts that onus to the validators and in cases
such as the one
demonstrated by your second code snippet, this is far from ideal.

I've put your code in the test suite which means I now have a broken
build I need to fix :)

This would be a great addition to bouncer. I'll take some time to go
over a couple of implementation
options but I'm keen on adding it in.

> Okay, constructive criticism and all that aside, great work on this library
> again. Looking forward to the next release soon.
>
>   ~Gary
>

I'm glad you enjoyed the lib - stay tuned, I'll probably have news
over the weekend.

Cheers,
Leo.

-- 
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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

Stathis,

That's a very good point. I've been thinking about the usefulness of
returning the errors map in the original map since the errors map itself is
returned as the first element in the call to 'validate'.

To be honest I'm tempted to remove that with the next release, making
validate return a single value: the errors map.

I'm happy for you to argue otherwise though. Do you think having the
qualified keywords in the original map is still useful?

I'll be releasing a new version over the weekend that will include this
change.

Thanks for the feedback

Leonardo Borges
www.leonardoborges.com
On Jan 10, 2013 7:08 AM, "Stathis Sideris"  wrote:

> Hey Leonardo,
>
> This is very interesting, but I'd like to know whether it's possible to
> validate a map that contains an :errors key. Would bouncer overwrite this
> with its own :errors key? Should it not be using a fully-qualified keyword
> (as in ::errors) to avoid the clash?
>
> Thanks,
>
> Stathis
>
>
> On Friday, 4 January 2013 06:56:19 UTC, Leonardo Borges wrote:
>>
>> Hey guys,
>>
>> I extracted a small validation library from a side project I'm working
>> on and bouncer is the result.
>>
>> While I do know there are a couple of validation libs out there
>> already, I decided this was worth publishing mostly because:
>>
>> - That’s what I’m using in my current side project
>> - It takes a fundamentally different implementation approach that is
>> in itself worthy of exploration
>> - If nothing else, this is yet another example of where Monads can be
>> useful.
>>
>> The full reasoning can be found in a post I wrote:
>> https://bitly.com/ZiLJzO
>>
>> Where to find it:
>>
>> Github: 
>> https://github.com/**leonardoborges/bouncer<https://github.com/leonardoborges/bouncer>
>> Clojars: https://clojars.org/bouncer
>>
>> The README file on github contains a detailed guide to using the
>> library, hopefully that's enough should you want to try it out.
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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 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

Re: ANN: bouncer, validation library for clojure

[Leonardo Borges]

The ones I looked at were https://github.com/r0man/validation-clj and
https://github.com/michaelklishin/validateur


Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Jan 9, 2013 at 4:29 PM, Karim Nassar  wrote:
> what are the other validation libraries?
>
> TIA,
> Karim
>
> --
> Karim
>
>
> On Thu, Jan 3, 2013 at 10:56 PM, Leonardo Borges
>  wrote:
>>
>> Hey guys,
>>
>> I extracted a small validation library from a side project I'm working
>> on and bouncer is the result.
>>
>> While I do know there are a couple of validation libs out there
>> already, I decided this was worth publishing mostly because:
>>
>> - That’s what I’m using in my current side project
>> - It takes a fundamentally different implementation approach that is
>> in itself worthy of exploration
>> - If nothing else, this is yet another example of where Monads can be
>> useful.
>>
>> The full reasoning can be found in a post I wrote:
>> https://bitly.com/ZiLJzO
>>
>> Where to find it:
>>
>> Github: https://github.com/leonardoborges/bouncer
>> Clojars: https://clojars.org/bouncer
>>
>> The README file on github contains a detailed guide to using the
>> library, hopefully that's enough should you want to try it out.
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.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 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 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

Re: Copying (immigrating) macros from namespace to namespace

[Leonardo Borges]

On Mon, Jan 7, 2013 at 1:17 PM, Stuart Sierra
 wrote:
> I've said it before and I will keep saying it: copying symbols by interning
> vars breaks the identity of the original vars. It breaks dynamic binding,
> with-redefs, and the ability to redefine functions at the REPL.
>
> Clojure has a two perfectly good mechanisms for making vars available in
> other namespaces:
>
> 1. `refer`. Define a public function that `refer`s all the symbols you want.
> It's an extra step for the user, but that's good because it makes it evident
> that extra symbols are being added.
>

So this would be no different than having the user put an extra 'use'
call to use any additional namespaces right? In this case I'd rather
have the user explicitly perform the  "use" call instead of "refer",
like this:

(require '[bouncer.core :as b])
(use '[bouncer.validators :only [defvalidator])

Which is what I recommend at the moment.

> 2. `load`. If you have N namespaces with no clashing symbols, then you only
> need one namespace. If you want to split it across multiple files, use
> `load`. `clojure.core` does this.
>

This sounds like what I want. I'll look into it, thanks.

Leo.

-- 
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

Re: Copying (immigrating) macros from namespace to namespace

[Leonardo Borges]

+1

I was thinking of doing the same in the validation lib I published
recently [1] and this thread came in handy. I haven't implemented it
yet but having a common way in which people do this seems reasonable -
if it's in core then all the better.

Cheers,
Leo


[1] - https://github.com/leonardoborges/bouncer
Leonardo Borges
www.leonardoborges.com


On Mon, Jan 7, 2013 at 12:04 PM, Brian Marick  wrote:
>
> On Jan 6, 2013, at 3:34 PM, Sean Corfield  wrote:
>
>> Here's what I use to pull symbols from Enlive into FW/1:
>
>
> Midje plays similar tricks to make namespace abilities available via one 
> `use`.
>
> Which makes me think:
>
> 1: In the old patterns world, there was a "rule of three" which claimed that 
> something shouldn't be published as a pattern until it could be demonstrated 
> in three real systems.
>
> 2: Lispers like Gabriel and others noted that what were patterns in languages 
> like Smalltalk and C++ were built into Lisp or were easily regularized 
> in-language with macros.
>
> Therefore: to me, this email thread suggests that the ability to do such 
> consolidation should be immortalized not in email examples of patterns 
> ("here's how I accomplished X") but - in a more Lispy fashion - by writing a 
> common library and making it available to the user base. That is: functions 
> like Adam's and Sean's and mine should be in some official library close to 
> clojure.core.
>
> 
> Occasional consulting on programming technique
> Contract programming in Ruby and Clojure
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
>
> --
> 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 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

Re: Different concrete type reported from macro

[Leonardo Borges]

Tks for link. I'll work around it.


Leonardo Borges
www.leonardoborges.com


On Fri, Jan 4, 2013 at 12:24 PM, Stephen Compall
 wrote:
> On Jan 3, 2013 6:24 AM, "Leonardo Borges" 
> wrote:
>> As you can see, when using macroexpand-1, the type of the arg is
>> clojure.lang.PersistentList.
>>
>> However, when actually executing the macro, the type is clojure.lang.Cons
>>
>> Is this behaviour expected?
>
> Yes. Last thread here:
> http://thread.gmane.org/gmane.comp.java.clojure.user/66294 ; search for
> further threads on the seq* trichotomy.
>
> tl;dr don't use 'list?'.
>
> --
> Stephen Compall
> If anyone in the MSA is online, you should watch this flythrough.
>
> --
> 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 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

ANN: bouncer, validation library for clojure

[Leonardo Borges]

Hey guys,

I extracted a small validation library from a side project I'm working
on and bouncer is the result.

While I do know there are a couple of validation libs out there
already, I decided this was worth publishing mostly because:

- That’s what I’m using in my current side project
- It takes a fundamentally different implementation approach that is
in itself worthy of exploration
- If nothing else, this is yet another example of where Monads can be useful.

The full reasoning can be found in a post I wrote: https://bitly.com/ZiLJzO

Where to find it:

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

The README file on github contains a detailed guide to using the
library, hopefully that's enough should you want to try it out.

Cheers,
Leonardo Borges
www.leonardoborges.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

Different concrete type reported from macro

[Leonardo Borges]

Hi all,

I'm writing a macro and hit an issue with concrete types. I extracted
the code into a minimum macro that exposes the issue below:


(defmacro my-macro [arg]
  (prn (type arg)))

(macroexpand-1 '(my-macro #((complement nil?) %)))
;; clojure.lang.PersistentList

(my-macro #((complement nil?) %))
;;clojure.lang.Cons


As you can see, when using macroexpand-1, the type of the arg is
clojure.lang.PersistentList.

However, when actually executing the macro, the type is clojure.lang.Cons

Is this behaviour expected?


Cheers,
Leonardo Borges
www.leonardoborges.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

Re: abysmal multicore performance, especially on AMD processors

[Leonardo Borges]

In that case isn't context switching dominating your test?

.isArray isn't expensive enough to warrant the use of pmap

Leonardo Borges
www.leonardoborges.com
On Dec 29, 2012 10:29 AM, "cameron"  wrote:

> Hi Lee,
>   I've done some more digging and seem to have found the root of the
> problem,
> it seems that java native methods are much slower when called in parallel.
> The following code illustrates the problem:
>
> (letfn [(time-native [f]
>  (let [c (class [])]
>(time (dorun (f
>  (fn [_] (.isArray c))
>  (range 1000))]
>   (println "Sequential Test:")
>   (time-native map)
>   (println "Parallel Test:")
>   (time-native pmap))
>
> On a dual quad-core xeon box I get the following results:
>   Sequential Test:
>"Elapsed time: 1054.807725 msecs"
>   Parallel Test:
>"Elapsed time: 15302.605697 msecs"
>
> ie. the code executed in parallel was 15 times slower than the sequential
> version.
> The same can be seen with isInstance and isArray members of
> java.lang.Class.
>
> I'm not sure where to go from here, these functions are frequently used by
> clojure.core
> Perhaps someone with more JVM implementation knowledge can help?
>
> Cameron.
>
> --
> 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 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

Re: Clojure videos deleted from blip.tv?

[Leonardo Borges]

Ilshad,
Thanks a lot!

Cheers,

Leonardo Borges
www.leonardoborges.com



On Fri, Dec 14, 2012 at 7:21 PM, Ilshad Khabibullin wrote:

> I'm sorry, Russian link. English is:
>
>
> https://itunes.apple.com/en/podcast/michael-fogus-fertile-ground/id275488598?i=126465057&mt=2
>
> On 14.12.2012, at 12:19, Ilshad Khabibullin  wrote:
>
> Leo,
>
> yes, here:
>
>
> https://itunes.apple.com/ru/podcast/michael-fogus-fertile-ground/id275488598?i=126465057&mt=2
>
> On 14.12.2012, at 3:59, Leonardo Borges 
> wrote:
>
>
> > Are these videos available elsewhere?
>>
>> Yes, in iTunes podcasts.
>>
>
> Really? I tried finding them in itunes but no luck. Would you be able to
> point me to one of them?
>
> Cheers,
> Leo
>
> --
> 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 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 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

Re: Clojure videos deleted from blip.tv?

[Leonardo Borges]

> > Are these videos available elsewhere?
>
> Yes, in iTunes podcasts.
>

Really? I tried finding them in itunes but no luck. Would you be able to
point me to one of them?

Cheers,
Leo

-- 
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

Re: Clojure web framework

[Leonardo Borges]

On Sun, Sep 30, 2012 at 12:27 PM, James MacAulay wrote:

> Frameworks have benefits which can't easily be achieved with
> documentation. The most obvious to me is that a framework lets you fire up
> a complete system of carefully curated components in no time. They also let
> you defer choices until you actually need to care about them.
>
> Because Clojure's libraries are so composable, it seems like a good
> approach to fill this gap would be "just" a lein project template with an
> opinionated set of dependencies, a sane and predictable folder hierarchy,
> and a good Getting Started Guide. A quick clojars search reveals many that
> might fit that description, but none have very high visibility.
>
>
That's a good point. I put together a repo that I've been using as my main
template for web apps for a while. You can find it on github:
https://github.com/leonardoborges/clj-boilerplate

It tries to bridge that gap. The idea is to clone it, follow the readme and
you should have a new webapp running in a short amount of time.

I would like to turn it into a lein template but haven't had the time to do
so. Still, it could be useful to some.

Cheers,
Leonardo Borges

-- 
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

Re: Clojure : a good start for non-programmers?

[Leonardo Borges]

Hi Gregorius!

I think Clojure is a great way to start to learn to program! Clojure
is a flavour of lisp and so is Scheme - which has been used for
decades to teach programming to MIT undergrads.

In terms of resources on learning functional programming I think The
Little Lisper is a terrific book:
http://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/0262560992

And if yearn for more advanced things later on, SICP - the actual text
book used at MIT - can be found for free online here:
http://mitpress.mit.edu/sicp/

Both books use scheme but I believe you should be able translate the
examples to Clojure without too much effort.

just my 2c.

Best of luck!

Leonardo Borges
www.leonardoborges.com


On Mon, Sep 24, 2012 at 4:11 PM, Gregorius R.  wrote:
> Hello Clojurists!
>
> I'm a person in middle age (you know, too old to rock'n'roll, to young to
> die) and would like to programm but starting with functional programming.
> Regarding this i have some questions:
>
> is clojure a good start to learn programming?
> which (prerfer free online) is a good tut to start?
> am i to old for this stuff?
>
> thnx in advance for all responses
> Greg
>
> --
> 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 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

Re: clj-logging-config, lein2 and AOT compilation == NullPointerException

[Leonardo Borges]

I haven't really found out what the problem is - and haven't been looking 
into it - but I put a small clojure app together to replicate the issue.

You can find it on dropbox[1]

I've also updated the issue I had opened on the clj-logging-config github 
issues page [2]

If you're keen on debugging this, just grab the project on dropbox, extract 
somewhere and compile it:

lein with-profile production compile :all

Then try to start the server like so:

lein trampoline with-profile production run -m logging-tests.core 4000

You should have a big fat exception right on your terminal.

[1] https://dl.dropbox.com/u/6251992/logging-tests.zip
[2] https://github.com/malcolmsparks/clj-logging-config/issues/15


On Tuesday, September 4, 2012 2:57:21 PM UTC+10, Leonardo Borges wrote:
>
> Hi all,
>
> I've been debugging an issue in my Clojure app deployed on Heroku and 
> after some time I finally tracked it down to what appears 
> to be an issue when AOT compiling the project while using 
> clj-logging-config [1]
>
> It works without any issues if I let Clojure compile my namespaces on the 
> fly. As soon as I AOT compile, I can't run my jetty server any longer.
>
> This led me to open an issue [2] with clj-logging-config where you can 
> find some extra info on my setup.
>
> I'm posting this here in the hopes someone has been through this before 
> and that the solution is something trivial I've overlooked.
>
> [1] https://github.com/malcolmsparks/clj-logging-config
> [2] https://github.com/malcolmsparks/clj-logging-config/issues/15
>
> Thanks,
> Leonardo Borges
> www.leonardoborges.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

clj-logging-config, lein2 and AOT compilation == NullPointerException

[Leonardo Borges]

Hi all,

I've been debugging an issue in my Clojure app deployed on Heroku and after
some time I finally tracked it down to what appears
to be an issue when AOT compiling the project while using
clj-logging-config [1]

It works without any issues if I let Clojure compile my namespaces on the
fly. As soon as I AOT compile, I can't run my jetty server any longer.

This led me to open an issue [2] with clj-logging-config where you can find
some extra info on my setup.

I'm posting this here in the hopes someone has been through this before and
that the solution is something trivial I've overlooked.

[1] https://github.com/malcolmsparks/clj-logging-config
[2] https://github.com/malcolmsparks/clj-logging-config/issues/15

Thanks,
Leonardo Borges
www.leonardoborges.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

Re: Deprecation of Swank Clojure, long live nrepl.el

[Leonardo Borges]

Nevermind. I used lein deps :tree to analyze my current dependency
tree an realized korma depended on Clojure 1.3.0 - why lein was
loading 1.2.1 sometimes is still beyond me.

I upgraded Korma and lein repl now respects my preference for clojure 1.4.0

All is well in the world. Sorry for the noise.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Aug 23, 2012 at 1:06 PM, Leonardo Borges
 wrote:
> Moreover, not only it starts an old version of Clojure, but it
> randomly picks a clojure version each time I start the repl (?!) from
> within the same project directory
>
> $ lein repl
> nREPL server started on port 7888
> REPL-y 0.1.0-beta10
> Clojure 1.3.0
>
>
> $ lein repl
> nREPL server started on port 7888
> REPL-y 0.1.0-beta10
> Clojure 1.2.1
>
> $ lein repl
> nREPL server started on port 7888
> REPL-y 0.1.0-beta10
> Clojure 1.3.0
>
> Absolutely no clue. I even removed all Clojure versions from ~/.m2
> just in case that was messing up something but no help.
>
> And I do have Clojure 1.4.0 listed in my project.clj:
>
> (defproject blah/blah "1.0.0-SNAPSHOT"
>  :dependencies [[org.clojure/clojure "1.4.0"]
> ...
>
> Cheers,
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Thu, Aug 23, 2012 at 12:03 PM, Leonardo Borges
>  wrote:
>> I must be missing something here. I followed the steps on the
>> leiningen upgrade wiki page and everything seemed fine.
>>
>> However, even thought my project has an explicit dependency on Clojure
>> 1.4.0, lein repl is starting a session with Clojure 1.2.1
>>
>> Can't really see where I've gone wrong. Does this ring a bell to anyone?
>>
>> Cheers,
>> Leonardo Borges
>> www.leonardoborges.com
>>
>>
>> On Thu, Aug 23, 2012 at 7:52 AM, Warren Lynn  wrote:
>>>
>>>
>>>> Hi Warren,
>>>>
>>>> You may want to check out  https://github.com/purcell/ac-nrepl.
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>
>>> Thank you. I tried it out. It basically works but has glitches:
>>>
>>> 1. If I type "(clojure.repl/", right after the forward slash, I got a
>>> exception "java.lang.ClassNotFoundException: clojure.repl" (followed by a
>>> long stack trace). This is close to a deal breaker for me.
>>>
>>> 2. The pop-up documentation does not work right. Lines are missing (but
>>> those lines will show up again if I resize my Emacs window to force a
>>> redraw). I am on Windows so that could be a factor, but my auto-complete
>>> pop-up documentation for my Elisp code has no problem.
>>>
>>>
>>>
>>> --
>>> 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 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

Re: Deprecation of Swank Clojure, long live nrepl.el

[Leonardo Borges]

Moreover, not only it starts an old version of Clojure, but it
randomly picks a clojure version each time I start the repl (?!) from
within the same project directory

$ lein repl
nREPL server started on port 7888
REPL-y 0.1.0-beta10
Clojure 1.3.0


$ lein repl
nREPL server started on port 7888
REPL-y 0.1.0-beta10
Clojure 1.2.1

$ lein repl
nREPL server started on port 7888
REPL-y 0.1.0-beta10
Clojure 1.3.0

Absolutely no clue. I even removed all Clojure versions from ~/.m2
just in case that was messing up something but no help.

And I do have Clojure 1.4.0 listed in my project.clj:

(defproject blah/blah "1.0.0-SNAPSHOT"
 :dependencies [[org.clojure/clojure "1.4.0"]
...

Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Aug 23, 2012 at 12:03 PM, Leonardo Borges
 wrote:
> I must be missing something here. I followed the steps on the
> leiningen upgrade wiki page and everything seemed fine.
>
> However, even thought my project has an explicit dependency on Clojure
> 1.4.0, lein repl is starting a session with Clojure 1.2.1
>
> Can't really see where I've gone wrong. Does this ring a bell to anyone?
>
> Cheers,
> Leonardo Borges
> www.leonardoborges.com
>
>
> On Thu, Aug 23, 2012 at 7:52 AM, Warren Lynn  wrote:
>>
>>
>>> Hi Warren,
>>>
>>> You may want to check out  https://github.com/purcell/ac-nrepl.
>>>
>>> Cheers,
>>> Tim
>>>
>>
>> Thank you. I tried it out. It basically works but has glitches:
>>
>> 1. If I type "(clojure.repl/", right after the forward slash, I got a
>> exception "java.lang.ClassNotFoundException: clojure.repl" (followed by a
>> long stack trace). This is close to a deal breaker for me.
>>
>> 2. The pop-up documentation does not work right. Lines are missing (but
>> those lines will show up again if I resize my Emacs window to force a
>> redraw). I am on Windows so that could be a factor, but my auto-complete
>> pop-up documentation for my Elisp code has no problem.
>>
>>
>>
>> --
>> 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 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

Re: Deprecation of Swank Clojure, long live nrepl.el

[Leonardo Borges]

I must be missing something here. I followed the steps on the
leiningen upgrade wiki page and everything seemed fine.

However, even thought my project has an explicit dependency on Clojure
1.4.0, lein repl is starting a session with Clojure 1.2.1

Can't really see where I've gone wrong. Does this ring a bell to anyone?

Cheers,
Leonardo Borges
www.leonardoborges.com


On Thu, Aug 23, 2012 at 7:52 AM, Warren Lynn  wrote:
>
>
>> Hi Warren,
>>
>> You may want to check out  https://github.com/purcell/ac-nrepl.
>>
>> Cheers,
>> Tim
>>
>
> Thank you. I tried it out. It basically works but has glitches:
>
> 1. If I type "(clojure.repl/", right after the forward slash, I got a
> exception "java.lang.ClassNotFoundException: clojure.repl" (followed by a
> long stack trace). This is close to a deal breaker for me.
>
> 2. The pop-up documentation does not work right. Lines are missing (but
> those lines will show up again if I resize my Emacs window to force a
> redraw). I am on Windows so that could be a factor, but my auto-complete
> pop-up documentation for my Elisp code has no problem.
>
>
>
> --
> 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 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

Re: What concurrency models to document?

[Leonardo Borges]

Hey,

A bit late to the party but something I'd love to see in the book is
an approachable summary/description/use cases of the main concurrency
models at play today: event-based and thread-based concurrency. I see
this section helping people compare Clojure with something like
Node.js or Ruby with EventMachine (Clojure has aleph[1] for that
purpose).

There is a lot of controversy around the topic and I believe even a
brief discussion on the subject will be beneficial.

This paper has a lot a good info:
http://static.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
(it is biased towards a threaded model though).

Would this be way out of scope for your book? - Even not exactly what
you were after when you asked about concurrency models?

[1] https://github.com/ztellman/aleph/

Cheers,
Leonardo Borges
www.leonardoborges.com


On Fri, Aug 3, 2012 at 1:11 PM, cej38  wrote:
> I think that you have to talk about concurrency!  It is on everyone's mind.
> I would like to see the discussion go further than what I have seen in most
> other Clojure books.  If you are REALLY interested in concurrency, you are
> probably interested in looking at using more than one node in a cluster.
> Two areas that are always interested in concurrency are big data and high
> performance computing.  I come from a background where the only idea of how
> to do concurrency is through the use of MPI.  I would like to learn how to
> get nodes on a cluster to talk to each other within a Clojure enviroment.
>
> Further, a paragraph or two about what use cases each of the node
> interconnect models would work best for would be absolutely awesome.  As an
> example, I know that all of the following exist but I don't know when to use
> what (I know clojure-hadoop is NOT what I want for my use cases).
>
> clojure-hadoop
> swamiji
> cacalog
> zookeeper-clj
> storm
> Avout
> lein-condor
>
> --
> 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 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

Re: Idea around SCMs and Clojure

[Leonardo Borges]

I haven't been following this discussion that closely so far but I'd
like to comment on this bit:

> One of my frustrations with source control systems is the way you end up 
> repeating information, e.g. Modified function X, Refactored function Y. > 
> Added defmethod etc… This information is already present in the commit, after 
> all its what you DID. The system should be able to work that out > and 
> provide that information.

Good commit messages contain more than that. For instance it would
contain the reasoning behind the refactoring of function Y or the
change to function X. That might be clear to you and perhaps some of
your team. New members - and existing ones - might lack that context.

My point is that I don't think the proposed output should replace a
well hand crafted commit message.

Cheers,
Leonardo Borges
www.leonardoborges.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

Re: mcache 0.1.0 released

[Leonardo Borges]

There's this one: https://github.com/shughes/clojure-memcached

It's two years old so definitely out of date but maybe worth forking?

Cheers,
Leonardo Borges
www.leonardoborges.com


On Sun, Feb 19, 2012 at 12:14 PM, DHM  wrote:

> Hi,
>
> I want to announce the release of mcache 0.1.0:
> https://github.com/davidhmartin/mcache
>
> This provides protocol-based support for memcached and memcached-like
> clients, with an implementation using spymemcached.
>
> I coded this up in support of a web site I'm developing. I didn't find
> much in the way of existing clojure-based memcached support. I assume
> this is because it's easy enough to use the java apis directly, but it
> seemed like there can still be a benefit to putting a wrapper around
> these and adding some higher-level functionality.
> This initial version provides functions for add, set, replace, get,
> and incr/decr, plus a couple of additional functions supporting the
> caching of data fetched from a persistent store.
>
> I'm quite new to Clojure, so any feedback or suggestions of better
> ways to do things are more than welcome.
>
> Thanks!
>
> -Dave
>
> --
> 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 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

Re: Calling all Melbourne, Australia, Clojure users

[Leonardo Borges]

Hi James,

I'm currently using Meetup.com - http://www.meetup.com/clj-syd/ - to handle
our Sydney Clojure User Group. We're about to have our first open meeting -
the group was internal to ThoughtWorks before that.

So far I like Meetup's interface. Feel free to hit me up if I can be of any
help.

Also, do visit us if you ever come to Sydney.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Tue, Feb 7, 2012 at 10:23 PM, James Sofra  wrote:

> Hi all,
>
> I have been discussing recently possibly starting a Melbourne Clojure
> meetup.
> We have a possible location scouted out already but I really don't have a
> good idea of who may be using Clojure in Melbourne.
>
> I met a couple of people at the Conj last year so I am in contact with
> them and there is this list of people at
> http://clojure.meetup.com/members/au/melbourne/
>
> If I can find enough interested people I will go ahead and organise
> something more official but for the moment I am just trying to scout out to
> see if there is any interest.
>
> So please drop a note here, or you email me directly, to let me know if
> you are in Melbourne and interesting in catching up to chat about and hack
> Clojure.
>
> BTW, anyone had any experience with meetup.com, is it worth paying the
> dues to use?
>
> Cheers,
> James Sofra
>
> --
> 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 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

[ANN] Sydney Clojure User Group

[Leonardo Borges]

Hi everyone,

Just a quick note to let you know about the Sydney Clojure User Group
(clj-syd)

The group started as an internal meetup at the ThoughtWorks office but
we're about to have our first open meetup in a couple of weeks.

Here's the announcement: http://bit.ly/clj-syd
Google groups: http://bit.ly/yLfPTr
Meetup.com page: http://www.meetup.com/clj-syd/

So that's it, if you're ever in town, come say hi. We have parenthesis,
pizza and beer :)


Cheers,
Leonardo Borges
www.leonardoborges.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

Re: Distributed transactions

[Leonardo Borges]

Distributed transactions slow u down Why the hell would you want that?
I'm yet to see a valid use case! They require sticky sessions *whi*ch suck
for scalability! Keep in mind it's 4am on the 31st of December :-)

Leonardo Borges
www.leonardoborges.com
Sent from my Galaxy Nexus(IceCreamSandwhich)
On Jan 1, 2012 3:42 AM, "Bronsa"  wrote:

> maybe avout is what you're looking for?
> https://github.com/liebke/avout
>
> 2011/12/31 Michael Jaaka 
>
>> Is there any attempt to make distributed transactions?
>> The usage scenario is the same like in JEE apps.
>> I mean, there is a web service call, the transaction is started, there
>> are some changes to db, some jms sends and when there is no failure
>> all is commited.
>> Maybe someone is already using glassfish or spring from clojure? Some
>> reference to github?
>>
>> --
>> 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 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 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

Re: Simplicity, and implications on usage of SQL

[Leonardo Borges]

I'm new to clojure but I find the approach [1]Arel takes to SQL very useful.
It uses relational algebra to make complex SQL statements composed by
smaller structures that represent simple SQL statements.

On my current project, we use it as a way to provide the staff will a
flexible query builder. They use a fancy UI in the web app to choose the
"rules" they want applied to their query and the code then composes the
complex statement by "merging" all those "relations" together. It's a really
great way to abstract SQL and has done wonders for us in this particular
project.

[1] https://github.com/nkallen/arel


Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Oct 26, 2011 at 1:04 PM, Brent Millare wrote:

> In the thread about Rich Hickey's talk on simplicity, people bring up the
> point that Rich suggests to *finally*, learn SQL. The idea is to use
> declarations to describe your solution, decoupling implementation details.
>
> However, its arguable that SQL itself is hard. For example, programmers can
> often encounter deeply nested SQL statements. One might say the statement is
> complex and thus harder to understand. What would help is if the SQL
> statement could be broken up into composable pieces. Pig/Pig Latin [1], is
> one such example of this, where programmers write imperative (seems more
> like functional to me), statements, and you can model your data conceptually
> via input and output through named bindings and operators.
>
> My question is this, is it possible to write composable SQL? Named
> expressions might help (binding a query to a name that you can reuse in
> another query), but I feel like they may not be enough.
>
> In core.match, queries are declarative, but one can write functions that
> work on query arguments, thus giving composable queries, is this the right
> approach?
>
> Best,
> Brent
>
>
> [1]
> http://www.google.com/url?sa=t&rct=j&q=pig%20latin%20sigmod%202008&source=web&cd=2&ved=0CCIQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.134.9888%26rep%3Drep1%26type%3Dpdf&ei=lWenTquWGqrz0gH7jfW9Dg&usg=AFQjCNGNzB3kdxtWW3r-6q3Ts8CWhYrffg
>
> --
> 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 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

Re: Shameless self promotion - JavaOne

[Leonardo Borges]

How about putting it up on slideshare?  Pretty sure they can import pptx ;)

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Oct 5, 2011 at 3:55 PM, Dennis  wrote:

> Here is a link to my presentation.
>
>
> http://dl.dropbox.com/u/5831287/JavaOne%202011%20-%20Monitoring%20a%20Large-Scale%20Infrastructure%20with%20Clojure%20FINAL.pptx
>
> Sorry about the file format :)
>
> Let me know if the link doesn't work.
>
> -- Dennis
>
> On Tue, Oct 4, 2011 at 10:17 AM, C. Arel  wrote:
> > Hi Dennis and Chas,
> > I'd also like the slides if possible. Maybe if you could post them
> > here in the group more people can get them.
> >
> > Thanks,
> > Can
> >
> > On 27 Sep, 17:50, Dennis  wrote:
> >> Hey guys,
> >>
> >> I will be giving a talk at JavaOne (it is Clojure related).  Here is
> >> the information.
> >>
> >> Title:  Monitoring a Large-Scale Infrastructure with Clojure
> >> Time Tuesday, 07:30 PM, Parc 55 - Embarcadero
> >> Length  45 Minutes
> >> Abstract:   Monitoring a large infrastructure brings unique
> challenges
> >> that require blending development and operations concepts. This
> >> session discusses how Dell Inc. used Clojure to develop a
> >> data-flow-based monitoring system that stores, evaluates, and acts on
> >> hundreds of thousands of metrics.
> >>
> >> It covers
> >> • Real-world applications of Clojure's parallel programming constructs
> >> to take advantage of multiple cores available in today's systems
> >> • Using Clojure's homoiconic nature to create DSLs
> >> • Taking advantage of Clojure running on the JVM to use the Java
> ecosystem
> >> • How DevOps takes advantage of the JVM dynamic languages to develop
> >> new monitoring tools
> >> Track   Emerging Languages, Tools, and Techniques
> >> Optional Track  The Java Frontier
> >>
> >> -- Dennis
> >
> > --
> > 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 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 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

Re: Neighbors function from The Joy of Clojure

[Leonardo Borges]

It certainly helped :)

I played around with it last night after chouser's response and it all made 
sense, thanks!

Cheers,

Leonardo Borges
www.leonardoborges.com

On 15/09/2011, at 1:39 AM, Sean Corfield  wrote:

> On Wed, Sep 14, 2011 at 5:58 AM, Leonardo Borges
>  wrote:
>> (defn neighbors
>>   ([size yx] (neighbors [[-1 0] [1 0] [0 -1] [0 1]] size yx))
>>   ([deltas size yx]
>> (filter (fn [new-yx]
>>   (every? #(< -1 % size) new-yx))
>>  (map #(map + yx %) deltas
>> 
>> This syntax made me scratch my head since I believe it was the first
>> time I saw it.
> 
> In case it wasn't clear from Chouser's response, the key difference is
> that this declares two versions of neighbors, one that takes three
> arguments and one that takes four - essentially overloading on arity.
> Here's an example from some of our code at World Singles:
> 
> (defn save-row
>  "Given a table name (string), a record and an optional
>   key-gen function, either insert it after applying the
>   key-gen function (if no pk) or update it. In both
>   cases, return the pk. The default key-gen function
>   is a no-op (identity).
>   When operating on a MongoDB collection, the logic is
>   much simpler because the pk is always :_id and key
>   generation is always handled by MongoDB. Also, we
>   always return the entire updated record (since we
>   can run functions against the database)."
>  ([table record](save-row table record identity :id 0))
>  ([table record key-gen](save-row table record key-gen :id 0))
>  ([table record key-gen pk] (save-row table record key-gen pk 0))
>  ([table record key-gen pk retry]
>...))
> 
> Mostly we call this as (save-row :table-name {:some "record"}) but we
> can also supply a key generation function (save-row :table-name {:some
> "record"} add-uuid), for tables that don't have a generated PK column,
> and we can specify the PK name if it isn't :id (save-row :table-row
> {:some "record"} identity :email).
> 
> Ignore retry - we need to refactor that into a private helper function
> :) It's part of the machinery that let's automatically retry
> operations on MongoDB if the replica set has no active primary node
> since it can take a while to failover...
> 
> Hope that helps?
> -- 
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.com/
> 
> "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 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

Re: Neighbors function from The Joy of Clojure

[Leonardo Borges]

Ah, got ya. Did not think of that :)

Thanks for the insight!

Cheers,
Leonardo Borges
www.leonardoborges.com



On Wed, Sep 14, 2011 at 11:29 PM, Chouser  wrote:
> On Wed, Sep 14, 2011 at 8:58 AM, Leonardo Borges
>  wrote:
>> Hi Guys,
>> I'm pretty new to clojure and to the list as well - this being my 1st
>> message - so hello everyone :)
>> I'm going through the book The Joy of Clojure which, pardon the pun,
>> I'm enJOYing a lot and stumbled upon this function to find neighbors
>> of a location in a 2D matrix:
>
> Glad you like the book [careful avoidance of pun intended]!
>
>> (defn neighbors
>>   ([size yx] (neighbors [[-1 0] [1 0] [0 -1] [0 1]] size yx))
>>   ([deltas size yx]
>>     (filter (fn [new-yx]
>>               (every? #(< -1 % size) new-yx))
>>      (map #(map + yx %) deltas
>>
>> This syntax made me scratch my head since I believe it was the first
>> time I saw it. However, upon closer analysis it seems it could be
>> rewritten like this, yielding the same result:
>>
>> (defn neighbors-1 [size yx]
>>   (let [deltas [[-1 0] [1 0] [0 -1] [0 1]]]
>>     (filter (fn [new-yx]
>>               (every? #(< -1 % size) new-yx))
>>       (map #(map + yx %) deltas
>>
>> The second version feels a lot easier on my eyes. Am I missing
>> something or they are really equivalent? And if so, why is the first
>> syntax supported or better yet, when is it best to use it?
>
> The main difference is that the first version allows you to pass in
> your own deltas.  This could be useful if you wanted to include
> diagonals as neighbors.  We don't think we take advantage of the
> flexibility anywhere in the book, so perhaps your version would indeed
> be better.
>
> --Chouser
>
> --
> 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 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