Re: [Pharo-users] Embedding pharo in C++
On Tue, Jan 21, 2020 at 08:20:48PM +0100, Roland Plüss via Pharo-users wrote:
The first mode is the "runtime mode". This would be the mode used for the released products and does not allow to "directly modify" the image. This mode would only require basic set of classes (frameworks) since the game engine provides a large set of functionality in the module layer so the script layer provides the logic, UI and things like that. This image would not require to be enriched with a lot of things.
This is doable currently. The Pharo image is embedded into the executable and used in read-only mode. Although personally I'd implement as much of the app logic in Pharo as possible simply because of the high productivity.
The second mode is the "development mode". For this one I thought about exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I would opt to expose the full power of Pharo/Smalltalk to the developer.
I envisage doing this via some kind of data exchange between the host program and Pharo, which seems doable for both the embedded and 'over the wire' development cases. Pablo recently published an example of embedding a headless-but-GUI Pharo image inside a C program via the Windows resource mechanism. As it happens, I have just implemented the same example that works on Linux and MacOS from one source code. Didn't test on Windows, but I'm sure it'll work there too. In a day or two I will publish the code and blog post. Attached teaser screenshot. :-) Pierce
Hi, we are working on the tools required to have embedded Pharo in different solutions. My idea is to implement an API to communicate to the image, I was thinking more in an API similar to Objective-C Bridge or COM objects. Still I am not sure how to design the API or the way to integrate it. Today, I am thinking about not having to much marsharlling of Pharo Objects to external objects, I am thinking to use a similar strategy like the used with FFI. A simple start point begins with exposing callbacks from the image. This will only work with the new Queue based callbacks, as the image will receive callbacks from outside a call-out. I have started with a POC of this, but time / resources is the limitant. I will try to put some time on it, but we have other priorities. Cheers, On Wed, Jan 22, 2020 at 9:38 AM Pierce Ng <pierce@samadhiweb.com> wrote:
On Tue, Jan 21, 2020 at 08:20:48PM +0100, Roland Plüss via Pharo-users wrote:
The first mode is the "runtime mode". This would be the mode used for the released products and does not allow to "directly modify" the image. This mode would only require basic set of classes (frameworks) since the game engine provides a large set of functionality in the module layer so the script layer provides the logic, UI and things like that. This image would not require to be enriched with a lot of things.
This is doable currently. The Pharo image is embedded into the executable and used in read-only mode. Although personally I'd implement as much of the app logic in Pharo as possible simply because of the high productivity.
The second mode is the "development mode". For this one I thought about exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I would opt to expose the full power of Pharo/Smalltalk to the developer.
I envisage doing this via some kind of data exchange between the host program and Pharo, which seems doable for both the embedded and 'over the wire' development cases.
Pablo recently published an example of embedding a headless-but-GUI Pharo image inside a C program via the Windows resource mechanism. As it happens, I have just implemented the same example that works on Linux and MacOS from one source code. Didn't test on Windows, but I'm sure it'll work there too. In a day or two I will publish the code and blog post.
Attached teaser screenshot. :-)
Pierce
-- Pablo Tesone. tesonep@gmail.com
On Wed, Jan 22, 2020 at 10:09:33AM +0100, tesonep@gmail.com wrote:
Hi, we are working on the tools required to have embedded Pharo in different solutions.
Hi Pablo, Your published example embed the image as a Windows resource. Well, the excellent and, like Smalltalk, vastly underrated Free Pascal has built-in cross platform support for Windows resources. Basically I have implemented in Pascal the simplest FFI to libPharoVMCore and the embedded image access routines for callback by libPharoVMCore, together with a driver program which is pretty much a straight port of your C program. Pascal also produces static and dynamic libraries. My embedded image access code can be packaged as such, which makes it accessible from other languages.
My idea is to implement an API to communicate to the image, I was thinking more in an API similar to Objective-C Bridge or COM objects. Still I am not sure how to design the API or the way to integrate it. Today, I am thinking about not having to much marsharlling of Pharo Objects to external objects, I am thinking to use a similar strategy like the used with FFI.
I am more thinking about marshaling, using say MessagePack. For 'over the wire' development, maybe MessagePack RPC between headful Pharo and the to-be-host program. For embedded, some means to pass MessagePack structures back and forth. Pierce
Hi, nice to hear about the Pascal experiment, yes, that could be an alternative. I started to see how is the API for different embeddable runtimes. I want to have an API that allows us to continue having the power of the objects, I don't want to have strings passing from one side to the other. I will check MessagePack, thanks for the pointer. Cheers, Pablo On Wed, Jan 22, 2020 at 11:01 AM Pierce Ng <pierce@samadhiweb.com> wrote:
On Wed, Jan 22, 2020 at 10:09:33AM +0100, tesonep@gmail.com wrote:
Hi, we are working on the tools required to have embedded Pharo in different solutions.
Hi Pablo,
Your published example embed the image as a Windows resource. Well, the excellent and, like Smalltalk, vastly underrated Free Pascal has built-in cross platform support for Windows resources. Basically I have implemented in Pascal the simplest FFI to libPharoVMCore and the embedded image access routines for callback by libPharoVMCore, together with a driver program which is pretty much a straight port of your C program.
Pascal also produces static and dynamic libraries. My embedded image access code can be packaged as such, which makes it accessible from other languages.
My idea is to implement an API to communicate to the image, I was thinking more in an API similar to Objective-C Bridge or COM objects. Still I am not sure how to design the API or the way to integrate it. Today, I am thinking about not having to much marsharlling of Pharo Objects to external objects, I am thinking to use a similar strategy like the used with FFI.
I am more thinking about marshaling, using say MessagePack. For 'over the wire' development, maybe MessagePack RPC between headful Pharo and the to-be-host program. For embedded, some means to pass MessagePack structures back and forth.
Pierce
-- Pablo Tesone. tesonep@gmail.com
On Wed, Jan 22, 2020 at 11:04:07AM +0100, tesonep@gmail.com wrote:
nice to hear about the Pascal experiment,
I've published my code on GH and sent an announcement to pharo-dev. Repo is https://github.com/PierceNg/pharo-vm-embedded-pascal Pierce
I gave the C-Example repository a try but I don't fully understand how it works. Does the vm_main_with_parameters() block until the VM is quit or some function it runs? From looking at the source code I'm not sure what it does. On 1/22/20 12:17 PM, Pierce Ng wrote:
On Wed, Jan 22, 2020 at 11:04:07AM +0100, tesonep@gmail.com wrote:
nice to hear about the Pascal experiment, I've published my code on GH and sent an announcement to pharo-dev.
Repo is https://github.com/PierceNg/pharo-vm-embedded-pascal
Pierce
-- Yours sincerely Plüss Roland Leader and Head Programmer - Game: Epsylon ( http://www.indiedb.com/games/epsylon ) - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine , http://dragengine.rptd.ch/wiki ) - As well as various Blender export scripts und game tools
participants (3)
-
Pierce Ng -
Roland Plüss -
tesonep＠gmail.com