[Vm-dev] reducing the gap - ioProcessEvents()
K K Subbu
kksubbu.ml at gmail.com
Sun May 14 07:28:54 UTC 2017
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  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 :
and then moved onto vm-dev at:
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
More information about the Vm-dev