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

[Bruce Durling]

Jony,

It is being introduced into what was the intro to OO course.

cheers,
Bruce

On Fri, Oct 10, 2014 at 11:27 PM, Jony Hudson  wrote:
> If this is the unofficial survey post of academics using Clojure then I'd
> better add myself to the list :-)
>
> @Bruce do you know what course they're going to be teaching Clojure on at
> Birkbeck?
>
>
> Jony
>
>
> On Friday, 10 October 2014 08:08:28 UTC+1, Bruce Durling wrote:
>>
>> I also know that Birkbeck College University of London is going to be
>> teaching Clojure this year.
>>
>> On Oct 10, 2014 12:01 AM, "Lee Spector"  wrote:
>>>
>>>
>>> FWIW I'm another person using Clojure mostly for academic research. And
>>> for computer science education, e.g. I'm currently teaching a Clojure-based
>>> AI course. I'd be curious to know how many others of us are out there. And
>>> BTW I think that attention to users in these categories could help to grow
>>> the community.
>>>
>>>  -Lee
>>>
>>> On Oct 9, 2014, at 12:32 AM, Mars0i  wrote:
>>>
>>> > Thanks for the survey!
>>> >
>>> > I have a couple of suggestions/questions:
>>> >
>>> > For domains, there are no categories for scientific or other research
>>> > applications.  For example, I mainly use Clojure for writing agent-based
>>> > models for academic research.  Would a set of categories in this area be
>>> > usedful?
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[Atamert Ölçgen]

Dear Clojurians,


>  Inclusion of such questions on the survey would be another opportunity
> for Clojure to be more than just not unwelcoming to atypical folks and
> allow us to purposefully invite more people to this relative paradise we
> inhabit.


I would simply not fill the survey. Because what does my age or gender or
race have to do with a programming language.

There is nothing stopping the atypical folks from grabbing a REPL and
typing away some code.



On Wed, Oct 15, 2014 at 3:33 PM, Bruce Durling  wrote:

> Jony,
>
> It is being introduced into what was the intro to OO course.
>
> cheers,
> Bruce
>
> On Fri, Oct 10, 2014 at 11:27 PM, Jony Hudson 
> wrote:
> > If this is the unofficial survey post of academics using Clojure then I'd
> > better add myself to the list :-)
> >
> > @Bruce do you know what course they're going to be teaching Clojure on at
> > Birkbeck?
> >
> >
> > Jony
> >
> >
> > On Friday, 10 October 2014 08:08:28 UTC+1, Bruce Durling wrote:
> >>
> >> I also know that Birkbeck College University of London is going to be
> >> teaching Clojure this year.
> >>
> >> On Oct 10, 2014 12:01 AM, "Lee Spector"  wrote:
> >>>
> >>>
> >>> FWIW I'm another person using Clojure mostly for academic research. And
> >>> for computer science education, e.g. I'm currently teaching a
> Clojure-based
> >>> AI course. I'd be curious to know how many others of us are out there.
> And
> >>> BTW I think that attention to users in these categories could help to
> grow
> >>> the community.
> >>>
> >>>  -Lee
> >>>
> >>> On Oct 9, 2014, at 12:32 AM, Mars0i  wrote:
> >>>
> >>> > Thanks for the survey!
> >>> >
> >>> > I have a couple of suggestions/questions:
> >>> >
> >>> > For domains, there are no categories for scientific or other research
> >>> > applications.  For example, I mainly use Clojure for writing
> agent-based
> >>> > models for academic research.  Would a set of categories in this
> area be
> >>> > usedful?
> >>> >
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Clojure" group.
> >>> To post to this group, send email to clo...@googlegroups.com
> >>> Note that posts from new members are moderated - please be patient with
> >>> your first post.
> >>> To unsubscribe from this group, send email to
> >>> clojure+u...@googlegroups.com
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/clojure?hl=en
> >>> ---
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "Clojure" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to clojure+u...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

Code clinic: Idiomatic and performance; finding the closest match of words in two phases independent of order

[Yu Shen]

In the following code, I'm struggling to be idiomatic and at the same time 
to consider save times of iterations. I sometimes find it conflicts between 
the two objectives of expressiveness and performance, for example, in order 
to save time of iterations over a sequence, I have to use (loop, and recur) 
a lot, but for readability and expressiveness, some of such loop structure 
could be more elegantly expressed as list expressions of filters, etc. 

I'd like to seek your advise, whether my following code could be improved 
in both purposes?

Thanks a lot for your help!

Yu Shen 


(ns dw-pos-study.pairwise-match
  (:use incanter.stats)
  (:use utils-yushen.util)
  (:use clojure.test))


;; This package tries to find the most likely match between words 
independent of order in two phrases. 
;; Care is taken to be efficient in order to support plausible approximate 
match of names between users' text nad a database. 


(defn switch [[x y]]
  [y x])


