what's an idiomatic way of abstracting over a value that could be either a map or a set?

i.e a hashed collection where I'm only interested in its keys

contains? works on both types

but removing items is awkward:

(if (associative? coll)
  (dissoc coll k)
  (disj coll k))

you could do something clever with remove

(into (empty coll) (remove (k coll) coll))

@qythium Perhaps convert the set to a hash map (where you don't care about the values)?

I would be suspicious of a function that could accept both a set and a hash map -- that suggests there's something wrong with the abstractions being used in the program perhaps?

user=> (let [s #{:a :b :c :f :h}] (zipmap s s)) ; no need for this (into {} (map vector s s))
{:c :c, :h :h, :b :b, :f :f, :a :a}

(and if you need to get a set back, (into #{} (keys s)) where s is your hash map "set")

Thanks, I was actually "broadening" the type of an object from a set to a map, to account for cases where I would need an optional "label" for a key

and wondering if there was a way to do so without having to go around and refactor all the function calls

would (zipmap s s) be equivalent to the above?

Yes, that would be simpler. My bad.

thanks 🙂 I suppose the order of sequencing s is guaranteed to be the same for both arguments of zipmap, even though it's unordered

Hello all, I want to do something like this: - Having a big list/vector/something else ... with (it´s a list of ips) - Having like n 'consumers' that will "consume" the element of this list in thread, not more than n running at the same time Is that possible? How can I limit the n running thread function at the same time?

Queue + worker pool

= Java executor

Hi. I was expecting to get "hola" everywhere. Is there something about map that ignores the binding?

map is lazy, so it returns a lazy seq of pending calls to f

you are forcing those calls in printing the result returned from the binding (after the binding has been popped)

pmap is sending those calls off in binding scope and then lazily looking at the results

many ways to alter behavior here, but changing map to mapv would make it eager

for a side-effecting thing like this, usually run! is preferred to map

(defn hrm []
  (prn "M" *xxx*)
  (run! f [1 2 3]))

Ah, thanks. Forgot about the laziness of map 🙂 I'll go with mapv as my actual code does other things.

that's also sufficient to fix this. returns nil instead, rather than (nil nil nil)

or wrap a doall around the map call

Is there a simpler way to do the following?

dev=> (join "." (filter some? ["a" nil]))
"a"
dev=> (join "." (filter some? ["a" "b"]))
"a.b"

that's pretty simple ...

I suppose so

I would thread that

(->> ["a" "b"] (filter some?) (join "."))

I feel like the nonthreaded is a little easier to read

Thanks for the input 🙂

some? to me implies caring about false

user=> (some? false)
true

perhaps it could be clearer with (filter string?) @robertfrederickwarner

That's true, I like that. Thanks!

no that's false 😂

string.join can handle non-strings. it will attempt to coerce them

(str/join "." [:a "b" 3]) so it depends on what is unacceptable to you

it's the nils I need to avoid

dev=> (join "." ["a" nil])
"a."

I want that to come out as "a"

then string? is not what you want

I see your point

unless you can keep nils out higher up or make sure only strings end up. then you can filter str/blank?

(end up in your collection i mean)

`(join "." (keep some? coll))` ? - incorrect

The second value is coming out of an associative destructuring, so I could set a default for that to be ""

consider (remove nil?) or (filter identity)

I still think some? implies caring about false

(remove nil?) is pretty explicit, I like that

See also keep.

but keep is like map - it transforms the elements (often you can avoid needing a filter identity by using keep instead of map)

nothing beats (remove nil?) when your goal is to remove nils imo

it's like literally the same words :)

hey, any tips on testing of private functions? wrap them with with-test?

use #'my/foo to invoke them via the var

vars that refer to functions can be invoked and will invoke the function they refer to

Thanks 🙂 I was wondering if that was the more canonical options, b/c people have presented it as something of a hack

I believe it's a fine thing to do :)

go forth and test thy private functions :)

Is there anyway to select keys based off a regex?

So re date-times, if you have an inst in clojure that is particularly long ago, like #inst "0001-01-01". If you convert that to an Instant, you get a particular strange representation of “0000-12-30T00:00:00Z”. I guess that sense because of shifts in calendar systems between now and thousands of years ago, but what is the inst actually representing, where is this difference in presentation coming from

#inst is not any particular type

abstractly true, but if you literally type #inst ..., you'll get a java.util.Date and that's kind of baked in

so you could rephrase as, if I have a java.util.Date representing some very old instant, and format it with "whatever inst uses", why does it present in this way?

getting Clojure mostly out of the way to leave you with a Java question

off the top of my head, I have no idea

when you say "convert that to an Instant" that is almost certainly where the difference is introduced

and you'll have to be more specific about how that is done

yeah, that would be my question too

.toInstant()?

yeah, toInstant does this indeed

Date.toInstant() does Instant.ofEpochMilli(getTime()) where "getTime()" is just long millis since the beginning of 1970 (when all time began)

right, so they are both the same value so to say, but they are shown differently

they have the same number of milliseconds since epoch

I don’t feel like I am posing a coherent question, sorry!

odd its 12-30 not 12-31

prob a leap day kind of thing somewhere I'd guess

but i think this is a timezone thing maybe?

Clojure 1.10.0
user=> #inst "0001-01-01"
#inst "0001-01-01T00:00:00.000-00:00"
user=>

but i'm guessing its a UTC and then local time thing

and in a few hours i'll see it too

I don't think I'd rely much on the Instant object toString() you're seeing in there

the Z means UTC correct?

yes

this makes sense to me (modulo the 12-30 not 12-31).

Okay, not my most coherent question, thanks for thinking along…

You’re not going to get year 0 you shouldn’t be getting year 0, b/c year 0 does not exist (if you use the AD/BC aka CE/BCE)

…except in ISO when it is, turns out. https://en.wikipedia.org/wiki/Year_zero#ISO_8601 Calendars in the deep past are worse than handling summer/winter time and leap years 🙂