Could this somehow be adapted into a Jupyter Notebook-type technology for C/C++?
It is Windows only, so no.
C and C++ Hot-Reload/Live Coding
81–90 of 102 posts
Re: C and C++ Hot-Reload/Live Coding
#82Earlier quoted context omitted.
No, totally reasonable not wanting to spend your whole life financially beholden to everybody you've ever done business with. "you will own nothing and be happy" is sadly becoming true, as you have pretty much no Rights for any digital and more of the world is becoming digital. When people ask why I don't like copilot and want a worse alternative when copilot "pays for itself", it's not because I don't want to pay, I…
I just want to buy something and have it. You are buying time. Never pass up an opportunity to do that.
But, if the subscription provider goes out of business or changes the product, I have to be prepared to spend more time to find an alternative. So, if I want to keep a project long term, I'd avoid subscriptions.
Re: C and C++ Hot-Reload/Live Coding
#83Earlier quoted context omitted.
Interesting approach. Was it enough for your use case despite being quite cumbersome if you end up needing to save a bunch of different more complex instances? I mean, I imagine most dynamic objects that are the real state you'd care about will probably be allocated somewhere on the heap and be referenced from lists or pointer types. I guess this would work best for POD types like program settings and the like, so I'…
Yeah it worked fairly well. IIRC there wasn't any kind of dynamically allocated data at all as is common in embedded projects. All strings were stored as fixed size, basically char[64]. Instead of storing pointers, I stored offsets within the memory file, since the base address changes from run to run. (rant incoming) This is actually something that bothers me with contemporary programming languages - the huge amount…
I like the direction you're heading. Roughly:
1) state machine esque predictable function stack
2) global rather than nested state
3) relational model rather than explicit memory objects
4) serialize to disk as builtin
I think
1) is a goal to aim for for the programmer, but when a stack is needed a stack is useful, so should be provided by the language
2) is a good point, encapsulation is a good support for programmers, but encapsulation in the debugger is unwanted; so hopefully the language provides easy support for this
3) Nice idea. Depends on the application domain. Maybe pointers, maybe relational is more useful depending on the situation. Formal verification, err... An excuse for pointers would be: code a solution close to the problem is best for verifying problem->solution->proof which may mean pointers, although verifying solution->proof is better for relational. A good idea to explore...
4) Unequivocal yes
Re: C and C++ Hot-Reload/Live Coding
#84Earlier quoted context omitted.
This. I haven't used it for a while, but my experience is that this whole idea is not worth the trouble. If you want to rapidly design and test algorithms in a JIT environment, just use Python. It's designed for that. You can always port it to c++ in the end if performance is an issue.
you might be getting downvoted for conflating REPL with JIT, but there's definitely a place for a C++ REPL (and anyway, with ROOT/cppyy you can basically use inline C++ in python REPLs)
REPL is just an interface on top. It complicates the whole thing even further, but it's not the root (no pun intended) of the problem.
>you can basically use inline C++ in python REPLs
That's exactly what I was getting at. There's no need for a pure C++ interactive environment. Just use python at this point.
Re: C and C++ Hot-Reload/Live Coding
#85Earlier quoted context omitted.
This. I haven't used it for a while, but my experience is that this whole idea is not worth the trouble. If you want to rapidly design and test algorithms in a JIT environment, just use Python. It's designed for that. You can always port it to c++ in the end if performance is an issue.
I understand that frustration. Fortunately, Clojure (and jank) gets around this entirely. Functions can be redefined at any time, even with different signatures, globals as well. References to the will stay intact and will use the latest value; this is also thread-safe. Ultimately, this isn't something Cling needs to worry about. You can have your cake and eat it, too. If that sounds too good to be true, know that it…
I think this would have been great 15 years ago. Today I really can't see the need for something like it anymore.
Re: C and C++ Hot-Reload/Live Coding
#86Earlier quoted context omitted.
I understand that frustration. Fortunately, Clojure (and jank) gets around this entirely. Functions can be redefined at any time, even with different signatures, globals as well. References to the will stay intact and will use the latest value; this is also thread-safe. Ultimately, this isn't something Cling needs to worry about. You can have your cake and eat it, too. If that sounds too good to be true, know that it…
I think this would have been great 15 years ago. Today I really can't see the need for something like it anymore.
Game industry is one example of such need, hence why Unreal has this kind of tooling integration, or why Visual C++ keeps improving it.
Re: C and C++ Hot-Reload/Live Coding
#87Folks interested in this should absolutely look at the open source Cling project, which uses Clang/LLVM to JIT compile C++ in-process. https://github.com/root-project/cling I'm using Cling, as part of jank, a native Clojure dialect on LLVM, with C++ interop. This allows me to have truly interactive, dynamic programming, while still reaching into native code. jank source compiles to C++, which is then JIT compiled by…
There's also C++/CLI.
Recently updated to C++20, although not all of it.
https://devblogs.microsoft.com/cppblog/cpp20-support-comes-t...
Re: C and C++ Hot-Reload/Live Coding
#88Earlier quoted context omitted.
I think this would have been great 15 years ago. Today I really can't see the need for something like it anymore.
Game industry is one example of such need, hence why Unreal has this kind of tooling integration, or why Visual C++ keeps improving it.
And it's unbelievably bad in Unreal as well. They do so much shady hooks and memory management / GC under the hood that Unreal C++ is effectively more like Java or C# at this point. They would save devs a ton of headache if they just went all the way like Unity. C++ has its uses - but those are definitely not it.
Re: C and C++ Hot-Reload/Live Coding
#89Earlier quoted context omitted.
There is a tsoding daily video with hot code reloading in C [0]. He dicusses techniques for this. one of which is a "migration" approach, similar to database migrations. Where, for example, you have a version number in your struct. and a function for migrating from an old version to a new version. I don't think he implements it in that video though. [0] https://www.youtube.com/watch?v=Y57ruDOwH1g&t=15s
I experimented with hot-reloadable C++ a while back. https://github.com/jheruty/hscpp.git Video for how it works: https://www.youtube.com/watch?v=pjGngeKgni8 To migrate from one class version to another, I found the easiest way was to provide a callback method in the constructor where one could save the state from the old class, and read it into the new class. For example: https://github.com/jheruty/hscpp/blob/master…
Hm. I have mixed feelings about this project (judging solely from the video presentation). On one hand, it is very impressive, no question about that. The sheer amount and diversity of stuff in it would require a degree of focus that makes me feel envious even after this very superficial examinaton. On the other hand, the choice of which stuff to put in just disagrees with how the boundaries are drawn in my head—I’d would have thought a file monitor and a build system/dependency tracker were separate tools, while expecting at least the simple part of migration boilerplate to be generated.
But I guess that’d require hooks into the compiler frontend, which is not just goes against your goal of being relatively compiler-agnostic but is also fantastically difficult for C++. (I wonder if DWARF contains enough data to at least transfer over identically-named fields?.. It’s also something of a bear, but nowhere near a full C++ frontend.) I don’t know how this could be useful to you, sorry. Thank you for showing your project, I’m grateful for the food for thought in any case.
Now, can we just all take a moment to appreciate that you needed a Smalltalk-style become:[1] and ended up making an object table, precisely the classic Smalltalk way? In the end it’s either that or precise pointer tracing, there isn’t (AFAIK) a lot of choice, but it’s still amusing to see an ostensibly high-level mechanism reproduced in a very different environment.
[1] https://gbracha.blogspot.com/2009/07/miracle-of-become.html
Re: C and C++ Hot-Reload/Live Coding
#90Earlier quoted context omitted.
Game industry is one example of such need, hence why Unreal has this kind of tooling integration, or why Visual C++ keeps improving it.
And it's unbelievably bad in Unreal as well. They do so much shady hooks and memory management / GC under the hood that Unreal C++ is effectively more like Java or C# at this point. They would save devs a ton of headache if they just went all the way like Unity. C++ has its uses - but those are definitely not it.
C++ was already Java and C# before they came to be, as experienced in tooling like Energize C++, Visual Age for C++, and C++ Builder.
The problem is that too many people insist in using it like C.
Is as if one changes the JavaScript file extension to Typescript, and then keeps writing JavaScript ES3 on it.