This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (1)
- # announcements (4)
- # beginners (120)
- # calva (5)
- # cider (12)
- # clara (3)
- # cljdoc (48)
- # cljs-dev (33)
- # cljsrn (4)
- # clojure (124)
- # clojure-dev (43)
- # clojure-europe (2)
- # clojure-italy (168)
- # clojure-nl (2)
- # clojure-spec (7)
- # clojure-uk (79)
- # clojurescript (50)
- # core-logic (6)
- # cursive (12)
- # datascript (1)
- # datomic (8)
- # devcards (2)
- # emacs (5)
- # events (2)
- # figwheel-main (6)
- # fulcro (18)
- # graphql (42)
- # hyperfiddle (3)
- # jobs (1)
- # luminus (2)
- # nrepl (5)
- # off-topic (59)
- # onyx (5)
- # parinfer (2)
- # pathom (10)
- # pedestal (2)
- # portkey (3)
- # re-frame (24)
- # reagent (6)
- # reitit (54)
- # remote-jobs (1)
- # ring (5)
- # shadow-cljs (75)
- # spacemacs (35)
- # sql (22)
- # tools-deps (16)
- # unrepl (10)
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.
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.
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 https://twitter.com/garybernhardt/status/1067111872225136640
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.
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.
well, if someone offers to take over maintainership, they should be able to publish under their name right?
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
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
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
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
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?
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: https://www.reddit.com/r/Clojure/comments/a0xk0y/job_remote_looking_for_a_fullstack_clojure_web/
Any tips about how to handle
(class xx) => clojure.lang.ExceptionInfo (.toString xx) Evaluation error (StackOverflowError) at java.util.regex.Pattern$Branch.match (Pattern.java:4736). null
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.
(.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 (APersistentMap.java:29). null (class (.getData xx)) => clojure.lang.PersistentArrayMap (keys (.getData xx)) => (:clojure.spec.alpha/problems :clojure.spec.alpha/spec :clojure.spec.alpha/value :clojure.spec.alpha/fn :clojure.spec.alpha/args :clojure.spec.alpha/failure :clojure.spec.test.alpha/caller)
i remember hired man had a seemingly wild but accurate root cause on this: are you using rebel readline?
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.
@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.