Fork me on GitHub

Has anyone used curved monitors? There are some nice large ones for sale as it's "cyber" monday and just curious about any opinions


I used a 27" 16:9 curved. Mostly a gimmick. The curve makes a bit of sense at 21:9 though. But at that aspect ratio, 29" seems like not enough vertical real estate as compared to a 27" 16:9, and a 34" 21:9 is just too big for me. I heard light bleed is more of an issue in the curved ones. YMMV.

Drew Verlee05:11:23

also try to find a price history, i feel a lot of sales aren't really sales


Office neighbor has one and said it's a gimmick too.


he got a cheap one from a brand I never hear of tho, so maybe that something to take into factor, might not be the best quality out there.


rich hickey gist ^


It's pretty insane how many people have the mentality of "I prefer FOO; so the community has to do FOO." instead of "I prefer FOO; so I'm going to fork the codebase to do FOO."


That or "I prefer FOO; but I don't have big problems with BAR so I'm not going to complain about it."


speaking of a world where more developers have the freedom to contribute to open source projects


In fairness, there are more options than “let’s allow anyone to push whatever code they want” and “let’s only allow one person to enact changes”


yeah, I was just posting it for the effect. I've seen all kinds of manifestations of open source software be successful.


shame though, This basically opens up everyone tangentially responsible up to have fingers pointed at them publicly and pretty aggressively.

Lennart Buit07:11:28

I like how people were like: but you maintain this, you MUST maintain this

Lennart Buit07:11:48

I understand that it is nice that (s)he would maintain it

Lennart Buit07:11:53

but there is no obligation whatsoever

Lennart Buit07:11:06

and usually, when you stop maintaining something its not because you don’t want to but because you can’t. So someone dropping by saying “ahh I’ll do it”, that initially looks like a win


I have a (maybe extreme?) opinion that you should just not be able to transition a repo or npm module to someone else.

💯 4

especially a module

Lennart Buit08:11:01

well, if someone offers to take over maintainership, they should be able to publish under their name right?


IMO no. they should fork it and release it under a new name


if the old maintainer wants to endorse the fork they can update their README or whatever to say it’s deprecated and to move on to a fork

☝️ 4
Lennart Buit08:11:54

well, I see difference in forking for the purpose of diverging from the source, and/or faithfully taking over maintainership. But I get your point


forks and responsibility is quite difficult. Especially in Clojure with maven.


If I fork a library, and keep the namespaces unchanged, then we end up with conflicts. If I fork a library and change the namespaces, then none of my dependencies will use my fork. So I have to go fork them, and convince them that my fork is better. I have no autonomy as a user.


I guess the problem is not really about the fact he/she didn't want to maintain it, more with giving the keys to somebody else without much checking/knowing on this person. This is (imho) a poor project management problem more than anything related to "freedom to contribute to open source projects" at large

👍 4

I guess forking exists for a reason and it's cheap to do.


To what extend do you want to check? He did made some pr's previous to the request.


co-habitation might be a good place to start I suppose. But if you're determined to be malicious, you can always wait it out.


I think that statement has changed my stance on the js debacle somewhat :thinking_face:


I suppose you can only trust authors, not libraries. If you update a library, and it isn't signed by someone you trust, then you should check whether you trust this someone.


@gklijs he had no contrib into the project before being given write access as far as I can see


also, ownership transfer on npm is the most problematic thing imho


I’m glad that tools-deps sidesteps that quite nicely — but we also all depend to any kind of opaque Java.class blob on maven, right?


amen to that (tools-deps)


At least it's a lot harder to put something in maven central then on npm


Fun stuff


I think a few things help in Clojure. It is batteries included, so you should try and can very much use as little dependencies as possible. I think JS has a "framework" culture that isn't very healthy. You should be able to put together your own, only hard things should require a dependency, like auth/crypto, serialization, http parsing/routing, etc. After that, the culture of never breaking also means you don't always need to upgrade. So you can spend some time reviewing the dependencies you're depending on. Going through their CRs, maintainer list, etc.


We are looking for remote Clojure developers @ Medical Database. Here is the job posting on Reddit:


Any tips about how to handle

(class xx)
=> clojure.lang.ExceptionInfo
(.toString xx)
Evaluation error (StackOverflowError) at java.util.regex.Pattern$Branch.match (


Are you using Leiningen? If so, do you have anything in your $HOME/.lein/profiles.clj file or a user.clj file that might be causing troubles? (e.g. do you get the same result if you temporarily rename those files, start another repl, and try again?)


I half-recall seeing something similar in the last couple of weeks, but don't recall if the root cause was discovered.


is a odd exception


Not in Slack history any longer, though.


(.getMessage xx)
=> "Call to #'com.wsscode.pathom.diplomat.http/request did not conform to spec."
(.getData xx)
Error printing return value (StackOverflowError) at clojure.lang.APersistentMap.cons (
(class (.getData xx))
=> clojure.lang.PersistentArrayMap
(keys (.getData xx))


i remember hired man had a seemingly wild but accurate root cause on this: are you using rebel readline?


I'm on cursive repl stack overflow on (.toString xx) discard repl problems I think


I'm not sure they do, as I think some REPL plugins monkey-patch the way exceptions are printed, including perhaps .toString


Sorry, that is just a shot in the dark, though, not a solution. I don't know the explanation now.


(binding [*print-level* 2] (.toString xx)) works 🙂 #clojure-spec generates a really deep map


@souenzzo Does that exception also happen in a lein REPL? That would help isolate whether Cursive’s exception printing is responsible or not.


I will create a one-line clj to reproduce at home

Alex Miller (Clojure team)22:11:35

@souenzzo is this Clojure 1.10 per chance?


@alexmiller i'm on RC2 🙂 Find out that the "minimal example" just trows a huge exception. I guess that could combinatorial spec error that goes crazy-huge with my pathom schema. I will debug at #pathom channel.

Alex Miller (Clojure team)23:11:36

hrm, just wanted to make sure it’s not new error handling code

Alex Miller (Clojure team)23:11:11

So would be curious if you tried with1.9