Functional neotest integration for Julia in neovim, at least for running individual tests:
asciinema.org/a/K9A4ElzEUl...
I'll clean it up and link when it's ready for more general use
The problem I had been wrestling with was communicating with the test controller server, handling intricacies of the LSP flavor of JSONRPC. Being able to use the nvim JSONRPC machinery without the LSP request requirements means this project now really is just writing handlers for the requests
References in the docstring specifically call out LSP, but `vim.lsp.rpc` starts a command and communicates using the LSP flavor of JSONRPC. Unlike `vim.lsp`, the RPC module *does not* automatically send the typical LSP initialize request.
Long story short, after discussions + poring over the nvim code, I found there is a non-LSP implementation of JSONRPC available natively via `vim.lsp.rpc`
github.com/neovim/neovi...
Work proceeds on the TestItemController.jl integration for #JuliaLang in #nvim
The persistent problem I've been wrestling with is editor-client communication from nvim
Once Julia communication is working, the neotest interface is (moderately) well documented. So ideally we'll get the usual "running/passed/failed/watch file" features easily. That part is just data manipulation so hopefully quick to implement- moving the data around is the awkward part, so far
Making it work generally is the next step. There's some Lua-JSONRPC.jl communication that needs to be tightened up, some LSP calls to properly fill out the test item information. I expect the nvim side of communicating via stdio is the "hard" part, but that is primarily a Lua problem
Also made French Onion Soup for lunch today, all in all a pretty good week
#neovim #nvim #julialang since I forgot to tag these along the way
Right now this is just a Lua file on my machine pointing to some tests that have a JSON payload generated by what `neotest-julials` outputs at the moment. BUT! The all the constituent pieces are there, it's just a matter of gluing it all together now
Also need to pull the Project/Package URI and data as per this LSP call, so that needs to be added
github.com/julia-vscode...
Had to do a type conversion in the Julia code (not sure why a specific Dict is oddly-typed), and I'm hard-coding some hashes + IDs, but these are basic pieces that can be built in.
It looks like a bunch of nonsense but this is a successful run of a Julia test item, kicked off via Lua in nvim. There's a lot of engineering work left to make this actually usable, but the proof of concept is there!
Quality start to extending neotest-julials: I got it working again like it was 6 months ago 😅
README was incomplete before and didn't state how to enable test item detection, but I got (back) there. Tomorrow I start spinning up TestItemController.jl and work on talking with the controller
I took the last month off programming, but it feels nice to be back. I plugged my column stagger keyboard back in, opened nvim back up, and I have some space to work on personal projects for a bit.
First up is working on the the Neotest integration for Julia
I've purposefully avoided coding with AI to this point. What is the utility you're gaining given the "often wrong" nature?
I'm interested in compelling reasons or situations to try with it, not entirely skeptical
In practice, outside of open source and working across multiple teams, I find that the present tooling (and time, in industry, but that's a separate issue) to support hand-rolling these testers is lacking. Perhaps that's a sign to improve my PBT/generic test writing skills
Writing proper testers for "interfaces" is good practice regardless, as you said. In a perfect world, we get something like CRTU for all meaningful interfaces. Especially for anything load-bearing and intended to compose
Agreed entirely w/r/t productivity without interfaces. As much as I daydream at times about being able to have statically inferable Julia end to end, the dynamic nature of the language is important
It's something I get by without most of the time, but I use it when I can. None of it is very ergonomic, and it's all just "check the method table" right now
Culture is definitely a big part. Very few packages actually adopt the idea, and people are productive without it.
And finally, the talk I gave that helped me formalize my views on this topic. The talk is primarily a survey of the topic rather than a technical proposal. Nevertheless, I hope it can serve as a jumping off point
"Building Confidently in Julia with Interface Driven Design"
youtu.be/mMO9NzkTxL0
I do have thoughts on how to codify interfaces/design patterns with them. I've written interface checkers and used several of them; they are all needs suiting at the moment, but there's always room for improvement.
I have an upcoming sabbatical, hopefully I can spend some time on this problem then
Further, at JuliaCon last summer, there seemed to be myriad discussions around interfaces. My talk sparked some personal conversations, Guillaume and Rafael gave a talk on Interfaces.jl, and Lillith included some discussion of traits + interfaces in her talk as well. People care about this problem!
Fortunately, there is movement beyond user-developed packages: Keno recently developed a "roadmap for interfaces"
None of this is course binding, but interest from a core developer of the language is a promising sign
hackmd.io/BbEw0_B4Q8uD...
Right now, the state of the art here is something like Interfaces.jl or RequiredInterfaces.jl to define and check (via your test suite) interfaces. Ideally, a library author would expose a testing utility to verify this interfaces. An elaborate checker could even do some property based testing!
This is where an interface abstraction comes in: either a statically or dynamically checkable contract that an object:
* possesses the proper methods (easier, gets you 80% of the way there), and
* these methods are correct from a type-system perspective (harder, really improves dev experience)
The catch here is that there's nothing forcing you to implement the Array Interface when you subtype AbstractArray.
Without interfaces, we really have no guidance on what we can do with a given object. Often, we add an abstract type to a signature to imply assumptions about what that type should do; e.g., an AbstractArray should be iterable. This assumption is so important in fact it's called the Array Interface
Interfaces provide a dual abstraction to structs or types within the language: they codify the verbs that comprise our system, the actions we guarantee these types can perform (or have performed on that)
I am a major proponent that #JuliaLang needs an abstraction for interfaces. I feel so strongly about this that I gave a talk on its importance at #JuliaCon this past summer (link in thread)
Four months on, I still believe this is one of the most important missing pieces from the language