@sebastianpoeplau: for prod I created my Dockerfile starting from develar/java:8u45

seylerius: you should checkout http://dev.clojure.org/jira/browse/CLJ-1906

Thanks, @hiredman. That looks like it's going to do the trick.

@gfredericks: your (doto prn) trick is eye-opening to me

we need a place to put all of those repl tricks

I'm a repl trick junkie

@pesterhazy: can you show me an example of this (doto prn) trick?

https://clojurians.slack.com/archives/clojure/p1470338422002968

gets around the fact that prn always returns nil

ah nice, so the value f1 does not get affected at all and is really passed to f2 with printing in between. (-> 2 inc (doto (prn "WTF")) inc) 3 "WTF" 4

yup

That's super cool, beats this: (-> 2 inc ((fn [x] (println x) x)) inc)

it totally does

Doesn’t work that good with (->> x …) though, right?

nope

(the reason for the ‘my-doto is that ‘doto is a macro 😕 )

https://clojars.org/ is down?

https://twitter.com/clojars/status/761497607252291584

got it ,thanks

https://twitter.com/clojars/status/761503436462370817 (end of twitter relaying)

yep, now works

Sets are collections of unique values. and = `...compares numbers and collections in a type-independent manner` how is that

SET
=> #{2 10}
(vec SET)
=> [2 10]
(= SET (vec SET))
=> false 

From my understanding, it compares in a type-independent manner but not in a properties-independent manner

is it not the properties of a collection what define its type?

then what "type independent manner" mean for a collection?

distinctness, order -- are they not properties of a type of a collection?

no ordering in a set, makes no sense to be "equal" with an ordered thing

@mpenet: you depend on type, no? is it not "type-independent"?

everything is an Object ultimately

I guess there are possible exceptions, but vec and sets are quite different beasts

sorted-map and hash-map will compare the way you suggest tho. but they are slight variations of the same thing, which is not the case with vec/set imho

We can infer properties from type but can not infer type from properties. That means collections which share the same property don’t need to be the same type.

@tap: exactly. that is why when we say "type-independent" that includes properties too... Anyway, I found it in clojure.lang.Util :

static EquivPred equivColl = new EquivPred(){
        public boolean equiv(Object k1, Object k2) {
            if(k1 instanceof IPersistentCollection || k2 instanceof IPersistentCollection)
                return pcequiv(k1, k2);
            return k1.equals(k2);
        }
    };

or, let us say, sets are not collections

No. It can be different types with the same property and equal. But vector and set don’t have that same property

"But vector and set don’t have that same property" ... and that alone is what makes them different types. Just cant see how it can be read differently

