depends on the size you're looking for: but minimum requirements would be 4k and usbc support

I have a DELL-U2720Q I am quite happy with, 27 inches with all the above

difficult to go wrong with the "mid/high end" dell monitors

you might want to stay away from 120+hz with an air, but I could be wrong.

oh! https://tonsky.me/blog/monitors-mac/

yes, 4k + usbc. One thing I'm always worried about is the default font size to be big enough. I once bought a 25" monitor of which the fonts rendered just a bit too small so I sold it eventually since the scaling didn't properly work

I'm currently working on a Full HD screen but after getting used to Retina it's a bit dissatisfying

Thanks for the link

It seems there is only one 27" screen in that list and it doesn't come with usbc

cc @U050UBKAA

This site has some recommendations I considered to buy a monitor recently: https://www.rtings.com/monitor/reviews/best/monitors#recommendation_242478

My work supplied me with a HP z27, 4k, usb-c hub

although my example has a bit of coil whine, not sure if thats a common problem.

@UDF11HLKC Is this connected to a macbook air m1?

no, macbook pro (also M1 tho)

I’m using LG 27GP950-B (4k @ 144Hz) with USB-C to DP cable. If you don’t care about 144Hz, I’d recommend Huawey MateView 28, as it gives a bit of extra vertical space in addition to usual 4k

I’m fine with 4k 27", it’s large, yes, but I like it. I know some people can’t stand that, for them, I guess, the only option is Apple 5k or 6k super-expensive displays

@U050UBKAA I think that when you're satisfied with the LG, I'll surely be satisfied ;). Does the scaling option work in macOS? I'm always afraid I will buy the wrong monitor with tiny fonts in macOS that can't scale

And does it work with macbook m1 air?

Gigabyte M28U is probably another good option

I don’t use scaling, always 2x, so I have as much space as 1080p but at 2x retina resolution

In my past experience, scaling slows down macbook a lot and lines are not perfect, so it’s a pass for me

but the default is good enough, to not have too tiny fonts? I've had this with a 25" qhd monitor once, trauma

They are rather large, not tiny

GB looks interesting, it has usb-c

Air M1 is 227 ppi, 4k 27" is 163 ppi, so ~1.4 times larger than on macbook

Right, I had 117 ppi with a 25" one which was too tiny. I guess ppi/dpi is the thing I should look out for

Yep

Thanks a lot niki!

Every 6 months I come back to Niki's incredible blog post. Thank you so much Niki!

For the M1 Air, the ultra wide screens are a nice alternative to the old double externa screens setup.

I have LG 27UK850 with USB-C and an Air M2 and it works really well. Air (M1, M2) internal display comes with an unnatural scaling, I did like Niki recommends and upscaled it up to 2x (a natural scale factor, then). I don't remember if I've had to do likewise for the Air to scale the external LG 27UK850 to 2x, or if it does it by default. Size is fine to me.

If LG is interesting to you, @U04V15CAJ I can borrow wife's Air M1 and do some tests for you; maybe take some pictures with the iphone of both its internal and external screens together.

@U0514DPR7 yes please!

also check the refresh rate when connected to it

Following pictures are of Air M2 (wife is out with M1 this morning…) M1 will behave the same since M2 didn’t improve anything display-wise IIRW, and I can confirm later M1 displays the same at 4K 60Hz. (The other external monitors on left and right are displaying from another computer.)

Whoa, looks like picture quality is useless, let me check if I can do better.

I think I get the idea though. The font size looks like I could read it :)

Font size looks roughly 1.5 times bigger than internal monitor (but obviously we keep the big screen farther away, and at my viewing distance it still looks bigger than my scaled up M2 monitor).

Personally I dream of a 5K monitor so that 2 side-by-side windows might show more content, but find the prices for 5K monitors unthinkable.

so even the "more text" thing works on macos with that display, interesting

more text?

sorry, "larger text"

it should work with any display, and if it doesn’t, try Option-click “Scaled” and it should show even more options.

I think it only works with hidpi displays

with my current full hd monitor it only shows other resolutions and this scales the screen in a weird way

Oh, yes, you’re right. Still, option-clicking around in this system settings dialog shows more options for any external monitor (more resolution choices, more refresh rate settings sometimes).

it doesn't for this one, but it's good to know it works for your lg display

BTW were you already operating your internal monitor at 2x scaling, or at its default of 1.5x?

I'm not using my laptop monitor currently

Ok; I could have taken pics of internal at its default (even smaller characters) to make the comparison more obvious, if that’s what you use when in “full portability mode” But I realize it might not really be pertinent. 🙂

Since M1/M2 devices get quirky with multiple monitors, I would get a single huge monitor (perhaps ultrawide) instead of a dual-monitor setup.

