drothlis

7 ms·

1.
by drothlis 2y ago
> Claude's ability to count pixels and interact with a screen using precise coordinate I guess you mean its "Computer use" API that can (if I understand correctly) send mouse click at specific coordinates? I got excited th
2.
by drothlis 2y ago
I noticed in your demo it generated the prompt "tap on the 'Log in' button located directly below the 'Facebook Password' field". Does your model consistently get the positions right? (above, below, etc). Ever
3.
by drothlis 3y ago
Beautiful.
4.
by drothlis 3y ago
https://en.wikipedia.org/wiki/Characterization_test aka snapshot tests.
5.
by drothlis 3y ago
According to the ViperGPT paper their "ImagePatch.find()" uses GLIP. According to the GLIP paper,† accuracy on a test-set not seen during training is around 60% so... neat demos but whether it'll be reliable enough depends o
6.
by drothlis 4y ago
Could you implement (some of) astroid's inference using stack graphs? [1],[2] That would allow a lot of caching optimisations, as you can "index" each file in isolation. [1]: https://github.blog/2021-12-09-int
7.
by drothlis 4y ago
It side-steps the problem of git conflicts, I suppose. You'd have to use their tool (`touca diff`? I don't know if that exists) instead of `git diff`.
8.
by drothlis 4y ago
Some ideas I got from Jeremias Rõßler's talk: https://t.co/xWtA58Q9q5 - Snapshot testing is like version-control but for the outputs rather than the inputs (source code). - Asserts in traditional unit tests are like
9.
GPT is all you need for the back end(github.com)
252 points by drothlis 4y ago|264 comments
10.
by drothlis 4y ago
Obviously a sensationalised title, but it's a neat illustration of how you'd apply the language models of the future to real tasks.
11.
by drothlis 4y ago
Think systems integrators and compliance tests. I would imagine that each of the individual systems being "integrated" do have their own unit tests, upstream, in their own repos.
12.
by drothlis 4y ago
Some good ideas here for when your tests are in a separate repo than the system under test (GPUs/drivers/compilers in the case of the author, but it's applicable to a variety of industries).
13.
Software testing, and why I'm unhappy about it(nhaehnle.blogspot.com)
78 points by drothlis 4y ago|73 comments
14.
by drothlis 4y ago
Related: I think it was Kernighan & Pike's "The Practice Of Programming" where I read the idea of testing a complex implementation by comparing its output against a simpler but less performant implementation.
15.
by drothlis 4y ago
Interesting thought, somewhat related to the articles on "snapshot testing" that have been trending on HN lately.
16.
Cross-Branch Testing(buttondown.email)
2 points by drothlis 4y ago|2 comments
17.
by drothlis 4y ago
"Regression testing" can also refer to a process: When the QA team says they're doing regression testing, it means they're testing that existing functionality hasn't regressed (as opposed to testing a new feature).
18.
by drothlis 4y ago
In the article they don't change /etc/machine-id, but APT::Machine-ID in apt.conf.
19.
by drothlis 4y ago
https://approvaltests.com/
20.
by drothlis 4y ago
...and my favourite term, "characterization test": https://en.wikipedia.org/wiki/Characterization_test "Regression test" means something else, at least at the companies I've worked at: It means
21.
by drothlis 4y ago
I realised this is another example of "trees" as first-class citizens in a build system. In my comment above the tree we're passing around is a docker layer; in my LWN article it's an OSTree ref. We use the former for ou
22.
by drothlis 4y ago
I suppose they're ideal for cases where there's a simple, obviously correct but slow implementation that you can use to test a more complex but faster implementation.
23.
by drothlis 4y ago
Fixed your link to the full article: https://lwn.net/Articles/821367/ OSTree is still working very well for us. At the time I wrote the article we had been using OSTree (and the build system I described in the art
24.
by drothlis 4y ago
P.S. They're also great for writing tests for new code, for many of the reasons described in the OP.
25.
by drothlis 4y ago
I'm not the OP but I think Fibonacci is a contrived example. In practice these "characterisation tests" are great for adding tests to an existing codebase. The "snapshot" just records the current behaviour; it doesn
26.
by drothlis 4y ago
I have been using this type of "expect" tests (I use the term "characterisation tests") more and more. Some examples: - Server-side rendering and testability: https://david.rothlis.net/server-side-renderi
27.
by drothlis 4y ago
I love Python + Ninja! I was going to link to my article on Ninja + OSTree, but I found in your blog you've already seen it. :-)
28.
by drothlis 4y ago
They probably mean incremental builds, where the actual compilation doesn't overshadow the "coordination" work. In my (artificial) benchmark, make scaled poorly, taking 70 seconds to process 100k C files worth of dependencies
29.
by drothlis 4y ago
I found that Ninja tries hard to build things in the order they’re listed in the build file (dependencies permitting). Whereas GNU Make... well, it does start off trying to build depth-first, but if it needs to build a target's prerequ
30.
by drothlis 4y ago
Fine-grained access tokens are available on org-owned repos too, but the org has to opt in (for some reason).

More ›