if anyone has used Kafka-fast and come across an issue where "hostame cannot be null" (http://pastebin.com/euwTYXqG) then I really could do with a pointer in the right direction... can't figure out what is wrong but I have a vague notion what I'm trying to do isn't supported (re: https://github.com/brianfrankcooper/YCSB/issues/619#issuecomment-182148588)

If one could do this:

(defn foo [a b]
  [a b])

(apply foo [1 2]) ; => [1 2]

(defn bar [& {:keys [a b]}]
  [a b])

(apply bar {:a 1 :b 2}) ; => [1 2]

(apply bar [:a 1 :b 2]) maybe?

@niwinz: Hm... That mean this:

(apply bar (-> {:a 1 :b 2} seq flatten))

(apply bar (mapcat identity {:a 1 :b 2}))

is much better approach than using flatten 😉

A very quick and not accurate benchmark

user=> (time (dotimes [i 10000] (-> {:a 1 :b 2} seq flatten vec)))
"Elapsed time: 52.428818 msecs"
nil
user=> (time (dotimes [i 10000] (vec (mapcat identity {:a 1 :b 2}))))
"Elapsed time: 12.735619 msecs"
nil

@niwinz: Matter of taste or other reasons?

@niwinz: I see. 😄

@novakboskov: as general approach flatten should be avoided if you know the data structure

That's make sense since flatten also care about any level of nested structures and handle them while concat do the same only for the higher level .

@niwinz @novakboskov another unscientific benchmark suggests using into with a transducer is even faster

user=> (def data (zipmap (range 1000) (range 1000)))
user=> (time (dotimes [i 10000] (into [] cat data)))
"Elapsed time: 2558.654174 msecs"
user=> (time (dotimes [i 10000] (vec (mapcat identity data))))
"Elapsed time: 5145.451993 msecs"

but with small number of arguments

the difference is very very small

you are not going to have 1000 arguments

in the majority of cases

fair point

into [] cat seems to be about 7% faster on {:a 0 :b 1}, which is not huge. I pointed it out because it's generally the most efficient way to concatenate sequences.

it’s the most efficient if you want a collection at the end

if you want a lazy sequence that you may or may not use all of, then concat is a better choice

@pesterhazy I think it's useful in Real Code too

for calling out side effects

@theblackbox: have not used kafka fast but sounds like you dont have your host configured correctly. Kafka consumers usually need a zookeeper host (usually with port 2081), and producers need a "bootstrap" host usually with port 9092

The old military industrial complect...

@theblackbox: Why kafka-fast?

@cddr: kafka-fast uses redis instead of zk

Ah I forgot about that. Thanks

from what I can tell it uses both zookeeper and redis?

redis for offset and zookeper for brokers

@cddr: yeah, I think there is an issue with redis in cluster mode, because when I use a single instance I'm able to connect

but I think I have some problem when it comes to zookeeper: "No brokers found in ZK".... which isn't great

That sounds like a producer can connect to zookeeper but that the broker hasnt registered itself as being available

that sounds correct: I can connect a producer, but not a consumer

where might that config be found?

.... or I'm just being a bell end and connecting to the wrong port....

Good catch

Using Instaparse, is there a way to define that a e.g. a “sentence" consists of a sequence of “word” “whitespace”, but at the same time output the latter as “word word word”? That is, keep the sentence including whitespace as one single string. Constraints for the question: Don't describe sentence as a single reg-ex and do it all in Instaparse (no post-processing). Example: Parsing “One two three” should return [:sentence “One two three”], not [:sentence “one” “ “ “two” “ “ “three”].

@mokr wrap the whitespace portion in angle brackets to hide it from the tree

So SENTENCE = WORD (<WS> WORD)* should do it.

Per https://github.com/Engelberg/instaparse#hiding-content

@seancorfield: Thanks for the suggestion, but then I lose it. I want to keep it, but not split the parts.

Ah, I misread your question.

Thought so 😉

I can solve this if I disregard either of my constraints, they are not hard constraints, but I’m just curious if I’m missing something in Instaparse itself.

Then I think the answer is "no", you’ll need a post-processing step to convert the :sentence sequences back to strings.

Hmm, can transform help you here?

https://github.com/Engelberg/instaparse#transforming-the-tree

I have to admit it has been a while since I read through all the Instaparse doc. Today I just wanted to start coding after seeing something at work that I wanted to parse. Transform rings a bell, so I will have a look. Thanks for helping out.

We use instaparse at work but it’s been a while since I revisited the docs too...

instaparse grammars can't concatenate strings during the parse step, but transform should make that pretty easy

I believe if you call transform with a partial transform map, only the terminals you specified actually get changed

@aengelberg: Thanks, now I know for sure where to look. Keep up the good work! 🙂

So {:sentence (partial apply str)} in this case? @aengelberg

heh thanks. also there's an #C06AH8PGS channel if you have any more questions

@seancorfield actually just {:sentence str}

Ah, good to know. I was actually thinking of searching for library channels this evening.

Ah, it already deals with the variadic case… makes sense...

Without having read up on the solution, that looks nice.

If I have structure like this:

(def cs {:customers
         [{:id           #uuid "590bed10-efcb-4d5d-af9a-ae14e76cf63c"
           :type         :institution
           :marketplaces [:whole-term-loan]
           :full-name    "Alice"
           :nickname     "Alice"}

          {:id           #uuid "a7a91e56-1863-4d96-a6c0-140057fcb7d9"
           :type         :accredited
           :marketplaces [:fractional-term-loan]
           :full-name    "Bob"
           :nickname     "Bob"}]})

(filter #(= x (:id %)) (:customers cs))

@ag I would use group-by on the :customer vector

but yes group-by is more useful if you need to have that indexed by :id in the future, which was not actually in your request

(first (filter #(= <id> (:id %)) (:customers cs)))

(or maybe more readable with a threading macro?)