Re: expectations 2.0 has been released

[Jay Fields]

Jochen (and anyone else affected by this): Sorry, took me a few days,
but I've released 2.0.7, which fixes all the bugs reported above.

Cheers, Jay

On Thu, Mar 13, 2014 at 6:54 AM, Jay Fields  wrote:
> Thanks for all the examples, I'll look today at getting these fixed up.
>
>
> On Thursday, March 13, 2014, Jochen  wrote:
>>
>> Hi Jay
>>
>> unfortunately I found another one, again on AssertionErrors but this time
>> with for-each:
>> (expect AssertionError (from-each [a [1 2]] (assert (string? a ;; all
>> pass as intended
>> (expect AssertionError (from-each [a [1 "2"]] (assert (string? a ;;
>> still all pass but should signal 1 error
>> (expect AssertionError (from-each [a ["1" 2]] (assert (string? a ;;
>> still all pass but should signal 1 error
>> (expect AssertionError (from-each [a ["1" "2"]] (assert (string? a ;;
>> shows both errors
>>
>> Ciao
>>
>> ...Jochen
>>
>> Am Mittwoch, 12. März 2014 02:28:37 UTC+1 schrieb Jay Fields:
>>>>
>>>> expectations is a minimilist's unit testing framework
>>>>
>>>> website: http://jayfields.com/expectations/
>>>> github: https://github.com/jaycfields/expectations
>>>>
>>>> changelog:
>>>> https://github.com/jaycfields/expectations/blob/master/CHANGELOG.md
>>>>
>>>> some large changes that will hopefully result in even more concise and
>>>> maintainable tests.
>>>>
>>>> feedback always welcome.
>>>>
>>>> Jay
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/exQyg9YUUas/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/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: expectations 2.0 has been released

[Jay Fields]

Thanks for all the examples, I'll look today at getting these fixed up.

On Thursday, March 13, 2014, Jochen  wrote:

> Hi Jay
>
> unfortunately I found another one, again on AssertionErrors but this time
> with for-each:
> (expect AssertionError (from-each [a [1 2]] (assert (string? a ;; all
> pass as intended
> (expect AssertionError (from-each [a [1 "2"]] (assert (string? a ;;
> still all pass but should signal 1 error
> (expect AssertionError (from-each [a ["1" 2]] (assert (string? a ;;
> still all pass but should signal 1 error
> (expect AssertionError (from-each [a ["1" "2"]] (assert (string? a ;;
> shows both errors
>
> Ciao
>
> ...Jochen
>
> Am Mittwoch, 12. März 2014 02:28:37 UTC+1 schrieb Jay Fields:
>
>> expectations is a minimilist's unit testing framework
>>>
>>> website: http://jayfields.com/expectations/
>>> github: https://github.com/jaycfields/expectations
>>>
>>> changelog: https://github.com/jaycfields/expectations/blob/master/
>>> CHANGELOG.md
>>>
>>> some large changes that will hopefully result in even more concise and
>>> maintainable tests.
>>>
>>> feedback always welcome.
>>>
>>> Jay
>>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 
> clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/exQyg9YUUas/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/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: expectations 2.0 has been released

[Jay Fields]

On Wednesday, March 12, 2014 2:53:09 PM UTC-4, Sean Corfield wrote:
>
> Since `given` was a relatively simple macro, we added it to 
> worldsingles.util.test and switched all our test namespaces to refer given 
> from there instead, and then upgraded to Expectations 2.0.6. Seems to have 
> gone smoothly. 
>

Sorry, just saw this email. 'given is pretty simple, and well contained. 
Adding it as a util seems like a great solution for your case.

While you're converting, if you run into a test that you want to convert 
but can't quite figure how, a good first pass might be to wrap the whole 
thing in from-each, do a comparison on the last line, and (expect true 
...). You lose all of expectations' smarter comparisons and better failure 
messages, but it can be a pragmatic choice while converting - allowing you 
to revisit when you're not focusing strictly on conversion.

I'm glad you're happy with the changes. We've been running the new version 
in prod for a few weeks and all seems well for us. That said, let me know 
if you run into issues and I'll fix them up asap.

Jay

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

expectations 2.0 has been released

[Jay Fields]

expectations is a minimilist's unit testing framework

website: http://jayfields.com/expectations/
github: https://github.com/jaycfields/expectations

changelog: https://github.com/jaycfields/expectations/blob/master/CHANGELOG.md

some large changes that will hopefully result in even more concise and
maintainable tests.

feedback always welcome.

Jay

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

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

On Wed, Feb 5, 2014 at 10:40 PM, Sean Corfield  wrote:
> FWIW, I find the language of Expectations to be much better suited to
> describing the desired behaviors of a system I want to build than the
> assertion-based language of clojure.test - so for me it's about
> test-before, not test-after.

Thinking more on this, when I originally wrote expectations, I was
doing all TDD at the time (in IntelliJ). The main focus on
expectations syntax as always been around maintainability, and my tdd
or test-after opinions would always take a back seat to
maintainability.

I'm glad it works well for you Sean; hopefully your team is just as happy. =)

Cheers, Jay

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

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

On Wed, Feb 5, 2014 at 4:35 PM, James Trunk  wrote:
> As a TDD practitioner and Expectations user, I've been following this thread
> with great interest!
>
> @Jay: Will your change in thinking have any impact on Expectations?

I don't anticipate making any changes to expectations, but it's likely
that my preference for test-after did help shape some of expectations
syntax. Writing tests after is pretty boring work, which is likely at
least part of the reason that you're able to write such concise tests
using expectations.

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

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

Colin, I'm using emacs-live: http://overtone.github.io/emacs-live/

To evaluate (+ 2 2) and spit the results I'm using C-u C-x C-e

It's definitely an evaluation, not a copy paste of the results.

Cheers, Jay

On Tue, Feb 4, 2014 at 11:43 AM, Colin Yates  wrote:
> Jay - in your demo I can't determine whether the (+ 2 2) expression is
> evaluated and the results pasted inline or whether you have manually pasted
> them?
>
> I see you are using emacs, can you detail how you have configured emacs?
>
>
> On Tuesday, 4 February 2014 16:33:44 UTC, Jay Fields wrote:
>>
>> On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:
>>>
>>> thanks for the report.  I only have few doubts about REPL making TDD to
>>> shame.
>>
>>
>> In this blog entry -
>> http://blog.jayfields.com/2014/01/repl-driven-development.html - I
>> demonstrate (very briefly, by design) my workflow. I also give my thoughts
>> on TDD.
>>
>> On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo
>> wrote:
>>>
>>> +1 from Melbourne :)
>>
>>
>> I actually gave the talk in Melbourne, as part of YOW!. It was recorded
>> and will be online at some point.
>>
>> On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:
>>>
>>> Is there going to be online access during/after the event?  I would
>>> greatly value seeing this, but probably not enough to travel from the UK to
>>> Chicago :).
>>
>>
>> This talk will not be recorded (afaik), but it's the same as the YOW!
>> version, and that should be online soon.
>>
>> On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:
>>>
>>> A question: did you abandon TDD? why?
>>> IMO, TDD is a workflow that pushes for simplicity
>>
>>
>> TDD, yes, for the most part. However, I still write a large number of
>> tests. YMMV though, as you may find that TDD gives you better design
>> direction. Assuming that's the case, I'd never try to convince you to do
>> something else. This is an experience report, not a prescription for
>> adopting Clojure. =)
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/huwg05Vl2RY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:

> thanks for the report.  I only have few doubts about REPL making TDD to 
> shame. 
>

In this blog entry - 
http://blog.jayfields.com/2014/01/repl-driven-development.html - I 
demonstrate (very briefly, by design) my workflow. I also give my thoughts 
on TDD.

On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo 
wrote:
>
> +1 from Melbourne :)
>

I actually gave the talk in Melbourne, as part of YOW!. It was recorded and 
will be online at some point.

On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:
>
> Is there going to be online access during/after the event?  I would 
> greatly value seeing this, but probably not enough to travel from the UK to 
> Chicago :).
>

This talk will not be recorded (afaik), but it's the same as the YOW! 
version, and that should be online soon. 

On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:
>
> A question: did you abandon TDD? why?
> IMO, TDD is a workflow that pushes for simplicity
>

TDD, yes, for the most part. However, I still write a large number of 
tests. YMMV though, as you may find that TDD gives you better design 
direction. Assuming that's the case, I'd never try to convince you to do 
something else. This is an experience report, not a prescription for 
adopting Clojure. =) 


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

Lessons Learned from Adopting Clojure

[Jay Fields]

tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in
Chicago on Feb 11th:
http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf

Five years ago DRW Trading was primarily a Java shop, and I was
primarily developing in Ruby. Needless to say, it wasn't a match made
in heaven. Fast forward five years, Clojure is the second most used
language in the firm, and the primary language for several teams
(including mine). Clojure wasn't the first language that I've
introduced to an organization; however, it's unquestionably the most
successful adoption I've ever been a part of. The use of Clojure has
had many impacts on the firm: culturally, politically, and
technically. My talk will discuss general ideas around language
selection and maintenance trade-offs, and specific examples of what
aspects of Clojure made it the correct choice for us.

A few highlights

- Where to first introduce a new language and your role as the
language care-taker.
- REPL driven development, putting TDD's 'rapid feedback' to shame.
- Operations impact of adding a language - i.e. get ready for some DevOps.
- Functional programming, the Lisp Advantage, and their impact on
maintainability.

Of course, no good experience report is all roses. The adoption has
seen several hurdles along the way, and I'll happily to describe those
as well.

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

Re: What's your testing flow with the current clj tools?

[Jay Fields]

sorry, I forgot to mention you can you also expectations/run-all-tests
(with or without a regex) if you're the kind of developer who likes to
live in the repl.

On Sat, Jan 25, 2014 at 8:19 AM, Jay Fields  wrote:
> I use emacs & expectations[1]
>
> These days I do more repl-driven-development than
> test-driven-development, so the tests tend to come after solving the
> problem at hand. At that point I run all the tests via "lein
> expectations"[2] to get an idea of what's broken. Now that I know what
> test namespaces contain broken tests, I'll open those namespaces in
> emacs and execute them individually with expectations-mode[3]. One
> execution makes it clear which tests are broken, and my next step is
> to fix the existing tests. Once that's done, I take a look at my
> current changes, and determine if any new tests need to be written.
>
> A few friends of mine prefer a more continuous testing style, which is
> also possible if you use lein-autoexpect[4]. One of my friends wrote
> up his experiences on continuous testing here:
> http://jakemccrary.com/blog/2011/12/16/continuous-testing-with-clojure-and-expectations/
>
> I would say above all, you should try out all the tools that are
> available to you, and find out what works best for you. The
> testing/coding flow seems to vary greatly by person, so what's "most
> effective" will largely be driven by you, not by the tools.
>
> [1] http://jayfields.com/expectations/
> [2] https://github.com/gar3thjon3s/lein-expectations
> [3] https://github.com/gar3thjon3s/expectations-mode
> [4] https://github.com/jakemcc/lein-autoexpect
>
> On Sat, Jan 25, 2014 at 12:57 AM, Alexandr Kurilin  wrote:
>> I've been running my app's tests through `lein test` (most often for
>> specific namespaces) for a long time now, but after reading Leiningen's
>> recommendation to run them from the REPL I decided I should figure out how
>> to make this happen.
>>
>> I've heard a few options on this subject, and would love to know what you
>> yourselves use. A couple I stumbled upon were:
>>
>> In your favorite editor with nrepl/cider, do some work in the ns you're
>> testing, reload it from within the editor, then switch to the testing ns and
>> run (clojure.test/run-tests) from within. Then when you're done with your
>> work, run a `lein test` just in case your state while nrepling in was
>> corrupted or another ns was affected etc.
>> Use your favorite editor with nrepl/cider to work on the app's ns, but then
>> switch to a repl started within `lein repl` in which you're only running
>> tests. This potentially helps with a slightly cleaner state. (I'm not clear
>> how you'd reload the app's ns without the hassle of having to always
>> (require) the right set of changed nses)
>> In a new `lein repl`, use bultitude, load all test nses, use
>> clojure.test/run-all-tests with the right regex. Like `lein repl`, minus
>> having to spin up a new JVM every time.
>>
>> I'm currently playing around with the first approach. I'd love to know if I
>> missed something much more effective, or if I can make this a bit simpler
>> and less manual. Tips would be greatly welcome.
>>
>> Cheers!
>>
>>
>> --
>> Alexandr Kurilin
>> 206.687.8740 | @alex_kurilin | blog
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: What's your testing flow with the current clj tools?

[Jay Fields]

I use emacs & expectations[1]

These days I do more repl-driven-development than
test-driven-development, so the tests tend to come after solving the
problem at hand. At that point I run all the tests via "lein
expectations"[2] to get an idea of what's broken. Now that I know what
test namespaces contain broken tests, I'll open those namespaces in
emacs and execute them individually with expectations-mode[3]. One
execution makes it clear which tests are broken, and my next step is
to fix the existing tests. Once that's done, I take a look at my
current changes, and determine if any new tests need to be written.

A few friends of mine prefer a more continuous testing style, which is
also possible if you use lein-autoexpect[4]. One of my friends wrote
up his experiences on continuous testing here:
http://jakemccrary.com/blog/2011/12/16/continuous-testing-with-clojure-and-expectations/

I would say above all, you should try out all the tools that are
available to you, and find out what works best for you. The
testing/coding flow seems to vary greatly by person, so what's "most
effective" will largely be driven by you, not by the tools.

[1] http://jayfields.com/expectations/
[2] https://github.com/gar3thjon3s/lein-expectations
[3] https://github.com/gar3thjon3s/expectations-mode
[4] https://github.com/jakemcc/lein-autoexpect

On Sat, Jan 25, 2014 at 12:57 AM, Alexandr Kurilin  wrote:
> I've been running my app's tests through `lein test` (most often for
> specific namespaces) for a long time now, but after reading Leiningen's
> recommendation to run them from the REPL I decided I should figure out how
> to make this happen.
>
> I've heard a few options on this subject, and would love to know what you
> yourselves use. A couple I stumbled upon were:
>
> In your favorite editor with nrepl/cider, do some work in the ns you're
> testing, reload it from within the editor, then switch to the testing ns and
> run (clojure.test/run-tests) from within. Then when you're done with your
> work, run a `lein test` just in case your state while nrepling in was
> corrupted or another ns was affected etc.
> Use your favorite editor with nrepl/cider to work on the app's ns, but then
> switch to a repl started within `lein repl` in which you're only running
> tests. This potentially helps with a slightly cleaner state. (I'm not clear
> how you'd reload the app's ns without the hassle of having to always
> (require) the right set of changed nses)
> In a new `lein repl`, use bultitude, load all test nses, use
> clojure.test/run-all-tests with the right regex. Like `lein repl`, minus
> having to spin up a new JVM every time.
>
> I'm currently playing around with the first approach. I'd love to know if I
> missed something much more effective, or if I can make this a bit simpler
> and less manual. Tips would be greatly welcome.
>
> Cheers!
>
>
> --
> Alexandr Kurilin
> 206.687.8740 | @alex_kurilin | blog
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: is there a tutorial about working at the REPL?

[Jay Fields]

make the app work with 'lein run' and it'll work in the repl as well.

On Sun, Dec 29, 2013 at 4:30 PM, larry google groups
 wrote:
>> If it can't find the file, `clojure.java.io/resource` returns nil; and
>> (slurp
>> nil) throws an IllegalArgumentException, which doesn't seem to be the
>> error
>> you're getting.
>
>
> Thanks for that. But the app has no problem reading the schema.edn file when
> I start the app with:
>
> java -jar admin-1-standalone.jar
>
> So why would it have trouble reading the file when I'm in the repl?
>
>
>
> On Sunday, December 29, 2013 12:55:04 AM UTC-5, John Mastro wrote:
>>
>> Hi Larry,
>>
>> > 4.) load whatever file holds the (main-) function that starts the app.
>> > So for
>> > me, for instance, it might be: (load-file "src/admin/core.clj")
>>
>> I don't think the `load-file` should be necessary. Do things not work if
>> you
>> omit it?
>>
>> The code on disk when you jacked in will already have been loaded, so you
>> should only need to re-evaluate it (whether through cider/nrepl.el,
>> `load-file`, or what have you) if you've made subsequent changes. I tend
>> to use
>> `cider-eval-defun-at-point`, `cider-eval-last-sexp`, or
>> `cider-eval-region` to
>> evaluate just the code I've changed rather than reloading the whole file.
>> (Actually, lately I've been using the `tools.namespace`[1] approach a lot,
>> but
>> that's probably a separate topic).
>>
>> (Cider[2], by the way, is just nrepl.el's new name).
>>
>> > But when I want to work on this app at the REPL, the app seems unable to
>> > find
>> > the schema.edn file. You can see my REPL session below. The function
>> > (initiate-forms) has this line: (read-string (slurp
>> > (clojure.java.io/resource
>> > "config/schema.edn")))
>>
>> I'm not positive, but I don't think the issue is that it can't find
>> "config/schema.edn". What's the result of (clojure.java.io/resource
>> "config/schema.edn")?
>>
>> If it can't find the file, `clojure.java.io/resource` returns nil; and
>> (slurp
>> nil) throws an IllegalArgumentException, which doesn't seem to be the
>> error
>> you're getting.
>>
>> [1] https://github.com/clojure/tools.namespace
>> [2] https://github.com/clojure-emacs/cider
>>
>> - 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/groups/opt_out.

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

Re: Best way to loop a map of maps

[Jay Fields]

I was going to type in the example with multiple bindings, but this
will probably be more helpful:
http://blog.jayfields.com/2013/05/clojure-combining-calls-to-doseq-and-let.html

On Tue, Dec 3, 2013 at 6:05 PM, Ryan  wrote:
> Hi all,
>
> I am trying to figure out a better way to loop the following map than using
> nested doseq. The map has the following structure:
>
>> (def m
>>   {"outerKeyA" {:innerKeyA {"string id" {:foo 1 :bar 2}}}
>>"outerKeyB" {:innerKeyB {"string id" {:bar 5 :baz 10)
>
>
> So, right now i am doing the following:
>
>> (doseq [[outer-keys collections] m]
>>   (doseq [[collection-name collection] collections]
>> (doseq [[string-id data] collection]
>>   ;; do stuff with all the above
>> )))
>
>
> Is there a more idiomatic/better way to do deeply nested
> iterations/traversal of map of maps?
>
> Thank you for any replies!
>
> Ryan
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Breaking out of doseq

[Jay Fields]

I'm not sure doseq is what you want.. I'd probably just use loop recur.

On Wed, Nov 27, 2013 at 9:43 AM, Jonathon McKitrick
 wrote:
> To clarify what I'm trying to do, I have a map of regexes, and after
> iterating them, when one matches (the order of the regexes is significant) I
> want exactly one result returned by applying the looked up function to the
> string.  After that regex matches, no more matches should be attempted.
>
> What is the 'reduced' function?
>
>
> On Wednesday, November 27, 2013 9:26:21 AM UTC-5, Jonathon McKitrick wrote:
>>
>> I'm iterating a map (regex -> function) and I'd like to call FUNCTION with
>> the result of re-groups after a match for REGEX is found.  I also want to
>> exit the sequence, returning the results of FUNCTION.  In common lisp, I
>> would use return-from, but how would this be done in clojure?
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: maintainability, DSLs, declarative APIs, etc.

[Jay Fields]

On Fri, Nov 15, 2013 at 3:30 PM, Brian Craft  wrote:
> I've heard people doing contract work in ruby swearing when
> they encounter another DSL: it kills their productivity.
>

those same people wouldn't have Ruby contracting work if it weren't
for metaprogramming...

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

Re: maintainability, DSLs, declarative APIs, etc.

[Jay Fields]

I've worked extensively in Java, Ruby, and Clojure, so I have plenty
of experience with having and not having meta-programming and macros.
In my opinion meta-programming and macros are not black art, they are
simply part of the language. If someone chooses to do something that
isn't easy to understand, that's not the fault of the language, it's
the fault of the programmer.

(this is the royal You, not Brian)
Your language choice should probably factor in your desire to dig into
metaprogramming or macros. You don't need to use those features of the
language in your own code, but you'll surely run into both using
someone else's framework or library. If you prefer not to deal with
the complexities that can arise from having those features available,
not using Ruby or Clojure is probably a good choice. Conversely, if
you want the power of metaprogramming and macros, and are willing to
learn them deeply enough that you can deal with some poorly written
metaprogramming or macros, then you should prefer Ruby or Clojure.
Better to have the ability when you desire it, than not to have it -
if you're willing to put up with other people (ab)using that power at
times.

It's a balance, and I strongly believe that people program in many
different ways. (among other tradeoffs) You can have a powerful IDE
and a ton of boiler plate, explicit code, or you can have little
refactoring support and the ability to eliminate the boiler plate
code; you have to chose which you value more. You also need to know
that the choice you make will eliminate working with some people -
those that choose the other way. Neither group of people will be good
or bad, both will have great and terrible programmers who simply
prefer to program in differing ways.

On Fri, Nov 15, 2013 at 2:51 PM, Brian Craft  wrote:
> Pulling this from another thread:
>
> On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:
>
> The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no
> magic (Python). This probably comes down to personal preference, and so is a
> potential benefit of any of them, depending on your preference, but it's a
> significant difference, so it's worth pointing out. By "magic" I just mean
> when the system seems to be more doing something much more powerful than you
> can readily see just by looking at the code. A simple few lines of code are
> doing all these wondrous things that aren't spelled out completely in the
> code (unless you peek under the covers and can understand the black arts
> that lie there). In Ruby/Rails this is the result of a lot of
> metaprogramming happening, based on conventions (that must be learned). In
> Clojure this happens through macros that implement powerful DSLs. In Python,
> it doesn't happen nearly as much. Code tends to be more transparent.
>
>
>
> This description of ruby, clojure, and python very much matches my
> experience (though with ruby I'm relying on the accounts of other developers
> that I know, since I haven't personally used ruby).
>
> Why are black arts and opaque code desirable? It's almost a tautology that
> these things are unmaintainable: you can't maintain code if you can't
> readily understand it, e.g. if it depends on "black arts", or is not
> transparent.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: blog article on RSpec like TDD with a rapid feedback cycle in Clojure

[Jay Fields]

expectations has the same thing as well:
https://github.com/jakemcc/lein-autoexpect

I think midje, speclj, and expectations all have emacs modes as well -
which completely eliminate the JVM start up issue.

On Sun, Oct 20, 2013 at 4:36 PM, Waldemar
 wrote:
> I suspected as much.
> Thanks for the link. I did put it in as a comment.
>
> Best regards,
> Waldemar
>
> Am 20.10.2013 um 22:24 schrieb Korny Sietsma :
>
> Note you can do the same thing in midje :
> https://github.com/marick/Midje/wiki/Auto test - it works quite nicely.
>
> On 20 Oct 2013 21:04, "Waldemar"  wrote:
>>
>> I noticed that some struggle finding a good TDD workflow, in Clojure, with
>> a rapid feedback cycle because of the JVM startup time. Especially the
>> people comming from RSpec.
>>
>> So I wrote down my workflow, that is based on speclj, which supports
>> auotesting and the typical "describe" "it" "should" way of describing
>> things.
>> When using the autotesting feature, it keeps a JVM running, this way test
>> run with only milliseconds of overhead.
>>
>>
>> http://velrok.github.io/blog/2013/10/20/test-driven-development-tdd-with-clojure/
>>
>> All the best,
>> Waldemar
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: reference types (var, atom, ref, agent) and add-watch: deterministic order of notification

[Jay Fields]

Watch behavior varies a bit by ref type, I believe. You'll probably
want to look into the details of the specific ref type you're using.

for atoms and refs, I believe the watch is done on the thread that's
updating the ref. Since retries can occur you can't really count on
ordering. You could create your own thread to single thread the action
- I've done that in the past with success. While you can't rely on
ordering, having the old and new value to diff might be enough to know
what actions you want to perform in your watch (on your single thread)

for agents, I believe everything will be single threaded and in the
order of agent updates.

On Fri, Sep 13, 2013 at 8:04 AM, gixxi
 wrote:
> Hi,
>
> i got a question on reference type instances with attached watches.
>
> Consider a reference type instance R with a watch W attached by (add-watch R
> :watcher #(...)) and
>
> a n parallel activities committing a transition to R in some monotonic order
> 0..n-1.
>
> Does Clojure ensure that the function calls by the watch dog are executed in
> the very same order? Is it possible to wrap the watch dog notification in a
> synchronisation block?
>
> Thanks in advance
>
> Best regards
>
> Christian
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Sorting a collection on multiple fields

[Jay Fields]

No - I honestly missed that version of yours the first time. I like
that solution, and prefer it to the sort-by-map final solution.
Probably just a style pref though.

On Wed, Sep 11, 2013 at 6:07 PM, ulsa  wrote:
> Interesting. You used recursion, where I tried to see it as a sequence. Any
> other differences?
>
> My solution was:
>
> (defn compare-many [comps]
>   (fn [xs ys]
> (if-let [result (first (drop-while zero? (map (fn [f x y] (. f (compare
> x y))) comps xs ys)))]
>   result
>   0)))
>
> (->> [{:name "zack" :age 25} {:name "amanda" :age 19}
>   {:name "zack" :age 20} {:name "zack" :age 21}]
>  (sort-by (juxt :name :age) (compare-many [compare >])))
>
>
> On Saturday, 31 August 2013 17:28:45 UTC+2, Jay Fields wrote:
>>
>> I would solve it like this-
>>
>>   (defn multi-compare [[c & cs] [x & xs] [y & ys]]
>> (if (= x y)
>>   (multi-compare cs xs ys)
>>   (c x y)))
>>
>>   (defn multi-comparator [comparators]
>> (fn [xs ys]
>>   (if (= (count xs) (count ys) (count comparators))
>> (multi-compare comparators xs ys)
>> (throw (RuntimeException. "count not equal")
>>
>>
>>   (->> [{:name "zack" :age 25} {:name "amanda" :age 19}
>> {:name "zack" :age 20} {:name "zack" :age 21}]
>>(sort-by (juxt :name :age) (multi-comparator [compare >]))
>>)
>>
>> On Sat, Aug 31, 2013 at 9:04 AM, Leonardo Borges
>>  wrote:
>> > Would this help?
>> >
>> > (sort-by (juxt :key1 :key2) your-list-of-maps)
>> >
>> > On 31/08/2013 7:57 PM, "ulsa"  wrote:
>> >>
>> >> I wanted to sort a sequence of maps using a spec consisting of an
>> >> ordered
>> >> map of key and order, like this:
>> >>
>> >> (array-map :name 1 :age -1)
>> >>
>> >> I couldn't find a ready-made solution, so I rolled my own. I ended up
>> >> with
>> >> three functions with a total of 10 lines of code. Two of them are
>> >> generic,
>> >> and one is specific to my problem.
>> >>
>> >> First a comparator-generator, that is fed a collection of comparators:
>> >>
>> >> (defn compare-many [comps]
>> >>   (fn [xs ys]
>> >> (if-let [result (first (drop-while zero? (map (fn [f x y] (. f
>> >> (compare x y))) comps xs ys)))]
>> >>   result
>> >>   0)))
>> >>
>> >> It uses the same trick as sort-by does, namely the fact that all
>> >> functions
>> >> implement Comparator. This means that I can pass in a predicate instead
>> >> of a
>> >> comparator, if it makes sense:
>> >>
>> >> user=> ((compare-many [> compare]) [4 "beta"] [4 "alpha"])
>> >> 1
>> >> user=> ((compare-many [> compare]) [4 "beta"] [3 "gamma"])
>> >> -1
>> >>
>> >> Next, a convenience function that takes a collection of keyfns, a
>> >> collection of comparators (or predicates), and a collection to sort,
>> >> passing
>> >> it to sort-by:
>> >>
>> >> (defn sort-by-many [keyfns comps coll] (sort-by (apply juxt keyfns)
>> >> (compare-many comps) coll))
>> >>
>> >> It's called like this:
>> >>
>> >> user=> (sort-by-many [:a :b] [> compare] [{:a 4 :b "beta"} {:a 4 :b
>> >> "alpha"} {:a 3 :b "gamma"} {:a 5 :b "delta"}])
>> >> ({:a 5, :b "delta"}
>> >>  {:a 4, :b "alpha"}
>> >>  {:a 4, :b "beta"}
>> >>  {:a 3, :b "gamma"})
>> >>
>> >> And finally a function specific to my problem domain. It takes a sort
>> >> order map and the collection to sort (note that I use (comp - compare)
>> >> to
>> >> get the inverse sort order):
>> >>
>> >> (defn sort-by-map [m coll]
>> >>   (sort-by-many (keys m)
>> >>(map #(case % 1 compare -1 (comp - compare) (throw
>> >> (Exception. "1 or -1"))) (vals m))
>> >>coll))
>> >>
>> >> It's called like this:
>> >>
>> >> user=> (sort-by-map (array-map :name 1 :age -1)
>> >> 

Re: Sorting a collection on multiple fields

[Jay Fields]

I would solve it like this-

  (defn multi-compare [[c & cs] [x & xs] [y & ys]]
(if (= x y)
  (multi-compare cs xs ys)
  (c x y)))

  (defn multi-comparator [comparators]
(fn [xs ys]
  (if (= (count xs) (count ys) (count comparators))
(multi-compare comparators xs ys)
(throw (RuntimeException. "count not equal")


  (->> [{:name "zack" :age 25} {:name "amanda" :age 19}
{:name "zack" :age 20} {:name "zack" :age 21}]
   (sort-by (juxt :name :age) (multi-comparator [compare >]))
   )

On Sat, Aug 31, 2013 at 9:04 AM, Leonardo Borges
 wrote:
> Would this help?
>
> (sort-by (juxt :key1 :key2) your-list-of-maps)
>
> On 31/08/2013 7:57 PM, "ulsa"  wrote:
>>
>> I wanted to sort a sequence of maps using a spec consisting of an ordered
>> map of key and order, like this:
>>
>> (array-map :name 1 :age -1)
>>
>> I couldn't find a ready-made solution, so I rolled my own. I ended up with
>> three functions with a total of 10 lines of code. Two of them are generic,
>> and one is specific to my problem.
>>
>> First a comparator-generator, that is fed a collection of comparators:
>>
>> (defn compare-many [comps]
>>   (fn [xs ys]
>> (if-let [result (first (drop-while zero? (map (fn [f x y] (. f
>> (compare x y))) comps xs ys)))]
>>   result
>>   0)))
>>
>> It uses the same trick as sort-by does, namely the fact that all functions
>> implement Comparator. This means that I can pass in a predicate instead of a
>> comparator, if it makes sense:
>>
>> user=> ((compare-many [> compare]) [4 "beta"] [4 "alpha"])
>> 1
>> user=> ((compare-many [> compare]) [4 "beta"] [3 "gamma"])
>> -1
>>
>> Next, a convenience function that takes a collection of keyfns, a
>> collection of comparators (or predicates), and a collection to sort, passing
>> it to sort-by:
>>
>> (defn sort-by-many [keyfns comps coll] (sort-by (apply juxt keyfns)
>> (compare-many comps) coll))
>>
>> It's called like this:
>>
>> user=> (sort-by-many [:a :b] [> compare] [{:a 4 :b "beta"} {:a 4 :b
>> "alpha"} {:a 3 :b "gamma"} {:a 5 :b "delta"}])
>> ({:a 5, :b "delta"}
>>  {:a 4, :b "alpha"}
>>  {:a 4, :b "beta"}
>>  {:a 3, :b "gamma"})
>>
>> And finally a function specific to my problem domain. It takes a sort
>> order map and the collection to sort (note that I use (comp - compare) to
>> get the inverse sort order):
>>
>> (defn sort-by-map [m coll]
>>   (sort-by-many (keys m)
>>(map #(case % 1 compare -1 (comp - compare) (throw
>> (Exception. "1 or -1"))) (vals m))
>>coll))
>>
>> It's called like this:
>>
>> user=> (sort-by-map (array-map :name 1 :age -1)
>>  [{:name "zack" :age 25} {:name "amanda" :age 19} {:name "zack"
>> :age 20} {:name "zack" :age 21}])
>> ({:age 19, :name "amanda"}
>>  {:age 25, :name "zack"}
>>  {:age 21, :name "zack"}
>>  {:age 20, :name "zack"})
>>
>> The collection doesn't have to contain maps:
>>
>> user=> (sort-by-map (array-map first 1 second -1) [["zack" 25] ["amanda"
>> 19] ["zack" 20] ["zack" 21]])
>> (["amanda" 19]
>>  ["zack" 25]
>>  ["zack" 21]
>>  ["zack" 20])
>>
>> Is there anything that I've missed? Improvements?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

profiler?

[Jay Fields]

What are you all using these days? I've been using YourKit and I'm
fairly happy with it. Just making sure I'm not missing out on some new
hotness.

Cheers, Jay

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

Re: Place of function?

[Jay Fields]

you're probably looking for fn?

On Mon, Aug 26, 2013 at 9:11 AM, Christian Sperandio
 wrote:
> Hi,
>
> Does anyone know why the functions like: map?, number?, vector?, … belongs to 
> the clojure.core but not  function? ?
>
> Christian
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: preference and implications of using as-> vs let

[Jay Fields]

On Mon, Aug 19, 2013 at 6:41 PM, Anand Prakash  wrote:
> What is the major benefit of as->
>
> => (-> 4 (#(* % %)) (+ 12) )
>
> 28
>
> => (-> 4 (as-> y (* y y)) (+ 12))
>
> 28

Solving the contrived example doesn't really help answer the original
question of preference and tradeoffs. As to the benefits of as->, I'd
defer to the benefits of threading macros in general.

The actual production code I'd originally written had this shape,
though I suspect it won't make much sense without context.

(defn foo [xrel yrel]
  (as-> (filter #(= "a val" (:a-key %)) xrel) x
(map :b-key x)
(set x)
(filter (comp x :b-key) yrel)
(set x)))

The above solution can be written in many ways, including
- a single let to build the filter predicate
(defn foo [xrel yrel]
  (let [pred (->> xrel (filter (comp (partial = "a val") :a-key)) (map
:b-key) set)]
(set (filter (comp pred :b-key) yrel

and many other options as well
- using the -> macro, wrapping the map with a (->>) and extracting the
comp to (it's own) line above
- using clojure.set/project, select-keys, & clojure.set/select
- using group-by to create a map that you use as the filter pred
etc, etc.

The two that I found the most readable were
A. the above as solution, my first example
B. single let that builds the predicate set, my second example

I find that A, in my opinion, eliminates a let, but sacrifices a bit
of readability at a high level - i.e. it's hard to look at the parts
of the function and determine the sum of what you're trying to do.
Conversely, I find that B includes a let that's strictly introduced
for readability, and sacrifices low level readability - i.e. the parts
are not easy to digest, but once you've figured them out the sum of
what you're trying to do is very obvious.

I haven't decided which I prefer, though I tend to lean towards A,
considering it to be (as David described) an elimination of a
superfluous let.

Cheers, Jay

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

preference and implications of using as-> vs let

[Jay Fields]

In the past, I've written code like the following

(defn foo [x y]
  (let [x-squared (* x x)]
(if (pos? y)
  (+ x-squared y)
  (- x-squared y

However, the introduction of as-> has led me to write the following, at times

(defn foo [x y]
  (as-> (* x x) x-squared
(if (pos? y)
  (+ x-squared y)
  (- x-squared y

In essence, I've started replacing single binding lets with as->. John
Hume has pointed out that as-> seems to have been introduced to work
in conjunction with ->. Which brings me to my question - do you think
it's better to use a single binding let from a readability
perspective? Are there any (performance or otherwise) impacts that I
should be aware of?

Cheers, Jay

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

Re: function creation, partial or #()

[Jay Fields]

Sean, it sounds like you want

(swap! some-a update-in [:k1 :k2] (fnil conj []) id)

But that's based on some pretty limited context.

On Friday, August 16, 2013, Sean Corfield wrote:

> On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge 
> >
> wrote:
> > I'm just going to throw this out there, but I almost always consider
> using
> > #() instead of (fn []) to be bad practice.
>
> I still use #() for anonymous single argument functions that are
> small, single forms, but I've started switching to (fn [..] ..) for
> anything even slightly more complex because, like you, I find having a
> named argument to be worth the extra typing, even if it is just a
> single letter, suggestive of the argument type.
>
> Today I found myself writing (fnil #(conj % id) []) a couple of times
> because (fnil (fn [v] (conj v id)) []) doesn't seem any clearer - but
> suggestions for nicer code are always welcome. It's part of (swap!
> some-atom update-in [:path :to :item] ...) if that helps :)
>
> Sean
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: function creation, partial or #()

[Jay Fields]

Thanks everyone. Seems like there's pretty solid agreement on which
solution is preferred.

Cheers, Jay

On Saturday, August 17, 2013, David Chelimsky wrote:

> On Fri, Aug 16, 2013 at 9:49 PM, Gregg Reynolds 
> 
> > wrote:
>
>> On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume 
>> > 'duelin.mark...@gmail.com');>>
>> wrote:
>> > Though in some cases the performance impact could be significant, my
>> concern
>> > is readability. My understanding of the concept of partial function
>> > application is that it's about supplying some but not all of the
>> arguments.
>> > So when I see `partial` in code, I expect more arguments to be supplied
>> > later, which is confusing when that's not the case. (Obviously context
>> can
>> > make it easy to see that there will be no more arguments, but often that
>> > context is not present.)
>> >
>>
>> +1.  Using partial to convert a unary func into a nullary func when
>> #() is available strikes me as malpractice.  Suppose you were to come
>> across something like this in legacy code:
>>
>> >> (do-work (partial say-hello "bob"))
>>
>> For me, the natural inference would be that say-hello must want at
>> least one more arg (otherwise why partial?), so do-work must be
>> feeding some arg to the result of (partial say-hello "bob"), like
>> adding "Don't worry, we're not watching you", in case the NSA owns
>> do-work.  Execution efficiency aside, downstream programmer confusion
>> due to implied semantics also has a cost.
>>
>> -Gregg
>>
>
> I agree w/ John and Gregg, though I don't think I'd sue you for
> malpractice ;) partial means something and using it this way gives it a
> different meaning, even if it happens to solve the problem at hand.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 
> clojure@googlegroups.com 'clojure@googlegroups.com');>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: vec to map with consolidated vals

[Jay Fields]

Of your proposed solutions, this one

 (defn to-consolidated-map [parts]
(->> parts (map (partial apply hash-map)) (apply merge-with +))

Is the one I thought of first and also find very readable.

On Saturday, August 17, 2013, David Chelimsky wrote:

> Sorry - pressed send before refreshing and didn't see your response.
>
> Readability is a very subjective topic. I have an (possibly irrational)
> aversion to anonymous fns when core fns solve the same problem, so I'm very
> accustomed to reading things like (partial apply xxx). The perf issue would
> definitely push me over, however.
>
>
>
>
> On Sat, Aug 17, 2013 at 11:19 AM, David Chelimsky wrote:
>
> Hey Steven, here's a variation of my first example that, I think, gets
> closer to what you're proposing (with maybe-add handled in-line):
>
> (defn to-consolidated-map [parts]
>   (reduce (fn [h [k v]]
> (assoc h k (+ (get h k 0) v)))
>   {}
>   parts))
>
> Using assoc instead of update-in allows it to handle nils with a default
> value to get. All core lib fns. WDYT?
>
> Also, this:
>
>   (defn to-consolidated-map [parts]
> (apply merge-with + (map (partial apply hash-map) parts)))
>
> or this variant:
>
>   (defn to-consolidated-map [parts]
> (->> parts (map (partial apply hash-map)) (apply merge-with +))
>
> each use only core lib fns, which you say you're looking for. I find this
> less accidental-complexity-ish than the implementations that use reduce
> with a custom (anonymous) fn, which each require handling nil in some
> fashion. WDYT?
>
>
>
>
> On Sat, Aug 17, 2013 at 10:42 AM, Steven Degutis wrote:
>
> Wow. Sorry for the awful formatting. Re-pasting it from Google Groups
> (instead of email) to fix it:
>
> (def a [[:a 1] [:b 2] [:a 3]])
>
>
>
> (defn add-maybe [& nums]
>
>   (->> nums
>
>(remove nil?)
>
>(reduce +)))
>
>
>
> (reduce (fn [m [k
>
>

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

function creation, partial or #()

[Jay Fields]

Say you have a simple function: (defn do-work [f] (f))

When you want to call do-work you need a function, let's pretend we
want to use this function: (defn say-hello [n] (println "hello" n))

Which of the following solutions do you prefer?

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

I'd been using partial (which I font-lock**), but a teammate recently
pointed out that partial's documentation explicitly calls out the fact
that the number of args to partial should be less than the number of
args to f. In practice it's been working 'fine', but I can't help but
wonder if I'm sacrificing something I'm not aware of (performance?)

** with a font-lock, using partial *displays* the same number of chars
as the reader macro solution, and I find it more readable when
everything is in the parenthesis. -
http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html

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

Re: Do you like the Clojure syntax?

[Jay Fields]

I'll repeat something I've said publicly several times (sorry if
you've previously heard it) -

My first exposure to Clojure was a Stu Halloway blog post:
http://thinkrelevance.com/blog/tags/java-next. At the time I was
writing mostly Ruby & some Java. I remember finding Clojure syntax
repulsive. Despite my gut reaction, I gave Clojure a shot for various
(not relevant to this conversation) reasons.

Fast forward to today, I find non-homoiconic languages to be
repulsive. The same feeling applies to inconsistencies - e.g. import
syntax != assignment syntax != control flow syntax ... you get the
idea.

I think it's common, and okay, for programmers to see Clojure (lisp?)
syntax and feel uncomfortable. If they can't get past that and give it
a try, that's okay as well - languages fit people in different ways,
there's no 'best' language for the masses.

This quote feels relevant: Programmers know the benefits of everything
and the tradeoffs of nothing -- Rich Hickey. Lisp syntax is one of the
oldest in our industry. Rich's selection wasn't arbitrary. If you want
to challenge it, you're going to want to know the tradeoffs very, very
well.

On Mon, Aug 12, 2013 at 7:43 AM, Softaddicts
 wrote:
> isolating the syntax from the other features of the language is a like 
> removing
> a part from a rocket engine however small it may be and wondering if it will 
> lift off
> without it.
>
> Macros are the first thing you may think of related to syntax change I am 
> convinced that other areas benefit from the syntax.
> It's early here and without caffein I will not even attempt to make a list..
>
> Who would choose a tool based on its syntax alone ?
> A tool = feature set = more or less productivity.
>
> We're not in a grocery store choosing between a banana and a cauliflower 
> based on their respective color to accompany a steak.  Banana + steak ?
> Wow... maybe some chef tried it or will but personally I pass,
> as good looking as the banana might be :) It's like emacs to me (joking here 
> guys :)
>
> Your poll has only two questions, I would have added at least a third one, 
> how many programming languages have you been using at work ?
> Maybe a fourth one, for how many years have you been programming ?
>
> How much weight does the first answer have if you do not assess the comparison
> basis of people answering the first question ? I would probably drop the 
> second one.
>
> A pool looks like a simple tool but it's hard work to put together questions
> to get meaningful data.
>
> Luc P.
>
>> Hi,
>> > I'm curious about the general opinion on the Clojure syntax, whether 
>> > people > actually like it or just use it because it provides macros. So I 
>> > would like > to ask you to participate in a poll. Thank You.
>> > Here's the link:
> https://docs.google.com/forms/d/1GSgfkeThpUYlgFVzhhNIgA1JbTilu6S9eudq_Sbxl34/viewform
>> > Răzvan
>> > -- > -- > You received this message because you are subscribed to the 
>> > Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- > You received this message because you are subscribed to the Google 
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>> > > --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: Wrong documentation of contains?

[Jay Fields]

I ran into a similar (in my opinion) issue the other day.

I was working a vector and updating a value at a specific index. Ordering
and performance were important, so it seemed like a good default choice.

(-> [1 2 3] (update-in [1] inc))

Then the code changed a bit, I needed to filter some elements out. I ended
up with code similar to what's below

(-> (filter odd? [1 2 3])
(update-in [1] inc))

The above code fails, since my vector becomes a lazyseq.

I solved the issue in a different way, but I was a bit disappointed that
using filter caused me to have to move away from updating at an index.



On Wed, Aug 7, 2013 at 9:45 AM, Jay Fields  wrote:

> that's kind of my point, you wouldn't use contains? with a list 99.99% of
> the time (you probably want some), so if the perf is terrible while you're
> figuring out that you want some, it doesn't matter.
>
>
> On Wed, Aug 7, 2013 at 9:39 AM, Jeremy Heiler wrote:
>
>> On August 7, 2013 at 9:02:51 AM, Tassilo Horn (t...@gnu.org) wrote:
>>
>> Jay Fields  writes:
>>
>> > For a list, it seems like converting the list to a vectoc (via vec)
>> > would be a reasonable solution, though I'm sure there's some side
>> > effect that I haven't considered. Perf would be impacted, but this
>> > doesn't seem like the kind of thing you'd want to do anyway, so having
>> > poor perf wouldn't be the end of the world. At least it wouldn't
>> > exception out.
>>
>> IMHO, it would be bad if converting lists (and seqs?) to vectors would
>> be done under the hoods. There are high chances that you accidentally
>> pass a seq/list to `contains?` and then suffer from worse performance
>> without actually noticing. E.g. you do something like
>>
>> (contains? (map fuddle blabla) 3) ;; has at least 4 items
>>
>> where you actually wanted to do
>>
>> (contains? (mapv fuddle blabla) 3) ;; has at least 4 items
>>
>> I'm not sure any conversion should take place. The confusion with vectors
>> is that (contains? [1 2 3 4] 3) returns true because there are four
>> elements, not because 3 is present. So by returning false, false
>> assumptions are being validated in various cases.
>>
>>
>>
>

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

Re: Wrong documentation of contains?

[Jay Fields]

contains? is possibly poorly named, contains-key? would probably have
avoided this entire issue. That said, I'd like to see contains? return
false for things where it doesn't make sense, longs, keywords, etc. For a
list, it seems like converting the list to a vectoc (via vec) would be a
reasonable solution, though I'm sure there's some side effect that I
haven't considered. Perf would be impacted, but this doesn't seem like the
kind of thing you'd want to do anyway, so having poor perf wouldn't be the
end of the world. At least it wouldn't exception out.


On Wed, Aug 7, 2013 at 8:14 AM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> That's only obvious if you already know how it works.
>
> Jonathan
>
>
> On Wed, Aug 7, 2013 at 2:13 PM, Karsten Schmidt wrote:
>
>> The fact, that the docs refer to checking if a "key" is present in the
>> collection, should make it obvious which types are supported, no? Only
>> vectors, maps and sets have keys. Lists and seqs do not. Of course it never
>> hurts to be more explicit about it...
>>  On 7 Aug 2013 12:49, "Marcus Lindner" <
>> marcus.goldritter.lind...@gmail.com> wrote:
>>
>>> Thanks.
>>>
>>> But the problem is, that this is not mentioned in the documentation of
>>> contains? I found so far :(.
>>> I had such a problem a long time ago and remember now which type of
>>> "collection" can be used with contains?. But after a time I will forget
>>> this again and will refer to the documentation. (And when I get the
>>> Exception I remember again.)
>>>
>>> And I think this question arise also more frequently.
>>>
>>> But then my assumption that the documentation of contains? is misleading
>>> is true. Is it possible to update the documentation for the next version?
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2013/8/7 Baishampayan Ghose 
>>>
 Hi,

 `contains?` only works with associative data-structures like maps &
 vectors. If you want to find out if a sequence contains a specific
 object then you need to use `some` paired with a set as a predicate.

 For example:

 (some #{3} '(1 2 3 4))

 Hope this helps.

 ~BG


 On Wed, Aug 7, 2013 at 4:54 PM, Goldritter
  wrote:
 > In an program I used the result of keys as an argument for a function
 which
 > verifies whether an object is in a passed collection or not.
 > The result I got was following Exception:
 > IllegalArgumentException contains? not supported on type:
 > clojure.lang.APersistentMap$KeySeq  clojure.lang.RT.contains
 (RT.java:724)
 >
 > What are the reasons behind this Exception?
 >
 > In the documentation of contains? it is written, that
 > "Returns true if key is present in the given collection, otherwise
 returns
 > false."
 > The examples on this page
 > (http://clojuredocs.org/clojure_core/clojure.core/contains_q) and the
 > parameter description indicates, that contains? accept any collection
 as
 > argument.
 >
 > The result of keys is also a collection
 > => (coll? (keys {:a "f" :b 23}))
 > true
 >
 > So is this a bug or is there a reason behind the fact, that contains?
 does
 > not accept any collection?
 > Or is the documentation wrong and it should nor be a collection as
 argument
 > but a set or a vector?
 >
 > Because I get the same Exception for a list, but not for a vector.
 > The same for lists, which returns also true for coll?.
 > => (coll? '(1 2 3 4))
 > true
 >
 > => (contains? '(1 2 3 4) 3)
 > IllegalArgumentException contains? not supported on type:
 > clojure.lang.PersistentList  clojure.lang.RT.contains (RT.java:724)
 >
 > => (contains? [1 2 3 4] 3)
 > true
 >
 > --
 > --
 > You received this message because you are subscribed to the Google
 > Groups "Clojure" group.
 > To post to this group, send email to clojure@googlegroups.com
 > Note that posts from new members are moderated - please be patient
 with your
 > first post.
 > To unsubscribe from this group, send email to
 > clojure+unsubscr...@googlegroups.com
 > For more options, visit this group at
 > http://groups.google.com/group/clojure?hl=en
 > ---
 > You received this message because you are subscribed to the Google
 Groups
 > "Clojure" group.
 > To unsubscribe from this group and stop receiving emails from it,
 send an
 > email to clojure+unsubscr...@googlegroups.com.
 > For more options, visit https://groups.google.com/groups/opt_out.
 >
 >



 --
 Baishampayan Ghose
 b.ghose at gmail.com

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

should contains? throw an exception on sorted maps?

[Jay Fields]

This: (contains? (sorted-map 1 2 3 4) :a)
Results in this: ClassCastException java.lang.Long cannot be cast to
clojure.lang.Keyword  clojure.lang.Keyword.compareTo (Keyword.java:102)

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

Re: Does this abstraction have any existing name?

[Jay Fields]

I'm not sure I'd call this more readable, but it's another option - using
clojure.walk

(defn deep-update-vals
  [m f & args]
  (let [f (fn [[k v]] (if (map? v) [k v] [k (apply f v args)]))]
(clojure.walk/postwalk (fn [x] (if (map? x) (into {} (map f x)) x)) m)))


On Fri, Jul 26, 2013 at 2:06 PM, Jay Fields  wrote:

> I defined update-vals in jry:
> https://github.com/jaycfields/jry/blob/master/src/clojure/jry.clj#L74-L75
>
> It doesn't traverse nested maps, but I haven't ever needed that ability
> either.
>
> 1) I've never seen a name for that.
> 2) not in core. I'm sure it's been written 50 times in various helper libs.
> 3) I'd probably write it like below, but I'm not convinced it's any better.
>
> (defn deep-update-vals
>   [m f & args]
>   (if (map? m)
> (reduce-kv #(assoc %1 %2 (apply deep-update-vals %3 f args)) {} m)
> (apply f m args)))
>
>
> On Fri, Jul 26, 2013 at 1:31 PM, Yoshinori Kohyama wrote:
>
>> Thank you Gary.
>> There's no reason why this need to be a macro.
>> It has rewritten as a function.
>>
>> And I'd still like to hear any response about the same three questions.
>>
>>
>> (require '[clojure.test :refer (with-test is run-tests)])
>>
>>
>> (with-test
>>   (defn mapf [f m & args]
>>
>> ((fn g [n]
>>(if (map? n)
>>
>>(into {} (map (fn [[k v]] [k (g v)]) n))
>>
>>(apply f n args)))
>>
>>  m))
>>
>>   (is (= (mapf #(* % %) {:a {:b 3 :c 4} :d 5})
>>
>>  {:a {:b 9 :c 16} :d 25}))
>>
>>   (is (= (mapf #(+ (* %1 %1) %2) {:a {:b 3 :c 4} :d 5} 1)
>>
>>  {:a {:b 10 :c 17} :d 26})))
>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>

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

Re: Does this abstraction have any existing name?

[Jay Fields]

I defined update-vals in jry:
https://github.com/jaycfields/jry/blob/master/src/clojure/jry.clj#L74-L75

It doesn't traverse nested maps, but I haven't ever needed that ability
either.

1) I've never seen a name for that.
2) not in core. I'm sure it's been written 50 times in various helper libs.
3) I'd probably write it like below, but I'm not convinced it's any better.

(defn deep-update-vals
  [m f & args]
  (if (map? m)
(reduce-kv #(assoc %1 %2 (apply deep-update-vals %3 f args)) {} m)
(apply f m args)))


On Fri, Jul 26, 2013 at 1:31 PM, Yoshinori Kohyama wrote:

> Thank you Gary.
> There's no reason why this need to be a macro.
> It has rewritten as a function.
>
> And I'd still like to hear any response about the same three questions.
>
> (require '[clojure.test :refer (with-test is run-tests)])
>
> (with-test
>   (defn mapf [f m & args]
> ((fn g [n]
>(if (map? n)
>(into {} (map (fn [[k v]] [k (g v)]) n))
>(apply f n args)))
>
>  m))
>
>   (is (= (mapf #(* % %) {:a {:b 3 :c 4} :d 5})
>  {:a {:b 9 :c 16} :d 25}))
>   (is (= (mapf #(+ (* %1 %1) %2) {:a {:b 3 :c 4} :d 5} 1)
>  {:a {:b 10 :c 17} :d 26})))
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: map from list of maps

[Jay Fields]

I use this:
https://github.com/jaycfields/jry/blob/master/src/clojure/jry/set.clj#L3-L4


On Thu, Jul 25, 2013 at 5:55 PM, Brian Craft  wrote:

> Ah, interesting. Only works for keys that are functions.
>
>
> On Thursday, July 25, 2013 2:48:10 PM UTC-7, Gary Trakhman wrote:
>
>> user> (into {}  (map (juxt :a :b) [{:a "blah" :b "ack"} {:a "red" :b
>> "blue"}]))
>> {"blah" "ack", "red" "blue"}
>>
>>
>>
>> On Thu, Jul 25, 2013 at 5:34 PM, Brian Craft  wrote:
>>
>>> Is there a better way to do this, making a map of certain keys from a
>>> list of maps?
>>>
>>> > (apply hash-map (mapcat (fn [x] [(x :a) (x :b)]) [{:a "blah" :b "ack"}
>>> {:a "red" :b "blue"}]))
>>> {"red" "blue", "blah" "ack"}
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: [ANN] verily, non-magic testing lib

[Jay Fields]

I've never spoken to Steven in anything that wasn't a public email to this
list, so it wasn't me. I'm not sure who the self-proclaimed project
guardians are, but I just wanted to make sure no one thought I was trying
to "protect" https://github.com/jaycfields/expectations in anyway.

I don't actually think there's much value in unifying the infrastructure,
but I agree with Meikel that no one has the right to tell you what you can
and cannot work on. My *opinion* is that it's a waste of your (Steven's)
time, but it costs me nothing for you (Steven) to try. If I'm wrong then we
all benefit, which is obviously a good thing. I mean, we're all here
because Rich wanted something better, right?

That said, if all you want is the ability to run the different styles of
tests side by side, start sending pull requests to align the internals of
the 3. I can't imagine any of Brian, Micah, and I would have a problem with
you tweaking internals that might allow more people to use our software.


On Wed, Jul 24, 2013 at 7:31 AM, Meikel Brandmeyer (kotarak) 
wrote:

>
> Am Mittwoch, 24. Juli 2013 08:14:15 UTC+2 schrieb Steven Degutis:
>>
>> It's been brought to my attention that this project is an utter waste of
>> time, brings no real improvement over the existing solutions, and was
>> wrought in complete arrogance. So I've deleted the project. Sorry for
>> wasting a thread on this.
>>
>>
> Wat? Don't let yourself be pushed by self-proclaimed project guardians. If
> you saw any use of your library, then by-all-means you should continue it!
> Even if there are other libraries already, you'll maybe come up with the
> cool new feature. Who knows. The worst that can happen is that you learned
> yourself a lot about doing things. And that is always a win.
>
> From your message I get the impression that the act of "bringing things to
> your attention" was done in a rather non-diplomatic way. Feel free to make
> things public in such a case (maybe the case itself, not the names of the
> people involved). I don't think that this an appropriate behaviour for a
> community like clojure's. Especially since it is not done in public. It is
> absolutely arrogant to judge other people's projects in such a way. The
> other person has no right whatsoever to tell you which projects you should
> pursue and which not.
>
> Meikel
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Proposed change to let-> syntax

[Jay Fields]

I'm already using as-> in prod. I think the ship has sailed on convincing
Rich not to include them.


On Fri, Jul 19, 2013 at 5:39 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> I use some-> and cond-> pretty heavily... I know I'm just one dude, but I
> am grateful they're in core so I don't have to cajole all my teammates into
> accepting them in the code base :)
>
>
> On Fri, Jul 19, 2013 at 1:38 AM, Michał Marczyk 
> wrote:
>
>> On 19 July 2013 10:24, Daniel Dinnyes  wrote:
>> > Why don't we have a "candidate" name-space, a separate library, like the
>> > contrib before, which most people who prefer to be on the cutting edge
>> just
>> > include automatically. That would give reasonable feedback on how much
>> > traction new stuff like these get, and keeps it physically obvious what
>> is
>> > considered The Core.
>>
>> https://github.com/clojure/core.incubator
>>
>> Cheers,
>> Michał
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Domain-specific language design books

[Jay Fields]

this is a great book:
http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943

don't let the language selection deter you. the patterns are abstract and
can easily be applied to Clojure.


On Thu, Jul 18, 2013 at 4:30 PM, JvJ  wrote:

> Does anyone know of any good books on DSL design, in Clojure or any other
> Lisp?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Comma separated String values from vector

[Jay Fields]

this seems to do what you want: (clojure.string/join ", " (map pr-str
my-strings))


On Tue, Jul 16, 2013 at 10:17 AM, Cedric Greevey  wrote:

> (apply str "\"" (interpose "\", \"" my-strings) "\"") might work...
>
>
> On Tue, Jul 16, 2013 at 9:53 AM,  wrote:
>
>> Hi All,
>>
>> I'm new to Clojure -
>>
>> I'm defining a vector containing string values. The requirement for me is
>> to retrieve the String values separated by comma from the input vector.
>>
>> Example:
>>
>> => (def my-strings ["one" "two" "three"])
>>
>> ;; My expected output should be ;; *"one", "two", "three"*
>>
>> I tried interpose and join as below
>>
>> => (apply str (interpose "," my-strings))
>>
>> => (clojure.string/join "," my-strings)
>>
>> both returning as "one,two,three" but I need each string surrounded by
>> double quotes "" like in my example example.
>>
>> /Sunil.
>>
>>
>>
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Multiple REPLs in Emacs? (was: test run startup time

[Jay Fields]

On Thu, Jul 11, 2013 at 5:53 PM, Sean Corfield wrote:

> On Wed, Jul 10, 2013 at 10:53 AM, Jay Fields  wrote:
> > I work in emacs with 2 repls running - 1 for running my app and 1 for
> > running my tests.
>
> What is the magic to get this working and how does Emacs / nrepl.el
> know which REPL to send commands to?
>
>
I don't remember how I ended up with my current config, but I'm pretty sure
I started here:
https://github.com/kingtim/nrepl.el#managing-multiple-sessions

After that, it was as easy as configuring my emacs to push compiles to both
repls, and defaulting to 1 repl for running the app.

https://github.com/jaycfields/unplugged-pack/blob/master/init.el#L15-L16 &
https://github.com/jaycfields/unplugged-pack/blob/master/init.el#L29-L43

If you want multi repls for different projects, you'll probably want
slightly different behavior.

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

Re: test run startup time

[Jay Fields]

There are significantly more productive ways to work, but they'll require
you to know your environment well.

I work in emacs with 2 repls running - 1 for running my app and 1 for
running my tests. I use emacs-live[1], the unplugged-pack[2], &
expectations[3] for my tests. In emacs 'switch projects' via a command
defined in unplugged-pack, then I M-x expectations-repl to have a
expectations dedicated repl.

The result:
C-c C-k loads any changes I make in a buffer into the running environments.
I can navigate to any expectations test ns and run all of the tests with
C-c C-, - there's no start and stop other than at the beginning. Any
changes I make and C-c C-k will be immediately reflected in both my running
application and in the tests. I don't find myself ever waiting for
feedback, in fact, I strongly believe my current workflow is faster than
any TDD workflow I've used in the past.

The learning curve is steep, but the payout is large.

[1] http://overtone.github.io/emacs-live/
[2] https://github.com/jaycfields/unplugged-pack
[3] http://jayfields.com/expectations/


On Wed, Jul 10, 2013 at 1:36 PM, Brian Craft  wrote:

> The clojure start-up time is killing me, while working in a tight
> edit-test-edit development loop. Is there any way to speed this up? E.g.
> could the edited code be dynamically loaded, and the test suites run w/o
> restarting the jvm? I have previously experimented with nailgun for
> starting the repl, without much success. I suspect it's the clojure
> start-up time, not the jvm, that's taking so long, but I know next to
> nothing about the jvm and clojure start-up procedures.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: (newbie) replace certain values of a map based on a predicate

[Jay Fields]

I use update-vals from https://github.com/jaycfields/jry fairly often. As
long as you don't mind doing the pred check in the fn you pass to
update-vals, it should do the trick.

Cheers, Jay


On Fri, Jul 5, 2013 at 5:14 PM, Jim - FooBar(); wrote:

> You'll never really 'replace' any values so why not reduce/reduce-kv ?
> Just build a new map out of the old one...
>
> Jim
>
>
> On 05/07/13 21:59, Colin Yates wrote:
>
>> Hi all,
>>
>> I think this is one of those questions which has quite a few answers, but
>> given a map, how do I replace the values by applying a function to those
>> values, but only if they meet a condition?
>>
>> I understand the building blocks of (map..), (filter..), (assoc-in..) and
>> (filter..) and I can see how something could work using those pieces but is
>> would be pretty verbose.  I am sure there is probably a much more simple
>> way using a more abstract function.
>>
>> The actual use case is I have a list of maps as returned from the
>> clojure.java.jdbc framework and they contain timestamps.  I want to replace
>> all the timestamps with (for example) to a Joda LocalDate using the
>> excellent clj-time library.
>>
>> Any pointers?
>>
>> Thanks!
>>
>> Col
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> clojure+unsubscribe@**googlegroups.com
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

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

Re: Clojure in production

[Jay Fields]

On Monday, June 10, 2013 5:47:25 PM UTC-4, Plinio Balduino wrote:

> Hi there 
>
> I'm writing a talk about Clojure in the real world and I would like to 
> know, if possible, which companies are using Clojure for production or 
> to make internal tools. 
>

I've previously written about adopting Clojure at DRW (drw.com): 
http://blog.jayfields.com/2012/01/lessons-learned-while-introducing-new.html
 

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

Re: expectations documentation

[Jay Fields]

On Tuesday, June 11, 2013 2:39:33 PM UTC-4, Jay Fields wrote:

> expectations* has always had a decent amount of documentation; however, 
> it's traditionally been in the form of blog entries. 
>
> I spent a bit of time and converted those entries into the following site: 
> http://jayfields.com/expectations/index.html
>

More documentation added for (a) reducing failure noise and (b) tweaking 
emacs to indent correctly and take up less horizontal space

http://jayfields.com/expectations/env-tweaks.html
http://jayfields.com/expectations/emacs-tweaks.html 

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

Re: expectations documentation

[Jay Fields]

Thanks for the report Phillip, I've pushed an update that I hope addresses 
your issue. Let me know if things aren't fixed.

Cheers, Jay

On Tuesday, June 11, 2013 4:51:08 PM UTC-4, Phillip Lord wrote:
>
> I can't get the nav bar on the left to scroll -- so I can't get to all the 
> documentation. The bottom two 
> also overlap the "isn't github fun" links. 
>
> Haven't seen expectations before. Looks really nice. 
>
> Phil 
>  
> From: clo...@googlegroups.com  
> [clo...@googlegroups.com] 
> on behalf of Jay Fields [j...@jayfields.com ] 
> Sent: 11 June 2013 19:39 
> To: clo...@googlegroups.com  
> Subject: expectations documentation 
>
> expectations* has always had a decent amount of documentation; however, 
> it's traditionally been in the form of blog entries. 
>
> I spent a bit of time and converted those entries into the following site: 
> http://jayfields.com/expectations/index.html 
>
> If you've never looked at expectations and you'd like an alternative to 
> clojure.test, you might want to look at the 10 second example. If the 10 
> second example looks interesting, take 2 minutes to read the introduction - 
> that should give you an idea of whether or not you should invest more in 
> expectations. 
>
> Cheers, Jay 
>
> -- 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> To post to this group, send email to clo...@googlegroups.com  
> Note that posts from new members are moderated - please be patient with 
> your first post. 
> To unsubscribe from this group, send email to 
> clojure+u...@googlegroups.com  
> For more options, visit this group at 
> http://groups.google.com/group/clojure?hl=en 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com . 
> For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>

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

Re: expectations documentation

[Jay Fields]

No worries. It's been on my todo list for awhile, and confusion about features 
motivated the actual effort. 

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

expectations documentation

[Jay Fields]

expectations* has always had a decent amount of documentation; however,
it's traditionally been in the form of blog entries.

I spent a bit of time and converted those entries into the following site:
http://jayfields.com/expectations/index.html

If you've never looked at expectations and you'd like an alternative to
clojure.test, you might want to look at the 10 second example. If the 10
second example looks interesting, take 2 minutes to read the introduction -
that should give you an idea of whether or not you should invest more in
expectations.

Cheers, Jay

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Tuesday, June 11, 2013 11:11:23 AM UTC-4, Steven Degutis wrote:

> Jay,
>
> [elided] 
>
That's the issue I'm trying to solve. Maybe that's not what everyone sees 
> in this. But this is the big win I see in it.
>

I think that's a good goal, I think you should stick to that, instead of 
continuing to make incorrect statements about the existing libraries. 

So far you've called my framework 'inflexible' and claimed that 'around' 
isn't possible. Both statements are (a) incorrect and (b) not relevant. I 
have an issue with that, and will continue to keep responding as long as 
you keep making inaccurate statements. 

Cheers, Jay

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Tuesday, June 11, 2013 12:39:59 AM UTC-4, Steven Degutis wrote:

> It's pretty frustrating that I, a regular old Clojure user who likes 
> writing tests, can't mix and match tools from existing testing libraries. 
> Seriously, there's 4 major ones (clojure.test, speclj, midje, expectations) 
> and they each do mostly the same things but vary slightly in some areas. I 
> can't use speclj's around-all feature with expectations' (expect) function.
>

Unless I'm missing something, I don't see how expectations doesn't support 
around.

here's the speclj from the wiki: https://gist.github.com/jaycfields/5757320
here's the expectations equivalent: 
https://gist.github.com/jaycfields/5757387 

Maybe the issue is more around knowing the frameworks than lack of features 
- which could speak to a need for better documentation.

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

Re: Best IDE

[Jay Fields]

2013/6/8 Jay Fields >

> My favorite recent addition - I can run my app from within emacs, allowing 
>> me to change my app with a simple C-x C-e and see my changes immediately in 
>> the running app (no restart, refresh or reload necessary). 
>
>
> Would you mind to extend on that ?
>
> How is this done, exactly ?
>

Sure. I assume you have some top level function that you call to 'start' 
your application. If you ever use 'lein run', then I'm probably talking 
about the -main function in whatever namespace you specify as your main 
namespace 
(e.g. 
https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L130)

Let's pretend your main namespace is my-main.

First I start a new nrepl. M-x nrepl-jack-in
Then I open my-main in a new buffer. C-x C-f my_main.clj
(If there isn't one already) I put a comment at the bottom of the 
namespace. c-tab
In the comment, I put (-main) and, after the parenthesis, I C-x C-e to 
evaluate the previous form.

At that point my app is running from within Emacs. Now I can go to any form 
in the codebase and C-x C-e, which will evaluate the form in my running 
nrepl, which is also running my app. Let's say I have some function that's 
being called every minute and printing the time via println. I can go to 
that function and change the format of the output, C-x C-e the entire 
function, and the next println will be in my new format. There are a few 
gotchas (it's problematic to redef a defmulti, once you've passed a f in as 
a parameter you can't redef it), but for the 95% case I don't need to do 
anything special - it just works.

Cheers, Jay

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Sunday, June 9, 2013 8:50:46 PM UTC-4, Steven Degutis wrote:

> But that's what I meant, that he's proposing we start with his lib and add 
> extensibility in the places we want it. So my response to that still 
> applies.


That's not at all what I said, proposed, alluded to, or anything of the 
sort.  

I'll use quotes, perhaps that will make things easier - though I'm 
skeptical at this point.

You said: "..were frustrated with the inflexibility of existing libs.."

I pointed out: "..expectations* has 0 open pull requests, 0 open issues, 
and is very actively maintained.."

Further, I wanted to make sure it was clear that "..anyone who chooses to 
use expectations should feel free to contact me with any suggestions.."

That's the only thing I said. I have no desire to integrate with test2.

I'll leave it at that.

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

Re: Refactoring tools

[Jay Fields]

I've written the 2nd one in emacs lisp, the first one would be even easier. 
If you're using emacs, you should give it a shot, it was a great learning 
experience for me.

On Friday, March 22, 2013 10:54:36 PM UTC-4, Russell Mull wrote:
>
> I find myself doing that a lot by hand, a tool to help would be very 
> useful. Some others that I've thought of are:
>
> - change between (fn [x] ...) and #(...)
> - pull sexp up to let, or introduce a new let (like introduce variable in 
> java et. al)
>
>
> On Saturday, March 23, 2013 10:42:10 AM UTC+9, Alex Baranosky wrote:
>>
>> I'd really like to see a way to factor to code that uses ->/->> and back 
>> again.
>>
>> On Fri, Mar 22, 2013 at 12:01 PM, Laurent PETIT wrote:
>>
>>> 2013/3/22 Daniel Glauser 
>>>
 I feel your pain, would love to see some Clojure refactorings. I had 
 started working on the 1.3 branch of clojure-refactoring trying to bring 
 it 
 up to speed. I met with Tony (the original author of clojure-refactoring) 
 and Phil H. at Clojure/West. Tony was very adamant that we ditch his code 
 and start over. Currently I'm doing some experimenting with sjacket (
 https://github.com/cgrand/sjacket) trying to see if we could make that 
 work for renaming. Once I'm confident that direction will work I'm happy 
 to 
 throw some code up on Github. If someone beats me to it then I'd like to 
 contribute to their project.

 I just created a #clojure-refactoring channel up on Freenode to make it 
 easier to collaborate. We can rename the node once a name emerges for a 
 new 
 project.

>>>
>>> Please note that I've also created a project entry for the Google Summer 
>>> Of Code for this : creating refactoring library + integration of it into 
>>> Counterclockwise : 
>>> http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs
>>>
>>> I think writing a refactoring library with more than one client in mind 
>>> (e.g. a "command line" client as well as an "IDE" client) is interesting 
>>> because it will help shape its API (for instance, an "IDE" client will 
>>> usually want to offer a view of the modifications to be applied, thus 
>>> refactoring can have a review step).
>>>
>>> Cheers,
>>>
>>> -- 
>>> Laurent
>>>  
>>>

 On Thursday, March 21, 2013 12:12:42 AM UTC-6, Akhil Wali wrote:

> A fairly new project for refactoring Clojure is clj-refactor.el.
> Not too much functionality yet, but supplements clojure-refactoring 
> pretty well. 
> clj-refactor.el will later interop with nRepl, or that's the plan I 
> heard.
>
> That aside (and I know I'm being redundant), refactoring any Lisp is a 
> snap with paredit-mode.
> It doesn't do stuff like renaming a function or exracting a var, but 
> I've had some success in making these operations as interactive 
> functions. 
>
>
>
> On Thu, Mar 21, 2013 at 8:11 AM, Devin Walters wrote:
>
>> Yeah it sort of bums me out that clojure-refactoring has been in the 
>> ditch.
>>
>> There are a number of tasks to get this back into a good state. The 
>> plan right now is to take tests (which were mostly failing and using 
>> outdated dependencies) from the old-test directory and get them passing 
>> under Midje. Then, get it to play nicely with nrepl and update any elisp 
>> that needs updating to bring back the clojure-refactoring minor mode.
>>
>> If anyone wants to help resurrect this project: https://github.com/**
>> devn/clojure-refactoring/tree/**clojure-1.5
>>  your 
>> help would be appreciated. I created a new branch and started 
>> bringing old failing tests over. Feel free to drop me a pull request. 
>> Big, 
>> sweeping commits and tiny typo commits are both equally welcome.
>>  
>> On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote:
>>
>> Thanks. It looks like nothing has happened on that in a year and it 
>> appears to require slime/swank. But it's a start I guess if there isn't 
>> anything else.
>>
>> On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) 
>> wrote:
>>
>>  I don't think much has happened with it recently, but I used to use 
>> https://github.com/joodie/clojure-refactoring
>> .
>>
>> -- 
>> '(Devin Walters)
>> Sent from my Motorola RAZR V3 (Matte Black)
>>
>> On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:
>>
>> I'm wondering if there are any refactoring tools around for working 
>> with Clojure projects in Emacs. There seems to be all kinds of other 
>> tools 
>> except for refactoring. I'm really looking for simple things like ways 
>> to 
>> easily rename variables, functions, namespaces, etc. That 

Re: Refactoring tools

[Jay Fields]

nrepl has macroexpansion, so you can already have 1/2 of what you want - 
better than nothing.

On Friday, March 22, 2013 9:42:10 PM UTC-4, Alex Baranosky wrote:
>
> I'd really like to see a way to factor to code that uses ->/->> and back 
> again.
>
> On Fri, Mar 22, 2013 at 12:01 PM, Laurent PETIT 
> 
> > wrote:
>
>> 2013/3/22 Daniel Glauser >
>>
>>> I feel your pain, would love to see some Clojure refactorings. I had 
>>> started working on the 1.3 branch of clojure-refactoring trying to bring it 
>>> up to speed. I met with Tony (the original author of clojure-refactoring) 
>>> and Phil H. at Clojure/West. Tony was very adamant that we ditch his code 
>>> and start over. Currently I'm doing some experimenting with sjacket (
>>> https://github.com/cgrand/sjacket) trying to see if we could make that 
>>> work for renaming. Once I'm confident that direction will work I'm happy to 
>>> throw some code up on Github. If someone beats me to it then I'd like to 
>>> contribute to their project.
>>>
>>> I just created a #clojure-refactoring channel up on Freenode to make it 
>>> easier to collaborate. We can rename the node once a name emerges for a new 
>>> project.
>>>
>>
>> Please note that I've also created a project entry for the Google Summer 
>> Of Code for this : creating refactoring library + integration of it into 
>> Counterclockwise : 
>> http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs
>>
>> I think writing a refactoring library with more than one client in mind 
>> (e.g. a "command line" client as well as an "IDE" client) is interesting 
>> because it will help shape its API (for instance, an "IDE" client will 
>> usually want to offer a view of the modifications to be applied, thus 
>> refactoring can have a review step).
>>
>> Cheers,
>>
>> -- 
>> Laurent
>>  
>>
>>>
>>> On Thursday, March 21, 2013 12:12:42 AM UTC-6, Akhil Wali wrote:
>>>
 A fairly new project for refactoring Clojure is clj-refactor.el.
 Not too much functionality yet, but supplements clojure-refactoring 
 pretty well. 
 clj-refactor.el will later interop with nRepl, or that's the plan I 
 heard.

 That aside (and I know I'm being redundant), refactoring any Lisp is a 
 snap with paredit-mode.
 It doesn't do stuff like renaming a function or exracting a var, but 
 I've had some success in making these operations as interactive functions. 



 On Thu, Mar 21, 2013 at 8:11 AM, Devin Walters wrote:

> Yeah it sort of bums me out that clojure-refactoring has been in the 
> ditch.
>
> There are a number of tasks to get this back into a good state. The 
> plan right now is to take tests (which were mostly failing and using 
> outdated dependencies) from the old-test directory and get them passing 
> under Midje. Then, get it to play nicely with nrepl and update any elisp 
> that needs updating to bring back the clojure-refactoring minor mode.
>
> If anyone wants to help resurrect this project: https://github.com/**
> devn/clojure-refactoring/tree/**clojure-1.5
>  your 
> help would be appreciated. I created a new branch and started 
> bringing old failing tests over. Feel free to drop me a pull request. 
> Big, 
> sweeping commits and tiny typo commits are both equally welcome.
>  
> On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote:
>
> Thanks. It looks like nothing has happened on that in a year and it 
> appears to require slime/swank. But it's a start I guess if there isn't 
> anything else.
>
> On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) 
> wrote:
>
>  I don't think much has happened with it recently, but I used to use 
> https://github.com/joodie/clojure-refactoring
> .
>
> -- 
> '(Devin Walters)
> Sent from my Motorola RAZR V3 (Matte Black)
>
> On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote:
>
> I'm wondering if there are any refactoring tools around for working 
> with Clojure projects in Emacs. There seems to be all kinds of other 
> tools 
> except for refactoring. I'm really looking for simple things like ways to 
> easily rename variables, functions, namespaces, etc. That seems to be the 
> most common thing I'm trying to do. Are there any tools out there to make 
> it easier?
>
> Thanks,
>
> Dave
>
> -- 
> -- 
> 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...@**googlegro

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

I'd like to mention that expectations* has 0 open pull requests, 0 open 
issues, and is very actively maintained**. Steven, I don't want to 
discourage you from creating your own testing framework, I think everyone 
should, it's a very educational experience.

I just wanted to be clear that no one has ever asked me for any help 
extending expectations, and anyone who chooses to use expectations should 
feel free to contact me with any suggestions.

* https://github.com/jaycfields/expectations
** https://github.com/jaycfields/expectations/commits/master

On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
> Test2 is a new testing lib for Clojure, where the power is its simplicity, 
> extensibility, and a 
> SPEC much 
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with 
> the smart folks in #clojure, who were frustrated with the inflexibility of 
> existing libs, and intended this to be the spiritual successor to 
> clojure.test. We wanted something that was still simple like clojure.test, 
> but could be extended externally much more easily in case you wanted 
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever 
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written 
> one last night, 
> test2-autorunner, 
> which took about an hour. This should give some idea of how easy it is and 
> how well-designed the SPEC was by the smart folks of #clojure. There are 
> some ideas at the bottom of the wiki, but of course any extensions are 
> encouraged.
>
> -Steven
>

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

Re: Best IDE

[Jay Fields]

I was actually thinking pretty much the same thing. About a year ago I'd 
never used emacs and now I've contributed to emacs-live*, 
expectations-mode**, etc, etc. I also have my own emacs lisp open source*** 
that I use for all kinds of tweaking. My favorite recent addition - I can 
run my app from within emacs, allowing me to change my app with a simple 
C-x C-e and see my changes immediately in the running app (no restart, 
refresh or reload necessary). I also run a second repl (concurrently) that 
I use for running my tests, allowing me to look at the state (deref atoms, 
refs, whatever) from my running app, while running tests independently. 
It's often the case that I'll develop a feature, run my tests, find them 
failing, eval the running app state, find that the test date is no longer 
valid, paste in the state from the running app, rerun and verify that 
everything works as expected.

I've used IntelliJ plenty, and it's likely that I'll use it again in my 
career; however, I can now say that I'm also prepared to use emacs for any 
future language that I may end up adopting.

* https://github.com/overtone/emacs-live
** https://github.com/gar3thjon3s/expectations-mode
*** https://github.com/jaycfields/unplugged-pack/blob/master/init.el

On Friday, June 7, 2013 6:27:26 PM UTC-4, Denis Labaye wrote:
>
> *Learning Emacs is more important than learning Clojure.*
>
>   -- A Clojure fanboy and former Vim user
>
>
>
> On Fri, Jun 7, 2013 at 10:46 PM, futile  >wrote:
>
>> Before, I used vim for several years. But when I learned Clojure I 
>> switched to emacs, and it's really not hard or awkward like I was afraid 
>> of. Honestly now I like it much better than vim. And I've found paredit and 
>> nrepl.el to be extremely handy, even used together.
>>
>>
>> On Tuesday, January 17, 2012 3:38:05 PM UTC-6, Josef Frydl wrote:
>>>
>>> Can you please recommend the Best IDE for Clojure? I have Eclipse 
>>> NetBeans and JetBrain already installed. 
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

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

Re: feeding leiningen a local JAR file

[Jay Fields]

David Chelimsky recently 
released: https://github.com/dchelimsky/lein-expand-resource-paths

On Friday, June 7, 2013 10:37:46 PM UTC-4, David Williams wrote:
>
> Try here
>
>
> http://nakkaya.com/2010/03/16/adding-custom-libraries-into-local-leiningen-repository/
>
>
>
> On Wednesday, November 21, 2012 3:47:40 AM UTC-8, Dick Davies wrote:
>>
>> I've got a couple of projects that need a newer version of a JAR 
>> than is available in Maven. 
>>
>> Is there any support/syntax in project.clj that will allow me to point 
>> at a local JAR file? 
>>
>> Also, is it possible to 'override' a given dependency to favour a local 
>> JAR 
>> over the 'official' maven one? 
>>
>> [ specifically, I'm trying to use clj-xmpp which uses the SMACK XMPP 
>> libraries under the hood, and the maven shipped version won't 
>> authenticate 
>> against our ejabberd ] 
>>
>

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

[job opening] DRW (http://drw.com) is looking for a Sr. Software Engineer - Clojure/JRuby

[Jay Fields]

DRW (http://drw.com) is looking for a Sr. Software Engineer - Clojure/JRuby

more info: 
http://drw.submit4jobs.com/index.cfm?fuseaction=83084.viewjobdetail&CID=83084&JID=149069

My experience working for DRW: 
http://blog.jayfields.com/2013/04/year-five.html

Drop me a line if you want more info.

Cheers, Jay

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

Re: Clojure Login form error: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.Atom

[Jay Fields]

On Thursday, May 2, 2013 10:19:51 AM UTC-4, David Toomey wrote:

>
> [snipped]


If you want help in the future, I'd recommend spending less time demanding 
answers and more time reading responses and code.

I've never looked at the 4clojure source, didn't even know it was on 
github. I've never used ring, compojure, or any other clojure web 
framework. The total time it took me to clone the 4clojure repo, grep for 
what John recommended, and get you this link (
https://github.com/4clojure/4clojure/blob/develop/src/foreclojure/core.clj#L58),
 
about 30 seconds.

Python has been around significantly longer, and has a much larger 
community. If you need that level of support, I don't think Clojure is the 
right language for you.

Cheers, Jay

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

Re: Sending Clojure Objects over TCP

[Jay Fields]

http://code.google.com/p/jetlang/wiki/Remoting

On Wed, Feb 6, 2013 at 8:16 PM, JvJ  wrote:
> Does anyone know if there's a simplified networking library that allows
> this?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

[Jay Fields]

If you knew neither, I'm convinced emacs would be the right answer. You'll
have more peers to using both that can help you work through problems. You
can edit the environment using a language that is similar to clojure...
There are many small reasons like that.

But, you're desire to stay in vim (which you already know) may outweigh any
of those reasons. Only you will be able to answer your question. I would
give emacs 3-6 months of a trial period and then you'll know which you
want.

2 guys on my team had previous vim experience and no previous emacs
experience. I offered to try vim with Clojure if after using emacs they
found they still preferred clojure in vim. So far, we're all still using
emacs.

Sent from my iPhone

On Feb 2, 2013, at 5:09 AM, Ersin Er  wrote:

Hi all,

Just as Colin Yates announced in the thread "emacs - how to wean me off the
family of Java IDEs" I am in the process of moving to emacs or vim for
active development with Clojure.

My question is a bit different: I am already an experienced vim user. I
have been using vim mostly for editing shell scripts, config files etc. but
not for active development. I am also not a vim expert such as one who can
write at the speed of thought! (So this is a signal that I am not that much
bound to vim and I can make a switch.)

As far as I can see I need to type a little more in emacs for getting stuff
done than I do with vim. Despite this disadvantage(?) does emacs really
shine for begin an environment? On the other hand, vim-foreplay also looks
promising at vim's side.

I don't want to restart an editor flame war here but I really need advice.

Thanks.

-- 
Ersin Er

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

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

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

I could define repl driven development in a lot of ways. If I'm in a
clj file is there an easy way to evaluate a sexp in the context of the
repl? Just having a repl that I cut and paste from is not a similar
experience.

Sent from my iPhone

On Jan 29, 2013, at 5:21 PM, Dennis Haupt  wrote:

> Am 29.01.2013 23:05, schrieb Phil Hagelberg:
>>
>> Jay Fields writes:
>>
>>> On Tue, Jan 29, 2013 at 11:45 AM, Laurent PETIT  
>>> wrote:
>>>> Hello Jay,
>>>>
>>>> I'd like to learn a little bit more from what makes you prefer emacs
>>>> over IntelliJ.
>>>> As the main developer of Counterclockwise, I'm I could learn some
>>>> ideas, if not lessons, from your experience.
>>>
>>> Sure, responses inline-
>>
>> While it's great to list features, the specific features really aren't
>> the point--the point is that new features can be added with very little
>> friction. If you had to restart the program and lose all the state
>> you've built up just to try out a new command you're going to be less
>> likely to bother with it, but if you can just open up your dotfiles,
>> bash out a new defn and try it incrementally, you're going to be more
>> likely to experiment with the little things.
>>
>> I blogged (ranted?) a bit about this a while ago: http://technomancy.us/115
>>
>> But perhaps it's redundant to praise at length the benefits of a
>> repl-driven workflow to this audience. =)
>>
>> -Phil
>
> you can do repl driven development with intellij as well i think.
>
> --
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

I use it for Clojure, html, css, & js - no sql tho, so I can't comment
on that. Otherwise, everything is great.

I use emacs-live, which you can add to a vanilla emacs install and get
right started. All you need to nrepl-jack-in.

On Tue, Jan 29, 2013 at 1:21 PM, Josh Kamau  wrote:
> Question: Is this emacs also good in other stuff such as
> javascript/css/html/sql  Most of my projects involve writing this as
> well .   Does anyone have a link to an up to date instructions on how to
> setup emacs for clojure ? most of what i find are out of date... e.g some
> talk of swank-clojure and i read somewhere that i should use nRepl or
> something like that.
>
> regards.
> Josh.
>
>
> On Tue, Jan 29, 2013 at 9:17 PM, Jay Fields  wrote:
>>
>> Rich, almost all keystrokes have names you can use from M-x - if you
>> prefer that to keystrokes.
>>
>> On Tue, Jan 29, 2013 at 11:59 AM, Rich Morin  wrote:
>> > On Jan 29, 2013, at 08:50, Dennis Haupt wrote:
>> >> i don't know emacs, so i would like to know as well what the killer
>> >> features
>> >> are that make you more productive with emacs
>> >
>> > Me two.  More generally, I'm interested in features that DON'T require
>> > filling
>> > my head with zillions of obscure key sequences.
>> >
>> > -r
>> >
>> >  --
>> > http://www.cfcl.com/rdmRich Morin
>> > http://www.cfcl.com/rdm/resume r...@cfcl.com
>> > http://www.cfcl.com/rdm/weblog +1 650-873-7841
>> >
>> > Software system design, development, and documentation
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

Rich, almost all keystrokes have names you can use from M-x - if you
prefer that to keystrokes.

On Tue, Jan 29, 2013 at 11:59 AM, Rich Morin  wrote:
> On Jan 29, 2013, at 08:50, Dennis Haupt wrote:
>> i don't know emacs, so i would like to know as well what the killer features
>> are that make you more productive with emacs
>
> Me two.  More generally, I'm interested in features that DON'T require filling
> my head with zillions of obscure key sequences.
>
> -r
>
>  --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

On Tue, Jan 29, 2013 at 11:45 AM, Laurent PETIT  wrote:
> Hello Jay,
>
> I'd like to learn a little bit more from what makes you prefer emacs
> over IntelliJ.
> As the main developer of Counterclockwise, I'm I could learn some
> ideas, if not lessons, from your experience.

Sure, responses inline-

> 2013/1/28 Jay Fields :
>> There are too many reasons to list, but it all comes down to a
>> simple question for me: do you want the ability to easily automate tasks
>> that you often repeat?
>
> Is this really the core of your concerns? Are you talking about the
> ability for you to write new elisp scripts, or to benefit from a bunch
> of existing elisp scripts from the emacs community? Is this mostly
> related to the fact that Clojure support in IntelliJ is lacking in key
> areas? Or is it really the liberty that comes with emacs lisp that you
> value overall? (And is it overrated, or not ?)

What's already written is great (clojure-mode, paredit, magit, ace
jump) and the ability to extend via elisp is equally nice. Here's a
"grep defun init.el"
(defun run-expectations () ;;; run all the tests for my project
(defun run-expectations-for-source () ;;; run the tests for the src
file I'm currently editing
(defun rerun-last-run-expectations () ;;; rerun the last tests,
regardless of what buffer I'm in
(defun toggle-expectations-and-src () ;;; go to test for src or src
for test, depending on which I'm already in
(defun clojure-comment-sexp () ;;; comment an entire sexp instead of
only commenting a line
(defun switch-project (project-root) ;;; close all buffers, restart
the repl, set my project dir, etc
(defun grep-string-in-project (s) ;;; find a string in my project
(defun grep-string-in (s project-root) ;;; find a string in a dir -
defaulted to my project root
(defun default-window-layout () ;;; layout my buffers in my usual way
(two pane, src & test)
(defun console-layout () ;;; layout my buffers with src on left and
logs on right
(defun clear-nrepl-server-output () ;;; no matter what buffer I'm in,
clear the output in the nrepl server buffer
(defun create-clj-function ()  ;;; create a new function with the name
of the currently selected symbol
(defun extract-let (var-name) ;;; extract a let with the currently selected sexp
(defun inline-let-var () ;;; inline instances of a var from my let

Basically, I can switch to a project, set my buffers (split horizontal
or vertical), search, run tests, & run the app all with commands that
I've defined (or keystrokes that I've defined).

>> IntelliJ is great at automating some things (e.g. Import namespace), but if
>> you want to extend its functionality it's a significant task. Conversely, I
>> now open my projects with a keystroke,
>
> Can you describe this "open my projects with a keystroke" feature to me?

the elisp
(defun switch-project (project-root)
  (interactive (list (read-directory-name "Project Root: "
(locate-dominating-file default-directory "project.clj"
  (nrepl-quit)
  (when (equal current-prefix-arg nil)
(mapc 'kill-buffer (buffer-list)))
  (cd project-root)
  (nrepl-jack-in))

in english
select the project root, kill any currently running nrepl,
conditionally kill all existing buffers, set my working dir, start a
new repl. At that point I can navigate (C-x C-f **) to my "main"
namespace and run my "start" function (C-x C-e ***) to start my
project in the context of my newly running repl. The bottom of my main
namespace will probably look like
(comment
  (start)
)
So, I go to the space following the closing parenthesis on the start
line and C-x C-e to evaluate (start) - which starts my app.

Now my app is running and I can C-x C-e on any sexp in my codebase to
change anything. I can stop/start any third party connections, reload
configuration files, send fake data to the UI, or anything else I
want. Since I can evaluate any snippet of code in the context of my
app, I can do anything. Often it's as simple as simply looking at the
values of an atom or ref, but it can also be: reload the config file
to pick up a change I just made to point to a new 3rd party server,
restart the 3rd party connections, redefine the 3rd party data handler
to print the incoming data, then redefine the 3rd party data handler
to store it in the appropriate atom, then print the value of the atom
for verification.

I have an interactive environment that I can eval any snippet in. I
can develop new features without starting and stopping my server, and
see the changes immediately.

** Find file
*** Evaluate the Emacs Lisp expression before point, and print the
value in the echo area (eval-last-sexp).

>> start my app with a keystroke
>
> same question. Is it mostly (only?) leiningen apps with a repl ?

Answered above, but, yes, a leiningen app, c

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

On Tue, Jan 29, 2013 at 9:28 AM, Feng Shen  wrote:
> I have programming Clojure for almost 2 years, for a living.
>

This is probably an important part of what answer the OP is looking
for. When I was doing Clojure for about 10% of my job IntelliJ was
fine. Now that it's 90% of my job, I wouldn't be able to give up emacs
go back to IntelliJ.

If you're just looking at Clojure as a hobby and you already know
IntelliJ, I wouldn't recommend switching. However, if you're going to
be programming Clojure almost all of the time, I think emacs is the
superior choice.

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

Re: is intellij idea a good ide for clojure development?

[Jay Fields]

I used IntelliJ for clojure dev for almost 3 years. About six months ago I
finally took the time to learn emacs, and I strongly regret not doing it
much earlier. There are too many reasons to list, but it all comes down to
a simple question for me: do you want the ability to easily automate tasks
that you often repeat?

IntelliJ is great at automating some things (e.g. Import namespace), but if
you want to extend its functionality it's a significant task. Conversely, I
now open my projects with a keystroke, start my app with a keystroke and
have the ability to eval any snippet of clojure in the context of my app. I
also automated running tests, creating tests that do not exist, and
navigating to tests. Finally, paredit - which I could neither adequately
praise or explain in one sentence. For me, that equals a level of
productivity that is orders of magnitude better than what I had in
IntelliJ.

But, if you simply want the best pre packaged solution, I wouldn't
recommend emacs.

If you want to get started with emacs, give emacs live a look. It's a great
starting point.

Sent from my iPhone

On Jan 28, 2013, at 6:38 AM, Dennis Haupt  wrote:

the only ides i have used so far for clojure are intellij idea and
netbeans. is there one that is a lot better? if yes, why?
i am not interested in details or single features, i just want to know if
there is some magic editor out there that i should look into because it is
*obviously a lot* better - like in "you should use an ide for java
development instead of notepad"

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

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

Re: Is contributing to clojurescript is intentionally made hard ?

[Jay Fields]

I'm not sure I've ever sent an email where the entire content should
be "+1", but this is the one where it felt most compelling.

Please split the list.

Sent from my iPhone

On Jan 18, 2013, at 4:25 PM, Phil Hagelberg  wrote:

>
> Irakli Gozalishvili writes:
>
>> - I do understand that most of the clojurescript audience is probably
>> also interested in clojure, but please don't enforce that. Have a
>> separate mailing list so that people interested in clojurescript and
>> not clojure could follow relevant discussions without manually
>> filtering out threads.
>
> I don't know whether or not contributions are intentionally made hard,
> but I would also appreciate separate mailing lists and IRC channels for
> Clojure and ClojureScript.
>
> -Phil
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: emacs - how to wean me off the family of Java IDEs

[Jay Fields]

emacs-live is a pretty great starting point. It's the
'whole-kitchen-sink', but it's great for finding out what you don't
know.

emacs-rocks videos are good (and short)

I also put off learning it until late last year, and I'm not
completely converted. I *love* it and would be very unhappy if I
didn't have it.

I missed the project explorer at first, until I figured out that I can
C-x C-f and just start typing, and emacs will fuzzy match what I might
be looking for, including files in directories other than current.

On Wed, Jan 16, 2013 at 10:01 AM, Colin Yates  wrote:
> Thanks Alex.
>
> Charlie - I hear you.  You are right to (very gently) point out that I
> should embrace new idioms.  Boy it is hard though :).  I have to say that I
> too found it much less of a shock then I thought.  I am very familiar with
> Linux and shell scripts so I had that skillset already which I think helps
> the with the paradigm shift.
>
> I accept your (implicit) challenge - let's continue without a project
> explorer :)
>
>
> On 16 January 2013 14:42, Charlie Griefer  wrote:
>>
>>
>> On Jan 16, 2013, at 7:29 AM, Colin Yates  wrote:
>>
>> Hi all,
>>
>> After 15 off years of using IDEs I am making the jump into Emacs.  I have
>> read http://dev.clojure.org/display/doc/Getting+Started+with+Emacs and
>> https://github.com/technomancy/emacs-starter-kit and I am just at the point
>> where I have stopped yelling at paredit and starting to appreciate its
>> point.
>>
>> My current major stumbling block though is navigating my project.  Whilst
>> (I expect) the density and sane namespacing capabilities of Clojure to
>> significantly reduce the number of files, that isn't true of everything.  In
>> particular, ExtJS encourages you to follow the "one file per class".  You
>> don't have to but eventually you will have more than a handful of files
>> regardless.
>>
>> So my questions:
>>  - is there a decent project explorer.  I really miss the "tree on the
>> left, editor on the right" layout
>>  - is there a decent JS and clojure autocompletion aware plugin
>>  - other than paredit, nrepl and clojure-mode (and the excellent
>> coffee-mode for coffeescript), what other plugins should I install
>>
>>
>> Hi Colin:
>>
>> No real answers, but I wanted to chime in to say that I'm in the same
>> spot. I had been putting off using Emacs until I felt I was "ready", but
>> then came to realize that the choice to use Emacs is like the choice to have
>> kids. If you wait until you're "ready", you'll never do it.
>>
>> This is week 2 and it's definitely getting better, altho truth be told it
>> wasn't nearly as bad last week as I expected it would be. Been working on
>> the desktop with a cheat sheet constantly open on my laptop next to me.
>>
>> I also miss the project explorer. I'm used to working with multiple files
>> at once, having them open in tabs, and being able to easily switch back and
>> forth between any of them. I've definitely found that to be a bit jarring in
>> Emacs, but trust that at some point I'll get used to the "Emacs way" versus
>> trying to find a plugin to provide a project explorer. I have to remind
>> myself that all of the files that I'm working with are there, they're just
>> not immediately visible. M-x B will let me go thru the list of files open in
>> buffers, even if those buffers aren't visible. It's different, but that's
>> where the trust comes in :)
>>
>> The biggest issue I find with the lack of a project explorer is when I
>> don't know what directory a particular file is in. Emacs provides great
>> autocompletion when you're navigating to a particular file in the
>> minibuffer, but that presumes you know exactly where the file is.
>>
>> I suppose there's always the option of opening a dired buffer (M-x dired)
>> or even a shell (M-x shell). That's still not as "easy" or visual as a
>> directory tree, but I think the big issue is that Emacs is really all about
>> keeping your hands on the (proper) keys. A shell at least lets you continue
>> to type your way around your directory structure to locate a file. A
>> directory tree/project explorer would likely require grabbing the mouse and
>> clicking down into various directories. It's what we're used to, yes… but
>> it's not really, um… idiomatic Emacs :D
>>
>> --
>> Charlie Griefer
>> http://charlie.griefer.com
>>
>> "Give light, and the darkness will disappear of itself."
>> -- Desiderius Erasmus
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group,

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Jay Fields]

It might help if you told us why you're asking this question. My guess
would be that you want to introduce Clojure, but you're afraid of
backing yourself into a corner if it begins to die off. If that is the
case, I think choosing to adopt is a safe choice (I've made the same
choice, and many others have as well). If you have another motivation
for your question, you should probably share it.

As far as Rich commiting to a platform, why would he? Who knows that
Oracle will do with the JVM? Who knows what Rich will do with his life
(what if he wanted to dedicate all his time to Datomic?) Why would he
want to commit to anything? Clojure is viable now and available now,
but no one knows what the future holds.

You aren't likely to get commitments, so you have to make the safest
bet given the current information. Currently, Clojure is JVM first.
Smart money says it will be for the foreseeable future, but nothing is
or will ever be guaranteed. If you *need* a guarantee, you probably
shouldn't adopt Clojure. If there's a better option than the JVM,
Clojure may move, and so will most of us. We want to deliver software
- not dedicate ourselves to a specific VM. However, if you're
comfortable making a safe bet, then Clojure+JVM are likely to be
around for a very long time.

On Thu, Dec 27, 2012 at 11:55 PM, Sukh Singh  wrote:
> Is there any chance of clojure community abandoning the JVM as the
> primary plaform in the future?
>
> On Dec 27, 4:41 pm, Michael Klishin 
> wrote:
>> 2012/12/27 Sukh Singh 
>>
>> > From the above statements, can I say that
>>
>> > *the JVM will always likely, remain the primary Clojure implementation* ?
>>
>> The answer is: nobody will give you a definitive answer. This is open
>> source software, "primary" implementations
>> are not "assigned", they are what people actually adopt.
>>
>> Seehttps://groups.google.com/d/topic/clojure/pEWgq1MGbYY/discussion
>> --
>> MK
>>
>> http://github.com/michaelklishinhttp://twitter.com/michaelklishin
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Autotest for Clojure/Midje?

[Jay Fields]

another option:

https://github.com/jaycfields/expectations
&
https://github.com/jakemcc/lein-autoexpect

On Tue, Dec 11, 2012 at 12:38 PM, Timothy Baldridge
 wrote:
> For a project I'm working on it would be awesome to have my tests auto-rerun
> after every file change. I know lazy test exists, but it doesn't work with
> Lein2 it seems.
>
> In the past I've used speclj with lein speclj -a. But I'd rather not use
> specs in this design, instead sticking with clojure's tests.
>
> Any suggestions?
>
> Thanks,
>
> Timothy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: what Jetty jars do I need for WebSockets?

[Jay Fields]

The upside of using Java is that it's very widely documented. Also, I
find people on this mailing list to be very helpful. Nonetheless, I'm
sure it's frustrating to have to learn about Java when you just want
to do some Clojure.

I've previously written about using Webbit with Clojure:
http://blog.jayfields.com/2011/02/clojure-web-socket-introduction.html

afaik, the post should be up to date and still working. Feel free to
email me if you run into any issues.

On Mon, Dec 10, 2012 at 8:25 AM, larry google groups
 wrote:
>
> Thank you. I will do that.
>
> I find that trying to learn both Clojure and the JVM (which automatically
> entails parts of the Java eco-system), is a little overwhelming at first.
> But I suppose that is true of learning anything new.
>
>
> On Sunday, December 9, 2012 9:04:44 PM UTC-5, Jay Fields wrote:
>>
>> I don't have the answer, but I would strongly recommend webbit:
>> https://github.com/webbit/webbit
>>
>> I've been using it for quite awhile and I've been very happy with it.
>>
>> On Sun, Dec 9, 2012 at 8:55 PM, larry google groups
>>  wrote:
>> >
>> > I am still fairly new to Clojure, the JVM and Java, so I get lost trying
>> > to
>> > read some of the stuff that assumes knowledge of any of those 3. I want
>> > to
>> > build a Clojure app using Jetty and offering WebSocket connections.
>> >
>> > I have already built an app with Clojure and Jetty, so that part is
>> > easy.
>> > But I look here:
>> >
>> >
>> > http://wiki.eclipse.org/index.php?title=Jetty/Feature/WebSockets&oldid=297254
>> >
>> > and it says I should download 3 jars:
>> >
>> > wget -O jetty-all.jar --user-agent=demo \
>> >
>> >
>> > http://repo2.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/7.6.2.v20120308/jetty-all-7.6.2.v20120308.jar
>> > wget -O jetty-websocket-tests.jar --user-agent=demo \
>> >
>> >
>> > http://repo2.maven.org/maven2/org/eclipse/jetty/jetty-websocket/7.6.2.v20120308/jetty-websocket-7.6.2.v20120308-tests.jar
>> > wget --user-agent=demo \
>> >
>> >
>> > http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
>> >
>> >
>> >
>> > I assume I put these in project.clj? I already have stuff in there like:
>> >
>> >   :dependencies [[org.clojure/clojure "1.3.0"]
>> >  [net.cgrand/moustache "1.1.0"]
>> >  [ring "1.1.5"]
>> >  [ring/ring-jetty-adapter "1.1.5"]
>> >
>> > etc
>> >
>> > Searching on this topic brought me to this:
>> >
>> >
>> > https://groups.google.com/forum/?fromgroups=#!topic/ring-clojure/JD9FLJFTVsg
>> >
>> > But that is 2 years old. I have not found anything specific to
>> > ring/jetty/websockets that is recent.
>> >
>> > Can anyone point me to documentation that might lead me out of my
>> > confusion?
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > 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 post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: what Jetty jars do I need for WebSockets?

[Jay Fields]

I don't have the answer, but I would strongly recommend webbit:
https://github.com/webbit/webbit

I've been using it for quite awhile and I've been very happy with it.

On Sun, Dec 9, 2012 at 8:55 PM, larry google groups
 wrote:
>
> I am still fairly new to Clojure, the JVM and Java, so I get lost trying to
> read some of the stuff that assumes knowledge of any of those 3. I want to
> build a Clojure app using Jetty and offering WebSocket connections.
>
> I have already built an app with Clojure and Jetty, so that part is easy.
> But I look here:
>
> http://wiki.eclipse.org/index.php?title=Jetty/Feature/WebSockets&oldid=297254
>
> and it says I should download 3 jars:
>
> wget -O jetty-all.jar --user-agent=demo \
>
> http://repo2.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/7.6.2.v20120308/jetty-all-7.6.2.v20120308.jar
> wget -O jetty-websocket-tests.jar --user-agent=demo \
>
> http://repo2.maven.org/maven2/org/eclipse/jetty/jetty-websocket/7.6.2.v20120308/jetty-websocket-7.6.2.v20120308-tests.jar
> wget --user-agent=demo \
>
> http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
>
>
>
> I assume I put these in project.clj? I already have stuff in there like:
>
>   :dependencies [[org.clojure/clojure "1.3.0"]
>  [net.cgrand/moustache "1.1.0"]
>  [ring "1.1.5"]
>  [ring/ring-jetty-adapter "1.1.5"]
>
> etc
>
> Searching on this topic brought me to this:
>
> https://groups.google.com/forum/?fromgroups=#!topic/ring-clojure/JD9FLJFTVsg
>
> But that is 2 years old. I have not found anything specific to
> ring/jetty/websockets that is recent.
>
> Can anyone point me to documentation that might lead me out of my confusion?
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Proposed change to let-> syntax

[Jay Fields]

On Fri, Nov 30, 2012 at 10:37 AM, Rich Hickey  wrote:
> The new names being considered for let->, test-> and when-> are:
>
> A) let-> becomes as->

I prefer ->as, but don't feel strongly about it.

(-> 1
str
(->as one-str
  (count one-str)
  (* 2 one-str))) ;; returns 2

The thing that I like about this is that it reads to me as "thread
as", and the ordering of "->" and "as" reminds me that the args are
slightly different from traditional threading macros (i.e. it's not
(thread-macro x & forms).

> B) test-> becomes cond->

I don't like cond-> for the same reason I didn't like let->, the
cond-> isn't easy to understand if you already understand cond and ->.
To try to come up with a name that I like, I tried to write some
similar code to see what I would use. I came up with the following:

(->> 1
 (#(if (number? %) (str %) %))
 (#(if (string? %) (count %) %))) ;; returns 1

Which led me to the following (the best I can come up with right now).

(if-> 1
  number? str
  string? count) ;; returns 1

I don't think this is a homerun, as the understanding of "if" and "->"
wouldn't guarantee an understanding of this. However, I couldn't come
up with an example of solving a similar problem with -> and cond in
any sensible way. I don't think the shape of the arguments should
define the name, which is the only reason you'd want to use "cond",
imho.

I also considered something that expressed "if or identity. Perhaps
something like the following

(ifoi-> 1
 number? str
 string? count) ;; ifoi stands for "if or identity".

You could also use ifei->, for "if else identity"

Perhaps the issue is resolved if the form can take an else fn. Then
the original if-> example becomes

(if-> 1
  number? str identity
  string? count identity)

This also gives you the freedom to put any function you want in the
else clause. I don't know if that's a good thing or not.

Or, since the significant majority of us have auto-complete, perhaps
the following works

(if-else-identity-> 1
number? str
string? count)

> C) when-> becomes some->

I don't see any issue with when->, that one actually seems very clear.
Is the issue that you want to be able to continue the threading with
false? If so, I wouldn't overload the meaning of "some", I'd simply
make it take a test fn - then you can use any pred you want.

(->when (comp not nil) (f1) (f2))

Which is even more clear if you define not-nil? in core. Then all of
the following would easily work

(->when 1 not-nil? (f1) (f2)) ; thread when not nil
(->when 1 identity (f1) (f2)) ; thread when truthy
(->when 1 #{1 2 3} (f1) (f2)) ; thread when the value is 1 2 or 3.

note, I switched the order again, as I like the way it reads (e.g.
"thread when 1 is not nil"), and it reminds me that this is a
threading macro that takes more than x & forms.

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

Re: help choosing dev environment for clojure

[Jay Fields]

I spent 3 years doing Clojure (for prod apps) in IntelliJ. 3 months ago I 
switched to emacs - and would never go back. 

If the idea of customizing your dev environment to automate repetitive tasks is 
appealing to you, start learning emacs immediately. I deeply regret not 
learning emacs earlier. If you just want to get things done and don't care too 
much about your development env, stick with eclipse or IntelliJ. 

Sent from my iPad

On Nov 25, 2012, at 8:39 AM, Sol Tourne  wrote:

> 
> hello -- 
> 
> There are a few resources out there to help one getting started with 
> emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource 
> helping me decide which learning curve to climb: the pros and cons of 
> sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, 
> etc.
> 
> In making that choice, my priority is an environment that complements the 
> REPL with a debugger that allows me to step through the execution, peek at 
> values at intermediate stages of the computation, evaluate expressions within 
> that intermediate stage, etc. Given that, does anybody have advice for a 
> newcomer? 
> 
> thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs...
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Proposed change to let-> syntax

[Jay Fields]

another thought - a really nice thing about if, let, and if-let is
that if you know how to use if and let, if-let just makes sense. You
can't say the same about ->, let, and let-> with the current proposal.

On Fri, Nov 16, 2012 at 7:32 AM, Alex Nixon  wrote:
> On 16 November 2012 01:25, Mark Engelberg  wrote:
>>
>> On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy  wrote:
>>>
>>> The primary point of let-> is that you can insert it into an existing ->
>>> pipeline.
>>>
>>
>> That makes sense.
>
> It does - thanks for the clarification.
>
> So is let-> intended to be *never* used outside of ->? If so, can an
> argument be made for enforcing its use within -> to avoid (as far as I'm
> aware) introducing a 'new' (value first, name second, no destructuring
> support) binding syntax into core?  Despite it being more verbose, I'd
> rather read (-> 42 (let-> meaning-of-life (inc))) than (let-> 42
> meaning-of-life (inc)).
>
> And on destructuring - the closest I can get with keeping compatibility with
> existing -> forms would be
>
> (-> {:foo 1}
>   (let-> {:keys [foo] :as x}
> (assoc x :bar :foo)))
>
> The pro is that you get the power of destructuring.  The con is that this
> would be the first occurrence of destructuring from outside of an explicit
> binding form.
> --
> Alex Nixon
>
> Software Engineer | SwiftKey
>
> a...@swiftkey.net | http://www.swiftkey.net/
>
>
> ++
> WINNER - MOST INNOVATIVE MOBILE APP - GSMA GLOBAL MOBILE AWARDS 2012
>
> Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
> limited company registered in England and Wales, number 06671487. Registered
> office: 91-95 Southwark Bridge Road, London, SE1 0AX
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Proposed change to let-> syntax

[Jay Fields]

I think using 'let' is what makes this confusing.

I'd like to have a macro/fn for both ideas being discussed in this
thread, ideally they'd both be named in a way that causes the least
amount of confusion.

I'm not sure what those names are, perhaps

(-> 1 (inc) (rebind a-num
  (- 2 a-num)
  (dec a-num))
=> -1

(let-rebind [{:keys [a b] :as state} {:a 1 :b 2 :c 9}]
  (assoc state :a (inc a))
  (assoc state :b (inc b)))
=> {:a 2 :b 3 :c 9}

On Fri, Nov 16, 2012 at 7:32 AM, Alex Nixon  wrote:
> On 16 November 2012 01:25, Mark Engelberg  wrote:
>>
>> On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy  wrote:
>>>
>>> The primary point of let-> is that you can insert it into an existing ->
>>> pipeline.
>>>
>>
>> That makes sense.
>
> It does - thanks for the clarification.
>
> So is let-> intended to be *never* used outside of ->? If so, can an
> argument be made for enforcing its use within -> to avoid (as far as I'm
> aware) introducing a 'new' (value first, name second, no destructuring
> support) binding syntax into core?  Despite it being more verbose, I'd
> rather read (-> 42 (let-> meaning-of-life (inc))) than (let-> 42
> meaning-of-life (inc)).
>
> And on destructuring - the closest I can get with keeping compatibility with
> existing -> forms would be
>
> (-> {:foo 1}
>   (let-> {:keys [foo] :as x}
> (assoc x :bar :foo)))
>
> The pro is that you get the power of destructuring.  The con is that this
> would be the first occurrence of destructuring from outside of an explicit
> binding form.
> --
> Alex Nixon
>
> Software Engineer | SwiftKey
>
> a...@swiftkey.net | http://www.swiftkey.net/
>
>
> ++
> WINNER - MOST INNOVATIVE MOBILE APP - GSMA GLOBAL MOBILE AWARDS 2012
>
> Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
> limited company registered in England and Wales, number 06671487. Registered
> office: 91-95 Southwark Bridge Road, London, SE1 0AX
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Can't dynamically bind non-dynamic var

[Jay Fields]

agreed. also, I prefer
(constantly 400)
over
(fn [] 400)

On Fri, Nov 16, 2012 at 8:11 AM, Baishampayan Ghose  wrote:
> Check out 'with-redefs' in clojure.core.
>
> -BG
>
> Sent from phone. Please excuse brevity.
>
> On 16 Nov 2012 08:02, "faenvie"  wrote:
>>
>> hi clojure-users,
>>
>> for testing an app that uses quil, i want to mock out some
>> function-calls to the quil-library ... when i do it like this:
>>
>> (ns myapp
>>   (:use clojure.test)
>>   (:require [quil.core :as q]))
>>
>> (deftest
>>   (binding [q/height (fn [] 400)]
>>   (is  400 (q/height
>>
>> i get an Exception that says:
>>
>> actual: java.lang.IllegalStateException: Can't dynamically bind
>> non-dynamic var: quil.core/height
>>
>> Any hints, how this an be solved or circumvented ?
>>
>> thanks & have a successful day
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: How to write this in idiomatic Clojure code?

[Jay Fields]

That code is clear enough that I wouldn't feel obligated to change it
if I encountered it.

You could also

(defmulti crazy class)

(defmethod crazy SomeClass [input]
  (seq (process-some-class-instance input))

(defmethod crazy :default [{:keys [children]}]
  (map crazy children))

On Thu, Nov 15, 2012 at 5:33 PM, Hussein B.  wrote:
> Hi,
>
> Would you please help me to morph this to an idiomatic Clojure ?
>
> (defn crazy [input]
> (if (instance? SomeClass input)
> (seq (process-some-class-instance input))
> (map  crazy  (:children input
>
>
> Thanks for help and time.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

ANN: expectations 1.4.18

[Jay Fields]

What - expectations is a minimalist's testing framework

- what you are testing is inferred from the expected and actual forms
- stacktraces are trimmed of clojure library lines and java.lang lines
- focused error & failure messages

Where - https://github.com/jaycfields/expectations

When - read through this code and decide if you prefer these tests to
the ones you're currently writing:
https://github.com/jaycfields/expectations/blob/master/test/clojure/success/success_examples.clj

Why - I prefer simple code that requires the minimum amount of
ceremony. expectations has a very strong emphasis on removing as much
noise as possible in the code itself and in the error messages that
are presented when a failure occurs. When a test fails the framework
concisely tells you what exactly went wrong and what it thinks is
likely the problem. expectations also has a strong focus on
consistency - whether you are testing equality, regex matching,
expected exceptions, or interactions, the syntax remains the same.
This leads to easy to write and easy to read tests - again, it's all
about increasing signal and reducing noise.

Stability - I've been using expectations to test prod code for over 2 years.

If you'd like to get started with expectations,
https://github.com/jaycfields/expectations contains instructions for
getting started using Lein, Emacs, IntelliJ, or nothing at all.

Cheers, Jay

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

Re: Bug: incorrect stack trace for function names containing ->

[Jay Fields]

Fair enough. I never noticed it before, and I know I've seen ->
converted to something similar to __GT_ in the debugger, so I
(mistakenly) thought it had something to do with the repl.

Looks like this has been around for awhile, or I'm doing something wrong.

jfields@wud-jfields01:~$ lein repl
REPL started; server listening on localhost port 44397
user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)
java.lang.IllegalArgumentException: Wrong number of args (1) passed
to: user$a (NO_SOURCE_FILE:0)
user=> *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier ""}

jfields@wud-jfields01:~$ lein --version
Leiningen 1.7.1 on Java 1.6.0_33 Java HotSpot(TM) 64-Bit Server VM

jfields@wud-jfields01:~$ lein2 repl
nREPL server started on port 49847
REPL-y 0.1.0-beta10
Clojure 1.4.0
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
  (user/sourcery function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
  (user/clojuredocs name-here)
  (user/clojuredocs "ns-here" "name-here")
user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)
ArityException Wrong number of args (1) passed to: user$a
clojure.lang.AFn.throwArity (AFn.java:437)

user=> *clojure-version*
{:major 1, :minor 4, :incremental 0, :qualifier nil}
user=> Bye for now!

jfields@wud-jfields01:~$ lein2 --version
Leiningen 2.0.0-preview10 on Java 1.6.0_33 Java HotSpot(TM) 64-Bit Server VM

jfields@wud-jfields01:~/src/zubron$ lein2 repl
nREPL server started on port 42865
REPL-y 0.1.0-beta10
Clojure 1.3.0
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
  (user/sourcery function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
  (user/clojuredocs name-here)
  (user/clojuredocs "ns-here" "name-here")
user=> *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}
user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)
ArityException Wrong number of args (1) passed to: user$a
clojure.lang.AFn.throwArity (AFn.java:437)

user=> *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}
user=> Bye for now!

Cheers, Jay

On Tue, Oct 9, 2012 at 8:38 AM, Chas Emerick  wrote:
> The message is produced in AFn.throwArity:
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFn.java#L434
>
> It looks like any name that contains a hyphen followed by a "special 
> character" (w.r.t. allowable chars in Java classnames) will result in a 
> munged (i.e. Compiler.munge()'ed) name containing a double-underscore 
> sequence that is assumed by throwArity to be a system-generated suffix.
>
> This is perhaps another case where pushing var metadata (or some subset 
> thereof) down to the function being defined in defns would be beneficial; 
> AFunction could then override throwArity to just use the :name of the 
> function being called, thus avoiding any confusion introduced by munged or 
> un-munging names.
>
> None of the above is related to nREPL.
>
> - Chas
>
> On Oct 9, 2012, at 9:10 AM, Jay Fields wrote:
>
>> I noticed something similar, but I'm using 1.3. Maybe it's a bug in nrepl?
>>
>> On Tue, Oct 9, 2012 at 6:39 AM, Alex Nixon  wrote:
>>> Hey all,
>>>
>>> I believe I've come across a minor bug in Clojure 1.4.0 (and I see the same
>>> behaviour in 1.5.0-alpha5):
>>>
>>> user=> (defn a->b [])
>>> #'user/a->b
>>> user=> (a->b 1)
>>> ArityException Wrong number of args (1) passed to: user$a
>>> clojure.lang.AFn.throwArity (AFn.java:437)
>>>
>>> Note that the reported function name in the stack trace is "user$a", where
>>> it should be "user$a->b" (or some mangled variant thereof?)
>>>
>>> Cheers,
>>> --
>>> Alex Nixon
>>>
>>> Software Engineer | SwiftKey
>>>
>>> a...@swiftkey.net | http://www.swiftkey.net/
>>>
>>> ++
>>> WINNER - MOST INNOVATIVE MOBILE APP - GSMA GLOBAL MOBILE AWARDS 2012
>>>
>>> Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
>>> limited company registered in England and Wales, number 06671487. Registered
>>> office: 21 Lawn Terrace, Blackheath, London, SE3 9LL, United Kingdom.
>>>
>>> --
>>>

Re: Bug: incorrect stack trace for function names containing ->

[Jay Fields]

I noticed something similar, but I'm using 1.3. Maybe it's a bug in nrepl?

On Tue, Oct 9, 2012 at 6:39 AM, Alex Nixon  wrote:
> Hey all,
>
> I believe I've come across a minor bug in Clojure 1.4.0 (and I see the same
> behaviour in 1.5.0-alpha5):
>
> user=> (defn a->b [])
> #'user/a->b
> user=> (a->b 1)
> ArityException Wrong number of args (1) passed to: user$a
> clojure.lang.AFn.throwArity (AFn.java:437)
>
> Note that the reported function name in the stack trace is "user$a", where
> it should be "user$a->b" (or some mangled variant thereof?)
>
> Cheers,
> --
> Alex Nixon
>
> Software Engineer | SwiftKey
>
> a...@swiftkey.net | http://www.swiftkey.net/
>
> ++
> WINNER - MOST INNOVATIVE MOBILE APP - GSMA GLOBAL MOBILE AWARDS 2012
>
> Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a
> limited company registered in England and Wales, number 06671487. Registered
> office: 21 Lawn Terrace, Blackheath, London, SE3 9LL, United Kingdom.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: basic quoting question

[Jay Fields]

symbol, 'X in the last case, implements IFn, and you're calling it
with the symbol 'Y as an argument.

On Mon, Oct 8, 2012 at 9:43 AM, Brian Craft  wrote:
> user=> ("X" "Y")
> ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
> user/eval116 (NO_SOURCE_FILE:32)
> user=> '(X Y)
> (X Y)
> user=> ['X 'Y]
> [X Y]
> user=> '[X Y]
> [X Y]
> user=> ('X 'Y)
> nil
>
>
> All of these are as I expected except the last, which I thought would throw
> something like the 1st case. What's going on there?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: ANN: a Clojure docs site, and github organization

[Jay Fields]

The CA process isn't what stops me from contributing, the post a patch
to Jira is what seems broken to me. I don't even remember how to
create a patch. Clojure is on github - we live in a fork & pull
request world, it's time for Clojure to get on board with that.

I once noticed that a Clojure fn didn't have a type hint on a return
value. Adding ^String made a substantial performance difference. Not
knowing the process, I forked, and did a pull request. I got this
response:

"Clojure projects cannot accept pull requests so all issues need to be
logged in the appropriate JIRA project and patches can be accepted
from people who have a signed Contributor's Agreement on file:

http://clojure.org/contributing
http://clojure.org/patches";

Which is informative and correct, but, do you really think I'm going
to go through that trouble? If you said yes, you're wrong.

Cheers, Jay

On Sat, Oct 6, 2012 at 11:40 AM, Softaddicts
 wrote:
> This insistence on the so-called "CA pain" seems to me overemphasized.
> It's a one shot process.
>
> Even if it takes 4 weeks for the paper to reach its destination, it does not
> prevent anyone from starting to work on some contribution. The CA
> needs to be in by the time the work is about to get published, not by the time
> you start to contribute.
>
> My writing is horrible, worst than a doctor, I hate filling forms by hand but 
> I
> was able to fill the CA, stamp it and drop it in the mailbox in less than 10 
> mns.
>
> I live in Canada close to the US, I can understand the frustration if you 
> have to drop
> by your local post office if it needs to get stamped over there but one time
> processes like this rarely benefit from an optimization.
>
> I would be surprised that we end up with >250,000 contributors in the next
> 3 years. There is simply not enough Clojure wired brains out there to get to
> numbers like the above.
>
> If it ever happens, you can bet than Clojure Core will come out
> with something to avoid being flooded by papers if it is legally feasible.
>
> Laws in many countries have been slow to move to consider
> electronic formats as legally binding documents.
> This may well be why a written CA is needed considering that contributors come
> different countries. What may seem obviously legal in one country may not be 
> legal
> at all in another.
>
> Better documentation is to me by far a more urgent priority to attract newbies
> than allowing CAs to be submitted electronically given the legal fees 
> involved just
> to get an opinion about its feasability.
>
> Luc P.
>
>
>> +1 to lowering the barrier to entry for contributing to the community.
>>
>> One of the much lauded features of Git is that it can be used to create a
>> "network of trust". In principle this means you can open your repo up to
>> anyone, but by being choosy about the pull requests you accept you can
>> control what's going to get in.
>>
>> This is perfect for something like documentation.
>>
>> Also, as it's been said before, a pen and paper CA is a pain.
>>
>>
>> On Friday, 5 October 2012 08:26:39 UTC-5, Mayank Jain wrote:
>> >
>> >
>> >
>> > On Fri, Oct 5, 2012 at 6:54 PM, Michael Klishin 
>> > 
>> > > wrote:
>> >
>> >>
>> >>
>> >> 2012/10/5 Michael Fogus >
>> >>
>> >>> You say that as if it's a bad thing.  I'm of the opinion that these
>> >>> kinds of efforts should have a low barrier to contribution and be fun.
>> >>>
>> >>
>> >> My apologies, I did not imply that it is a bad thing, only that it is not
>> >> entirely clear what direction the project
>> >> will take. While for CDS it is pretty clear (at least to people who have
>> >> started it).
>> >>
>> >> While we are at this fun stuff, can we also make the CA submission
>> >> process fun?
>> >>
>> > +1
>> >
>> >>
>> >> --
>> >> MK
>> >>
>> >> http://github.com/michaelklishin
>> >> http://twitter.com/michaelklishin
>> >>
>> >>  --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to 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
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Mayank.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post t

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

[Jay Fields]

On Mon, Sep 24, 2012 at 2:11 AM, Gregorius R.  wrote:
> Hello Clojurists!
>
> is clojure a good start to learn programming?

It depends what your goal is. If you were planning a long career in
the software development industry, then I think it's a great place to
start. As other's have pointed out, SICP is considered must-read
material for any professional programmer - thus knowing a Lisp can
only be a good thing.

That said, if your only in it to make a few extra bucks in the short
term (<10 years), I'd stick with a mainstream programming language -
.net or java. You'll have less competition in the .net space, but
you'll have less people to learn from. In the Java space you'll be
fighting more people for jobs, but you're more likely to find a mentor
as well. If you do choose Java you'll have a head-start on getting
into Clojure if you find that your path leads you there.

side/related note: people often ask me how they can break into our
industry, but they're motivated by getting a good job - not a desire
to program. These days I've been thinking: if you're just looking for
a good job, you might what to join the UX or DataScience space. Both
are still young and are more in-demand than programmers - thus you
have far less competition. Also, with a lack of an experienced
workforce, you're more likely to find jobs that are willing to accept
less experience or loosely related experience.

Finally, if you want to learn to program as a hobby, Clojure is a great choice.

Cheers, Jay

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

Re: ANN lein-expectations 0.0.7

[Jay Fields]

If you like Midje you should probably stick with it. The two libraries were
designed with very different goals in mind. Midje is much more polished and
targeted adoption early on. expectations was created for testing the
application I was working on, made available on github, but never really
promoted. If it suits your testing style, you should love it. If not,
you'll likely hate it - it's very opinionated.

Check out the github page and look at the success examples that are linked.
That will cost you less than 5 minutes, and should give you all the
information you need to decide which you prefer.

Cheers, Jay

Sent from my iPhone

On Aug 8, 2012, at 9:28 PM, keeds  wrote:

Silly question but how is Expectations better or different from Midje?
I'm just starting out with Midje and was just wondering?

Thanks,
Andrew

On Monday, 6 August 2012 19:43:18 UTC+1, Sean Corfield wrote:
>
> lein-expectations - the plugin for running Jay Fields' awesome
> Expectations testing library - has been updated for Leiningen 2.0.
>
> If you are using Leiningen 1.x, continue to use lein-expectations 0.0.5.
>
> If you are on Leiningen 2.x, you should use lein-expectations 0.0.7 so
> that exit on test failure is handled correctly.
>
> 0.0.6 added a partial fix for exit codes in Leiningen 2.0 but it
> didn't work properly with "with-profile". After discussions with Phil
> H about exit status codes, the logic was changed / simplified for the
> 0.0.7 release.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
 --
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

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

Re: ANN lein-expectations 0.0.7

[Jay Fields]

On Aug 8, 2012, at 1:09 AM, Sean Corfield wrote:

> expecting not to
> throw a specific exception is a bit trickier...

You can expect a specific exception easily, but not an exception message 
easily...

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

Re: ANN lein-expectations 0.0.7

[Jay Fields]

Laurent, as far as I know, the blog entries are still up to date. I've only 
documented the stable features of expectations, thus they shouldn't have 
changed since the blog entires were written. That said, please do let me know 
if anything is incorrect.

Sean, JUnit integration should be as simple as creating your own class that 
looks like this one:

jfields$ cat src/proj/test/expectations/AllExpectations.java 
package expectations;

import expectations.junit.ExpectationsTestRunner;
import org.junit.runner.RunWith;

@RunWith(ExpectationsTestRunner.class)
public class AllExpectations implements ExpectationsTestRunner.TestSource{
public String testPath() {
return "test";
}
}

I'm returning a path that's relative (from testPath), but it should work with 
an absolute path as well - if that's what you want. Then you just run the 
AllExpectations.java class the same as you would for any JUnit test class.

Cheers, Jay


On Aug 7, 2012, at 10:47 PM, Laurent PETIT wrote:

> Hello Jay, 
> 
> thanks for this really great livrary.
> 
> I can see that there's a thorough analysis of the framework in a blog series, 
> but which may or may not be up to date. At least, it seems a little bit 
> "dated" (in software duration time scales), but maybe it's still accurate. 
> Maybe updates on the blogs may help the newcomer understand if it's worth 
> reading now in August 2012 ?
> 
> As for IDE integration via JUnit bridge, I'll try to test it and report back 
> when I return from holidays.
> 
> Cheers,
> 
> -- 
> Laurent
> 
> 2012/8/7 Jay Fields 
> Hello all,
> 
> expectations (github.com/jaycfields/expectations) is an opinionated testing 
> framework that is available for anyone to use. I've been using it to test my 
> production code for almost 2 years now, and it's used by various teams at DRW 
> (http://drw.com) to test their production code as well. 
> 
> more info is on the readme at github.com/jaycfields/expectations
> 
> If you want to use expectations you probably want to check out
> - auto-execpt
> - lein-expectations
> - expectations-mode
> 
> and, if you're in an env where you're using an IDE, you'll probably want to 
> check out the JUnit integration. It runs very well in IntelliJ (run failed 
> tests doesn't work, everything else does afaik).
> 
> Cheers, Jay
> 
> On Aug 7, 2012, at 12:14 AM, Laurent PETIT wrote:
> 
>> Wow Expectations wasn't in my radar, thanks for helping me fix this, since 
>> it looks like a really useful and featureful test library.
>> 
>> I love the way it clearly has a path to JUnit integration which should 
>> really help leverage existing IDEs possibilities in this area.
>> 
>> Makes me think again on working on a better automated tests story for 
>> Counterclockwise users ...
>> 
>> 2012/8/7 Laurent PETIT 
>> Thanks,
>> 
>> sorry for the short email, it was sent from smartphone
>> 
>> 
>> 2012/8/6 Sean Corfield 
>> On Mon, Aug 6, 2012 at 12:01 PM, Laurent PETIT  
>> wrote:
>> > Links ?
>> 
>> https://clojars.org/lein-expectations
>> https://github.com/gar3thjon3s/lein-expectations
>> 
>> > Le 6 août 2012 à 20:43, Sean Corfield  a écrit :
>> >> lein-expectations - the plugin for running Jay Fields' awesome
>> >> Expectations testing library - has been updated for Leiningen 2.0.
>> >>
>> >> If you are using Leiningen 1.x, continue to use lein-expectations 0.0.5.
>> >>
>> >> If you are on Leiningen 2.x, you should use lein-expectations 0.0.7 so
>> >> that exit on test failure is handled correctly.
>> >>
>> >> 0.0.6 added a partial fix for exit codes in Leiningen 2.0 but it
>> >> didn't work properly with "with-profile". After discussions with Phil
>> >> H about exit status codes, the logic was changed / simplified for the
>> >> 0.0.7 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

Re: ANN lein-expectations 0.0.7

[Jay Fields]

Hello all,

expectations (github.com/jaycfields/expectations) is an opinionated testing 
framework that is available for anyone to use. I've been using it to test my 
production code for almost 2 years now, and it's used by various teams at DRW 
(http://drw.com) to test their production code as well. 

more info is on the readme at github.com/jaycfields/expectations

If you want to use expectations you probably want to check out
- auto-execpt
- lein-expectations
- expectations-mode

and, if you're in an env where you're using an IDE, you'll probably want to 
check out the JUnit integration. It runs very well in IntelliJ (run failed 
tests doesn't work, everything else does afaik).

Cheers, Jay

On Aug 7, 2012, at 12:14 AM, Laurent PETIT wrote:

> Wow Expectations wasn't in my radar, thanks for helping me fix this, since it 
> looks like a really useful and featureful test library.
> 
> I love the way it clearly has a path to JUnit integration which should really 
> help leverage existing IDEs possibilities in this area.
> 
> Makes me think again on working on a better automated tests story for 
> Counterclockwise users ...
> 
> 2012/8/7 Laurent PETIT 
> Thanks,
> 
> sorry for the short email, it was sent from smartphone
> 
> 
> 2012/8/6 Sean Corfield 
> On Mon, Aug 6, 2012 at 12:01 PM, Laurent PETIT  
> wrote:
> > Links ?
> 
> https://clojars.org/lein-expectations
> https://github.com/gar3thjon3s/lein-expectations
> 
> > Le 6 août 2012 à 20:43, Sean Corfield  a écrit :
> >> lein-expectations - the plugin for running Jay Fields' awesome
> >> Expectations testing library - has been updated for Leiningen 2.0.
> >>
> >> If you are using Leiningen 1.x, continue to use lein-expectations 0.0.5.
> >>
> >> If you are on Leiningen 2.x, you should use lein-expectations 0.0.7 so
> >> that exit on test failure is handled correctly.
> >>
> >> 0.0.6 added a partial fix for exit codes in Leiningen 2.0 but it
> >> didn't work properly with "with-profile". After discussions with Phil
> >> H about exit status codes, the logic was changed / simplified for the
> >> 0.0.7 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 post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: What concurrency models to document?

[Jay Fields]

I don't find it to be one of the reasons I use Clojure... Nor do I
find it significantly easier than other options I've used in the past
(e.g. Java + Jetlang)

I feel like concurrency is the half-truth we tell to encourage
borderline adopters or spark interest. I don't believe it's a
motivating factor for adoption.

Of course, I could name 10+ other motivating reasons, but that's
probably a topic for another time...

Sent from my iPhone

On Aug 2, 2012, at 12:05 PM, Brian Marick  wrote:

>
> On Aug 2, 2012, at 8:50 AM, Meikel Brandmeyer (kotarak) wrote:
>
>> You have to put quite a bit of thought in to get things right.
>
> Which raises the question: *is* concurrency actually a strong selling point 
> for functional languages?
>
> In last year's state of clojure survey [*], concurrency ranked 6 out of 13 
> for the "biggest wins" question, but I don't know what conclusions to draw 
> from that.
>
> I added this chapter to the outline partly as a way to force myself to learn 
> more about functional concurrency. Perhaps I need to find another excuse.
>
>
> (*) 
> http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/
>
> -
> Brian Marick, Artisanal Labrador
> Contract programming in Ruby and Clojure
> Occasional consulting on Agile
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: What concurrency models to document?

[Jay Fields]

I find auto-concurrency in clojure to be misleadingly thrown around as
free. I think a good description of what is free would be helpful, and
examples of concurrency patterns that are still necessary above
clojure data structures.

A common example from my work is a screen that will need to display a
snapshot of data when opened and insert new data at the top on new
events. It's not acceptable to publish the same data twice or never,
it must be an immediately consistent view at all times. I've found
ways to do this with both agents (when some latency is acceptable) and
single threading the storing and publishing logic. I've also solved
this problem by always sending full snapshots of the data and removing
the data that's already known to be on the screen.

None of these solutions felt elegant.

Sent from my iPhone

On Aug 2, 2012, at 2:53 AM, Christian Sperandio
 wrote:

> Hi,
>
> I don't like the term auto-concurrency  because auto-concurrency
> doesn't exist. The immutability make easier the concurrency
> programming  because you don't have to manage the shared data but, you
> always have the synchronising management and write specific code for
> concurrency (using pmap, futures, promises and so on).
>
> About the types of concurrency, I think you should talk about ref and
> agent. Refs for their transactions management and agents because for
> people coming from OOP, They remember them things like actor pattern.
>
> Good luck for your book.
>
>
> Christian
>
> Le 2 août 2012 à 02:29, Brian Marick  a écrit :
>
>> I'm writing a book on /Functional Programming for the Object-Oriented 
>> Programmer/.  It uses Clojure as the teaching 
>> language.
>>
>> Since one of the things that attracts programmers to FP is the hope that 
>> ordinary mortals can write multicore programs, I want to have a chapter on 
>> concurrency. Of the various types of concurrency Clojure offers, which do 
>> you think would be most useful to explain? My inclination is: 
>> auto-concurrency due to immutability, futures (I love futures), and atoms. 
>> What do you think would be the right set?
>>
>> -
>> Brian Marick, Artisanal Labrador
>> Contract programming in Ruby and Clojure
>> Occasional consulting on Agile
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: s-expression levels and higher order functions

[Jay Fields]

In https://github.com/jaycfields/jry I define update values, which allows you 
to 
(update-values {:a 1 :b 2} inc) ;=> {:a 2 :b 3}

I've used that in combination with update-in to do all sorts of 
transformations. 
That is obviously designed for maps, which is what your example looks like to 
me. (I don't know Mathematica)

Sent from my iPad

On Jul 17, 2012, at 9:17 PM, Seth Chandler  wrote:

> I'm new both to Clojure and to this group, so please be gentle.  I come to 
> Clojure mostly from a Mathematica background, which has a certain Lispyness 
> to it.  One of the things one can do in Mathematica is to map a function to 
> an s-expression but not at its top level, but rather at some user specified 
> level.  Thus Map[f, {{a,b},{c,d}},{2}] will (because of the {2} as the last 
> argument) evaluate to {{f[a],f[b]},{f[c],f[d]}} rather than 
> {f[{a,b}],f[{c,d}]}.  I have found this capability of having functions that 
> work at levels of an expression to be extremely valuable.  Is there work 
> already done that extends the higher order functions to permit something like 
> this.  And, yes, I am sure one could write a macro and perhaps that has 
> already been done, but I was curious as to what was out there.  My Google 
> search did not yield much on this topic, but perhaps I used the wrong Clojure 
> vocabulary.
> 
> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: a newbie question

[Jay Fields]

I think subvec is likely what you're looking for, but I also wanted to
mention take-last for the sake of completeness.

On Wed, Jul 4, 2012 at 2:16 PM, Tassilo Horn  wrote:
> John Holland  writes:
>
> Hi John,
>
>> If I want to get the last n elements of a list or vector I am doing
>> the following:
>>
>> (reverse (take n (reverse thelist)))
>>
>> Is there a better way to do this?
>
> For vectors, you can do that much more efficiently using subvec:
>
>   (subvec my-vec (- (count vec) n))
>
> For all sequential collections (lists, vectors, and sequences), I think
> this should be better:
>
>   (drop (- (count my-seq) n) my-seq)
>
> That's because lists, vectors, seqs (with the exception of lazy seqs)
> usually implement the Counted abstraction meaning that (count coll) is a
> constant time operation.
>
> Bye,
> Tassilo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: 'last' on empty collections

[Jay Fields]

It works as I expect, and I would be disappointed if it did throw. 

Sent from my iPhone

On Jul 1, 2012, at 3:47 PM, Warren Lynn  wrote:

> Right now
> 
> (last []) => nil
> (last [nil]) => nil
> 
> So there is no way to differentiate these two (except with some
> emptiness checking). In my opinion (last []) should throw an
> exception, because that's when last does not apply. From another point
> of view, there are two cases:
> 
> 1. The local semantics requires the collection not to be empty.
> Throwing an exception here will remove the burden of manual checking.
> 
> 2. The local semantics allows the collection to be empty, in that case
> the caller needs to do
> (when-not (empty? c) (last c)).
> 
> case 1 is the "normal case" with higher probability, so the burden of
> checking should be on the second case.
> 
> Your opinion?
> 
> Note this is rather academic because it probably is too late do
> anything about it at this stage. But it may help future cases.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: How to speed up Clojure Training for New Recruitment

[Jay Fields]

That's a complicated question. I think consultants* are incentivized
to present new technologies to clients and convince them it's the
right choice.** However, I don't think it ends up being the right
choice for the company on most occasions. I wish that weren't true,
but I believe that's the most common case.

If a client is already using Clojure, and wants to bring a consultancy
in, that's great for the consultancy. However, if a (traditionally
Java) client wants to bring in a consultancy, they are not likely to
be able to support any application written in Clojure. There will
definitely be exceptions; however, I think the general rule holds.

Adopting a language is tough and requires deep organizational
commitment. If a client is willing to make that commitment, great! If
not, you're likely going to fail - sooner or later. The most
interesting technical project I ever worked on was 75% abandoned when
our team left, as the in house devs were not able to support it. Part
of that was due to the way the client structured the contract;
however, the technology choice also contributed to that outcome.

I do believe that Clojure provides an advantage. I use it every day,
partly for that reason. However, you need the people around that can
support it, or it needs to be 'complete' - meaning zero maintenance. A
good example could be building a prototype.

* my statements are generalized to all consultancies, none of my
comments reflect opinions that only apply TW.
** given current consulting models. It doesn't have to be this way.

On Wed, Jun 20, 2012 at 7:53 AM, Jay Fields  wrote:
> That's a complicated question. I think consultants* are incentivized to
> present new technologies to clients and convince them it's the right
> choice.** However, I don't think it ends up being the right choice for the
> company on most occasions. I wish that weren't true, but I believe that's
> the most common case.
>
> If a client is already using Clojure, and wants to bring a consultancy in,
> that's great for the consultancy. However, if a (traditionally Java) client
> wants to bring in a consultancy, they are not likely to be able to support
> any application written in Clojure. There will definitely be exceptions;
> however, I think the general rule holds.
>
> Adopting a language is tough and requires deep organizational commitment. If
> a client is willing to make that commitment, great! If not, you're likely
> going to fail - sooner or later. The most interesting technical project I
> ever worked on was 75% abandoned when our team left, as the in house devs
> were not able to support it. Part of that was due to the way the client
> structured the contract; however, the technology choice also contributed to
> that outcome.
>
> I do believe that Clojure provides an advantage. I use it every day, partly
> for that reason. However, you need the people around that can
>
> * my statements are generalized to all consultancies, none of my comments
> reflect opinions that only apply TW.
> ** given current consulting models. It doesn't have to be this way.
>
>
> On Jun 20, 2012, at 7:37 AM, Julian wrote:
>
> Thanks Jay,
>
> Those articles are indeed inspirational. I was just wondering - back from
> your TW days - would the arguments in those articles make sense for a TW
> consultant to present to a client?
>
> Cheers, Julian
>
> On Tuesday, 19 June 2012 01:22:34 UTC+10, Jay Fields wrote:
>>
>>
>> learning curve, and training time be reduced for new recruits ? Also how
>> do you pitch it to the management ?
>>
>> I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even
>> suggest they read it. http://www.paulgraham.com/avg.html
>> Related: http://www.paulgraham.com/icad.html
>>
>> Cheers, Jay
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>

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

Re: Standard alias for partial?

[Jay Fields]

I'd actually like to see %(...) become (partial ...), as I think
people associate % with anonymous functions. Which is why I chose (%
...), as it's close to what I wish we had.

I get your point though, and I don't disagree. But, this does keep
coming up, so I think a shorter syntax for partial would be nice,
whether it's %(), #&() or whatever.

Cheers, Jay

On Tue, Jun 19, 2012 at 2:52 PM, Timothy Baldridge  wrote:
>> uh, it's going to do what you expect...
>>
>> user=>  (def % partial)
>> #'user/%
>> user=> (map #(inc %) [1 2 3])
>> (2 3 4)
>
> My point was that you have overloaded the meaning of the % symbol. If
> someone says "what does % mean in clojure". You can say "it's
> shorthand for the first argument in the shorthand version of the
> anonymous function definition.", now you have to say "well it depends
> on the scope"
>
> Please, don't ever take reader macros and re-define them out of scope
> to mean something else. It just confuses people and makes the code
> harder to read.
>
> Timothy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Standard alias for partial?

[Jay Fields]

uh, it's going to do what you expect...

user=>  (def % partial)
#'user/%
user=> (map #(inc %) [1 2 3])
(2 3 4)


On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar();  wrote:
> On 19/06/12 19:32, Timothy Baldridge wrote:
>>
>> That works until you try to use the shorthand for anonymous functions:
>>
>> (map #(inc %) [1 2 3]) ; what's this going to do?
>>
>> Timothy
>
>
> Thank you! :-)
>
> Jim
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Standard alias for partial?

[Jay Fields]

I use %, (def % partial)

On Tue, Jun 19, 2012 at 2:28 PM, Jim - FooBar();  wrote:
> what if you need the '$' for interop?
>
> Jim
>
>
> On 19/06/12 19:25, JvJ wrote:
>>
>> This is not really a big deal, but I was wondering if there was a shorter
>> alias for partial in the standard library.  It seems like one of those
>> things that should require a single-character operator.
>>
>> I usually do something like this :
>>
>> (def $ partial)
>>
>> I wonder if something like that could be integrated into the library...
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Converting String to Hashmap

[Jay Fields]

first of all, what gender is "n"? =)

http://blog.jayfields.com/2011/03/clojure-eval-ing-string-in-clojure.html

On Mon, Jun 18, 2012 at 11:18 AM, Antix wrote:

> Hi Guys,
> I'm very new to clojure and searching for a way to convert a given
> String to a Hashmap as far as this is possible.
> I thought already about the use of a macro, but all the different
> quotes are a little bit confusing for me.
>
> Is it possible to create a Hashmap or some similar structure by using
> a given String.
>
> My Input-String is something like: :Name "John", :age 20, :gender
> "n"
> Is it possible to convert this to a hashmap similar to this:
> (def hashm {:Name "John", :age 20, :gender "n"  }) ?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: How to speed up Clojure Training for New Recruitment

[Jay Fields]

On Mon, Jun 18, 2012 at 3:11 AM, Murtaza Husain <
murtaza.hus...@sevenolives.com> wrote:

> Hi,
>
> Just wanted to get pointers on how do you manage the training of recruits.
> It is difficult to find clojure talent, and we are located in India, where
> it is close to impossible. Also the non availability of talent becomes a
> hard sell to management too while introducing clojure projects. How can the
> learning curve, and training time be reduced for new recruits ? Also how do
> you pitch it to the management ?
>

I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even
suggest they read it. http://www.paulgraham.com/avg.html
Related: http://www.paulgraham.com/icad.html

As far as actually finding people, I'd look in the Ruby community. Many of
those people are fine with functional style and not too attached to a
specific language. And, do what Bill recommended.

Cheers, Jay

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

Re: meta-questions - [clojure] in front of Subject line

[Jay Fields]

this is also true of the ActionScript solution...

let's get back on topic, tabs or spaces?

On Mon, Jun 18, 2012 at 9:02 AM, Tassilo Horn wrote:

> Dave Kincaid  writes:
>
> >> [Automatic insertion of [clojure] depending on user preference]
> >
> > Seems like a great enhancement that Google could make. Give each
> > subscriber this as an option. Then each of us can choose whether to
> > add this or not to messages we see.
>
> No, that's actually not a very good idea.  As soon as you follow up to
> some message, your personal preferences shine through for all to see.
>
>  Re: [clojure] the real subject
>
> For me, it'll look like you've changed the subject (well, you actually
> did).
>
> Bye,
> Tassilo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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