decoupling the vm: UI and interpretation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

decoupling the vm: UI and interpretation

Fernando olivero-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Igor Stasenko
On 20 December 2011 10:38, Fernando Olivero <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Fernando olivero-2
In reply to this post by Igor Stasenko
Ok, i'm in favor of having everything in smalltalk too.

The problem i have is the following:  i want to change  "how" the VM
should announce events "were" the vm should draw

Regarding the "were", currently the VM has a primitive from which you
can specify which Form will act as the Display. But what if i want to
render to something else than a form?
Esteban: how does the COCOA VM draw the Display? Does it create a
NSWindow, with a custom view, which copies the bits from the Display
Form, into a drawing context (Quartz? OpenGL?).

If we are moving towards a vectorial framework( AthensCanvas rendering
to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive
in the vm. there's no need for such primitive.
We just need access to the drawing context of the Pharo window, and
render whatever we want there.

We need the following: (using COCOA as an example)
an OS window =>NSWindow
with a custom view ==> subclass of NSView
that creates a Cairo surface to a quartz backend, from which in the
image side i can tell the AthensCanvas to draw into.

For the event part, i should directly change the platform specific
code for the Cocoa VM's?
Cocoa provides higher level events and the VM is encoding them into
Arrays, that in the image are decoded back into high level events (
see HandMorph>>generateEvt:from:). Which makes it hard to add new kind
of events, specifically those originated from the trackpad (pinch,
swipe, etc). (another BIG  problem is that  currently, all the VMs
arent encoding EXACTLY the same OS events into the VM Arrays of
events). I would like to play with the OS event encoding/decoding, to
not loose so much in the translation.

Please let me know wether i explained myself clearly, i'm still in the
process of understanding how to detach the VM from the Bitmapped
forms.

Fernando


On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Igor Stasenko
I wanting the same long time :)

Having a VM which handling a platform-specific nuances and providing a
uniform interface
to language side is a great advantage.
But of course it not comes without drawbacks: you have a minimal
common functionality,
provided over all supported platforms.

It would be cool to change the situation.
A first step would be to make a Display/events primitives optional
(move them into a separate plugin,
outside of core VM).
Like that a "default" VM without such plugin will be headless without
obligation to support graphical user interface.
The next step is, like you said, think about how to encode events
without losing flexibility and pass them to language side.

On 20 December 2011 13:12, Fernando Olivero <[hidden email]> wrote:

