On Sat, 16 May 2020 at 12:56, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> Hi Ben, > > On May 15, 2020, at 10:33 AM, Ben Coman <b...@openinworld.com> wrote: > On Fri, 15 May 2020 at 14:09, Shaping <shap...@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
