morning lovely people

o/

Morning!

\o

Morning

Do people mostly tend to use mapv rather than doseq for eager evaluation?

I’d use doseq where I want a nil i.e. pure effect, and an eager-like for, i.e. nested iteration… guessing you mean doall.

Ah I think we had a conversation about this the other day, quite a few different options depending on what you want to do

In which case it depends I think on whether you’re being given something that might be lazy… or if you’re in control and want something eager. I’d assume the later given your question. So if you have the control and want something eager, then you’re better creating it as such with either into, a transducer, or mapv — but also consider whether the datastructure is important.

I’ll definitely use into, mapv and doseq quite regularly, doall less so

yeah doall over a lazy seq that you’ve created is code you don’t need.

better to just create what you want directly

So, let's say I'm slurping a json file and creating a map, inside that map there is a key with a vector (of strings). I want to hit an API with each string, one after the other, would you invoke that API via a mapv (passing in each string) or a doseq?

What does the api return?

a json response that I'm just echoing out to the log

I’d probably use doseq or run! in that case, because there are only side effects, the return value not used

Yeah you shouldn’t use mapv to force effects

kk, thank you both! 🙂

be explicit about the effects, so doseq run! etc are much better.

https://clojuredocs.org/clojure.core/run%21 run! was the one I found out about the other day when we were chatting about this, I’d always used doseq before

which is perferred, doseq or run! (I seem to recall, somewhere, can't remember, that run! should be the first choice...can't remember the reasons)

use run! if you’re mapping an effectful procedure you already have over a sequence you already have (sounds like you do).

use doseq if you’re building the effects inline.

kk, thanks!

e.g. (run! println (range 10)) or

(doseq [i (range 10)]
  (dosomething! i ,,,)
  (dosomething-else! i)))

(run! (fn [vin] (check-eligibility vin)) vins) works grand! (I'll probably use a function literal, just playing...)

thanks both!

but it’s not the end of the world if you pick either way — it’s totally fine… I’m splitting hairs somewhat. A more important distinction is picking doseq if you want for-like comprehension behaviour.

i.e. nested iterations, :while :when :let are all useful.

that's great information, I'll keep a note of that.

I don't think I have ever used run!. Somehow it is one of those core functions that I always forget even exists.

Honestly, if I found a magic lamp, I think my first wish would be to have a complete mental catalogue of the clojure core API 🙂

\0

an unusual and humble request from a genie

I’m going to echo @wesley.hall here, I don’t think I’ve ever used run! to the point where I vaguely know what it does but can’t even remember the args >_<…

yep that’s basically what I’d use doseq for :)…

What is a bit confusing (for me at least!) is that in the run! docs, it says runs the supplied procedure, shouldn't it be runs the supplied function. I'm always thinking functions thesedays...

@danieleneal You only say that because I haven't told you my other two wishes 😛

ARe you planning on packaging your wishes up as a lazy sequence to get by the “you can’t wish for more wishes” rule

@dharrigan That might be a subtle nod to the fact that you don't care about / wont get the return value. "Function" implies input / output, I guess "procedure" describes a side-effect 'function'.

@danieleneal http://files.explosm.net/comics/Rob/genie-lamp.png

Perhaps, although still confusing! 😉

hahahah

@dharrigan an async viewpoint - for an api or other i/o op, and if you are using async i/o, you can do something somewhat different - and use a graph of (core.async) channels or (manifold) streams stream<op-metadata> ==> stream<promise<op-result>> ==> buffered-stream<promise<op-result>> ==> stream<op-result> and then you can use the size of the buffer to control concurrency (with backpressure)

in manifold terms this looks like (->> ops (s/map do-async-op-io) (s/buffer N) (s/realize-each) (s/reduce conj []))

that's very handy! copied into my review-later notes! 🙂

shout out to the collective wisdom - does anyone know of a linux (arch) utility that when fed a string (or some stdin), that it will display on the terminal in big bold letters (configurable) and a red line surrounding (configurable) the stdin - if you recall the guru meditation on amigas, you know what I mean 🙂

I suppose cowsay does what I want

toilet gets you some way as well

toilet -F border will put a simple border around the text -f term will just use regular letters rather than fancy figlet fonts

oooh

noice!

It doesn't really do colours unless you want a rainbow

its rainbow option does make for fabulous /etc/motd files 🙂

rainbows are fine 🙂

Who doesn't like a nice rainbow?

well quite

They have their place. Didn't think that's what you were going for with a guru meditation though 🙂

There was some interest in Clojure and Graal previously, eg. compiling JVM languages to native images, fast startup time, etc. Is there still interested in London Clojurians event on Graal?

One of the developers at Oracle is interested in doing a talk or workshop with the Clojure community in London. What sort of things would you find interesting??

@dharrigan for configurable letters, figlet? https://en.wikipedia.org/wiki/FIGlet

Thank you Jane 🙂

(oh, toilet is figlet++, nvm 😄 )

Its interesting to see projects such as clj-kondo using Graal to help distribute to different platforms. I havent looked into the detail, but it seem to give Clojure more reach...

@jr0cket I would be interested in seeing that, please record if possible 🙂

@borkdude will do. Just curious, do you use GraalVM native images to help startup time for clj-kondo ? I though you might be, but not 100% sure.

@jr0cket I compile to native using GraalVM yes

got three projects doing this: clj-kondo, babashka and jet

there's also a #graalvm channel btw

@jr0cket I think the native-image stuff has been talked to death. But the multi language features seem to have been under explored imo.

There's a lot of cool stuff in graal, and it's way more than just native image

@jr0cket am interested in the graal as well =)…

Night