I am secrely coveting this extreme monitor: https://www.youtube.com/watch?v=MEiq0oCUb_8 I want the parentheses literally watching me from the above.

@U04V15CAJ Wife is back. I took a pic with her Air M1 hooked up to the LG 27UK850. Everything is identical to the M2. Same scaling options, same 60 Hz. So no point in working to share the pic here, unless you want proof. 😄

I believe you! It seems the monitor isn't available anymore in shops here in NL, but I'll keep an eye out.

I don't think the 120 Hz is so important to me so I'll probably go with 60hz LG screen

I think it needs to somehow think about table-tests (something in the direction of golang) so that people wouldn't do this: https://github.com/clojure-vim/clojure.vim/blob/master/clj/test/vim/syntax_test.clj#L113 IMO these kinds of macros that people can write are not good. I was editing that code and what it does is that kw and !kw are declared as predicates at the top which check for a key existence in a code result (the code that you test is supposed to return a list). So the testing macro itself takes this predicate and tests whether the kw or !kw predicate matches and then fails or passes. And as it does that it breaks run-current-test runners in IDEs and you're forced to rerun whole test namespace each time, for instance. I think that the reason why the author wrote it this way was because there was no easy way to do "table tests" and he invented his own by runing defn and other stuff in his macros. Also the tests that are in that file are very shallow so I actually don't really see much benefit in having them at all as they basically don't check anything.

Fixtures I want to be able to pass arguments into tests

@UK0810AQ2 Why isn't this good enough? https://clojuredocs.org/clojure.test/use-fixtures Edit: I used fixtures to run something once per namespace and it worked alright

Because I don't want to use dynamic variables

Also, some mechanism similar to how Unison lets you attach examples as tests to metadata

setup and teardown functions that work per file, per test, and per suite

> setup and teardown functions Cora, he didn't like when I proposed to use the same thing. > I don't want to use dynamic variables I think you confuse two things -- the assertion part and the initialization part. If you don't want to use fixtures then don't use the builtin fixtures and simply create your states on your own. This way you will have what you expect. But if you run a lot of computation per namespace (not per test suite) then there is no other way and I don't think there is a better way. Also IMO it's always best to do the is assertions outside of your logic because this way you can deterministically see the results when evaluating by hand. I don't think you can beat this by any means. I think this is an anti-pattern because if a and b are hard to initialize then you have to add even more code to even see c in REPL:

(testing "my-numbers-one"
  (let [a (my-complex-fn-a 1)
        b (my-complex-fn-b 1)]
    (is (= a 1))
    (is (= b 2))
    (let [c (my-complex-fn-c a b)]
      (is (= c 3)))))

• remove fixtures • add before, before-each, after-each, and after functions/macros that can be used outside or inside deftests • change testing so it creates a new nested testing context like deftest (these two would act like javascript’s Mocha framework) • change assertion interface to throw an exception instead of printing, and then have deftest catch it

Sure. https://www.lambdatest.com/mocha-js: > Since 2016, Mocha has shown a constant decrease in the percentage of satisfying the testers and developer community. The level of satisfaction has dropped from 94% in 2016 to 69% in 2021. There already exists such a framework and I used it. And then I refactored my code to use the stock Clojure's core.test because I didn't like how it worked anymore. https://github.com/slagyr/speclj#a-sample-spec-file I think that if you like it then you could try to use it

Sure, speclj is cool and it looks like it's getting developed again, which is great. I tried it a couple years ago and ran into some issues so stopped using it due to lack of activity. It’s not exactly how I described or how I imagine a generic test framework would look tho

Add to that around that expands to before and after Name the before and after steps Specify dependencies between them Resolve them topologically Have the option to refer to the context Basically, Component

For me Component sounds like OOP, but you could get away with a wrapper function that you pass a function which you call is from. Or you could do doall and return the items which would be way better. Could you tell why any of these are bad?

(testing "my-numbers-one"
  (is (= [:a :b :c]
         (with-my-resource ;; this could do init and teardown
           (fn [res]
             (doall (.getItems res)))))))

(testing "my-numbers-two"
  (is (= [:a :b :c]
         (with-open [res (new init-stuff)] ;; AutoCloseable
           (doall (.getItems res))))))

Component has nothing to do with OOP. If anything, it's closer to dataflow

I want my test code to not be intertwined with setup and teardown, while not losing the context of setup and teardown. Fixtures make me play computer and destroy my ability to reason about my tests

Do you prefer nested describes that change the states of the objects? I think nested describes are not a good pattern because when I refactor I tend to rewrite very many tests. I think that when I use nested describe then I couple the test behavior to the code. And I don't like to have it because if I change method invocation order (in JS OOP) then I have to rewrite my tests as they're very coupled. Edit: This was the reason why I moved away from speclj. It works and it's nice to write it initially. But when I came back to my code I was changing small things and needed to rewrite large chunks of tests. Maybe I'm somehow wrong, I don't know.

