On Sat, 16 May 2020 at 12:56, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Ben,

On May 15, 2020, at 10:33 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, 15 May 2020 at 14:09, Shaping <shaping@uurda.org> wrote:

��

Would reintegrating Squeak and Pharo development make more sense?


I think that is not likely.�� Both continue to have different goals.�� And a significant area where they are likely to continue to diverge is the graphics.�� Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic.
This is one of the reasons��that Spec was created - to be independence layer.
IIUC in Pharo 9 Spec is already working on top of a GTK3 backend.

wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening��
is controlled from the Image via FFI rather than the VM.�� This conflicts with Squeak's backward comparability��goals.

The VM comprises an execution engine[1], a memory manager[2] (which share an object representation), and an assorted collection of plugins and platform support[3].�� The execution engine and��memory manager are the core support for Smalltalk language execution and are shared 100% between Squeak and Pharo.�� And I have rearchitected this core, adding a JIT and a much improved object representation and��memory manager.�� Pharo has made *no change* to this core.

The��assorted collection of plugins and platform support are a kit of parts which can be assembled in a variety of configurations, just as a Smalltalk image can be configured in radically different ways to develop and deploy different applications.

It is therefore not true that there is a conflict in backward compatibility.�� The core VM is only backward compatible at a source level.�� Backward compatibility in the platform is no more than a configuration in the kit of parts.�� And the existence of the minheadless minimal core platform support alongside the transitional head Gul platform proves that there need be no conflict.

The Pharo community makes great claims about how different its VM is when in fact the new work that has given us much improved performance and scalability is shared 109% between the two.

Thanks for clarifying that for Shaping.�� I did understand that [1] and [2] are the same for SqueakVM and PharoVM.�� My point was that IIUC Pharo is dropping some significant parts of [3] from their VM, so a Squeak/Pharo reintegration into a common Image running on a single VM binary could not run old Squeak images.�� Such backward compatibility I understand is important to the Squeak community,��but not so important to Pharo since Pharo delivers a specific VM for a specific Image Release and uses PharoLauncher to coordinate which VM to use for a given��Image.�� Just another difference in philosophy the would impede a full Squeak/Pharo reintegration.����

cheers -ben