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.htmland then moved onto vm-dev at:
http://lists.squeakfoundation.org/pipermail/vm-dev/2012-September/011347.htmlAs 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