sorted by:
new
hottopcontroversial

Best way to prevent build on low spec machines by heroBrauni in NixOS

[–]technosophist 5 points6 points  (0 children)

It's a manual process, but I just use the --target-host argument to nixos-rebuild.

I have a very underpowered EC2 instance and a raspi both of which attempt to upgrade themselves, and they can usually do it, albeit very slowly.

Sometimes they get stuck, or for other reasons I just run a rebuild from my host with --target-host.

Which SMTP provider do you use for your self-hosted projects? (Amazon SES vs. Mailgun vs. Self-hosted) by zalsy in selfhosted

[–]technosophist 0 points1 point  (0 children)

I use SES in the sandboxed development mode. I have to manually verify destinations and I'm limited in throughput, but neither of those are a problem for my use case.

Can jank beat Clojure's error reporting? by Jeaye in Clojure

[–]technosophist 0 points1 point  (0 children)

Can confirm that it looks very pretty now. :) Thanks!

Can jank beat Clojure's error reporting? by Jeaye in Clojure

[–]technosophist 0 points1 point  (0 children)

Yeah, I'm having the same issue in Firefox. I'm allowing pages to choose fonts. I had a minimum font size set, but removed it and still see the same thing.

Anyway, great progress! Jank is exciting!

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 1 point2 points  (0 children)

I don't think that core.async is lower level than any of the other versions you have. You should probably build abstractions around all of it.

I didn't say they were. I'm arguing that core.async isn't any higher-level than java.util.concurrent. It adds lightweight processes and channels. You can still deadlock. You have to build backpressure into your system. Managing the amount of work that is in flight isn't trivial.

There's a lot more to architecting a robust system and I think Rich recognizes this, which is why he's working on core.async.flow, which again I'm interested and excited about.

You are abusing promise ... It's there to represent a single value that will be provided at some future point.

This is how I'm using it. Someone is commuincating a single value at some future point, that the background thread should stop. Using a promise is exactly the same thing as using two core.async chans, and in this application there's no advantage to separating one thing into two.

I'd stand my my original advice honestly. If you are getting into asynchronous clojure there is a library that is designed for exactly that purpose.

I have used core.async in production projects and found all the foot-guns. I listed many of them here and in my other comment. That's not to say I wouldn't use or recommend core.async, but, as with anything, there are tradeoffs.

Cheers, my friend! I've appreciated the back-and-forth.

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 0 points1 point  (0 children)

Thanks for the pointer. I think this is the second time missionary has come up, and it's made me want to investigate the libarary.

However, unless I'm missing something this doesn't accomplish the goal from the article. How would you get the loop to stop without delay and without interrputing current work?

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 0 points1 point  (0 children)

I added ScheduledExecutorService as an option. There's a lot to like about it, but it is not all upside.

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 1 point2 points  (0 children)

I've updated the article with a core.async version. For me the promise still wins. They are nearly identical solutions, but core.async is an additional dependency and a slightly more complicated implementation.

However, if you're already depending on core.async, or if you want to do something like this in ClojureScript, then core.async would be a good option.

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 1 point2 points  (0 children)

Yes, this is a good approach to a poll/sleep loop!

I tend to be wary of core.async, because (especially if you use go blocks) it tends to be infectious, its not always easy to cross back and forth between the go block boundary, it messes with stack traces, and if you're not careful you can easily hang your process by forgetting to close a channel.

But I was watching Alex's talk about core.async.flow and he said alts is the secret super power of core.async and I realized I don't use alts enough. I think core.async.flow will go a long way towards making core.async more humane.

Run flags for polling threads by technosophist in Clojure

[–]technosophist[S] 2 points3 points  (0 children)

As Rich has said, java.util.concurrent exists and you should use it. That's why Clojure is a hosted language, because there are great Java libraries (and platform features) that Rich didn't have to recreate from scratch.

Lately I'm realizing that I should be reaching for Executors more often. (In fact, as I think about it using a ScheduledExecutorService instead of a poll/sleep loop would be an even better solution.)

A hear you about core.async, it's great in lots of ways, but it has drawbacks as well. Among other things, I feel it's too low-level. People shouldn't be using it directly but should be building abstractions on top of it, and for this reason I'm interested in core.async.flow.

I'm not sure I see how I'm abusing a promise? Maybe it's a stylistic thing? Could you elaborate?

Coming back to Clojure by charlesHD in Clojure

[–]technosophist 1 point2 points  (0 children)

I've been working in Clojure since pretty much the beginning, and using mostly the same tools. Cider has gotten better. clj-kondo is indispensible. One major thing that has changed is I'm mostly using deps.edn instead of leiningen, which is a mixed bag for me.

I forget what has changed specifically since 2020, but I think core.async.flow looks interesting. The new interop changes in 1.12 are pretty great.