I prefer no change of state and not to think of any object

Buf if you do this you are introducing context:

(describe
 (let [a []]
   (describe
    (let [b (my-fn a)]
      (describe
       (let [c (my-fn-2 a b)]
         (it (should= c :hello))))))))

> Also, some mechanism similar to how Unison lets you attach examples as tests to metadata @UK0810AQ2 Not familiar with Unison. But are you talking about this?

(require '[clojure.test :as t])

(defn foo [x] 
  {:test (fn [] (t/is (= 2 (foo 1))))}
  (+ x 1))

(t/with-test
 (defn foo [x] (+ x 1))
 (t/is (= 2 (foo 1))))

@U90R0EPHA yes but as data, not code Imagine a sequence of pairs which will be checked as if by are And to be able to see it as part of the docs

After thinking about it a bit, I feel like the biggest limiter is the simplicity of assertions and the tight coupling of “building an assertion result” with “printing an assertion result”. If failed assertions threw an ex-info with the :expected and :actual and :msg data, then any runner could decide how they want to format the output

This would also solve the problem of attaching line and character info to failures automatically and would handle exceptions thrown from non-assertions

But it would short-circuit the tests and wouldn't run later ones if there are more is calls in the same level (would you want to support this kind of side-effect-y code?). The printer could instead print not into the command line but it could print into a data structure and then return it as a result. You'd be doing this conversion from Exception anyway :thinking_face:

I prefer to not run further assertions if an assertion fails. If my function is implemented wrong, logging 10 variations of “it's wrong” is deeply unhelpful.

That sounds like something that should be configurable by the user?

Probably. I don’t know if it's possible with clojure.test at the moment

> I think it needs to somehow think about table-tests (something in the direction of golang) so that people wouldn't do this: https://github.com/clojure-vim/clojure.vim/blob/master/clj/test/vim/syntax_test.clj#L113 are fits the bill perfectly for table tests. It's really worth mastering. @U42REFCKA’s recent https://github.com/camsaul/humane-are is a nicer are . Traditionally I just write are with some very minimal ceremony to achieve the same niceties.

it would be nice to have some a way to add new assertions similar to thrown? in a way that is friendly to clj-kondo

If you don't mind, what don't you like about the expectations.clojure.test-style macro that throws that you require in your test namespace?

specifically I want not-thrown?

and I don't know enough about expectations.clojure.test to really speak on it. my team doesn't use it. we're talking about improving clojure.test, aren't we?

(I'm assuming you were asking me, Noah)

Sorry, yeah, I was thinking of a stopgap solution you could use immediately instead of just letting you combination complain+daydream (as we all are lol)

Looks like this: https://github.com/clojure-expectations/clojure-test/blob/031f55fe494d3cbf1e77039a41b2b2a60048a11a/src/expectations/clojure/test.cljc#L41

there are ways to extend clojure.test's assertions https://stackoverflow.com/a/72657274

but clj-kondo doesn't recognize them

so it's probably more of a thing that could be fixed in kondo, or kondo could be extended to work with it, than has to be fixed in clojure.test

The are macro is already better than the custom macro from my initial example because I can run that single testsuite with CIDER-nREPL code. But it would be really nice that if it would provide line numbers of each failed assertion :thinking_face:

Sorry, @U02N27RK69K, seems I'm not being clear, my apologies. I mean that for a given codebase that defines a new assert-expr, it could/should also define a macro of the same name that expands to throwing an exception, so for example when you use not-thrown? in a test file, you can require it from the defining namespace to provide proper linting while also providing better error messages if you use it incorrectly.

If you already understood that, then oops lol

ahhhh I see

right

I believe you showed me that the other day

😅

Hah yeah, no worries. My question remains, then: if you don't mind, what don't you like about this method of handling things?

I don't much like having to nest it directly under is and this feels like a workaround for that

What I don't like is that thrown? and thrown-with-msg? are implemented as dirty macro exprs which aren't syntax-completable. I think that you have to be able to import them :thinking_face: I have to google every time how to write the thrown-msg thing and I can't ever remember. Then I find a post like that to simply remember it: https://stackoverflow.com/questions/53494704/thrown-with-msg-throws-runtimeexception-with-unsupported-character And when I finally write it correctly... what is the signature again? Oh hey, it works with two inputs... but I remember I have to put in a regex somewhere... I don't know, let's open docs again..... that's not good. It has to also fail if I don't provide a regex. Also when you have those forms you can't jump to their documentation because... they're not macros.

perhaps relevant https://stuartsierra.com/2016/05/19/fixtures-as-caches

@UCFG3SDFV https://github.com/clojure-expectations/clojure-test -- I liked the "Classic" Expectations that Jay Fields designed but the lack of compatibility with clojure.test was a problem (esp. auto-generation of test names, since they aren't stable so they don't work with most clojure.test tooling or REPL workflows -- same criticism for RCF BTW). I like the expressiveness of (expect predicate (some-expression)) and some of the more* higher-order predicates. I agree that fixtures are a bit clunky -- stuck onto namespaces as metadata -- and I haven't yet come up with anything better in Expectations (but I've been thinking about it recently).

For me, a better ClojureScript support for async tests. Maybe something that understand JS promises, or something that configures a timeout, etc...

Others have already mentioned fixtures which is a pain point for me, especially not being able to alter/apply fixtures per-test. Another one for me is that the difference between deftest and testing to me feels like an unnecessarily arbitrary distinction. People end up in discussions about how big deftests should be and how much to use testing, but to me that seems like an artifact of the fact that you can only apply fixtures on a deftest. I’d instead go for an approach more like https://hspec.github.io/writing-specs.html where test suites form a tree with fixture-like hooks (before, after, around) and context groups as branches and assertions as leaves. Context groups and assertions are all individually addressable, meaning you can focus on a whole suite, any size group, or even a single assertion. There’s no need for fixtures because there’s no longer anything special about them: they’re just (often inline) functions used in hooks, no different from your setup and teardown code. The whole thing feels like an obvious generalization in retrospect, it takes your tests from being piles of imperative slush to wonderfullyl decoupled setup/teardowns and assertions. I sketched out a design for this in Clojure at one point, but I never got it beyond the prototype stage. It’s something I’ve been thinking about going back to if/when I take a sabbatical, though if anyone’s interested in working on it I’d happily turn over my notes.

Ooooh that's super cool! I had a discussion with a coworker about how one might write such a thing in Clojure but we also never followed up. Thanks for the link, my Haskell is poor but I bet I can glean something useful

that reminds me a ton of rspec

from ruby, I mean

Hspec was inspired by rspec but takes the assertion/group addressability to a new level. I don't think it'd be all that hard to write as an integration for Kaocha, kaocha already models tests as a tree so you'd just have to map the nodes. There's obviously a few wrinkles: you need to figure out how to bind variables in hooks so they're available in assertions (hint: dynamically), and there's some funny business around getting before-each/after-each hooks to execute both in the right place in the tree and with respect to each other, but I think those are solvable problems. I think the hardest bit might be that clojure.test is so ingrained in the ecosystem wrt test discovery, result reporting, focus addressing, etc that an incompatible model might have to reinvent a lot of stuff

Since I mentioned Unison previously https://www.unison-lang.org/learn/tour/#testing-your-code

The docs system can include links and embedded code https://www.unison-lang.org/learn/usage-topics/documentation/

the location something is hosted in doesn't matter, what matters is the timezone configuration of the software on the server

it is very common to run servers configured with the utc timezone

ah ok I thought it might be UTC but I just wanted to verify, thanks

depending on who you ask, the best way to store times in the database is either "store it without a timezone and just always make everything utc everywhere" or "store it with a timezone just in case, but also use utc everywhere"

you can also get time oddities where you have a time in utc, insert it into a field that doesn't store the timestamp, then read it out, and the jdbc driver attaches your local timezone to times without a timezone, so now the utc time looks like a local time, and then clojure when printing out inst tagged literals converts them to utc

so your utc date is interpreted as a local time, then re-adjusted to be a utc time then printed

does next.jdbc print #inst tag literals as UTC by default? or am I misunderstanding

or is that Clojure specific behavior

that is a clojure feature

and it is just how it prints

the underlying data might be in any timezone

how sure are you that java-http-clj/get is returning a body of "{}" ?

like, if it is actually get a response from the other end and the response is complete and it is being return, it seems like that would be a be some difference in how the server you are connecting to is handling requests

there is an issue open on the lambda emulator repo (https://github.com/aws/aws-lambda-runtime-interface-emulator/issues/21) that suggests it returns the wrong http status on timeouts

Oh that's an interesting issue

> how sure are you that java-http-clj/get is returning a body of "{}" ? I was just printing out the response value and saw "{}".

I don't know much about java-http-clj, but recently me and a co-worker had some trouble with http://java.net.http.HttpClient, of which java-http-clj is built on. Namely that there is no timeout (even if you set request timeout) for receiving the body: https://bugs.openjdk.org/browse/JDK-8258397 So my personal opinion would be to stay away from http://java.net.http.HttpClient for now. It seems this is not the issue hitting you now, but it might later.

(Sorry if that was off topic, but I thought it might be good to know...)