Apple | Debugger Engineer | Full-time | Onsite | Cupertino

The LLDB team at Apple is looking for an engineer to work on the LLDB debugger. LLDB is a core part of Apple's developer tools, used internally to debug Apple's software stack and externally by millions of developers. You’ll be able to work on different levels of the stack: from supporting our existing and upcoming platforms to developing new features to make debugging even better. Most of your work will be open source, on llvm.org (http://llvm.org/) and github.com (http://github.com/) where you’ll collaborate with the LLVM and Swift community.

If you love working on low-level tools you should check out the details here: https://jobs.apple.com/en-us/details/200311412/debugger-engi...

Indeed, the commit hash reported in the version corresponds to something that landed on master at 11PM this Monday.

Clang is the lucky one here, it has both SQLite and Dr Hipp on its side.

Rust has Crater which allows new rustc builds to be run against the entire public crates.io dgraph.

https://github.com/rust-lang/crater

> Clang is the lucky one here, it has both SQLite and Dr Hipp on its side.

Clang is lucky that OSSFuzz does testing of unreleased clang version on other OSS projects, like SQLite.

Love it. This is the dream of open-source.

The one for Chris Lattner is definitely off: https://twitter.com/clattner_llvm/status/1150992062365310977

I wish more developers wrote code with a mute keyboard.

LLVM adopted a new version scheme which made the minor version redundant. IIRC someone suggested to remove it and nobody objected.

http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm...

Does this page explain the parent's question? It specifically mentions keeping the minor version more than once.

> What for you might need it on iOS? Server is meant to run on a development machine.

While I totally agree, I can see the author's point. Think for example about Swift Playgrounds.

Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language.

While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST.

So LSP actually leads to more duplicated code and worse editors.

VS Code will never be able to match the functionality of IDEA unless each language server reimplements all the functionality slightly differently. What a mess.

I'm implementing an LSP server using IDEA as a backend, so hopefully VS Code will be able to match the functionality sometime.

https://github.com/Ruin0x11/intellij-lsp-server

That being said, as an implementor I'm finding cases where LSP's feature set is underdeveloped. For example, there is nothing in the spec to account for renaming files, so I can't put in my rename action without the behavior being incorrect (because if you rename a class in Java you have to rename the corresponding file, which IDEA handles). Also some things require custom LSP requests, like getting the list of build configurations to run. I think this is a product of the Java support in IDEA being so much more comprehensive than anything in LSP so far. But hopefully as the spec is improved these issues will be worked out

And no other editor can implement IDEA’s feature set except from scratch. What a mess.

Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.

LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specifi...

Is your complaint that they're not iterating fast enough? Because this is something I'd prefer they take their time and get it right, especially once we get past the low-hanging fruit and into complex things like debugging.

My complaint is that the entire concept on which LSPs are based today — each LSP reimplements all functionality itself, the editor is only a dumb textview — is wrong.

Language servers should expose an AST, not some actions. Language Servers shouldn't even know where the cursor is — or how many there are.

With a proper LSP, you can also write a linter just by using the protocol, you can call the same action on a thousand places at the same time, and the refactoring functionality is implemented only once, and reused everywhere.

The entire design of LSP is flawed.

Can you go into more detail please on why it had to be subpar?

LSP supports refactorings via Code Action Request messages.

You mean, with common IDE plugins, you end up with one implementation of refactoring functionality per IDE. That's what's being avoided here (because, for one thing, there are far more IDEs than you think, and they don't deserve to be second-class citizens.)

No, all IDEs could use the same AST backend.

Just like LSP. Just a more intelligent protocol.

You have one implementation of refactoring, instead of, as today, one per language.

Technically solvable if somebody writes a LSP proxy server that merges together backends.

Oh, you're right. We should just dump all other editors and use IDEA. /s

Or maybe we should build an LSP that exposes an AST in a way that is more useful to IDEs, like IDEAs plugins do today.

In fact, the code in IDEA that does this is open source, so you can start with it, and build a better LSP based on it.

This would be an interesting idea, provided that editors go all-in on supporting such refactoring logic on the client side. The IDEA code defines "extension points" so language specific support for common actions can be implemented in a modular fashion. When the user decides to execute a refactoring, it is just the matter of iterating through the loaded extension points and choosing the one for the language being edited. Having worked with the IDEA code myself to build an LSP server, there end up being language-specific parts such that the support between e.g. Java and Kotlin have to be handled separately. However that was probably due to the way I wrote the server; these could be generalized to a single "refactor" entrypoint with some work. It's just that using the current LSP model with the server being the part with AST awareness, there isn't much gain in doing so.

In addition to what everyone else has said, something I'd find really useful would be going in the other direction. Just mark some keys and it tells you what chord you're playing.

Thanks for the feature request! I've had this feature request many time, it's on my list. But like UncleMeat said, it's a bit trickier because there isn't a 1-1 mapping. So I'll have to find some elegant UI pattern for this. I want to keep Note Kitchen very minimal and simple so I have to be careful about too many menus and buttons, etc.

Doesn't work. The same notes can be represented as several different chords depending on harmonic context.

> Let’s face it, programming books suck.

While I agree that there are a lot of bad books out there, I don't agree that programming books suck in general. I very much prefer a well structured book over one of those chaotic tutorials that leave me with more questions than answers. Especially for languages where the "why" matters a lot more than the "how".

> It’s a lot like the way you may have already been doing it, just with more learning.

Maybe that's the reason why I disagree. Indeed, they way I read a book is by putting its content into practice.