> 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()?
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.