@rutledgepaulv if you're taking code as input at runtime, I think that's basically the definition of what eval is for

if the code has unbound locals, which I think is what you're describing, I've used a trick to wrap it in a function that takes the named arguments you want to supply e.g.,

(eval `(fn [{:keys [~@some-arg-names]}] ~the-expression-with-unbound-locals))

then you can call that function with a map

ooh

I think that would do the trick. thanks for the idea!

should’ve known I was trying to do too much in one macro + eval instead of just using a function lol

thanks @gfredericks that allowed me to do what I was trying to.

I’m not actually trying to rebind merge to inc.. just an example. lol

though a “guess what function I replaced your original function with” game sounds fun

Nice

Is there something like https://github.com/lightyear/sql-logging#options but for Clojure? tldr it aides you see if you have costly SQL being emitted, and actually points out the culprit LOC

On second thoughts, probably this library wouldn't make that much sense in Clojure, given "magical" ORMs aren't the norm here... so emitted SQL should have no surprises ...but still I can see myself using some simple metrics, e.g. query x took 30ms

@vemv I believe there are Java libraries that can act as a proxy for the actual JDBC driver and provide that sort of statistical logging.

@vemv you can always just hook the function yourself too if you can find the place you want to instrument

why does (read-string "07") return 7, but (read-string "08") throws an exception?

a leading zero often means that the following number is octal

8 however, is not a valid literal in octal

(read-string "010") is also 8 (base 10) instead of the 10 (base 10) you would have expected

WHY they decided to have 0 be the prefix for octal instead of 0o is beyond me. As the hex/binary prefix is 0x and 0b respectively…

Yay Java. I remember that one hitting me way back when I was doing Java for my degree...

thx

if i have an input array of strings, and i want to pick those that are also in a predefined set of valid strings, is it better to use (filter #{"valid1" "valid",,,} input) or some other way?

I think with the set is quite elegant

def the set of accepted strings somewhere, or make a predicate is-allowed-string? I guess

yeah that's the plan. i was wondering if for example set/intersection would be a better choice?

the result would need to be all unique too, so i'd need to fit a distinct in there

intersection would work too if your input is a set

it isn't

(remember, all set operations are explicitly undefined for non-sets)

i'd need to cast the input to set, making me again wonder if that's faster or running distinct on it

test it ^^

Benchmark it with criterium

timing it now

Unless performance is a bottleneck, pick the appropriate semantics.

i.e, if order doesn't matter and you don't care about duplicates

use clojure.set/intersection

in the normal case it isn't (as only 3-4 elements should be in the input), but i'd rather not accidentally create an attack vector

else (filter #{"input1" "input2" ...} input)

distinct has an … interesting implementation

this is interesting

user=> (time (->> input distinct (filter valid)))
"Elapsed time: 0.229339 msecs"

user=> (time (->> input distinct (filter valid) sort))
"Elapsed time: 0.581802 msecs"

user=> (time (set/intersection valid (set input)))
"Elapsed time: 0.219935 msecs"

user=>   (time (sort (set/intersection valid (set input))))
"Elapsed time: 0.199401 msecs"

why is sort so slow? the resulting filtered collection in the second case is only 4 elements, why is it taking such a toll?

you have to be careful on some of those - filter is lazy and you aren’t forcing realization

so the first timing isn’t doing the filter at all

all of the other ops here are eager so will force realization

timing a single instance of any of these is also likely meaningless

will into serve that purpose?

doall would work

but really you should time 1000s of instances of these ops to compare

like (dotimes [i 5] (time (dotimes [i 1000] (->> input distinct (filter valid) sort))))

the outer loop is 5 trials, the inner loop is 1000 reps per trial

you’ll usually notice it gets faster as the jit warms up

critierium is a fancier version of this

i see

thanks for the advice!

using sets seems to be significantly faster

like 3-4 times

hah, I did not expect that. I expected converting to a set to be a pricey operation

i tried generating the input randomly so the jvm would sweat a little

user=> (time (dotimes [m 10000] (->> (input) distinct (filter valid) sort)))
"Elapsed time: 693.849881 msecs"
user=> (time (dotimes [m 10000] (sort (set/intersection valid (set (input))))))
"Elapsed time: 279.379693 msecs"

moving distinct after the filter makes it a little faster but still twice as slow

input being a list?

try making it a set in the first one, i wonder if that'll speed it up at all

sure did.

using set instead of distinct made it 2-3 times faster

i suspect using the filter set predicate is using some sort of set-based stuff under the hood that makes comparisons to other sets much faster than comparing against a list

the only issue is if your input has duplicates

and you need them for some reason

no, i need it to be distinct so it's perfect

user=> (time (dotimes [m 10000] (->> (input) set (filter valid) sort)))
"Elapsed time: 272.51252 msecs"
user=> (time (dotimes [m 10000] (->> (input) set (set/intersection valid) sort)))
"Elapsed time: 271.146103 msecs"

@vale Just FYI, (time (dotimes ..)) doesn't always give you accurate benchmarks -- check out criterium for a better approach.

(uh-oh, is Alex going to correct me?)

with a big enough N and enough sample points, dotimes is sufficient, imo

And criterium is the agreed definition of "a big enough N and enough sample points" !

the fact that it loudly warns you if JIT is turned off is also a bonus

I find the benefit of NOT using criterium is that you can see when the jit is sufficiently warm when the sample stabilize

generally this is much faster than using criterium

I also don’t find that usually the gc stuff in criterium is worth much

and if you don’t use leiningen you never run into the jit thing :)