Code Annotations for SourceHut(drewdevault.com) |
Code Annotations for SourceHut(drewdevault.com) |
> There does not exist any widely available standalone C parsing library to provide C programs with access to an AST. There’s LLVM, but I have a deeply held belief that programming language compiler and introspection tooling should be implemented in the language itself. So, I set about to write a C parser from scratch.
Even if you prefer to write your C indexer in C, you could use LLVM's C [1] or Python [2] APIs. Plus, you can handle C++ without having to implement your own C++ parser from scratch, which is a much larger undertaking than C99 plus a few GNU extensions.
[1]: https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f1... [2]: https://github.com/llvm-mirror/clang/blob/master/bindings/py...
As for parsing C++, since LLVM is written in C++ using it to write a C++ annotator would be a natural fit :) But C and C++ are different langauges and I don't wish to require LLVM to deal with it. LLVM is one of the largest open source projects on the net, and it requires a lot more complexity and compile time to utilize under these circumstances. On the other hand, I came up with a solution which is <1,300 lines of code and won't grow much more as it expands to support a broader set of C extensions.
There does exist prior art, but I deliberately chose to go with the lowest common denomoniator to provide support for a lot of use-cases we can't predict in an environment which gives users more control over its behavior. I think over time it will be pretty easy to plug the prior art into this system, but harder to plug their systems into novel use-cases. The existing solutions are not always the best, but I did put in a lot of research time to validate that assumption.
But, plugging Semantic into SourceHut should be totally possible with some mild massaging of the output JSON.
If I wanted good code reviewing with Haskell, I figure it would be best to translate HIE files (https://www.haskell.org/ghc/blog/20190626-HIEFiles.html) to LSIF (https://github.com/mpickering/hie-lsif), which is supported in VSCode. Because of the limitations of only parsing, GitHub alone will not be as powerful. If I then just make an LSIF to SourceHut converter, SourceHut will have better annotations than GitHub...
https://code.visualstudio.com/blogs/2018/12/04/rich-navigati...
For Python dig up the old PySonar project (the author took it down for some reason but there are mirrors/archives where you can find versions. Oh hey, it looks like it has been resurrected: https://github.com/yinwang0/pysonar2) It might have been superseded by something else in the meantime, I dunno.
It was the basis for Google's internal Python annotations thingy, and it fscking rocks.
Conceivably someone could write an offline annotation viewer/editor as well? I would love for something like that to catch on.
Imagine Emacs and Pycharm plugins for viewing and editing these annotations, for example.
It has a nice summary of what's cool about it. It's very lightweight on the UI but it's actually very featureful, and includes mailing lists, CI service, etc.
This random HN commenter says yes!
As for merge requests, don't hold your breath. SourceHut embraces the email-based model. A tutorial is available here to give you an idea of how it works: https://git-send-email.io and check out this video for the maintainer's side: https://aerc-mail.org/
The advantages of email include:
- It's based on a venerable and well-understood standards, with ample open-source tooling available
- It's decentralized, federated, and highly fault tolerant
- It doesn't lock you into my platform, you have ownership over your content and can freely interact with projects anywhere
It's also easy and natural to review code by writing emails, and by far the most efficient workflow for git collaboration I've used (having extensively worked in email, GitHub, GitLab, and Gerrit). I think you should give it a chance!
It definitely would make SourceHut more attractive for many people, but so would a nice Git plugin for VS Code that provides a nice UI for automating the git send-email process.
However, I don't focus on the enterprise crowd, you're right about that.
I'm not necessarily saying it's the right choice for Source Hut, but I think it's part of the reason why Github is quite successful in the open source community.
I feel like he's asking me to open up Emacs every time I want to PR/MR, but I'm a Vim user. I don't have any email workflow currently, and I don't want to have to figure it out for a problem I don't have. He's telling me it's more efficient, but most cost vs savings ratio seems very off compared to what I imagine his is.
I don't disagree with anything he says about email, yet I have zero desire to try it out. If I was getting multiple MRs a day, or god forbid dozens a day, yea I'd be dying for something more efficient. But in the Emacs example, I wouldn't mind opening it if I was going to be doing it regularly.
Being required to use a workflow that you rarely use and is always in the "how did I do x?" part of your brain is a hard selling point for me. Even if that workflow is better, if I never remember how to use it what does it matter? It's still worse for me.