As the topic title mentions I would like to embed pharo into a GPL/L-GPL licenses software. I experimented before with a PoC based on GnuSmalltalk which allows embedding and this worked but GnuSmalltalk is kinda outdated and even fails to properly compile since some time. For this reason I would like to do another
PoC but with Pharo to see if this would be a candidate to use in
the project. The application is C++ based but a C interface is fine with me too. Important is that the Pharo VM is fully controlled by the application not running a pharo image with a VM binary or things like that. Is this possible and if yes how does it
work?
--
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 signature.asc (201 bytes) Download Attachment |
Looks like you always meet twice in life I guess. You won't remember me but I've been a student of yours once upon time. Nice to see you again, Prof. Ducasse, I had in mind to have the VM running in two modes actually. 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. 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. Does this sound feasible in the way PharoVM is designed?
--
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 signature.asc (201 bytes) Download Attachment |
Hi Stéphane, In the GnuSmalltalk PoC I could init the VM and then I run
functions in it like this: On 1/21/20 10:13 PM, Stéphane Ducasse
wrote:
Hi roland, --
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 signature.asc (201 bytes) Download Attachment |
In reply to this post by Pharo Smalltalk Users mailing list
Good day
Is it a variant to implement an embeddable Little Smalltalk-like engine that does not use bytecode but uses LLVM JIT for direct machine code compilation? Or maybe can we use a less aggressive approach with the same embedded engine which interprets bytecode? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by Pharo Smalltalk Users mailing list
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 embedded-linux.png (82K) Download Attachment |
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 <[hidden email]> 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. [hidden email] |
On Wed, Jan 22, 2020 at 10:09:33AM +0100, [hidden email] 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 <[hidden email]> wrote: > > On Wed, Jan 22, 2020 at 10:09:33AM +0100, [hidden email] 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. [hidden email] |
On Wed, Jan 22, 2020 at 11:04:07AM +0100, [hidden email] 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, [hidden email] 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 signature.asc (201 bytes) Download Attachment |
Hi Roland,
the function vm_main_with_parameters() starts the vm and it will not return until the image finishes. In my example, only when the SDL window is closed, the quit primitive is executed and the function ends. To do a nicer POC we need to make modifications in the image, so it handles keeping the image open. On Wed, Jan 22, 2020 at 7:08 PM Roland Plüss via Pharo-users <[hidden email]> wrote: > > 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, [hidden email] 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 > -- Pablo Tesone. [hidden email] |
The dragon has been unleashed. The game engine is now available to the
public. See https://www.indiedb.com/engines/dragengine for more information. Right now the Smalltalk Script Module is a proof of concept with the GNU Smalltalk. The idea is to change this to use Pharo and bringing it up to the scope of the DragonScript module. The source code repository is at https://github.com/LordOfDragons/dragengine . I'll add a branch "feature-pharo" to contain all this work. Once Pharo is up to be used properly for embedding (or to help getting there) this branch can be used. Since it is right now in a proof-of-concept state I think it would be not a bad idea to experiment with Pharo embedding there when not yet too many engine relate complications are present. -- 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 signature.asc (201 bytes) Download Attachment |
This is an exciting work Roland.
Keep going! Bridging Pharo to other technologies is crucial, and you are doing well. Something you could do, is having Pharo running, on a different process, and exchanging (using a binary format) things between C++ and Pharo. We are doing this using CSharp and Python, and it works well. cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
In reply to this post by Pharo Smalltalk Users mailing list
Thinking about it I would have a better idea: ITC. The best solution though would be embedding like GNU Smalltalk has it. But that's a question for Pablo. How feasible is it to have an embedded working version in the near future? That said both versions (embedded, ITC) would shared majority of code so going one way or the other does not exclude the other way. On 4/22/20 6:14 PM, Alexandre Bergel
wrote:
This is an exciting work Roland. --
Yours sincerely Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc (201 bytes) Download Attachment |
Free forum by Nabble | Edit this page |