reducing the gap - ioProcessEvents()

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

reducing the gap - ioProcessEvents()

Ben Coman
 
Its great that Pharo is back-in-the fold building out of the OpenSmalltalk repo,
but I wonder if we could be even closer, by trying to minimise the
number of  "#ifdef PharoVM".

Perhaps sqUnixMain.c is a good candidate.
To help analysis I ran the file through unifdef [1] and diff'd it here... .
* https://www.diffchecker.com/MO0KHNpH

One preliminary question...
   what is the return value of ioProcessEvents() used for?
Apart from this line in sqUnixMain.c...
   result = dpy->ioProcessEvents();
the rest of the codebase seems to discard the return value...
* https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=ioProcessEvents&type=

Now where Pharo always returns 0 from ioProcessEvents()
would that be a problem for Squeak?

So would Squeak be interested in adopting Pharo's flexible ioProcessEvents()?

[1] https://linux.die.net/man/1/unifdef

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

Re: reducing the gap - ioProcessEvents()

K K Subbu
 
On Friday 12 May 2017 11:52 PM, Ben Coman wrote:

>
> Its great that Pharo is back-in-the fold building out of the OpenSmalltalk repo,
> but I wonder if we could be even closer, by trying to minimise the
> number of  "#ifdef PharoVM".
>
> Perhaps sqUnixMain.c is a good candidate.
> To help analysis I ran the file through unifdef [1] and diff'd it here... .
> * https://www.diffchecker.com/MO0KHNpH
>
> One preliminary question...
>    what is the return value of ioProcessEvents() used for?
> Apart from this line in sqUnixMain.c...
>    result = dpy->ioProcessEvents();
> the rest of the codebase seems to discard the return value...
> * https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=ioProcessEvents&type=
>
> Now where Pharo always returns 0 from ioProcessEvents()
> would that be a problem for Squeak?
>
> So would Squeak be interested in adopting Pharo's flexible ioProcessEvents()?

The context starts here in pharo-project :
 
https://lists.gforge.inria.fr/pipermail/pharo-project/2012-September/069448.html
and then moved onto vm-dev at:
 
http://lists.squeakfoundation.org/pipermail/vm-dev/2012-September/011347.html

As far as I could make out, the change was made to delay handling i/o
events till the first host window is created and the image is ready to
process events. This gives more flexibility like multi-window, native
window integration etc, but it breaks old images which depend on the VM
for handling window events.

Regards .. Subbu