Removing most of the windowing code

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

Re: Removing most of the windowing code

Igor Stasenko
 


On 24 November 2016 at 19:55, tim Rowledge <[hidden email]> wrote:


> On 23-11-2016, at 11:12 PM, Ronie Salgado <[hidden email]> wrote:
>
> In DisplayScreen class >> startUp we have the following:
> startUp  "DisplayScreen startUp"
>     Display setExtent: self actualScreenSize depth: Display nativeDepth.
>     Display beDisplay
>
> Does it make sense, to always trying to create a display in startup time?

No, it doesn’t. Ideally no resource should be started up/connected/created/tweaked until and unless it is actually needed by the running system.

Obviously, the default setup for a Smalltalk tends to be the GUI IDE and it’s so very easy to slide into the assumption that graphics and sounds and windows must be started up no matter what. We all do that kind of thing, even when we know we shouldn’t. You can make some reasonable arguments that an image configured to be an IDE ought to open a window or two during start up since that is kind of its raison d’etre.

My small protest against this is/was the RISC OS VM not creating a UI window until the first display update was made. At least that meant that an image with no need of a graphical UI never needed to do anything other than not display anything on the Display.

I’d say that all the host window IO related stuff ought to go into an extend HostWindowPlugin and be removed from the core. I’d also prefer all the plugins to be external, even though I know there can be a tiny performance hit, depending upon the details of how the OS does late binding. The unix VM kinda-sorta does some of this with the C++ usage and vm-display-xxxxx modules etc, but I think a lot more needs doing. And of course, the image needs lots of work to make good use of it. Until you have images that don’t need display/sound/sockets/whatever, there isn’t a lot of point worrying about the vm side.


In Pharo we did a special OSWindow layer, that allows platform-independent access to host window setup & manipulation etc.
There are multiple drivers , each for own platform/implementation, like SDL2, as well as a special NullWindowDriver, that simply passing all UI-related requirests to /dev/null ..
This is done so, to ensure that image could run fine even if VM is missing host window support or can't find any plugins etc, since historically too much code in image is done with 
assumption, that its always there.. In that case, we can always switch to null-window driver so all user-code would still function without knowing that there's actually no host window created etc.

 
tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LA: Lockout Access





--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Ben Coman
In reply to this post by Ronie Salgado
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Igor Stasenko
 


On 29 November 2016 at 14:43, Ben Coman <[hidden email]> wrote:
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben


well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API. 



--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Ronie Salgado
 
well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API.
Currently, I am going to focus on making a standard interface for initializing the VM, loading the image, passing the command line arguments, running the interpreter and shutting down. This seems easy to do, and it allows me to unify the platform specific versions of the VM.

For more complicated stuffs such as calling Smalltalk from C, or a standard interface for defining primitives in C( for doing things such as moving unessential VM plugins outside of the main VM source code tree). We should have a proper discussion on the mailing list.

My priority with removing the windowing code is getting OSWindow working well in Windows. Currently it is having conflicts with the main loop provided by the VM, which makes it unusable.

2016-11-29 14:22 GMT-03:00 Igor Stasenko <[hidden email]>:
 


On 29 November 2016 at 14:43, Ben Coman <[hidden email]> wrote:
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben


well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API. 



--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Igor Stasenko
 


On 29 November 2016 at 19:30, Ronie Salgado <[hidden email]> wrote:
 
well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API.
Currently, I am going to focus on making a standard interface for initializing the VM, loading the image, passing the command line arguments, running the interpreter and shutting down. This seems easy to do, and it allows me to unify the platform specific versions of the VM.

For more complicated stuffs such as calling Smalltalk from C, or a standard interface for defining primitives in C( for doing things such as moving unessential VM plugins outside of the main VM source code tree). We should have a proper discussion on the mailing list.

My priority with removing the windowing code is getting OSWindow working well in Windows. Currently it is having conflicts with the main loop provided by the VM, which makes it unusable.

right, this main loop concept is a first thing, that goes in a conflict with host application, that wants to control what it wants to run or not and when.

 
2016-11-29 14:22 GMT-03:00 Igor Stasenko <[hidden email]>:
 


On 29 November 2016 at 14:43, Ben Coman <[hidden email]> wrote:
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben


well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API. 



--
Best regards,
Igor Stasenko.






--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Igor Stasenko
 


On 29 November 2016 at 19:42, Igor Stasenko <[hidden email]> wrote:


On 29 November 2016 at 19:30, Ronie Salgado <[hidden email]> wrote:
 
