Fork me on GitHub
#clojure
<
2021-11-12
>
genRaiy12:11:15

is there a way to retain metadata when transforming it eg via seq?

genRaiy12:11:26

here is an example

genRaiy12:11:14

(let [xform-meta :prn-xform]
  (meta (->> '[x y]
             (reduce (fn [form param]
                       (conj form (keyword param) param))
                     ^xform-meta ['prn]))))
=> {:tag :prn-xform}
(let [xform-meta :prn-xform]
  (meta (->> '[x y]
             (reduce (fn [form param]
                       (conj form (keyword param) param))
                     ^xform-meta ['prn])
             (seq))))
=> nil

p-himik13:11:27

By making your own wrapper for seq that preserves it.

Alex Miller (Clojure team)13:11:37

Generally coll fns preserve metadata, seq fns don’t

cursork13:11:51

Warning that nil won’t work with with-meta, so e.g.

user=> (with-meta (seq []) {:foo 1})
Execution error (NullPointerException) at user/eval144 (REPL:1).

genRaiy13:11:22

(meta (let [result (->> '[x y]
                        (reduce (fn [form param]
                                  (conj form (keyword param) param))
                                ['prn])
                        seq)]
        (with-meta result {:foo 1})))
=> {:foo 1}

genRaiy14:11:58

it's a hack but I'll take it

dpsutton16:11:47

my brain is foggy right now. Is there a function in core that given a predicate f and a collection col (X f coll) would return a pair of sequences, the items in coll satisfying the predicate and the items not satisfying the predicate? It’s kinda split-with but not exactly

dpsutton16:11:37

ah group-by. duckie

2
restenb16:11:32

would this be a sensible way to exit a go-loop that is doing work until some rare external event happens?

ghadi16:11:58

in general, pass the exit-ch or other signal channels in as arguments, rather than generating them within the process launcher

ghadi16:11:12

that way your processes are open to orchestration from the outside

ghadi16:11:59

but it sounds like you have the right idea: alt over your input channel & the signal channel

dpsutton16:11:47

passing in the quit channel allows a single channel to signal to possible multiple processes to stop? without hooking up everyone’s bespoke quit-chan to a central source?

ghadi16:11:43

correct

👍 1
restenb16:11:38

@dpsutton that's a good idea, as there will potentially be several "loopys" at the same time

dpsutton16:11:00

it’s ghadi’s idea. i was just fleshing out the reasoning so it was clear why it was a good idea

dpsutton16:11:29

“open to orchestration from the outside” can either be vague or borderline meaningless or completely clarifying depending on experience level 🙂

restenb16:11:22

another question I have is how to handle a long blocking op inside the go-loop. so far, i've chosen to wrap it in it's own thread: (<! (thread (long-blocking-op ...)))

restenb16:11:56

in my mind, this should park the go-loop thread & make it available again to the underlying threadpool while otherwise blocking.

restenb16:11:48

but to also facilitate loop exit I now have to wrap this in it's own channel again. this is hard to follow for monkey brains

restenb16:11:18

i guess it's still the same tho; everything inside go-loop gets put on one thread initially

sova-soars-the-sora20:11:12

Hi, got a dynamic var tryna call set! on it but Can't set! from non-binding thread :thinking_face:

dorab20:11:14

From https://clojure.org/reference/vars#set Currently, it is an error to attempt to set the root binding of a var using set!, i.e. var assignments are thread-local.

Alex Miller (Clojure team)20:11:46

you can only use set! when a value has already been bound on that thread using binding

Alex Miller (Clojure team)20:11:35

there are some cases you commonly see in your repl like (set! *warn-on-reflection* true) - these are actually not different because they have been bound by your repl using binding around the entire repl

sova-soars-the-sora20:11:02

Oh wow okay cool. news to me 😄 ty @alexmiller so maybe try and find a place to set! within a binding ?

Alex Miller (Clojure team)20:11:11

well you could maybe just use binding but hard to say without knowing anything else

sova-soars-the-sora20:11:40

Ah right on. Yeah I understand. Cool, will try that. ty

the-alchemist21:11:33

probably a question for @borkdude 😉 I’ve been curious whether anyone has looked into writing Clojure on Truffle, the GraalVM. would there be any benefit? I don’t know enough about compiler theory to make an educated guess. I even noticed that there’s a Lisp-y language already implemented using Truffle: https://github.com/cesquivias/mumbler

borkdude21:11:00

I've looked into a bit, and other have too

1
borkdude22:11:36

From a performance perspective there are some small gains to be made when it comes to numerical things. But I don't expect major gains in terms of general performance since you're trading JIT with Truffle specialization. Truffle languages do compile to native image as well, so it could be interesting to make a thing like babashka but this is more heavy weight: it doesn't yield small binaries and interaction with other classes outside of the graal context can be more complex. There is also Espresso which is a Truffle bytecode interpreter which can be used to interpret the bytecode that the Clojure compiler produces, but currently it is pretty slow both to start up and performance.

borkdude22:11:59

There is a thesis from 2015 on this. Also @U02H98RUV3M is currently doing his thesis on this subject.

👍 1
the-alchemist22:11:12

thanks so much for the informative answer, @borkdude!

sova-soars-the-sora21:11:09

:^dynamic atoms ended up being a better solution that work with reset!

hiredman21:11:39

sounds horrendous

hiredman21:11:11

using more than one atom is often a mistake, using reset! is often a mistake, using :dynamic is often a mistake, combining them all, well 😬

👆 1
sova-soars-the-sora04:11:39

lol well let's see if i can provide some context and we can brain storm healthier alternatives...

Alex Miller (Clojure team)21:11:29

yeah, I would question that that's the best option. but if you share more, maybe we could help more