[Pharo-project] decoupling the vm: UI and interpretation
Hi, a question to the VM maintainers. Would it be hard to decouple the VM, one part handling the object machinery, and the other the UI portion of the current OS. The "UI Vm" would feed the VM with the events, similarly to the current scheme, but there's no need for them to be coupled within the same project. So we could implement separately the "UI Vm", that its implemented in whatever windowed framework we choose ( Cocoa, X11, Windows, etc..). In short, do you think it would worth it to break the VM into two pieces: 1)UI VM: handles the window, the drawing context were Pharo should be drawn into, and announcing user events to the Smalltalk VM. 2)Smalltalk VM: everything else (truly headless). (The two OS processes could communicate via any available IPC(interprocess communication)) Wouldn't it make easier the task of maintaining and enhancing both VMs separately? This idea came up because of the current effort to free Pharo, from the outdated bitmap dependency, into a vectorial user interface framework. Fernando pd: I've been playing around recently with Cocoa, the "smalltalk and morphic" ripoff from apple. And found it relatively easy to come with a "UI VM". What is difficult is to plug into the current scheme.
On 20 December 2011 10:38, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi, Â a question to the VM maintainers.
Would it be hard to decouple the VM, one part handling the object machinery, and the other the UI portion of the current OS.
The "UI Vm" would feed the VM with the events, similarly to the current scheme, Â but there's no need for them to be coupled within the same project. So we could implement separately the "UI Vm", that its implemented in whatever windowed framework we choose ( Cocoa, X11, Windows, etc..).
In short, do you think it would worth it to break the VM into two pieces:
1)UI VM: handles the window, the drawing context were Pharo should be drawn into, and announcing user events to the Smalltalk VM. 2)Smalltalk VM: everything else (truly headless).
(The two OS processes could communicate via any available IPC(interprocess communication))
Wouldn't it make easier the task of maintaining and enhancing both VMs separately?
I think what would be easier is to make a language side to handle everything. Unfortunately in practice this means moving substantial parts implemented in C and putting in smalltalk. I also don't see how separating it into 2 processes make things easier. I think it will complicate things even more, because now you will need to invent own communication schemes , which is also platform specific. And possibly it will work slower because of IPC overhead.
This idea came up  because of the current effort to free Pharo, from the outdated bitmap dependency, into a vectorial user interface framework.
Fernando pd: I've been playing around recently with Cocoa, the "smalltalk and morphic" ripoff from apple. And found it relatively easy to come with a "UI VM". What is difficult is to plug into the current scheme.
-- Best regards, Igor Stasenko.
El 20/12/2011, a las 7:30a.m., Igor Stasenko escribió:
I think what would be easier is to make a language side to handle everything. Unfortunately in practice this means moving substantial parts implemented in C and putting in smalltalk.
+1 It takes time... but in the long way is the best approach, I think.
I also don't see how separating it into 2 processes make things easier. I think it will complicate things even more, because now you will need to invent own communication schemes , which is also platform specific. And possibly it will work slower because of IPC overhead.
They are not easier... but can be better for applications. That's the "default" behavior for mac and that's the reason why you usually don't have UI freezes while doing stuff (of course, not all applications -nor our vm, I changed it to single process- works that way... because is harder to maintain) best, Esteban
Em 20/12/2011 07:38, Fernando Olivero < fernando.olivero@usi.ch > escreveu:
Hi, a question to the VM maintainers. Would it be hard to decouple the VM, one part handling the object machinery, and the other the UI portion of the current OS. The "UI Vm" would feed the VM with the events, similarly to the current scheme, but there's no need for them to be coupled within the same project. So we could implement separately the "UI Vm", that its implemented in whatever windowed framework we choose ( Cocoa, X11, Windows, etc..).
I think this is an idea which may have appeal for theoretic reasons and even if it is short to medium term feasible it will not have the impact it deserves.
In short, do you think it would worth it to break the VM into two pieces: 1)UI VM: handles the window, the drawing context were Pharo should be drawn into, and announcing user events to the Smalltalk VM. 2)Smalltalk VM: everything else (truly headless). (The two OS processes could communicate via any available IPC(interprocess communication))
It would add complexity, reduce performance without any obvious advantage for the final user...
Wouldn't it make easier the task of maintaining and enhancing both VMs separately?
No, because the problems to port for each platform would remain all there. Worse, if we need to create a new "upper level" abstraction in order to translate all the UI VM primitives to all the corresponding platform OSs.
This idea came up because of the current effort to free Pharo, from the outdated bitmap dependency, into a vectorial user interface framework.
Which I see as distantly related issue which is not easily solvable by the proposal of this post.
Fernando pd: I've been playing around recently with Cocoa, the "smalltalk and morphic" ripoff from apple. And found it relatively easy to come with a "UI VM". What is difficult is to plug into the current scheme.
Yes, then imagine plug into the current scheme 'n' different UI VMs. . .
participants (4)
-
csrabak＠bol.com.br -
Esteban Lorenzano -
Fernando Olivero -
Igor Stasenko