Given a sequence of maps ms and a key k. How to get the value from the first map in ms which contains a value for k without iterating/reducing over all ms?

if you don't care about falsey values, (some k ms)

I need a test.check generator that produces nested maps with simple keys, but (gen/recursive-gen #(gen/map gen/simple-type-printable, %), gen/simple-type-printable) fails with IllegalArgumentException bit operation not supported for: class java.lang.Double clojure.lang.Numbers.bitOpsCast (Numbers.java:1122)

@gv do you have the full stack trace?

sure, see above

@gv what version of test.check are you using?

0.9.0 - I just found https://dev.clojure.org/jira/browse/TCHECK-145

ah; so maybe fixed in the alpha versions

I knew it sounded familiar

yes, in 0.10.0-alpha3 it works

recursive-gen sometimes does not create the root container?

In seldom cases I got a value from the scalar-gen instead of the expected map

Is there a complementary gen/all-of in addition to gen/one-of such that two generators can be combined as follows?

Actually, the corresponding working one-of example looks as follows:

hello, I have a question regarding the usage of go-loop: with go, the function returns a channel that contains the result of the go block. what does the channel of a go-loop contains ? is there a way to leverage the returned channel so a value computed for each iteration is put into this channel ?

imo your best bet is to pass a channel from the outside and use that. btw go-loop is just (go (loop... so it doesn't have unique semantics

thanks @joelsanchez, I'm already doing that, wondering if there was a better way

@mpenet thanks for knit https://github.com/mpenet/knit/

I haven't touched it in a while, it gets the job done 😉

Looks nice, I wanted to have a look at how executors and thread pools etc work - I’ll use this as a guiding map :)

created circa 2012 don't blame me for the sometimes questionable API choices 😄

is there an efficient way of converting a map {:a 1 :b 2} to a flat sequence (:a 1 :b 2) without flattening all the map elements?

no, but reduce-kv is likely the most efficient path to accessing all k’s and v’s for a PHM (as it avoids ever constructing map entries)

it would be my guess that combining reduce-kv with transients is the fastest path to that

thanks

@borkdude my first instinct there would be (into [] cat m)

user=> (into [] cat {:a 1 :b 2})
[:a 1 :b 2]

good one

I'm benchmarking to compare that with a simple usage of reduce-kv with a transient

TIL that unlike conj which is varags, conj! only takes 0, 1, or 2 args

user=> (crit/bench (persistent! (reduce-kv (fn [t k v] (-> t (conj! k) (conj! v))) (transient []) m)))
Evaluation count : 33792360 in 60 samples of 563206 calls.
             Execution time mean : 1.800892 µs
    Execution time std-deviation : 52.165518 ns
   Execution time lower quantile : 1.734716 µs ( 2.5%)
   Execution time upper quantile : 1.907247 µs (97.5%)
                   Overhead used : 1.904748 ns

Found 2 outliers in 60 samples (3.3333 %)
	low-severe	 1 (1.6667 %)
	low-mild	 1 (1.6667 %)
 Variance from outliers : 15.8045 % Variance is moderately inflated by outliers
nil

user=> (crit/bench (into [] cat m))
WARNING: Final GC required 1.148392675847086 % of runtime
Evaluation count : 17838060 in 60 samples of 297301 calls.
             Execution time mean : 3.552092 µs
    Execution time std-deviation : 494.411529 ns
   Execution time lower quantile : 3.305118 µs ( 2.5%)
   Execution time upper quantile : 4.750097 µs (97.5%)
                   Overhead used : 1.904748 ns

Found 6 outliers in 60 samples (10.0000 %)
	low-severe	 1 (1.6667 %)
	low-mild	 5 (8.3333 %)
 Variance from outliers : 82.3999 % Variance is severely inflated by outliers
nil

of course @alexmiller was right about the reduce-kv version being fastest

You can vote on this ticket if changing that interests you: https://dev.clojure.org/jira/browse/CLJ-1103

I do not recall whether the changes proposed in that patch do everything you might wish for.

that case didn't match the case I meant:

(ins)user=> (conj [:a :b] 1 2 3)
[:a :b 1 2 3]
(ins)user=> (conj! (transient [:a :b]) 1 2 3)
ArityException Wrong number of args (4) passed to: core/conj!  clojure.lang.AFn.throwArity (AFn.java:429)

Looking at the -10 patch on that ticket, it looks like it does generalize conj!

oh, I didn't see it in the examples, I didn't look at the patch

The description could be better, agreed.

I guess I will update it.

Description updated.

:thumbsup:

But, FYI, if it gets somewhere within top 3 voted tickets, it might get love more quickly.

thumbs up here appreciated, but not tracked on JIRA 🙂

what's a good, simple, performant pattern for a "history", where you push something onto it and if the count is greater than the established max size, it throws the oldest value out

ring buffer

seems like something that might have an established pattern, if not a core function

ring buffer?

a ring buffer is word for a thing with that behavior

nice!

thats awesome, I was really hoping that a word like that existed!

hahaha, I love this slack. The intelligence aggregated on here is so outstanding 😆

one way to implement a ring buffer in something like C would be an array of a fixed size and you update it like arr[idx++%size] = whatever

you can translate that idea directly to clojure using a vector, or try and be fancier (a fixed size binary tree or something)

I forgot I have a gist https://gist.github.com/hiredman/f56a593bc92062dcdfeebded0ab6725e

ooh, that is fancy!

I’m curious if the perf of persistent queue is good (`conj` to add, pop to remove). Maybe a ring buffer approach is faster.

dunno, in some ways pqueue is similar to mod in to a vector approach, but sort of extended to not be a fixed size

it builds a vector and as needed seqs the vector and replaces the vector with an empty vector

the gotcha with persistant queue in my experience is if someone calls rest instead of pop it silently turns from a fifo to a lifo, but doesn't error

for a real world usage I would likely go with mod + a vector, the binary tree ring buffer stuff was just me trying to figure out how I would get a persistent fifo queue without clojure's datastructures

that implementation was a blocking queue not a sliding queue, right?

when out of capacity it didn't drop its oldest value, it refused the incoming value

@dpsutton with the index / mod technique, the difference is whether reading moves the index vs. writing

otherwise they stay the same

(push [ring datum]
    (if (and (= read write)
             (pos? entries))
      false

i was looking at this. if read and write are equal don't do anything

ahh, right