Re: ANN - [vinyasa 0.1.0] - Give your clojure workflow more flow

2014-01-01 Thread Ambrose Bonnaire-Sergeant
Thanks for sharing!

Ambrose


On Wed, Jan 1, 2014 at 12:56 PM, zcaudate z...@caudate.me wrote:

 I've done a write up of my workflow here:

 http://z.caudate.me/give-your-clojure-workflow-more-flow/

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


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


ANN: bidi, a URI dispatch and formation library for Clojure

2014-01-01 Thread Malcolm Sparks
I'd like to announce a new URI routing library called bidi.

If you're planning to write HTTP/web applications in Clojure in 2014, 
chances are you'll be including hyperlinks (URIs) in your 
pages/views/templates. After all, this is what the web is all about. But 
the code that includes/generates your URIs can get tightly coupled with the 
code that dispatches on them (Compojure routes, etc.), this can lead to 
broken links if you're not careful.

Having used Pedestal services in many of my systems, I'd made heavy use of 
the (url-for) function. But I found it difficult to extract the Pedestal 
routing code from the rest of the Pedestal back-end concepts. When I wanted 
to be able to use http-kit for another project, this prevented me from 
using Pedestal and I really missed the ability to form URIs - I wanted was 
the (url-for) function back!

Like Pedestal, bidi starts with a data description of your routes - acting 
as the basis for both the generation of URIs and the dispatch to your 
handlers. However, bidi only offers URI routing and formation - nothing 
else - so it can be used for 'traditional' Ring web apps, http-kit, 
Liberator and so on. With a little work it should work well with 
ClojureScript too, since it is based on protocols rather than macros.

You can find more about bidi, with code examples, here: 
https://github.com/juxt/bidi

While I've been thinking about writing bidi for a long time (hoping someone 
else more capable than me would write it!), the actual code is very new and 
so all the usual disclaimers apply. However, I'd be very grateful for 
feedback on this new library - what you like and dislike about it, initial 
impressions, complaints, alternatives you know about and any questions etc..

And finally I'd like to wish everyone on this list a Happy New Year and the 
very best for your Clojure hacking activies in 2014.


Malcolm

JUXT - https://juxt.pro


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


core.logic vectors vs lists

2014-01-01 Thread Milton Silva
Given this:

