Re: Architectural doubts

[Ashton Kemerling]

Because of the way that Datomic stores it's data (5 tuples: entity, 
attribute, value, transaction, and operation) it has some pretty simple 
indexes that allow for powerful queries. EAVT allows for rapidly searching 
by entity, VAET allows for quick reverse look ups, etc. The only index that 
you get to choose on is the AVET index, that allows for searching across an 
attribute (column level search in the relational world), and that's toggled 
by the :db/index attribute on the schema. Which index a query uses depends 
on what you're trying to do with datalog, it's pretty much out of the users 
hands unless if you start using the raw index API.

The current word from the Datomic team is that they highly recommend 
leaving the index on for all attributes, as it consumes small enough 
amounts of data in most scenarios. Datomic is also pretty good at keeping 
only useful indexes in memory, so you should probably be fine.

--
Ashton

On Sunday, February 1, 2015 at 5:31:37 AM UTC-7, Milton Silva wrote:
>
> For now I'm hand coding a big loop with transients and a bytebuffer. It is 
> an incredibly ugly imperative mess but, it is fast enough and so far it 
> fits nicely into ram.
> It takes 2s (at this point gloss was taking upwards of 5 minutes) to 
> decode 200MB all the way to tcp and uses 500MB of heap. This is faster than 
> wireshark(10s) but a bit more memory hungry. Will see how it responds when 
> decoding diameter, so far that part is stored as byte-arrays.
>
> Thank you for the pointers with datomic. Are the indexes created 
> automatically or do I need to specify them on the schema?
>
>>  

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

[Ashton Kemerling]

Also remember to give the JVM some warm up time, as the JVM depends heavily 
on JIT style optimizations, and measuring performance without it might not 
represent real world behavior,

--
Ashton

On Saturday, January 31, 2015 at 11:39:05 PM UTC-7, Mars0i wrote:
>
> You also might want to use Criterium 
>  rather than *time *for accurate 
> benchmarking*.*
>
> On Friday, January 30, 2015 at 6:54:52 AM UTC-6, Maris wrote:
>>
>>
>> yes,  it helped :-)
>>
>> type hints make non-trivial difference   
>>
>> thank you
>>
>> On Friday, 30 January 2015 12:43:40 UTC, Nicola Mometto wrote:
>>>
>>>
>>> If you set! *warn-on-reflection* to true, you'd see a lot of reflection 
>>> warnings from your code. 
>>>
>>> Type-hinting the code like this: http://sprunge.us/ATiV makes your 
>>> example execute in 120ms on my machine. 
>>>
>>> Maris writes: 
>>>
>>> > I implemented leftist heap (from Purely Functional Data Structures 
>>> book) 
>>> >  in clojure. 
>>> > 
>>> > https://gist.github.com/maruks/135fef92455578b61de2 
>>> > 
>>> > It takes 32 seconds to insert 10 elements in heap: 
>>> > 
>>> > (time  (peek   (reduce conj (empty-heap)  (range 1000 2000 
>>> 100) 
>>> > ))) 
>>> > "Elapsed time: 32649.71438 msecs" 
>>> > 1000 
>>> > 
>>> > Why is it so much slower than SML NJ?  Something wrong with my code? 
>>> > 
>>> > 
>>> > Here is SML version: 
>>> > https://gist.github.com/maruks/c863eac9cf057a071307 
>>> > 
>>> > And function that inserts 10 elements in *54* milliseconds ! 
>>> > 
>>> > fun test(n:int) : int  = 
>>> > let 
>>> > val r = List.tabulate(n, fn x => 1000 + 100 * x) 
>>> > val h = foldl ( fn (e, h) => IntHeap.insert(e , h) )  IntHeap.empty  r 
>>> > in 
>>> > IntHeap.findMin(h) 
>>> > end 
>>>
>>> -- 
>>>
>>

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

[Ashton Kemerling]

A lot of the slowness in Clojure comes down to how slow it is to load the 
main namespaces that are needed, especially clojure.core (see this post 

). 

You should also look into the Clojure fastload branch, which apparently 
helped out a few Android programmers according to the clojure-android 
google list. 

On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote:
>
>
> On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote:
>>
>> Hello Everyone,
>>
>> Basically the approach is this: cljs -> js -> rhino [3] -> bytecode. 
>>  Provides java interop through rhino.  By the time things get to rhino, 
>> google closure has already thrown away most of the runtime away since we 
>> didn't use it, and we end up with manageable amount of JS which is compiled 
>> to manageable amount of byte code.   All of jvm is still available.
>>
>
> Sounds like the clojure compiler could benefit from dead code elimination. 
> I'm not sure if that is possible or not but it does sound like it might 
> work. Compiles would probably take longer so the gains might be offset by 
> longer compile times. If this is the case then it wouldn't help development 
> workflows but could provide deployment/runtime gains.
>
> I'm wondering if the availability of eval in clojure and the lack of it in 
> clojurescript makes a difference - it might lead to some code that can't be 
> properly analyzed.
>
> Alan
>
>

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

[Ashton Kemerling]

I've had good luck with lein prism to cut out any annoying lein startup time. 
Mixed in with cider when I want to run one test works nicely for me. 

https://github.com/aphyr/prism/

--Ashton

Sent from my iPhone

> On Jan 8, 2015, at 7:32 AM, Malcolm Sparks  wrote:
> 
> LISP systems work better when they are continually up-and-running. Take Emacs 
> for example. Clojure systems aren't much different. 
> 
> I prefer to think of lein more as a launch tool than a build tool.
> 
> I don't think anyone has mentioned it on this thread yet, but lots of people 
> are using Stuart Sierra's component workflow for precisely this reason - you 
> can make changes and see the effects very quickly simply by typing (reset) 
> into the REPL. See https://github.com/stuartsierra/component
> 
> For a working example of incremental compilation, see 
> http://modularity.org/templates/dashboard.html - it will recompile your 
> ClojureScript and Less css files incrementally, and can do so because it can 
> keep context between resets. It's possible to add 'test' components which 
> will run your tests after every reset. I don't have any templates 
> demonstrating that yet, but I have seen people do it.
> 
> 
>> On Thursday, 8 January 2015 14:20:56 UTC, Andrea Crotti wrote:
>> Ah great that's what I wanted, I'll try later. 
>> Does it give some feedback on what it's compiling and what is going on? 
>> 
>> I would use just cider in theory but I had some errors with namespaces 
>> (probably my fault) and more importantly it seemed that it didn't 
>> always recompiled things that were changed (again probably my fault). 
>> 
>> So in short only changing dependencies should require a new "lein 
>> test" or "lein deps"? 
>> 
>> And this useful plugins do you normally put them in your 
>> ./lein/profiles.clj or in every project you have? 
>> 
>> thanks a lot 
>> 
>> 2015-01-08 11:41 GMT+00:00 Robin Heggelund Hansen : 
>> > The reason lein is initially slow, has to do with Clojures bootstrapping 
>> > process, which is slow. People tend to avoid starting clojure programs 
>> > repeatedly, and thus do alot of work from the repl, or using leiningen 
>> > plugins which keeps running and listens for changes. 
>> > 
>> > Take a look at lein-test-refresh for tdd: 
>> > 
>> > https://github.com/jakemcc/lein-test-refresh 
>> > 
>> > It detects when you change your code, incrementally compiles and re-runs 
>> > the 
>> > tests. It runs your tests everytime you save a file :) 
>> > 
>> > kl. 12:32:44 UTC+1 torsdag 8. januar 2015 skrev Andrea Crotti følgende: 
>> >> 
>> >> Hi guys, 
>> >> 
>> >> I'm starting to use Clojure a bit more seriously, I knew already Lisp a 
>> >> bit and Haskell, in plus I've been using Emacs for a long time so 
>> >> luckily it's not as hard, and it's a lot of fun. 
>> >> 
>> >> I'm using Emacs + Cider for development and it works wonderfully, 
>> >> however I have a few problems/questions trying to do TDD. 
>> >> 
>> >> 1. Isn't it possible to make Lein more verbose? 
>> >> 
>> >>It's often quite slow and it would be nice to know what is going 
>> >>on, I can stand the slowness but at least tell me something :D 
>> >> 
>> >> 2. When is exactly that I need to run again "lein test" (which is 
>> >>painfully slow) and when just rerunning the tests from the same REPL 
>> >>suffice? 
>> >> 
>> >>I thought only when changing dependencies, but I had different 
>> >>experiences so I'm not too sure about the rule. 
>> >> 
>> >>And what command exactly is Cider triggering when I run the tests? 
>> >>It would be nice to be able to see somewhere more information like: 
>> >>- compiling file x 
>> >>- running tests for y with command z 
>> >> 
>> >>  3. Does incremental compilation work well/make sense for Clojure? 
>> >> I found something but the fact that it's not done straight away in 
>> >> Leiningen makes me think it's maybe not much used? 
>> >> 
>> >> Thanks a lot, and congratulations to all the developers for the great 
>> >> language! 
>> > 
>> > -- 
>> > 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 

Re: is there a shorter way to do this in core.logic ?

[Ashton Kemerling]

I'm no expert, but I think no, at least not in any way you'd want to maintain. 

Also, if that's all of your core.logic code, that's pretty damned short and 
clear. I can read and understand that right away. 

--Ashton

Sent from my iPhone

> On Jan 4, 2015, at 2:43 AM, rogergl  wrote:
> 
> The following snippet works
> 
> (fresh [?row ?col]
> (fd/+ row 1 ?row)
> (fd/+ col 1 ?col)
> (membero {:row ?row :col ?col} data)))] ; check 
> existence of  {:row (?row + 1) :col (?col + 1)} 
> 
> But I'm not sure if this isn't to verbose.
> 
> The question is: Is it really neccessary to bind to row and col or ist there 
> a shorter way ?
> 
> Regards
>   Roger
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: lazy-seq performance

[Ashton Kemerling]

I was going to say that testing JVM programs is notoriously tricky due to JIT 
warm up. Did you run that function enough to warm it before taking your timings?

This is why micro benchmark frameworks are popular. 

--Ashton

Sent from my iPhone

