robertkrahn01

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.

Just put scaffolding around it, will fit much better into NYC :D

Can they fix schedules and reliability first please?! https://www.welt.de/politik/deutschland/article244075801/Bah...

Probably linking the paper and examples notebook here makes sense as they are pretty explanatory:

https://github.com/ExtensityAI/symbolicai/blob/main/examples...

https://arxiv.org/pdf/2402.00854

Brendan Eich used both Scheme and Self as inspirations. Self is a dialect of Smalltalk.

https://en.wikipedia.org/wiki/Brendan_Eich

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.

Another Emacs integration, using org-mode for ChatGPT and DALL-E: https://github.com/rksm/org-ai

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.

[1] https://lukego.livejournal.com/23379.html [2] https://github.com/purcell/lively/tree/348675828c6a81bfa1ac3...

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.

[1] Hirschfeld et al. Assisting System Evolution: A Smalltalk Retrospective. http://soft.vub.ac.be/Publications/2002/vub-prog-tr-02-25.pd...

> have a "release" compilation mode that removes the hot reloading entirely

Oh that is easy to do thanks to Rust features, see the reload-feature example: https://github.com/rksm/hot-lib-reloader-rs/tree/master/exam...

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.

Dan Luu's "How do cars fare in crash tests they're not specifically optimized for?" comes to mind. https://danluu.com/car-safety/

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.

[1] https://emacs-lsp.github.io/lsp-mode/

[2] https://cider.mx/

Your project looks very interesting :)

Not sure if I can help but happy to get in touch. Feel free to shoot me an email or such, contact links in my profile.

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.

[1] https://github.com/LivelyKernel/LivelyKernel/tree/master/cor...

> Did any of the Replit people work on Lively Kernel?

No, and I wasn't suggesting that. Though Lively was a project at YC Research in 2016/2017 and replit is a YC 18 company I think. So they might have heard about it but I do not remember giving any demos to folks involved with it.

And even if, we actually invited folks to copy the ideas. The Lively project was not a product but trying to carry forward a set of ideas rooted in Smalltalk. Every copy (even if its not a good one) is cool to see. It has the change to make the language and tooling eco system better, programming easier and more immediate, and might invite more people to get started building software and having fun with computers.

> is there a list of languages it supports

No not really. We build out a few to have more polish (as you mentioned LivelyR and cloxp, support for shell programming and node.js that is part of Lively itself). But there isn't really much to it: here is e.g. a quick'n dirty Haskell "subserver" that can run as part of Lively and allows to load a Haskell runtime, load Haskell files and evaluate expressions [1] (this is anno 2013, please don't judge too hard about the code ;). Some of these are floating around. We then customized the ACE editor [2] a bit for providing some fundamental editing experience (it has syntax highlighting for a large number of languages builtin). That's it, for a simple integration, not much is needed really.

There is also the amazing Ohm project [3], a toolkit for writing PEG parser and interpreters which is standalone but got its integration into Lively as well. It allows to quickly experiment with new language ideas or implement grammars/interpreters for existing languages.

[1] https://lively-web.org/core/servers/HaskellServer.js

[2] https://ace.c9.io/

[3] https://github.com/harc/ohm

Yeah wasm is definitely getting interesting as a platform for these. As long as you can build/compile a language VM (such as the Python VM) or a language compiler itself in wasm there shouldn't be much stopping you.

Thinks like that have been done even with plain JS and the results are very cool, see e.g. SqueakJS, a Squeak/Smalltalk VM implemented directly in JS.

[1] https://squeak.js.org/

I've worked for ten years on the Lively Kernel project [1,2,3], originally created by Dan Ingalls at Sun Microsystems. Running JavaScript, Smalltalk, R, Clojure, Haskell, Python, C++ and a few other languages in it. When I first saw replit, I thought, wow someone copied 1/4 of Lively. Do they really think they had an original idea?

[1] https://lively-kernel.org

[2] https://lively-next.org

[3] https://cloxp.github.io/cloxp-intro.html