On Thu, Sep 15, 2016 at 3:38 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Live coding on Pharo is great, easy , simple and working out of the box. An extremely useful tool to be able to code an application while it runs, change and improve code with no interruptions.
However there will be cases that Pharo wont be enough, that can be because pharo code is not as fast as you want it to be, or plainly you found a great library in C or C++ you wanna use from Pharo and there is literally a ton of them. However there is a catch , you kiss goodbye to live coding , you say hello to slow compiles and crashes because of bad memory management.
Unfortunately that is the nature of C/C++. However live coding is gaining ground lately and more and more languages use it for super fast development. Some C++ coders have wondered whether they can bring this feature back to C++ and they have succeed.
One example is Unreal game engine I am using .It can compile code on the fly and load it back even though the game is keep running. It calls this process "hot reloading".
But for people that dont want to bother with Unreal there is this project
http://runtimecompiledcplusplus.blogspot.gr/
The nice things about this is that not only it allows for live coding and very fast compiles but also its able to catch crashes with system exceptions, in a case of a crash the application keeps running because the crashy code is exchanged with the previous version of the code that did not crash and the crash is captured with an exception, you can use the debugger to debug it , correct the code and continue like you would with Pharo.
There are disadvantages though, because RCPP makes no compromises when it comes to performance that means that it needs a very specific way of coding to accomodate for live coding, usually a main loop should exist and there is an API that must be used to track changes to the files and reload code on demand. But generally it does work very well and its also used by commercial projects all around the world.
This will be a real nice addition to the toolbox of people who like to extend Pharo with C/C++ but do not want to live the comforts of live coding and have low tolerance for slow compile times and crashes.
Nice idea. I've been wondering if there might be some way of having a SafeFFI for use during development and by newbies. After all, gdb doesn't crash when the program its hosting crashes I guess there is *some* trick could be used. It could even be a *lot* slower and still be useful, to be turned off at deployment. Actually just last night I was contemplating what a Pharo system might be like with FFI-libclang dynamically compiling in-Image C code, (re-)linking it into a dynamic library and immediately calling those functions using FFI again. My very first graduate programming job was a company developing satellite image processing software that got a lot of their speed by generating/compiling/linking/loading C functions for filter-chains to apply to the huge data sets. Maybe something like... Behavior subclass: #CLanguageDescription instanceVariableNames: 'index translationUnit' classVariableNames: '' package: 'ExternalLanguage-C' "Provide compatibility to integrate equivalent of C files in our System Browser. - class-pane==>C-file, method-pane==>types and functions" ProtoObject subclass: #CLanguageRootHierarchy instanceVariableNames: '' classVariableNames: '' package: 'ExternalLanguage-C' "My subclasses are instances of CLanguageDescription compiled by a C compiler such that pure C syntax can be used. i.e. positional function arguments f(a,b)" At a minimum, it might bring FFI function callout definitions closer to pure cut and paste. (Although the current UFFI callout format is pretty good.) A *lot* further stretch... you might store all the VM platform sources inside the image, as well as the generated C code from slang primitives. Updating the slang method immediately re-generates the C code, compiles it and updates the dynamic library. Dependencies could be tracked at a finer level that standard file based makefile, such that an update to a platform C type or function declaration would be linked to other types and functions using (based on AST analysis and the minimum set recompiled immediately. Unit tests for platform sources would be Smalltalk based FFI callouts invoked from TestRunner. (But I know... its easy to dream. harder to do.) cheers -ben