Support Cyberbrain in more editors and IDEs

[laike9m]

There are countless editors and IDEs out there. For convenience, I'll call them environments. I'd like to see Cyberbrain integrated with all of them, but this simply is not possible given the limited time I have. Considering the technologies Cyberbrain is using, here's what I'm gonna do.

• Cyberbrain will officially support major vscode-compatible environments
• Support for non-vscode-compatible environments will rely on the community
  I'm committed to provide as much help as I can, including but not limited to:
  • Answering questions
  • Audio/video 1:1
  • Making necessary code changes
  • Pair programming

The reason is simple. The only environment we now support is VS Code (local), thus it's much easier to support vscode-compatible environments than others.

Based on the strategy, the environments we will offically support include:

• Gitpod
• Theia
• VSCodium
• GitHub Codespaces
• CodeSanbox
• Onivim 2
• code-server

Please let me know if there's more.

The environments that we will rely on the community to support include:

• All non-web IDEs (PyCharm/Eclipse/Visual Studio/etc)
• Vim/Emacs/Sublime/Atom/etc
• Jyputer notebook
• Command line

I will create a formal specification of the internal API to help people build third-party tools.

There is no preset timeline for when each environment will be supported, or in which version. I want to keep it flexible, and most likely, the environments that more people requested for will be supported first. Once a new environment is supported, we'll release a new minor version.

For requesting support for another vscode-compatible environment, please open a separate issue.

If you want to migrate Cyberbrain to a non-vscode-compatible environment, please contact me directly on Twitter or Discord. I'm happy to discuss it anytime.

[alexmojaki]

I think editor integrations is the wrong idea. I spent a long time making a birdseye plugin for PyCharm and it was a big mistake. It was a huge amount of work, it didn't add that much value, and now it doesn't even work any more and it's not worth my time to fix it.

I suggest you make an interface that can be used in the browser, similar to birdseye or heartrate. Then people can use it even if they code in notepad.

Beyond that, I still think the minimal CLI that I suggested way back would also be a good approach.

[laike9m]

Hi Alex, thanks for your feedback. I always expect your input since you're the expert in this area.

now it doesn't even work any more

I noticed that...

I suggest you make an interface that can be used in the browser

Actually this is already possible. The interface is defined using protobuf + gRPC. For web usage, there's gRPC Web. I will write a more descriptive spec later to explain how it works.

Beyond that, I still think the minimal CLI that I suggested way back would also be a good approach.

This is easier than in the previous version, since right now everything is already serialized to JSON. But it all comes down to one problem: there are so many bugs to fix right now and I don't have enough time...

With all respect, I don't agree with the opinion that "editor integrations is the wrong idea". Cyberbrain is trying to picth a brand new idea of variable tracing, it hasn't been achieved by any other debugging tools I've seen. To demonstrate this idea, I need a UI that is usable enough, otherwise people won't even understand what "tracing" means. I agree that your point might be correct from a pure technical perspective, but Cyberbrain needs more than that to succeed, because it is very hard to spread a new idea. Hope that explains it.

Also, you're absolutely correct that it's not scalable to maintain every integration. That's why I only plan to maintain vscode-compatible environments. Hopefully in the future we'll see a PyCharm integration built by the community.

[alexmojaki]

Sorry, I should have made some things clearer.

I figured there was already a web server and such, but I don't know how to use it. I suggest you document it clearly at the forefront. It should be as usable as possible on its own so that everyone finds your tool pleasant to use without a specific editor.

I also thought that a PyCharm plugin would make birdseye so easy and convenient to use that everyone would use it, but it didn't work that way. It was only afterwards that I polished and refined the browser interface and realised how much easier and more effective that was. The PyCharm plugin was still the most convenient, but only by a thin margin.

Make the interfaces that everyone can use your top priority. Make them user friendly and well documented. Then afterwards, editor integrations can be a bonus to help spread the word further.

[alexmojaki]

Also check out the editors and IDEs section of https://www.jetbrains.com/lp/python-developers-survey-2019/

[laike9m]

I see what you mean. The decision of supporting VS Code not web is more of a technical decision.

For tracing to be useful, it's necessary to show source code alongside the trace graph. However, I don't know how to make an "editor like" UI (even if I do, it's gonna take a lot more effort). birdseye shows source code by itself while Cyberbrain doesn't, and that leads to the difference (which all make sense IMHO).

And thanks for posting the survey results. I use PyCharm to develop Cyberbrain too.

For the server interface, it will be documented because I definitely want people to be able to build tools on top of it easily. One thing to note that this interface is subject to change at any time, and that's why I want to wait for it to become more stable before publishing it.

[alexmojaki]

Here's roughly how I think it should look:

I think that would be an improvement over the existing VSCode interface already. It's hard to look at line numbers on their own in the graph diagram and map them to source code. Don't rely on the editor on the side, present the text in the ideal format yourself. Lines not directly relevant to the graph but which still provide valuable context can be shown but with less space and emphasis.

[laike9m]

Thanks for the suggestion, it's a good starting point for building a web version.

It's hard to look at line numbers on their own in the graph diagram and map them to source code.

That's why I have this feature planned:
Allow mutual interaction between source code and the trace graph.