remote-apis
language-server-protocol
remote-apis | language-server-protocol | |
---|---|---|
5 | 121 | |
300 | 10,725 | |
0.3% | 1.1% | |
5.8 | 8.7 | |
15 days ago | 1 day ago | |
Starlark | HTML | |
Apache License 2.0 | Creative Commons Attribution 4.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
remote-apis
-
Mozilla sccache: cache with cloud storage
In the case of the Remote Execution/Cache API used by Bazel among others[1] at least, it's a bit more detailed. There's an "ActionCache" and an actual content-addressed cache that just stores blobs ("ContentAddressableStorage"). When you run a `gcc -O2 foo.c -o foo.o` command (locally or remotely; doesn't matter), you upload an "Action" into the action cache, which basically said "This command was run. As a result it had this stderr, stdout, error code, and these input files read and output files written." The input and output files are then referenced by the hash of their contents, in this case.
Most importantly you can look up an action in the ActionCache without actually running it. So now when another person comes by and runs the same build command, they say "Has this Action, with these inputs, been run before?" and the server can say "Yes, and the output is a file identified by hash XYZ" where XYZ is the hash of foo.o
So realistically you always some mix of "input content hashing" and "output content hashing" (the second being the definition of 'content addressable'.)
[1] https://github.com/bazelbuild/remote-apis/blob/main/build/ba...
-
Distcc: A fast, free distributed C/C++ compiler
Not only it's distributed like distcc, Bazel also provide sandboxing to ensure that environment factors does not affect the build/test results. This might not mean much for smaller use cases, but at scale with different compiler toolchains targeting different OS and CPU Architecture, the sandbox helps a ton in keeping your cache accurate.
On top of it, the APIs Bazel uses to communicate with the remote execution environment is standardized and adopted by other build tools with multiple server implementation to match it. Looking into https://github.com/bazelbuild/remote-apis/#clients, you could see big players are involved: Meta, Twitter, Chromium project, Bloomberg while there are commercial supports for some server implementations.
Finally, on top of C/C++, Bazel also supports these remote compilation / remote test execution for Go, Java, Rust, JS/TS etc... Which matters a lot for many enterprise users.
Disclaimer: I work for https://www.buildbuddy.io/ which provides one of the remote execution server implementation and I am a contributor to Bazel.
-
When to Use Bazel?
Regardless of whether you should use Bazel or not, my hope is that any future build systems attempt to adopt Bazel's remote execution protocol (or at least a protocol that is similar in spirit):
https://github.com/bazelbuild/remote-apis
In my opinion the protocol is fairly well designed.
-
Programming Breakthroughs We Need
> The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine.
This is already achievable nowadays using Bazel (https://bazel.build) as a build system. It uses a gRPC based protocol for offloading/caching the actual build on a build cluster (https://github.com/bazelbuild/remote-apis). I am the author of one of the Open Source build cluster implementations (Buildbarn).
-
Distributed Cloud Builds for Everyone
Very nice! I really like the ease-of-use of this, as well as the scale-to-zero costs. That's a tricky thing to achieve. Seems like it could become a standard path to ease the migration from local to remote builds.
If the author is interested in standardizing the same, I'd suggest implementing the REAPI protocol (https://github.com/bazelbuild/remote-apis). It should be amenable to implementing on a Lambda-esque back-end, and is already standard amongst most tools doing Remote Execution (including Bazel! Bazel+llama could be fun). And equally, it's totally usable by a distcc-esque distribution tool (recc[1] is one example) - that's also what Android is doing before they finish migrating to Bazel ([2], sadly not yet oss'd).
The main interesting challenge I expect this project to hit is going to be worker-local caching: for compilation actions it's not too bad to skip assuming the compiler is built into the container environment, but if branching out into either hermetic toolchains or data-heavy action types (like linking), fetching all bytes to the ephemeral worker anew each time may prove to be prohibitive. On the other hand, that might be a nice transition point to switch to persistent workers: use a lambda backed solution for the scale-to-0 case, and switch execution stacks under the hood to something based on reused VMs when hitting sufficient scale that persistent executors start to win out.
(Disclaimer: I TL'd the creation of this API, and Google implementation of the same).
[1] https://gitlab.com/BuildGrid/recc
[2] https://opensource.googleblog.com/2020/11/welcome-android-op...
language-server-protocol
-
Ollama is now available on Windows in preview
But these are typically filling the usecases of productivity applications, not ‘engines’.
Microsoft Word doesn’t run its grammar checker as an external service and shunt JSON over a localhost socket to get spelling and style suggestions.
Photoshop doesn’t install a background service to host filters.
The closest pattern I can think of is the ‘language servers’ model used by IDEs to handle autosuggest - see https://microsoft.github.io/language-server-protocol/ - but the point of that is to enable many to many interop - multiple languages supporting multiple IDEs. Is that the expected usecase for local language assistants and image generators?
-
The Mechanics of mutable and immutable references in Rust
If you tried writing code like the one above, your Rust LSP should already be telling you that what you're doing is unacceptable:
-
A guide on Neovim's LSP client
A language server is an external program that follows the Language Server Protocol. The LSP specification defines what type of messages a language server can receive, and also how it should respond. The idea here is that any tool that follows the LSP specification can communicate with a language server.
-
The IDEs we had 30 years ago and we lost
> There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.
The Language Server Protocol [1] is the best thing to happen to text editors. Any editor that speaks it gets IDE features. Now if only they'd adopt the Debug Adapter Protocol [2]...
[1] https://microsoft.github.io/language-server-protocol/
[2] https://microsoft.github.io/debug-adapter-protocol/
-
The More You Gno: Gno.land Monthly Updates - 6
The Gno Language Server (gnols) is an implementation of the Language Server Protocol (LSP) for the Gno programming language. It is similar to the equivalent “gopls” project for Go, as they can be plugged into your code editor through extensions and allow you to access handy features, such as autocompletion, formatting, and compile-time warnings/errors. Gnols makes writing code simpler, working with several editors to suit your preferences. To try it out, visit the CONTRIBUTING.md file, which contains instructions to get you started. Our current documentation targets Vim, Neovim, and SublimeText, but can likely be used with any editor that supports LSP. Feel free to contribute to improving Gnols and adding more features. It’s well-written, and simple to dive into the code and add more capabilities.
-
LSP could have been better
Honestly, you should read some of the docs [0] if these are the sorts of questions you're asking.
[0] https://microsoft.github.io/language-server-protocol/
-
Show HN: Postgres Language Server
hey HN. this is a Language Server[0] designed specifically for Postgres. A language server adds features to IDEs (VSCode, NeoVim, etc) - features like auto-complete, go-to-definition, or documentation on hover, etc.
there have been previous some attempts at adding Postgres support to code editors. usually these attempts implement a generic SQL parser and then offer various "flavours" of SQL.
This attempt is different because it uses the actual Postgres parser to do the heavy-lifting. This is done via libg_query, an excellent C library for accessing the PostgreSQL parser outside of the server. We feel this is a better approach because it gives developers 100% confidence in the parser, and it allows us to keep up with the rapid development of Postgres.
this is still in early development, and mostly useful for testers/collaborators. the majority of work is still ahead, but we've verified that the approach works. we're making it public now so that we can develop it in the open with input from the community.
a lot of the credit belongs to pganalyze[1] for their work on libg_query, and to psteinroe (https://github.com/psteinroe) who the creator and maintainer of the LSP.
[0] LSP: https://microsoft.github.io/language-server-protocol/
[1] pganalyze: https://pganalyze.com/
-
Refactoring tools
See: https://github.com/microsoft/language-server-protocol/issues/1164
-
Nx Console gets Lit
The nxls is a language server based on the Language Server Protocol (LSP) and acts as the “brain” of Nx Console. It analyzes your Nx workspace and provides information on it, including code completion and more.
-
How to configure vim like an IDE
LSP stands for "Language Server Protocol", which defines how a language server and an editor (client) can communicate to provide code navigation, completion, etc. (source). Traditional IDE's would have something similar to this baked-in already, but proprietary to their software/language; whereas LSP is an open standard, so anything could implement it.
What are some alternatives?
dylint - Run Rust lints from dynamic libraries
intellij-lsp-server - Exposes IntelliJ IDEA features through the Language Server Protocol.
bazel-gba-example - Bazel GBA (Game Boy Advance) Example
tree-sitter-org - Org grammar for tree-sitter
llama
omnisharp-server - HTTP wrapper around NRefactory allowing C# editor plugins to be written in any language.
MyDef - Programming in the next paradigm -- your way
tree-sitter - An incremental parsing system for programming tools
bazel-buildfarm - Bazel remote caching and execution service
magic-racket - The best coding experience for Racket in VS Code
embedded-postgres-binaries - Lightweight bundles of PostgreSQL binaries with reduced size intended for testing purposes.
friendly-snippets - Set of preconfigured snippets for different languages.