Fork me on GitHub
#clojure
<
2016-08-05
>
richiardiandrea01:08:07

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

seylerius06:08:57

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

pesterhazy07:08:00

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

pesterhazy07:08:41

we need a place to put all of those repl tricks

pesterhazy07:08:49

I'm a repl trick junkie

hlolli08:08:18

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

pesterhazy08:08:22

gets around the fact that prn always returns nil

hlolli09:08:05

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

dominicm09:08:32

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

pesterhazy09:08:27

it totally does

gnejs09:08:47

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

gnejs09:08:35

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

rmuslimov09:08:27

got it ,thanks

rmuslimov10:08:16

yep, now works

andmed11:08:20

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 

tap11:08:04

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

andmed11:08:50

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

andmed11:08:20

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

andmed11:08:18

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

mpenet11:08:19

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

andmed11:08:27

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

mpenet12:08:10

everything is an Object ultimately

mpenet12:08:31

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

mpenet12:08:18

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

tap12:08:10

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.

andmed12:08:21

@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);
        }
    };
basically, it does various checks for IPersistentCollection, otherwise just calls Java equals, imo this is not what the docs say

andmed12:08:10

or, let us say, sets are not collections

tap12:08:22

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

andmed12:08:22

"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

theblackbox13:08:14

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)

novakboskov13:08:31

If one could do this:

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

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

How could I achieve this:
(defn bar [& {:keys [a b]}]
  [a b])

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

niwinz13:08:50

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

novakboskov13:08:27

@niwinz: Hm... That mean this:

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

niwinz13:08:28

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

niwinz13:08:41

is much better approach than using flatten 😉

niwinz13:08:58

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

novakboskov13:08:06

@niwinz: Matter of taste or other reasons?

niwinz13:08:55

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

novakboskov13:08:38

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 .

codonnell13:08:40

@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"

niwinz13:08:00

but with small number of arguments

niwinz13:08:08

the difference is very very small

niwinz13:08:18

you are not going to have 1000 arguments

niwinz13:08:26

in the majority of cases

codonnell13:08:22

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.

alexmiller13:08:15

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

alexmiller13:08:47

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

gfredericks14:08:00

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

gfredericks14:08:10

for calling out side effects

cddr15:08:41

@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

devn15:08:20

The old military industrial complect...

devn15:08:43

@theblackbox: Why kafka-fast?

devn15:08:51

@cddr: kafka-fast uses redis instead of zk

cddr15:08:33

Ah I forgot about that. Thanks

theblackbox15:08:16

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

theblackbox15:08:37

redis for offset and zookeper for brokers

theblackbox15:08:15

@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

theblackbox15:08:53

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

cddr15:08:23

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

theblackbox15:08:33

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

theblackbox15:08:41

where might that config be found?

theblackbox15:08:03

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

cddr15:08:14

Good catch

mokr18:08:37

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”].

seancorfield18:08:26

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

seancorfield18:08:42

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

mokr18:08:30

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

seancorfield18:08:13

Ah, I misread your question.

mokr18:08:27

Thought so 😉

mokr18:08:29

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.

seancorfield18:08:43

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

seancorfield18:08:38

Hmm, can transform help you here?

mokr18:08:04

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.

seancorfield18:08:36

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

aengelberg18:08:44

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

aengelberg18:08:16

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

mokr18:08:51

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

seancorfield18:08:00

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

aengelberg18:08:07

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

aengelberg18:08:33

@seancorfield actually just {:sentence str}

mokr18:08:00

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

seancorfield18:08:02

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

mokr18:08:35

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

ag21:08:02

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"}]})
What's the most elegant way to find customer with specified id?

dg21:08:43

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

richiardiandrea21:08:44

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

richiardiandrea21:08:51

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

gnejs21:08:51

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

gnejs21:08:28

(or maybe more readable with a threading macro?)