well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API.
Currently, I am going to focus on making a standard interface for initializing the VM, loading the image, passing the command line arguments, running the interpreter and shutting down. This seems easy to do, and it allows me to unify the platform specific versions of the VM.

For more complicated stuffs such as calling Smalltalk from C, or a standard interface for defining primitives in C( for doing things such as moving unessential VM plugins outside of the main VM source code tree). We should have a proper discussion on the mailing list.

My priority with removing the windowing code is getting OSWindow working well in Windows. Currently it is having conflicts with the main loop provided by the VM, which makes it unusable.

right, this main loop concept is a first thing, that goes in a conflict with host application, that wants to control what it wants to run or not and when.


that's why, for instance i was pursuing the idea of implementing process scheduling in a language itself, leaving very small part of required logic on VM side
- mostly stripping a logic that switches process(es) to specially registered 'interrupt' process, when signal from semaphore arrived, while leaving the rest of logic on hands
of image-side implementation. 


--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Ben Coman
 
On Wed, Nov 30, 2016 at 1:49 AM, Igor Stasenko <[hidden email]> wrote:

>
>
>
> On 29 November 2016 at 19:42, Igor Stasenko <[hidden email]> wrote:
>>
>>
>>
>> On 29 November 2016 at 19:30, Ronie Salgado <[hidden email]> wrote:
>>>
>>>
>>>>
>>>> well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
>>>> and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
>>>> it's all because it was never designed to be run in a host environment and be open from that end.
>>>> that's why it is much easier to implement FFI, that C -> smalltalk API.

okay. thanks for the insight.

>>>
>>> Currently, I am going to focus on making a standard interface for initializing the VM, loading the image, passing the command line arguments, running the interpreter and shutting down. This seems easy to do, and it allows me to unify the platform specific versions of the VM.
>>>
>>> For more complicated stuffs such as calling Smalltalk from C, or a standard interface for defining primitives in C( for doing things such as moving unessential VM plugins outside of the main VM source code tree). We should have a proper discussion on the mailing list.
>>>
>>> My priority with removing the windowing code is getting OSWindow working well in Windows. Currently it is having conflicts with the main loop provided by the VM, which makes it unusable.
>>>
>> right, this main loop concept is a first thing, that goes in a conflict with host application, that wants to control what it wants to run or not and when.
>>
>
> that's why, for instance i was pursuing the idea of implementing process scheduling in a language itself, leaving very small part of required logic on VM side
> - mostly stripping a logic that switches process(es) to specially registered 'interrupt' process, when signal from semaphore arrived, while leaving the rest of logic on hands
> of image-side implementation.

Would it make sense to mix that in with DelayScheduler running at
priority 80?  Use the same Semaphore that is already signalled from
the VM.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

kilon.alios
In reply to this post by Igor Stasenko
 
Whats so special about pharo context and process  and how is that related to embedding pharo ?

On Tue, Nov 29, 2016 at 7:22 PM Igor Stasenko <[hidden email]> wrote:
On 29 November 2016 at 14:43, Ben Coman <[hidden email]> wrote:
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben


well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API. 



--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Removing most of the windowing code

Igor Stasenko
 


On 29 November 2016 at 22:51, Dimitris Chloupis <[hidden email]> wrote:
 
Whats so special about pharo context and process  and how is that related to embedding pharo ?

in short: scheduling , and top-level infinite loop.
 

On Tue, Nov 29, 2016 at 7:22 PM Igor Stasenko <[hidden email]> wrote:
On 29 November 2016 at 14:43, Ben Coman <[hidden email]> wrote:
 


On Thu, Nov 24, 2016 at 10:06 PM, Ronie Salgado <[hidden email]> wrote:
 
It is still needed to define a proper interface for embedding the VM. This interface should be a single .h file, with the highest level of abstraction possible. There are some other issues such as potential name clashes, and the fact that the VM symbols are public by default. At the bare minimum, it has to provide functions for initializing the VM, passing command line arguments, loading an image, running the image, and shutting down.

I don't know if its really suitable, but since Lua is the incumbent embedded gaming language, perhaps echoing it would make it easier to substitute ours for theirs.    

cheers -ben


well, the problem is that we're in a bit more difficult situation that Lua.. in Lua there's no processes/contexts..
and if we would want implement an external message send i.e.  send message - get result, things not so straightforward as in Lua.
it's all because it was never designed to be run in a host environment and be open from that end.
that's why it is much easier to implement FFI, that C -> smalltalk API. 



--
Best regards,
Igor Stasenko.




--
Best regards,
Igor Stasenko.
12