Clojurians Log v2

can someone comment on how mixing time bits into an uuid affect its randomness? can you "predict" an uuid generated like this? https://gist.github.com/valerauko/138978741ef9477104eac5796195e61e

generally, I don't think uuids are meant to be completely unpredictable. if it's critical to security, then I would probably use some other method.

Good morning! I'm reading Alex Miller's book Programming Clojure. I stumbled some on an example of a function blank? for checking if a string is empty or only has whitespace in it:

(​defn​ blank? [str]
​ 	  (every? #(Character/isWhitespace %) str))

Character is a java class, you can't do anything at all with it from clojurescript

In general, books and materials covering clojure cover clojure and not clojurescript and you should not expect the code in them to be valid clojurescript

For the record, I didn't expect that. I just don't have a Clojure REPL handy so I tried to make do with what I have.

I figured out a way to use Replete for this:

(defn not-blank? [s]
 (not-every? #(re-matches #"\s" (str %)) s))

not-every? Is defined as (comp not every?) so it's truth table is exactly the inverse of every?

Thanks! Being on a phone is not optimal when wondering such things. I guessed that would be the definition.

Like every? corresponds with forall, some corresponds with there exists

So you can turn them into each other by shuffling not arround

some confuses me a lot. Not sure why.

(not-every? f s) => (some (comp not f) s)

Could I define every? using some in a similar way? I'm trying to answer it myself, but I fail...

How do you got from not-every? to every?

I mean, you can work it out as an equation

@pez some is like keep but for the first element

If (not-every? f s) = (some (comp not f) s)

And you know not-every? has the inverse truth table to every?, what do you need to do to the left side to turn it into an every?, and then just make sure to do the same thing to the right side

That is the thing with some, it most often not used as a predicate, which can be confusing

(defn my-every? [pred coll]
 ((comp not some) (comp not pred) coll))

There are a lot of examples on some at clojuredocs. Reading them with your hint, @borkdude , really helps!

Does anyone have any favourite open-source code showing how to do background worker threads in a web app? I’m trying to figure out how to do the kinds of things I used to do with Sidekiq in Ruby: send emails, render PDFs, etc. I’m having trouble setting this up reliably with core.async.

is there an easy way to read an input string using some popup in CIDER / emacs? like (read-line) but more visible for in a demo

core.async isn't persistent though so the purpose is a little different

there are redis/rdb backed job queues for clojure too iirc

We’ve been trying to move separate processes along an event log but we’re have some trouble with exceptions killing off a worker and figuring out how best to handle retries, supervision etc. and I’m presuming it’s not necessary for us to reinvent this stuff.

When working with sets is there a performance difference between these two when checking if a set is empty?

(seq #{1 2 3})   ; is one of these faster?
(first #{1 2 3})

The second one will give a misleading reading if the set contains nil and that happens to be the value you get @martinklepsch

also just empty? works

which is implemented via (not (seq ...))

Though I will ignore this advice in the docstring forever more

Please use the idiom (seq x) rather than (not (empty? x))

If the argument to first is not already an ISeq, then first calls seq on its argument, so even aside from first potentially giving the wrong answer, it's definitely going to be slower.

static public Object first(Object x){
	if(x instanceof ISeq)
		return ((ISeq) x).first();
	ISeq seq = seq(x);
	if(seq == null)
		return null;
	return seq.first();
}

all first does is call this method in clojure.lang.RT

If the seq isn't empty and you get the first element, i know that a lazy-seq might realize 32 elements at that point

so calling .first() might potentially add work

cool, very interesting

but besides that, worst case its a second null check

and direct static method calls - including invokeStatic on clojure.core$first - are the exact kind of thing hotspot can inline if it is hot

same thing with redundant null checks

so as per usual, wait til there is a problem and measure - but seq/empty? are what will deal with null elements

Yeah, so core.async probably isn't your best path

That is made mostly with light interprocess communication in mind

If you want actual background worker threads, you should use an ExecutorService

yeah makes sense, I didn’t actually run into any issues, I was just wondering since, yeah converting to a seq seems like a step that may not be necessary, didn’t consider that first would also do that but makes perfect sense

There are more complete libraries, like quartz, that will have more feature parity with sidekiq

but for basic stuff, submitting tasks to an ExecutorService is the way to go

(defn create-background-executor []
  (Executors/newFixedThreadPool 8))

(defn submit-job! [background-executor job]
  (.submit background-executor
           (reify Runnable
             (run [_] 
               (job))))

Then there are simple enough ways to make a job retry a certain number of times and whatnot

but if you want actual persistent background jobs that will survive a restart and whatnot then something like this might be useful https://www.jobrunr.io/en/

oh, nice…. thank you. This is another of those areas where coming in to Clojure via ClojureScript has me at a disadvantage, not having ever really worked in Java.

I don't even remember my learning order, but the Stockholm syndrome of java has definitely set in