> Ok, i'm in favor of having everything in smalltalk too.
>
> The problem i have is the following:  i want to change  "how" the VM
> should announce events "were" the vm should draw
>
> Regarding the "were", currently the VM has a primitive from which you
> can specify which Form will act as the Display. But what if i want to
> render to something else than a form?
> Esteban: how does the COCOA VM draw the Display? Does it create a
> NSWindow, with a custom view, which copies the bits from the Display
> Form, into a drawing context (Quartz? OpenGL?).
>
> If we are moving towards a vectorial framework( AthensCanvas rendering
> to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive
> in the vm. there's no need for such primitive.
> We just need access to the drawing context of the Pharo window, and
> render whatever we want there.
>
> We need the following: (using COCOA as an example)
> an OS window =>NSWindow
> with a custom view ==> subclass of NSView
> that creates a Cairo surface to a quartz backend, from which in the
> image side i can tell the AthensCanvas to draw into.
>
> For the event part, i should directly change the platform specific
> code for the Cocoa VM's?
> Cocoa provides higher level events and the VM is encoding them into
> Arrays, that in the image are decoded back into high level events (
> see HandMorph>>generateEvt:from:). Which makes it hard to add new kind
> of events, specifically those originated from the trackpad (pinch,
> swipe, etc). (another BIG  problem is that  currently, all the VMs
> arent encoding EXACTLY the same OS events into the VM Arrays of
> events). I would like to play with the OS event encoding/decoding, to
> not loose so much in the translation.
>
> Please let me know wether i explained myself clearly, i'm still in the
> process of understanding how to detach the VM from the Bitmapped
> forms.
>
> Fernando
>
>
> On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <[hidden email]> wrote:
>>
>> 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
>>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Fernando olivero-2
In reply to this post by Fernando olivero-2
YES!,the current VM was devised on 90's, maybe its time to alter it a bit now..

Esteban, in your opinion would this be feasible, in decent amount of
time? Moving Display to a separate plugin.

Yet remains a question, how would the "UI-pluggable VM" talk with the
headless vm.
I will implement a proof of concept, using some kind of IPC (for the
MAc), so we can measure the responsiveness of such scheme.


Fernando

On Tue, Dec 20, 2011 at 1:58 PM, Igor Stasenko <[hidden email]> wrote:

> I wanting the same long time :)
>
> Having a VM which handling a platform-specific nuances and providing a
> uniform interface
> to language side is a great advantage.
> But of course it not comes without drawbacks: you have a minimal
> common functionality,
> provided over all supported platforms.
>
> It would be cool to change the situation.
> A first step would be to make a Display/events primitives optional
> (move them into a separate plugin,
> outside of core VM).
> Like that a "default" VM without such plugin will be headless without
> obligation to support graphical user interface.
> The next step is, like you said, think about how to encode events
> without losing flexibility and pass them to language side.
>
> On 20 December 2011 13:12, Fernando Olivero <[hidden email]> wrote:
>> Ok, i'm in favor of having everything in smalltalk too.
>>
>> The problem i have is the following:  i want to change  "how" the VM
>> should announce events "were" the vm should draw
>>
>> Regarding the "were", currently the VM has a primitive from which you
>> can specify which Form will act as the Display. But what if i want to
>> render to something else than a form?
>> Esteban: how does the COCOA VM draw the Display? Does it create a
>> NSWindow, with a custom view, which copies the bits from the Display
>> Form, into a drawing context (Quartz? OpenGL?).
>>
>> If we are moving towards a vectorial framework( AthensCanvas rendering
>> to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive
>> in the vm. there's no need for such primitive.
>> We just need access to the drawing context of the Pharo window, and
>> render whatever we want there.
>>
>> We need the following: (using COCOA as an example)
>> an OS window =>NSWindow
>> with a custom view ==> subclass of NSView
>> that creates a Cairo surface to a quartz backend, from which in the
>> image side i can tell the AthensCanvas to draw into.
>>
>> For the event part, i should directly change the platform specific
>> code for the Cocoa VM's?
>> Cocoa provides higher level events and the VM is encoding them into
>> Arrays, that in the image are decoded back into high level events (
>> see HandMorph>>generateEvt:from:). Which makes it hard to add new kind
>> of events, specifically those originated from the trackpad (pinch,
>> swipe, etc). (another BIG  problem is that  currently, all the VMs
>> arent encoding EXACTLY the same OS events into the VM Arrays of
>> events). I would like to play with the OS event encoding/decoding, to
>> not loose so much in the translation.
>>
>> Please let me know wether i explained myself clearly, i'm still in the
>> process of understanding how to detach the VM from the Bitmapped
>> forms.
>>
>> Fernando
>>
>>
>> On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <[hidden email]> wrote:
>>>
>>> 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
>>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Igor Stasenko
On 21 December 2011 08:45, Fernando Olivero <[hidden email]> wrote:

> YES!,the current VM was devised on 90's, maybe its time to alter it a bit now..
>
> Esteban, in your opinion would this be feasible, in decent amount of
> time? Moving Display to a separate plugin.
>
> Yet remains a question, how would the "UI-pluggable VM" talk with the
> headless vm.
> I will implement a proof of concept, using some kind of IPC (for the
> MAc), so we can measure the responsiveness of such scheme.
>

.. and probably while inventing this new wheel, you can read about X
server design,
which having such architecture for years. :)
But we need that wheel for sure, even if we need to reinvent it :)



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Frank Shearar-3
On 21 December 2011 10:58, Igor Stasenko <[hidden email]> wrote:

> On 21 December 2011 08:45, Fernando Olivero <[hidden email]> wrote:
>> YES!,the current VM was devised on 90's, maybe its time to alter it a bit now..
>>
>> Esteban, in your opinion would this be feasible, in decent amount of
>> time? Moving Display to a separate plugin.
>>
>> Yet remains a question, how would the "UI-pluggable VM" talk with the
>> headless vm.
>> I will implement a proof of concept, using some kind of IPC (for the
>> MAc), so we can measure the responsiveness of such scheme.
>>
>
> .. and probably while inventing this new wheel, you can read about X
> server design,
> which having such architecture for years. :)
> But we need that wheel for sure, even if we need to reinvent it :)

If this is going to end up re-inventing X, why not just use X? And I
don't mean re-implementing X either, but using someone else's hard
work.

frank

Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

Yanni Chiu
On 21/12/11 9:10 AM, Frank Shearar wrote:
>
> If this is going to end up re-inventing X, why not just use X? And I
> don't mean re-implementing X either, but using someone else's hard
> work.

Doesn't RFB/VNC implement something close to X Protocol?


Reply | Threaded
Open this post in threaded view
|

Re: decoupling the vm: UI and interpretation

csrabak
In reply to this post by Fernando olivero-2
Em 20/12/2011 07:38, Fernando Olivero < [hidden email] > 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. . .

>
>