On Thu, Sep 15, 2016 at 3:38 AM, Dimitris Chloupis
<kilon.al...@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