> On Dec 31, 2014, at 7:04 PM, Daniel  wrote:
> 
> The first thing that jumps out at me are the boxed numbers: 0N and 1N.  I'm 
> guessing the Clojure implementation can produce a much larger result than the 
> python implementation can - so, apples to oranges.  Probably unbox the 
> numbers and you get much more comparable speed.
> 
> Also, you should definitely do two things when running speed comparisons:
> 
> 1. Make sure the JVM flag -server is configured.
> 2. Test with Criterium.  (https://github.com/hugoduncan/criterium)
> 
>> On Wednesday, December 31, 2014 2:03:03 PM UTC-6, Sakis K wrote:
>> Hi,
>> 
>> Clojure newbie here :) I'm reading "Programming Clojure" by Halloway and 
>> Bedra. In the book there is a lazy-seq example of the Fibonacci sequence:
>> 
>> (defn lazy-seq-fibo
>>   ([]
>>  (concat [0 1] (lazy-seq-fibo 0N 1N)))
>>   ([a b]
>>  (let [n (+ a b)]  
>>(lazy-seq   
>> (cons n (lazy-seq-fibo b n))
>> 
>> 
>> I like the flexibility of this implementation but I am a bit sceptical about 
>> its performance:
>> 
>> user=> (time (rem (nth (lazy-seq-fibo) 100) 1000))
>> "Elapsed time: 53552.014713 msecs"
>> 875N
>> 
>> 
>> 
>> Here's a Python implementation taken from 
>> http://en.literateprograms.org/Fibonacci_numbers_%28Python%29
>> 
>> def fib(n):
>> a, b = 0, 1
>> for i in range(n):
>> a, b = b, a + b
>> return a
>> 
>> if __name__ == '__main__':
>> print(fib(100) % 1000)
>> 
>> 
>> time python fib.py 
>> 875
>> 
>> real0m16.609s
>> user0m16.475s
>> sys 0m0.115s
>> 
>> 
>> 53 vs 17 seconds is a big gap. Is there a way to achieve better performance 
>> in Clojure? Maybe the fact that I executed the code in the REPL or the Java 
>> version that I'm using matters:
>> java -version
>> java version "1.7.0_65"
>> OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu1)
>> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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 to handle refactoring with TDD and mocking/stubbing

[Ashton Kemerling]

I've always done the full database setup and tear down thing, but that's made 
sufficiently performant with datomics in memory store. Consider using 
transactions to isolate tests, or use Midje, which is more designed for this 
kind of usage. 

--Ashton

Sent from my iPhone

> On Dec 31, 2014, at 9:48 AM, Jonathon McKitrick  wrote:
> 
> I use TDD and mocking/stubbing (conjure) to test each layer of my code.  The 
> problem is when I change the function signature and the tests do not break, 
> because the mocks/stubs do not know when their argument lists no longer agree 
> with the underlying function they are mocking.  Is there a way to catch this? 
>  Short of a test suite that eschews stubbing in favor of full setup/teardown 
> of DB data for each test?
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Finding ClojureScript Libraries

[Ashton Kemerling]

Seems like we need a "Clojurescript toolbox" like website. 

--Ashton

Sent from my iPhone

> On Dec 29, 2014, at 11:14 AM, Raju Bitter  wrote:
> 
> I agree, that would be really helpful. And cool to see ClojureScript taking 
> off like this!
> - Raju
> 
>> On Mon, Dec 29, 2014 at 4:49 PM, David Nolen  wrote:
>> There's been an explosion of ClojureScript libraries over the past
>> year. It would be nice to begin tracking them on the wiki so that
>> newcomers can more easily get their bearings:
>> 
>> If you have a ClojureScript library please add it to the following growing 
>> list:
>> 
>> https://github.com/clojure/clojurescript/wiki#useful-libraries
>> 
>> If your library works with both Clojure & ClojureScript please note that.
>> 
>> Thanks!
>> David
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from 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 to get a list of changes in Datomic

[Ashton Kemerling]

I think this conj video covered that. 

http://m.youtube.com/watch?v=7lm3K8zVOdY

--Ashton

Sent from my iPhone

> On Dec 27, 2014, at 1:57 PM, rogergl  wrote:
> 
> I would like to replay all changes since a specific timestamp.  It seems as 
> if I can get all transactions with 
> 
> (q '[:find ?t :where 
>  [_ :db/txInstant ?t]
>  ] (db conn))
> 
> Using as-of would allow me to replay the state at a given point in time. But 
> that would replay the complete state and not just the changes.
> 
> Is it possbile to get just the changes for a specific transaction ?
> 
> I tried 
> 
>   (q '[:find ?c ?n  :where 
>  [?tx :db/txInstant g]
>  [?c :db/txInstant ?n ?tx]] (db conn))
> 
> to test if I can get back a result for a specific transaction. That did not 
> work although g was a value from the first query.
> 
> Regards
>   Roger
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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 do you name your protocols?

[Ashton Kemerling]

Changing old protocol names should trigger a major revision change in the 
minimum because it breaks backwards compatibility. 

--Ashton

Sent from my iPhone

> On Dec 27, 2014, at 11:18 AM, Michael Klishin  
> wrote:
> 
>> On 27 December 2014 at 19:10:38, Jozef Wagner (jozef.wag...@gmail.com) wrote:
>> clj-time seems to be naming protocols inconsistently. It uses  
>> ISomething, Something and SomethingProtocol naming.
> 
> I suspect it is because it has 60 contributors and most users never have to
> extend the protocols.
> 
> Feel free to submit a PR that standardises all names on Something. 
> --  
> @michaelklishin, github.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/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: Basic usage of namespaces

[Ashton Kemerling]

(use 'myapp.other) is the same as require with a ":refer all" from a users 
perspective, but it's fallen out of favor for :as and :referring individual 
names. 

--Ashton

Sent from my iPhone

> On Dec 24, 2014, at 7:37 AM, Fluid Dynamics  wrote:
> 
>> On Wednesday, December 24, 2014 5:14:01 AM UTC-5, Michael Klishin wrote:
>> On 24 December 2014 at 12:59:11, Eric Le Goff (ele...@gmail.com) wrote: 
>> > Now my newbie question : 
>> > Is there a simpler way to avoid the redundant 2 lines 
>> > (require 'myapp.other) 
>> > (refer 'myapp.other) 
>> 
>> (require '[myapp.other :refer [foo]]) 
>> 
>> See  http://clojure-doc.org/articles/language/namespaces.html
> 
> You can also give it a shorter prefix:
> 
> (require '[myapp.other :as ot])
> 
> (ot/foo 42)
> => 84
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: [lein] compile sass?

[Ashton Kemerling]

Your best bet is probably to ask for the lein-haml-sass plugin to be updated 
with the latest and greatest. A simple update is no reason for a fork or 
rewrite unless if the plugin is simply missing features you need (and that 
can't be added). 

--Ashton

Sent from my iPhone

> On Dec 23, 2014, at 4:41 PM, stephanos  wrote:
> 
> Hey there,
> 
> I would love to use the SASS library bourbon.io for my project. Is there any 
> way I can use leiningen to compile the scss files to css?
> 
> PS: I tried lein-haml-sass but there is no bundled version of the sass gem 
> after 3.2.x and bourbon requires at least 3.3.
> 
> 
> Stephan
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Clojure Style Guide

[Ashton Kemerling]

That's true. I'm just saying I've accidentally done that before in single arity 
functions with no penalty. But if you count on cider or similar picking up 
docstrings from your own functions you'll want to do it the official way. 

--Ashton

Sent from my iPhone

> On Dec 20, 2014, at 10:53 AM, J Irving  wrote:
> 
> It's not a docstring then, just the first expression in the body.
> 
>> On Sat, Dec 20, 2014 at 12:05 PM, Ashton Kemerling 
>>  wrote:
>> You can put the docstring after the args, but the tooling won't pick it up. 
>> 
>> --Ashton
>> 
>> Sent from my iPhone
>> 
>>> On Dec 20, 2014, at 10:01 AM, Eli Naeher  wrote:
>>> 
>>>> On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge  
>>>> wrote:
>>>>  
>>>> And on a client project recently, it was decided (when I wasn't around) 
>>>> that the arguments to a function should always be on a newline:
>>>> 
>>>> (defn foo
>>>>   [x]
>>>>   (+ x x))
>>>> 
>>>> Instead of:
>>>> 
>>>> (defn foo [x]
>>>>   (+ x x))
>>> 
>>> Like you I prefer the arguments on the same line as the defn.
>>> 
>>> Of course, when a docstring is present (and IMO there should nearly always 
>>> be a docstring), this is not possible. Does anyone here know why in Clojure 
>>> it was decided to move the docstring from its traditional-in-Lisp location 
>>> after the argument list? Perhaps it's just a question of what I'm used to, 
>>> but it feels very awkward to me. I like to be able to see the arglist while 
>>> I'm reading the docstring so that I can understand to which arguments it's 
>>> referring, but in Clojure with a long docstring often times the arglist is 
>>> not even visible on the screen.
>>>  
>>> -Eli
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Clojure" group.
>>> To unsubscribe from 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: Clojure Style Guide

[Ashton Kemerling]

You can put the docstring after the args, but the tooling won't pick it up. 

--Ashton

Sent from my iPhone

> On Dec 20, 2014, at 10:01 AM, Eli Naeher  wrote:
> 
>> On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge  
>> wrote:
>>  
>> And on a client project recently, it was decided (when I wasn't around) that 
>> the arguments to a function should always be on a newline:
>> 
>> (defn foo
>>   [x]
>>   (+ x x))
>> 
>> Instead of:
>> 
>> (defn foo [x]
>>   (+ x x))
> 
> Like you I prefer the arguments on the same line as the defn.
> 
> Of course, when a docstring is present (and IMO there should nearly always be 
> a docstring), this is not possible. Does anyone here know why in Clojure it 
> was decided to move the docstring from its traditional-in-Lisp location after 
> the argument list? Perhaps it's just a question of what I'm used to, but it 
> feels very awkward to me. I like to be able to see the arglist while I'm 
> reading the docstring so that I can understand to which arguments it's 
> referring, but in Clojure with a long docstring often times the arglist is 
> not even visible on the screen.
>  
> -Eli
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Core Banking And The Mechanics Of Money Creation

[Ashton Kemerling]

I'm sure successful releases will go a long way on the "clojure tolerance" 
front. 

--Ashton

Sent from my iPhone

> On Dec 18, 2014, at 7:23 AM, Timothy Washington  wrote:
> 
> That's awesome. I'm glad you and your clients are seeing the benefits. 
> 
> 
> Much success :) 
> 
> Tim Washington 
> Interruptsoftware.com 
> 416.843.9060 
> 
> 
>> On Wed, Dec 17, 2014 at 8:04 PM, Matt Dean  wrote:
>> Tim, I enjoyed reading your post. Having recently launched an online banking 
>> user interface for a credit union using the same principles you mentioned 
>> (and React), I agree that this represents the path forward for financial 
>> institutions, and a surprising number of credit union execs seem to feel the 
>> same. It's an intimidating idea for most but they're seeing the opportunity.
>> 
>> To bring this back around to the mailing list topic, we've recently started 
>> a new banking front end using clojurescript, with a liberator-based mock API 
>> for development. The experience has been fantastic and we're looking forward 
>> to using Clojure as much as our clients can tolerate.
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from 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: Handling increasingly-intensive processes

[Ashton Kemerling]

Sam,

It sounds like you need to either find a caching strategy that works for 
your application's needs, or you'll need to adjust how your data is stored 
(model or data store). Without knowing more about your performance and 
business needs I can't really speculate with any confidence.

--
Ashton

On Sunday, December 14, 2014 8:54:04 PM UTC-7, Sam Raker wrote:
>
> I'm (still) pulling tweets from twitter, processing them, and storing them 
> in CouchDB with hashtags as doc ids, such that if a tweet contains 3 
> hashtags, that tweet will be indexed under each of those 3 hashtags. My 
> application hits CouchDB for the relevant document and uses Cheshire to 
> convert the resulting string to a map. The map's values consist of a few 
> string values and an array that consists of all the tweets that contain 
> that hashtag. The problem is thus with common hashtags: the more tweets 
> contain a given hashtag, the long that hashtag's "tweets" array will be, 
> and, additionally, the more often that document will be retrieved from 
> CouchDB. The likelihood and magnitude of performance hits on my app are 
> therefore correlated, which is Bad.
>
> I'm reaching out to you all for suggestions about how best to deal with 
> this situation. Some way of caching something, somehow? I'm at a loss, but 
> I want to believe there's a solution.
>
>
> Thanks,
> -sam
>

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

[Ashton Kemerling]

Apologies on the email flood, my email client decided to do the most 
useless of all possible actions.


On Sun, Dec 14, 2014 at 11:53 PM, Ashton Kemerling 
 wrote:
Honestly, it sounds like you'll either need to move the indexing into 
memor


On Sun, Dec 14, 2014 at 8:54 PM, Sam Raker  
wrote:
I'm (still) pulling tweets from twitter, processing them, and 
storing them in CouchDB with hashtags as doc ids, such that if a 
tweet contains 3 hashtags, that tweet will be indexed under each of 
those 3 hashtags. My application hits CouchDB for the relevant 
document and uses Cheshire to convert the resulting string to a map. 
The map's values consist of a few string values and an array that 
consists of all the tweets that contain that hashtag. The problem is 
thus with common hashtags: the more tweets contain a given hashtag, 
the long that hashtag's "tweets" array will be, and, additionally, 
the more often that document will be retrieved from CouchDB. The 
likelihood and magnitude of performance hits on my app are therefore 
correlated, which is Bad.


I'm reaching out to you all for suggestions about how best to deal 
with this situation. Some way of caching something, somehow? I'm at 
a loss, but I want to believe there's a solution.



Thanks,
-sam
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from 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: clojure.edn won't accept clojure.java.io/reader? How to work around this and why isn't this documented anywhere?

[Ashton Kemerling]

Nothing in the Java.io namespace was made by the clojure team, so it's not 
their fault that reader and pushbackreader aren't cross compatible. I'm 
assuming that they need something from pushbackreader for performance reasons, 
but that's just a guess. 

Clojurescript and ClojureCLR must have different solutions because they're just 
different platforms. Abstracting the whole high performance IO api from each of 
these platforms is silly and probably unwise.  

--Ashton

Sent from my iPhone

> On Dec 8, 2014, at 1:12 AM, Fluid Dynamics  wrote:
> 
>> On Monday, December 8, 2014 2:26:42 AM UTC-5, Andy Fingerhut wrote:
>> In regards to your question "Why isn't this documented anywhere?", it is 
>> documented somewhere -- in the documentation string for clojure.edn/read, 
>> the very function you were attempting to use:
>> 
>> user=> (doc clojure.edn/read)
>> -
>> clojure.edn/read
>> ([] [stream] [opts stream])
>>   Reads the next object from stream, which must be an instance of
>>   java.io.PushbackReader or some derivee.  stream defaults to the
>>   current value of *in*.
> 
> What's *not* documented is that io/reader doesn't output something that 
> edn/read can use directly, nor is there documented an officially recommended 
> workaround for this.
> 
> AFAICT just wrapping the reader output in "(java.io.PushbackReader. ...)" 
> works.
> 
> Still, this is awkward, verbose, and prevents the (nontrivial) use of edn in 
> a platform-neutral way by referring only to Clojure functions without direct 
> interop. Well, except for the even more awkward workaround of slurp and 
> read-string, with the accompanying need to hold the entire file in memory 
> *twice* for a short time.
> 
>> As far as why it requires a PushbackReader, I didn't design the API.  Yes, 
>> some things in Clojure require using Java interop, and in many (but not all) 
>> cases, file I/O requires it.
> 
> Perhaps io/reader should output a PushbackReader, if only for convenience's 
> sake.
> 
> Also, how does this work on ClojureCLR or ClojureScript? Neither of those 
> platforms has a java.io.PushbackReader, and I'm not even sure what the 
> equivalent of the clojure.java.io namespace is for them, unless the "java" in 
> that name is misleading.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Function order in Clojure vs scripting languages

[Ashton Kemerling]

Clojure, like most lisps, is designed around a REPL. So the highest compilation 
unit isn't a file, but a top level definition like defn or defmacro. 

While the comparison isn't perfect, compilation in a lot of lisps is a lot like 
piping a file into an active REPL, at least from a user's perspective.  

--Ashton

Sent from my iPhone

> On Dec 7, 2014, at 7:29 AM, gvim  wrote:
> 
> Considering Clojure has a compile phase why is it more dependent on function 
> definition order than scripting languages like Perl? My naive assumption is 
> that one of the benefits of a compile phase is that every definition is 
> defined ahead of runtime.
> 
> gvim
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Is there a tool to display all the references to a symbol in a project?

[Ashton Kemerling]

I would recommend the silver searcher (ag) if the project is large, as it is 
much faster. 

--Ashton

Sent from my iPhone

> On Dec 3, 2014, at 8:34 AM, Gary Trakhman  wrote:
> 
> I use grep or ack. It's not exact, but it works.
> 
>> On Wednesday, December 3, 2014, Yehonathan Sharvit  wrote:
>> Is there a tool to display all the references to a symbol in a project?
>> 
>> Preferably without using emacs.
>> 
>> Thanks.
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] stateful-check 0.1.0 - test stateful systems with test.check

[Ashton Kemerling]

I'm glad my talk got someone working on things! I'm going to see if that 
library would be a better match for our integration tests than test.check 
alone. 

--Ashton

Sent from my iPhone

> On Nov 28, 2014, at 9:50 AM, Carlo Zancanaro  wrote:
> 
> Hey Jan!
> 
>> On Fri, Nov 28, 2014 at 06:37:06AM -0800, Jan Stępień wrote:
>> Thanks for sharing! I see that generative testing of statful computations 
>> is a popular topic in the Clojure world these days;
> 
> Yeah, it certainly seems to be that way. I was re-invigorated to work on
> stateful-check after watching a talk from the conj about generative
> integration tests.
> 
>> I think we've started working on our libraries nearly the same day :)
>> 
>> https://github.com/jstepien/states
> 
> I've actually seen your library since writing stateful-check. When I
> experimented with it, though, I found its shrinking to be a bit lacking.
> With stateful-check I've actually implemented my own shrinking of
> commands to try to improve the shrinking results (it essentially tries
> to prune irrelevant commands before trying to shrink individual
> commands).
> 
> I was quite interested in your approach of using a single function per
> specification property (precondition/postcondition/next-state). I
> thought that would be a bit constricting when it comes to actually
> writing test cases, though, so I've opted instead to have each of those
> defined per-command. How have you found that to be in practice?
> 
> Thanks!
> 
> Carlo
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: snubbed on clojurescript one

[Ashton Kemerling]

I thought the pedestal frontend is not being developed. I would recommend om, 
reagent, or dommy depending on what your goals are. 

--Ashton

Sent from my iPhone

> On Nov 18, 2014, at 11:56 AM, atucker  wrote:
> 
> "Pedestal is a continuation of ClojureScript One."
> 
> https://groups.google.com/d/msg/clojure/XQ4wuUc0bCk/JuUmUj6cSwUJ
> 
>> On Tuesday, 18 November 2014 06:39:40 UTC, Kevin Banjo wrote:
>> Really excited to use clojurescript one but got shot down right out of the 
>> gate.
>> 
>> Anyone here have the answer?
>> 
>> https://github.com/brentonashworth/one/issues/145
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Mutable local variables

[Ashton Kemerling]

Mutation is not a bad performance optimization, and is super useful when the 
algorithm in question just works better with it. 

--Ashton

Sent from my iPhone

> On Nov 10, 2014, at 11:11 AM, Jacob Goodson  
> wrote:
> 
> I like the map suggestion but there are still those times when mutation makes 
> for a cleaner hack(imo of course).
> 
>> On Monday, November 10, 2014 5:44:25 AM UTC-5, Thomas Heller wrote:
>> @Jacob: If you get too many arguments in a loop I found it best to use a map.
>> 
>> (loop [{:keys [a b c] :as state} a-map]
>>   (cond
>>(and (= a 1) (= b 2))
>>(recur (update state :a inc)) ;; 1.7+ only, otherwise use update-in
>>...))
>> 
>> Working with named arguments (vs. positional) is a lot more user-friendly 
>> since you don't have to repeat everything all the time.
>> 
>> HTH,
>> /thomas 
>> 
>>> On Monday, November 10, 2014 8:21:57 AM UTC+1, Jacob Goodson wrote:
>>> Sometimes, when writing code that loops with a good bit of branching, it 
>>> can be quite annoying to stay immutable.
>>> 
>>> (loop [way 1
>>>   too   2
>>>   many   3
>>>   args 4
>>>   makes 5
>>>   things  6
>>>   annoying 7]
>>>   (cond (and (= way 3) (= too 4)) (recur (inc way) you get the point.  
>>> 
>>> Imagine about 14 different conditions under cond and this thing starts 
>>> looking like crap.  I got around this with macros and pattern matching, 
>>> however, I do not think that this happens too often for many clojurians. 
>>> 
 On Saturday, November 8, 2014 11:49:42 PM UTC-5, Fluid Dynamics wrote:
 I wonder if the OP is aware that you can rebind the same name multiple 
 times in a let. For instance
 
 (let [x something
   y otherthing
   x (if (pred? x y) x (some-func x y))
   x (further (complex (calculations x)))
   ...]
   (do-something-with x))
 
 No actual mutability, but most of the times that suffices for whatever you 
 might use a mutable local for in another language.
 
 Then there's loop/recur. I'd consider let rebinding and loop/recur long 
 before resorting to any sort of mutable. The most significant pain point 
 in my experience has been wanting to "smuggle" a side calculation out of 
 some closure that has to return something else. The most recent case I ran 
 into like that involved (swap! some-atom conj thingy) where the atom held 
 a vector, I also wanted to know the new length of the vector, I didn't 
 want any race conditions (following up with a (count @some-atom) allowed 
 the possibility of the vector changing again in between the swap and the 
 deref, but I wanted to know the position of the item just conjed on), and 
 dosync/ref seemed like overkill (only the one isolated mutable). I *could* 
 have done something like
 
 (let [c (int-array 1)]
   (swap! some-atom (fn [x] (let [x (conj x thingy)] (aset c 0 (count x)) 
 x)))
   (let [c (aget c 0)]
 ; work with c
 ...))
 
 but it was unnecessary to use this kluge, for swap! returns not the atom 
 itself but the new value that was returned by the passed-in function. So 
 all I actually needed was
 
 (let [c (count (swap! some-atom conj thingy))]
   ...)
 
 with no mutability besides the atom itself (and in particular no local 
 mutability). I've since needed swap!'s return value on another occasion, 
 when it was a map, resulting in (get-in (swap! m update-in [k1 k2] f arg1 
 arg2) [k1 k2]) to both update the map and have the exact value for the 
 sub-key that was updated, as of that update. With maps, it may also be 
 possible to store some extra information in the map with a 
 ::module-local-keyword without this interfering with anything else, which 
 can be pulled out of swap!'s return value, and with several kinds of 
 objects you can smuggle extra information out of a closure by adding a 
 ::module-local-keyword to the object's *metadata* (in particular, this 
 won't perturb the equality semantics of the object, as well as working 
 with vectors and several other non-map-like things as well as with records 
 and maps. And if you're wanting to return extra information out of an 
 ordinary function or a loop where you control how the return value is 
 interpreted, you can bind and destructure the return value after making 
 that a short vector or a map with several thingys in it.
 
 Lately I hardly ever find myself feeling the need for any kind of local 
 mutables, and only small amounts of global state (often nothing, or just 
 one atom wrapping a map handled with nesting, update-in, assoc-in, and 
 get-in, though refs and dosync will put in an appearance if a high degree 
 of concurrency is required).
> 
> -- 
> You received this message because you are subscribed to the

Re: better way to group consecutive numbers in a vector?

[Ashton Kemerling]

Consider using partition-by. I can't type clojure on my phone, but the 
following link might help. https://clojuredocs.org/clojure.core/partition-by

--Ashton

Sent from my iPhone

> On Nov 6, 2014, at 3:22 PM, John Gabriele  wrote:
> 
> Hi all,
> 
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
> 
> That is, I'd like to group consecutive numbers together (the final goal being 
> to produce something like `["1" "3-5" "7" "9-12"]`, but that's the easy part).
> 
> I haven't found an easy way to do this. Here's what I've come up with in 
> Clojure:
> 
> ~~~clojure
> #!/usr/bin/env lein-exec
> 
> (def v [1 3 4 5 7 9 10 11 12])
> 
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
> 
> (prn (congeal-consecutives v))
> ~~~
> 
> and here's it done in Python:
> 
> ~~~python
> #!/usr/bin/python3
> 
> v = [1, 3, 4, 5, 7, 9, 10, 11, 12]
> 
> def congeal_consecutives(coll):
> accum = [[ coll[0] ]]
> more  = coll[1:]
> for x in more:
> if x == accum[-1][-1] + 1:
> accum[-1].append(x)
> else:
> accum.append([x])
> return accum
> 
> print(congeal_consecutives(v))
> ~~~
> 
> Can anyone suggest a better / simpler / more easily-understandable way to do 
> this in Clojure?
> 
> Thanks,
> -- John
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: clojure.test.check with fixtures

[Ashton Kemerling]

You can use fixtures from Clojure.test, but each spec from the perspective of 
clojure.test includes multiple runs. So I use fixtures :once to do any global 
setup, and then farm out to a setup function for anything that needs to be done 
before each test run. 

--Ashton

Sent from my iPhone

> On Nov 5, 2014, at 3:27 PM, Sven Richter  wrote:
> 
> Hi,
> 
> Is there a way to use clojure.test.check's defspec with fixtures?
> Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures 
> test library?
> 
> How do other people execute setup and teardowns with clojure.test.check?
> 
> Best Regards,
> Sven
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Clojure usage in production - survey on Hacker News (Nov 2014)

[Ashton Kemerling]

We aren't secretive about our usage of it, but it's used for testing only. It 
doesn't get shipped to any server, hence why production is a stretch.

On Mon, Nov 3, 2014 at 5:57 PM, Alex Miller  wrote:

> I was mostly trying to include interesting companies using it for 
> something. Sorry if I overstepped! :)
> On Monday, November 3, 2014 6:27:41 PM UTC-6, viksit wrote:
>>
>>
>> Ashton - perhaps you should elucidate on matters on that thread :) And why 
>> do you say "stretching" definitions?
>>
>>
>> On Monday, November 3, 2014 4:03:36 PM UTC-8, Ashton Kemerling wrote:
>>>
>>> I'm really entertained that pivotal labs made that list, as I wrote that 
>>> code (and that blog post) and "production" is stretching definitions pretty 
>>> far sadly. 
>>>
>>>
>>>
>>> On Mon, Nov 3, 2014 at 4:55 PM, viksit  wrote:
>>>
>>>> Hello all,
>>>>
>>>> I was curious about the state of Clojure in production, and put up this 
>>>> thread on Hacker News asking for insight, since all the other threads are 
>>>> quite dated. 
>>>>
>>>> https://news.ycombinator.com/item?id=8549823
>>>>
>>>> Given the large amount of feedback that's already on it, I thought I'd 
>>>> cross post here and get the list's feedback on this as well. 
>>>>
>>>> I think it would be great to have this resource updated with the latest 
>>>> state of Clojure in production around the world, especially so in helping 
>>>> answer queries in people's minds as they try to figure out who else uses 
>>>> it 
>>>> before they do.
>>>>
>>>> Cheers,
>>>> Viksit
>>>>
>>>>
>>>>
>>>>
>>>>  -- 
>>>> 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: Clojure usage in production - survey on Hacker News (Nov 2014)

[Ashton Kemerling]

I'm really entertained that pivotal labs made that list, as I wrote that code 
(and that blog post) and "production" is stretching definitions pretty far 
sadly.

On Mon, Nov 3, 2014 at 4:55 PM, viksit  wrote:

> Hello all,
> I was curious about the state of Clojure in production, and put up this 
> thread on Hacker News asking for insight, since all the other threads are 
> quite dated. 
> https://news.ycombinator.com/item?id=8549823
> Given the large amount of feedback that's already on it, I thought I'd 
> cross post here and get the list's feedback on this as well. 
> I think it would be great to have this resource updated with the latest 
> state of Clojure in production around the world, especially so in helping 
> answer queries in people's minds as they try to figure out who else uses it 
> before they do.
> Cheers,
> Viksit
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: On Testing

[Ashton Kemerling]

I can say for certain that at a minimum better indentation of data structures 
to the console would be a must, a vector with 4+ hash maps in it are currently 
unreadable and I have to copy to an editor to indent and analyze. 


Beyond that, I can imagine the need for a structural diff that tells me in a 
human readable form how things are different. Different types (plain sequence 
vs hash map), different positions or keys in structures, etc.

On Sat, Nov 1, 2014 at 12:58 PM, Alex Miller  wrote:

> It would be great if someone could enumerate more explicitly what "better" 
> test output means. What are the specific problems in the current test output 
> reporting?
> Similar problem list for test runner might be useful.
> Discussion here is fine but ultimately needs to land on a design wiki page.
> I am happy to do what I can to move this through a process toward inclusion 
> in a release.
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: On Testing

[Ashton Kemerling]

That's an excellent idea, currently at least test.check hacks on top of 
clojure.test by using macros that emit clojure.test tests. 


Beyond that it seems that the #1 wish is better output. I don't think that 
ought to be very hard for us to pull off as a community.

On Fri, Oct 31, 2014 at 6:56 PM, Andrew Rosa  wrote:

> +1 to something like humane-test-output being part of core library.
> There is value for the community to have some foundation library share 
> across our test frameworks? Something like `test.runners`, to encapsulate 
> error reporting and organization? Bit crazy, I know, but the idea come 
> after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do 
> Haskell, but I kind of like the way of composing a single integrated suite 
> of different flavors of test.
> Andrew
> On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote:
>>
>> Would be great if humane-test-output was part of clojure.test. Would make 
>> it easier for beginners to find it. 
>>
>> On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote:
>>>
>>> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling  
>>> wrote:
>>>  
>>>
>>>> It's my opinion that these two libraries are largely complete aside from 
>>>> some human interface improvements (quality of output for example), but 
>>>> clearly not everyone agrees with me. 
>>>>
>>>
>>> Hi Ashton,
>>>
>>> Check out https://github.com/pjstadig/humane-test-output if you haven't 
>>> already seen it, it's a nice improvement over the default output--in 
>>> particular seeing the specific diffs between expected and actual values is 
>>> really useful when you are dealing with collections.
>>>
>>> -Eli
>>>
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: On Testing

[Ashton Kemerling]

I don't want to speak for others, I notified everyone involved on Twitter that 
I made this thread so they can voice their own complaints.

On Fri, Oct 31, 2014 at 9:02 AM, László Török  wrote:

> "I tweeted recently that I thought that Clojure is super testable, and I
> was genuinely surprised about the number of people who disagreed with me."
> My 2c.
> Without explicitly citing those complaints, it will be difficult to conduct
> a meaningful debate.
> 2014-10-31 14:52 GMT+00:00 Ashton Kemerling :
>>  I tweeted recently that I thought that Clojure is super testable, and I
>> was genuinely surprised about the number of people who disagreed with me.
>>
>> There's been a lively discussion about what the best testing frameworks in
>> clojure currently are, and what the built in solutions (clojure.test and
>> test.check) are lacking. While a lot of people recommend midje or
>> expectations, I generally prefer the built in options (no offense to
>> contributors of either of those libraries) and usually recommend people
>> stick with clojure.test for its lack of magic.
>>
>> It's my opinion that these two libraries are largely complete aside from
>> some human interface improvements (quality of output for example), but
>> clearly not everyone agrees with me.
>>
>> So let's talk about what we could add to make the clojure testing
>> experience superior compared to other languages.
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
> -- 
> László Török
> Checkout justonemorepoint.com - Know your true value
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.

On Testing

[Ashton Kemerling]

I tweeted recently that I thought that Clojure is super testable, and I was 
genuinely surprised about the number of people who disagreed with me. 

There's been a lively discussion about what the best testing frameworks in 
clojure currently are, and what the built in solutions (clojure.test and 
test.check) are lacking. While a lot of people recommend midje or expectations, 
I generally prefer the built in options (no offense to contributors of either 
of those libraries) and usually recommend people stick with clojure.test for 
its lack of magic. 


It's my opinion that these two libraries are largely complete aside from some 
human interface improvements (quality of output for example), but clearly not 
everyone agrees with me. 


So let's talk about what we could add to make the clojure testing experience 
superior compared to other languages.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Cannot understand why I get this output.

[Ashton Kemerling]

I think you're confused on the terminal output. Try typing [octavia] in the 
repl, and compare the output you get to the above code. 


Clojure prints out the raw values of any computation, not variable names.

On Mon, Oct 27, 2014 at 9:45 AM, Roelof Wobben 
wrote:

> Op maandag 27 oktober 2014 16:37:49 UTC+1 schreef James Reeves:
>>
>> On 27 October 2014 13:45, Roelof Wobben > 
>> wrote:
>>
>>> Hello, 
>>>
>>> I have this "facts". 
>>>
>>> (def octavia {:name "Octavia E. Butler"
>>>   :birth-year 1947
>>>   :death-year 2006})
>>>
>>>
>> So you've assigned the var "octavia" to the data structure:
>>
>> {:death-year 2006, :name "Octavia E. Butler", :birth-year 1947}
>>
>>
>> (def wild-seed {:title "Wild Seed", :authors [octavia]})
>>>
>>>
>> Here you've assigned the var "wild-seed" to:
>>
>> {:title "Wild Seed", :authors [octavia]}
>>
>>  
>> Which is the same as:
>>
>> {:title "Wild Seed", :authors [{:death-year 2006, :name "Octavia E. Butler", 
>> :birth-year 1947}]}
>>
>>
>> So I thought when I do this : 
>>>
>>> (defn old-book->new-book [book]
>>>(get book :authors))
>>>
>>> (old-book->new-book {:title "Wild Seed", :authors [octavia]}) 
>>>
>>>
>> Okay, so work through your code. You start with:
>>
>> (old-book->new-book {:title "Wild Seed", :authors [octavia]}) 
>>
>>
>> Resolving this gets:
>>
>> (get {:title "Wild Seed", :authors [octavia]} :authors) 
>>
>>
>> Resolving this gets:
>>
>> [octavia]
>>
>>
>> Which resolves to:
>>
>> [{:death-year 2006, :name "Octavia E. Butler", :birth-year 1947}]
>>
>>
>> I'm not sure why you'd expect anything else. Did you not expect "octavia" 
>> to resolve?
>>
>> - James
>>
>>
> I think I do not fully understand how clojure works as a beginner.
> As far as I see it I have to find a way to stop with [octavia] so I can 
> make a set of it. 
> Roelof
>  
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Cannot understand why I get this output.

[Ashton Kemerling]

The hash map you posted has the value of [octavia] under the key :authors, and 
that's what printed out. The repl doesnt inline the variable name, instead it 
prints out the literal value.

On Mon, Oct 27, 2014 at 9:22 AM, Roelof Wobben 
wrote:

> Op maandag 27 oktober 2014 16:07:15 UTC+1 schreef Gary Verhaegen:
>>
>> On Monday, 27 October 2014, Roelof Wobben > > wrote:
>>
>>> Now Im complete confused. I never succeed in reading the value of authors 
>>> so I can do the set command. 
>>>
>>> Roelof
>>>
>>
>> And now you're kind of confusing me. What makes you think you do not read 
>> the value of authors? What did you expect instead of what you got? 
>>
> I expected the outcome : *octavia*
> but I see the output : [{:death-year 2006, :name "
> Octavia E. Butler", :birth-year 1947}]  
> Roelof
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Starting a project the right way - tips?

[Ashton Kemerling]

I ham-fistedly kill and reset the DB before every test using clojure.test 
fixtures.




Passing the conn never occurred to me, and I kind of wish I did it that way. 
Currently I have any reading database functions accept the db (which makes 
testing using “with” very fast and easy), and any writing functions return the 
tx-data rather than executing it directly. This also makes testing easier, as I 
can assert on the exact tx-data expected, or again use with in my tests to 
check the side-effects. As a result the only tests I have that actually touch 
db state are anything that check my actual routing code.




—

Ashton

On Mon, Oct 27, 2014 at 7:52 AM, Sven Richter 
wrote:

> Hi Ashton,
> After some discussion in the datomic and clojure irc channel I decided to 
> go the route to pass in the datomic connection or datomic value to every 
> function. This way it is really easy to do integration tests of these 
> functions by setting up an in memory datomic database for every single one 
> of my tests.
> Mixing in some fixtures and I was done.
> I am curious, how did you solve this finally?
> Best Regards,
> Sven
> Am Montag, 27. Oktober 2014 14:25:12 UTC+1 schrieb Ashton Kemerling:
>>
>> Consider how your database will be setup and handled. My project uses 
>> Datomic (also a SPA), but it was a little painful learning how to get the 
>> tests to run cleanly with the database being setup and torn down between 
>> runs.
>>
>> Also, consider using Secretary on the frontend early. I’m using Om and 
>> thought I could get away without it by using component state to control 
>> what is displayed, and boy was I wrong.
>>
>> —
>> Ashton
>>
>>
>>
>> On Mon, Oct 27, 2014 at 6:54 AM, Joshua Ballanco > > wrote:
>>
>>> Just in case you hadn’t already come across it in your Google-ing, I 
>>> thought you should know about http://clojure-doc.org . This site is more 
>>> than just API documentation, it also contains a number of useful guides 
>>> covering various topics in Clojure. It’s not exactly a collection of 
>>> prescriptions, but it might help you figure out what direction to head in 
>>> more than just reading the API docs would.
>>>
>>> Cheers,
>>> Josh
>>>
>>>
>>> On October 27, 2014 at 13:08:42, Colin Yates (colin...@gmail.com 
>>> ) wrote:
>>>
>>>   About to embark on a new project and interested in "wish I knew 
>>> this"/"wish I had used this" type sentiments. An extension of this splendid 
>>> article: 
>>> http://blog.mattgauger.com/blog/2014/09/15/clojure-code-quality-tools/. 
>>> Any others?
>>>
>>> For context, this is going to be a non-trivial SPA using clojurescript 
>>> supported by a Clojure backend (
>>> https://groups.google.com/d/topic/clojurescript/9cDFfAGsDE4/discussion)
>>>
>>> In addition to the tips I found in the article I am also planning on 
>>> using core.typed, primarily to address the "anyone remember what this data 
>>> structure looked like?" 12 month maintenance risk. I did look at schematic 
>>> but I like the extra enforcement core.typed gives.
>>>
>>> On a side note, answering this question from google alone is non-trivial. 
>>> We, as a community have reached that point where there are so many (good, 
>>> but overlapping and sometimes contradictory) good next steps it is easy to 
>>> be paralysed by choice. A few more "authorized" (whatever that means) 
>>> "prescriptions" wouldn't go amiss. Not sure what the answer is, merely 
>>> raising the flag. 
>>>
>>> So, what tips/techniques/XYZ do you wish you had started with?
>>>
>>> Thanks!
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google Groups 
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d

Re: Starting a project the right way - tips?

[Ashton Kemerling]

Consider how your database will be setup and handled. My project uses Datomic 
(also a SPA), but it was a little painful learning how to get the tests to run 
cleanly with the database being setup and torn down between runs.




Also, consider using Secretary on the frontend early. I’m using Om and thought 
I could get away without it by using component state to control what is 
displayed, and boy was I wrong.




—

Ashton

On Mon, Oct 27, 2014 at 6:54 AM, Joshua Ballanco 
wrote:

> Just in case you hadn’t already come across it in your Google-ing, I thought 
> you should know about http://clojure-doc.org . This site is more than just 
> API documentation, it also contains a number of useful guides covering 
> various topics in Clojure. It’s not exactly a collection of prescriptions, 
> but it might help you figure out what direction to head in more than just 
> reading the API docs would.
> Cheers,
> Josh
> On October 27, 2014 at 13:08:42, Colin Yates (colin.ya...@gmail.com) wrote:
> About to embark on a new project and interested in "wish I knew this"/"wish I 
> had used this" type sentiments. An extension of this splendid article: 
> http://blog.mattgauger.com/blog/2014/09/15/clojure-code-quality-tools/. Any 
> others?
> For context, this is going to be a non-trivial SPA using clojurescript 
> supported by a Clojure backend 
> (https://groups.google.com/d/topic/clojurescript/9cDFfAGsDE4/discussion)
> In addition to the tips I found in the article I am also planning on using 
> core.typed, primarily to address the "anyone remember what this data 
> structure looked like?" 12 month maintenance risk. I did look at schematic 
> but I like the extra enforcement core.typed gives.
> On a side note, answering this question from google alone is non-trivial. We, 
> as a community have reached that point where there are so many (good, but 
> overlapping and sometimes contradictory) good next steps it is easy to be 
> paralysed by choice. A few more "authorized" (whatever that means) 
> "prescriptions" wouldn't go amiss. Not sure what the answer is, merely 
> raising the flag. 
> So, what tips/techniques/XYZ do you wish you had started with?
> Thanks!
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: testing platform , midje or specjl ?

[Ashton Kemerling]

I'd forgotten to mention Test.Check, thanks Reid!

I've had really great luck using test.check (and Doublecheck, the cljx
port) for testing both Clojure(script), Javascript, and Ruby
(integration style). Highly recommend.

On 10/26/2014 08:28 PM, Reid McKenzie wrote:
> Have another +1 for clojure.test. It’s packaged with Clojure and while
> it’s not especially shiny I find that it gets the job done most of the
> time in addition to having the best tooling support.
> 
> In my latest project, I’ve been enjoying using org.clojure/test.check
> <https://github.com/clojure/test.check>, arguably the most active of the
> QuickCheck clones for Clojure. I’ve been very happy with it, especially
> when paired with lein-cloverage <https://github.com/lshift/cloverage> to
> report on test coverage. It’s been …. interesting to say the least to be
> able to watch how the tests I write compare to the actual code paths I
> write. Many corner cases now covered and eliminated as a result. By way
> of example: a trivial recursive decent parser:
> https://github.com/oxlang/oxlang/blob/master/src/oxlang/parser.clj and
> test.check test coverage:
> https://github.com/oxlang/oxlang/blob/master/test/oxlang/parser_test.clj. Note
> that the |(defspec)| form is a macro that emits |clojure.test| test
> handles for |test.check| properties, so you can get the best of both :D.
> 
> Reid
> 
> On 10/26/2014 04:50 PM, cameron wrote:
> 
>> Id' second clojure.test,
>>   it's simple, tests are written in idiomatic clojure and has good
>> tooling support (eg. run tests in cider).
>> It's my go-to testing library now.
>>
>>
>> On Monday, 27 October 2014 07:26:25 UTC+11, Ashton Kemerling wrote:
>>
>> Don't forget clojure.test! It's simple, but I've found it to be
>> sufficient.
>>
>>
>>
>> On Sun, Oct 26, 2014 at 11:51 AM, Roelof Wobben
>> > wrote:
>>
>> Hello,
>>
>> Im learning clojure as the beginnner.
>> When im googeling for a testing platform there seems to be two
>> major choices midje and specjl.
>>
>> Now I see that my learning course from github uses midje.
>>
>> Can I better learn midje and it this one still active
>> maintained or can I better learn specjl.
>>
>>
>> Roelof
>>
>> -- You received this message because you are
>> subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> 
>> Note that posts from new members are moderated - please be
>> patient with your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> <http://groups.google.com/group/clojure?hl=en>
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "Clojure" group.
>> To 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
>> <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
>> <mailto:clojure+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout.
> 
> ​
> 

-- 
Ashton

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: testing platform , midje or specjl ?

[Ashton Kemerling]

Don't forget clojure.test! It's simple, but I've found it to be sufficient.

On Sun, Oct 26, 2014 at 11:51 AM, Roelof Wobben 
wrote:

> Hello, 
> Im learning clojure as the beginnner.
> When im googeling for a testing platform there seems to be two major 
> choices midje and specjl.
> Now I see that my learning course from github uses midje.
> Can I better learn midje and it this one still active maintained or can I 
> better learn specjl. 
> Roelof
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: multimethod, record, type, and protocol pitfalls?

[Ashton Kemerling]

The way defmulti handles argument matching. I could be incorrect, but if I 
recall I was forced to use namespaced keywords for matching, and I couldn't use 
& args like I wanted to.

On Sun, Oct 26, 2014 at 9:48 AM, Daniel Higginbotham
 wrote:

>  
> What's difficult when it comes to understanding multimethods, records, 
> types, and protocols? I'm writing a chapter on multimethods, records, 
> types, and protocols for the book Clojure for the Brave and True, and I'd 
> love to hear about what kinds of pitfalls I should be sure to cover :)
> Thanks!
> Daniel
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Question about test.check, and knossos

[Ashton Kemerling]

Oh thank goodness, I've been directing people towards the source for 
test.check, which is obviously sub-optimal. Thanks for adding that!

On Fri, Oct 24, 2014 at 11:43 AM, Reid Draper 
wrote:

> Hey Andy,
> I've added a link to the API documentation [1]. And I'll update Codox for 
> the next version of test.check, hopefully to be released shortly.
> [1] 
> https://github.com/clojure/test.check/commit/200b77bbf24b67d2904dab4d4f5722badbe8b223
> Reid
> On Thursday, October 23, 2014 11:44:54 PM UTC-5, Andy Chambers wrote:
>>
>> On Thursday, October 23, 2014 11:21:44 PM UTC-4, Andy Chambers wrote:
>>>
>>> On Thursday, October 23, 2014 9:23:36 PM UTC-4, tcrayford wrote:

 Hi Andy, All,

 I wrote a tool like this: https://github.com/tcrayford/laundromat

 it's super hacky, and the api is definitely in beta. I asked some folk 
 about reviewing this api, got little feedback, and figured it wasn't that 
 much of a wanted thing after all. I still use it internally, but it's 
 pretty bad at what it does right now. I'd love to hear if more folk are 
 interested or if anybody's interested in contributing.

>>>
>>> Hi Tom,
>>>
>>> Your project looks interesting and I definitely think it has value. Where 
>>> were you expecting feedback? When I have questions about a project like 
>>> this, I'm never sure where to ask them. Stackoverflow? A github issue? 
>>> Google groups? Anyway it looks pretty cool to my untrained eye but I'd be 
>>> interested in hearing what Reid Draper or Kyle Kingsbury has to say about 
>>> it.
>>>
>>> Do you mind me asking what made you decide to diverge from the original 
>>> Erlang implementation? Also what makes it bad? I'd be interested in helping 
>>> out if I can.
>>>
>>
>> Also, while I'm here talking about test.check, there's a couple of bugs 
>> I'd like to report.
>>
>>  * There's no link to the API docs in the README
>>  * I did manage to find some docs here (
>> http://clojure.github.io/test.check/) but there is no link to the source 
>> like there is in the compojure codox documentation
>>
>> I tried to use JIRA after signing the CA but the secure signing page 
>> doesn't seem to be working at the moment (screenshot attached).
>>
>> Cheers,
>> Andy
>>
>>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

I also just realized that I'm accidentally continuing this conversation despite 
Sean's best efforts. Please disregard my last message.

On Wed, Oct 15, 2014 at 8:31 PM, Ashton Kemerling
 wrote:

> I wasn't prepared to make moral statements about the survey, I'm just 
> interested in what helps the community the most. If such questions would 
> exclude people from the survey and/or the community then obviously that seems 
> problematic, although I'm curious (but not doubtful) as to why that would 
> happen. 
> But I am not in a position of authority or experience in this area, if others 
> more experienced than I believe that's a bad idea, I'm happy to defer to 
> their wiser judgement. 
> --
> Ashton
> On Wed, Oct 15, 2014 at 7:49 PM, Sean Corfield  wrote:
>> I'm replying to Ashton and Mars0i off-list - and I'm happy to continue 
>> discussing the issue off-list, with anyone who wants to, but I think it's 
>> getting off-topic and close to inappropriate for this (technical) list.
>> And, for what it's worth, Atamert, I'm on your side on this.
>> Sean
>> On Oct 15, 2014, at 6:44 PM, Atamert Ölçgen  wrote:
>>> On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling 
>>>  wrote:
>>> I'm curious if there's any empirical evidence that significant numbers of 
>>> people will do that. 
>>> 
>>> Suppose I have provided reliable data that shows only 0.1% would refuse to 
>>> answer such a Survey. A programming related survey with questions about 
>>> demographics and a stated mission of being inclusive. What would be your 
>>> moral reasoning for not being inclusive for this group of people?

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

Re: ANN: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

I wasn't prepared to make moral statements about the survey, I'm just 
interested in what helps the community the most. If such questions would 
exclude people from the survey and/or the community then obviously that seems 
problematic, although I'm curious (but not doubtful) as to why that would 
happen. 


But I am not in a position of authority or experience in this area, if others 
more experienced than I believe that's a bad idea, I'm happy to defer to their 
wiser judgement. 




--

Ashton

On Wed, Oct 15, 2014 at 7:49 PM, Sean Corfield  wrote:

> I'm replying to Ashton and Mars0i off-list - and I'm happy to continue 
> discussing the issue off-list, with anyone who wants to, but I think it's 
> getting off-topic and close to inappropriate for this (technical) list.
> And, for what it's worth, Atamert, I'm on your side on this.
> Sean
> On Oct 15, 2014, at 6:44 PM, Atamert Ölçgen  wrote:
>> On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling 
>>  wrote:
>> I'm curious if there's any empirical evidence that significant numbers of 
>> people will do that. 
>> 
>> Suppose I have provided reliable data that shows only 0.1% would refuse to 
>> answer such a Survey. A programming related survey with questions about 
>> demographics and a stated mission of being inclusive. What would be your 
>> moral reasoning for not being inclusive for this group of people?

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

Re: ANN: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

I'm curious if there's any empirical evidence that significant numbers of 
people will do that.

On Wed, Oct 15, 2014 at 6:23 PM, Mars0i  wrote:

> I don't really get it.  I don't see a legitimate reason why anyone would 
> refuse to participate in the survey because it included demographic 
> questions.  The survey is anonymous.  The combination of questions is not 
> such that it would be at all plausible that anyone could be identified by 
> their responses.  At worst, answering a few additional questions--or simply 
> skipping those questions--would be a very minor annoyance.  Is it that some 
> people object to the idea that there are disparities due to systemic 
> factors in our society?  If someone wants to disagree about that, OK, but I 
> still don't see how boycotting a survey because it offers respondents the 
> opportunity to provide demographic information is reasonable.
> On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote:
>>
>> On Oct 15, 2014, at 11:29 AM, Ashton Kemerling > > wrote: 
>> > "I would rather not say" is a common and valid response in these 
>> scenarios. 
>>
>> Yes, although that doesn't address that there are people who will not 
>> complete a survey that even asks such questions (on a philosophical 
>> objection to collecting such demographic information). As I said, it's a 
>> sensitive issue. 
>>
>> As Bridget noted, they'll consider the approach for 2015. 
>>
>> 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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

"I would rather not say" is a common and valid response in these scenarios.

On Wed, Oct 15, 2014 at 12:19 PM, Sean Corfield  wrote:

> Asking questions about race and/or gender can be a very sensitive issue and a 
> lot of people would refuse to complete those sections, or may even refuse to 
> complete the survey at all if such questions were included - for a variety of 
> very valid reasons.
> Sean
> On Oct 14, 2014, at 9:23 PM, Zack Maril  wrote:
>> ClojureBridge and conj grants are excellent ways to encourage all types of 
>> folks to join Clojure and I'm stoked that these programs have emerged from 
>> the community. These are Good Things and should be continued and improved 
>> upon wherever possible. I'd personally like to know how much good these 
>> efforts do and tracking demographics of the Clojure community, whether it is 
>> through the State of Clojure survey or other means, would allow us to 
>> measure the distance between our ideals and reality. I'm proud of the 
>> attempts and efforts undertaken to increase diversity within the community 
>> and, beyond the specifics of this current conversation, I'm confident that 
>> Clojure will make strides towards a more diverse user base. 
>> 
>> For the issue at hand, I believe that by including demographics within the 
>> State of the Clojure survey the Clojure leadership would be making a strong 
>> statement indicating their desire for a more desire community. The survey 
>> measures that which has been deemed important to know and understand in 
>> terms of the stewardship and development of Clojure. Including demographic 
>> questions in the survey, along with the context of why they were included, 
>> would indicate that there is a strong desire to understand and improve the 
>> diversity of the community by those who lead the community. Inclusion of 
>> such questions on the survey would be another opportunity for Clojure to be 
>> more than just not unwelcoming to atypical folks and allow us to 
>> purposefully invite more people to this relative paradise we inhabit. For a 
>> relatively small effort* it would show atypical folks that we care to know 
>> that they exist in the context of Clojure usage and that we are interested 
>> in understanding and improving their situation. 
>> -Zack
>> 
>> *If I've misgauged the difficultly of adding such questions to the survey, 
>> please say so. My impression is that this would be straightforward 
>> technologically and, by perhaps copying questions from similar surveys, 
>> straightforward in terms of survey design. I don't mean to ask you to drop 
>> everything and try to solve all the problems of sexism all at once but only 
>> to do something which seems, from an outside perspective, fairly economical 
>> with low costs and high benefits. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Diversity (was: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

I'm always very proud to tell other people how much effort the clojure 
community is putting into this, especially compared to its size. Keep up the 
good work!


--

Ashton

On Mon, Oct 13, 2014 at 5:41 PM, Sean Corfield  wrote:

> On Oct 13, 2014, at 11:50 AM, Zack Maril  wrote:
>> I'd like to know if selecting Clojure as my default/main programming 
>> language means that I'll be forced to select from a fairly homogeneous group 
>> of potential coworkers and miss out on the benefits of a diverse working 
>> environment.
> One of the reasons I started ClojureBridge - http://clojurebridge.org - was 
> because of the lack of diversity in the visible Clojure community and I 
> wanted to see if we could do for Clojure what RailsBridge did for the Ruby on 
> Rails community. We have been running workshops successfully around the globe 
> now for over six months. I've been very pleased with the amount of support 
> ClojureBridge has received from the community, and that a strong team has 
> emerged to run the organization (so my involvement is now fairly minimal). It 
> will take time but I believe we can change the demographics of our community 
> if we all want to do so.
> In particular, the demographics of your work environment depend almost 
> entirely on your hiring process and willingness to train your employees so 
> that's definitely an area where you can effect change if you have the will.
> Sean Corfield -- http://clojurebridge.org
> "ClojureBridge aims to increase diversity within the Clojure community by
>  offering free, beginner-friendly Clojure programming workshops for women."

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: State of Clojure 2014 Survey - please contribute!!

[Ashton Kemerling]

It would've been nice to have back-stats to tell if efforts like Clojure bridge 
are having a statistical impact on the communities makeup.


That being said, I'm sure the clojure bridge folk have their own internal 
metrics to guide their actions and measure outcomes, but it would've been nice 
to see overall.

On Mon, Oct 13, 2014 at 5:10 PM, Mars0i  wrote:

> On Monday, October 13, 2014 1:50:13 PM UTC-5, Zack Maril wrote:
>>
>> Next year, I would appreciate questions that measure the demographics of 
>> Clojure users be included. Out of the hundreds of people I've heard and 
>> seen talking about using Clojure, the vast majority of them have been white 
>> men. I've thought about it for a few days now and I can only think of three 
>> or four women who I know use Clojure and only a few non white men. I'd like 
>> to know if selecting Clojure as my default/main programming language means 
>> that I'll be forced to select from a fairly homogeneous group of potential 
>> coworkers and miss out on the benefits of a diverse working environment. 
>> -Zack 
>>
> I agree that including demographic questions would be a nice addition.
> In the U.S.,   the distribution of sexes and racial/ethnic groups among IT 
> people 
> 
>  
> is pretty skewed toward white males, as I'm sure you would imagine.  Even 
> if the percentages of groups among Clojure programmers were the same as 
> they are for, say, Java programmers, there would in theory be a lot more 
> women and non-white Java programmers to choose from if you wanted to build 
> a diverse shop.  That is, in general if you're in a smaller community 
> (Clojure), your flexibility is more limited.
> (Also, although I think the State of Clojure survey is valuable, no one 
> would claim that it uses a reliable sampling method.  That's not a 
> criticism at all.  Coming up with a reliable sample would be difficult, in 
> practice, The point is that sampling problems can be worse when you're 
> dealing with small numbers.  So for example, if one group of people is a 
> small but significant minority of all programmers, survey on their 
> percentages in a relatively small community, such as the Clojure could be 
> wildly inaccurate, even if their percentages were higher among Clojure 
> programmers than in the general programming community.
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Why is my function faster with eval?

[Ashton Kemerling]

Did you run it enough times to fully warm up the JVM?

On Fri, Oct 10, 2014 at 4:21 PM, Michael Blume 
wrote:

> https://github.com/MichaelBlume/eval-speed
> eval-speed.core=> (time-fn read-to-maps)
> "Elapsed time: 5551.011069 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-fn)
> "Elapsed time: 5587.256991 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-partial)
> "Elapsed time: 5606.649172 msecs"
> nil
> eval-speed.core=> (time-fn read-to-maps-eval)
> "Elapsed time: 2627.521592 msecs"
> nil
> Ben, I'd still like to understand exactly what work the CPU is doing in the 
> uneval'd version that it's skipping in the eval'd version. It seems like in 
> the generated bytecode there's going to be *some* concept of iterating 
> through the row in either case, if only as part of the destructuring 
> process.
> On Friday, October 10, 2014 1:07:08 PM UTC-7, Ben wrote:
>>
>> I believe it's because the `mapper` function is just creating and 
>> returning a map literal. The "mapper" function in the evaled version is 
>> something like this:
>>
>> user> (def names '[n1 n2 n3 n4])
>> #'user/names
>> user> (def headers '[h1 h2 h3 h4])
>> #'user/headers
>> user> `(fn [[~@names]] ~(zipmap headers names))
>> (clojure.core/fn [[n1 n2 n3 n4]] {h4 n4, h3 n3, h2 n2, h1 n1})   ;; just a 
>> map literal, whose keys are already known.
>>
>> Whereas in the first version, zipmap has to be called, iterating over 
>> headers and names each time.
>>
>> On Fri, Oct 10, 2014 at 1:04 PM, Sean Corfield > > wrote:
>>
>>> It may be more to do with the difference between `for` and `map`. How do 
>>> these versions compare in your benchmark:
>>>
>>> (defn read-to-maps-partial [rows]
>>>   (let [headers (->>
>>>   rows
>>>   first
>>>   (take-while (complement #{""}))
>>>   (map keyword))]
>>> (map (partial zipmap headers) (rest rows
>>>
>>> (defn read-to-maps-fn [rows]
>>>   (let [headers (->>
>>>   rows
>>>   first
>>>   (take-while (complement #{""}))
>>>   (map keyword))
>>> mapper (fn [row] (zipmap headers row))]
>>> (map mapper (rest rows
>>>
>>> Sean
>>>
>>> On Oct 10, 2014, at 11:42 AM, Michael Blume >> > wrote:
>>> > So I'm reading a bunch of rows from a huge csv file and marshalling 
>>> those rows into maps using the first row as keys. I wrote the function two 
>>> ways: https://gist.github.com/MichaelBlume/c67d22df0ff9c225d956 and the 
>>> version with eval is twice as fast and I'm kind of curious about why. 
>>> Presumably the eval'd function still implicitly contains a list of keys, 
>>> it's still implicitly treating each row as a seq and walking it, so I'm 
>>> wondering what the seq-destructuring and the map literal are doing under 
>>> the hood that's faster.
>>>
>>>
>>
>>
>> -- 
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks, which 
>> may be sweet, aromatic, fermented or spirit-based. ... Family and social 
>> life also offer numerous other occasions to consume drinks for pleasure." 
>> [Larousse, "Drink" entry]
>>
>>  
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Profiling in Counterclockwise

[Ashton Kemerling]

The profiling and logging tool might be Java specific.

On Sun, Oct 5, 2014 at 2:38 PM, Fluid Dynamics  wrote:

> On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote:
>>
>> When I need to profile (which is asmittedly quite rare), I use VisualVM, 
>> which should have been installed along with the JDK. I'd recommend editing 
>> the default settings to remove clojure.** and add your own namespaces as 
>> starting points for the profiling.
>>
>> For more lightweight approaches, I'd suggest checking out Timbre and 
>> Criterium, though I have very little experience with both.
>>
>>
>> None of this is Eclipse specific or runs in Eclipse.
>>
> So, what you're saying is that I'd have to
> 1) Package everything up
> 2) Deploy to somewhere
> 3) Learn how to use  classpath configuration and stuff>
> 4) Identify hot spots
> 5) Make improvement of some sort
> 6) Back to step 1?
> Because that seems to *completely eliminate* the benefit of having a REPL 
> and fast development/try things/edit cycle. :(
>  
> Meanwhile, why did I get google results for a supposed "Profiling and 
> Logging perspective" in Eclipse if no such thing exists?
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Variadic argument function call to another v.a.f.

[Ashton Kemerling]

That makes plenty of sense, you passed 1 argument to va1, and it was a list 
(from &args). If you wish to unwrap that list, use apply:


(apply va1 '(1 2 3))

On Sun, Oct 5, 2014 at 12:01 PM, Mate Varga  wrote:

> Hi,
> there's a closed old bug on the CLJS JIRA from 2012:
> http://dev.clojure.org/jira/browse/CLJS-383 "Empty variadic argument 
> initialised with (nil) when using arity overloading 
> "
> I am experiencing completely similar behavior in the latest CLJ 1.6:
> (defn va1 [& args] args)
> => (var syn-ws.core/va1)
> (defn va2 [& args] (va1 args))
> => (var syn-ws.core/va2)
> (va2 1 2 3)
> => ((1 2 3))
> (va2)
> => (nil)
> I.e. variadic arguments are passed as lists, and when they're passed to 
> another function with variadic arguments then the list is wrapped in 
> another list. It this the correct behavior?
> Thanks,
> Mate
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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] Monroe 0.1.0 - nrepl client for Emacs

[Ashton Kemerling]

The transition to cider was tough for some, I remember it being broken for me 
for a version or two. Perhaps they added that for the transition?

On Fri, Oct 3, 2014 at 6:40 AM, Daniel Szmulewicz
 wrote:

> You're right. 
> I got confused because in ob-clojure.el, both cider and nrepl.el are 
> considered back-ends, so I thought they were separate things. So in fact, 
> nrepl.el is just an old incarnation of Cider? Ob-clojure.el needs a fixing, 
> I believe.
> Oops, I meant 
> nrepl.el: https://github.com/technomancy/nrepl.el/blob/master/nrepl.el
> On Friday, October 3, 2014 3:34:26 PM UTC+3, Bozhidar Batsov wrote:
>>
>> On October 3, 2014 at 3:06:08 PM, Daniel Szmulewicz (daniel.s...@gmail.com 
>> ) wrote:
>>
>> Hi Sanel and thanks for Monroe. 
>>
>> I think the use case is clear: lightweight alternative to Cider. 
>> So the question is what is the use case pertaining to nrepl.el, which is 
>> also lightweight.
>>
>> This question is a bit confusing as nrepl.el is cider’s old name. You 
>> can't really compare something with itself, but you can compare an old 
>> version of a project with its current version.
>>
>>
>>
>> On Wednesday, September 24, 2014 7:50:52 PM UTC+3, Sanel Zukan wrote:
>>>
>>> Hi everyone,
>>>
>>> Here  is initial release for Monroe, a 
>>> new Clojure nREPL client for Emacs. The main idea behind Monroe is to be 
>>> simple, easy to install (just put it in your *load-path*) and to work 
>>> like inferior modes (inferior-lisp or inferior-scheme), providing common 
>>> keybindings in REPL, including color and history support. You will also 
>>> need clojure-mode.el for code syntax highlighting, but this is optional.
>>>
>>> This initial release is ready for consumption (I'm using it on a bit 
>>> larger project) and feel free to drop me a line if you find some issues.
>>>
>>> Again, the url is https://github.com/sanel/monroe
>>>
>>> Best,
>>> Sanel
>>>
>> --
>> 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: What is the best setup to program Clojurescript IF...

[Ashton Kemerling]

If I recall vim has good tools.

On Thu, Oct 2, 2014 at 1:13 PM, Peter Mancini  wrote:

> What is the best setup to program Clojurescript IF:
>- you hate EMACS
>- use linux or windows
> Any suggestions?
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Acceptance testing with Clojure

[Ashton Kemerling]

Possibly, I don't know off the top of my head though.

On Mon, Sep 29, 2014 at 2:13 AM, Adrian Mowat 
wrote:

> Thanks for pointing out prism - it's just what I needed.
> Is there any way to add colours to the output so I can easily see if a test 
> failed?
> On Sunday, 28 September 2014 15:34:39 UTC+1, Ashton Kemerling wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- 
>> Hash: SHA1 
>>
>> I can answer this in two ways: 
>>
>> 1. Acceptance testing Clojure code. 
>> 2. Acceptance testing other code with Clojure. 
>>
>> I have significantly more experience with the latter than the former. 
>>
>> All in all, I prefer the built in clojure.test library over more 
>> opinionated libraries like Midje. In particular I recommend adding in 
>> Aphyr's excellent Prism plugin to your profiles.clj to do auto 
>> testing, and pjstadig`s similarly excellent humane-test-output for 
>> readability. 
>>
>> My dislike of midje stems from how awkward I found it to share setup 
>> code between tests. I feel that clojure.test nests more, allowing me 
>> to save more code up front. I also haven't used Midje in a while, so 
>> Brian might've upgraded it without me noticing. 
>>
>> You also cannot go wrong with test.check. I really enjoy using it for 
>> both correctness and simple profiling (e.g. print to console and see 
>> if anything gets too slow). 
>>
>> On the latter front, test.check + JDBC/Selenium/HTTP appears to be one 
>> of the most fruitful ways of hunting down bugs in single-page 
>> applications that I've ever seen. I think at this point the bug count 
>> for our testing code is close to 5 for an average of 3 hours per bug. 
>> Most of these bugs were either concurrency, caching, or SQL based, and 
>> some were close to 4 years old. I'll be giving a talk on this subject 
>> at the Conj this year, and the video will be posted later if you 
>> aren't attending. 
>>
>> For more info on test.check, you should check out Reid Draper's 
>> Cognicast episode 
>> (
>> http://thinkrelevance.com/blog/2013/11/11/reid-draper-cognicast-episode-045) 
>>
>> and my Cognicast episode 
>> (http://blog.cognitect.com/cognicast/ashton-kemerling-064) 
>>
>> On 09/28/2014 08:24 AM, Ruslan Prokopchuk wrote: 
>> > I've googled around a little bit, but didn't found any relevant 
>> > info about subject. Please, share your experience about acceptance 
>> > testing with Clojure! 
>> > 
>>
>> - -- 
>> Ashton 
>> -BEGIN PGP SIGNATURE- 
>> Version: GnuPG v1 
>>
>> iQIcBAEBAgAGBQJUKBxtAAoJEIkUqIW02x05kBMQALUcIDvGO+ohCVUJw2xC2HMT 
>> UPBK3eFHVhrgp84EqFx00A/+/sFmXM6wKWzcbTuEeG4YEuiea2UiZjqs7bFvqg3w 
>> L2j3CwGpG+eENSP4CQ4L2qB0n4ljuWSqHgH1eWYIGC98f6hKfMC2Itb7SEKWdm1M 
>> iYTQdFKhULbsmahwL1Z+dKuxe9Q6Vv20HahQan5T7JY8jE8QJI5d/icXI8xel6OV 
>> 3wlsW1AfBec1d7r/67R0MRnWqD2swE3WFbh+SlNQz/orSNvHvOLufhS5s0Xamtji 
>> xo59pX7xrAMkyf/a40HopHTcWD1Qkp9T0VBO0X43dfdbTH5gMdc7iOFmpHXj5EAi 
>> wbRRAtXp75F6tdYHf4n6I9y+N2auRz1SF1KOPb69mjkjx8Pujy8EwZdfpwABqLtu 
>> 4D06KlRrVmCiduvc0eVBcUVOa0o2lait2y0cMLa1M2Tt3rwNZb23nrJ3T9xXhrIY 
>> GKW/N+uQ2uC028Wqh3oFcOrjN6S6XU6rahhojCSSXsfMddmzsgz6qPdy3voAa68j 
>> e4Z/aP5Q9fPViW3j/E9FGmrQU89eOUdPVabbrJNu2J3DqGu3eaRLpAJP9oa5v7Q+ 
>> iEOGU38ZbLwMXhvw8VvMOnF9MKn9JAsoDZOPFOfuftZWmP1q0HqmBxxxg4WBW3hC 
>> 2EldloS4hNyaSJ4tIlex 
>> =djIk 
>> -END PGP SIGNATURE- 
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Acceptance testing with Clojure

[Ashton Kemerling]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I can answer this in two ways:

1. Acceptance testing Clojure code.
2. Acceptance testing other code with Clojure.

I have significantly more experience with the latter than the former.

All in all, I prefer the built in clojure.test library over more
opinionated libraries like Midje. In particular I recommend adding in
Aphyr's excellent Prism plugin to your profiles.clj to do auto
testing, and pjstadig`s similarly excellent humane-test-output for
readability.

My dislike of midje stems from how awkward I found it to share setup
code between tests. I feel that clojure.test nests more, allowing me
to save more code up front. I also haven't used Midje in a while, so
Brian might've upgraded it without me noticing.

You also cannot go wrong with test.check. I really enjoy using it for
both correctness and simple profiling (e.g. print to console and see
if anything gets too slow).

On the latter front, test.check + JDBC/Selenium/HTTP appears to be one
of the most fruitful ways of hunting down bugs in single-page
applications that I've ever seen. I think at this point the bug count
for our testing code is close to 5 for an average of 3 hours per bug.
Most of these bugs were either concurrency, caching, or SQL based, and
some were close to 4 years old. I'll be giving a talk on this subject
at the Conj this year, and the video will be posted later if you
aren't attending.

For more info on test.check, you should check out Reid Draper's
Cognicast episode
(http://thinkrelevance.com/blog/2013/11/11/reid-draper-cognicast-episode-045)
and my Cognicast episode
(http://blog.cognitect.com/cognicast/ashton-kemerling-064)

On 09/28/2014 08:24 AM, Ruslan Prokopchuk wrote:
> I've googled around a little bit, but didn't found any relevant
> info about subject. Please, share your experience about acceptance
> testing with Clojure!
> 

- -- 
Ashton
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUKBxtAAoJEIkUqIW02x05kBMQALUcIDvGO+ohCVUJw2xC2HMT
UPBK3eFHVhrgp84EqFx00A/+/sFmXM6wKWzcbTuEeG4YEuiea2UiZjqs7bFvqg3w
L2j3CwGpG+eENSP4CQ4L2qB0n4ljuWSqHgH1eWYIGC98f6hKfMC2Itb7SEKWdm1M
iYTQdFKhULbsmahwL1Z+dKuxe9Q6Vv20HahQan5T7JY8jE8QJI5d/icXI8xel6OV
3wlsW1AfBec1d7r/67R0MRnWqD2swE3WFbh+SlNQz/orSNvHvOLufhS5s0Xamtji
xo59pX7xrAMkyf/a40HopHTcWD1Qkp9T0VBO0X43dfdbTH5gMdc7iOFmpHXj5EAi
wbRRAtXp75F6tdYHf4n6I9y+N2auRz1SF1KOPb69mjkjx8Pujy8EwZdfpwABqLtu
4D06KlRrVmCiduvc0eVBcUVOa0o2lait2y0cMLa1M2Tt3rwNZb23nrJ3T9xXhrIY
GKW/N+uQ2uC028Wqh3oFcOrjN6S6XU6rahhojCSSXsfMddmzsgz6qPdy3voAa68j
e4Z/aP5Q9fPViW3j/E9FGmrQU89eOUdPVabbrJNu2J3DqGu3eaRLpAJP9oa5v7Q+
iEOGU38ZbLwMXhvw8VvMOnF9MKn9JAsoDZOPFOfuftZWmP1q0HqmBxxxg4WBW3hC
2EldloS4hNyaSJ4tIlex
=djIk
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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 to read a transit string from client side (transit-cljs) on server side (tansit-clj)

[Ashton Kemerling]

I think you should take a look at the transit-Clj README, it has docs and 
examples. 


https://github.com/cognitect/transit-clj/blob/master/README.md

On Thu, Sep 25, 2014 at 6:56 AM, Bin Li  wrote:

> Hi Guys,
> I was playing around the transit library recently , that is what I did:
> On client side , which using tansit-cljs (*clojrescript*)  :
> (def w (t/writer :json))
> (.send xhr
> url
> "POST"
> (transit/write w *{:test :test-value}*)
> #js {"Content-Type" "application/transit+json"})
> And from server side , using *clojure *:
> I got the string like: *["^ ","~:test","~:test-value"]*
> The question is how can I read this transit'ed string back to a map ?
> 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/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] lein-shorthand - a leiningen plugin to create namespaces with short names for use in the REPL

[Ashton Kemerling]

That's super helpful, thank you!

On Wed, Sep 24, 2014 at 6:17 AM, Hugo Duncan  wrote:

> In the REPL, there are functions that you always want to have handy, no
> matter which namespace you are in.  One way of achieving this is to put
> these functions into a namespace with a short name, like `.`, so you can
> refer to them easily.  The original idea came from Gary Fredericks, who
> also wrote dot-slash[1], which I discovered after writing this.
> The `lein-shorthand` plugin[2] lets you declare such a namespace in your
> leiningen profiles.
> e.g.
> {:user
>   {:dependencies [[alembic "0.3.2"]]
>:plugins [[com.palletops/lein-shorthand "0.4.0"]]
>:shorthand {. [alembic.still/distill alembic.still/lein]}}}
> This would allow you to use `(./lein deps :tree)` to run the lein deps
> task from any namespace, using alembic[3].
> See the README for full details, including how to make the shorthand
> functions load the required namespaces lazily, on first use.
> Hugo
> [1] https://github.com/gfredericks/dot-slash
> [2] https://github.com/palletops/lein-shorthand
> [3] https://github.com/pallet/alembic

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Assigning Values in Core.Logic

[Ashton Kemerling]

Aha, I believe the "is" method has solved my dilemma.

--
Ashton Kemerling

On Thu, Sep 18, 2014 at 7:56 PM, Ashton Kemerling  wrote:

> I can't tell if I'm being silly, but I'm having issues figuring out how to
> record the results of my computation in Core.Logic.
>
> The basic idea is that I'm trying to determine if a schedule a user has
> requested is solvable or not. I'm trying to find out how to assign to each
> hash-map what resource I determined can be used for it. The following case
> is simplistic, but I need to get this code working before attempting to
> generalize what the user has requested.
>
> (defn solve [types reservations]
>   (let [reservations (map #(assoc % :assigned-resource (l/lvar))
> reservations)
> resources (flatten (map :resources types))
> vars (repeatedly (count reservations) l/lvar)
> resource-vars (take (count by-resource) vars)
>
> ]
> (l/run 1 [q]
>(l/== q vars)
>;;
>(l/everyg #(l/membero % reservations) resource-vars)
>(l/everyg #(l/fresh [resource]
>(l/membero resource resources)
>(l/== % (l/partial-map {:resource
> resource}))
>;; Somehow assign resource to
> :assigned-resource here.
>)
>  resource-vars)
>
>
>(l/distincto resource-vars)
>)))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.

Assigning Values in Core.Logic

[Ashton Kemerling]

I can't tell if I'm being silly, but I'm having issues figuring out how to 
record the results of my computation in Core.Logic.

The basic idea is that I'm trying to determine if a schedule a user has 
requested is solvable or not. I'm trying to find out how to assign to each 
hash-map what resource I determined can be used for it. The following case 
is simplistic, but I need to get this code working before attempting to 
generalize what the user has requested.

(defn solve [types reservations]
  (let [reservations (map #(assoc % :assigned-resource (l/lvar)) 
reservations)
resources (flatten (map :resources types))
vars (repeatedly (count reservations) l/lvar)
resource-vars (take (count by-resource) vars)

]
(l/run 1 [q]
   (l/== q vars)
   ;; 
   (l/everyg #(l/membero % reservations) resource-vars)
   (l/everyg #(l/fresh [resource]
   (l/membero resource resources)
   (l/== % (l/partial-map {:resource resource}))
   ;; Somehow assign resource to 
:assigned-resource here.
   )
 resource-vars)


   (l/distincto resource-vars)
   )))

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: it's possible to query for optional parts on many relations?

[Ashton Kemerling]

Couldn't you just retrieve users and use "entity" to get their photos?

On Thu, Sep 18, 2014 at 4:43 PM, Wilker  wrote:

> Forgot to mention, I tried the (get-else) but it raises an error about
> cardinality many not supported, so I guessed it doesn't works here...
> ---
> Wilker Lúcio
> http://about.me/wilkerlucio/bio
> Woboinc Consultant
> +55 81 82556600
> On Thu, Sep 18, 2014 at 7:41 PM, Wilker  wrote:
>> Hi
>>
>> I'm trying to figure if I can make some parts of my query results to be
>> optional, for example, given the following query:
>>
>> [:find ?name ?age
>>  :where
>>  [?m :person/name ?name]
>>  [?m :person/age ?age]]
>>
>> This will return all entities that has a :person/name and :person/age. Ok,
>> so, if I want to make the name mandatory and the age optional, I can do:
>>
>> [:find ?name ?age
>>  :in $
>>  :where
>>  [?m :person/name ?name]
>>  [(get-else $ ?m :person/age 0) ?age]]
>>
>> Ok, so, for single values that works great, but what about this:
>>
>> [:find ?m ?name (vec ?url)
>>  :in $
>>  :where
>>  [?m :person/name ?name]
>>  [?m :photos ?p]
>>  [?p :file/url ?url]]
>>
>> On the previous query, it fetch every person that has at least 1 photo,
>> but not those that has no photos.
>>
>> How do I make to the query to return all entities that has name, having
>> photos or not (ideally the value would be a blank list for those without
>> photos)?
>>
>> Best regards.
>> ---
>> Wilker Lúcio
>> http://about.me/wilkerlucio/bio
>> Woboinc Consultant
>> +55 81 82556600
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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] www.core-async.info: a new web resource for core.async

[Ashton Kemerling]

That looks really nice! My only feedback is that it doesn't load at all on my 
iPhone.

On Thu, Sep 18, 2014 at 1:01 PM, Daniel Solano Gómez 
wrote:

> Hello, all,
> Over the past few months I have been working on creating some resources
> to help people learn to use core.async.  My goal is make this the best
> resource available to help people get started with core.async and to
> document best practices for composing applications with core.async.
> It is still a work in progress, but it currently includes the following:
> 1. An introduction to channels, buffers, and basic channel operations
> 2. A tutorial/workshop that introduces core.async using both Clojure and
>ClojureScript
> 3. A reference section of the core.async API, including both the
>Clojure and ClojureScript sources
> Please check it out at .
> I will continue to add more reference and tutorial material in the
> future.  Please let me know if there is anything you would think would
> be useful to add.
> Thanks,
> Daniel
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: why (> 2) returns true

[Ashton Kemerling]

I wouldn't be surprised if the 1 arg form is to help people who use > along 
with apply, just in case the list is only 1 element long.

On Wed, Sep 17, 2014 at 7:40 AM, Phillip Lord
 wrote:

> Herwig Hochleitner  writes:
>> 2014-09-17 11:51 GMT+02:00 Phillip Lord :
>>
>>>
>>> So, why not special case 1 arg as well, and have that except? It's a
>>> reasonable question. I would submit a bug report and see if anyone else
>>> agrees. Something is wrong for sure. Either (> x) should throw arity, or
>>> (>) should return true, or the docstring should be changed to note the
>>> special case for (>).
>>>
>>>
>> Totally agree, please post ticket number, so that we can favorite!
> http://dev.clojure.org/jira/browse/CLJ-1526
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: ECHELON: Wrangling messy political data

[Ashton Kemerling]

That's really neat. Planning on giving a talk?

On Tue, Sep 16, 2014 at 12:08 PM, kovas boguta 
wrote:

> Thats very cool!!
> On Tue, Sep 16, 2014 at 1:48 PM, Zack Maril  wrote:
>> This might be of interest to the Clojure/Datomic community:
>>
>> http://sunlightfoundation.com/blog/2014/09/16/wrangling-messy-political-data-into-usable-information/
>> https://github.com/sunlightlabs/echelon
>>
>> I'm part of the Influence Explorer team at the Sunlight Foundation. We're
>> building a system with Datomic and Instaparse to disentangle and analyze the
>> web of relationships between lobbyists, special interest groups, and
>> legislators. It's been surprisingly successful so far, as in it works as
>> well as we hoped it would when we first started building it. Datomic has
>> been a pleasure to use and Instaparse has been excellent so far. The above
>> link is a results oriented blog post about what we did and why we did it. We
>> haven't written up the technical details yet as they are still evolving
>> (we're attempting to move from the current static batch processing system to
>> hopefully a streaming approach in the near future). But, if you have any
>> questions about the project I'd be happy to answer them.
>> -Zack
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.7.0-alpha2

[Ashton Kemerling]

Perhaps me means dangerous as in it shouldn't be done causually, and that it 
could become a problematic habit if formed.

On Wed, Sep 10, 2014 at 8:55 PM, Brent Millare 
wrote:

> I understand usage of volatiles are dangerous via vswap! but what about 
> creation? Again relating to what you said, 'I asked Rich and he said 
> "making a volatile is as dangerous as any ! op".'
> On Wednesday, September 10, 2014 10:19:33 AM UTC-4, Alex Miller wrote:
>>
>> Usually that's called "visibility". 
>>
>> Atoms are *not* subject to race conditions if swap! is called from 
>> multiple threads (the state of the atom will not change while the update 
>> function is being applied). The atom is thus "safe" to be used from 
>> multiple threads.
>>
>> Volatiles *are* subject to race conditions with vswap! is called from 
>> multiple threads (the state of the volatile may change while the update 
>> function is being applied). The volatile is thus "dangerous" and safety is 
>> derived from how it's used.
>>
>> On Wednesday, September 10, 2014 8:44:27 AM UTC-5, Brent Millare wrote:
>>>
>>> When I say synchronization, I specifically mean "writes are guaranteed to 
>>> be seen by subsequent reads on any thread*" *as Alex said.
>>>
>>> On Wednesday, September 10, 2014 9:37:09 AM UTC-4, Brent Millare wrote:

 So to summarize, Clojure's volatile provides synchronization across 
 threads but does not provide atomaticity with vswap!. So, as a follow up 
 question, then why would the creation of a volatile be "dangerous" but 
 creating an atom isn't? (Hence the exclamation point in the name 
 "volatile!")

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

[Ashton Kemerling]

IIRC they are coming out in clojure 1.7. I don't see any indication of when it 
will be declared as stable, but there are alpha builds available if you need 
them. 


--

Ashton

On Thu, Sep 4, 2014 at 1:29 AM, cig  wrote:

> Thanks Alex. Feel silly not to have noticed the partition function. When 
> will transduces be available to use?
> On Wednesday, 3 September 2014 22:48:20 UTC+2, Alex Miller wrote:
>>
>> I think that's just a partition transducer on the channel?
>>
>>
>> On Wednesday, September 3, 2014 2:24:28 AM UTC-5, Gary Verhaegen wrote:
>>>
>>> I'd use another channel on which I put vectors of the correct length, 
>>> with an intermediate loop that takes from the first channel, accumulates 
>>> until the vector has the right size, and then put the vector on the second 
>>> channel.
>>>
>>> There might be a better solution with transducers, though. (Or without.)
>>>
>>> On Wednesday, 3 September 2014, cig  wrote:
>>>
 Thanks Timothy, that makes sense.

 A follow on question if you don't mind.

 I would like to 'take' n items off of a channel, but wait until n items 
 are available rather than eagerly returning the way take does. Do you have 
 any ideas on how
 I could achieve this?

 On Tuesday, 2 September 2014 22:23:10 UTC+2, tbc++ wrote:
>
> It's because into is pulling items as fast as it can from take. Sure 
> the buffer might get full but then into takes another value allowing take 
> to continue. 
>
> Timothy
>
>
> On Tue, Sep 2, 2014 at 1:48 PM, cig  wrote:
>
>> Hi
>>
>> I was expecting the following example to park, waiting for the 'out' 
>> channel to be cleared. Could anybody explain why 'take' does not
>> park when the output buffer size is smaller than the number of entries 
>> being taken from the input channel?
>>
>> (def from (to-chan [1 2 3 4 5 6 7]))
>> (> buffer size is 2 (less than 4 items being taken off of the 'from' 
>> channel)
>>
>> ;; => [1 2 3 4]
>>
>>
>>  -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was 
> that–lacking zero–they had no way to indicate successful termination of 
> their C programs.”
> (Robert Firth) 
>
  -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: StackOverflow TV Opportunity to Promote Clojure

[Ashton Kemerling]

I tried to email t...@stackoverflow.com and got delivery failure messages.

On Wed, Sep 3, 2014 at 1:55 PM, A. Webb  wrote:

> StackOverflow just announced an experimental project to produce videos in 
> its New York City office. This could be a great opportunity to polish up 
> one of your presentations and promote Clojure to a wide audience. No 
> speaker fees, but reasonable travel costs covered.
> Post: http://meta.stackoverflow.com/q/270574/1756702
> Email: t...@stackoverflow.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: Why is this an Exception ?

[Ashton Kemerling]

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

On Fri, Aug 29, 2014 at 11:56 AM, Sreeharsha Mudivarti
 wrote:

> (defn foo[]
>   (println bar/baz))
> (defn car[]
>   (println 42))
> ---
>  java -cp ~/clojure/clojure-1.6.0.jar  clojure.main foo.clj
> Exception in thread "main" java.lang.RuntimeException: No such namespace: 
> bar, compiling:(/Users/harsha/foobar/foo.clj:2:3)
> ...
> In Ruby and Python, the compiler is silent.
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Resolve function or object by name in ClojureScript

[Ashton Kemerling]

To be fair, calling from outside of Clojurescript is probably the only
use-case for this behavior that I can imagine, which is exactly what
^:export was designed (and named) for.

--
Ashton Kemerling


On Mon, Aug 25, 2014 at 12:18 PM, Thomas Heller  wrote:

> It is possible, the question is WHEN?
>
> You can make a function callable by name if you export it.
>
> (ns myns)
>
> (def ^:export testfn []
>   :foo)
>
> can be called like so, must be careful with name munging though:
>
> (let [the-fn (aget js/window "myns" "testfn")]
>   (the-fn))
>
> which also works with advanced compilation. I wouldn't recommend exporting
> all functions, but I do it for functions I want to use from HTML/JS.
>
> HTH,
> /thomas
>
>
> On Monday, August 25, 2014 6:09:29 PM UTC+2, David Nolen wrote:
>
>> Any such facility is at odds with Google Closure Compiler's advanced
>> compilation.
>>
>> David
>>
>> On Mon, Aug 25, 2014 at 11:59 AM, Timur  wrote:
>> > Hi everybody,
>> >
>> > Is there a way to resolve a function or object using its string name in
>> > ClojureScript? I found this however it is old:
>> >
>> > http://stackoverflow.com/questions/12020576/resolve-
>> function-throws-an-error-in-clojurescript-but-not-clojure/
>> 12020663#12020663
>> >
>> > 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 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: GSoC: Congratulations Aleksandr and Prasant!

[Ashton Kemerling]

Very Nice! I'd be particularly interested to see some benchmarks to show
off the improvements.

--
Ashton Kemerling


On Mon, Aug 25, 2014 at 12:57 PM, Mars0i  wrote:

> Thank you! to Prasant and Aleksandr.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 evaluated (question about transdurcers)

[Ashton Kemerling]

If you are referring to the new transducer comp, if I recall correctly it works 
in the opposite direction from the comp in clojure.core. I can't find any docs 
at hand that prove that, so I would check the docstring of comp.

On Sun, Aug 24, 2014 at 11:04 AM, rogergl  wrote:

> I have problems to understand how the following code evaluates. I 
> understand what the code does but not how this result is computed:
> BTW: This is an example from the async webinar:
> (chan 1 (comp (map #(.-keyCode %))
>   (filter #{37 39})
>   (map {37 :previous 39 :next})
> For example:  comp evaluates from right to left. But this code looks more 
> like it is evaluated from left to right ?
> Regards
>   Roger
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: CLISP books any good to learn Clojure

[Ashton Kemerling]

Just remember that Clisp 


1) not entirely immutable

2) not a hosted language




I worked in CL professionally for a year (SBCL in particular) and while clojure 
is closer to SBCL than it is to python, it is a different beast. CL is a more 
complicated language, with a long past and odd specs containing holdovers from 
decades gone by, and CL has pretty much absorbed every paradigm that has come 
out since it's inception. So I would recommend staying away from sections 
covering the Common Lisp object system (clos) or the meta object protocol 
(mop), as they have no real parallels in clojure.

On Sun, Aug 24, 2014 at 4:49 AM, Cecil Westerhof 
wrote:

> There are a lot of good (or so I am told) CLISP books. For example:
> “Paradigms Of Artificial Intelligence Programming Case Studies In Common
> Lisp”.
> Would they be useful for learning Clojure, or is the difference to big?
> I should at least have http://clojure.org/lisps handy. ;-)
> -- 
> Cecil Westerhof
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Presentation about Clojure

[Ashton Kemerling]

Whenever I try and sell Clojure, I sell four things:


   1. JVM based deploy and performance.
   2. A complete state model for safe and easy concurrency
   3. Macros to eliminate boilerplate and add features otherwise impossible
   4. An ecosystem of decoupled libraries that take a "no magic" approach,
   meaning fewer nasty surprises at update time.

Beyond that I would point out how leiningen just works, and do some
examples.

--
Ashton Kemerling


On Thu, Aug 21, 2014 at 6:32 AM, Serzh Nechyporchuk 
wrote:

>  ​Good idea, I am always a more technical person, but your way will be
>> more productive.
>> It is a two day event. I could ask if it would be possible to give it on
>> the first day and have the option to give a hands-on the second day if
>> there is interest for that.
>
>
> I also had a second talk too. In it I show production examples of using
> clojure and repl-driven development. So it will be very nice if you have
> time for a second talk too.
>
> You are welcome :)
>
> Четвер, 21 серпня 2014 р. 14:56:00 UTC+3 користувач Cecil Westerhof
> написав:
>>
>> 2014-08-21 13:43 GMT+02:00 Serzh Nechyporchuk :
>>
>> You can use this presentation as your own :)
>>>
>>
>> ​I probably will change some things (but reading the rest of your email
>> less as I expected), but will certainly at least mention it is inspired on
>> your presentation. Credit where credit is due.
>> I want to show the REPL (I find that a very big plus) and maybe something
>> about the ease to develop for the Android. I have not tried it yet, but as
>> I was told it is a breeze. If that is true, it is certainly something to
>> mention.
>>
>> ​
>>
>>
>>> The auditory I was talked to consists of:
>>> - several java
>>> - one clojure :)
>>> - rest python developers.
>>> In this presentation I intentionally don't focus on syntax and other
>>> "getting started" features. I think that this is less important and it is
>>> really easy to get in.
>>> The goal of this talk was not to teach write hello world programs. What
>>> I really focused on in this talk is power that clojure gives you.
>>>
>>
>> ​Good idea, I am always a more technical person, but your way will be
>> more productive.
>> It is a two day event. I could ask if it would be possible to give it on
>> the first day and have the option to give a hands-on the second day if
>> there is interest for that.
>>
>>
>>
>>> The presentation took about 45 minutes. But with questions it took about
>>> one hour.
>>>
>>
>> ​Should be doable then.
>>
>> Thanks again.​
>>
>> ​I am flabbergasted how useful this newsgroup is.​ :-D
>>
>>
>>
>>> 2014-08-21 14:26 GMT+03:00 Cecil Westerhof :
>>>
>>>> 2014-08-21 12:49 GMT+02:00 Serzh Nechyporchuk :
>>>>
>>>> In most programming languages cool features are provided as core
>>>>> functionality and you can't extend it manually. But in lisp you can do it
>>>>> just as library.
>>>>> For example:
>>>>> - Go channels - core.async
>>>>> - logic programming - core.logic
>>>>>
>>>>> Link to presentation https://docs.google.com/presentation/d/
>>>>> 1ewQYugwi9mBdogWMLGQM74uadrI-jw4Kf3Tasxve_bs/edit?usp=sharing
>>>>>
>>>>
>>>> ​Thank you very much. You have almost done all the work for me. ;-)
>>>>
>>>> I suppose that the people you gave this presentation to already knew
>>>> something?
>>>> How much time did your presentation take?​
>>>>
>>>>
>>>>
>>>>>
>>>>> 2014-08-21 13:39 GMT+03:00 Cecil Westerhof :
>>>>>
>>>>>>
>>>>>> 2014-08-21 12:33 GMT+02:00 Serzh Nechyporchuk :
>>>>>>
>>>>>> I can give you my presentation about Clojure. I have several
>>>>>>> questions:
>>>>>>>
>>>>>>> - (classic) parenthesis
>>>>>>> - How do you model your domain without objects?
>>>>>>> - About dsl. If clojure is good for dsl, does it mean that when you
>>>>>>> get new librarty with its own dsl, you have to learn new language?
>>>>>>> - How does new people adopts in your command?
>>>>>>> - What is production use of Clojure?
>>>>>>>
>>>>>>> That's a

Re: Is Clojure a language for growth?

[Ashton Kemerling]

I personally snuck it into my company in a limited fashion by selling its 
libraries, test.check in particular. This has gone quite well.

On Wed, Aug 20, 2014 at 1:28 PM, Quzanti  wrote:

> Whenever there is an external institutional stakeholder it is almost 
> guaranteed to happen. Someone in that external institution has a bonus or 
> promotion depending on the outcome, and will demand results. They will also 
> have penalty clauses in the contract which can be anything from 
> non-payment, to seizing control of a start up, or even shutting it down.
> I have seen it happen myself in England and Germany, and there are plenty 
> of well documented cases from the States so I don't think it is culturally 
> dependent in the sense of national culture.
> If you live in a blame free society let us know where as it would be an 
> excellent place for a start up!
> On Wednesday, August 20, 2014 7:16:55 PM UTC+1, Henrik Eneroth wrote:
>>
>>
>>  … as soon as anything goes wrong whether it has anything to do with the 
>>> technology choice or not you become mr fall guy, to be blamed and fired so 
>>> that other people can keep their jobs. Seen it happen so many times. 
>>>
>>
>> Good lord, truly? Perhaps this is a good time to ask what culture OP lives 
>> in. This wouldn't happen where I live/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: Transit Idea

[Ashton Kemerling]

I went ahead and wrote it. I'm sure there are some bugs to work out, but 
for now it works in the basic cases. The pullrequest for this feature can 
be located on Solr's github here: 
https://github.com/apache/lucene-solr/pull/85.

--
Ashton

On Wednesday, August 13, 2014 6:50:34 PM UTC-6, Alex Miller wrote:
>
> Sounds good to me. :) 
>
> On Wednesday, August 13, 2014 1:59:54 PM UTC-4, Ashton Kemerling wrote:
>>
>> I realized that Solr currently provides a lot of language-specific 
>> serializer options. Currently Ruby, Python, PHP, and javabin(?) are 
>> options, along with the normal json and xml. Wouldn't it make a lot of 
>> sense for us to add a transit-json and transit-messagepack options to Solr?
>>
>> --
>> Ashton
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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] lein-plz 0.1.1 - Add dependencies quickly

[Ashton Kemerling]

Ahh, I just had a coworker who is used to NPM complain about leiningen not 
having this, thank you!

--
Ashton

On Saturday, August 16, 2014 6:19:42 PM UTC-6, john walker wrote:
>
> Hello everyone.
>
> This is a lein plugin that helps you add dependencies to projects pretty 
> quickly. The git repo is here: https://github.com/johnwalker/lein-plz
>
> Basically, you write something like this:
>
>
> lein new foo
> cd foo
> lein plz add cljs async match jdbc
>
> and get this:
>
> (defproject foo "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :dependencies [[org.clojure/clojure "1.6.0"]
>  [org.clojure/clojurescript "0.0-2311"]
>  [org.clojure/core.async "0.1.319.0-6b1aca-alpha"]
>  [org.clojure/core.match "0.2.2"]
>  [org.clojure/java.jdbc "0.3.5"]])
>
> I hope it's useful.
>
> -- John
>

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

Transit Idea

[Ashton Kemerling]

I realized that Solr currently provides a lot of language-specific 
serializer options. Currently Ruby, Python, PHP, and javabin(?) are 
options, along with the normal json and xml. Wouldn't it make a lot of 
sense for us to add a transit-json and transit-messagepack options to Solr?

--
Ashton

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