(defn nullo [l]
  (== '() l))

(defn all-uno [l]
  (conde
   [(nullo l) s#]
   [(fresh [f r]
 * (firsto l 1)*
  (resto l r)
  (all-uno r))]))

why is it that 
(run* [q]
  (all-uno [1 q 1 q])) 

unifies q with 1 and

(run* [q]
  (all-uno '(1 q 1 q)))

doesn't?

More generally, when using core.logic, when should we expect behavior to 
differ when  using vectors vs proper lists?

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


[Video] Generative testing in Clojure

2014-01-01 Thread James Trunk
Hi everyone,

Here is an introduction to generative testing in 
Clojurehttp://www.youtube.com/watch?v=u0TkAw8QqrQ using 
simple-check.

I hope newcomers to the technique/library find it useful!

Cheers, 
James

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


Re: core.logic vectors vs lists

2014-01-01 Thread Milton Silva
Thank you for the response and for core.logic. I assumed '(a b c) was equal 
to (list a b c) which I now see is a wrong assumption.

On Wednesday, 1 January 2014 15:57:38 UTC, Milton Silva wrote:

 Given this:

 (defn nullo [l]
   (== '() l))

 (defn all-uno [l]
   (conde
[(nullo l) s#]
[(fresh [f r]
  * (firsto l 1)*
   (resto l r)
   (all-uno r))]))

 why is it that 
 (run* [q]
   (all-uno [1 q 1 q])) 

 unifies q with 1 and

 (run* [q]
   (all-uno '(1 q 1 q)))

 doesn't?

 More generally, when using core.logic, when should we expect behavior to 
 differ when  using vectors vs proper lists?


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


Storing data on web server with Clojure

2014-01-01 Thread curiousGuy
I recently got started with Heroku and Clojure. They provide an optional 
SQL database for handling data, but it is not enabled by default. I'm 
wondering how much sense it makes to use SQL on a Clojure environment, vs 
just using sequence types within the language to store data and backing 
them up as writes out to a file, then reading them back in when necessary? 
I suppose for very large data stores, this is not ideal as you'd have a lot 
of data in memory.

I'm coming from a PHP/MySQL background and am quite new to Clojure so I 
don't want to shoot myself in the foot by quickly adopting old habits 
rather than embracing more idiomatic approaches. Any advice, or anyone 
actively using data in the cloud with Clojure care to comment?

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

2014-01-01 Thread Mark Nutter
Nicely done, I've been looking for a good intro to generative testing. The
real-world example at the end nicely illustrates the value of the
shrinking part of the algorithm. Thanks for publishing this.


On Wed, Jan 1, 2014 at 10:58 AM, James Trunk james.tr...@gmail.com wrote:

 Hi everyone,

 Here is an introduction to generative testing in 
 Clojurehttp://www.youtube.com/watch?v=u0TkAw8QqrQ using
 simple-check.

 I hope newcomers to the technique/library find it useful!

 Cheers,
 James

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

 For more options, visit https://groups.google.com/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: bidi, a URI dispatch and formation library for Clojure

2014-01-01 Thread Adrian Mowat
Hi Malcolm,

I'm working through the examples and I am getting exceptions when I try 
defining multiple routes.  I noticed the 1.8.0 is mentioned in the docs but 
the highest version on clojars is 1.7.0.  Is clojars up to date.

Stacktraces as follows

user= (def routes [/ {index.html :index
  #_= articles/ {index.html :article-index
  #_=  article.html :article}}])
#'user/routes
user= (match-route routes /index.html)

java.lang.IllegalArgumentException: No implementation of method: 
:resolve-handler of protocol: #'bidi.bidi/Matched found for class: 
clojure.lang.PersistentHashMap
   clojure.core/-cache-protocol-fn 
core_deftype.clj:  541
   bidi.bidi/eval3017/fn/G 
bidi.clj:   87
  bidi.bidi/match-pair 
bidi.clj:   97
 bidi.bidi/match-route 
bidi.clj:  193
clojure.lang.RestFn.invoke 
 RestFn.java:  425
  user$eval3329.invoke 
  NO_SOURCE_FILE:1
user= 
clojure.lang.Compiler.evalCompiler.java: 6619
clojure.lang.Compiler.eval 
   Compiler.java: 6582
 clojure.core/eval 
core.clj: 2852
  clojure.main/repl/read-eval-print/fn 
main.clj:  259
 clojure.main/repl/read-eval-print 
main.clj:  259
  clojure.main/repl/fn 
main.clj:  277
 clojure.main/repl 
main.clj:  277
clojure.lang.RestFn.invoke 
 RestFn.java: 1096
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn 
  interruptible_eval.clj:   56
clojure.lang.AFn.applyToHelper 
AFn.java:  159
  clojure.lang.AFn.applyTo 
AFn.java:  151
clojure.core/apply 
core.clj:  617
   clojure.core/with-bindings* 
core.clj: 1788
clojure.lang.RestFn.invoke 
 RestFn.java:  425
clojure.tools.nrepl.middleware.interruptible-eval/evaluate 
  interruptible_eval.clj:   41
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn 
  interruptible_eval.clj:  171
  clojure.core/comp/fn 
core.clj: 2330
 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn 
  interruptible_eval.clj:  138
  clojure.lang.AFn.run 
AFn.java:   24
 java.util.concurrent.ThreadPoolExecutor.runWorker 
 ThreadPoolExecutor.java: 1110
java.util.concurrent.ThreadPoolExecutor$Worker.run 
 ThreadPoolExecutor.java:  603
  java.lang.Thread.run 
 Thread.java:  722
(match-

user= 

user= (path-for routes :index)

java.lang.IllegalArgumentException: No implementation of method: 
:unresolve-handler of protocol: #'bidi.bidi/Matched found for class: 
clojure.lang.PersistentHashMap
   clojure.core/-cache-protocol-fn 
core_deftype.clj:  541
   bidi.bidi/eval3017/fn/G 
bidi.clj:   87
bidi.bidi/unmatch-pair 
bidi.clj:  149
bidi.bidi/path-for 
bidi.clj:  201
clojure.lang.RestFn.invoke 
 RestFn.java:  425
  user$eval3331.invoke 
  NO_SOURCE_FILE:1
clojure.lang.Compiler.eval 
   Compiler.java: 6619
clojure.lang.Compiler.eval 
   Compiler.java: 6582
 clojure.core/eval 
core.clj: 2852
  clojure.main/repl/read-eval-print/fn 
main.clj:  259
 

Namespaces in waiting

2014-01-01 Thread Dave Tenny
When I use 'lein repl' in some project context and get to the REPL prompt, 
there's an available but as yet not ... present ... namespace, i.e. 
(all-ns) won't list the namespace(s) created in the lein project directory 
tree.

Is there some API I can use to see a list these available but not active 
namespaces?

I'm guessing that looking at what's on the class path doesn't necessarily 
tell me what namespaces might be USE-able via (use 'x).




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

2014-01-01 Thread zcaudate
I've updated the lib to version 0.1.1

Also, for people having issues with the library. The minimum leiningen 
version required for vinyasa is 2.3.4. Please do an upgrade of leiningen 
before using it.

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

2014-01-01 Thread Adrian Mowat
HI Malcolm

Yup, that's much better.  Thanks for the quick reply

Cheers

Adrian


On Wednesday, 1 January 2014 20:16:50 UTC, Malcolm Sparks wrote:

 Hi Adrian,

 Yes, it was the missing clojars deployment. 1.8.0 is up there now. 1.7.0 
 doesn't have the map representation, which I added to the existing 
 vector-of-vectors syntax and moved the README examples to. Please try now.

 Regards,

 Malcolm


 On 1 January 2014 20:06, Adrian Mowat adrian...@gmail.com 
 javascript:wrote:

 Hi Malcolm,

 I'm working through the examples and I am getting exceptions when I try 
 defining multiple routes.  I noticed the 1.8.0 is mentioned in the docs but 
 the highest version on clojars is 1.7.0.  Is clojars up to date.

 Stacktraces as follows

 user= (def routes [/ {index.html :index
   #_= articles/ {index.html :article-index
   #_=  article.html :article}}])
 #'user/routes
 user= (match-route routes /index.html)

 java.lang.IllegalArgumentException: No implementation of method: 
 :resolve-handler of protocol: #'bidi.bidi/Matched found for class: 
 clojure.lang.PersistentHashMap
   
  clojure.core/-cache-protocol-fn core_deftype.clj:  541
   
  bidi.bidi/eval3017/fn/G bidi.clj:   87
   
 bidi.bidi/match-pair bidi.clj:   97
 
  bidi.bidi/match-route bidi.clj:  193
 
 clojure.lang.RestFn.invoke  RestFn.java:  425
   
 user$eval3329.invoke   NO_SOURCE_FILE:1
 user= 
 clojure.lang.Compiler.evalCompiler.java: 6619
 
 clojure.lang.Compiler.evalCompiler.java: 6582
 
  clojure.core/eval core.clj: 2852
   
 clojure.main/repl/read-eval-print/fn main.clj:  259
 
  clojure.main/repl/read-eval-print main.clj:  259
   
 clojure.main/repl/fn main.clj:  277
 
  clojure.main/repl main.clj:  277
 
 clojure.lang.RestFn.invoke  RestFn.java: 1096
 
  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn   
 interruptible_eval.clj:   56
 
 clojure.lang.AFn.applyToHelper AFn.java:  159
   
 clojure.lang.AFn.applyTo AFn.java:  151
 
 clojure.core/apply core.clj:  617
   
  clojure.core/with-bindings* core.clj: 1788
 
 clojure.lang.RestFn.invoke  RestFn.java:  425
 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate   
 interruptible_eval.clj:   41
 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn 
   interruptible_eval.clj:  171
   
 clojure.core/comp/fn core.clj: 2330
 
  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn   
 interruptible_eval.clj:  138
   
 clojure.lang.AFn.run AFn.java:   24
 
  java.util.concurrent.ThreadPoolExecutor.runWorker 
  ThreadPoolExecutor.java: 1110
 
 java.util.concurrent.ThreadPoolExecutor$Worker.run 
  ThreadPoolExecutor.java:  603
   
 java.lang.Thread.run  Thread.java:  722
 (match-

 user= 

 user= (path-for routes :index)

 java.lang.IllegalArgumentException: No implementation of method: 
 :unresolve-handler of protocol: #'bidi.bidi/Matched found for class: 
 clojure.lang.PersistentHashMap
   
  clojure.core/-cache-protocol-fn core_deftype.clj:  541
   
  bidi.bidi/eval3017/fn/G bidi.clj:   87
 
 bidi.bidi/unmatch-pair bidi.clj:  149
 
 bidi.bidi/path-for bidi.clj:  201
 
 clojure.lang.RestFn.invoke  RestFn.java:  425
  

Re: core.async - extracting code from a go block

2014-01-01 Thread Paul Butcher
Thanks all - I appreciate the thoughts.

--
paul.butcher-msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher




On 1 Jan 2014, at 05:46, Timothy Baldridge tbaldri...@gmail.com wrote:

 A few other things that might help:
 
 1) you can use (put! c val) from inside any function. Sometimes if you want 
 to fire and forget a send, that might be the best option
 
 2) you can wrap the code inside the sub fns inside another go. This isn't as 
 slow as you might think 
 
 3) think about using core.async's higher order ops like map, filter, mux, 
 pub, mix, etc. 
 
 Often I've found that by rethinking the problem a bit in therms of these 
 ideas, it's possible to simplify the go blocks a bit. 
 
 Timothy
 
 
 On Tue, Dec 31, 2013 at 7:14 PM, Cedric Greevey cgree...@gmail.com wrote:
 It should work if it's inlined or a macro. It won't shrink foo's generated 
 code size any if bar is a macro, but it will split up the source code into 
 smaller pieces if that's all you're concerned about.
 
 
 On Tue, Dec 31, 2013 at 8:50 PM, Paul Butcher p...@paulbutcher.com wrote:
 I recently discovered that parking calls only work if they're directly 
 contained within a go block. So this works fine:
 
 (defn foo [ch]
   (go
 (! ch)))
 
 But this:
 
 (defn bar [ch]
   (! ch))
 
 (defn foo [ch]
   (go
 (bar ch)))
 
 Results in Assert failed: ! used not in (go ...) block
 
 Is there any way around this? If I have a go block that's getting too big and 
 want to extract some portion of it into a separate function, what's the best 
 approach?
 
 --
 paul.butcher-msgCount++
 
 Silverstone, Brands Hatch, Donington Park...
 Who says I have a one track mind?
 
 http://www.paulbutcher.com/
 LinkedIn: http://www.linkedin.com/in/paulbutcher
 Skype: paulrabutcher
 
 
 
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and 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.
 
 
 
 -- 
 “One of the main causes of the fall of the Roman Empire was that–lacking 
 zero–they had no way to indicate successful termination of their C programs.”
 (Robert Firth)
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

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


[Job Spam] Write Clojure at Rally Software in Boulder, Colorado

2014-01-01 Thread Chris Perkins
Rally Software is hiring.

Rally is a SAAS provider of web-based agile project-management software. 
Over the past couple of years, we have been writing many of our back-end 
services in Clojure. You should come and work here.

The team I work on does infrastructure projects, dealing with things like 
authentication, data storage, and real-time messaging. We spend our days 
pairing in Emacs (sometimes remotely via tmux), solving real-world problems 
(like performance, scalability, and security), discussing and designing 
solutions, and occasionally watching clips from bad 80's movies on the 
projector. There are six developers on our team now, but we have more work 
than we can handle - that's why we need you.

We are looking for experienced polygot developers. Beyond that, I won't 
waste your time with a laundry-list of technical requirements. As always, a 
link you your github can help a lot (but is not required).

Rally is hiring in several locations (see the link, below), but working on 
an all-Clojure team currently requires relocating to beautiful Boulder 
Colorado, which is a great city and is no longer under water, I swear.

Here is an official link - it doesn't mention Clojure yet, but does a good 
job of selling you on the many benefits of working here:  
https://www.rallydev.com/careers/open-positions


Feel free to email me off-list with questions, or send me your resume and 
I'll get it into the right hands.


- Chris Perkins
chrisperkin...@gmail.com

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


Re: Storing data on web server with Clojure

2014-01-01 Thread Sean Corfield
I'd say it's really about how you want to interact with the data. If
your pattern of interaction suits a database, use one. If you just
want to store / load data structures and do everything in memory, do
that instead.

I use MySQL and MongoDB extensively via Clojure for a complex Internet
dating platform so I'm pretty comfortable using databases with
Clojure. Disclosure: I maintain Clojure's java.jdbc contrib library
and I'm the primary committer on CongoMongo, a Clojure wrapper for
MongoDB, so I'm probably more inclined toward those solutions than
other Clojurians might be :)

Sean

On Wed, Jan 1, 2014 at 1:07 AM, curiousGuy andrew...@gmail.com wrote:
 I recently got started with Heroku and Clojure. They provide an optional SQL
 database for handling data, but it is not enabled by default. I'm wondering
 how much sense it makes to use SQL on a Clojure environment, vs just using
 sequence types within the language to store data and backing them up as
 writes out to a file, then reading them back in when necessary? I suppose
 for very large data stores, this is not ideal as you'd have a lot of data in
 memory.

 I'm coming from a PHP/MySQL background and am quite new to Clojure so I
 don't want to shoot myself in the foot by quickly adopting old habits rather
 than embracing more idiomatic approaches. Any advice, or anyone actively
 using data in the cloud with Clojure care to comment?

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



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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


Auto updating Leiningen dependencies?

2014-01-01 Thread gvim
Is there are a way to auto-update project.clj dependencies in Leiningen 
or configure them to simply use the latest stable version? I'm also 
finding `lein search dep` pretty useless for quickly getting a dep's 
latest version when it returns 39 pages for clojure itself, starting 
with the oldest version.


gvim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


ANN - New podcast Functional Geekery

2014-01-01 Thread Steven Proctor
I am doing a new podcast Functional Geekery, with the goal to cover topics 
across multiple languages, Clojure included.  I am announcing it here, as 
Clojure was the language that got me to dig deeper into functional 
programming.

The site can be found here: http://www.functionalgeekery.com/ and the first 
episode is posted.  I am working on getting the feed in iTunes and the Zune 
Music Marketplace, but it should be in those soon.

If you have any suggestions or topics for the show, I would love to hear 
you feedback.

Thanks!
--Proctor

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


Future of performant software: cores or memory?

2014-01-01 Thread Mark P
I have watched a number of clojure talks where the concurrent programming 
benefits of Clojure are emphasized.  People have suggested that the number 
of cores in computers is growing with an exponential trend.  Software 
developers will need programming techniques (eg immutable functional 
programing) which allow full harnessing of this.  Software that doesn't 
utilize the cores will not perform well and will be left behind.

But I have heard counter arguments to this view of the future...

   1. The number of cores isn't growing very fast.
  - There isn't much demand for more cores, so this growth will be very 
  slow for most computer devices.
  2. Memory performance is the key at this time.
  - Whereas raw CPU speed previously was growing dramatically for many 
  years, this has never been true for memory speed.  As a result, memory 
  access accounts for a high percentage of execution time in modern 
software.
  - The key to writing performant software at this time (and for many 
  years to come) is to concentrate primarily on good memory performance. 
   This means...
 - Keep memory footprint of programs small.
 - Use various techniques to minimize cache misses.
  - I have heard claims that dramatic program performance improvements 
  may be achieved by concentrating on these memory considerations.
  - It is claimed that for the next 5 or 10 years, there will be much 
  more performance yield to be had by concentrating on memory 
optimizations, 
  than to concentrate on growth in the number of CPU cores for performance.
  - Yes utilize the multiple cores where appropriate, but only in 
  simple ways.  More focus should be given to performant memory usage 
within 
  each thread, than worrying about deeply entwined multi-threaded 
programming.
  - Languages like C/C++ allow for good memory optimizations much 
  better than Java.  And in Clojure, it sounds like it is harder again.
   
There is a lot that I like about Clojure, but is it unsuitable for software 
where performance will be important into the future?

Or will the increase in multi-core capabilities soon mean that memory 
performance limitations pale into insignificance compared with the 
computational gains achieved through Clojure techniques for effectively 
utilizing many cores?

Or is it possible to improve memory performance (eg reduce cache misses) 
within Clojure?

Thanks,

Mark P.

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

2014-01-01 Thread Sean Corfield
Perhaps lein-ancient would be more useful, at least in identifying
when there are more recent versions available?

https://github.com/xsc/lein-ancient

On Wed, Jan 1, 2014 at 4:28 PM, gvim gvi...@gmail.com wrote:
 Is there are a way to auto-update project.clj dependencies in Leiningen or
 configure them to simply use the latest stable version? I'm also finding
 `lein search dep` pretty useless for quickly getting a dep's latest
 version when it returns 39 pages for clojure itself, starting with the
 oldest version.

 gvim

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



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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


Re: Future of performant software: cores or memory?

2014-01-01 Thread Gary Trakhman
It depends on your workload and use-cases, and you could fill many
textbooks with a discussion of the tradeoffs, but I can think of some rules
of thumb that point in clojure's favor.

The most essential metric for me to see has been Amdahl's Law:
http://en.wikipedia.org/wiki/File:AmdahlsLaw.svg

To summarize it, The speedup of a program using multiple processors in
parallel computing is limited by the time needed for the sequential
fraction of the program.

My observation is that 'the program' can be replaced by 'the system'.
 Memory and cpu are sort of like space/time duality, but not 100% either
way, since you can see with caches and latency that memory usage has time
implications, and cpu performance relies on registers and things.

For example, in a shared memory system, the parallelization of the cache
coherence protocol of the hardware can dominate performance aspects of your
software once your software's 'good enough', thus I'd argue the protocol
itself becomes part of the 'sequential fraction' of the system and program
and subject to Amdahl's law.

When this sort of thing happens often enough, programmers write code that
takes away control from this aspect of the system and does things manually,
since the programmers have better knowledge of the system than the CPU or
compiler ever will.  Switching to a message-passing algorithm might be the
way to do it in this case, manually overriding data sent between cores,
accepting the overhead of data copies and such along the way.

Consider core.async, I think it's a great example of a thread scheduler and
set of abstractions to overcome the limitations of OS-provided threads,
schedulers, the control offered by them, and the backlash against code
written to them.  It's useful because the scenarios it addresses are common
enough now that we need to give ourselves back the control that was taken
away by OS's in the first place.

Core.async is implemented by thread-pools, which I can consider a
subsection and delineation of a common set of resources for a specific
usage, similarly it's common in game-dev and I imagine other fields to use
memory-pools to offer predictable or better performance and things like
instrumentation.

But, I would argue that the greatest hindrance to writing the systems we
want is actually programmer productivity.  Taken to an extreme, why
wouldn't we write our own OS's and kernels on bare-metal, in ASM or C every
time instead of re-using anything?  It's because the tradeoffs that are
offered by reusing different subsystems are well-understood and convenient,
or anything else is impractical/impossible.

By picking C++ over Clojure/Java for these reasons you're effectively
saying (which might be true) that the difficulty of optimization and the
need for manual control is more important than all of the benefits(minus
drawbacks) afforded by a higher-level system.

So, it's possible to improve memory-locality in clojure and java, people do
it all the time.  The java memory model is not a giant leap away from
x86/64 and there are ways to avoid being subject to the garbage collector
if you want it.

This blog is a great resource: http://mechanical-sympathy.blogspot.com/

I think clojure's value-add in the big-picture of performance and
parallelism is effective high-level coding, at-least-as-good-as-java
low-level coding, and the ease of traversing those abstraction levels in a
unified way.

By default, you're getting immutable and functional code and the
implications of clojure's relative ease/difficulty tradeoffs.


On Wed, Jan 1, 2014 at 8:59 PM, Mark P pierh...@gmail.com wrote:

 I have watched a number of clojure talks where the concurrent programming
 benefits of Clojure are emphasized.  People have suggested that the number
 of cores in computers is growing with an exponential trend.  Software
 developers will need programming techniques (eg immutable functional
 programing) which allow full harnessing of this.  Software that doesn't
 utilize the cores will not perform well and will be left behind.

 But I have heard counter arguments to this view of the future...

1. The number of cores isn't growing very fast.
   - There isn't much demand for more cores, so this growth will be
   very slow for most computer devices.
   2. Memory performance is the key at this time.
   - Whereas raw CPU speed previously was growing dramatically for
   many years, this has never been true for memory speed.  As a result, 
 memory
   access accounts for a high percentage of execution time in modern 
 software.
   - The key to writing performant software at this time (and for many
   years to come) is to concentrate primarily on good memory performance.
This means...
  - Keep memory footprint of programs small.
  - Use various techniques to minimize cache misses.
   - I have heard claims that dramatic program performance
   improvements may be achieved by concentrating on these memory
  

Re: Auto updating Leiningen dependencies?

2014-01-01 Thread gvim

On 02/01/2014 02:31, Sean Corfield wrote:

Perhaps lein-ancient would be more useful, at least in identifying
when there are more recent versions available?

https://github.com/xsc/lein-ancient


Perfect. Thanks.

gvim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: ANN - New podcast Functional Geekery

2014-01-01 Thread Magnar Sveen
Looks great! Please post here when the feed is available in iTunes.

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