Love using this tool. While it is made to make AI agents more efficient in navigating source code, I also found it really handy in getting a quick overview of code bases and understanding static relationships. Integrated that in Emacs to have quick navigation at my fingertips that go beyond lsp-based functionality.
What an incredible loss. I first met Vanessa almost 20 years ago while she was working for impara in Magdeburg. We were colleagues until 2017. She introduced me to Cory Doctorow's Little Brother novels. We attended Hackers together. She was an incredible programmer, a role model and very kind soul. I learned a lot from her. May she find peace wherever she is now.
From the workflow shown in the video it might even make sense to build a low-res game now with DirectX 9 and "mod it up"? The texture upscaling and material inference as well as the direct modification capabilities look amazing!
Thanks for reporting, we'll be looking into this. What is the location that you installed the app to? Are you starting it via the startup menu, desktop icon, or directly with coscreen.exe?
Hello! We are still planning on Linux support but, to be honest, have had our hands full with supporting macOS and Windows. There are a surprising number of things to do and edge cases (multiple displays, spaces, full screen behavior, non-invasive event injection, etc). There are no specific technical issues holding us back really.
We are currently working on a headless client that will also work on Linux. We do not have exact dates for a release yet but it (and a full client) is on our roadmap. IT WILL happen. Fingers crossed.
https://github.com/gabdube/native-windows-gui isn't in the list but is quite a polished option for building Windows specific GUIs. Seems to be the more mature option compared to winsafe.
There is lively.el [1]! It is also on MELPA in a more recent version [2].
It allows to put an elisp expression into any buffer and then replaces that with the output in a time interval or manually. I use that frequently.
In JS for example, if you change the prototype of an object you have effectively changed it's data layout but of course everything is behind a pointer / an indirection.
When changing instance or class variables in Smalltalk, the system actually changing the object layout and goes and recompiles code using it. If you are interested in the details: Chapter 5 of [1] explains it a bit.
It's definitely a possibility to design some form of RPC mechanism and have multiple parts of your application run as essentially a distributed system. There would still be the problem that the "main" application part is expecting the rest of the system to behave in a certain way and if it is maintaining state, the state to be in a certain form. So I'm not sure that you would really win much.
Also, part of the idea is to make hot-reload as little additional burden as possible. Proper compiler support would be the real solution to that but in the form presented in the article you can at least quickly switch between an efficient static build and a dev version, something that would be hard to achieve with an RPC mechanism.
Yeah the approach is restricted and more compiler support for this kind of workflow would be incredibly welcome. I wrote this in part to try to get more folks in the Rust community thinking in this direction. The hot-reload support that Zig is planning sounds really exciting and I would love for Rust to have something similar (one can dream, right ;).
That being said, you can still go quite some way with this approach. On the one hand, simply being able to twiddle an algorithm into shape is really handy when making a game, visualization or exploring data.
On the other hand, you can also serialize state or keep it in a generic form like a serde_json::Value. Serialization of course needs some kind of migration on the part of the code using it (if the data layout changes it loads an old version and needs to convert it to the new form) or defaults for newly added fields/types. However, this is true in general, even in other languages.
I'm using Emacs as my main development tool since more than a decade. In recent years, the improvements around language server tooling, especially lsp-mode [1], makes setting emacs up for different environments and languages a lot simpler. I regularly dabble around with Jetbrain tools mostly to compare if I'm missing out on something but I mostly don't find that to be the case.
And in some areas emacs is just better than other tools in my opinion. E.g. I consider emacs-cider [2] to provide the best Clojure development experience.
Not quite, Lively runs code both client side (JS, languages implemented on top of JS) as well as server side. The Lively server has a "subserver" system [1] that allows you to connect to VMs, compilers, etc.