Re: Flow control in Clojure

[Juan A. Ruz @tangrammer]

Hi Ditlev, 
I was struggling with same flow-control logic and I reached to this (alpha) 
solution based in describing logic flows
https://github.com/DEEP-IMPACT-AG/flowgic

so far It worked fine in my current code and i think that it also answers 
the 2 points that Daniel Compton mentioned 

>  1) decompose functions into smaller functions, regardless of these helper 
> functions being of no use anywhere else.
>  2) define a bunch of helper functions in a top-level let-expression - 
> again to avoid having functions which are too heavily indented?


Cheers!


El martes, 8 de diciembre de 2015, 21:18:18 (UTC+1), Ditlev Tøjner escribió:
>
> In designing our (by now) two clojure-based REST services we are 
> struggling with managing flow-control.
>
> (Disclaimer: earlier backgrounds are with Python, C, Javascript and once 
> upon a time Java/C# etc)
>
> What we'd like is to accomplish a series of steps which we feel are 
> universal to REST-services.
> In the context of PUT/POST that is:
> ---
> 1. ensure that the content is of a given format (application/json)
>
> 2. receive & validate input
> 2a. if the input is invalid, return error output (in our case describing 
> what went wrong)
>
> 3. create a new entry / update an existing entry
> (Note if you know the entire URI, then using PUT for both 
> updating/creating is acceptable)
>
> 4. format a response (typically containing the created/updated object)
> ---
>
> Fig1 details how, after several passes, we're dealing with this. The 
> approach is heavily inspired
> by Ref1 and essentially executes each step outlined above with the 
> understanding that failure might
> occur. If a failure occurs, an error message is returned (of course).
>
> We chose an approach similar to Ref1 because we wanted to abort on errors, 
> occasionally recover
> (such as update becoming create if no record is found) and we wanted 
> detailed errors which
> precludes the use of (and ...).
>
> The astute observer may note that our model fails to capture the concept 
> of recoverable failures
> - update-record* may fail for more reasons than simply not having a row 
> (transient errors, actual
> logic-related errors etc) some of which are non-recoverable. 
>
> As it stands, this means the function needs refactoring, *again*. 
> What all this boils down to is this: given the unique interplay of 
> immutability with LISP-style
> (AST) syntax - which techniques are successfully employed to avoid heavily 
> indented code ? Is
> the only solution really to either:
>
> 1) decompose functions into smaller functions, regardless of
> these helper functions being of no use anywhere else.
>
> 2) define a bunch of helper functions in a top-level let-expression - 
> again to avoid having
>functions which are too heavily indented?
>
>
> Does it ever get easier ? Are we missing something ? It seems extreme to 
> reach for monads for
> something of this nature.
>
> References
> 1. https://brehaut.net/blog/2011/error_monads (Ref1)
>
> Fig. 1. - a PUT endpoint
> 
> (defn update*
>   "create/update a pin."
>   [cid source rq]
>   (err/attempt-all
>[_ (chk/mediatype-in? (get rq :content-type) ["application/json"])
> rq (clojure.walk/keywordize-keys rq)
> ;; data which can come from the user
> input (merge {:method "app"
>   :seen_at (-> (at/now-utc) (at/->dt-utc-str))}
>  (get rq :body)
>  {:source_type (get source :type) :source_id (get source :
> id)})
> _ (av/input-valid? validate-pin-params input)
>
>
> ;; additional data extracted from URI & token
> record-data (merge input
>{:cid cid
> :uid (rq->uid* rq)})
> record (err/any (update-record* record-data)
> (new-record* record-data))]
>;; Success
>(rsp/created
> (url cid source)
> {:key-name "pinid"
>  :body {:request (model/transform record)}})
>;; Failure
>err/handle-failure))
>
> 
>

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

[ANN] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth

[Michał Marczyk]

Hi,

