[Vm-dev] Removing most of the windowing code

Dimitris Chloupis kilon.alios at gmail.com
Thu Nov 24 14:30:23 UTC 2016


That is not worthless at all. That is still an excellent mechanism for fast
> IPC.
>
>
> Indeed it is, and it works now, so no complains, plus I learned a ton in
the process about UFFI, C++, Pharo and much more.


>
> It is still needed to define a proper interface for embedding the VM. This
> interface should be a single .h file, with the highest level of abstraction
> possible. There are some other issues such as potential name clashes, and
> the fact that the VM symbols are public by default. At the bare minimum, it
> has to provide functions for initializing the VM, passing command line
> arguments, loading an image, running the image, and shutting down.
>
> So far I managed to reduce main source code a lot in sqMain.c (
> https://github.com/ronsaldo/opensmalltalk-vm/blob/MinimalisticHeadless/minheadless/source/sqMain.c
> ) . I am probably moving most of that into a separate source code file that
> will be always linked with VM core library, and keeping the source file
> with main function only couple of lines long (Init vm, load image,
> interpret and shutdown )
>
>
Will give it a look and send you pull requests


> BTW, now I am working for a chilean video game company using Unreal. I do
> not like Unreal because it takes a very long time to compile, even with a
> 44 cores machine (88 threads) that we have in the company for rendering and
> compiling. I am wondering how that integration is going to end.
>
>
Yeah why people do that ?

It took me a day to find a way to reduce compile times down to zero seconds
and basically turn C++ to a live coding language following the advice of
this brilliant C coder here

https://www.youtube.com/watch?v=WMSBRk5WG58


The idea is simple , generate an executable with a basic loop that the only
things it  does is just gives access to its memory via pointers, detects
changes in code and auto compiles it to dynamically linked libraries that
loads of course dynamically. Because it compiles only the dynamic library ,
compile times are close to zero seconds and also compiles happen in the
background so you dont have to even wait for the compile to finish if a
couple seconds compile times is too much.

The executable never stops executing , its just the dynamic libraries that
modify and recompile.

This is very similar to what Unreal editor uses for hot reloading.

So its pretty easy to do this with your own unreal projects and eliminate
the need for dealing with compile time and even avoid using a scripting
language like pharo altogether if you prefer working only on C++.

I am going to use this technique because live coding in pharo for unreal
wont be enough I will need to live code also in C++ because some of the
code will have to be written on C++ for performance reason and compile
times for than 2-3 seconds are unacceptable for my standards.

I did a test for this with C++ you can find the code here

https://github.com/kilon/LiveCPP

Worked like a charm.

But have not tested with Unreal yet because I was focused on my shared
memory bridge. However I see no reason why this would not work well. It
should work even for static compiles because you can static compile dynamic
libraries.

there is also this library

https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus

which takes live coding C++ to a whole new level that I may integrate or at
least use as inspiration.

I am not giving up on live coding any time soon this millennium :D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161124/f343d8b2/attachment.html>


More information about the Vm-dev mailing list