Re: Map Keys are functions, why not vector elements?

2017-11-18 Thread Alex Baranosky
Practically speaking, Java numbers cannot be extended with the IFn
interface to make this possible.

On Mon, Nov 13, 2017 at 9:15 AM, Alex Miller  wrote:

> Regarding the title, this is incorrect. Map keys are not functions;
> keywords are functions that take an associative data structure and will
> look themselves up in it. So, the premise here is not even correct to start.
>
> Usually we prefer to work by starting from a problem and consider
> alternatives, but as you state below, you don't have a problem in mind.
>
>
> On Monday, November 13, 2017 at 3:49:41 AM UTC-6, Stephen Feyrer wrote:
>>
>> Hi there,
>>
>> This is possibly a silly question (and may have been asked before but I
>> couldn't find earlier examples) so here it goes.
>>
>> We start with a form which we're all familiar with:
>>
>> user=> (:this {:this "is" :the "same"})
>> "is"
>>
>>
>> Then it's not a stretch to go to:
>>
>> user=> (def the 1)
>> #'user/the
>> user=> (nth [1 "is" the :same] 1)
>>
>> "is"
>>
>>
>> Here's where it gets tricky as we enter the land of make believe and
>> what-if?
>>
>> I suggest a special form where vector elements could be treated like
>> functions in a manner similar to maps keys.  As this is purely
>> hypothetical there might be better ways of representing this:
>>
>> Get the nth element of the vector
>>
>> user=> (3 [1 "is" the :same])
>> :same
>>
>>
>>
> Note that you can do something similar now with:
>
> ([1 "is" the :same] 3)
>
> Whereas in the situation with maps, keywords (a specific common key type)
> are functions, here you are implying that anything could implicitly be
> invokable as a lookup function on an associative data structure. This
> doesn't make a lot of sense to me and would undoubtedly have performance
> effects. Maybe there is some case like `(map 1 [[:a 0] [:b 1] [:c 2]])`
> where this would make sense. But this doesn't make sense for all indexed
> data structures, just those indexed by longs. Layering invocability on
> longs would require special handling in the compiler (Keywords are a type
> that embeds this by implementing IFn naturally, so it's not a special case).
>
>
>> Get the nth element of the vector
>>
>> user=> (2 [1 "is" the :same])
>> 1
>>
>>
>> Get the nthiness of an element in the vector
>>
>> user=> (::same [1 "is" the :same])
>> 3
>>
>>
> This is something completely different - a linear search for a match.
> Clojure has considered and rejected making linear searching easier multiple
> times. It's almost always a sign that you are using the wrong data
> structure in the first place and should be using a hashed data structure
> instead. There is no chance we would do something like this.
>
>
>>
>> Get the nthiness of an element in the vector
>>
>> user=> (:the [1 "is" the :same])
>> 2
>>
>>
>> Get the nthiness of an element in the vector
>>
>> user=> (:1 [1 "is" the :same])
>> (0 2)
>>
>>
> I don't even understand what is intended here.
>
>
>> Taking things further into the realms of really you should have stopped
>> there!
>>
>> Get the these element of the vector
>>
>> user=> ((1 3) [1 "is" the :same])
>> ("is" :same)
>>
>>
>> Just for fun I tried:
>>
>> user=> ((:this :the) {:this "is" :the "same"})
>>
>>
>>
>> NullPointerException   user/eval786 (NO_SOURCE_FILE:1)
>>
>>
>>
>> I may be barking up the wrong tree or possibly just barking...  I hope
>> what I'm asking makes some sort of sense.
>>
>
> Not particularly.
>
>
>> By way of apology to the reader, when I began writing this question it
>> was ill thought out and seemed a lot simpler.  As a disclaimer, I can't
>> think of direct examples how this would improve readability or such or even
>> necessarily be useful.
>>
>
> Seems like that should have been a sign. :)
>
>
>> Though, that being said, I do believe that there people who'd make good
>> use of such a feature, though I don't know who they are either but I'm
>> hoping you're reading this ;)
>>
>> My parting shot, I have a guess as to why things are the way they are but
>> that is completely in substantiated and lacks in even the most basic
>> rationality as I also guess as to why my guess might not be true... :(
>>
>>
>> --
>> Warning!  If you question everything the answer you'll get is
>> "EVERYTHING!"
>>
>> Stephen.
>>
> --
> You 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: calling a clojure function within a quote/(')

2017-11-18 Thread Alex Baranosky
Also:

(cond-> query
true
(conj ['? :data/number '?number])
true
(conj [(list '> '?number (foo 2))]))

;; => [:find ?e :in $ :where w [? :data/number ?number] [(> ?number 3)]]

On Fri, Nov 17, 2017 at 8:44 PM, Matching Socks 
wrote:

> In the docs: "syntax quote" on https://clojure.org/reference/reader
>
> --
> You 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: Grateful Appreciation

2017-11-03 Thread Alex Baranosky
Clojure is amazing, and at this point I couldn't imagine life without
Clojure. (I guess I'd have to become a Common Lisp guy if Clojure fell off
the face of the Earth, hehe)

Clojure and Rich's talks have over the years totally changed my thinking on
creating software.

Thanks for all the work thats gone into it :)

On Wed, Nov 1, 2017 at 7:33 PM, Wei Hsu  wrote:

> I want to say the same. I've been using Clojure for nearly a decade and it
> remains my favorite language to work in, largely thanks to the ecosystem
> and wonderful community. Keep up the good work!
>
> --
> You 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: Predicates for atom/ref/agent

2017-08-05 Thread Alex Baranosky
Do we want a predicate for every interface? I, for one, DEFINITELY do not.
Just make some utils if you need to check for (instance? IAtom x) a lot in
your application. All such fns do is bloat clojure.core.

On Sun, Jul 16, 2017 at 5:24 PM, Alex Miller  wrote:

> The decisions for volatile? vs other predicates were made at different
> times so I don't think there is necessarily any guiding design principle
> behind having one vs not having the other. I wrote the volatile addition,
> but I don't remember any of the details around why we included volatile? at
> that time.
>
> The broader question is, do we need a predicate for every interface? Is
> this worth having vs just #(instance? clojure.lang.IAtom %). One reason a
> predicate can be useful is for portability with ClojureScript, so I think
> that adds a little more weight to atom? (and none for ref? or agent?).
>
> Another question is where this would be useful - what could do you
> envision where it's helpful to have it. If it's not common, then it's not
> worth having yet another function in core that needs to be loaded.
>
> And another question is how prevalent this function is "in the wild"
> either as a predicate or even more interestingly as something else.
> clojure.inspector and cider.nrepl actually have an atom? that is more of
> the traditional lisp/scheme sense of a non-collection. I see other impls of
> atom? in places like plumatic schema, taoensso encore, hara.common.checks,
> seesaw, and many others. (All of those impls are actually dated in that
> they check for the concrete class Atom rather than the interface IAtom that
> was introduced in 1.7.). See https://crossclj.info/clojure/atom%3F.html
> for more definitions.
>
> Having many existing impls of this function out there means that we either
> introduce warnings, or worse we actually introduce a core function that has
> different semantics - there are many similar functions that instead check
> for Atom, and some that do something entirely different.
>
> Weighing all this, I can't say that adding atom?, ref? (likely to have way
> more conflicts with different semantics), or agent? seems like a big win to
> me and is certainly not problem-free. When we added volatile?, that was not
> an existing overlap with many (or maybe any) existing functions out in the
> wild so was a little easier from that perspective.
>
> On Sunday, July 16, 2017 at 3:38:47 PM UTC-5, Shantanu Kumar wrote:
>>
>> Hi,
>>
>> Since Clojure 1.7 there's a `volatile?` predicate function, but no such
>> equivalent for atom/ref/agent. Can anybody explain the rationale behind the
>> difference? I found an old thread on a related topic (URL below) but would
>> like to know if there's an updated explanation.
>> https://groups.google.com/forum/#!topic/clojure/mIJK3x_SUyM
>>
>>
>> Shantanu
>>
> --
> You 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: How is this code to create a stateful lazy sequence?

2017-08-05 Thread Alex Baranosky
My version of distinct-by just took clojure.core/distinct and added a keyfn
(and optional max-n). It's hard to claim this code is readable. I took this
approach mostly because I knew it would be unlikely to be buggy, since it
was a simple change or two from clojure.core/distinct

(defn distinct-by
  "Like distinct, but calls keyfn to determine distinctness, much like
sort-by.
   Takes an optional max-n, indicating how many duplicates are acceptible."
  ([keyfn coll]
 (distinct-by keyfn 1 coll))
  ([keyfn max-n coll]
 (let [step (fn step [xs seen]
  (lazy-seq
   ((fn [[f :as xs] seen]
  (when-let [s (seq xs)]
(if (>= (get seen (keyfn f) 0) max-n)
  (recur (rest s) seen)
  (cons f (step (rest s) (update-in seen [(keyfn
f)] (fnil inc 0)))
xs seen)))]
   (step coll {}

On Sun, Jul 23, 2017 at 8:25 PM, Rob Nikander 
wrote:

> Yes, I find that much clearer too. Thanks!
>
> On Saturday, July 22, 2017 at 4:50:23 PM UTC-4, tbc++ wrote:
>>
>> If we think about what we're doing here is a stateful filter, then maybe
>> we could leverage a few more core Clojure functions:
>>
>>
>> (defn distinct-by [f coll]
>>   (let [seen (atom #{})]
>> (filter (fn [itm]
>>(let [m (f itm)]
>>   (when-not (@seen m)
>> (swap! seen conj m
>>  coll)))
>>
>> --
> You 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.


ThreatGRID/Cisco Looking for Clojure Developers (again)

2017-02-27 Thread Alex Baranosky
[ Full disclosure: I am the technical lead on this product and the hiring
manager in this case. Feel free to contact me with questions, and to pass
this gist around:
https://gist.github.com/AlexBaranosky/7cb700d032d26946e9587a599f5aa80c ]

Clojure Developer for Malware Analysis Product

The ThreatGRID team at Cisco is looking for experienced clojure developers
to
work on our large scale, malware analysis product. Our entire platform is
built
on Clojure, from the the API services, around the event processing
subsystem,
and down to the core.logic analysis engine.

Our system runs as a distributed cluster in the cloud, and shrunk down to a
single on-premises appliance. This keeps us focused on simple solutions,
clear
abstractions between services, composition of services, functional data
processing, and minimal state.

We are analyzing 300k+ malware files a day, and will be scaling to millions
a
day as we integrate more with the Cisco product line. We need experienced
hands
in executing this scaling task.

Our team is distributed across the U.S. and works from home with occasional
office visits and travel -- this requires excellent written communications,
self-confidence, trust in your co-workers, and assuming ownership of the
problems you encounter.

We work with these technologies:

 * Clojure, core.logic, riemann
 * ElasticSearch
 * PostgreSQL
 * Redis

We are looking for experience in some of the following problem domains:

 * Web Services Scaling -- Ok, but what happens if 2 million devices ask
that
   question?

 * Cloud Deployment -- A herd of containers, a society of JVMs. Multiple
data
   centers.

 * DevOps -- Developers and Operators working together to reduce mean-time
to
   discovery and remediation.

 * System Monitoring and Alerting -- Kiries is Kibana, Riemann and
Elasticsearch

 * Data Modeling -- Applied JSON epistemology in a world of hostile actors

 * Micro-Services Architecture -- Towards NetFlix OSS, but in a Clojure way.

 * Continuous Integration/Deployment -- Keep it green, push the button to
deploy

We offer:

 * An endless supply of interesting problems, and people to solve them with

 * Work in one of the fastest growing product lines in Cisco

 * Competitive salary and benefits to support a stable, high-quality life
   outside of work

 * Decades of collective experience with Clojure and Common Lisp

 * Support in developing your skills and talents, we love to help each other
   grow

 * Work from home, or a Cisco office, as you please.

# CONTACT

Email - j...@threatgrid.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.


ThreatGRID/Cisco Looking for Clojure Developers

2016-09-27 Thread Alex Baranosky
[ Full disclosure: I am the technical lead on this product and the hiring 
manager in this case. Feel free to contact me with questions, and to pass 
this around. ]

Clojure Developer for Malware Analysis Product

The ThreatGRID team at Cisco is looking for experienced clojure developers 
to
work on our large scale, malware analysis product. Our entire platform is 
built
on Clojure, from the the API services, around the event processing 
subsystem,
and down to the core.logic analysis engine.

Our system runs as a distributed cluster in the cloud, and shrunk down to a
single on-premises appliance. This keeps us focused on simple solutions, 
clear
abstractions between services, composition of services, functional data
processing, and minimal state.

We are analyzing 300k+ malware files a day, and will be scaling to millions 
a
day as we integrate more with the Cisco product line. We need experienced 
hands
in executing this scaling task.

Our team is distributed across the U.S. and works from home with occasional
office visits and travel -- this requires excellent written communications,
self-confidence, trust in your co-workers, and assuming ownership of the
problems you encounter.

We work with these technologies:

 * Clojure, core.logic, riemann
 * ElasticSearch
 * PostgreSQL
 * Redis

We are looking for experience in some of the following problem domains:

 * Web Services Scaling -- Ok, but what happens if 2 million devices ask 
that
   question?

 * Cloud Deployment -- A herd of containers, a society of JVMs. Multiple 
data
   centers.

 * DevOps -- Developers and Operators working together to reduce mean-time 
to
   discovery and remediation.

 * System Monitoring and Alerting -- Kiries is Kibana, Riemann and 
Elasticsearch

 * Data Modeling -- Applied JSON epistemology in a world of hostile actors

 * Micro-Services Architecture -- Towards NetFlix OSS, but in a Clojure way.

 * Continuous Integration/Deployment -- Keep it green, push the button to 
deploy

We offer:

 * An endless supply of interesting problems, and people to solve them with

 * Work in one of the fastest growing product lines in Cisco

 * Competitive salary and benefits to support a stable, high-quality life
   outside of work

 * Decades of collective experience with Clojure and Common Lisp

 * Support in developing your skills and talents, we love to help each other
   grow

 * Work from home, or a Cisco office, as you please.
 
# CONTACT

Email - j...@threatgrid.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help with idiomatic clojure.

2015-11-12 Thread Alex Baranosky
The main thing to note is to not use atoms for things like this. Colin's
cond-> approach is a good idea.

On Thu, Nov 12, 2015 at 4:08 PM, Colin Yates  wrote:

> One other minor point (if (seq some-sequence) true false) is preferred by
> some (I won’t say more idiomatic) than (if (empty? some-sequence) true
> false). Also, in no-errors branch you probably want to return status: 200?
>
>
> On 12 Nov 2015, at 19:44, Brian  wrote:
>
> Thanks Colin, Thanks Erik
> Exactly what I was looking for.
>
> I've updated the gist with Colin's suggestion and a bit of destructuring.
> If this project gets any bigger I will definitely look at vlad
>  and Prismatic Schema
> .
>
> BDF.
>
> On Thu, Nov 12, 2015 at 12:02 PM, Erik Assum  wrote:
>
>> There is also https://github.com/logaan/vlad which helps with
>> validation.
>>
>> Erik.
>> --
>> i farta
>>
>> Den 12. nov. 2015 kl. 17.12 skrev Colin Yates :
>>
>> A nicer equivalent form would be:
>>
>> (cond-> []
>>   this-error? (conj “It failed with this error”)
>>   that-error? (conj “It failed with that error”))
>>
>> However, purely for validation there are a few utilities out there
>> already. Checkout the ‘Validation’ section on
>> http://www.clojure-toolbox.com
>>
>> Also, in terms of enforcing contracts - Prismatic Schema is highly
>> recommended but hard to ‘englishify’ the errors. Failures are considered
>> API failures rather than happy-case failures.
>>
>> On 12 Nov 2015, at 16:09, Brian Forester 
>> wrote:
>>
>> I'm writing a very small REST application in clojure using compojure and 
>> ring.  One problem is that I don't have anyone who can review my work or 
>> provide feedback.
>>
>>
>> I've written a small function to validate a simple JSON request.  I'm 
>> validating the three values that are in the post and collecting the errors 
>> for return.
>>
>> The core mechanic I've used
>>
>>  (swap! errors str "'grepString' must not be null or empty.\n"))
>>
>> does not seem to be a very idiomatic clojure way to solve this simple 
>> problem.
>>
>>
>> https://gist.github.com/BDF/8e61daf8fe8b602a248a
>>
>>
>> Any feedback is appreciated.
>>
>> BDF.
>>
>>
>>
>>
>> --
>> You 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.
>>
>
>
> --
> You 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 

ThreatGRID/Cisco Looking for Clojure Developers

2015-10-22 Thread Alex Baranosky
I'm a senior Clojure developer on the Advanced Threat Integration Team in
Cisco's
Security Business Group. We have a fully remote team, with people spread
all across
the US.

The Advanced Threat Integration Team in Cisco's Security Business
Group is building a global scale, multi-product security platform with
an emphasis on Threat Intelligence and Incident Response support.

Our system runs as a distributed cluster in the cloud, and shrunk
down to a single on-premises appliance.  This keeps us focused on
simple solutions, clear abstractions between services, composition of
services, functional data processing, and minimal state.

Our team is distributed across the U.S. and works from home with
occasional office visits and travel -- this requires excellent written
communications, self-confidence, trust in your co-workers, and
assuming ownership of the problems you encounter.


We are looking for experience in some of the following problem domains:

 * Web Services Scaling -- Ok, but what happens if 2 million devices
   ask that question?

 * Cloud Deployment -- A herd of containers, a society of JVMs

 * DevOps -- Developers and Operators working together to reduce
   mean-time to discovery and remediation

 * Applied Machine Learning -- Fancy word for statistics, optimization
   and linear algebra

 * Data Modeling -- Applied JSON epistemology in a world of hostile
   actors

 * System Monitoring and Alerting -- Kiries is Kibana, Riemann and
   Elasticsearch

 * Micro-Services Architecture -- Towards NetFlix OSS, but in a
   Clojure way

 * Continuous Integration/Deployment -- Keep it green, push the button
   to deploy

We offer:

 * An endless supply of interesting problems, and people to solve them
   with

 * Work in one of the fastest growing product lines in Cisco

 * Competitive salary and benefits to support a stable, high-quality
   life outside of work

 * Decades of collective experience with Clojure and Common Lisp

 * Support in developing your skills and talents, we love to help each
   other grow

 * Work from home, or a Cisco office, as you please

# Senior Clojure Developer

## Role
 * Design and implement RESTish API services
 * Develop a multi-product data exchange platform
 * Support other teams integration with that platform

## Requirements
 * Experience with Clojure, Ruby and other JVM languages
 * Experience designing domain-driven data models
 * Experience with large scale data processing systems
 * Experience with ElasticSearch
 * Experience with CQRS/ES is a plus
 * Experience with Kafka, Onyx or Storm is a plus


Contact: j...@threatgrid.com

See the rest of our job listings here:
https://gist.github.com/AlexBaranosky/bad552de30b9001fbc04

-- 
You 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] Dunaj project, an alternative core API for Clojure

2015-03-05 Thread Alex Baranosky
Yeah, I'm excited to see some of the 10 write-ups. What's the ETA on the
first one?

On Thu, Mar 5, 2015 at 6:02 PM, Alex Miller a...@puredanger.com wrote:

 I'm happy to see experiments if we can learn something useful. Can't
 really judge more till the posts are out. Seems perfectly possible that
 something promising could get a design page and move towards inclusion in
 some way.

 Alex

 --
 You 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] Dunaj project, an alternative core API for Clojure

2015-03-05 Thread Alex Baranosky
Where is this example project?

On Thu, Mar 5, 2015 at 7:40 PM, Ivan L ivan.laza...@gmail.com wrote:

 Just a quick glance at the example project shows integrated type
 definitions.  I'm curious for sure.

 --
 You 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] print.foo 1.0.0 - library of print debugging macros

2014-11-20 Thread Alex Baranosky
Hi guys,

I've further refined my print.foo project, and thought I'd share the latest
version here with you all. I get a ton of mileage out of the library
personally and professionally using it everyday to enhance my repl-driven
development.

Here some highlights from the README (you can read a complete set of
examples on the Github README @
https://github.com/AlexBaranosky/print-foo#usage):

print.foo= (print-sexp (str (+ 3 4) (+ 5 (* 6 2)) 4))
3 3
4 4
(+ 3 4) 7
5 5
6 6
2 2
(* 6 2) 12
(+ 5 (* 6 2)) 17
4 4
(str (+ 3 4) (+ 5 (* 6 2)) 4) 7174


print.foo= (print- 1 inc dec inc dec)
1 1
inc 2
dec 1
inc 2
dec 1
1


print.foo= (print-cond- {}
  (pos? 1)
  (assoc :a 1)

  (pos? 2)
  (merge {:b 2})

  (neg? 2)
  (merge {:c 3}))
test: (pos? 1)  value: {:a 1}
test: (pos? 2)  value: {:a 1, :b 2}
{:b 2, :a 1}


print.foo (middleware-
{:get-in [:session]
 :timings? true}}
my-handler
wrap-exception-handling
wrap-params)

(defn m1 [x]
  (println x)
  x)
(defn m2 [x]
  (fn [y]
(x (assoc y :m2 true
(defn m3 [x]
  (fn [y]
(x (assoc y :m3 true

((middleware- {:timings? false
:get-in [:session]}
   m1
   m2
   m3)

 {:session {:token 1}})

;; prints:

REQUEST - GOING INTO: m3
{:token 1}
REQUEST - GOING INTO: m2
{:token 1}
{:m2 true, :m3 true, :session {:token 1}}
RESPONSE - COMING OUT OF: m2
{:token 1}
RESPONSE - COMING OUT OF: m3
{:token 1}

-- 
You 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: style question on tightly coupled functions

2014-11-20 Thread Alex Baranosky
I'd structure my app like this.

Say there's one pages ns with code for different webpages

pages/index is a pretty short function
pages/dashboard is a more elaborate function and has two subcomponents:
-analytics, and -user-info
pages.analytics/-analytics
pages.user-info/-user-info

On Thu, Nov 20, 2014 at 9:23 AM, Tassilo Horn t...@gnu.org wrote:

 henry w henryw...@gmail.com writes:

  you have understood my arguments pretty much. again the thing that
  bothers me is that f and g are logically part of x only, but are
  visible from y and z (even if and and y are declared higher up, the
  same problem applies to their own related, private fns and x).

 Then declare f and g inside of x using `let' or `letfn'.

 Bye,
 Tassilo

 --
 You 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: style question on tightly coupled functions

2014-11-20 Thread Alex Baranosky
letfn has no value imo. It is an unwritten stylistic rule I have to never
use it.  Why introduce a new macro syntax for something that could just as
easily be written as?:

(let [f1 (fn [] ...)
   f2 (fn [] ...)]
  (+ (f1) (f2)))


On Thu, Nov 20, 2014 at 12:41 PM, henry w henryw...@gmail.com wrote:

 I never heard of letfn before. that looks like a clear way to do what i
 need.

 just found this stackoverflow thread which is relevant:
 http://stackoverflow.com/questions/23255798/clojure-style-defn-vs-letfn

 On Thu, Nov 20, 2014 at 3:34 PM, Alex Baranosky 
 alexander.barano...@gmail.com wrote:

 I'd structure my app like this.

 Say there's one pages ns with code for different webpages

 pages/index is a pretty short function
 pages/dashboard is a more elaborate function and has two subcomponents:
 -analytics, and -user-info
 pages.analytics/-analytics
 pages.user-info/-user-info

 On Thu, Nov 20, 2014 at 9:23 AM, Tassilo Horn t...@gnu.org wrote:

 henry w henryw...@gmail.com writes:

  you have understood my arguments pretty much. again the thing that
  bothers me is that f and g are logically part of x only, but are
  visible from y and z (even if and and y are declared higher up, the
  same problem applies to their own related, private fns and x).

 Then declare f and g inside of x using `let' or `letfn'.

 Bye,
 Tassilo

 --
 You 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: style question on tightly coupled functions

2014-11-20 Thread Alex Baranosky
Imo, that makes the let version even better. The Clojure compiler doesn't
to allow circular dependencies, so I would consider the letfn behavior as
surprising and therefore unideal.

On Thu, Nov 20, 2014 at 2:21 PM, Dan Girellini d...@longhands.org wrote:

 Using letfn allows the local functions to reference each other
 arbitrarily. In your example, f2 can call f1 but not vice versa.

 On Thu, Nov 20, 2014 at 11:08 AM, Alex Baranosky 
 alexander.barano...@gmail.com wrote:

 letfn has no value imo. It is an unwritten stylistic rule I have to never
 use it.  Why introduce a new macro syntax for something that could just as
 easily be written as?:

 (let [f1 (fn [] ...)
f2 (fn [] ...)]
   (+ (f1) (f2)))


 On Thu, Nov 20, 2014 at 12:41 PM, henry w henryw...@gmail.com wrote:

 I never heard of letfn before. that looks like a clear way to do what i
 need.

 just found this stackoverflow thread which is relevant:
 http://stackoverflow.com/questions/23255798/clojure-style-defn-vs-letfn

 On Thu, Nov 20, 2014 at 3:34 PM, Alex Baranosky 
 alexander.barano...@gmail.com wrote:

 I'd structure my app like this.

 Say there's one pages ns with code for different webpages

 pages/index is a pretty short function
 pages/dashboard is a more elaborate function and has two subcomponents:
 -analytics, and -user-info
 pages.analytics/-analytics
 pages.user-info/-user-info

 On Thu, Nov 20, 2014 at 9:23 AM, Tassilo Horn t...@gnu.org wrote:

 henry w henryw...@gmail.com writes:

  you have understood my arguments pretty much. again the thing that
  bothers me is that f and g are logically part of x only, but are
  visible from y and z (even if and and y are declared higher up, the
  same problem applies to their own related, private fns and x).

 Then declare f and g inside of x using `let' or `letfn'.

 Bye,
 Tassilo

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


-- 
You 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: style question on tightly coupled functions

2014-11-20 Thread Alex Baranosky
Sean James, yes of course there are times that it is _needed_. Agreed.

I just would never opt for using tools like declare and letfn as the _go to
tool_.  I think of cyclic dependencies as less simple, harder to grok etc.
When you need it, by all means have the power to do so, but when you don't
need it, then no need for adding extra mental weight for code-readers to
have to go through to understand your code.

On Thu, Nov 20, 2014 at 2:41 PM, James Reeves ja...@booleanknot.com wrote:

 On 20 November 2014 19:33, Alex Baranosky alexander.barano...@gmail.com
 wrote:

 Imo, that makes the let version even better. The Clojure compiler doesn't
 to allow circular dependencies, so I would consider the letfn behavior as
 surprising and therefore unideal.


 It does, via declare. This is often necessary in parsers, as often
 languages have some form of recursive definition (e.g. expressions can be
 nested in expressions).

 The letfn macro allows for local mutual recursion and is sometimes
 necessary.

 - James

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You 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: Modelling in Clojure

2014-10-19 Thread Alex Baranosky
I've maintained 5+ year-old Clojure applications and the Uniform Access
Principle was not a concern for me.

Bigger concerns for me were the Single-Responsibility Principle, and
conversely, the Big Ball of Mud Anti-pattern. But I think these are both
concerns on any large, old program in any language.

On Sat, Oct 18, 2014 at 10:35 PM, Brandon Bloom brandon.d.bl...@gmail.com
wrote:

 I don't know who is the outlier. The point is that Scala, for instance,
 has explicit support to hide the distinction between accessing a value
 and computing a value. The point is to support the uniform access
 principle.

 http://en.wikipedia.org/wiki/Uniform_access_principle


 In one sense, accessing data and calling functions uniform: keyword
 lookups are just function calls themselves. In another sense, lookup by
 keyword requires implementing ILookup etc rather than changing a simple
 function.

 If you take the stance that the data is your API (and you should), then it
 makes sense that switching from a keyword lookup to a function call is a
 breaking change! It shouldn't be easy to rip the data-rug out from under
 your callers. At least it *is* possible, depending on how far you're
 willing to go down the Clojure interfaces rabbit hole. Of course, this
 equation changes even more in favor of Clojure's keywords approach if your
 client lives across the network.

 That said, if you're not sure if you want to make the data your API, you
 can reserve the right to change your mind later quite easily. Let's say you
 have (ns user) and want to create a username function:

 (def username :username) ; tada!

 Yes, this requires some foresight. Back in my C# days, the guidance was
 always make everything a property. That was especially important if you
 cared about binary compatibility, since changing from a readonly field to
 a getter was a breaking ABI change. But you know what, over quite a few
 major and minor releases of our widely used APIs, I don't recall ever once
 changing from a trivial `return foo` getter to more complex getter logic.
 The expectation that a getter is a simple data read was always a core part
 of the public interface.

 --
 You 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: Using an atom for a caching map

2014-09-01 Thread Alex Baranosky
I believe you can replace:
(when-not (contains? @cache k)
  (swap! cache assoc k (calc-value* k

with:
(swap! cache (fn [cache']
   (if (contains? cache' k)
 cache'
 (assoc cache' k (calc-value* k)

Note: I haven't run this code


On Mon, Sep 1, 2014 at 2:20 AM, Colin Fleming colin.mailingl...@gmail.com
wrote:

 Hi Thomas,

 Normally I'd agree with you, but in my case it actually works quite well
 since I don't need to expire or worry about sizing. This is for caching
 objects on IntelliJ parse tree elements, and the element with its cached
 values is thrown away every time the document is parsed, so these are
 pretty transient caches. In this particular case the calculation isn't too
 heavyweight either so recalculating it in the unlikely event of contention
 isn't a big deal. In fact, this discussion and the related thinking has
 made me realise that my original solution was actually sufficient for my
 somewhat strange use case, which is nice :-). For more typical server side
 caching, I agree that Guava would be a great solution.

 Cheers,
 Colin


 On 1 September 2014 20:54, Thomas Heller th.hel...@gmail.com wrote:

 As much as I like Clojure and atoms, I do not think they are a good fit
 for caching. Not only is it impossible to address the concurrency issues
 related to multiple threads loading the same object, but you also have to
 do expiration and size management yourself. Immutability doesn't help much
 for caching either. There is core.cache that does some bits but I probably
 would recommend using something like CacheBuilder from the guava libs:

 See
 https://code.google.com/p/guava-libraries/

 http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html

 Its Java but the Clojure-Java interop is so good that it doesn't matter
 much.

 On Saturday, August 30, 2014 7:27:05 AM UTC+2, Colin Fleming wrote:

 Hi all,

 I want to use a map to cache values based on a key. I'm planning to use
 an atom for this. My basic operation is give me the value for this key -
 if the value exists in the map then that value should be returned,
 otherwise a new value should be calculated, inserted in the map and then
 returned. My plan is to implement something like the following:


 (defn ensure [cache key]  (if (contains? cache key)cache(assoc 
 cache key (calc-value key(let [value (get (swap! cache ensure key) 
 key)]  ... do my thing with value ...)


 So 'ensure' ensures that the cache contains the value for key, the swap!
 operation returns the cache with the value and then I get it out. This
 works but feels a little clumsy, is there a better way to do this?

 Also, looking at the Atom source code, I see that this will cause a CAS
 operation even if the value returned from swap! is identical to the
 original value. It seems like a reasonable optimisation would be to check
 if the values are identical and not update if so - is there a reason this
 might not be a good idea?

 Thanks,
 Colin

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

Re: Why is this an Exception ?

2014-08-31 Thread Alex Baranosky
There is no pot of gold at the end of the no-namespacing rainbow. Only
sadness. :'(


On Sat, Aug 30, 2014 at 9:29 AM, Andy Fingerhut andy.finger...@gmail.com
wrote:

 How would another Lisp avoid giving you an error when referring to a
 symbol that has no value?

 If you just want your entire program in a single namespace, and don't want
 to use any libraries in other namespaces, then simply don't use the /
 character in your symbol names.

 If you want to use the symbols in other namespaces without a namespace/
 prefix in front of them, you can use a declaration like this:

 (ns my.namespace.name
   (:require [other.namespace :refer :all]
  [yet.another.namespace :refer :all]))

 Then you can use the names of public symbols from other.namespace and
 yet.another.namespace in your code without the namespace prefix.

 Andy


 On Sat, Aug 30, 2014 at 1:02 AM, Sreeharsha Mudivarti 
 msreehar...@gmail.com wrote:



 On Saturday, August 30, 2014 12:34:24 AM UTC+5:30, Ashton Kemerling wrote:

 Bar/baz refers to the symbol baz in the namespace bar. If you haven't
 created and imported bar, that's an error.


 This feels too java-ish for a lisp.
 Can I avoid this by some form of declaration ?


  --
 You 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: How can I add meta to an object that doesn't implement IObj?

2014-08-30 Thread Alex Baranosky
The only way to do this is to wrap the object in something that implements
IObj. But at that point you might as well wrap it in a regular hashmap and
just wrap it in real data.


On Sat, Aug 30, 2014 at 1:54 AM, Atamert Ölçgen mu...@muhuk.com wrote:

 Hi François,

 Thanks for the links.

 I can't really pass a list since the first function is expecting the
 object I am passing, then it calls some other functions that were supposed
 to extract the meta. The problem is, functions that are called later can be
 executed in a different thread.



 On Sat, Aug 30, 2014 at 4:29 PM, François Rey fmj...@gmail.com wrote:

  On 30/08/14 05:15, Atamert Ölçgen wrote:

  Obviously I can't.

  But I need to add this capability to an object. During testing I attach
 meta to this object that contains an atom. Then I pass this object to other
 functions, known in runtime. I can't use a dynamic var because all this
 happens within a mock function that may be retried and run in different
 threads.

 In my case I used a list, e.g. (list obj), and used destructuring on the
 other side when needed, e.g. [obj :as wobj].


  I have seen this:
 http://stackoverflow.com/questions/20724219/simplest-possible-clojure-object-that-can-accept-a-primitive-and-metadata
 but can't deref it since I can't change the functions that will use it
 later. If I wrap this object I need to be able to delegate all of its
 functionality to the original object.

 I don't think there's a quick solution without changing the contract.
 Whatever solution is chosen you need to keep in mind how this will affect
 things like equality, hashing, and instanceof?
 Perhaps these links could be a start:
 https://groups.google.com/forum/#!topic/clojure/9zCGdW_Q7o8

 http://stackoverflow.com/questions/9086926/create-a-proxy-for-an-specific-instance-of-an-object-in-clojure
 Also, if the meta data is just for you own use, then you might want to
 store it yourself in a map with weak references, or just use WeakHashMap
 http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
 directly. But then you'll be stateful...

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




 --
 Kind Regards,
 Atamert Ölçgen

 -+-
 --+
 +++

 www.muhuk.com

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You 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: positional + keyword args

2014-07-20 Thread Alex Baranosky
You can get keyword args like this:

(defn f [ {:keys [a b c d]
:or {a 1 b 2 c 3 d 4}}]
  [a b c d])

But you cannot also get the ability to call:
(f 5 6 7 8)


On Sun, Jul 20, 2014 at 4:13 PM, Sam Raker sam.ra...@gmail.com wrote:

 I'm trying to write a function that takes (up to) 4 arguments. I want to
 be able to supply every argument positionally, with a keyword or as a
 default, so that

 (f)
 (f 1)
 (f 1 2)
 (f 1 2 3)
 (f 1 2 3 4)
 (f 1 :b 2)
 (f 1 2 :c 3)
 ...
 (f :a 1 :b 2 :c 3 :d 4)

 are all equivalent. In Python, I could do this by

 def f(a=1,b=2,c=3,d=4):...

 but I'm not sure how to do it in Clojure.

 --
 You 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: unexpected behavior of clojure.core/empty

2014-07-19 Thread Alex Baranosky
What does `empty` do for non-collection types?:

(empty 1) = nil
(empty 123) = nil
(empty :abc) = nil
(empty (clojure.lang.MapEntry. a 1))

So it is actually very consistent.


On Fri, Jul 18, 2014 at 6:06 PM, Brian Craft craft.br...@gmail.com wrote:

 hm, looks even more broken in the context of these examples.


 On Friday, July 18, 2014 5:04:34 AM UTC-7, Mike Fikes wrote:

 My guess: Perhaps this is a bug, or alternatively, a known issue that
 won't be addressed because to do so would be a breaking change.

 There is an old demo of Clojure given by Rich where MapEntry's were
 printed using some sort of un-readable notation #:foo 5. But clearly
 MapEntry's have been revised to act a lot like 2-element vectors.

 user= (rseq (first (mapv identity {:foo 5})))

 (5 :foo)

 user= (conj (first (mapv identity {:foo 5})) :x)

 [:foo 5 :x]

 user= (assoc (first (mapv identity {:foo 5})) 1 7)

 [:foo 7]

 user= (subvec (first (mapv identity {:foo 5})) 0 1)

 [:foo]


 FWIW, ClojureScript behaves in your expected way:


 (empty (first (mapv identity {:foo 5})))

 = []

  --
 You 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: unexpected behavior of clojure.core/empty

2014-07-19 Thread Alex Baranosky
You cannot have an empty MapEntry though, because map entries always have
just one size, a key and a value. I can definitely see how it can be
confusing though.


On Sat, Jul 19, 2014 at 4:42 PM, Brandon Bloom brandon.d.bl...@gmail.com
wrote:

 I've been bitten by all three of these things in the past:

 1) A MapEntry looks like a vector, but isn't.
 2) Two element vectors can't be used as map entries.
 3) Applying empty to a MapEntry returns nil.

 On Saturday, July 19, 2014 4:04:13 PM UTC-4, Jozef Wagner wrote:

 While the c.l.MapEntry is a persistent vector, there is no such thing as
 an empty MapEntry persistent vector. Returning empty HAMT persistent vector
 instead is not a good solution, as 2 elements HAMT vector does not
 implement IMapEntry interface.

 One approach on how to solve this is in Zach's clj-tuple [1] where every
 2-tuple automatically implements IMapEntry interface.

 [1] https://github.com/ztellman/clj-tuple

 Jozef

 On Saturday, July 19, 2014 9:49:21 PM UTC+2, puzzler wrote:

 As Mike points out, it does seem that MapEntry is considered a
 collection and is designed to emulate a vector so that you don't really
 have to worry about whether you have a MapEntry or a two-element vector
 (and as he points out, in ClojureScript there really is no distinction
 between a MapEntry and a vector).

 With that in mind, I would agree that MapEntry's lack of implementation
 for empty is most likely an oversight, and ideally should behave as if it
 were a vector.




 On Sat, Jul 19, 2014 at 11:46 AM, Mike Fikes mike...@me.com wrote:

 MapEntry is a collection:

 (coll? (clojure.lang.MapEntry. a 1))

 ;= true


 (ancestors (class (clojure.lang.MapEntry. a 1)))

 ;= (a set that includes clojure.lang.IPersistentCollection)


 The docstring for empty implies it would return an empty MapEntry. But
 perhaps since MapEntry is a special collection type that must have a size
 exactly equal to 2, empty must return nil.


 Perhaps ClojureScript will one day introduce a MapEntry type and behave
 the same way as Clojure (ClojureScript currently returns a
 PersistentVector).

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 You 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: Best tools for profiling Clojure programs?

2014-07-03 Thread Alex Baranosky
YourKit works well. I've heard good things about JVisualVM, but don't have
experience using it.


On Thu, Jul 3, 2014 at 12:31 AM, Jakub Holy jakub.h...@iterate.no wrote:

 No, it is not. At least it is available on Mac too.


 On Thursday, July 3, 2014 9:25:44 AM UTC+2, ru wrote:

 Thank you Niels,

 вторник, 1 июля 2014 г., 15:10:42 UTC+4 пользователь Niels van Klaveren
 написал:

 A new option for test purposes is included in JDK 1.7.0_40 and up and is
 called Java Mission Control. It is located in the JDK as /bin/jmc.exe.


 Is this tool only for Windows?


 With it you can connect to a local java process, or remotely through
 RMI, and record all kinds of performance characteristics in a Flight
 Recording. Such a flight recording can be a defined for a limited time, or
 it can buffer the recording to record only the latest x minutes. Overhead
 depends on the monitoring template used, but is typically around 2%. These
 recordings can then be browsed, analyzed and queried in a pretty good
 interface after the recording has been saved.

 To do so, you need to have the following options in your project.clj,
 and run your project on a JDK  1.7.0_40

 :jvm-opts [
 ; add Flight Recording options
 -XX:+UnlockCommercialFeatures
 -XX:+FlightRecorder
 ; add RMI connection (to connect to process remotely or
 running as service/daemon)
 ; this example has NO authentication enabled through the
 RMI port
 -Dcom.sun.management.jmxremote
 -Dcom.sun.management.jmxremote.port=
 -Dcom.sun.management.jmxremote.authenticate=false
 -Dcom.sun.management.jmxremote.ssl=false]


 On Friday, June 20, 2014 3:05:05 PM UTC+2, ru wrote:

 Hi all,

 What performance profiling instrument somebody can recommend for
 Clojure programs and corresponding documents, articles or tutorials. Thanks
 in advance.

 Sincerely,
   Ru

  --
 You 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: Best tools for profiling Clojure programs?

2014-07-03 Thread Alex Baranosky
Woops, posting too late... I typed JVisualVM, but meant to say Java Mission
Control.


On Thu, Jul 3, 2014 at 1:10 AM, Alex Baranosky 
alexander.barano...@gmail.com wrote:

 YourKit works well. I've heard good things about JVisualVM, but don't have
 experience using it.


 On Thu, Jul 3, 2014 at 12:31 AM, Jakub Holy jakub.h...@iterate.no wrote:

 No, it is not. At least it is available on Mac too.


 On Thursday, July 3, 2014 9:25:44 AM UTC+2, ru wrote:

 Thank you Niels,

 вторник, 1 июля 2014 г., 15:10:42 UTC+4 пользователь Niels van Klaveren
 написал:

 A new option for test purposes is included in JDK 1.7.0_40 and up and
 is called Java Mission Control. It is located in the JDK as /bin/jmc.exe.


 Is this tool only for Windows?


 With it you can connect to a local java process, or remotely through
 RMI, and record all kinds of performance characteristics in a Flight
 Recording. Such a flight recording can be a defined for a limited time, or
 it can buffer the recording to record only the latest x minutes. Overhead
 depends on the monitoring template used, but is typically around 2%. These
 recordings can then be browsed, analyzed and queried in a pretty good
 interface after the recording has been saved.

 To do so, you need to have the following options in your project.clj,
 and run your project on a JDK  1.7.0_40

 :jvm-opts [
 ; add Flight Recording options
 -XX:+UnlockCommercialFeatures
 -XX:+FlightRecorder
 ; add RMI connection (to connect to process remotely or
 running as service/daemon)
 ; this example has NO authentication enabled through
 the RMI port
 -Dcom.sun.management.jmxremote
 -Dcom.sun.management.jmxremote.port=
 -Dcom.sun.management.jmxremote.authenticate=false
 -Dcom.sun.management.jmxremote.ssl=false]


 On Friday, June 20, 2014 3:05:05 PM UTC+2, ru wrote:

 Hi all,

 What performance profiling instrument somebody can recommend for
 Clojure programs and corresponding documents, articles or tutorials. 
 Thanks
 in advance.

 Sincerely,
   Ru

  --
 You 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: Kwargs vs explicit parameter map for APIs?

2014-04-30 Thread Alex Baranosky
Thanks James, that's a useful version to experiment with :)


On Wed, Apr 30, 2014 at 12:04 AM, Colin Fleming colin.mailingl...@gmail.com
 wrote:

 After posting this last week I decided to go down the explicit map route,
 and I'm already really glad I did. Amongst other things, it has allowed me
 to have two similar calls easily share their common options and merge in
 the differences. I'm generally a fan of maintaining fairly minimal APIs, I
 don't think I'll be duplicating functions, I don't really see a need - two
 extra braces are just not that much noise for me. I'd rather use Alex's
 last example with the optional map arg than have my-function and
 my-function-from-map everywhere.


 On 30 April 2014 17:55, James Reeves ja...@booleanknot.com wrote:


 On 30 April 2014 06:07, Alex Baranosky alexander.barano...@gmail.comwrote:

 I especially dislike that my non-kwarg fns no-longer can elegantly
 accept no options.  Let me illustrate:

 (defn foo [ {:keys [a b]}]
   [a b])

 (foo :a 1 :b 2)
 (foo)


 You could write:

 (defn foo [ [{:keys [a b]}]]
   [a b])

 (foo {:a 1 :b 2})
 (foo)

 - James

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 You 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: Kwargs vs explicit parameter map for APIs?

2014-04-29 Thread Alex Baranosky
I'm extremely internally torn regarding kwargs.  I use them a lot; I know
they hinder composability; but every time I go back to straight maps for
these kinds of things I really don't like all the extra noise characters
and go back to kwargs.

I feel like I really should be using regular maps for all the good reasons
listed, but in practice I don't. Honestly, I don't usually run into the
composability issues too often, so I'm getting by ok with my indulgence
in kwargs, I suppose.

I especially dislike that my non-kwarg fns no-longer can elegantly accept
no options.  Let me illustrate:

(defn foo [ {:keys [a b]}]
  [a b])

(foo :a 1 :b 2)
(foo)

(defn foo [{:keys [a b]}]
  [a b])

(foo {:a 1 :b 1})
(foo {}) ;; -- unpleasant to my eyes, let me reimplement foo

(defn foo
  This is also pretty gross
  ([]
 (foo {}))
  ([{:keys [a b]}]
 [a b]))

So, yeah, I'm pretty torn.

I like the option of having kwargs for the outer API shell, and explicit
option maps internally.  I've played with that a little as well at work to
some ok success.

Alex



On Tue, Apr 29, 2014 at 8:41 PM, James Reeves ja...@booleanknot.com wrote:

 On 30 April 2014 03:54, Sean Corfield s...@corfield.org wrote:

 I still think the keyword argument approach is far more readable to
 _users_


 Really? It's only an omission of two braces. While readability is
 subjective, I'm not sure how that can be considered to be *far* more
 readable.

 From a purely practical perspective, explicit maps are generally a lot
 easier to work with. To my mind the disadvantages of keyword arguments
 often outweigh the small presentational benefits they have.

 - James

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You 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: How did you learn Clojure?

2014-03-21 Thread Alex Baranosky
Just take it one step at a time.  Learning Clojure likely involves more
paradigm changes than learning languages in the past, which is why learning
those languages seemed easier. I don't think Clojure is inherently harder
than regular OO... in fact I think it is a simpler approach, but one that
requires you to retrain yourself a little.

The way I learned Clojure personally was like this:
1) read some books
2) port a tiny program of mine to Clojure
3) port a slightly bigger one to Clojure
4) get involved in open source and cleanup code and generally do Clojure
coding
5) get a job doing 95% Clojure to learn the nitty gritty stuff.
6) keep doing more open source and learning more from the community as I go

Have fun with it :)


On Thu, Mar 20, 2014 at 11:12 PM, Sean Corfield s...@corfield.org wrote:

 On Mar 20, 2014, at 6:08 PM, Marcus Blankenship mar...@creoagency.com
 wrote:
  So I'm curious: how did you learn Clojure well enough to be proficient
 with it, or how are you working on learning it?

 Initial dabbling: The Joy of Clojure and a REPL. Caveat: it's not really
 an introductory Clojure book but I had past FP experience so I felt I could
 jump in.

 Initial serious learning: Attended Amit Rathore's Clojure Bootcamp - one
 day course for about $300 (if I remember correctly?).

 Follow-on: 4clojure.com, worked through Clojure in Action as well.

 Then I picked a handful of small-ish problems we'd already solved at work
 in other languages and re-coded them in Clojure.

 Since then it's been a steady stream of tackling increasingly larger
 problems at work, over a period of about three years.

  Anyone else facing the focus + fear dilemma?

 There's a lot less fear if you're used to learning new languages. I try to
 pick up a new language every year or two: Groovy in 2008/2009, Scala in
 2009/2010, Clojure in 2010/2011 (and onward). Dabbled in Ruby, Python,
 Haskell since then but nothing serious. Very interested in Elm right now.

 As for focus, yes, you really do need a project. Either pick things
 you've done before in other languages, or figure out something that would
 scratch an itch (a small web app, perhaps?) and tackle that.

 Sean Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org/

 Perfection is the enemy of the good.
 -- Gustave Flaubert, French realist novelist (1821-1880)





-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

2014-03-18 Thread Alex Baranosky
Tests look good in some of Staples Innovation Labs' projects.  Only
failures are ones that assume ordering, which is just an easily correct
failure in the test cases.


On Tue, Mar 18, 2014 at 2:06 PM, David Nolen dnolen.li...@gmail.com wrote:

 Yep, we'll get rid of it once 1.6.0 actually ships.

 David


 On Tue, Mar 18, 2014 at 5:04 PM, Alex Miller a...@puredanger.com wrote:

 I assume that fixing this is a matter of updating src/clj/cljs/core.clj
 in clojurescript to exclude unsigned-bit-shift-right?


 On Tuesday, March 18, 2014 2:52:03 PM UTC-5, Ambrose Bonnaire-Sergeant
 wrote:

 FYI `mvn test` will fail on core.typed because of this issue.

 I believe it otherwise passes.

 Ambrose


 On Wed, Mar 19, 2014 at 3:45 AM, Alex Miller al...@puredanger.comwrote:

 Yeah, that's a thing. I think the name was chosen intentionally to be
 the same across those as cljs had it first.


 On Tuesday, March 18, 2014 2:29:04 PM UTC-5, Ambrose Bonnaire-Sergeant
 wrote:

 I believe this is because cljs.core defines unsigned-bit-shift-right,
 which now conflicts
 with clojure.core/unsigned-bit-shift-right (added with 1.6.0).

 1.6.0 doesn't seem to break anything here, aside from adding to
 clojure.core.

 Thanks,
 Ambrose


 On Wed, Mar 19, 2014 at 3:12 AM, Ambrose Bonnaire-Sergeant 
 abonnair...@gmail.com wrote:

 I think I found a difference between 1.5.1-1.6.0-RC1.

 (compile 'cljs.core) fails with a NPE in 1.6.0-RC1. I realise this
 isn't particularly supported
 by CLJS, but it still worked in 1.5.1.

 https://github.com/frenchy64/clojure-16-fail

 Help narrowing this is appreciated.

 Thanks,
 Ambrose


 On Wed, Mar 19, 2014 at 3:05 AM, Alex Miller al...@puredanger.comwrote:

 Thanks Ken! You're the cheese on my nachos.


 On Tuesday, March 18, 2014 12:45:46 PM UTC-5, Ken Barber wrote:

 We had some bugs related to assumed ordering in our code which
 1.6.0-RC1 surfaced (https://github.com/puppetlabs/puppetdb/pull/887),

 otherwise everything looks good for our project - thanks for all
 the
 hard work on this release.

 ken.

 On Tue, Mar 18, 2014 at 2:21 PM, Alex Miller al...@puredanger.com
 wrote:
  Hello all,
 
  We would love to release Clojure 1.6.0 final soon.
 
  We need your help in checking out the current release candidate -
 this is
  your opportunity to let us know about problems *before* we
 release, rather
  than after.
 
  Try it via
  - Download: http://central.maven.org/maven
 2/org/clojure/clojure/1.6.0-RC1
  - Leiningen: [org.clojure/clojure 1.6.0-RC1]
 
  See the full change log here:
  https://github.com/clojure/clojure/blob/master/changes.md
 
  If you have questions, feel free to drop them here. For issues,
 please log
  them in JIRA.
 
  Alex
 
  --
  You received this message because you are subscribed to the
 Google
  Groups Clojure group.
  To post to this group, send email to clo...@googlegroups.com
  Note that posts from new members are moderated - please be
 patient with your
  first post.
  To unsubscribe from this group, send email to
  clojure+u...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you are subscribed to the
 Google Groups
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it,
 send an
  email to clojure+u...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient
 with your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


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

Re: Adatx - Test driven development... literally.

2014-03-12 Thread Alex Baranosky
There goes my job...


On Wed, Mar 12, 2014 at 8:00 PM, Timothy Washington twash...@gmail.comwrote:

 This looks interesting. I was hammocking a solution that could use that.
 But on Infoq, I recently 
 watchedhttp://www.infoq.com/interviews/byrd-relational-programming-minikanrenWilliam
  Byrd, describing just this feature in MiniKanren.

 As such, I expect to see this feature will be in core.logic. Did you
 explore that path? Was there something missing that prompted Adatx ?

 Many thanks.


 Tim Washington
 Interruptsoftware.com http://interruptsoftware.com


 On Sun, Mar 9, 2014 at 3:13 PM, Ludwik Grodzki grod...@gmail.com wrote:

 ... and here's an example of how it works:

 (def workings
  (adatx/prob-solve
   {
   :symvec['+ '- '* '/ 'x1 'x2]
   :prog-holder   '(fn [x1 x2] :adatx.prog-hold/prog)
   :in-out-pairs  [{:in [1 2] :out 4}
   {:in [1 3] :out 5}
   {:in [2 3] :out 7}
   {:in [4 3] :out 11}]
   :sandbox :none}))
 (adatx/get-solution workings); = (fn [x1 x2] (+ x1 x1 x2))





 On Saturday, 8 March 2014 21:30:56 UTC, Ludwik Grodzki wrote:

 Hello Clojure Group.

 I've put together a little library that writes clojure code for you...
 given test input/output examples and a heuristic of relevant functions.

 https://github.com/LudoTheHUN/adatx

 Feedback + contributions very welcome.

 Regards.

 Ludwik.

  --
 You 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] Clojure 1.6.0-beta1

2014-02-15 Thread Alex Baranosky
Great job on the new release guys :)

My one bit of feedback is that if-some and when-some behave like a let, but
don't include let in the name.  My guess is that this was chosen because
if-some-let and when-some-let are starting to get awkwardly long.


On Sat, Feb 15, 2014 at 2:32 PM, Andy Fingerhut andy.finger...@gmail.comwrote:

 Alex's suggestion is a good way to determine whether the 10k clj-tuples in
 a set case is being sped up by the new hash function -- just look at the
 variety of values of (hash x) for all x's in the set and see whether it is
 significantly more unique hash values in 1.6.0-beta1 than with 1.5.1.

 As for the 1-2ms slower, I am curious to know what percentage increase
 that represents over Clojure 1.5.1?

 I have some benchmark results on the wiki page below.  Look especially in
 the column Clojure 1.6.0 just after this 
 commithttps://github.com/clojure/clojure/commit/17b18350bdd28154241bc7ae80f423a5976c6de2on
  Jan 30 2014 near the bottom of the table for some speed comparisons
 versus the first column labeled Using Clojure 1.6.0-alpha3 hash (same as
 Clojure 1.5.1).

 http://dev.clojure.org/display/design/Better+hashing

 Andy


 On Fri, Feb 14, 2014 at 11:00 PM, tcrayford tcrayf...@gmail.com wrote:

 I ran clojure 1.6 through a benchmark suite (proprietary, but thought
 knowing about results might be interesting). Most of the benches were 1-2ms
 slower, but one (that involves pushing around 10k clj-tuples into a set)
 went from ~90ms to ~4ms. I'd guess that's the new hash stuff coming in, but
 either way, that speedup is super awesome!

 On Friday, 14 February 2014 19:04:09 UTC, Alex Miller wrote:

 Clojure 1.6.0-beta1 is now available.

 Try it via
 - Download: http://central.maven.org/maven2/org/clojure/
 clojure/1.6.0-beta1
 - Leiningen: [org.clojure/clojure 1.6.0-beta1]

 Highlights below or see the full change log here:
 https://github.com/clojure/clojure/blob/master/changes.md

 We expect Clojure 1.6.0-beta1 to be close to a release candidate; no
 other big changes are planned. Please give us your feedback and final
 issues if you find them so we can do the final release!

 Clojure 1.6.0-beta1 has the following changes from 1.5.1:

 1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
 SE 1.6 instead of Java SE 1.5. [CLJ-1268]

 2) The following features are no longer marked Alpha in Clojure:

 * Watches - add-watch, remove-watch
 * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!,
 disj!
 * Exception data - ex-info, ex-data
 * Promises - promise, deliver
 * Records - defrecord
 * Types - deftype
 * Pretty-print tables - print-table

 3) The clojure.java.api package provides a minimal interface to
 bootstrap
 Clojure access from other JVM languages. Example:

 IFn map = Clojure.var(clojure.core, map);
 IFn inc = Clojure.var(clojure.core, inc);
 map.invoke(inc, Clojure.read([1 2 3]));

 4) Map destructuring extended to support namespaced keys. [CLJ-1318]

 In the past, map destructuring with :keys and :syms would not work
 with maps containing namespaced keys or symbols. The :keys and :syms
 forms have been updated to allow them to match namespaced keys and
 bind to a local variable based on the name.

 Examples:

 (let [m {:x/a 1, :y/b 2}
   {:keys [x/a y/b]} m]
   (+ a b))

 (let [m {'x/a 1, 'y/b 2}
   {:syms [x/a y/b]} m]
   (+ a b))

 Additionally, the :keys form can now take keywords instead of symbols.
  This provides support specifically for auto-resolved keywords:

 (let [m {::x 1}
   {:keys [::x]} m]
   x)

 5) New some operations

 Many conditional functions rely on logical truth (where falsey
 values are nil or false). Sometimes it is useful to have functions
 that rely on not nilness instead. These functions have been added to
 support these cases [CLJ-1343]:

 * some? - same as (not (nil? x))
 * if-some - like if-let, but checks (not (nil? test)) instead of test
 * when-some - like when-let, but checks (not (nil? test)) instead of test

 6) Hashing overhaul

 The Clojure hash algorithms have changed for many primitives and
 collections.
 Read the changelog and http://clojure.org/data_structures#hash for more
 detail
 and if you are building external collections.

 In general, this change creates better hash codes (better bit
 dispersion, fewer
 collisions) to improve performance of hashed collections (maps and
 sets).
 *NOTE:* One side effect may be that code currently relying on the
 arbitrary order
 of hashed elements in a collection (tests for example) may need to be
 fixed.

 7) Other new things

 * unsigned-bit-shift-right - Java's 
 * clojure.test/test-vars - run a set of tests with fixtures

 8) Printing enhancements

 * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
   Print metadata for functions when *print-meta* is true and remove
 errant space at beginning.
 * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
   pprint cl-format now 

Re: cond- variant?

2014-02-12 Thread Alex Baranosky
I wrote pred-cond for Midje way back, which does what you want.
https://github.com/marick/Midje/blob/master/src/midje/clojure/core.clj#L176

Example use:
https://github.com/marick/Midje/blob/master/src/midje/parsing/1_to_explicit_form/facts.clj#L100

Like normal cond pred-cond will short-circuit once it hits a match (so
unlike con-)



On Tue, Feb 11, 2014 at 11:36 PM, s...@corfield.org wrote:

  I use cond- quite a lot but I find myself often wanting a version that
 uses predicate functions rather than expressions which would seem
 more “threaded”. Am I just missing a better way to write these things?

 For example:

 (cond- accounts
   (empty? accounts) (conj “stuff”))

 That just screams for something like:

 (condp- accounts
   empty? (conj “stuff”))

 Then you could thread the predicates:

 (condp- a
   p1 (f1 args)
   p2 (f2 args))

 which would be:

 (let [x (if (p1 a) (f1 a args) a)]
   (if (p2 x) (f2 x args) x))

 Suggestions?

 Sean Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org
 World Singles, LLC - http://worldsingles.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.


Re: [ANN] clj-refactor.el 0.10.0

2014-02-01 Thread Alex Baranosky
adrians,

Personally, for my part in clj-refactor.el, I don't have any interest in
porting it to Light Table. The project depends pretty heavily on other
Emacs packages such as paredit, multiple-cursors, and yas-snippets, so it's
not trivial to port.


On Sat, Feb 1, 2014 at 11:22 AM, adrians nman...@gmail.com wrote:

 Really cool stuff, guys. Are you considering a Light Table version as well?

 --
 You 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: idiomatic extension to - / -- ?

2014-01-18 Thread Alex Baranosky
What I think is the interesting part of the question is the inclusion of
the word idiomatic. I'm not sure swiss-arrows is idiomatic... that said I
don't know what would be considered idiomatic here.a

One solution I know of for examples like this is:

(- 2
 (+ 2)
 (#(* 1 % 3)))

I'm not sure this is idiomatic either, but it at least has the benefit of
requiring no additional dependencies.



On Fri, Jan 17, 2014 at 11:29 PM, t x txrev...@gmail.com wrote:

 You win. :-)


 On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist shaunxc...@gmail.comwrote:

 https://github.com/rplevy/swiss-arrows


 On Fri, Jan 17, 2014 at 11:05 PM, t x txrev...@gmail.com wrote:

 I have the following:

 (defn helper [initial funcs]
   (loop [fns funcs
  ans initial]
 (if (empty? fns)
   ans
   (recur (rest fns)
  (list (first fns) ans)

 (defmacro = [initial  funcs]
   (helper initial funcs))

 (macroexpand-1
  '(= 2
   #(+ % 2)
   #(* 1 % 3)))


 Is there something part of the idiomatic clojure / clojure core which
 does the above? Basically, I like the idea of - and --, but I find that I
 can't always guarantee (1) last element or (2) 2nd element.

 The above lets me place the argument directly via #%

 Question: is there something part of idiomatic clojure / clojure core
 that already does the above?

 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.


  --
 --
 You 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: idiomatic extension to - / -- ?

2014-01-18 Thread Alex Baranosky
I think if you have to choose one that is idiomatic, you'd have to say it
is as-, due to its inclusion in clojure.core.  I should start using that
pattern...


On Sat, Jan 18, 2014 at 12:47 AM, Jozef Wagner jozef.wag...@gmail.comwrote:

 There is a Syntax threading library at
 https://github.com/LonoCloud/synthread . See it in action at
 http://www.infoq.com/presentations/Macros-Monads


 On Sat, Jan 18, 2014 at 9:18 AM, Jordan Berg jordannealb...@gmail.comwrote:

 You can also use as- in 1.5+

 (- 2
 (+ 2)
 (as- x (* 1 x 3)))

 I like this a bit more than the (#()) approach, personally

 On Sat, Jan 18, 2014 at 12:07 AM, Alex Baranosky
 alexander.barano...@gmail.com wrote:
  What I think is the interesting part of the question is the inclusion
 of the
  word idiomatic. I'm not sure swiss-arrows is idiomatic... that said I
  don't know what would be considered idiomatic here.a
 
  One solution I know of for examples like this is:
 
  (- 2
   (+ 2)
   (#(* 1 % 3)))
 
  I'm not sure this is idiomatic either, but it at least has the benefit
 of
  requiring no additional dependencies.
 
 
 
  On Fri, Jan 17, 2014 at 11:29 PM, t x txrev...@gmail.com wrote:
 
  You win. :-)
 
 
  On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist 
 shaunxc...@gmail.com
  wrote:
 
  https://github.com/rplevy/swiss-arrows
 
 
  On Fri, Jan 17, 2014 at 11:05 PM, t x txrev...@gmail.com wrote:
 
  I have the following:
 
  (defn helper [initial funcs]
(loop [fns funcs
   ans initial]
  (if (empty? fns)
ans
(recur (rest fns)
   (list (first fns) ans)
 
  (defmacro = [initial  funcs]
(helper initial funcs))
 
  (macroexpand-1
   '(= 2
#(+ % 2)
#(* 1 % 3)))
 
 
  Is there something part of the idiomatic clojure / clojure core which
  does the above? Basically, I like the idea of - and --, but I find
 that I
  can't always guarantee (1) last element or (2) 2nd element.
 
  The above lets me place the argument directly via #%
 
  Question: is there something part of idiomatic clojure / clojure core
  that already does the above?
 
  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.
 
 
  --
  --
  You 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

Re: How can I improve this?

2014-01-11 Thread Alex Baranosky
I've been finding uses for Brandon Bloom's transduce mini-library left and
right lately. There is a class of problems where you want to track some
state as you process a seq, and transduce.lazy/map-state enables you to do
that (https://github.com/brandonbloom/transduce).

Here's my solution using it. It is concise and stateless:

(defn uniqify [coll]
  (map-state (fn [elem-times-seen x]
   (let [x (if-let [times-seen (elem-times-seen x)]
 (str x _ times-seen)
 x)
 elem-times-seen' (update-in elem-times-seen [x]
(fnil inc 0))]
 [elem-times-seen' x]))
 {}
 coll))


On Sat, Jan 11, 2014 at 12:32 AM, Mark Engelberg
mark.engelb...@gmail.comwrote:

 Very clever!


 On Fri, Jan 10, 2014 at 8:10 PM, Håkan Råberg hakan.rab...@gmail.comwrote:

 Another style, using channels for local state, but could been plain old
 iterators, slight golf warning:

 (require '[clojure.core.async :refer [to-chan !!]])

 (defn uniquify [s formatter]
   (let [g (memoize #(to-chan (cons % (map (partial formatter %) (next
 (range))]
 (map (fn f [x] ((some-fn #{x} f) (!! (g x s)))

 (uniquify [a a a a b a_2 a_3 a_3_1 a_3_1 a] #(str %1
 _ %2))
 ;= [a a_1 a_2 a_3 b a_2_1 a_3_1 a_3_1_1 a_3_1_2 a_4]


 On Friday, 10 January 2014 14:59:10 UTC, Colin Yates wrote:

 I have a sequence of file names and I want to make them unique.
  (uniquify [a b c a]) = [a b c a_1])

 This is what I have come up with, but surely there is a better way?

 What would you all do?  Feedback welcome (including the word 'muppet' as
 I am sure I have missed something simple) :)

 (defn uniquify
   Return a sequence, in the same order as s containing every element
   of s. If s (which is presumed to be a string) occurs more than once
   then every subsequent occurrence will be made unique.

   Items will be updated to include an incrementing numeric count using
   the specified formatter function. The formatter function will be
   given the name and the number and should return a combination of the
   two.

   The set of unique s's in the returned sequence will be the count of
   s's in s.
   ([s] (uniquify s (fn [item duplicates] (str item _ duplicates
   ([s formatter]
  (let [occurrences (atom {})
register-occurrence (fn [item]
  (if (get @occurrences item)
(swap! (get @occurrences item) inc)
(swap! occurrences assoc item (atom
 1)))
  @(get @occurrences item))
process (fn [item]
  (let [duplicates (dec (register-occurrence item))]
(if ( duplicates 0)
  (formatter item duplicates)
  item)))
unique-s (map process s)]
unique-s)))

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

Re: [ANN] clj-refactor.el - A few Clojure refactorings for Emacs.

2013-12-30 Thread Alex Baranosky
Hi Magnar,

I've been using this library for maybe a month.  The refactorings I use by
far the most are renaming files, and threading/unthreading. Thanks for your
work on this.


On Mon, Dec 30, 2013 at 7:52 AM, Magnar Sveen magn...@gmail.com wrote:

 clj-refactor.el https://github.com/magnars/clj-refactor.el provides a
 set of simple refactorings for Clojure in Emacs. It doesn't tackle the hard
 problems, like cross-namespace renaming. Instead it gives you a little
 quality of life while we're waiting.
 https://gist.github.com/magnars/51ccab2b478d97b9aa17#thread--unwindThread
 / unwind

 Given this:

 (map square (filter even? [1 2 3 4 5]))

 Start by wrapping it in a threading macro:

 (- (map square (filter even? [1 2 3 4 5])))

 And start threading away, using cljr-thread:

 (- (filter even? [1 2 3 4 5])
  (map square))

 And again:

 (- [1 2 3 4 5]
  (filter even?)
  (map square))

 To revert this, there's cljr-unwind. Just read the examples in the other
 direction.

 https://gist.github.com/magnars/51ccab2b478d97b9aa17#introduce--expand-letIntroduce
 / expand let

 Given this:

 (defn handle-request
   {:status 200
:body (find-body abc)})

 With the cursor in front of (find-body abc), I do cljr-introduce-let:

 (defn handle-request
   {:status 200
:body (let [X (find-body abc)]
X)})

 Now I have two cursors where the Xes are. Just type out the name, and
 press enter. Of course, that's not where I wanted the let statement. So I
 do cljr-expand-let:

 (defn handle-request
   (let [body (find-body abc)]
 {:status 200
  :body body}))

 Yay.

 https://gist.github.com/magnars/51ccab2b478d97b9aa17#automatic-insertion-of-namespace-declarationAutomatic
 insertion of namespace declaration

 When you open a blank .clj-file, clj-refactor inserts the namespace
 declaration for you.

 It will also add the relevant :use clauses in test files, normally using
 clojure.test, but if you're depending on midje in your project.clj it
 uses that instead.
 https://gist.github.com/magnars/51ccab2b478d97b9aa17#more-stuffMore
 stuff

- When you rename a file, it will update the ns-declaration and then
query-replace new ns in project.
- You can add :require and :import to the ns, and when you're done it
jumps back to where you were.

 https://gist.github.com/magnars/51ccab2b478d97b9aa17#in-summaryIn
 summary

 This isn't the big refactoring lib that we're all waiting for. That would
 require connecting to nREPL, analyzing ASTs, expanding macros, and a whole
 lot of other problems.

 Instead it adds a few helpful functions that are available right now.

 And if you want to contribute, and maybe grow this into the refactorer's
 dream - do let me know. I'm all for that. :-)

 - Magnar

 --
 --
 You 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: Akka-like framework in Clojure ?

2013-12-27 Thread Alex Baranosky
You can just use Akka directly w/ Clojure's excellent Java interop.


On Fri, Dec 27, 2013 at 3:48 PM, Paulo Suzart paulosuz...@gmail.com wrote:

 Hi,

 Am I wrong or Galaxy project (behind pulsar) is quite inactive? Does
 anybody know how promising are they?

 Cheers


 On 27 December 2013 17:32, Bruno Kim Medeiros Cesar brunokim...@gmail.com
  wrote:

 I haven't dabbled yet on actor-based concurrency, can someone point out
 (a blog post about) a comparison between Akka actors, Clojure agents and
 other solutions?


 On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:


 Hi,

 After a long background with imperative languages such as Java, I
 recently spent some time learning functionnal programming, starting with
 Scala. I had the opporrtunity to build a demo project based on the Akka
 framework.

 Now I am starting learning Clojure, and would be curious to know if
 there was some clojure based framework available which could implement
 rather similar features to Akka.

 In particular, I would be interested in an implementation of the Actor
 Model [1]

 Thanks.

 Eric


 [1] http://en.wikipedia.org/wiki/Actor_model

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




 --
 Paulo Suzart
 @paulosuzart

 --
 --
 You 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: In your opinion, what's the best, and what's the worst aspects of using Clojure?

2013-12-27 Thread Alex Baranosky
I always hear people say that the errors are bad, but I just don't see it.
 The stacktraces say exactly what went wrong and at what line of the
source. To me that's all I can hope for.

I think there may have been some more obtuse errors that came up in older
versions of Clojure that have since been improved in newer versions, though.


On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield seancorfi...@gmail.comwrote:

 Whilst the stacktraces can be pretty painful at times - esp. if you're
 dealing with lazy sequences - they do include filenames and line
 numbers, at least when you're outside the REPL. There are also a
 number of tools to clean up stack traces to show only Clojure-related
 entries and/or color-code them etc (e.g.,
 clojure.stacktrace/print-stack-trace which is part of the core Clojure
 download).

 That said, yes, debugging errors is probably the worst aspect of using
 Clojure :)

 And +1 on the language/community as best!

 Sean

 On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla grd...@gmail.com wrote:
  Seconded on Error reporting.
 
  I have been playing around with Clojure for sometime now and also
 completed
  almost 150 of the 4clojure problems. What still scars me in terms of
  incorporating Clojure as a language of choice in more complicated
 projects I
  work on in my other life, is the error reporting facility. The errors
  sometimes might as well just say 'I just cannot run!'.  It would be nice
 if
  there was some facility to approximately point to some s-exp or line
  numbers.
 
  May be I am missing some workflow used by other expert users. Can someone
  throw more light on this.
 
 
  Thanks
  Guru
 
 
  On Fri, Dec 27, 2013 at 3:44 PM, Daniel doubleagen...@gmail.com wrote:
 
  Best: Language  Community
  Worst: Error Reporting
 
 
  On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
 
  In your opinion, what's the best, and what's the worst aspects of using
  Clojure?
 
  --
  --
  You 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.



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

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

2013-12-27 Thread Alex Baranosky
Lee,

Sure, it'd be nice to have a functioning debugger, I'll give you that.


On Fri, Dec 27, 2013 at 8:03 PM, Lee Spector lspec...@hampshire.edu wrote:


 On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
  I always hear people say that the errors are bad, but I just don't see
 it.  The stacktraces say exactly what went wrong and at what line of the
 source. To me that's all I can hope for.

 One can hope to see the values of locals, which for me would make a big
 difference. This is apparently possible (through some combination of
 nrepl-ritz and avoiding locals clearing, I think), but not at all easy. In
 other parts of the Lisp universe this has been standard for decades and, I
 think, central to common debugging practices.

 --
 --
 You 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: Is Clojure right for me?

2013-12-26 Thread Alex Baranosky
I'm still partial to Ring.


On Thu, Dec 26, 2013 at 2:16 AM, James Reeves ja...@booleanknot.com wrote:

 What sort of web development were you planning to do?

 - James


 On 25 December 2013 21:06, Massimiliano Tomassoli kiuhn...@gmail.comwrote:

 Hi,
 I'm not sure if Clojure is the right language for me. I'd like to use
 Clojure mainly for web development but I don't know if it's already mature
 enough to be productive. For instance, Scala has Play, Groovy has Grails,
 etc... If I'm not wrong, Clojure doesn't have a well-established framework
 for web development. I'm intrigued by Clojure because I like functional
 programming, but I need to be productive and, alas, I don't have time to
 learn Clojure just for my pleasure.

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


Re: Is Clojure right for me?

2013-12-26 Thread Alex Baranosky
http://preview.getprismatic.com/news/home


On Thu, Dec 26, 2013 at 2:42 PM, john walker john.lou.wal...@gmail.comwrote:

 clojurekoans.com uses Joodo.

 https://github.com/slagyr/joodo

 What are some other cool sites powered by Clojure?


 On Wednesday, December 25, 2013 4:06:20 PM UTC-5, Massimiliano Tomassoli
 wrote:

 Hi,
 I'm not sure if Clojure is the right language for me. I'd like to use
 Clojure mainly for web development but I don't know if it's already mature
 enough to be productive. For instance, Scala has Play, Groovy has Grails,
 etc... If I'm not wrong, Clojure doesn't have a well-established framework
 for web development. I'm intrigued by Clojure because I like functional
 programming, but I need to be productive and, alas, I don't have time to
 learn Clojure just for my pleasure.

  --
 --
 You 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: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.

2013-12-24 Thread Alex Baranosky
Hi Solo,

I did a big migration from 1.2 to 1.5 at work this past February.  Here are
a few of the things that I gleaned from that experience, i addition to the
great advice mentioned already in this thread:

* with 1000's of these applications, I'd take the approach of only
migrating to 1.5 when there's a change needed, because there's a good
chance a lot of them will never need to be modified.  Any extra apps you
need to migrate could be work down the drain.
* on the other hand, you can get a nice groove going, and may want to do a
bunch of reports in one go. The changes you may find can be repetitive.
* to make sure you are only including namespaces that absolutely need to be
used by your application, AND to convert the ns declarations into 1.5
format automatically I used https://github.com/technomancy/slamhound. Watch
out for any macro-heavy code though, because Slamhound can miss
dependencies used exclusively in macros.
* are these reports tested? If not well tested be wary, because there were
a lot of number-related changes from 1.2 to 1.3
* keep an eye out for duplicated patterns in the reports.  If there are
some common pieces you might be able to just migrate those to 1.5 and use
them as a library for the other reports. YMMV.
*

Best,
Alex

On Tue, Dec 24, 2013 at 10:48 AM, Sean Corfield seancorfi...@gmail.comwrote:

 On Tue, Dec 24, 2013 at 7:23 AM,  solo.l...@gmail.com wrote:
  Yes, after looking into this, upgrading the libraries before upgrade the
  Clojure version is unfeasible in our case. I prefer not to keep a 1.2
  environment around forever but take our time phasing it out to avoid
 service
  disruption. I think the dual environment consensus here is the way to go.

 Please keep us posted on how this goes - I think it's an interesting
 case study for what happens with a large legacy code base.

 Fortunately the 1.2 - 1.3 changes were the biggest we've had to deal
 with so far and all the signs indicate we won't have to deal with that
 again, so this is a pain that only early adopters will be feeling.
 --
 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 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: Who is doing something worthwhile in Clojure?

2013-12-19 Thread Alex Baranosky
Yep, positive impact is pretty much entirely opinion-based.


On Thu, Dec 19, 2013 at 6:15 PM, Sean Corfield seancorfi...@gmail.comwrote:

 On Thu, Dec 19, 2013 at 5:19 PM, Rich Morin r...@cfcl.com wrote:
  I have no argument with The Climate Corporation's business model;
  my problems are with Monsanto.  That said, I don't want to dive
  off into that discussion.  In fact, my comment about them should
  probably have been left out of my initial posting.

 If you think that discussion is inappropriate for this list (and I
 agree - it is), then why do you think this discussion is appropriate:

  Can we get back to talking about folks who are using Clojure to
  make a positive impact?

 It seems to me this is bound to be a political or at least a very
 subjective one based on people's own moral compass and their ideology?
 As such I don't think it's a particularly useful discussion on what is
 primarily a technical list. Perhaps post the question on Quora? That
 seems to be very friendly toward political / moral discussions...
 --
 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 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: Who is doing something worthwhile in Clojure?

2013-12-19 Thread Alex Baranosky
Fair enough :)


On Thu, Dec 19, 2013 at 10:09 PM, John Wiseman jjwise...@gmail.com wrote:

 Suggestions of endeavors using clojure for something worthwhile itself
 seems like an entirely worthwhile discussion if people can resist the
 temptation to debate what worthwhile means and to disagree with other
 people's concept of worthwhile.  For example, here's a recipe for a useful
 discussion: If you know of activity X that you in good faith believe is
 worthwhile or, more specifically, (and I'm guessing at RIch's original
 intention so I could be wrong) philanthropic then post about X.  If you
 disagree with a poster about whether X is worthwhile, do not post.

 John



 On Thu, Dec 19, 2013 at 6:15 PM, Sean Corfield seancorfi...@gmail.comwrote:

 On Thu, Dec 19, 2013 at 5:19 PM, Rich Morin r...@cfcl.com wrote:
  I have no argument with The Climate Corporation's business model;
  my problems are with Monsanto.  That said, I don't want to dive
  off into that discussion.  In fact, my comment about them should
  probably have been left out of my initial posting.

 If you think that discussion is inappropriate for this list (and I
 agree - it is), then why do you think this discussion is appropriate:

  Can we get back to talking about folks who are using Clojure to
  make a positive impact?

 It seems to me this is bound to be a political or at least a very
 subjective one based on people's own moral compass and their ideology?
 As such I don't think it's a particularly useful discussion on what is
 primarily a technical list. Perhaps post the question on Quora? That
 seems to be very friendly toward political / moral discussions...
 --
 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 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.


Re: atom and vector .. remove prolbem

2013-12-09 Thread Alex Baranosky
There are ways to achieve what you ask, but normally you wouldn't use
nested vectors for data structures you want to operate on associatively.
 It will be inefficient, and the code will be ugly. Better to use more maps
and key them by:key and :id.


On Mon, Dec 9, 2013 at 12:46 AM, 박재혁 aquu...@gmail.com wrote:

 sorry I can't write English.


 watch my code.

 (def room-list (*atom[]*))

 (def rooms-1 {:key 12345 :create-dt 2013-11-22 :user-list[ {:name
 name-1 :id id-1}  {:name name-2 :id id-2}] })
 (def rooms-2 {:key 67890 :create-dt 2013-12-52 :user-list[ {:name
 name-3 :id id-3}  {:name name-3 :id id-3}] })

 (swap! room-list conj rooms-1)
 (swap! room-list conj rooms-2)

 @room-list
   -- [{:key 12345, :create-dt 2013-11-22, :user-list [{:name
 name-1, :id id-1} {:name name-2, :id id-2}]}
 {:key 67890, :create-dt 2013-12-52, :user-list [*{:name
 name-3, :id id-3}* {:name name-3, :id id-3}]}]


 I want remove red color text. ( red colore )

 @room-list
 --  [{:key 12345, :create-dt 2013-11-22, :user-list [{:name name-1,
 :id id-1} {:name name-2, :id id-2}]}
 {:key 67890, :create-dt 2013-12-52, :user-list [{:name
 name-3, :id id-3}] }]


 I don't know how to remove...

 dissoc,, pop, peek function can;t not solve.


 please help me...

 --
 --
 You 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: Am I missing something?

2013-12-03 Thread Alex Baranosky
I dislike all the migration libraries, because they all make migrations
super complex for what I usually want to do.  Wrote my own based of some
code Phil Hagelberg pointed me to months ago:
https://github.com/runa-dev/kits/blob/master/src/kits/db_migrator.clj


On Tue, Dec 3, 2013 at 9:21 PM, Brian Craft craft.br...@gmail.com wrote:

 Ah! And you just missed the survey.

 ;-)

 On Tuesday, December 3, 2013 4:20:52 PM UTC-8, James Laver wrote:

 Part of the 14 hours has been a learning curve for the libraries
 involved. I also seem to have spent rather too patching what I perceive to
 be holes where facilities should be in the libraries I'm using and in
 writing abstractions to avoid some of the tedium. I didn't really imagine
 I'd write two data structure handling libraries, two pieces of middleware
 and a validation layer atop korma just to be able to do a little bit of
 CRUD.

 I think I've been spoiled by the libraries available in other languages
 which seem to me to achieve a better balance between raw power and helping
 you to get things done more quickly (something I've found Perl achieves
 particularly well -- it errs on the side of power but the libraries seem
 more 'complete' if that makes sense).

  --
 --
 You 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] Slamhound 1.5.0 + screencast + Vim plugin

2013-11-30 Thread Alex Baranosky
Hi Guns,

Nice to see you carrying the Slamhound torch forward.  Good work.


On Sat, Nov 30, 2013 at 2:03 AM, r0man roman.sche...@burningswell.comwrote:

 This is very cool. Thanks!


 On Saturday, November 30, 2013 5:14:36 AM UTC+1, guns wrote:

 Hello,

 I am happy to announce version 1.5.0 of Slamhound, technomancy's amazing
 ns rewriting tool.

 ;; ~/.lein/profiles.clj
 {:user {:dependencies [[slamhound 1.5.0]]}}

 This is a *major* bugfix release. If you've tried Slamhound in the past
 and felt frustrated, now is a great time to give it another try.

 If you're unfamiliar with Slamhound, I've posted a short screencast
 here:

 https://vimeo.com/80650659

 Many thanks to Phil Hagelberg for allowing me to take the reins for this
 release.

 Enhancements since the last version include:

 - Greatly improved detection and disambiguation of missing ns
   references. Slamhound is now much better at DWIM.

 - References in the existing ns form are always preferred over other
   candidates on the classpath.

 - Mass-referred namespaces (via :use or :refer :all) are preserved
   as (:require [my.ns :refer :all]). Simply remove it from the ns
   form to get a vector of explicit refers.

 - File comment headers, ns metadata maps, docstrings, and :require
   flags (:reload et al), are correctly preserved.

 - Multiple options per require libspec are emitted correctly.
   e.g. (:require [clojure.test :as t :refer [deftest]])

 - Classes created via defrecord/deftype etc are correctly found.

 - Capitalized vars that shadow class names are no longer ignored.

 A full changelog is available here:

 https://github.com/technomancy/slamhound/blob/master/CHANGES

 Finally, for Vim users there is a new plugin for Slamhound integration:

 https://github.com/guns/vim-slamhound

 It was always easy to use Slamhound from fireplace.vim, but now it's
 just a Pathogen infect away.

 Cheers,

 guns

  --
 --
 You 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: tails function?

2013-11-30 Thread Alex Baranosky
user (rest (reductions conj [] [1 2 3 4]))
([1] [1 2] [1 2 3] [1 2 3 4])


On Sat, Nov 30, 2013 at 2:54 PM, Sean Corfield seancorfi...@gmail.comwrote:

 reductions requires a 2-arg function (reductions was my first thought
 too, but I couldn't come up with anything elegant with it).

 On Sat, Nov 30, 2013 at 9:20 AM, Alex Miller a...@puredanger.com wrote:
  reductions on rest?
 
  --
  --
  You 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.



 --
 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 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: quick macro review

2013-11-28 Thread Alex Baranosky
This also works, I believe:

(defmacro migrate [ migration-syms]
  (let [migration-vars (for [sym migration-syms]
   `(var ~sym))]
`(migrate* ~@migration-vars)))


On Thu, Nov 28, 2013 at 5:22 PM, juan.facorro juan.faco...@gmail.comwrote:

 Hi Curtis,

 The *apply* is unnecessary if you use *unquote-splice* (*~@*), also
 instead of the *into* and *for* usage you could just *map* over the list
 of symbols.

 Here's how I would do it:

 (defmacro migrate [ syms]
   `(migrate* ~@(map (partial list 'var) syms)))

 (macroexpand-1 '(migrate a b c))

 ;= (user/migrate* (var a) (var b) (var c))


 Hope it helps,

 Juan

 On Friday, November 29, 2013 5:26:14 AM UTC+8, Curtis Gagliardi wrote:

 I wrote a macro last night and got the feeling I did what I did in a
 suboptimal way.

 I have have a migration function that I stole from technomancy that takes
 in the vars of migration functions:
 (migrate #'create-db #'add-users-table #'etc)

 It uses the name of the var from the metadata to record which migrations
 have been run.  I wanted to try to make it so you didn't have to explicitly
 pass in the vars, and just have the migrate function call var for you.
 I've since decided this is a bad idea but I wrote the macro anyway just for
 fun.  My first question is: could this be done without a macro?  I didn't
 see how since if you write it as a function, all you recieve are the actual
 functions and not the vars, but I thought I'd ask to be sure.  Assuming you
 did have to write a macro, does this implementation seem reasonable?  I
 felt strange about using (into [] ...).

 https://www.refheap.com/21335

 Basically I'm trying to get from (migrate f g h) to (migrate* (var f)
 (var g) (var h)), I'm not sure I'm doing it right.

 Thanks,
 Curtis.

  --
 --
 You 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: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time

2013-11-20 Thread Alex Baranosky
Why all that pesky Ruby? =D


On Tue, Nov 19, 2013 at 4:44 PM, Alexey Verkhovsky 
alexey.verkhov...@gmail.com wrote:

 On Monday, 18 November 2013 16:45:40 UTC-7, Tony Tam wrote:

 If I sent you a like to a github profile that looked like yours (
 https://github.com/alexeyv?tab=repositories), would I ever get an
 answer? I mean, it's very probable that all your activity is going into
 private repos.


 I'd probably send you this link instead:
 https://github.com/thoughtworks/cruisecontrol.rb and explain that the
 peak of my open source activity happened before there was Github. And maybe
 mention the whole wife/family/kids thing :)

 Besides, I didn't say that stellar resume stands for nothing at all.
 So, in short, the answer is yes. By the way, Tony, your Github looks a
 heck of a lot better than mine.

 Back to the original subject of the thread, it looks like either there is
 more Clojure work than people with platform expertise, or Clojure is a
 mostly South American phenomenon. One way or the other, South America is
 the only place I've got any responses from so far. {puzzled}

 --Alex

 --
 --
 You 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: 2013 State of Clojure ClojureScript survey results

2013-11-20 Thread Alex Baranosky
The increased # of questions probably also reduces survey conversion ...
I ran out of time because it was so long, and had a lot of other things to
do, so I didn't submit my entry this year.


On Tue, Nov 19, 2013 at 7:09 PM, Sean Corfield seancorfi...@gmail.comwrote:

 Yes, the path separator is O/S dependent:

 user (import '(java.io File))
 java.io.File
 user (reduce #(File. %1 %2) [one two .. three])
 #File one/two/../three
 user  (.getCanonicalFile (reduce #(File. %1 %2) [one two ..
 three]))
 #File
 /Developer/workspace/worldsingles/ws/model/clojure/worldsingles/one/three
 user (.getPath (reduce #(File. %1 %2) [one two .. three]))
 one/two/../three

 Note that .getCanonicalFile renders the file path relative to the
 directory in which the REPL's JVM instance was started.

 Sean

 On Tue, Nov 19, 2013 at 7:02 PM, Cedric Greevey cgree...@gmail.com
 wrote:
  On Tue, Nov 19, 2013 at 10:02 AM, James Reeves ja...@booleanknot.com
  wrote:
 
 
  I think in this case it's more a problem with the Java API, which the fs
  library wraps. Until Java 7, I don't think relative path normalisation
  existed in the core Java libraries.
 
 
  It didn't, and .toPath isn't in the 1.6 java.io.File class in particular.
  1.6 gives you these options:
 
  user= (reduce #(File. %1 %2) [one two .. three])
  #File one\two\..\three
 
  user= (.getCanonicalFile (reduce #(File. %1 %2) [one two ..
  three]))
  #File C:\Windows\System32\one\three
 
  user= (.getPath (reduce #(File. %1 %2) [one two .. three]))
  one\\two\\..\\three
 
  Of these only getCanonicalFile normalizes, but it also makes it absolute,
  treating it as having been relative to (on the Win32 box I tested it on)
 the
  OS system directory of all places.
 
  It *is* interesting that Ruby Pathname objects and Java File objects get
  printed very similarly by Ruby and Clojure, respectively.
 
  I assume that / will replace \ as the separator (and the base directory
 used
  by getCanonicalFile will vary) if the above is used on other operating
  systems' JVMs.
 
  --
  --
  You 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.



 --
 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 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: Clojure High Performance Programming

2013-11-20 Thread Alex Baranosky
Congratulation on the book Shantanu!


On Wed, Nov 20, 2013 at 5:16 PM, Shantanu Kumar kumar.shant...@gmail.comwrote:

 Now also available on
 Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20
 Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21

 Shantanu

 On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I am pleased to announce availability of the book `Clojure High
 Performance Programming` that I have been writing for the better part of
 this year:

 http://www.packtpub.com/clojure-high-performance-programming/book

 This book is ideally meant for intermediate Clojure programmers. It is
 divided into seven chapters covering Clojure abstractions, Java interop,
 JVM internals, Concurrency and other performance-related topics.

 Shantanu

  --
 --
 You 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: What font is used for Clojure on clojure.org?

2013-11-10 Thread Alex Baranosky
Where I'm from the notion of cider in a champagne glass is a little
ludicrous. =)  But I guess maybe they're thinking of an alcoholic cider,
and I'm thinking more of the winter holiday season spiced warm cider in a
mug??


On Thu, Nov 7, 2013 at 6:17 AM, Tim Visher tim.vis...@gmail.com wrote:

 Cider _is_ nrepl.el at this point, essentially, so any screencast
 documenting nrepl.el would get you most of the way there.

 Also, Cider is _unstable_ at this point. I'm still using nrepl 0.2.0
 and it's working fine. I would _not_ recommend upgrading to Cider at
 this point.

 On Thu, Nov 7, 2013 at 9:10 AM, Erlis Vidal er...@erlisvidal.com wrote:
  And what about the screencasts?
 
  On Nov 7, 2013 8:34 AM, Tim Visher tim.vis...@gmail.com wrote:
 
  It's funny that in the comments bbatsov and I have already explored
  this space a bit. :)
 
  It seems like everyone has a different experience of drinking cider.
  I've never drank cider in anything but cups or mugs, and hot cider is
  always served in a mug in my circles. While it seems like other people
  have only ever drank it from champagne glasses. I wonder if this'll be
  a consistent source of confusion. :)
 
  On Thu, Nov 7, 2013 at 8:04 AM, Erlis Vidal er...@erlisvidal.com
 wrote:
   Is there any screen cast that shows how to use Cider? I would like to
   see it
   in action.
  
   I really liked this logo
  
 https://github.com/clojure-emacs/cider/issues/399#issuecomment-27805491
   I
   think it blends the Cider concept with the clojure characters ... the
   other
   are more colorful but really it looks like a coffee mug.
  
   Great Job!
  
   Erlis
  
  
   On Wed, Nov 6, 2013 at 12:32 PM, Tim Visher tim.vis...@gmail.com
   wrote:
  
   Thanks, Tom!
  
   Here's what I did with it:
  
 https://github.com/clojure-emacs/cider/issues/399#issuecomment-27878950
  
  
   On Wed, Nov 6, 2013 at 11:56 AM, Tom Hickey thic...@gmail.com
 wrote:
Hi Tim,
   
That is Avenir 65 Medium.
   
Cheers,
Tom Hickey
   
   
On Wednesday, November 6, 2013 11:06:24 AM UTC-5, Tim Visher wrote:
   
I'm looking for it to incorporate it into a cIDEr logo I'm playing
with.
   
--
   
In Christ,
   
Timmy V.
   
http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail
   
--
--
You 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.
 
  --
  --
  You 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
  

Re: [ANN] collection-check: validation for data structure variants

2013-10-30 Thread Alex Baranosky
Thanks Zach for this cool testing library, and thanks Reid for simple-check!

-- 
-- 
You 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: get fn and not-found

2013-10-28 Thread Alex Baranosky
Or a shorter variant of the sentinel approach:

(let [r (get a-map :b ::unfound)]
  (if (= r ::unfound)
(my-foo)
r))


On Sun, Oct 27, 2013 at 2:57 PM, Cedric Greevey cgree...@gmail.com wrote:

 (get a-map :b my-foo) will result in the function object itself being
 returned if :b is not found. If you want it to be called only in the event
 of not found, you need either

 (if (contains? a-map :b) (a-map :b) (my-foo)) -- which may perform the
 lookup twice -- or

 (if-let [r (a-map :b)] r (my-foo)) -- which does not, but treats a {:b
 nil} entry as the same as absence of :b -- or

 (let [sentinel (Object.)
   r (get a-map :b sentinel)]
   (if (identical? r sentinel)
 (my-foo)
 r)) -- which is longer and more complex, but calls my-foo (and returns
 what it returns) if and only if :b is genuinely absent from the map (like
 the first solution above) and performs the lookup only once (like the
 second solution above). If this has to be done in a tight loop, the extra
 efficiency over the second solution may be worth it, but you'll want to
 avoid repeatedly creating and discarding the sentinel object as well,
 resulting in something like

 (def {^:private} sentinel (Object.))

 ...

 (defn ...
 ...
   (loop ...
 ...
 (let [r (get a-map :b sentinel)]
   (if (identical? r sentinel)
 (my-foo)
 r)) ... ) ... )



 On Sun, Oct 27, 2013 at 1:00 PM, Ryan arekand...@gmail.com wrote:

 Silly me, thank you for your replies guys!

 One more question though, what if my-foo had parameters?

 Ryan


 On Sunday, October 27, 2013 6:55:34 PM UTC+2, Luc wrote:

 You are getting my-foo evaluated, remove the parens around it.

 Luc P.


  Hello,
 
  I am trying to understanding why is this happening:
 
   (defn my-foo [] (println Why do I get printed?))
   #'sandbox4724/my-foo
(get {:b 1} :b (my-foo))
   Why do I get printed?
   1
   
 
 
  Shouldn't (my-foo) only be called in case the key isn't found? Why am
 I
  seeing the above behavior instead?
 
  Thank you for your time,
 
  Ryan
 
  --
  --
  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=enhttp://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_outhttps://groups.google.com/groups/opt_out.

 
 --
 Softaddictslprefo...@**softaddicts.ca sent by ibisMail from my ipad!

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

Re: ANN: print-foo - a library of print debugging macros

2013-10-27 Thread Alex Baranosky
I took some inspiration from Tim Baldridge's code-walking macro youtube
video (http://www.youtube.com/watch?v=HXfDK1OYpco) and updated print-foo's
`print-sexp` macro to intelligently expand the code it surrounds.

print.foo= (print-sexp (str (+ 3 4) (+ 5 (* 6 2)) 4))3 34 4(+ 3 4) 75
56 62 2(* 6 2) 12(+ 5 (* 6 2)) 174 4(str (+ 3 4) (+ 5 (* 6 2)) 4)
7174

;; `print-sexp` replaces normal code like -, -, let, cond, if, ;;
etc, where possible with print.foo versions
print.foo= (pprint (macroexpand '(print-sexp (str (+ 3 4) (- 5 (* 6)
(* 2)) 4(print.foo/print-and-return
 '(str (+ 3 4) (- 5 (* 6) (* 2)) 4)
  
 (str
  (print.foo/print-and-return
   '(+ 3 4)

   (+
(print.foo/print-and-return '3   3)
(print.foo/print-and-return '4   4)))
  (print.foo/print- 5 (* 6) (* 2))
  (print.foo/print-and-return '4   4)))

As of now the latest version is 0.4.2.
https://github.com/AlexBaranosky/print-foo
https://clojars.org/print-foo

Best
Alex


On Thu, Mar 28, 2013 at 12:13 PM, Alex Baranosky 
alexander.barano...@gmail.com wrote:

 Jim,

 No reason I left out loop/recur.  I just didn't get around to it.  Pull
 requests accepted.


 On Thu, Mar 28, 2013 at 12:07 PM, Alex Baranosky 
 alexander.barano...@gmail.com wrote:

 adrians,

 https://clojars.org/print-foo

 I've got to deploy it with proper signing.


 On Thu, Mar 28, 2013 at 11:59 AM, adrians nman...@gmail.com wrote:

 Alex, print-foo *is* the correct artifact name, no? It seemed to be
 pulled down fine by pomegranate.


 On Thursday, March 28, 2013 2:35:31 PM UTC-4, Alex Baranosky wrote:

 Let me fix the README, the library should be required like this
 (:require [print.foo :refer :all])

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/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: Compulsive over-optimization

2013-10-22 Thread Alex Baranosky
Well said Niels.

As far as performance optimization. Imo that's premature until you profile.


On Tue, Oct 22, 2013 at 2:42 AM, Niels van Klaveren 
niels.vanklave...@gmail.com wrote:

 I can imagine this behavior. Unlike premature performance optimization,
 readability / terseness are well worth optimizing for when learning
 Clojure, as long as you value readability over terseness to keep well away
 from code golf territory.

 With Clojure, I always have the idea that things could be done in a
 simpler way, and usually it can. A lot of what I consider 'draft' code that
 works can be cleaned up drastically, and sometimes after cleaning I still
 have some niggles.  However, with time my 'draft' code tends to get cleaner
 and cleaner, and I also see up front where algorithms and function input /
 output can be changed to prevent code getting needlessly complex, and
 having to handle more exceptions than rules.

 While doing 4clojure problems, some of my first attempts were 4 or 5
 lines. While this is considered next nothing in Javaland, getting them down
 to 1 line, and comparing them to some of the Clojure vets you get a good
 feel for what's the idiomatic Clojure way to solve certain problems. So I
 guess it's all part of the learning process. I would not worry about it too
 much, you can only clean up for readability / terseness up to a point.

 Be sure to stay away from performance optimization unless absolutely
 necessary. There's way too many options, and it needs a really good insight
 into Clojure's implementation details to do effectively. Most idiomatic
 Clojure code performs on par or better compared to other dynamic languages
 like Python and Ruby.


 On Saturday, October 19, 2013 1:20:33 AM UTC+2, queshaw wrote:

 With clojure in particular, I am having trouble not rearranging my code
 to be what I think is more optimal in ways that seem probably not
 practical. I've noticed myself doing that when I'm newish to languages
 and apis. But, I go bonkers with clojure.

 Do you have any thoughts about how to avoid that, other than Bob
 Newhart's advice:

 http://www.youtube.com/watch?**v=Ow0lr63y4Mwhttp://www.youtube.com/watch?v=Ow0lr63y4Mw

 Kendall

  --
 --
 You 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: Compulsive over-optimization

2013-10-20 Thread Alex Baranosky
Kendall,

Refactoring is valuable especially when starting out, so that you can learn
how to represent patterns well in Clojure, imo.


On Sun, Oct 20, 2013 at 10:59 AM, Kendall Shaw ks...@kendallshaw.comwrote:

 I might have come off as obnoxious. So, sorry about that.

 Now that I think about it some more, the question probably doesn't have a
 procedure to suggest as an answer. It's in the same class as like how do I
 start or how can I stop asking so many questions.

 Kendall


 On 10/19/2013 03:05 PM, Softaddicts wrote:

 I read your post three times and now I need to get a couple of fuses
 replaced :)

 Holy smoke, it's Saturday man ! Most of us are probably trying to recover
 from the work week, give us a chance :)))

 Luc P.


  The question in the second paragraph depends on the belief that someone
 could engage in pointless refactoring.

 There is an implied assertion that clojure's design provides more
 opportunities for someone to engage in pointless refactoring.

 Disproving that someone could engage in pointless activity would miss
 the point of the question. So, providing an example for that would
 possibly lead to more confusion.

 If the implied asssertion about clojure's design were taken to further
 imply that the design is flawed in those cases, this would also be
 missing the point of the question.

 If  cases in which clojure's design were flawed were not invented for
 the purpose of pursuing this questioning. Without criticism of clojure's
 design, specifics about how clojure could be used in a multitude of ways
 to solve a problem, could be described by way of example. But, that
 would also miss the point of the question.

 So, if the image of someone engaging in pointless refactoring reminds
 you of an experience that you have had, and if you can use that as the
 model for a general case, how would you suggest preventing the general
 case from being made actual, in the future?

 Kendall

 On 10/19/2013 12:35 AM, Laurent PETIT wrote:

 Can you give a concrete example?

 Le samedi 19 octobre 2013, Kendall Shaw a écrit :

  With clojure in particular, I am having trouble not rearranging my
  code to be what I think is more optimal in ways that seem probably
  not practical. I've noticed myself doing that when I'm newish to
  languages and apis. But, I go bonkers with clojure.

  Do you have any thoughts about how to avoid that, other than Bob
  Newhart's advice:

  Bob Newhart-Stop It 
 http://www.youtube.com/watch?**v=Ow0lr63y4Mwhttp://www.youtube.com/watch?v=Ow0lr63y4Mw
 

  Kendall

  --
  --
  You 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.comclojure%2bunsubscr...@googlegroups.com
  For more options, visit this group at
  
 http://groups.google.com/**group/clojure?hl=enhttp://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.comclojure%2bunsubscr...@googlegroups.com
 .
  For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=enhttp://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.comclojure%2bunsubscr...@googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .


 --
 ThisIsHardToRead, asIsThis. This_is_easier, unless_it_is_underlined.
 This.is.easy. This-is-easy-too. Almost as easy to read as this.

 --
 --
 You 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.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 

Re: getting a stack trace

2013-10-18 Thread Alex Baranosky
 jstack process-id


On Fri, Oct 18, 2013 at 9:44 AM, Brian Craft craft.br...@gmail.com wrote:

 In trying to understand how threads work I'd like to dump a stack trace at
 various places. All the stack trace calls take an exception. Is there some
 simpler way, or should I throw  catch an except just to get a stack trace?

 --
 --
 You 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: is PG's imperative outside-in advice any good?

2013-10-15 Thread Alex Baranosky
I and some of my coworkers do tend to avoid `let` unless in this particular
case you especially want to emphasize the name of something unobvious.
OFten I'd prefer to pull out a new function over using let, or inline the
binding for readability *improvement*.


On Tue, Oct 15, 2013 at 8:18 AM, Raoul Duke rao...@gmail.com wrote:

 if a programming language doesn't have something like 'where', then i
 am sad. http://stackoverflow.com/questions/4362328/haskell-where-vs-let

 --
 --
 You 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: Reflecting on Arity

2013-10-13 Thread Alex Baranosky
c is the best bet, but still I wouldn't rely on it for anything.


On Sun, Oct 13, 2013 at 9:23 PM, Mikera mike.r.anderson...@gmail.comwrote:

 Currently IFn itself doesn't provide a way for you to do this.

 Options:
 a) example the source / docs
 b) Call the IFn and see which arities throw an ArityException
 c) If the IFn is in a var you can get arities from the :arglists metadata

 c) is probably your best bet if you know you have a var, e.g.

 (meta #'+)
 = {:arglists ([] [x] [x y] [x y  more]), :ns #Namespace clojure.core,
 :name +, :column 1, :added 1.2, :inline-arities #core$_GT_1_QMARK_
 clojure.core$_GT_1_QMARK_@564b8be6, :doc Returns the sum of nums. (+)
 returns 0. Does not auto-promote\n  longs, will throw on overflow. See
 also: +', :line 936, :file clojure/core.clj, :inline
 #core$nary_inline$fn__3961 clojure.core$nary_inline$fn__3961@abb88b8}



 On Monday, 14 October 2013 11:40:23 UTC+8, puzzler wrote:

 Is there a handy way to discover the valid arities for an arbitrary
 Clojure function?

  --
 --
 You 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: Improving a nested if, or How to use multimethods the right way.

2013-09-05 Thread Alex Baranosky
I'd just use a cond to flatten a nested if. That's usually all you need,
imo.


On Thu, Sep 5, 2013 at 1:07 PM, Bruno Kim Medeiros Cesar 
brunokim...@gmail.com wrote:

 Thanks for your suggestion, didn't know about that! One of the things that
 made someone say that Clojure looks like a language from the near future.
 However, I'm having a hard time using it with its full power. Could you
 recommend any other resource, besides the overview page on github, to learn
 pattern matching? Maybe a project that uses them?

 For the record, my code uses a simple truth table now:


 (defn add-edge
   ([g v1 v2  vs] (add-edge g (concat [v1 v2] vs)))
   ([g edge]
(let [two? (= 2 (count edge))
  dist? (apply distinct? edge)
  e (match [(hyper? g) (looped? g)] ; e will be nil if edge is
 invalid for this graph
  [false false] (when (and two? dist?) edge)
  [false true ] (when two?  edge)
  [true  false] (when dist? edge)
  [true  true ] edge]
  (if e
(update-in g [:edges] conj (if (directed? g) (vec e) (set e)))
g

 On Wednesday, September 4, 2013 7:07:06 PM UTC-3, Leonardo Borges wrote:

 You could use pattern matching with core.match
 On 05/09/2013 6:57 AM, Bruno Kim Medeiros Cesar bruno...@gmail.com
 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 http://imgur.com/IdgsGFG 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 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=enhttp://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_outhttps://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 

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

2013-09-05 Thread Alex Baranosky
;; Better yet...

(if (or (and (multi? graph) (not= 2 (count edge)))
(and (looped? graph) (not (distinct? edge
graph
(let [e (if (directed? edge) (vec edge) (set edge))]
  (update-in graph [:edges] conj e


On Thu, Sep 5, 2013 at 2:22 PM, Alex Baranosky 
alexander.barano...@gmail.com wrote:

 I'd just use a cond to flatten a nested if. That's usually all you need,
 imo.


 On Thu, Sep 5, 2013 at 1:07 PM, Bruno Kim Medeiros Cesar 
 brunokim...@gmail.com wrote:

 Thanks for your suggestion, didn't know about that! One of the things
 that made someone say that Clojure looks like a language from the near
 future. However, I'm having a hard time using it with its full power.
 Could you recommend any other resource, besides the overview page on
 github, to learn pattern matching? Maybe a project that uses them?

 For the record, my code uses a simple truth table now:


 (defn add-edge
   ([g v1 v2  vs] (add-edge g (concat [v1 v2] vs)))
([g edge]
(let [two? (= 2 (count edge))
  dist? (apply distinct? edge)
  e (match [(hyper? g) (looped? g)] ; e will be nil if edge is
 invalid for this graph
  [false false] (when (and two? dist?) edge)
  [false true ] (when two?  edge)
  [true  false] (when dist? edge)
  [true  true ] edge]
  (if e
(update-in g [:edges] conj (if (directed? g) (vec e) (set e)))
g

 On Wednesday, September 4, 2013 7:07:06 PM UTC-3, Leonardo Borges wrote:

 You could use pattern matching with core.match
 On 05/09/2013 6:57 AM, Bruno Kim Medeiros Cesar bruno...@gmail.com
 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 http://imgur.com/IdgsGFG 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 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=enhttp://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

Re: A macro for writing defn-like macros?

2013-09-03 Thread Alex Baranosky
https://github.com/clojure/tools.macro/blob/master/src/main/clojure/clojure/tools/macro.clj#L275??


On Tue, Sep 3, 2013 at 9:01 AM, Mark markaddle...@gmail.com wrote:

 I find the vast majority of the time I'm tempted to write a macro (yeah,
 yeah, I know the first rule of macro club), is to defn-like things.
 Writing a defn-like macro to handle all the stuff defn does is pretty tough
 so I end up writing a barebones thing that doesn't support doc-string,
 doesn't support multiple arities, and doesn't support metadata.  I'm
 wondering, has anyone written a defdefnmacro macro?

 --
 --
 You 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] core.typed 0.2.0 - Production Ready

2013-08-29 Thread Alex Baranosky
Imo, there's nothing easy about writing something like Slamhound. Even
after many iterations it can't handle macros, because ultimately they're
impossible, without some kind of hints specifically added for Slamhound (or
for Typed Clojure) :)

-- 
-- 
You 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: strange map

2013-08-28 Thread Alex Baranosky
map is lazy.  You shouldn't call side effect functions from it.  I
recommend you use doseq instead.


On Wed, Aug 28, 2013 at 1:57 AM, Christian Sperandio 
christian.speran...@gmail.com wrote:

 Hi,

 Try just one thing:

 (def r (map #(do (print -) %) '(1 2 3 4 5)))

 And after, do (println r)

 What do you get?







 2013/8/28 ljcppu...@gmail.com

 Hi

 (map #(do (print -) %) '(1 2 3 4 5))
 I think the result should be (-1 -2 -3 -4 -5), but it is (--1 -2 -3 -4
 5), it's difficult to understand,
 Can someone give answer?

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


Re: function creation, partial or #()

2013-08-16 Thread Alex Baranosky
My two cents:

The way I see it, the use of #( ... % ...) is analogous to the usage of the
word it in English: only use it when it is obvious beyond a shadow of a
doubt what it means.

Think about how clunky English would be without the word it.


On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge tbaldri...@gmail.comwrote:

 I'm just going to throw this out there, but I almost always consider using
 #() instead of (fn []) to be bad practice. Like all syntactic sugar, it has
 its place, but I reach for fn more often then not, because it allows me to
 name the arguments and track in my mind the data with which I am working. %
 means nothing to me, (fn [person]) at least gives me, as the reader of your
 code, some context to go on when trying to parse what you've written.

 So I see it as a few less characters, at the expense of harder to
 understand code.

 Timothy


 On Fri, Aug 16, 2013 at 1:49 PM, Gregg Reynolds d...@mobileink.com wrote:

 On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume duelin.mark...@gmail.com
 wrote:
  Though in some cases the performance impact could be significant, my
 concern
  is readability. My understanding of the concept of partial function
  application is that it's about supplying some but not all of the
 arguments.
  So when I see `partial` in code, I expect more arguments to be supplied
  later, which is confusing when that's not the case. (Obviously context
 can
  make it easy to see that there will be no more arguments, but often that
  context is not present.)
 

 +1.  Using partial to convert a unary func into a nullary func when
 #() is available strikes me as malpractice.  Suppose you were to come
 across something like this in legacy code:

  (do-work (partial say-hello bob))

 For me, the natural inference would be that say-hello must want at
 least one more arg (otherwise why partial?), so do-work must be
 feeding some arg to the result of (partial say-hello bob), like
 adding Don't worry, we're not watching you, in case the NSA owns
 do-work.  Execution efficiency aside, downstream programmer confusion
 due to implied semantics also has a cost.

 -Gregg

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




 --
 “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/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: Do you like the Clojure syntax?

2013-08-13 Thread Alex Baranosky
To me you cannot separate Clojure's syntax from its capabilities, because a
number of its capabilities are enabled by the syntax.

On Mon, Aug 12, 2013 at 10:55 PM, Christian Sperandio 
christian.speran...@gmail.com wrote:

 I think the choice of a language has always a subjective part.
 Particularly when you learn a language by yourself for pleasure.  Because
 it's 'for pleasure' you want to learn a fun stuff.

 At work, I believe the subjective part works against a choice. Currently,
 at my office, the 8 other colleagues don't want to take a look at Clojure
 because of its LISP syntax. Their brain blocks and they don't hear you when
 you talk about the language capabilities.
 Le 13 août 2013 03:14, Devin Walters dev...@gmail.com a écrit :

 I have to echo previous sentiments. I'm not going to fill out the survey
 because as it currently stands, it seems like it's begging for a conclusion
 that satisfies the author.

 I'd like to see more targeted questions w/r/t syntax. But there again, I
 think this kind of question is highly subjective, and likely to provide a
 narrow view of what people *actually* care about in Clojure: writing great
 programs, being inspired to dig deeper, realizing creative potential, etc.

 '(Devin Walters)

 On Aug 12, 2013, at 7:21 PM, Ramesh ramesh10dul...@gmail.com wrote:

 Great points here!

 I think once someone is comfortable with Clojure, Scala will be more
 disgusting than Java. This is because, Scala has such great adornments,
 ironically aspiring toward simplification.

 -ramesh


 On Mon, Aug 12, 2013 at 7:58 AM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 A couple of quick reactions...

 The survey itself is too flat. It's like asking do you like red or
 green? Well... I like green on my walls, but I like red on my ties.

 Scala has macros and a much richer syntax (although doing anything like
 core.async with Scala macros might be like putting tabsco on an open cut...
 just sayin') so I don't think the syntax and the macro stuff is a
 one-to-one mapping.

 People learn to work with a variety of syntaxes and are successful with
 them. Java and C++ have viscously awful syntax, yet they are very popular
 and most users of the languages don't notice. Both C and Lisp model an
 abstract computer and have syntax that reflects the computer that they
 model and to my mind, that helps the user of each language grok the
 abstract computer they are programming.

 I'd like a two-way mapping between a Clojure and an Excel-like formula
 language. That way people could write one-liner Clojure functions in a
 syntax that non-programmers are already comfortable with. I'm noodling with
 something like that right now.

 I think Jay and Colin are saying something very, very important: Clojure
 feels uncomfortable until it feels very comfortable and then there's no
 going back. I am not yet comfortable with Clojure's syntax, but I totally
 appreciate it. But I'm doing work in Scala, Java, and Clojure all for pay
 all in the same week every week... and bouncing among all three makes
 getting comfortable with Clojure a little slow. Further, I fear (deeply...
 in my bones) that once I am comfortable with Clojure, doing Scala will be
 as disgusting as doing Java is after 7 years of Scala. :-(



 On Mon, Aug 12, 2013 at 12:52 AM, Răzvan Rotaru razvan.rot...@gmail.com
  wrote:

 Hi,

 I'm curious about the general opinion on the Clojure syntax, whether
 people actually like it or just use it because it provides macros. So I
 would like to ask you to participate in a poll. Thank You.

 Here's the link:

 https://docs.google.com/forms/d/1GSgfkeThpUYlgFVzhhNIgA1JbTilu6S9eudq_Sbxl34/viewform

 Răzvan

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






 --
 Telegram, Simply Beautiful CMS https://telegr.am
 Lift, the simply functional web framework http://liftweb.net
 Follow me: http://twitter.com/dpp
 Blog: http://goodstuff.im

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

Re: Do you like the Clojure syntax?

2013-08-13 Thread Alex Baranosky
IMO, macros without homoiconicity are unnecessarily complex: so in that
sense Clojure's syntax makes macros simpler.  Where macros are simply
reorganizing some data in Clojure, in a language like Groovy you've got to
jump through hoops and only get a limited slice of the power.

Homoiconicity gives other little benefits as well, because it means you can
use the same code on the code as you could use on the data, which has
unforseen benefits.  For example I can diff source code, or list outputs
using the same function (
https://github.com/AlexBaranosky/gui-diff/blob/master/src/gui/diff.clj#L30).
 Also, you can very conveniently print data to a string and spit to a file,
then slurp it back out.  These things just make life easier in Clojure, and
are directly related to its syntax.

Alex

On Tue, Aug 13, 2013 at 12:23 AM, Christian Sperandio 
christian.speran...@gmail.com wrote:

 Even if I think the current syntax is one of the best, could you say what
 Clojure's capability couldn't be done with another syntax?

 Other languages implement FP without lisp syntax and the macros could be
 done in another way, perhaps with AST (like in groovy).

 Le 13 août 2013 08:53, Alex Baranosky alexander.barano...@gmail.com a
 écrit :

 To me you cannot separate Clojure's syntax from its capabilities, because
 a number of its capabilities are enabled by the syntax.

 On Mon, Aug 12, 2013 at 10:55 PM, Christian Sperandio 
 christian.speran...@gmail.com wrote:

 I think the choice of a language has always a subjective part.
 Particularly when you learn a language by yourself for pleasure.  Because
 it's 'for pleasure' you want to learn a fun stuff.

 At work, I believe the subjective part works against a choice.
 Currently,  at my office, the 8 other colleagues don't want to take a look
 at Clojure because of its LISP syntax. Their brain blocks and they don't
 hear you when you talk about the language capabilities.
 Le 13 août 2013 03:14, Devin Walters dev...@gmail.com a écrit :

 I have to echo previous sentiments. I'm not going to fill out the survey
 because as it currently stands, it seems like it's begging for a conclusion
 that satisfies the author.

 I'd like to see more targeted questions w/r/t syntax. But there again,
 I think this kind of question is highly subjective, and likely to provide a
 narrow view of what people *actually* care about in Clojure: writing great
 programs, being inspired to dig deeper, realizing creative potential, etc.

 '(Devin Walters)

 On Aug 12, 2013, at 7:21 PM, Ramesh ramesh10dul...@gmail.com wrote:

 Great points here!

 I think once someone is comfortable with Clojure, Scala will be more
 disgusting than Java. This is because, Scala has such great adornments,
 ironically aspiring toward simplification.

 -ramesh


 On Mon, Aug 12, 2013 at 7:58 AM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 A couple of quick reactions...

 The survey itself is too flat. It's like asking do you like red or
 green? Well... I like green on my walls, but I like red on my ties.

 Scala has macros and a much richer syntax (although doing anything
 like core.async with Scala macros might be like putting tabsco on an open
 cut... just sayin') so I don't think the syntax and the macro stuff is a
 one-to-one mapping.

 People learn to work with a variety of syntaxes and are successful
 with them. Java and C++ have viscously awful syntax, yet they are very
 popular and most users of the languages don't notice. Both C and Lisp 
 model
 an abstract computer and have syntax that reflects the computer that they
 model and to my mind, that helps the user of each language grok the
 abstract computer they are programming.

 I'd like a two-way mapping between a Clojure and an Excel-like formula
 language. That way people could write one-liner Clojure functions in a
 syntax that non-programmers are already comfortable with. I'm noodling 
 with
 something like that right now.

 I think Jay and Colin are saying something very, very important:
 Clojure feels uncomfortable until it feels very comfortable and then
 there's no going back. I am not yet comfortable with Clojure's syntax, but
 I totally appreciate it. But I'm doing work in Scala, Java, and Clojure 
 all
 for pay all in the same week every week... and bouncing among all three
 makes getting comfortable with Clojure a little slow. Further, I fear
 (deeply... in my bones) that once I am comfortable with Clojure, doing
 Scala will be as disgusting as doing Java is after 7 years of Scala. :-(



 On Mon, Aug 12, 2013 at 12:52 AM, Răzvan Rotaru 
 razvan.rot...@gmail.com wrote:

 Hi,

 I'm curious about the general opinion on the Clojure syntax, whether
 people actually like it or just use it because it provides macros. So I
 would like to ask you to participate in a poll. Thank You.

 Here's the link:

 https://docs.google.com/forms/d/1GSgfkeThpUYlgFVzhhNIgA1JbTilu6S9eudq_Sbxl34/viewform

 Răzvan

 --
 --
 You received this message because you

Re: Data Profiling

2013-08-10 Thread Alex Baranosky
You could possibly batch import it all into MySQL, and let people SQL query
over it.

On Sat, Aug 10, 2013 at 9:21 AM, Adrian Mowat adrian.mo...@gmail.comwrote:

 Hi,

 I have about 2.5 Gb of web transaction data (values submitted to forms
 etc) held as CSV files that my fairly non-technical users want to analyse.
  I want to make it easy for them to run basic analytics - averages,
 distribution of values, percentage nil etc - across all or a subset of the
 files.  I've seen commercial data profilers do this kind of thing and I
 think I could knock up something fairly quickly using incanter.  However, I
 can't help but feel it's a solved problem and I was wondering if anyone
 here knows of any github projects I could use to get me started?

 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/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: Status of Generic Functions (a la lisp)

2013-08-04 Thread Alex Baranosky
Razvan, are you asking about dispatch on multiple types...  protocols only
give fast dispatch on their first arg's type.

Currently you can either get fast dispatch on the type of the first arg, or
you get slower dispatch on anything w/ multimethods.

On Sat, Aug 3, 2013 at 11:48 PM, Robert Levy r.p.l...@gmail.com wrote:

 But isn't that the whole point of protocols, polymorphic dispatch that is
 fast?


 On Sat, Aug 3, 2013 at 11:45 PM, Răzvan Rotaru razvan.rot...@gmail.comwrote:

 The keyword here is speed. Multimethods are not fast. They don't use the
 JVM for dispatch (as far as I know). Protocols are fast. That's the reason
 for their existence. I want to find out whether there's some effort
 invested in making fast multiple dispatch in Clojure (and how else can it
 be but based on Java types?).

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




Re: Interest in a commercial IDE for Clojure?

2013-07-27 Thread Alex Baranosky
Hello Colin F,

A few of my observations:


   - I think heavy-duty Intellij Java users are the best market for such a
   plugin.  The business question then becomes: are there enough such teams to
   warrant the work necessary?


   - The plugin is at odds with a lot of Clojure's OSS community...  By
   this I mean is that there may be an uphill battle, because OSS is such a
   massive part of what makes Clojure's community tick.


   - Whatever you do, do *not* underestimate how good Emacs is.  One must
   know thy enemy ;)  Seriously though: Emacs is much more than a glorified
   text editor, and this is coming from an expert Intellij user.


   - I do think there is a place for a plugin like this... if you can do
   what Emacs does, and also do the things Intellij is renowned for, you'll
   have made a pretty great product.

Alex

On Sat, Jul 27, 2013 at 3:58 PM, coltnz colin.tay...@gmail.com wrote:

 Hi the other Colin.

 It's a shame this thread's been somewhat rudely hijacked from its purpose.
 Hopefully others aren't dissuaded from speaking out in support too.

 My team will heartily endorse such a project.

 Here's why:

 - we have a large legacy codebase of Java to embrace and extend with
 Clojure
 - we are expert Intellij users with no desire to retrain even if a
 comparable system existed - which it doesnt.
 - we want code aware development not glorified text editors and believe
 Intellij's platform offers the current best model for a code-aware
 development environment for Clojure.

 I'm sure many other companies are similarly placed.

 cheers
 Colin.


 On Saturday, July 27, 2013 11:54:58 PM UTC+12, Colin Fleming wrote:

 Hi all,

 I was planning to wait a little longer before going public, but since
 it's pretty relevant to the other IntelliJ thread going on at the moment I
 thought I'd jump in. For the last couple of months of happy unemployment
 I've been working on a fork of La Clojure which is now about 70% migrated
 to Clojure and significantly improved. It's a lot of work to develop a tool
 like this, and one of the options I'm considering is starting a company to
 develop it as a commercial product - JetBrains have never maintained
 development of La Clojure very actively. I've been doing a little market
 research but there's really not much data around about whether there are
 enough people working with Clojure to sustain a product like that, and also
 the community is currently very focused on open source.

 One problem is that the IDE space is already fairly fractured - there's
 Emacs and CCW, Clooj, Sublime Text and the promise of Light Table at some
 point, and of course the current public version of La Clojure. But there's
 still not a great option for something that's powerful but easy to use -
 CCW is probably the closest thing to this right now. However I think it's
 telling that a large fraction of people in the State of Clojure 2012 survey
 still identified development tools as a major pain point.

 I think that the IntelliJ platform is a fantastic base to build something
 like this on. Clojure as a language makes it pretty challenging to develop
 a lot of the great functionality that JetBrains are famous for, but I think
 there's scope to do a lot of great things. Certainly for mixed Clojure/Java
 projects it would be difficult to beat, but even for Clojure only projects
 I can imagine a lot of fantastic functionality built on their
 infrastructure. My plan would be to release a standalone IDE and a plugin
 for people using IntelliJ Ultimate for web dev, Ruby/Python or whatever.
 Since it's mostly Clojure now (and I'm migrating what's left as I get to
 it) there's a real possibility of a Clojure plugin/extension API. I
 envision charging PyCharm/RubyMine type prices, say $200 for company
 licenses or $100 for individual developers.

 So, I'd love to hear what people think. I'd appreciate it if we could
 stay away from the politics of open source vs proprietary - several people
 have told me privately that they'd rather use OSS and that's fine,
 proprietary isn't for everyone. What I'd like to know is if the idea is
 appealing to many people here?

 In case it's a concern for anyone, I've discussed this with JetBrains.

 Thanks for any feedback,

 Cheers,
 Colin

  --
 --
 You 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: help actually changing :use to :require :refer :all?

2013-07-27 Thread Alex Baranosky
Lee,

On our work projects at Runa, we have an unwritten code standard of always
writing out the full namespace, and not using shortcuts as you suggest.
 The reason being that it can be very hard to search for usages of a
namespace if you don't fully qualify them, which makes refactoring a
nightmare on projects with 250+ namespaces.

On Sat, Jul 27, 2013 at 4:00 PM, Colin Fleming
colin.mailingl...@gmail.comwrote:

 I think there's a lot of scope for automatic namespace management. I'm
 already doing this for Java but it's more complicated for Clojure.
 Currently for Java I automatically add an import via a popup if the user
 has a class short name (e.g. ArrayList) that isn't imported, and I also
 allow automatic importing of fully qualified names. This also works during
 completion (i.e. if the user autocompletes the short name of a class it
 will auto-import it). This also all works in the REPL editor - I
 automatically execute an (import 'class) statement in those cases.

 For Clojure it's a little trickier. I'm planning something similar to the
 above for Clojure symbols but how to specify the namespace alias is
 difficult from a UI point of view. If I type str/tr and then autocomplete
 I'd like a suggestion to :require [clojure.string :as str] and then
 autocomplete str/trim. But if I just type tr I'm not sure what should
 happen - currently I'm thinking of offering :require [clojure.string
 :refer [trim]], :require [clojure.string :as str] as options, where in
 the second one the prefix is either the most-frequently used alias for that
 NS in the project or the last segment of the namespace (string in this
 case) if not found. But I'm not sure how well this will work, you could
 potentially get a lot of completions, I'll probably make it so that the
 user has to explicitly request these completions (pressing complete twice,
 or something similar).

 I think adding intention actions to automatically refactor :use
 declarations into the corresponding :require should be pretty
 straightforward, though. I think all these features are a huge win for
 productivity, the automatic class import has been a life saver for me
 (since the plugin is a big interop project).


 On 28 July 2013 07:49, Laurent PETIT laurent.pe...@gmail.com wrote:

 2013/7/27 Lee Spector lspec...@hampshire.edu:
 
  On Jul 27, 2013, at 1:25 PM, Laurent PETIT wrote:
 
  But it's really not much better. This too will explode the number of
 lines in many of my ns declarations.
 
  Is there indeed a reasonably concise way to do this? What is it?
 
  Would it still bother you if the IDE helped maintain the ns
 declaration?
 
  I guess it depends on the details.
 
  If I can completely ignore the ns declaration and tell the IDE, through
 a menu selection or key command, something like Make an ns declaration
 that includes what I need, based on what I call here and where those things
 can be found in the project directory and other reasonable places, and I
 really never have to pay attention to the big mess that it produces for
 that, then that would indeed be quite excellent. Better than what I have to
 do now.

 Here's how I see it: it would change the ns declaration depending on
 the choices you make in the code completion list. That is, the code
 completion list would have to not only be made of what's already
 loaded in the REPL (as is generally the case), but also with all
 possible symbols from libraries currently accessible directly or
 transitively, depending on the project's classpath.
 I even sometimes dream of indexing via lucene all the open source
 libraries available via github, and have the created Index be the base
 for code completion. This would probably be awesome. After all, in a
 project, it's generally the project's source code which changes and
 needs dynamic treatment. The dependencies are generally known in
 advance, computable, and stable.


  But if my actual ns declarations have to get a lot bigger than they are
 now -- that is, if there isn't a reasonably concise way to use :require
 :refer :all in place of :use -- then I would really be dependent on such an
 IDE feature. And if the IDE helps but I still have to pay attention to
 the details then that may still be worse than the current situation.
 
  Seems better to me to leave :use alone and/or to ensure that there's a
 reasonably concise way to get the same effect from :require :refer :all.
 Maybe there is -- nobody has chimed in with it yet but I only posted the
 query this morning.
 
  Of course I'd still really like implicit use what you need and don't
 bother me about it unless you need to -- but I am not holding my breath
 for this :-).
 
   -Lee
 
 
  --
  --
  You 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
  

Re: Can we please deprecate the :use directive ?

2013-07-24 Thread Alex Baranosky
+1 for scary compiler deprecation warning for 1.6.0, then removing :use in
the 1.7.0 release.

On Wed, Jul 24, 2013 at 8:49 AM, Softaddicts lprefonta...@softaddicts.cawrote:

 I disagree, when I use tracing fns and other useful REPL tools,
 I like to have them included without having to prefix them with an alias.

 It's not a hack  it's a feature and you are free to use it or not.
 If code writers do not care about code readers it's a choice, maybe bad but
 that decision is not yours to take. It's theirs in their own context.

 Now this thread has slowly shifted to can we streamline how we express
 this
 feature to lets forbid this feature to be used. If ends up creating such
 policies enforced by the language, it's the wrong route.

 My answer to such proposals is a definite no. This a red line to me that
 should
 not be crossed.

 Luc P.


   I hate it mainly in blogs, where they explain some new API. They :use
  like 3 namespaces and you have to guess which fn is from which ns :)
 
  Agree.
  Code is read much more often than it is written, so omitting a few
  character is not effective time-saving.
  I also don't like :refer :all.
  I think it should be considered hack rather than official feature.
 
  On Wednesday, July 24, 2013 3:17:02 AM UTC+9, Jozef Wagner wrote:
  
   +1, :use is IMO an antipattern.
  
   I hate it mainly in blogs, where they explain some new API. They :use
 like
   3 namespaces and you have to guess which fn is from which ns :)
  
   JW
  
   On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
  
   I think I read somewhere that :use is no longer encouraged, but I
 could
   be mistaken.
  
   From what I've read, it seems like most people agree that Clojure has
 too
   many ways of including/importing/referencing/requiring/using things:
  
  
  
 http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
  
   The above gives a very nice explanation of all the various difference,
   but it also acknowledges their complexity.
  
   Since :use uses :require, and since :require can do everything that
 :use
   can, can we simplify Clojure programming a bit for newcomers by
 deprecating
   the use of :use? The situation in ClojureScript is even worse because
 it
   adds :require-macros on top of all the other ways of including files.
  
   Ideally, it would be awesome if there was just a single directive for
   everything, but perhaps there's some complicated low-level reason why
   that's not possible. :-\
  
   Thoughts?
  
   Thanks,
   Greg
  
   P.S. If this has already been brought up you have my sincere
 apologies.
  
   --
   Please do not email me anything that you are not comfortable also
 sharing
   with the NSA.
  
  
 
  --
  --
  You 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.
 
 
 
 --
 Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!

 --
 --
 You 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: Can we please deprecate the :use directive ?

2013-07-24 Thread Alex Baranosky
If anyone needs help removing all their uses, Slamhound (
https://github.com/technomancy/slamhound) does a decent, though not
perfect, job of automating this.

On Wed, Jul 24, 2013 at 9:16 AM, Alex Baranosky 
alexander.barano...@gmail.com wrote:

 +1 for scary compiler deprecation warning for 1.6.0, then removing :use in
 the 1.7.0 release.


 On Wed, Jul 24, 2013 at 8:49 AM, Softaddicts 
 lprefonta...@softaddicts.cawrote:

 I disagree, when I use tracing fns and other useful REPL tools,
 I like to have them included without having to prefix them with an alias.

 It's not a hack  it's a feature and you are free to use it or not.
 If code writers do not care about code readers it's a choice, maybe bad
 but
 that decision is not yours to take. It's theirs in their own context.

 Now this thread has slowly shifted to can we streamline how we express
 this
 feature to lets forbid this feature to be used. If ends up creating
 such
 policies enforced by the language, it's the wrong route.

 My answer to such proposals is a definite no. This a red line to me
 that should
 not be crossed.

 Luc P.


   I hate it mainly in blogs, where they explain some new API. They :use
  like 3 namespaces and you have to guess which fn is from which ns :)
 
  Agree.
  Code is read much more often than it is written, so omitting a few
  character is not effective time-saving.
  I also don't like :refer :all.
  I think it should be considered hack rather than official feature.
 
  On Wednesday, July 24, 2013 3:17:02 AM UTC+9, Jozef Wagner wrote:
  
   +1, :use is IMO an antipattern.
  
   I hate it mainly in blogs, where they explain some new API. They :use
 like
   3 namespaces and you have to guess which fn is from which ns :)
  
   JW
  
   On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote:
  
   I think I read somewhere that :use is no longer encouraged, but I
 could
   be mistaken.
  
   From what I've read, it seems like most people agree that Clojure
 has too
   many ways of including/importing/referencing/requiring/using things:
  
  
  
 http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
  
   The above gives a very nice explanation of all the various
 difference,
   but it also acknowledges their complexity.
  
   Since :use uses :require, and since :require can do everything that
 :use
   can, can we simplify Clojure programming a bit for newcomers by
 deprecating
   the use of :use? The situation in ClojureScript is even worse
 because it
   adds :require-macros on top of all the other ways of including files.
  
   Ideally, it would be awesome if there was just a single directive for
   everything, but perhaps there's some complicated low-level reason why
   that's not possible. :-\
  
   Thoughts?
  
   Thanks,
   Greg
  
   P.S. If this has already been brought up you have my sincere
 apologies.
  
   --
   Please do not email me anything that you are not comfortable also
 sharing
   with the NSA.
  
  
 
  --
  --
  You 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.
 
 
 
 --
 Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!

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

Re: Can we please deprecate the :use directive ?

2013-07-24 Thread Alex Baranosky
Imo, as soon as you have to maintain other peoples' code that heavily uses
naked use, require starts to look a whole lot nicer.

On Wed, Jul 24, 2013 at 10:14 AM, Lee Spector lspec...@hampshire.eduwrote:


 On Jul 24, 2013, at 12:45 PM, dennis zhuang wrote:
  I am using ':use' for my own namespaces.I know it's discouraged, but if
 i can control my own code,why not? Compiler can give me warnings and i
 process all warnings carefully.

 I agree. But I do now see that it's really just about as good, and better
 for other reasons, to use :require :refer :all instead.

 However, if the language then starts hassling me about using :require
 :refer :all then that will really rain on my parade. I don't want to have
 to jump through hoops to get different parts of my projects to see each
 other. Clojure already requires more of this than I'd prefer -- e.g. no way
 to require a whole subdirectory with a wildcard (and I understand this is
 unlikely to happen) -- and it'd be a drag to have to maintain lists of
 every function name everywhere.

  -Lee

 --
 --
 You 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: anaphoric macro?

2013-07-23 Thread Alex Baranosky
Hi Anders,

(defmacro def-name [name-vec  body]
  `(let ~(vec (interleave (map symbol name-vec)
  name-vec))
   ~@body))

user= (macroexpand '(def-name [a b c] 1 2 3))
(let* [a a b b c c] 1 2 3)

user= (def-name [a b c] a)
a
user= (def-name [a b c] b)
b
user= (def-name [a b c] (str a b))
ab

Best,
Alex

On Tue, Jul 23, 2013 at 12:18 AM, eliassona...@yahoo.com wrote:

 Hi,
 I want to write a macro that introduces new variables from data.
 The data is a vector and looks like this for example: [a b c]

 I want to use the macro like this:
 (def-names [a b c] (str a b))

 What code I want the macro to produce from the above is the following:
 (let [a a
b b
c c]
   (str a b))

 Is it possible to do that?
 Is it a good thing to do that or is it bad practice?

 Thanks
 --anders



 --
 --
 You 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: anaphoric macro?

2013-07-23 Thread Alex Baranosky
Good point BG,

I think it is almost certainly not a good idea :)  But educational,
definitely.

On Tue, Jul 23, 2013 at 12:48 AM, Baishampayan Ghose b.gh...@gmail.comwrote:

 Since the bindings are a function of the data that's passed in, IMO
 you don't need a anaphoric macro for this.

 For example -

 (defmacro def-names [names  body]
   (let [bindings* (vec (mapcat (juxt symbol identity) names))]
 `(let ~bindings*
~@body)))

 As to whether it's a good idea or not, I'd say it depends but YMMV.

 Regards,
 BG

 On Tue, Jul 23, 2013 at 12:48 PM,  eliassona...@yahoo.com wrote:
  Hi,
  I want to write a macro that introduces new variables from data.
  The data is a vector and looks like this for example: [a b c]
 
  I want to use the macro like this:
  (def-names [a b c] (str a b))
 
  What code I want the macro to produce from the above is the following:
  (let [a a
 b b
 c c]
(str a b))
 
  Is it possible to do that?
  Is it a good thing to do that or is it bad practice?
 
  Thanks
  --anders
 
 
 
  --
  --
  You 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.
 
 



 --
 Baishampayan Ghose
 b.ghose at gmail.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.




Re: Design Question: Agents vs. Refs

2013-07-19 Thread Alex Baranosky
I'll second that you are usually doing something unidiomatic if you're
using refs of refs.

On Fri, Jul 19, 2013 at 2:44 PM, vis thevisualist...@gmail.com wrote:

 Good point, I didn't think about that for some reason.
 Yes I will give it a read, thanks for the link!


 On Friday, July 19, 2013 6:19:03 PM UTC+2, Mikera wrote:

 If you want to do in in pure functional style then I would suggest a
 single atom / ref that contains the whole game state (including monsters,
 players, map, items etc.)

 That's the approach I've taken in the two Clojure games I've written so
 far, and it has worked pretty well. You might be interested in the blog
 posts I wrote about Alchemy, a 7 day Roguelike game in Clojure. There's a
 series of these starting with this: http://clojurefun.**
 wordpress.com/2013/03/12/**alchemy-day-1-a-room-with-a-**view/http://clojurefun.wordpress.com/2013/03/12/alchemy-day-1-a-room-with-a-view/

 On Friday, 19 July 2013 16:55:20 UTC+1, vis wrote:

 Hey guys,

 I am playing around with a gameserver in clojure, here is the situation:
 - I have a *ref of a hashmap that holds refs of players*
 - I have a *ref of a hashmap that holds refs of monsters*
 I used refs of players and refs of monsters because at some point I
 might have to transfer things from a player to a monster (like items).
 Since this would be a transaction, refs should be the right choice.

 But now I also need some kind of AI loop for each monster. So my
 question is, what would be the clojure way to do this?
 - use* *a* ref of a hashmap that holds agents of monsters *so I can
 just use send-off for each monster?
 - use a *ref of a hashmap that holds refs of monsters* that each have a
 agent property that I can send things to?
 - or simply use a java.thread for each one?
 - or am I completely missing something?

 Thanks in advance,
 vis

  --
 --
 You 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: easier way to write not not?

2013-07-17 Thread Alex Baranosky
`boolean`.  Agreed.

On Tue, Jul 16, 2013 at 11:13 PM, Shantanu Kumar
kumar.shant...@gmail.comwrote:



 On Wednesday, 17 July 2013 11:42:10 UTC+5:30, JvJ wrote:

 Not that it's a big deal, but is there a standard library function for
 #(not (not %))?


 Just say `boolean` maybe?

 Shantanu

 --
 --
 You 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] simple-sheck - A QuickCheck inspired testing tool

2013-07-16 Thread Alex Baranosky
Hi Reid,

I dig how nicely it integrates with clojure.test.  Does simple-check
implement some form of shrinking?

On Tue, Jul 16, 2013 at 12:20 PM, Reid Draper reiddra...@gmail.com wrote:

 Derp, I fat-fingered my own library name in the subject :)


 On Tuesday, July 16, 2013 2:18:54 PM UTC-5, Reid Draper wrote:

 I'm happy to announce the first non-snapshot version (0.1.0) of
 simple-check, a QuickCheck inspired testing tool: https://github.com/**
 reiddraper/simple-check https://github.com/reiddraper/simple-check.

 simple-check is a fairly faithful port of a subset of Haskell's
 QuickCheck, with some additional inspiration from Erlang QuickCheck. With
 simple-check, you write your tests as a property that holds true for all
 input to your function. So, supposing you were testing the `reverse`
 function, you might say: for all vectors V, the reverse of the reverse of V
 is equal to V. Further, reversing V preserves it's count. simple-check will
 then test your property with some number of random input. If the property
 fails, simple-check will attempt to 'shrink' the input, finding smaller
 input for which the test still fails, where 'smaller' is data-type
 specific. More documentation is available in the README, and API
 documentation: 
 http://**reiddraper.github.io/simple-**check/http://reiddraper.github.io/simple-check/.
 Enjoy, and please don't hesitate with feedback, positive or negative.

 Reid

  --
 --
 You 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: testselector

2013-07-09 Thread Alex Baranosky
At work I noticed that every once in a while we'd forget to add test
selectors to our tests, which means that they may not get executed by CI.
 To prevent this I wrote testselector as a way to periodically check that
all deftests have one of the expected metadatas present.

It is really simple to use with leiningen:

lein run -m testselector.checker . [:unit :integration :end-to-end]
;;   = [#'testselector.checker-test/a-test-without-metadata]


or from the command-line:

(require '[testselector.checker :as checker])
(checker/check #/apps/my-app/ [:unit :integration :end-to-end])


https://github.com/runa-dev/testselector

-- 
-- 
You 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: Can't figure out how to merge this dern map.

2013-07-08 Thread Alex Baranosky
Agreed that it is weird and I never use `into` in that manner, either.

On Mon, Jul 8, 2013 at 9:50 AM, Gary Trakhman gary.trakh...@gmail.comwrote:

 Into is reduce-conj, and this relies on a special-case of conj for maps
 and map entries.  I find it hard to read, so I would vote for apply/reduce
 merge.

 This is weird and unexpected, so please don't:
 user (into {:c :d} [{:a :b}])
 {:c :d, :a :b}
 user (into {:c :d} {:a :b})
 {:c :d, :a :b}



 On Mon, Jul 8, 2013 at 12:30 PM, Max Penet m...@qbits.cc wrote:

 You don't need apply, you can just use into:

 user (into {} [{:apple red and crunchy} nil nil {:Numb 1} nil nil
 {:Field FRUIT.Description}])
 {:apple red and crunchy, :Numb 1, :Field FRUIT.Description}

 On Monday, July 8, 2013 5:01:20 PM UTC+2, VaedaStrike wrote:

 So I have data structure that's equivalent to the following—

 ({:apple red and crunchy} nil nil {:Numb 1} nil nil {:Field
 FRUIT.Description})

 and I'm trying to combine the maps into a single map and I'm just being
 flummoxed

 I tried destructuring it and then applying a merge to the maps while not
 touching the 'nil's but I'm not getting that to work, here's the code I
 tried—


 (def sequ ({:apple red and crunchy} nil nil {:Numb 1} nil nil {:Field
 FRUIT.Description}))
 ::The above is just representing the structure I get from a previous
 parse function.
 ;; If there's a way to alter this so it works with what I'm trying to do
 please
 ;; let me know, or if I'm just doing it all wrong let me know as well!!


 (defn extract-n-merge-map [sequ]
   (let [(a _ _ b _ _ c) sequ]
 (merge a b c)))

 ;; This is giving me unsupported binding form: (a _ _ b _ _ c) at line
 ...

 Basically I'm using instaparse to take a block of code in another
 language and trying to automate it's transformation to a new format.

 I thought that parsing out and taging it's components in a map would
 give me an overall process that would make other such
 automatons in the future much easier, but since this is my first attempt
 at using clojure to do something productive I'm just
 riddled with noobness and it's just getting so frustrating to have
 gotten this far and not being able to figure out how to get over the
 last hump.

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




Re: Domain modelling question

2013-07-06 Thread Alex Baranosky
Hi Marc,

But the domain model I'm thinking of has lots of mutable things that
change over time when I execute the business actions.
In your case, you don't need any STM to model any of your domain.  I'd go
so far as to say that to use refs for this is almost certainly a mistake.

Of course the history is also required in the solution. It must be
possible to answer the question 'what feature was booked 2 months ago'.
You can get by swimmingly by passing an immutable data structure around for
this, and amending it as you go.

Do I have a bunch of customer functions that all get a customer map or
defrecord as first parameter and maybe other required parameters to do the
business work
Yes, this is a good approach in my experience.  (You likely don't need to
use defrecords, plain hash maps work great here)

To persist your state you can store it in some DB and have a namespace that
acts as a storage layer for it.  Then you can stub the storage layer
functions in unit tests.  Some people might use a protocol for the storage
layer, and have an in-memory version for tests and another that uses an DB
for use in production.

But these structures are somehow nested, aren't they?
You can always have nested maps.  Maybe I misunderstood your question here?

Best,
Alex

On Sat, Jul 6, 2013 at 4:02 AM, Chris Ford christophertf...@gmail.comwrote:

 I find the modelling Clojure data structures very similar to working out
 what your aggregates roots are for domain-driven design or using a document
 data store.

 I would suggest avoiding using refs in a customer map. In this case, it
 sounds like customer is your natural aggregate root, so you should embed
 your subordinate domain objects e.g. contracts directly in the customer
 map. When you want to add or modify a contract, do it by making a whole new
 customer map e.g. by using the update-in fn. That way your customer's
 timeline is a progression of immutable customer states.

 I would try and reserve references and mutability for multi-threaded
 situations.

 My two UGX,

 Chris


 On 6 July 2013 02:26, Marc Schneider snr@gmail.com wrote:

 Hello,

 I'm trying to implement some business model in Clojure. I have several
 years of experience developing OO systems in Java. So it's still very hard
 to wrap my head to functional thinking. I hope you can help me with
 following questions.

 I need a domain model for customers, contracts and features.

 Customers need to be created and modified.

 You can add one or more contracts to customers. But only one contract can
 be active at a given time for a customer.

 Within a contract you can add or remove features. Doing this should
 create a bill. A bill is not modifiable after creation.

 The business rules are more complex in reality but I would be happy to
 get some inspirations how to implement such a thing with Clojure.

 Functional programming has these immutability building block. But the
 domain model I'm thinking of has lots of mutable things that change over
 time when I execute the business actions.

 Of course the history is also required in the solution. It must be
 possible to answer the question what feature was booked 2 months ago.

 I started a solution where a customer was a map that had some refs to
 other maps. Then I had functions to alter the content of the refs. But code
 looks ugly and using it doesn't feel functional.

 How should I structure data? Where are the functions? Do I have a bunch
 of customer functions that all get a customer map or defrecord as first
 parameter and maybe other required parameters to do the business work? And
 another similar bunch of functions for contracts, features and bills? But
 these structures are somehow nested, aren't they?

 If structure will become more clear to me, then the next questions will
 go to the how can I persist and load all my state direction. I would be
 very glad if you could give me hints how I can solve this in a Clojure /
 functional way. I want to abstract it so that I can use some placeholder
 code in tests without the need for a real database.

 That's quite a lot my brain is thinking about. I hope it's not too much
 to find any help here. Maybe there are some example applications out there
 where I can find some ideas? All I found yet are only small snippets but no
 working in the field with business meat :-)

 Thanks a lot in advance for your help. If anything is unclear to you
 please tell me and I will try to describe my problems more clearly.

 Marc

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

Re: core.async

2013-06-28 Thread Alex Baranosky
Very cool stuff.

One point of feedback though: I thought Clojure Core had done a great job
of avoiding a Haskell-like symbol-heavy.  I might've been mis-informed, but
I thought this tendency to avoid  symbol-heavy naming was intentional.  For
example, instead of `-?` in 1.5 we got `some-`. I thought it was a great
compromise for readability.  In core.async, we've got a lot more symbols.
 Are people in love with names like `!` and `!!`, or is there room for
rethinking the naming?

Best,
Alex

On Fri, Jun 28, 2013 at 12:50 PM, Nahuel Greco ngr...@gmail.com wrote:

 I forgot the second Ulf Wiger link, related to the previous one:
 http://www.infoq.com/presentations/Death-by-Accidental-Complexity

 Saludos,
 Nahuel Greco.


 On Fri, Jun 28, 2013 at 4:46 PM, Nahuel Greco ngr...@gmail.com wrote:

 Very nice! Selectable channels FTW.

 Btw, are you aware of the Erlang selective-receive model? Is often very
 overlooked but it showed big advantages over unfiltered channels. See this:
 http://www.erlang.se/euc/05/1500Wiger.ppt

 Saludos,
 Nahuel Greco.


 On Fri, Jun 28, 2013 at 4:06 PM, Rich Hickey richhic...@gmail.comwrote:

 I've blogged a bit about the new core.async library:

 http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html

 Please try it out.

 Thanks,

 Rich

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/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: Database migrations

2013-06-14 Thread Alex Baranosky
Inspired by Technomancy's suggestion to try a simpler approach to
migrations on IRC, I came up with this tiny library based heavily on code
from the clojars repo, that Phil pointed me to.  Personally, I thought
Ragtime and Lobos, were overkill.

https://github.com/runa-dev/kits/blob/master/src/kits/db_migrator.clj

On Fri, Jun 14, 2013 at 3:32 PM, Juha Syrjälä juha.syrj...@gmail.comwrote:

 There are also following libraries to handle migrations:

 Ragtime: https://github.com/weavejester/ragtime
 Lobos: https://github.com/budu/lobos

 Lobos has its own DSL to implement database manipulation. Ragtime uses
 normal Clojure functions instead.


 On Friday, June 14, 2013 7:24:39 PM UTC+3, Reginald Choudari wrote:

 Hello all,

 I am trying to implement database migrations with Clojure. So far I have
 been looking at Drift 
 (https://github.com/**macourtney/drifthttps://github.com/macourtney/drift)
 as a candidate for implementing this. My question is, does anyone have a
 database migration workflow that they use and would like to share? One
 problem I have been thinking is how to tackle database credentials/db name
 configuration. I know in Rails its common to use a YAML to provide this
 info, wondering if there was something more idiosyncratic to clojure?

 Thanks in advance

  --
 --
 You 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: [job opening] DRW (http://drw.com) is looking for a Sr. Software Engineer - Clojure/JRuby

2013-06-07 Thread Alex Baranosky
Hi Jay,

I'm interested in DRW, but am pretty sure the offices are in New York /
Chicago right?  I'm not sure I could convince my significant other to move
away from the Bay Area.

I've been working with Runa for a year, have a lot of experience with
testing and JVM languages.

Github: https://github.com/AlexBaranosky
LinkedIn: http://www.linkedin.com/profile/view?id=97009666trk=tab_pro

Best,
Alex

On Fri, Jun 7, 2013 at 6:56 AM, Jay Fields j...@jayfields.com wrote:

 DRW (http://drw.com) is looking for a Sr. Software Engineer -
 Clojure/JRuby

 more info:
 http://drw.submit4jobs.com/index.cfm?fuseaction=83084.viewjobdetailCID=83084JID=149069

 My experience working for DRW:
 http://blog.jayfields.com/2013/04/year-five.html

 Drop me a line if you want more info.

 Cheers, Jay

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/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 diffs

2013-06-07 Thread Alex Baranosky
Thanks for remembering gui-diff Denis :)

I actually left it out of my post, having forgotten about it, even though I
use it multiple times a day, and couldn't get by without it in my workflow
anymore.

Best,
Alex

On Fri, Jun 7, 2013 at 12:47 AM, Dennis Haupt d.haup...@gmail.com wrote:

 intellij can do exactly what you want


 2013/6/7 Moocar anthony.mar...@gmail.com

 Hi all,

 Diffs for clojure code (and lisps in general) can be hard to read. Every
 time we wrap a form, any lines below are indented. The resulting diff just
 shows that you've deleted lines and added lines, even though you've only
 changed a few characters.

 What diff tools do people use to address this? I've found ediff is useful
 in emacs, but what I really want is a way to see good diffs in github pull
 requests.

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




Re: clojure diffs

2013-06-06 Thread Alex Baranosky
Intellij diffs, FileMerge, or Meld - they all highlight the words that
changed not just the lines.

On Thu, Jun 6, 2013 at 7:57 PM, John D. Hume duelin.mark...@gmail.comwrote:

 One neat hidden Github feature is that if you add the query string
 parameter w=1 to any diff view, it will ignore whitespace-only changes
 (like passing -w to git diff).
 That doesn't help with those final lines with added or removed close
 parens, but it still improves readability of many diffs.

 https://github.com/blog/967-github-secrets
 On Jun 6, 2013 9:31 PM, Moocar anthony.mar...@gmail.com wrote:

 Hi all,

 Diffs for clojure code (and lisps in general) can be hard to read. Every
 time we wrap a form, any lines below are indented. The resulting diff just
 shows that you've deleted lines and added lines, even though you've only
 changed a few characters.

 What diff tools do people use to address this? I've found ediff is useful
 in emacs, but what I really want is a way to see good diffs in github pull
 requests.

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




Re: Best IDE

2013-06-04 Thread Alex Baranosky
There are things I love and hate about both Emacs and Intellij, so after a
year of working professionally with a bunch of Clojure-Emacs users, I still
end up using Intellij about half the time, and get my fair share of
harassment over it.  I'd like to merge the two actually if possible.

On Tue, Jun 4, 2013 at 7:20 AM, Gary Trakhman gary.trakh...@gmail.comwrote:

 I used eclipse emacs+ for about a year for java code once I had started
 writing clojure in emacs, it made me more productive, but it was a hassle
 to set up.

 Unfortunately, when eclipse updated itself to juno, it broke, and there is
 still no support.

 Going forward, I think this is a more compelling solution to get some of
 the benefits of eclipse in emacs: https://github.com/senny/emacs-eclim

 But, I think it's not quite there yet.


 On Tue, Jun 4, 2013 at 9:02 AM, Kelker Ryan theinter...@yandex.comwrote:

 Have you tried Eclipse Emacs+?
 http://marketplace.eclipse.org/content/emacs

 04.06.2013, 21:41, Korny Sietsma ko...@sietsma.com:

 My 2c - I use emacs, I love it.  I don't inflict it on my team, and I
 strongly disagree with it being easy.  To learn the basics, yes, but full
 fluency?  If you have someone fluent in IntelliJ, with the major keystrokes
 in their muscle memory, and an instinctive familiarity with all the gui
 features, they are not going to be as productive in emacs in a hurry.

 Also, while I love the power of emacs, it's really struggling these days
 with the text-only idiom.  Speedbar is no replacement for a graphical
 directory tree.  Coloured text blocks next to modified lines is no
 replacement for being able to hover over a changed line and having a pop-up
 (a real pop-up, that is) tool tip that shows you the changes since the last
 commit.  And don't get me started on selecting fonts and other
 customizations...

 For an IDE for someone not from a vim/emacs background, I'd use whichever
 of Intellij or Eclipse is most familiar.  Eclipse is more clojure-friendly,
 but it has many warts as well - if you know IntelliJ, it's clojure plugin
 is definitely good enough.

 - Korny



 On 3 June 2013 00:05, Wei Qiu w...@qiu.es wrote:

 Hi,

 I used to use slimux+tmux combination until I find vim-fireplace.
 It's really cool. For me it makes life much easier.


 On Wednesday, January 18, 2012 8:35:34 PM UTC+1, Jeb wrote:

 Any suggestions for a vim man?
 On Wed, Jan 18, 2012 at 1:29 PM, Cedric Greevey cgre...@gmail.comwrote:

 On Wed, Jan 18, 2012 at 11:18 AM, Jay Fields j...@jayfields.com wrote:
  Use emacs, if you want the path of least resistance

 *boggles*

 Say WHAT?

 You've got to be kidding. That's like suggesting that the path of
 least resistance in taking a trip to L.A. involves climbing the north
 face of Everest instead of using an airplane. In particular, the
 learning curve of emacs and the north face of Everest, in a shocking
 coincidence, turn out to have exactly the same geometry. :)

 --
 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=enhttp://groups.google.com/group/clojure?hl=en




 --
 Jeb Beich
 http://www.red-source.net/jeb


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






 --
 Kornelis Sietsma  korny at my surname dot com http://korny.info
 .fnord { display: none !important; }


 --
 --
 You 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: alter a map in a vector (reference)

2013-06-03 Thread Alex Baranosky
You *can* update this inside the vector, but if you want to key by :id, I
would personally recommend, you put the email data into a map and look it
up by :id, like this:

{1 {:id 1 :email {a...@mail.com 1}}
  2 {:id 2 :email {d...@mail.com 1}}
  3 {:id 3 :email {g...@mail.com 2}}}

Best,
Alex

On Mon, Jun 3, 2013 at 1:44 PM, Yinka Erinle yeri...@gmail.com wrote:

 Thanks Meikel for the prompt reply, that does it.

 Please can you elaborate on how I can use the solution below to update a
 particular entry in the vector.

 [{:id 1 :email {a...@mail.com 1}}
   {:id 2 :email {d...@mail.com 1}}
   {:id 3 :email {g...@mail.com 2}}]

 So I will like to write a function that accepts an id and then updates the
 counter in email section of the given id.

 (defn update-counter [x xs]
(dosync
   (alter result ..

 Thanks again for your time.


 On Monday, June 3, 2013 9:23:47 PM UTC+1, Meikel Brandmeyer (kotarak)
 wrote:

 Hi,

 Am Montag, 3. Juni 2013 22:16:54 UTC+2 schrieb Yinka Erinle:

 Given I have the following
 (def result (ref [ { :id 1 :emails { yi...@mail.com 1}} ] ) )

 I like to alter the result in a transaction to become
 [{:id 1 :emails { yi...@mail.com 2}}]; increment the counter from
 1 to 2

 Please can someone provide pointers.


 You can use the uniform update principle to stitch together alter and
 update-in.

 (dosync
   (alter result update-in [0 :emails a@b.c] inc))

 Kind regards
 Meikel


  --
 --
 You 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: Use of io!

2013-05-30 Thread Alex Baranosky
Do any of you ever use io! ?  I've never used it, but could see using it if
I had a transaction-heavy application.

On Wed, May 29, 2013 at 11:43 PM, Michael Klishin 
michael.s.klis...@gmail.com wrote:

 2013/5/30 Josh Kamau joshnet2...@gmail.com

 Whats the point of using io! inside dosync if all it does is make an
 exception to be thrown?


 The point is to mark side-effecting code so that you can't accidentally
 use it in a transaction.
 --
 MK

 http://github.com/michaelklishin
 http://twitter.com/michaelklishin

 --
 --
 You 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: Structing Clojure tests/setup and tear down

2013-05-21 Thread Alex Baranosky
I tend to have macros for different types of setup/teardowns.  Mostly
because clojure.test fixtures always want to wrap *every* test in a file.

On Tue, May 21, 2013 at 9:41 AM, Colin Yates colin.ya...@gmail.com wrote:

 No worries ;)


 On 21 May 2013 17:18, Ulises ulises.cerv...@gmail.com wrote:

 Hey Colin,

 Apologies, I missed your First - I know about fixtures... line :)

 I'd probably +1 Gaz's macro (I've not tested it either but it looks
 reasonable.)


 On 21 May 2013 16:05, Colin Yates colin.ya...@gmail.com wrote:

 Hi Ulises,

 I don't think I am as that would require essentially a fixture per
 distinct combinations of test state, which is almost the same number of
 tests.

 Have I missed something?


 On 21 May 2013 15:51, Ulises ulises.cerv...@gmail.com wrote:

 Perhaps you're looking for fixtures?
 http://thornydev.blogspot.co.uk/2012/09/before-and-after-logic-in-clojuretest.html

 U


 On 21 May 2013 15:17, Colin Yates colin.ya...@gmail.com wrote:

 Howdy,

 I am using clojure.test and have some questions of how to write
 idiomatic Clojure.  This really isn't about testing at all per-se.

 First - I know about fixtures to get (at least) the same as JUnit's
 before/after behaviour.

 My code is a bloomy.  You can configure the bloomy and it does
 different things based on that behaviour.  Pretty much every test has a
 different bloomy, *and* that bloomy must be elegantly shut down.

 How should I handle this?

 At the moment I have the most un-idiomatic way and blunt way of :

 [code]
 (deftest my-test
   (let [bloomy (create-a-bloomy]
   (try
 (do-something-with-my-bloomy)
 (is (=))
   (finally (shut-down bloomy
 [/code]

 Yep, try/finally in every test - reminds me of early JDBC libraries
 before Spring :).  If I understand it correctly, I would end up writing a
 separate fixture for each and every test, or at least each any every 
 unique
 set of test context.

 I did consider writing a (defn with-bloomy [bloomy test] (try (test)
 (finally (shut-down bloomy but I couldn't figure out how to pass my
 bloomy into the test itself.  I also received lots of assertion not in
 expectation type errors.  To be explicit I would use this as 
 (with-bloomy
 (create-a-bloomy) (deftest...))).

 I did consider a variation on the above of passing in a function which
 only contained the assertions, so (deftest my-test (let [bloomy...]
 (with-bloomy bloomy #(is (= 1 (get-something bloomy) but I also ran
 into similar assertion not in expectation type errors, and the
 indentation in emacs was insane.

 I expect a macro might be the answer?

 So, how would you solve this?

 --
 --
 You 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 a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojure/Pm-DUDxWeM4/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, 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 

Re: [ANN] getclojure.org

2013-05-16 Thread Alex Baranosky
Really cool.  Thanks!

On Thu, May 16, 2013 at 8:04 PM, Devin Walters dev...@gmail.com wrote:

 Thanks for trying it out!

 One hint to people trying it out would be to not put too much stock into
 the first page of results. The plan is to add user ratings to augment
 search results in a meaningful way. At the moment searching for comp will
 give you the most relevant examples like: (comp comp comp comp comp
 comp), which is far from idiomatic or useful. Once ratings are added and
 weighted appropriately the first page of results should start to turn into
 a more idiomatic/instructive stew.

 Cheers,
 --
 {:∂evin :√valters}

 On Thursday, May 16, 2013 at 9:55 PM, Leon Talbot wrote:

 This project is actually very useful for learning clojure one (or two!)
 function at a time. Thanks a lot!

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




Re: Utility libraries and dependency hygiene

2013-05-13 Thread Alex Baranosky
Yes, by all means please just copy-n-paste out of
https://github.com/runa-dev/kits if it simplifies your dependency tree.

On Sun, May 12, 2013 at 8:53 PM, Dave Kincaid kincaid.d...@gmail.comwrote:

 Thanks for this, Stuart. I hope it's not too late. As one who has spent
 the last couple weeks spinning up a new project that uses its own local Ivy
 repository I've been feeling this pain first hand. The number of
 dependencies I have had to add just for a few Clojure libraries has been
 quite painful. I attributed it to how young the language is that these
 utility libraries haven't had time to consolidate.


 On Sunday, May 12, 2013 6:29:28 PM UTC-5, Stuart Sierra wrote:

 Based on a recent thread about utility libraries, I would like to
 take this opportunity to ask everyone to help us avoid the dependency
 mess that Common Lisp has gotten into, where there are over a dozen
 such convenience libraries[1].

 By all means, use these libraries in your *applications* if you find
 them useful. But please don't make your *libraries* depend on them
 unless you really need to.

 Doing this will help application developers who want to use your
 library. For example, if my application depends on libraries A, B, and
 C, I might end up with transitive dependencies on three different
 utility libraries. If I want to add library D which depends on an
 incompatible version of one of those utilities, I'm stuck. By
 adding to the dependencies of your library, you increase the
 likelihood of dependency conflicts for consumers.

 The ideal number of dependencies for a library release (not counting
 Clojure itself) is zero. Obviously, use common sense. If your library
 relies on critical functionality in another library, then make the
 dependency. But if you can get by without the dependency (even if that
 means copying some of those utility functions into your own code and
 making them private) then you will make life easier for consumers of
 your library.

 Thanks, and happy coding.
 -S


 [1]: 
 http://cliki.net/Convenience%**20libraryhttp://cliki.net/Convenience%20library

  --
 --
 You 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: Why is using (not (empty? coll)) not idiomatic?

2013-05-11 Thread Alex Baranosky
Most of the code I see and write at work at Runa uses (not (empty? foo)).
 I'll continue to defend the position that it is more obvious code, and
therefore better (imo :) )

Alex

On Sat, May 11, 2013 at 12:22 PM, Karsten Schmidt i...@toxi.co.uk wrote:

   What's the idiom in (seq coll)?

 Maybe one could say that, generally, in Clojure it's more meaningful
 to work with truthy values instead of the boolean true... ?

 --
 --
 You 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: Why is using (not (empty? coll)) not idiomatic?

2013-05-11 Thread Alex Baranosky
Sean,

I'd tend to write things like that, yeah.

On Sat, May 11, 2013 at 2:49 PM, AtKaaZ atk...@gmail.com wrote:

 I agree


 On Sat, May 11, 2013 at 10:25 PM, Alex Baranosky 
 alexander.barano...@gmail.com wrote:

 Most of the code I see and write at work at Runa uses (not (empty? foo)).
  I'll continue to defend the position that it is more obvious code, and
 therefore better (imo :) )

 Alex


 On Sat, May 11, 2013 at 12:22 PM, Karsten Schmidt i...@toxi.co.ukwrote:

   What's the idiom in (seq coll)?

 Maybe one could say that, generally, in Clojure it's more meaningful
 to work with truthy values instead of the boolean true... ?

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




-- 
-- 
You 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: kits 1.5.1 - some of Runa's core utilities

2013-05-09 Thread Alex Baranosky
Runa has decided to open source a project of our utility namespaces that we
call Runa Kits https://github.com/runa-dev/kits. At this point in time
this includes:

   - benchmark.clj ;; simple timing functions
   - csv.clj ;; wrapper around clojure-csv library that turn csv in to
   column-name, column-value key value pair that can be configured via
   :key-fn, :val-fn and :reader for each field
   - db_migrator.clj ;; simple SQL schema migration library
   - foundation.clj ;; catchall ns of utils
   - homeless.clj ;; another catchall ns of utils
   - logging.clj ;; Simple wrapper library for java.util.logging
   - map.clj ;; Functions that operate on Clojure maps
   - match.clj ;; Supports the speed optimized 'matches?' macro and
   'fmatches?' fn for checking if a string matches a sequence of strings or
   wildcard strings
   - queues.clj ;; Wrappers for constructing various java.util.concurrent
   queues
   - runtime.clj ;; Library to access run-time info from the JVM
   - seq.clj ;; Functions that operate on Clojure sequences
   - string.clj ;; Functions that operate on Strings or Keywords
   - structured_logging.clj ;; Logging Clojure data as JSON: supports :tags
   and log contexts
   - test_utils.clj ;; Functions and macros for making writing tests more
   effectively
   - timestamp.clj ;; Functions for creating and formatting timestamps
   (Longs)
   - xml.clj ;; To simplify working with clojure.xml

These are tools we use everyday, and have not been spiffed up with many doc
strings.  In general these kits are offered up for use by the community
as-is, and we hope you find something of use in there.

Best,
Alex

-- 
-- 
You 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: [OT] Re: More idiomatic way to use map like this?

2013-05-03 Thread Alex Baranosky
I concur with Timothy's assessment.  Really well stated and illustrated use
of reduce with a named reduce function.


On Fri, May 3, 2013 at 10:52 PM, Timothy Baldridge tbaldri...@gmail.comwrote:

 In general, loop/recur shouldn't be considered idiomatic, IMO. Instead,
 try for a more functional style:


 due = 100
 cards = cards.map do |card|
 card.applied_balance = max(0, due - card.balance)
 due -= card.applied_balance

 becomes (untested):

 (defn apply-balance-1 [{:keys [due] :as accum} [card-id balance]]
   (let [applied (max (- due balance))]
 (- accum
  (assoc-in [:applied card-id] applied)
  (assoc-in [:due] due


 (reduce apply-balance-1
 {:due 100}
 {:card-id-1 4404.00
  :card-id-2 3020.00
  etc})

 Often I have found that using reduce forces me to break functions into
 several parts. If I used loop/recur, normally the function prelude,
 postlude and loop block are all smashed into a single function. With reduce
 + a do-step-1 function (as seen above) we can more easily reason about what
 is happening. The code is then easier to test as well, as we can test the
 calculations apart from the loop logic.

 When I'm performing Clojure code reviews, I often consider loop/recur to
 be a code smell.

 Timothy



 On Fri, May 3, 2013 at 3:53 PM, Armando Blancas abm221...@gmail.comwrote:

 On Friday, May 3, 2013 1:15:24 PM UTC-7, Robert Pitts wrote:

 Armando was a good citizen and sent along a plain-text version as well –
 https://groups.google.com/**group/clojure/msg/**
 6aae8287bc55d436?dmode=source**output=gplainnoredirecthttps://groups.google.com/group/clojure/msg/6aae8287bc55d436?dmode=sourceoutput=gplainnoredirect


 That must have been Google Groups doing the right thing... nice feature.

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






 --
 “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/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.




  1   2   3   >