Hi Stéphane,

In the GnuSmalltalk PoC I could init the VM and then I run functions in it like this:
   gst_perform(pObjGame, selector);

Then I created some native test functions in C like this:
   gst_define_cfunc("DECanvas.setPosition", (void*)funcSetPosition);"

I then added in smalltalk a function definition calling the c-function like this:
position: aDEPoint [
   "Set position in parent canvas view units."
   <cCall: 'DECanvas.setPosition' returning: #void args: #(#self #smalltalk)>
]

If PharoVM would provide a mechanis like this then this would be all I need to pull it off.

That said though I don't know how the PharoVM works on the inside. I just read somewhere that there is an FFI with cCall so that sounds like basically half the job done.

Just tossing thoughts around here though.

Hi roland, 

From: Roland Plüss <[hidden email]>

Subject: Re: Embedding pharo in C++

Date: 21 January 2020 at 20:20:48 CET

To: [hidden email]

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,

Oh nice….

Long time :)

I was younger :)

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.

What is nice there is that it is also a safer path because it may be less complex. 

Theo is working on 

- exposing an interface of the VM so that we can query it from the outside. 

- I would love to be able to say to the VM to run a number of steps so that we could test it from outside

But this is really brainstorming. 

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.

The second scenario is what is used in woden and thales used it to developed the proof of concept with their boats. 

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

Does this sound feasible in the way PharoVM is designed?

I think that you can really have bindings and drive them from Pharo. 

Now what is complex is more the reverse control, in the sense that you want your application to drive Pharo.

I will let VM experts reply to you. 

In any case we are really interesting in helping you and getting information about our lacks and limits. 

On 21 Jan 2020, at 18:29, Roland Plüss <[hidden email]> wrote:

From: Roland Plüss <[hidden email]>

Subject: Embedding pharo in C++

Date: 21 January 2020 at 18:29:04 CET

To: [hidden email]

As the topic title mentions I would like to embed pharo into a GPL/L-GPL licenses software.

from the license point of view you can do it freely/ 

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.

We are really interesting in this experiment. 

We would love that it is possible (I have some doubts but this is important that we learn). 

For example 

- you can have an image without UI and it will remove a lot of burden (events and others)

- we worked on making Pharo silent (not reading, writing to files - there are certainly some problems 

but we should improve). 

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?

I will let the expert reply to you. 

But what I can tell you is that all the work around the headless vm and the idle are steps in that direction. 

We may not be fully ready now but we would love. 

S. 

--
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

--------------------------------------------

Stéphane Ducasse

http://stephane.ducasse.free.fr / http://www.pharo.org 

03 59 35 87 52

Assistant: Julie Jonas 

FAX 03 59 57 78 50

TEL 03 59 35 86 16

S. Ducasse - Inria

40, avenue Halley, 

Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650

France

--
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

--------------------------------------------

Stéphane Ducasse

http://stephane.ducasse.free.fr / http://www.pharo.org 

03 59 35 87 52

Assistant: Julie Jonas 

FAX 03 59 57 78 50

TEL 03 59 35 86 16

S. Ducasse - Inria

40, avenue Halley, 

Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650

France

signature.asc (201 bytes) Download Attachment