I am pleased to announce the 0.0.13 release of data.avl, a Clojure
Contrib library providing highly performant drop-in replacements for
Clojure(Script)'s built-in sorted maps and sets with the following
headline features:

 0. performance often superior to the built-ins (owing to the smaller
height of AVL trees), see end of this email for some benchmarks

 1. logarithmic-time slicing and splits:

(avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
;= [#{0 1 2} 3 #{4 5 6}]

(avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
;= [#{0 1} #{2 3 4 5}]

(avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
;= #{2 3 4}

All returned collections are independent from the originals for GC
purposes (no holding on to out-of-range keys present in the
original collections), all operations run in O(log n) time in
asymptotic terms, and actually fast in real-world terms.

 2. logarithmic-time access by rank and rank queries:

(nth (avl/sorted-set 0 1 2) 1)
;= 1

(avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
;= 2

 3. nearest-neighbour lookups:

(avl/nearest (avl/sorted-set 0 1 2) < 1)
;= 0

The complete clojure.core sorted collections API is also supported, as
is the transient API. See the README for more detailed examples and
feature descriptions.

Fixed in this release:

 1. IMeta and IFn implementations now use correct method names in the
ClojureScript version.

 2. sorted-map/sorted-map-by now throw exceptions if no value is
provided for the final key (in other words, if an odd number of
arguments is passed in) – patch by Andy Fingerhut, thanks!

Changed in this release:

 1. Seqs over data.avl maps now use node objects themselves as map
entries. This is in line with the behaviour of Clojure's built-in
sorted maps. Previously seqs over data.avl maps used
freshly-allocated map entry objects; this had the benefit of not
holding on to subtrees in some scenarios, however not without some
performance and GC pressure cost to regular traversals. Note that
the new behaviour allows the user to rewrap key/value pairs as map
entries if they so choose in a separate map step.

 2. Because of 1., AVL nodes now implement vector and map entry
interfaces.

Cheers,
Michał


;;; A handful of benchmarks

; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)

user> (def ks (range 1))
#'user/ks
user> (def ksks (doall (interleave ks ks)))
#'user/ksks
user> (def m1 (apply sorted-map ksks))
#'user/m1
user> (def m2 (apply avl/sorted-map ksks))
#'user/m2
user> (.tree m1)
[4095 4095]
user> (.getTree m2)
[4095 4095]
user> (let []
(prn :> 0)
(c/quick-bench (get m1 0))
(c/quick-bench (get m2 0))
(prn :> 4095)
(c/quick-bench (get m1 4095))
(c/quick-bench (get m2 4095))
(prn :> )
(c/quick-bench (get m1 ))
(c/quick-bench (get m2 )))
:> 0
WARNING: Final GC required 9.525315094951035 % of runtime
WARNING: Final GC required 88.3127760569387 % of runtime
Evaluation count : 2280474 in 6 samples of 380079 calls.
 Execution time mean : 262.138936 ns
Execution time std-deviation : 56.938518 ns
   Execution time lower quantile : 237.779848 ns ( 2.5%)
   Execution time upper quantile : 360.756510 ns (97.5%)
   Overhead used : 20.503990 ns

Found 1 outliers in 6 samples (16.6667 %)
low-severe 1 (16.6667 %)
 Variance from outliers : 64.2134 % Variance is severely inflated by
outliers
WARNING: Final GC required 78.56747149813818 % of runtime
Evaluation count : 2280498 in 6 samples of 380083 calls.
 Execution time mean : 261.626921 ns
Execution time std-deviation : 42.454179 ns
   Execution time lower quantile : 241.444705 ns ( 2.5%)
   Execution time upper quantile : 335.120524 ns (97.5%)
   Overhead used : 20.503990 ns

Found 1 outliers in 6 samples (16.6667 %)
low-severe 1 (16.6667 %)
 Variance from outliers : 47.5275 % Variance is moderately inflated by
outliers
:> 4095
WARNING: Final GC required 168.0614206986717 % of runtime
Evaluation count : 1056 in 6 samples of 176 calls.
 Execution time mean : 25.939625 ns
Execution time std-deviation : 4.135726 ns
   Execution time lower quantile : 22.648015 ns ( 2.5%)
   Execution time upper quantile : 32.134865 ns (97.5%)
   Overhead used : 20.503990 ns
WARNING: Final GC required 293.8046791844393 % of runtime
Evaluation count : 1056 in 6 samples of 176 calls.
 Execution time mean : 24.609377 ns
Execution time std-deviation : 1.015680 ns
   Execution time lower quantile : 23.720800 ns ( 2.5%)
   Execution time upper quantile : 26.283825 ns (97.5%)
   Overhead used : 20.503990 ns

Found 1 outliers in 6 samples (16.6667 %)
low-severe 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by
outliers
:>>>

Re: In core.match, what's the difference between predicates (:when) and guards (:guard)?

[Hunter Kelly]

Okay, thanks!

On 9 December 2015 at 02:39, David Nolen  wrote:

> core.match will attempt to optimize matching :when clauses in the decision
> tree.
>
> David
>
> On Tue, Dec 8, 2015 at 4:18 PM, retnuH  wrote:
>
>> I can't really figure out what the deal is with predicates.  They're not
>> mentioned in the Basic/Advanced usage wiki pages at all.  The code for
>> Guards and Predicates is basically identical.
>>
>> The only difference that I've been able to find (beyond the spelling,
>> obviously):
>>
>> - predicates can only be symbols, i.e. they can't be function
>> declarations (#() or (fn))
>>
>> - predicates have to be pre-declared with defpred
>>
>> Am I missing something?  Is there some use case that predicates fill that
>> guards don't?
>>
>> Cheers,
>>
>> H
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/6ESXmcPks60/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: [ANN] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth

['Jan-Paul Bultmann' via Clojure]

Very awesome :D!

Cheers, Jan

> On 09 Dec 2015, at 10:39, Michał Marczyk  wrote:
> 
> Hi,
> 
> I am pleased to announce the 0.0.13 release of data.avl, a Clojure
> Contrib library providing highly performant drop-in replacements for
> Clojure(Script)'s built-in sorted maps and sets with the following
> headline features:
> 
>  0. performance often superior to the built-ins (owing to the smaller
> height of AVL trees), see end of this email for some benchmarks
> 
>  1. logarithmic-time slicing and splits:
> 
> (avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1 2} 3 #{4 5 6}]
> 
> (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1} #{2 3 4 5}]
> 
> (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
> ;= #{2 3 4}
> 
> All returned collections are independent from the originals for GC
> purposes (no holding on to out-of-range keys present in the
> original collections), all operations run in O(log n) time in
> asymptotic terms, and actually fast in real-world terms.
> 
>  2. logarithmic-time access by rank and rank queries:
> 
> (nth (avl/sorted-set 0 1 2) 1)
> ;= 1
> 
> (avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
> ;= 2
> 
>  3. nearest-neighbour lookups:
> 
> (avl/nearest (avl/sorted-set 0 1 2) < 1)
> ;= 0
> 
> The complete clojure.core sorted collections API is also supported, as
> is the transient API. See the README for more detailed examples and
> feature descriptions.
> 
> Fixed in this release:
> 
>  1. IMeta and IFn implementations now use correct method names in the
> ClojureScript version.
> 
>  2. sorted-map/sorted-map-by now throw exceptions if no value is
> provided for the final key (in other words, if an odd number of
> arguments is passed in) – patch by Andy Fingerhut, thanks!
> 
> Changed in this release:
> 
>  1. Seqs over data.avl maps now use node objects themselves as map
> entries. This is in line with the behaviour of Clojure's built-in
> sorted maps. Previously seqs over data.avl maps used
> freshly-allocated map entry objects; this had the benefit of not
> holding on to subtrees in some scenarios, however not without some
> performance and GC pressure cost to regular traversals. Note that
> the new behaviour allows the user to rewrap key/value pairs as map
> entries if they so choose in a separate map step.
> 
>  2. Because of 1., AVL nodes now implement vector and map entry
> interfaces.
> 
> Cheers,
> Michał
> 
> 
> ;;; A handful of benchmarks
> 
> ; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)
> 
> user> (def ks (range 1))
> #'user/ks
> user> (def ksks (doall (interleave ks ks)))
> #'user/ksks
> user> (def m1 (apply sorted-map ksks))
> #'user/m1
> user> (def m2 (apply avl/sorted-map ksks))
> #'user/m2
> user> (.tree m1)
> [4095 4095]
> user> (.getTree m2)
> [4095 4095]
> user> (let []
> (prn :> 0)
> (c/quick-bench (get m1 0))
> (c/quick-bench (get m2 0))
> (prn :> 4095)
> (c/quick-bench (get m1 4095))
> (c/quick-bench (get m2 4095))
> (prn :> )
> (c/quick-bench (get m1 ))
> (c/quick-bench (get m2 )))
> :> 0
> WARNING: Final GC required 9.525315094951035 % of runtime
> WARNING: Final GC required 88.3127760569387 % of runtime
> Evaluation count : 2280474 in 6 samples of 380079 calls.
>  Execution time mean : 262.138936 ns
> Execution time std-deviation : 56.938518 ns
>Execution time lower quantile : 237.779848 ns ( 2.5%)
>Execution time upper quantile : 360.756510 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 64.2134 % Variance is severely inflated by outliers
> WARNING: Final GC required 78.56747149813818 % of runtime
> Evaluation count : 2280498 in 6 samples of 380083 calls.
>  Execution time mean : 261.626921 ns
> Execution time std-deviation : 42.454179 ns
>Execution time lower quantile : 241.444705 ns ( 2.5%)
>Execution time upper quantile : 335.120524 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 47.5275 % Variance is moderately inflated by 
> outliers
> :> 4095
> WARNING: Final GC required 168.0614206986717 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>  Execution time mean : 25.939625 ns
> Execution time std-deviation : 4.135726 ns
>Execution time lower quantile : 22.648015 ns ( 2.5%)
>Execution time upper quantile : 32.134865 ns (97.5%)
>Overhead used : 20.503990 ns
> WARNING: Final GC required 293.8046791844393 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>  Execution time mean 

Re: [ANN] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth

[Michał Marczyk]

Just noticed that I forgot to include dependency info and links… Here they
are:

  https://github.com/clojure/data.avl

  [org.clojure/data.avl "0.0.13"]

  
org.clojure
data.avl
0.0.13
  

  compile "org.clojure:data.avl:0.0.13"

Cheers,
Michał


On 9 December 2015 at 10:39, Michał Marczyk 
wrote:

> Hi,
>
> I am pleased to announce the 0.0.13 release of data.avl, a Clojure
> Contrib library providing highly performant drop-in replacements for
> Clojure(Script)'s built-in sorted maps and sets with the following
> headline features:
>
>  0. performance often superior to the built-ins (owing to the smaller
> height of AVL trees), see end of this email for some benchmarks
>
>  1. logarithmic-time slicing and splits:
>
> (avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1 2} 3 #{4 5 6}]
>
> (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1} #{2 3 4 5}]
>
> (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
> ;= #{2 3 4}
>
> All returned collections are independent from the originals for GC
> purposes (no holding on to out-of-range keys present in the
> original collections), all operations run in O(log n) time in
> asymptotic terms, and actually fast in real-world terms.
>
>  2. logarithmic-time access by rank and rank queries:
>
> (nth (avl/sorted-set 0 1 2) 1)
> ;= 1
>
> (avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
> ;= 2
>
>  3. nearest-neighbour lookups:
>
> (avl/nearest (avl/sorted-set 0 1 2) < 1)
> ;= 0
>
> The complete clojure.core sorted collections API is also supported, as
> is the transient API. See the README for more detailed examples and
> feature descriptions.
>
> Fixed in this release:
>
>  1. IMeta and IFn implementations now use correct method names in the
> ClojureScript version.
>
>  2. sorted-map/sorted-map-by now throw exceptions if no value is
> provided for the final key (in other words, if an odd number of
> arguments is passed in) – patch by Andy Fingerhut, thanks!
>
> Changed in this release:
>
>  1. Seqs over data.avl maps now use node objects themselves as map
> entries. This is in line with the behaviour of Clojure's built-in
> sorted maps. Previously seqs over data.avl maps used
> freshly-allocated map entry objects; this had the benefit of not
> holding on to subtrees in some scenarios, however not without some
> performance and GC pressure cost to regular traversals. Note that
> the new behaviour allows the user to rewrap key/value pairs as map
> entries if they so choose in a separate map step.
>
>  2. Because of 1., AVL nodes now implement vector and map entry
> interfaces.
>
> Cheers,
> Michał
>
>
> ;;; A handful of benchmarks
>
> ; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)
>
> user> (def ks (range 1))
> #'user/ks
> user> (def ksks (doall (interleave ks ks)))
> #'user/ksks
> user> (def m1 (apply sorted-map ksks))
> #'user/m1
> user> (def m2 (apply avl/sorted-map ksks))
> #'user/m2
> user> (.tree m1)
> [4095 4095]
> user> (.getTree m2)
> [4095 4095]
> user> (let []
> (prn :> 0)
> (c/quick-bench (get m1 0))
> (c/quick-bench (get m2 0))
> (prn :> 4095)
> (c/quick-bench (get m1 4095))
> (c/quick-bench (get m2 4095))
> (prn :> )
> (c/quick-bench (get m1 ))
> (c/quick-bench (get m2 )))
> :> 0
> WARNING: Final GC required 9.525315094951035 % of runtime
> WARNING: Final GC required 88.3127760569387 % of runtime
> Evaluation count : 2280474 in 6 samples of 380079 calls.
>  Execution time mean : 262.138936 ns
> Execution time std-deviation : 56.938518 ns
>Execution time lower quantile : 237.779848 ns ( 2.5%)
>Execution time upper quantile : 360.756510 ns (97.5%)
>Overhead used : 20.503990 ns
>
> Found 1 outliers in 6 samples (16.6667 %)
> low-severe 1 (16.6667 %)
>  Variance from outliers : 64.2134 % Variance is severely inflated by
> outliers
> WARNING: Final GC required 78.56747149813818 % of runtime
> Evaluation count : 2280498 in 6 samples of 380083 calls.
>  Execution time mean : 261.626921 ns
> Execution time std-deviation : 42.454179 ns
>Execution time lower quantile : 241.444705 ns ( 2.5%)
>Execution time upper quantile : 335.120524 ns (97.5%)
>Overhead used : 20.503990 ns
>
> Found 1 outliers in 6 samples (16.6667 %)
> low-severe 1 (16.6667 %)
>  Variance from outliers : 47.5275 % Variance is moderately inflated by
> outliers
> :> 4095
> WARNING: Final GC required 168.0614206986717 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>  Execution time mean : 25.939625 ns
> Execution time std-deviation : 4.135726 ns
>Execution time lower quantile : 22.648015 ns ( 2.5%)
>Execution time upper quantile : 32.134865 ns (97.5%)
>Overhe

[ANN] cljs-mathbox, wrapper for the MathBox JS lib

[Egg Syntax]

I've just released cljs-mathbox, an idiomatic cljs wrapper around the
MathBox visualization library.

MathBox  is a powerful
library for mathematical (and data) visualization in the browser,
specializing in two- and three-dimensional, animated visualizations, built
on Three.js. cljs-mathbox is a pretty thin wrapper over it.

Feedback and pull requests welcomed. I'm often on the Clojurians slack;
feel free to ask me questions directly or in the recently created #datavis
channel.

on clojars 
on github 
example repo 

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

Re: [ANN] 2015 State of Clojure Community survey

['Matt Bossenbroek' via Clojure]

How about adding a state of Datomic survey? :) 

-Matt


On Sunday, December 6, 2015 at 4:12 PM, Mars0i wrote:

> 
> 
> On Sunday, December 6, 2015 at 3:26:55 PM UTC-6, Lee wrote:
> > 
> > On Dec 6, 2015, at 3:00 PM, Alex Miller  > (javascript:)> wrote: 
> > 
> > > Almost all of the questions are optional - if they don't apply to your 
> > > scenario, you should skip the question.
> > 
> > 
> > FWIW if I recall correctly (it won't let me back in to check the questions 
> > now that I finished it) I think that some questions sort of apply but use 
> > terminology that implies an industrial context (like "in production"). Not 
> > a big deal but a bit confusing, and maybe if we want to encourage use in 
> > education and research these could be tweaked. 
> 
> I agree with Lee.  It's not that there are missing questions. It's that in 
> some cases I have an answer to the question, but it's not one of the options; 
> all of the options presume that we're doing certain sorts of things, which 
> are common in business.  Someone doing data manipulation and analysis for 
> scientific research may be doing a lot of coding that doesn't leave one or 
> two machines.  Likewise for scientific simulations.  These uses may not be 
> part an ongoing process--they're not used to run a business, or a website, or 
> anything like that.  You write something, do a lot with it, then move on to 
> something else.  Or come back and modify it for a related research project.  
> Clojure's a great language for that sort of thing.
> 
> I'd be happy to go through the survey and suggest a few things to add or 
> change if that would be helpful.  Lee's suggested additional questions seem 
> worthwhile, too.  I agree that some thought would have to be put into 
> formulating them.
>  
> > > 
> > > What question would be useful to add re use in academia? 
> > 
> > I'd personally be interested in knowing how many people are using Clojure 
> > for computer science courses, and which ones. Also, how many people are 
> > using Clojure for research, and in what fields. Also, what tools (e.g. 
> > IDEs, books, websites) are people using, and what do they think is missing, 
> > for research and education purposes. 
> > 
> > I'm not sure how best to phrase survey questions for these issues. 
> > 
> >  -Lee
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> (mailto:clojure@googlegroups.com)
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> (mailto:clojure+unsubscr...@googlegroups.com).
> For more options, visit https://groups.google.com/d/optout.

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

[Mars0i]

Another use case, fwiw:

(def my-atom
  (let [...
 
 ...]
(atom ...)))

A special naming convention for (e.g.) atoms makes it clear that what's 
below the many lines of let bindings (and maybe comment lines, too) is 
going to produce an atom; you don't have to read down and find the one line 
that contains '(atom'.

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

Re: [ANN] Clojure 1.8.0-RC3

[Michael Blume]

No issues here.

On Tue, Dec 8, 2015 at 5:39 PM James Elliott  wrote:

> I’ve been working with it for a few days and have seen no issues yet.
>
>
> On Wednesday, December 2, 2015 at 10:03:31 AM UTC-6, Alex Miller wrote:
>
>> Clojure 1.8.0-RC3 is now available. *This build is a "release
>> candidate"!* We would appreciate any and all testing you can do on your
>> own libraries or internal projects to find problems.
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>>- Leiningen: [org.clojure/clojure "1.8.0-RC3"]
>>
>> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1845  / CLJ-1851
>> New ^:redef to mark
>>vars that should not be direct linked
>>   - The metadata ^:redef can be used to mark function vars that
>>   should not be direct linked
>>   - clojure.core/load was previously marked with ^:dynamic for this
>>   purpose, but is now marked ^:redef
>>- CLJ-1856  Direct
>>linking breaks clojure.test location reporting for failures
>>- CLJ-1854  Set line
>>number in bytecode prior to invokeStatic call
>>- CLJ-1853  In socket
>>server, require the ns of the accept-fn before resolving 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/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.