"Are you sure C++ compilation is the best way ? There are a lot of flaws: Smalltalk needs to be restrictive or will be compiled to very slow code, you will loose debugging features, etc.
I would try to integrate Pharo the same way lua is integrated in engines like Source2 from valve: you run your Unreal engine and have it call Pharo as a scripting language to code some features. In such case, one needs to make the VM embeddable in a C++ app, but on the vm-dev mailing list people can help you to do so. Then you need to define some APIs based on what exist in the interpreter proxy to easily call Pharo methods and share struct / objects from C++. Lastly, you may consider adding a few settings in FFI. By default the Smalltalk stack and the C stack are separated to to Smalltalk specific stack page handling. I guess with some annotation in Pharo API code called from C++ you could define the case where the stack could be shared or not. While compiling to C++, how to you plan your compiler to manage memory ? " I am not able to use Pharo as scripting language for Unreal I am afraid the easy way. I cannot use FFI for reason I describe later on. How I plan my compiler to manage memory , it wont, the compiler will expect very close to C++ syntax and features, it will do minimal work at its side so it will be up to the coder. "I think you totally underestimate the task. Yes, Pharo (Smalltalk) is a pretty simple language (by design), so given a parsed AST (thanks Opal) it will not be so hard to transpile into some other language. But Pharo (Smalltalk) is much, much more: you need a sophisticated runtime (basically the VM) and a large part of the core libraries. Many people have worked very hard for decades to give us what we have today, this represents a huge amount of developer years. " I think you overestimate what I am trying to do, I am not trying to recreate Pharo. There wont be a reimplementation of the VM , or the pharo libraries. This is a simple tool that take pharo-like and turns it to C++ making zero assumptions. That means it will be up to the coder to make sure that what it makes is proper C++. It wont be a magical tool that takes pharo code and turns it to C++ no matter what. There will be a ton of limitations on how you write the code to make sure it produces readable and proper C++ code. The advantage of using it over pure Pharo code ? NONE !!! and NOT RECOMMENDED !!! The advantage of using it over pure C++ code ? a) prototype in pure Pharo code using all the advantages and tools of Pharo IDE b) turn it to pharo like C++ code without having to rewrite your code from scratch in C++ "even for C, there is no compiler that takes Pharo code and compiles it to C - binary code. what slang and vmmaker is doing, is more like a preprocessor, generating C - source code. Compiling C to code is done by an ordinary c-compiler, not smalltalk." we call it "compiler" when we have a tool that take one input and turns it to another output. I am well aware that the compiling is done by ordinary C compiler to machine code. I did not mean that I want to compile pharo code to machine code, but pharo code to C++ code and to be precise Unreal friendly C++ code. "AST for pharo code is not used in any step generating vm code or FFI glue code AFAIK" The way I understand it is that AST is used to take pharo code and brake it down to individual part that is the feed into bytecode compiler and the vm then turns bytecode to machine JIT or interprets it to machine depending on the optimisation. Again I am not concerned with the binary part this is taking one source code and turning to another source code, so it has nothing to do with VM, FFI and machine code. "If Unity does not provide a c-binding, it is really difficult to interact with it through a FF-interface. C++ code uses (theoretically every c++ runtime its own) different naming scheme for functions. You can not load and call c++ code the same way as for C. " My engine is Unreal not Unity. Unreal assumes that you either write C++ code or using their own scripting language "Blueprint". Its not designed to be used as a library so making wrappers for Pharo via FFI is not possible. The main reason is that iOS allows only for static executables. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