(defn pairwise-distances-sorted
  "Returns sorted the pairwise distance between words of search and 
candidate in increasing distance order.
  The keyword parameter perfect-match is used to control how strict two 
words are considered to be perfect match.
  By default, it's 0, thus identical words are perfect match. Relax the 
degree for perfect match may reduce the number of pairwise distances, and 
the sorting them."


  [search candidate & {:keys [perfect-match] :or {perfect-match 0 }}]


  (->>
   (loop [pairs (for [x search y candidate] [x y])
  distance-map {}]
 (if (empty? pairs)
   distance-map
   (let [pair (first pairs)]
(cond
(get distance-map pair) (recur (rest pairs) distance-map)
(get distance-map (switch pair)) (recur (rest pairs) (merge 
distance-map {pair (get distance-map (switch pair))}))
:else (let [distance (apply incanter.stats/levenshtein-distance 
pair)
relative-distance (/ distance (apply max (map count 
pair))) ; use relative distance to allow comparable tolerance in 
determining prefect match across different pair.
; the maximum length of the words in pair is the 
maximum of the distance possible for the pair.
perfect-match? (<= relative-distance perfect-match) ; 
try to optimize when there is perfect match found
]
(recur (if perfect-match? (filter (fn [[x y]] (and (not= x 
(first pair)) (not= y (second pair (rest pairs)) (rest pairs)) ; 
further reduce the search space of pairwise distances.
   (merge distance-map {pair distance})))
   (into [], ) ; use sequence, as map's order is not satble
   (sort-by second, )))


;; Copided from 
http://programming-puzzler.blogspot.com/2010/07/translating-code-from-python-and-scheme.html
 
thanks to mbAugust 2, 2010 at 10:59 PM
(defn remove-first
  [item coll]
  (lazy-seq
(when-let [s (seq coll)] ; use when-let, it automatically takes care of 
returning nil when there are no more items in the sequence.
  ; caching of the result of the seq call is that you save one level of 
indirection for any following first, next or rest call.
  (let [fst (first s)]
(if (= fst item)
  (next s)
  (cons fst (remove-first item (rest coll


(defn matched-closest
  "Find the closest matches of words between search and candidate 
independent of word order, returning the matches, and the residual of not 
matching.
  The match data contains the matched word pair, the levenshtein distance 
between them, and the maximum of word lengths of the words in the pair,
  which serves as the context to tell how significant the distance is.
  The keyword parameter perfect-match is used to control how strict two 
words are considered to be perfect match.
  By default, it's 0, thus identical words are perfect match."


  [search candidate & {:keys [perfect-match] :or {perfect-match 0}}]


  (let [word-distances-sorted (pairwise-distances-sorted search candidate 
:perfect-match perfect-match)]
(loop [matched []
   filtered word-distances-sorted
   [not-matched-search not-matched-candidate] [search candidate]]
  (if (empty? filtered)
[matched [not-matched-search not-matched-candidate]]
(let [[[a b] d] (first filtered)
  matched-updated (conj matched [[a b] d (max (count a) (count 
b))])
  ; remove any element with key containing a or b in their 
respective position, as [a b] is already considered, there is no point to 
cornsider them anymore.
  filtered-updated (filter (fn [[[x y] _]] (and (not= a x) 
(not= b y)))
   filtered)]
  (recur matched-updated
 filtered-updated
 [(remove-first a not-matched-search) (remove-first b 
not-matched-candidate)]))


(is (matched-closest (clojure.string/split "garbage real stuff" #"\s") 
(clojure.string/split "real stuff" #"\s")) 

Re: Code clinic: Idiomatic and performance; finding the closest match of words in two phases independent of order

[Yu Shen]

Here is the link to the gist for the 
code https://gist.github.com/yubrshen/63ffda973aff27d39868

On Wednesday, October 15, 2014 4:12:56 PM UTC+8, Yu Shen wrote:
>
> In the following code, I'm struggling to be idiomatic and at the same time 
> to consider save times of iterations. I sometimes find it conflicts between 
> the two objectives of expressiveness and performance, for example, in order 
> to save time of iterations over a sequence, I have to use (loop, and recur) 
> a lot, but for readability and expressiveness, some of such loop structure 
> could be more elegantly expressed as list expressions of filters, etc. 
>
> I'd like to seek your advise, whether my following code could be improved 
> in both purposes?
>
> Thanks a lot for your help!
>
> Yu Shen 
>
>
> (ns dw-pos-study.pairwise-match
>   (:use incanter.stats)
>   (:use utils-yushen.util)
>   (:use clojure.test))
>
>
> ;; This package tries to find the most likely match between words 
> independent of order in two phrases. 
> ;; Care is taken to be efficient in order to support plausible 
> approximate match of names between users' text nad a database. 
>
>
> (defn switch [[x y]]
>   [y x])
>
>
> (defn pairwise-distances-sorted
>   "Returns sorted the pairwise distance between words of search and 
> candidate in increasing distance order.
>   The keyword parameter perfect-match is used to control how strict two 
> words are considered to be perfect match.
>   By default, it's 0, thus identical words are perfect match. Relax the 
> degree for perfect match may reduce the number of pairwise distances, and 
> the sorting them."
>
>
>   [search candidate & {:keys [perfect-match] :or {perfect-match 0 }}]
>
>
>   (->>
>(loop [pairs (for [x search y candidate] [x y])
>   distance-map {}]
>  (if (empty? pairs)
>distance-map
>(let [pair (first pairs)]
> (cond
> (get distance-map pair) (recur (rest pairs) distance-map)
> (get distance-map (switch pair)) (recur (rest pairs) (merge 
> distance-map {pair (get distance-map (switch pair))}))
> :else (let [distance (apply incanter.stats/levenshtein-distance 
> pair)
> relative-distance (/ distance (apply max (map count 
> pair))) ; use relative distance to allow comparable tolerance in 
> determining prefect match across different pair.
> ; the maximum length of the words in pair is the 
> maximum of the distance possible for the pair.
> perfect-match? (<= relative-distance perfect-match) ; 
> try to optimize when there is perfect match found
> ]
> (recur (if perfect-match? (filter (fn [[x y]] (and (not= x 
> (first pair)) (not= y (second pair (rest pairs)) (rest pairs)) ; 
> further reduce the search space of pairwise distances.
>(merge distance-map {pair distance})))
>(into [], ) ; use sequence, as map's order is not satble
>(sort-by second, )))
>
>
> ;; Copided from 
> http://programming-puzzler.blogspot.com/2010/07/translating-code-from-python-and-scheme.html
>  
> thanks to mbAugust 2, 2010 at 10:59 PM
> (defn remove-first
>   [item coll]
>   (lazy-seq
> (when-let [s (seq coll)] ; use when-let, it automatically takes care 
> of returning nil when there are no more items in the sequence.
>   ; caching of the result of the seq call is that you save one level 
> of indirection for any following first, next or rest call.
>   (let [fst (first s)]
> (if (= fst item)
>   (next s)
>   (cons fst (remove-first item (rest coll
>
>
> (defn matched-closest
>   "Find the closest matches of words between search and candidate 
> independent of word order, returning the matches, and the residual of not 
> matching.
>   The match data contains the matched word pair, the levenshtein distance 
> between them, and the maximum of word lengths of the words in the pair,
>   which serves as the context to tell how significant the distance is.
>   The keyword parameter perfect-match is used to control how strict two 
> words are considered to be perfect match.
>   By default, it's 0, thus identical words are perfect match."
>
>
>   [search candidate & {:keys [perfect-match] :or {perfect-match 0}}]
>
>
>   (let [word-distances-sorted (pairwise-distances-sorted search candidate 
> :perfect-match perfect-match)]
> (loop [matched []
>filtered word-distances-sorted
>[not-matched-search not-matched-candidate] [search candidate]]
>   (if (empty? filtered)
> [matched [not-matched-search not-matched-candidate]]
> (let [[[a b] d] (first filtered)
>   matched-updated (conj matched [[a b] d (max (count a) (count 
> b))])
>   ; remove any element with key containing a or b in their 
> respective position, as [a b] is already considered, there is no point to 
> cornsider them anymore.
>   filtered-updated (filter (fn 

Re: Optimizing code : Fun but now paining me

[Baishampayan Ghose]

Can you still tell me what the problem statement is? I saw some
mutation in the earlier code, may be it was for testing. ~BG

On Tue, Oct 14, 2014 at 6:25 PM, Ashish Negi  wrote:
> @BG
>
> Glad to know i am interacting with you :)
> Of course i understand that you are not criticizing me..
>
> I have refactored my code and have made a gist.. that may help.. I have put
> some comments. https://gist.github.com/ashishnegi/a9ae3fb3c270c7d3742e
> please share your comments on that. I am really hoping about finding
> performance points there.
>
> Also for indentation, 1. i am using paredit and emacs and it was doing the
> usual good steps.
> i even tried with 1. C-x h and  C-M-/ 2. M-q 3. C-M-q .. but not much
> difference.
> What do you use for auto indentation ?
>
> I think that my code do not have any mutation. But may be i was doing
> something wrong. Can you tell where was i mutating ?
>
> ** I hope that one understands that i am participating in competitive
> programming so usually things like code indentation and variable naming take
> a back seat..
> but definitely that is not acceptable.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.



-- 
Baishampayan Ghose
b.ghose at gmail.com

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

Re: Optimizing code : Fun but now paining me

[Ashish Negi]

Problem is to evaluate a calculator string containing * / + - and brackets 
like "2+3*(4+2)/2/2" 
and the grammar for this is right associative for operators and precendence 
is as we know : ->unaray, brackets   >*/>+-

Also answer should be in (mod 17) which requires that every 
operation should be done with this mod..

For more detail please see 
https://www.hackerrank.com/contests/lambda-calculi-oct14/challenges/expressions-v2
However, i do NOT want any advantage in problem like some test cases that 
break my existing implementation, or somebody rewriting code for me.
but definitely want advantages with the language like optimization or 
better way to do this task.

Thanks

Here are some of the results and test caes..
   
   (= 1717 (int (first (Expression (make-calulator-list " 22 * 79 - 21")
   
   (= 12 (int (first (Expression (make-calulator-list " 4/2/2 + 8")
   
   (= 4  (int (first (Expression (make-calulator-list "4/-2/2 + 8")

   (= 98605 (int (mod  (first (Expression (make-calulator-list 
"55+3-45*33-25"))) ToMod)))

   (= 99987 (int (mod  (first (Expression (make-calulator-list 
"4/-2/(2+8)"))) ToMod)))
   
   (= 22 (int (first (Expression (make-calulator-list "(22)*+1/-1+(1)")
  
   (= 22 (int (first (Expression (make-calulator-list "11*(2/2)*2")

   (= 11 (int (first (Expression (make-calulator-list "22*2/2*2")

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

Testing existing java code with clojure tests from ant / gradle

[Sven Richter]

Hi,

I have the opportunity to start some clojure here in our office, we are a 
pure java team right now and as I am the only working on this currently I 
would like to run some tests in clojure. Of course, these tests will have 
to test existing java code.
So ideally, what I would like to do is to take existing projects and add 
some unit tests. These existing projects are build with gradle or ant (we 
are switching to gradle, however, our main libs will be built with ant for 
some time). That means that theses tests will have to be run during the 
gradle / ant build.
Additionally, as we are developing in eclipse, the tests also have to be 
part of the existing test suites. Is that possible at all?

Are there any examples out there that do something similar? I would like to 
keep the barrier of using the tests as low as possible (I am not talking 
about the development of the tests). 

Thanks for every comment, hint, whatever,
Sven

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

A proposal for an alternative implementation of clojure.core/transduce

[Daniel James]

Hi All,

I’d like to offer an alternative implementation of clojure.core/transduce.

(I’ve done some searching, and I didn’t find any evidence that this has 
been raised before, but my apologies if I missed anything.)

This alternative is best motivated by example. Consider the following 
transducers:

(defn init-with
  [x]
  (fn [rf]
(fn
  ([] (rf (rf) x))
  ([result] (rf result))
  ([result input]
 (rf result input)

(defn complete-with
  [x]
  (fn [rf]
(fn
  ([] (rf))
  ([result]
 (rf (rf result x)))
  ([result input]
 (rf result input)

(defn dupl
  []
  (fn [rf]
(fn
  ([] (rf))
  ([result] (rf result))
  ([result input]
 (rf (rf result input)
 input)

I have selected these as each illustrate something ‘interesting’ occurring 
in each of the three arities of the reducing functions produced.

Now consider the following transducer, which transforms numeric reducing 
functions.

(def xform (comp
(map inc)
(complete-with 10)
(map inc)
(init-with 100)
(map inc)
(dupl)))

The current behavior of transduce (and into, for illustration purposes) is:

(into [37] xform (range 5))
;=> [37 3 3 4 4 5 5 6 6 7 7 12 12]


(transduce xform + 37 (range 5))
;=> 111

(reduce + (into [37] xform (range 5)))
;=> 111

(transduce xform + (range 5))
;=> 74


So the dupl and complete-with transducers work as I expected, but the 
init-with does not.

What I was hoping for was:

;=> [37 101 101 3 3 4 4 5 5 6 6 7 7 12 12]

;=> 313

;=> 313

;=> 276


This is because transduce and into are currently implemented as something 
equivalent to the following:

(defn curr-transduce
  ([xform f coll]
 (transduce xform f (f) coll))
  ([xform f init coll]
 (let [rf (xform f)]
   (rf (reduce rf init coll)


(defn curr-into
  [to xform from]
  (curr-transduce xform conj to from))

In the first arity of transduce, the initial value is taken from the 
reducing function f, not the reducing function produced by (xform f).
And in the second arity, the supplied initial value is supplied directly to 
the reduction.
These both bypass the transducer xform entirely, so the zeroth-arity is 
never invoked and no transformation occurs.

I would like to propose the following alternative implementation:

(defn alt-transduce
  ([xform f coll]
 (let [rf (xform f)]
   (rf (reduce rf (rf) coll
  ([xform f init coll]
 (let [rf (xform
   (fn
 ([] init)
 ([result] (f result))
 ([result input] (f result input]
   (rf (reduce rf (rf) coll)

In the first arity, the initial value is drawn from the transformed 
reducing function, rather than the supplied reducing function.
In the second arity, a reducing function is constructed from f and init to 
be f in arity 1 and 2, but return init in arity 0.
Both cases ensure that the transducer is used to transform all three 
components of the reduction: init, step, and completion.

Because of the way that the second arity is implemented, into doesn’t need 
to change:

(defn alt-into
  [to xform from]
  (alt-transduce xform conj to from))

The effect is that the reducing function passed to xform is conj, except in 
arity 0, where the `to` collection is returned.

These return the results I was originally expecting:

(alt-into [37] xform (range 5))
;=> [37 101 101 3 3 4 4 5 5 6 6 7 7 12 12]

(reduce + (alt-into [37] xform (range 5)))
;=> 313

(alt-transduce xform + 37 (range 5))
;=> 313

(alt-transduce xform + (range 5))
;=> 276


I went though the list of transducers currently provided in clojure.core 
and none of them do anything ‘interesting’ in zeroth-arity init component, 
so the alternate implementation would not change their observable behavior. 
This only affects transducers that do something other than the trivial 
implementation of the zero-arity. The discussion 
https://groups.google.com/d/topic/clojure/M-13lRPfguc/discussion was the 
only related one I could find.

Thanks,
Dan

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

Re: Testing existing java code with clojure tests from ant / gradle

[henry w]

maybe someone will jump in with all the answers, but in the mean time here 
are some pointers.

if you are using clojure.test, then test-out 
https://github.com/arohner/lein-test-out will format the results so they 
can show up in continuous integration and eclipse as well if you can get 
something in it that reads junit reports.
 - that is a lein plugin of course, so maybe your first task is to make is 
work outside of lein.

i dont have any example code to invoke clojure tests other than from 
lein but is must be straightforward, just have a read of the 'lein 
test' code for starters perhaps.

with cursive for clojure it is easy to run clj tests from the ide (and see 
red/green against the tests in the editor). not sure if the eclipse plugin 
does the same?

as for being a part of existing test suites... i guess a parameterized 
junit test that calls out to clj namespaces to run tests could work.

or...why not just use lein for everything instead! we started pure java and 
getting the build onto lein was the first step for us. if you have some 
crazy baroque ant thing going on and need to keep it there is probably some 
way to do that from lein, just as there is from gradle.

good luck!


On Wednesday, October 15, 2014 1:17:05 PM UTC+1, Sven Richter wrote:
>
> Hi,
>
> I have the opportunity to start some clojure here in our office, we are a 
> pure java team right now and as I am the only working on this currently I 
> would like to run some tests in clojure. Of course, these tests will have 
> to test existing java code.
> So ideally, what I would like to do is to take existing projects and add 
> some unit tests. These existing projects are build with gradle or ant (we 
> are switching to gradle, however, our main libs will be built with ant for 
> some time). That means that theses tests will have to be run during the 
> gradle / ant build.
> Additionally, as we are developing in eclipse, the tests also have to be 
> part of the existing test suites. Is that possible at all?
>
> Are there any examples out there that do something similar? I would like 
> to keep the barrier of using the tests as low as possible (I am not talking 
> about the development of the tests). 
>
> Thanks for every comment, hint, whatever,
> Sven
>

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

Re: A proposal for an alternative implementation of clojure.core/transduce

[Andy Fingerhut]

Dan, I haven't read yours or Christophe Grand's articles thoroughly enough
even to know whether your ideas are similar, but you may be interested to
read this thread, and the blog posts written by Christophe, linked from his
first message in this discussion thread:
https://groups.google.com/forum/#!topic/clojure-dev/cWzMS_qqgcM

On Wed, Oct 15, 2014 at 6:22 AM, Daniel James  wrote:

> Hi All,
>
> I’d like to offer an alternative implementation of clojure.core/transduce.
>
> (I’ve done some searching, and I didn’t find any evidence that this has
> been raised before, but my apologies if I missed anything.)
>
> This alternative is best motivated by example. Consider the following
> transducers:
>
> (defn init-with
>   [x]
>   (fn [rf]
> (fn
>   ([] (rf (rf) x))
>   ([result] (rf result))
>   ([result input]
>  (rf result input)
>
> (defn complete-with
>   [x]
>   (fn [rf]
> (fn
>   ([] (rf))
>   ([result]
>  (rf (rf result x)))
>   ([result input]
>  (rf result input)
>
> (defn dupl
>   []
>   (fn [rf]
> (fn
>   ([] (rf))
>   ([result] (rf result))
>   ([result input]
>  (rf (rf result input)
>  input)
>
> I have selected these as each illustrate something ‘interesting’ occurring
> in each of the three arities of the reducing functions produced.
>
> Now consider the following transducer, which transforms numeric reducing
> functions.
>
> (def xform (comp
> (map inc)
> (complete-with 10)
> (map inc)
> (init-with 100)
> (map inc)
> (dupl)))
>
> The current behavior of transduce (and into, for illustration purposes) is:
>
> (into [37] xform (range 5))
> ;=> [37 3 3 4 4 5 5 6 6 7 7 12 12]
>
>
> (transduce xform + 37 (range 5))
> ;=> 111
>
> (reduce + (into [37] xform (range 5)))
> ;=> 111
>
> (transduce xform + (range 5))
> ;=> 74
>
>
> So the dupl and complete-with transducers work as I expected, but the
> init-with does not.
>
> What I was hoping for was:
>
> ;=> [37 101 101 3 3 4 4 5 5 6 6 7 7 12 12]
>
> ;=> 313
>
> ;=> 313
>
> ;=> 276
>
>
> This is because transduce and into are currently implemented as something
> equivalent to the following:
>
> (defn curr-transduce
>   ([xform f coll]
>  (transduce xform f (f) coll))
>   ([xform f init coll]
>  (let [rf (xform f)]
>(rf (reduce rf init coll)
>
>
> (defn curr-into
>   [to xform from]
>   (curr-transduce xform conj to from))
>
> In the first arity of transduce, the initial value is taken from the
> reducing function f, not the reducing function produced by (xform f).
> And in the second arity, the supplied initial value is supplied directly
> to the reduction.
> These both bypass the transducer xform entirely, so the zeroth-arity is
> never invoked and no transformation occurs.
>
> I would like to propose the following alternative implementation:
>
> (defn alt-transduce
>   ([xform f coll]
>  (let [rf (xform f)]
>(rf (reduce rf (rf) coll
>   ([xform f init coll]
>  (let [rf (xform
>(fn
>  ([] init)
>  ([result] (f result))
>  ([result input] (f result input]
>(rf (reduce rf (rf) coll)
>
> In the first arity, the initial value is drawn from the transformed
> reducing function, rather than the supplied reducing function.
> In the second arity, a reducing function is constructed from f and init to
> be f in arity 1 and 2, but return init in arity 0.
> Both cases ensure that the transducer is used to transform all three
> components of the reduction: init, step, and completion.
>
> Because of the way that the second arity is implemented, into doesn’t need
> to change:
>
> (defn alt-into
>   [to xform from]
>   (alt-transduce xform conj to from))
>
> The effect is that the reducing function passed to xform is conj, except
> in arity 0, where the `to` collection is returned.
>
> These return the results I was originally expecting:
>
> (alt-into [37] xform (range 5))
> ;=> [37 101 101 3 3 4 4 5 5 6 6 7 7 12 12]
>
> (reduce + (alt-into [37] xform (range 5)))
> ;=> 313
>
> (alt-transduce xform + 37 (range 5))
> ;=> 313
>
> (alt-transduce xform + (range 5))
> ;=> 276
>
>
> I went though the list of transducers currently provided in clojure.core
> and none of them do anything ‘interesting’ in zeroth-arity init component,
> so the alternate implementation would not change their observable behavior.
> This only affects transducers that do something other than the trivial
> implementation of the zero-arity. The discussion
> https://groups.google.com/d/topic/clojure/M-13lRPfguc/discussion was the
> only related one I could find.
>
> Thanks,
> Dan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with

Re: [ANN] logconfig 0.7.1

[Pierre-Yves Ritschard]

I wrote a few more words to describe the motivation behind logconfig:
http://spootnik.org/entries/2014/10/15_easy-clojure-logging-set-up-with-logconfig.html

On Tue, Oct 14, 2014 at 11:17 PM, Pierre-Yves Ritschard 
wrote:

> Hi,
>
> While clojure.tools.logging does a great job at logging, writing programs
> in clojure involves
> setting up the logging, which for people not familiar with the JVM can
> mean a lot of head scratching before figuring out how log4j.properties work
> and can be fed to a JVM.
>
> logconfig was meant to help in this scenario, allowing external
> log4j.properties to exist if need be
> but defaulting to a simpler method which can coexist with the
> application's main configuration method.
>
> logconfig provides a simple map-based config (which you might deserialize
> from a YAML/Json/EDN configuration file, or elsewhere) and supports console
> appenders as well as timebased rolling appenders, pattern layout and json
> layouts for easy interaction with syslog-ng, logstash and friends.
>
> https://github.com/pyr/logconfig
> http://pyr.github.io/logconfig
>
> Hope this helps!
>
>   - pyr
>

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

[Daniel James]

Hi Andy,

Thanks for the reference. I had already read Christophe’s blog posts, and 
had seen some of the the discussion around them. I can attempt to offer a 
comparison of what is being proposed.

Christophe is proposing changing the types. To illustrate this, in his 
formulation, the identity transducer would look like:

(def identity
  (fn [rf]
([] (rf))
([input] (rf input

Transducers as they are in Clojure 1.7, the identity transducer is:

(def identity
  (fn [rf]
([] (rf))
([result] (rf result))
([result input] (rf result input

In my proposal above, nothing is changing about the fact that transducers 
transform reducing functions to new reducing functions. The simple change 
is to use the reducing function that is produced by a transformation stack 
to seed the initial value of the reduction, rather than using the input 
reducing function (or explicit input seed value, in the second arity of 
transduce).

I hope that helps,

Dan



On Wednesday, October 15, 2014 10:23:37 AM UTC-4, Andy Fingerhut wrote:
>
> Dan, I haven't read yours or Christophe Grand's articles thoroughly enough 
> even to know whether your ideas are similar, but you may be interested to 
> read this thread, and the blog posts written by Christophe, linked from his 
> first message in this discussion thread: 
> https://groups.google.com/forum/#!topic/clojure-dev/cWzMS_qqgcM
>
> On Wed, Oct 15, 2014 at 6:22 AM, Daniel James  > wrote:
>
>> Hi All,
>>
>> I’d like to offer an alternative implementation of clojure.core/transduce.
>>
>> (I’ve done some searching, and I didn’t find any evidence that this has 
>> been raised before, but my apologies if I missed anything.)
>>
>> This alternative is best motivated by example. Consider the following 
>> transducers:
>>
>> (defn init-with
>>   [x]
>>   (fn [rf]
>> (fn
>>   ([] (rf (rf) x))
>>   ([result] (rf result))
>>   ([result input]
>>  (rf result input)
>>
>> (defn complete-with
>>   [x]
>>   (fn [rf]
>> (fn
>>   ([] (rf))
>>   ([result]
>>  (rf (rf result x)))
>>   ([result input]
>>  (rf result input)
>>
>> (defn dupl
>>   []
>>   (fn [rf]
>> (fn
>>   ([] (rf))
>>   ([result] (rf result))
>>   ([result input]
>>  (rf (rf result input)
>>  input)
>>
>> I have selected these as each illustrate something ‘interesting’ 
>> occurring in each of the three arities of the reducing functions produced.
>>
>> Now consider the following transducer, which transforms numeric reducing 
>> functions.
>>
>> (def xform (comp
>> (map inc)
>> (complete-with 10)
>> (map inc)
>> (init-with 100)
>> (map inc)
>> (dupl)))
>>
>> The current behavior of transduce (and into, for illustration purposes) 
>> is:
>>
>> (into [37] xform (range 5))
>> ;=> [37 3 3 4 4 5 5 6 6 7 7 12 12]
>>
>>
>> (transduce xform + 37 (range 5))
>> ;=> 111
>>
>> (reduce + (into [37] xform (range 5)))
>> ;=> 111
>>
>> (transduce xform + (range 5))
>> ;=> 74
>>
>>
>> So the dupl and complete-with transducers work as I expected, but the 
>> init-with does not.
>>
>> What I was hoping for was:
>>
>> ;=> [37 101 101 3 3 4 4 5 5 6 6 7 7 12 12]
>>
>> ;=> 313
>>
>> ;=> 313
>>
>> ;=> 276
>>
>>
>> This is because transduce and into are currently implemented as something 
>> equivalent to the following:
>>
>> (defn curr-transduce
>>   ([xform f coll]
>>  (transduce xform f (f) coll))
>>   ([xform f init coll]
>>  (let [rf (xform f)]
>>(rf (reduce rf init coll)
>>
>>
>> (defn curr-into
>>   [to xform from]
>>   (curr-transduce xform conj to from))
>>
>> In the first arity of transduce, the initial value is taken from the 
>> reducing function f, not the reducing function produced by (xform f).
>> And in the second arity, the supplied initial value is supplied directly 
>> to the reduction.
>> These both bypass the transducer xform entirely, so the zeroth-arity is 
>> never invoked and no transformation occurs.
>>
>> I would like to propose the following alternative implementation:
>>
>> (defn alt-transduce
>>   ([xform f coll]
>>  (let [rf (xform f)]
>>(rf (reduce rf (rf) coll
>>   ([xform f init coll]
>>  (let [rf (xform
>>(fn
>>  ([] init)
>>  ([result] (f result))
>>  ([result input] (f result input]
>>(rf (reduce rf (rf) coll)
>>
>> In the first arity, the initial value is drawn from the transformed 
>> reducing function, rather than the supplied reducing function.
>> In the second arity, a reducing function is constructed from f and init 
>> to be f in arity 1 and 2, but return init in arity 0.
>> Both cases ensure that the transducer is used to transform all three 
>> components of the reduction: init, step, and completion.
>>
>> Because of the way that the second arity is implemented, into doesn’t 
>> need to change:
>>
>> 

Clojars and poodlebleed

[Phil Hagelberg]

Greetings Clojure users.

In order to defend against the PoodleBleed SSL attack[1], I've disabled
SSL v3 on Clojars's nginx server.

This will break compatibility at least with IE6, and possibly some other
clients. If anyone discovers important clients that require SSL v3
enabled, let us know at cont...@clojars.org and we may be able to work
something out.

-Phil

[1] - https://www.imperialviolet.org/2014/10/14/poodle.html


pgpKpoI0QSI0_.pgp
Description: PGP signature

agent validation fails in STM

[shahrdad shadab]

Hi folks

 I know when I send/send-off an action to an agent within a STM transaction
no action will be
dispatched if transaction fails to commit.
I was expecting similar behaviour when agent fails: the transaction does
not commit when
the action puts the agent in an invalid / failed state.
It seems my expectation is wrong because the sent action will be dispatched
only when transaction successfully committed which by the time it is too
late to un-commit things.
In such scenario the resource (database, file,...) will be out of sync with
the modified collection in STM.  Am I missing any thing here?

Any comments is highly appreciated.

Thanks a lot
Best regards
Shahrdad

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

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

[Sean Corfield]

Asking questions about race and/or gender can be a very sensitive issue and a 
lot of people would refuse to complete those sections, or may even refuse to 
complete the survey at all if such questions were included - for a variety of 
very valid reasons.

Sean

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




signature.asc
Description: Message signed with OpenPGP using GPGMail

annotating functions that use destructuring in core.typed

[kurofune]

Hi everyone, 

I am learning core.typed and ran into a stumbling block. When I use 
annotations on normal functions and run 'check-ns', things work out ok, 

;; works as expected
> (ann plus1 [Number -> Number])
> (defn plus1 [n] (+ n 1))
>
> ;; Works as expected
> (ann mult-arity [Number String -> (HMap :mandatory {:a Number :b String})])
> (defn mult-arity [n s] {:a n :b s})



but with functions that use destructuring in their body, I run into 
problems. 


;; Does not work. 
> (ann map-span [Map Fn  -> Map])
> (defn map-span [m f] (into {} (for [[k v] m] [k (f v)])))
>
 

clojure.lang.ExceptionInfo: Type Checker: Found 8 errors :: {:type-error 
:top-level-error, :errors (# (cf (fn [m f] (into {} (for [[k v] m] [k (f v)]))) [Map Fn  -> Map])




I have been on the core.typed wiki and googled around but to no avail. I 
have also used lighter amounts of destructuring in the function parameters 
and run into similar errors. I am having trouble even understanding the 
error messages (even after reading the pertinent wiki page) so if someone 
could give me some insights on how to do this properly, I would really 
appreciate it. 

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/d/optout.

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

[Ashton Kemerling]

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

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

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

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

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

[Sean Corfield]

On Oct 15, 2014, at 11:29 AM, Ashton Kemerling  
wrote:
> "I would rather not say" is a common and valid response in these scenarios.

Yes, although that doesn't address that there are people who will not complete 
a survey that even asks such questions (on a philosophical objection to 
collecting such demographic information). As I said, it's a sensitive issue.

As Bridget noted, they'll consider the approach for 2015.

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

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





signature.asc
Description: Message signed with OpenPGP using GPGMail

Adding up numbers, quickly

[Jony Hudson]

Hi all,

 another performance question ... this time about arithmetic on vectors :-) 
Let's say I have two vectors of numbers (specifically, things with type 
clojure.lang.PersistentVector, containing things of type java.lang.Double). 
And let's say I want to sum the differences [1] between corresponding 
elements of the lists i.e. (a1 - b1) + (a2 - b2) + ...

Any suggestions on how to do this quickly. What I find is that if I use the 
'obvious' high-level construction:

(reduce + (mapv #(- %1 %2) a b))


then it goes pretty slowly. On my laptop I measure about 180us for 1000 
element lists.

If I try using `loop`:

(loop [sum 0.0 i 0]  
 (if (< i 1000)
   (recur (+ sum (- (nth a i) (nth b i))) (inc i))
   sum))

it does better, at about 100us.

But these are still a ways off what I might think is the best that could be 
done. If I run a similar computation in Java, it takes about 8us, which 
ties up with what my gut feeling would be.

So ... does anyone have any advice on closing the gap here?

Thanks in advance, again,


Jony


[1] Actually I want to sum the absolute differences, but that brings in 
java interop which I want to leave out lest it confuse matters.

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

[Jozef Wagner]

Slowdowns wrt math are caused mainly by boxing and range check, see this 
thread [1]

[1] https://groups.google.com/d/msg/clojure/kcx5eKdMxcs/Wy4_IHrSEaMJ

Jozef

On Wednesday, October 15, 2014 9:53:40 PM UTC+2, Jony Hudson wrote:
>
> Hi all,
>
>  another performance question ... this time about arithmetic on vectors 
> :-) Let's say I have two vectors of numbers (specifically, things with type 
> clojure.lang.PersistentVector, containing things of type java.lang.Double). 
> And let's say I want to sum the differences [1] between corresponding 
> elements of the lists i.e. (a1 - b1) + (a2 - b2) + ...
>
> Any suggestions on how to do this quickly. What I find is that if I use 
> the 'obvious' high-level construction:
>
> (reduce + (mapv #(- %1 %2) a b))
>
>
> then it goes pretty slowly. On my laptop I measure about 180us for 1000 
> element lists.
>
> If I try using `loop`:
>
> (loop [sum 0.0 i 0]  
>  (if (< i 1000)
>(recur (+ sum (- (nth a i) (nth b i))) (inc i))
>sum))
>
> it does better, at about 100us.
>
> But these are still a ways off what I might think is the best that could 
> be done. If I run a similar computation in Java, it takes about 8us, which 
> ties up with what my gut feeling would be.
>
> So ... does anyone have any advice on closing the gap here?
>
> Thanks in advance, again,
>
>
> Jony
>
>
> [1] Actually I want to sum the absolute differences, but that brings in 
> java interop which I want to leave out lest it confuse matters.
>

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

[Ambrose Bonnaire-Sergeant]

Hi,

The issue is that you can't use clojure.core/for in typed code.

You must use clojure.core.typed/for
, and annotate
the parameters and expected type.

(ann map-span (All [x y y1] [(Map x y) [y -> y1]  -> (Map x y1)]))
(defn map-span [m f]
   (into {} (t/for [[k v] :- '[x y] m] :- '[x y1]
  [k (f v)])))

Here's a real gist .

Thanks,
Ambrose

On Wed, Oct 15, 2014 at 2:28 PM, kurofune  wrote:

> Hi everyone,
>
> I am learning core.typed and ran into a stumbling block. When I use
> annotations on normal functions and run 'check-ns', things work out ok,
>
> ;; works as expected
>> (ann plus1 [Number -> Number])
>> (defn plus1 [n] (+ n 1))
>>
>> ;; Works as expected
>> (ann mult-arity [Number String -> (HMap :mandatory {:a Number :b
>> String})])
>> (defn mult-arity [n s] {:a n :b s})
>
>
>
> but with functions that use destructuring in their body, I run into
> problems.
>
>
> ;; Does not work.
>> (ann map-span [Map Fn  -> Map])
>> (defn map-span [m f] (into {} (for [[k v] m] [k (f v)])))
>>
>
>
> clojure.lang.ExceptionInfo: Type Checker: Found 8 errors :: {:type-error
> :top-level-error, :errors (# Polymorphic static method clojure.lang.RT/nth could not be applied to
> arguments: Polymorphic Variables: x y Domains: (I (CountRange 1) (U (I
> (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x))) (Val 0) Any
> (U nil (I (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x))
> Int y Arguments: Any (Val 0) nil Ranges: x
> (U x y) ...
>
>
> ;; This also throws errors at the repl.
>> (cf (fn [m f] (into {} (for [[k v] m] [k (f v)]))) [Map Fn  -> Map])
>
>
>
>
> I have been on the core.typed wiki and googled around but to no avail. I
> have also used lighter amounts of destructuring in the function parameters
> and run into similar errors. I am having trouble even understanding the
> error messages (even after reading the pertinent wiki page) so if someone
> could give me some insights on how to do this properly, I would really
> appreciate it.
>
> 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/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: Adding up numbers, quickly

[Jony Hudson]

Thanks, that's really useful!


Jony


On Wednesday, 15 October 2014 20:53:40 UTC+1, Jony Hudson wrote:
>
> Hi all,
>
>  another performance question ... this time about arithmetic on vectors 
> :-) Let's say I have two vectors of numbers (specifically, things with type 
> clojure.lang.PersistentVector, containing things of type java.lang.Double). 
> And let's say I want to sum the differences [1] between corresponding 
> elements of the lists i.e. (a1 - b1) + (a2 - b2) + ...
>
> Any suggestions on how to do this quickly. What I find is that if I use 
> the 'obvious' high-level construction:
>
> (reduce + (mapv #(- %1 %2) a b))
>
>
> then it goes pretty slowly. On my laptop I measure about 180us for 1000 
> element lists.
>
> If I try using `loop`:
>
> (loop [sum 0.0 i 0]  
>  (if (< i 1000)
>(recur (+ sum (- (nth a i) (nth b i))) (inc i))
>sum))
>
> it does better, at about 100us.
>
> But these are still a ways off what I might think is the best that could 
> be done. If I run a similar computation in Java, it takes about 8us, which 
> ties up with what my gut feeling would be.
>
> So ... does anyone have any advice on closing the gap here?
>
> Thanks in advance, again,
>
>
> Jony
>
>
> [1] Actually I want to sum the absolute differences, but that brings in 
> java interop which I want to leave out lest it confuse matters.
>

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

[kurofune]

Thanks Ambrose, 

It makes way better sense after looking at your gist. I still don't *quite* 
understand the :- syntax, though. Is it just introducing a type declaration 
to the data structure that comes after it?

This is a super cool project, by the way.

K


On Wednesday, October 15, 2014 3:14:58 PM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> Hi,
>
> The issue is that you can't use clojure.core/for in typed code.
>
> You must use clojure.core.typed/for 
> ,
>  
> and annotate the parameters and expected type.
>
> (ann map-span (All [x y y1] [(Map x y) [y -> y1]  -> (Map x y1)]))
> (defn map-span [m f] 
>(into {} (t/for [[k v] :- '[x y] m] :- '[x y1]
>   [k (f v)])))
>
> Here's a real gist 
> .
>
> Thanks,
> Ambrose
>
> On Wed, Oct 15, 2014 at 2:28 PM, kurofune  > wrote:
>
>> Hi everyone, 
>>
>> I am learning core.typed and ran into a stumbling block. When I use 
>> annotations on normal functions and run 'check-ns', things work out ok, 
>>
>> ;; works as expected
>>> (ann plus1 [Number -> Number])
>>> (defn plus1 [n] (+ n 1))
>>>
>>> ;; Works as expected
>>> (ann mult-arity [Number String -> (HMap :mandatory {:a Number :b 
>>> String})])
>>> (defn mult-arity [n s] {:a n :b s})
>>
>>
>>
>> but with functions that use destructuring in their body, I run into 
>> problems. 
>>
>>
>> ;; Does not work. 
>>> (ann map-span [Map Fn  -> Map])
>>> (defn map-span [m f] (into {} (for [[k v] m] [k (f v)])))
>>>
>>  
>>
>> clojure.lang.ExceptionInfo: Type Checker: Found 8 errors :: {:type-error 
>> :top-level-error, :errors (#> Polymorphic static method clojure.lang.RT/nth could not be applied to 
>> arguments: Polymorphic Variables: x y Domains: (I (CountRange 1) (U (I 
>> (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x))) (Val 0) Any 
>> (U nil (I (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x)) 
>> Int y Arguments: Any (Val 0) nil Ranges: x 
>> (U x y) ...
>>
>>
>> ;; This also throws errors at the repl.
>>> (cf (fn [m f] (into {} (for [[k v] m] [k (f v)]))) [Map Fn  -> Map])
>>
>>
>>
>>
>> I have been on the core.typed wiki and googled around but to no avail. I 
>> have also used lighter amounts of destructuring in the function parameters 
>> and run into similar errors. I am having trouble even understanding the 
>> error messages (even after reading the pertinent wiki page) so if someone 
>> could give me some insights on how to do this properly, I would really 
>> appreciate it. 
>>
>> K
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: annotating functions that use destructuring in core.typed

[Ambrose Bonnaire-Sergeant]

The :- is just a bit of syntax to signify an annotation. As a rule, it goes
*after*
the form you might expect to attach metadata to.

eg. (t/fn [a :- Int] :- Num ) is [Int -> Num]
  (t/let [a :- Int, 1] ...) checks 1 as being under Int.
  (t/let [[a b] :- '[Num Num], [1 2]] ...) checks [1 2] as under '[Num
Num], then assigns whatever expression is to the left the type '[Num Num]
  (t/for [[a b] :- '[Num Num], foo] :- Ret e) assigns the left hand
side of the binder type '[Num Num], where the right hand side is (U nil
(Seqable '[Num Num])). This is because every iteration [a b] is an element
of foo.
  The return type Ret is similarly for one iteration, and the inferred
type will be (Seq Ret).

Thanks,
Ambrose


On Wed, Oct 15, 2014 at 6:34 PM, kurofune  wrote:

> Thanks Ambrose,
>
> It makes way better sense after looking at your gist. I still don't
> *quite* understand the :- syntax, though. Is it just introducing a type
> declaration to the data structure that comes after it?
>
> This is a super cool project, by the way.
>
> K
>
>
> On Wednesday, October 15, 2014 3:14:58 PM UTC-5, Ambrose Bonnaire-Sergeant
> wrote:
>>
>> Hi,
>>
>> The issue is that you can't use clojure.core/for in typed code.
>>
>> You must use clojure.core.typed/for
>> ,
>> and annotate the parameters and expected type.
>>
>> (ann map-span (All [x y y1] [(Map x y) [y -> y1]  -> (Map x y1)]))
>> (defn map-span [m f]
>>(into {} (t/for [[k v] :- '[x y] m] :- '[x y1]
>>   [k (f v)])))
>>
>> Here's a real gist
>> .
>>
>> Thanks,
>> Ambrose
>>
>> On Wed, Oct 15, 2014 at 2:28 PM, kurofune  wrote:
>>
>>> Hi everyone,
>>>
>>> I am learning core.typed and ran into a stumbling block. When I use
>>> annotations on normal functions and run 'check-ns', things work out ok,
>>>
>>> ;; works as expected
 (ann plus1 [Number -> Number])
 (defn plus1 [n] (+ n 1))

 ;; Works as expected
 (ann mult-arity [Number String -> (HMap :mandatory {:a Number :b
 String})])
 (defn mult-arity [n s] {:a n :b s})
>>>
>>>
>>>
>>> but with functions that use destructuring in their body, I run into
>>> problems.
>>>
>>>
>>> ;; Does not work.
 (ann map-span [Map Fn  -> Map])
 (defn map-span [m f] (into {} (for [[k v] m] [k (f v)])))

>>>
>>>
>>> clojure.lang.ExceptionInfo: Type Checker: Found 8 errors :: {:type-error
>>> :top-level-error, :errors (#>> Polymorphic static method clojure.lang.RT/nth could not be applied to
>>> arguments: Polymorphic Variables: x y Domains: (I (CountRange 1) (U (I
>>> (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x))) (Val 0) Any
>>> (U nil (I (clojure.lang.Seqable x) clojure.lang.Sequential) (Indexed x))
>>> Int y Arguments: Any (Val 0) nil Ranges: x
>>> (U x y) ...
>>>
>>>
>>> ;; This also throws errors at the repl.
 (cf (fn [m f] (into {} (for [[k v] m] [k (f v)]))) [Map Fn  -> Map])
>>>
>>>
>>>
>>>
>>> I have been on the core.typed wiki and googled around but to no avail. I
>>> have also used lighter amounts of destructuring in the function parameters
>>> and run into similar errors. I am having trouble even understanding the
>>> error messages (even after reading the pertinent wiki page) so if someone
>>> could give me some insights on how to do this properly, I would really
>>> appreciate it.
>>>
>>> K
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: Adding up numbers, quickly

[Linus Ericsson]

There are primitive vectors. Extraordinary clever.

http://clojuredocs.org/clojure.core/vector-of

/Linus
Den 16 okt 2014 00:02 skrev "Jony Hudson" :

> Thanks, that's really useful!
>
>
> Jony
>
>
> On Wednesday, 15 October 2014 20:53:40 UTC+1, Jony Hudson wrote:
>>
>> Hi all,
>>
>>  another performance question ... this time about arithmetic on vectors
>> :-) Let's say I have two vectors of numbers (specifically, things with type
>> clojure.lang.PersistentVector, containing things of type java.lang.Double).
>> And let's say I want to sum the differences [1] between corresponding
>> elements of the lists i.e. (a1 - b1) + (a2 - b2) + ...
>>
>> Any suggestions on how to do this quickly. What I find is that if I use
>> the 'obvious' high-level construction:
>>
>> (reduce + (mapv #(- %1 %2) a b))
>>
>>
>> then it goes pretty slowly. On my laptop I measure about 180us for 1000
>> element lists.
>>
>> If I try using `loop`:
>>
>> (loop [sum 0.0 i 0]
>>  (if (< i 1000)
>>(recur (+ sum (- (nth a i) (nth b i))) (inc i))
>>sum))
>>
>> it does better, at about 100us.
>>
>> But these are still a ways off what I might think is the best that could
>> be done. If I run a similar computation in Java, it takes about 8us, which
>> ties up with what my gut feeling would be.
>>
>> So ... does anyone have any advice on closing the gap here?
>>
>> Thanks in advance, again,
>>
>>
>> Jony
>>
>>
>> [1] Actually I want to sum the absolute differences, but that brings in
>> java interop which I want to leave out lest it confuse matters.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Mars0i]

I don't really get it.  I don't see a legitimate reason why anyone would 
refuse to participate in the survey because it included demographic 
questions.  The survey is anonymous.  The combination of questions is not 
such that it would be at all plausible that anyone could be identified by 
their responses.  At worst, answering a few additional questions--or simply 
skipping those questions--would be a very minor annoyance.  Is it that some 
people object to the idea that there are disparities due to systemic 
factors in our society?  If someone wants to disagree about that, OK, but I 
still don't see how boycotting a survey because it offers respondents the 
opportunity to provide demographic information is reasonable.

On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote:
>
> On Oct 15, 2014, at 11:29 AM, Ashton Kemerling  > wrote: 
> > "I would rather not say" is a common and valid response in these 
> scenarios. 
>
> Yes, although that doesn't address that there are people who will not 
> complete a survey that even asks such questions (on a philosophical 
> objection to collecting such demographic information). As I said, it's a 
> sensitive issue. 
>
> As Bridget noted, they'll consider the approach for 2015. 
>
> Sean Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>
>
>
>

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

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

[Ashton Kemerling]

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

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

> I don't really get it.  I don't see a legitimate reason why anyone would 
> refuse to participate in the survey because it included demographic 
> questions.  The survey is anonymous.  The combination of questions is not 
> such that it would be at all plausible that anyone could be identified by 
> their responses.  At worst, answering a few additional questions--or simply 
> skipping those questions--would be a very minor annoyance.  Is it that some 
> people object to the idea that there are disparities due to systemic 
> factors in our society?  If someone wants to disagree about that, OK, but I 
> still don't see how boycotting a survey because it offers respondents the 
> opportunity to provide demographic information is reasonable.
> On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote:
>>
>> On Oct 15, 2014, at 11:29 AM, Ashton Kemerling > > wrote: 
>> > "I would rather not say" is a common and valid response in these 
>> scenarios. 
>>
>> Yes, although that doesn't address that there are people who will not 
>> complete a survey that even asks such questions (on a philosophical 
>> objection to collecting such demographic information). As I said, it's a 
>> sensitive issue. 
>>
>> As Bridget noted, they'll consider the approach for 2015. 
>>
>> Sean Corfield -- (904) 302-SEAN 
>> An Architect's View -- http://corfield.org/ 
>>
>> "Perfection is the enemy of the good." 
>> -- Gustave Flaubert, French realist novelist (1821-1880) 
>>
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[Atamert Ölçgen]

On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling  wrote:

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


Suppose I have provided reliable data that shows only 0.1% would refuse to
answer such a Survey. A programming related survey with questions about
demographics and a stated mission of being inclusive. What would be your
moral reasoning for not being inclusive for this group of people?



>
>
>
> On Wed, Oct 15, 2014 at 6:23 PM, Mars0i  wrote:
>
>> I don't really get it.  I don't see a legitimate reason why anyone would
>> refuse to participate in the survey because it included demographic
>> questions.  The survey is anonymous.  The combination of questions is not
>> such that it would be at all plausible that anyone could be identified by
>> their responses.  At worst, answering a few additional questions--or simply
>> skipping those questions--would be a very minor annoyance.  Is it that some
>> people object to the idea that there are disparities due to systemic
>> factors in our society?  If someone wants to disagree about that, OK, but I
>> still don't see how boycotting a survey because it offers respondents the
>> opportunity to provide demographic information is reasonable.
>>
>> On Wednesday, October 15, 2014 2:06:29 PM UTC-5, Sean Corfield wrote:
>>>
>>> On Oct 15, 2014, at 11:29 AM, Ashton Kemerling 
>>> wrote:
>>> > "I would rather not say" is a common and valid response in these
>>> scenarios.
>>>
>>> Yes, although that doesn't address that there are people who will not
>>> complete a survey that even asks such questions (on a philosophical
>>> objection to collecting such demographic information). As I said, it's a
>>> sensitive issue.
>>>
>>> As Bridget noted, they'll consider the approach for 2015.
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>>
>>>
>>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

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

[Sean Corfield]

I'm replying to Ashton and Mars0i off-list - and I'm happy to continue 
discussing the issue off-list, with anyone who wants to, but I think it's 
getting off-topic and close to inappropriate for this (technical) list.

And, for what it's worth, Atamert, I'm on your side on this.

Sean

On Oct 15, 2014, at 6:44 PM, Atamert Ölçgen  wrote:
> On Thu, Oct 16, 2014 at 8:30 AM, Ashton Kemerling  
> wrote:
> I'm curious if there's any empirical evidence that significant numbers of 
> people will do that. 
> 
> Suppose I have provided reliable data that shows only 0.1% would refuse to 
> answer such a Survey. A programming related survey with questions about 
> demographics and a stated mission of being inclusive. What would be your 
> moral reasoning for not being inclusive for this group of people?




signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Ashton Kemerling]

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


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




--

Ashton

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

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

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

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

[Ashton Kemerling]

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

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

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

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

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

[Mars0i]

After reading Sean's thoughtful off-list remarks, I think it's worth 
commenting on my previous remarks.  I don't think it matters whether I 
understand people's reasons.  People may have their own personal reasons 
for not wanting to answer demographic questions, and I accept that, don't 
object to it, and am open to supporting it.

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

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

Re: annotating functions that use destructuring in core.typed

[kurofune]

That's much clearer now. Thanks a lot. 



On Wednesday, October 15, 2014 5:46:37 PM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> The :- is just a bit of syntax to signify an annotation. As a rule, it 
> goes *after*
> the form you might expect to attach metadata to.
>
> eg. (t/fn [a :- Int] :- Num ) is [Int -> Num]
>   (t/let [a :- Int, 1] ...) checks 1 as being under Int.
>   (t/let [[a b] :- '[Num Num], [1 2]] ...) checks [1 2] as under 
> '[Num Num], then assigns whatever expression is to the left the type '[Num 
> Num]
>   (t/for [[a b] :- '[Num Num], foo] :- Ret e) assigns the left hand 
> side of the binder type '[Num Num], where the right hand side is (U nil 
> (Seqable '[Num Num])). This is because every iteration [a b] is an element 
> of foo.
>   The return type Ret is similarly for one iteration, and the inferred 
> type will be (Seq Ret).
>
> Thanks,
> Ambrose
>
>
> On Wed, Oct 15, 2014 at 6:34 PM, kurofune  > wrote:
>
>> Thanks Ambrose, 
>>
>> It makes way better sense after looking at your gist. I still don't 
>> *quite* understand the :- syntax, though. Is it just introducing a type 
>> declaration to the data structure that comes after it?
>>
>> This is a super cool project, by the way.
>>
>> K
>>
>>
>> On Wednesday, October 15, 2014 3:14:58 PM UTC-5, Ambrose 
>> Bonnaire-Sergeant wrote:
>>>
>>> Hi,
>>>
>>> The issue is that you can't use clojure.core/for in typed code.
>>>
>>> You must use clojure.core.typed/for 
>>> ,
>>>  
>>> and annotate the parameters and expected type.
>>>
>>> (ann map-span (All [x y y1] [(Map x y) [y -> y1]  -> (Map x y1)]))
>>> (defn map-span [m f] 
>>>(into {} (t/for [[k v] :- '[x y] m] :- '[x y1]
>>>   [k (f v)])))
>>>
>>> Here's a real gist 
>>> .
>>>
>>> Thanks,
>>> Ambrose
>>>
>>> On Wed, Oct 15, 2014 at 2:28 PM, kurofune  wrote:
>>>
 Hi everyone, 

 I am learning core.typed and ran into a stumbling block. When I use 
 annotations on normal functions and run 'check-ns', things work out ok, 

 ;; works as expected
> (ann plus1 [Number -> Number])
> (defn plus1 [n] (+ n 1))
>
> ;; Works as expected
> (ann mult-arity [Number String -> (HMap :mandatory {:a Number :b 
> String})])
> (defn mult-arity [n s] {:a n :b s})



 but with functions that use destructuring in their body, I run into 
 problems. 


 ;; Does not work. 
> (ann map-span [Map Fn  -> Map])
> (defn map-span [m f] (into {} (for [[k v] m] [k (f v)])))
>
  

 clojure.lang.ExceptionInfo: Type Checker: Found 8 errors :: 
 {:type-error :top-level-error, :errors (#>>> clojure.lang.ExceptionInfo: Polymorphic static method clojure.lang.RT/nth 
 could not be applied to arguments: Polymorphic Variables: x y Domains: (I 
 (CountRange 1) (U (I (clojure.lang.Seqable x) clojure.lang.Sequential) 
 (Indexed x))) (Val 0) Any (U nil (I (clojure.lang.Seqable x) 
 clojure.lang.Sequential) (Indexed x)) Int y Arguments: Any (Val 0) nil 
 Ranges: x 
 (U x y) ...


 ;; This also throws errors at the repl.
> (cf (fn [m f] (into {} (for [[k v] m] [k (f v)]))) [Map Fn  -> Map])




 I have been on the core.typed wiki and googled around but to no avail. 
 I have also used lighter amounts of destructuring in the function 
 parameters and run into similar errors. I am having trouble even 
 understanding the error messages (even after reading the pertinent wiki 
 page) so if someone could give me some insights on how to do this 
 properly, 
 I would really appreciate it. 

 K

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

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