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: > >> Why can’t the OSVM be a single, unforked, maxed-out VM with all the best and >> fastest features working in Squeak and Pharo? Why did the split happen? >> > > In very general terms, the fork was due to their being Group A wanting to go > one direction > and Group B wanting to go in a different direction. i.e.... > B says "We want to do X". > A says "We don't want to do X." > B says "We really want to do X." > A says "Definitely no." > B says "We really want to do X and actually we're doing it over here." > > In essence, Squeak considered backward compatibility of prime importance > including the code of some applications that had become entangled in the main > code base. Pharo wanted to "clean the code" by disentangling and stripping > those parts. They also wanted to move to a reproducible-build-system where > each change "bootstrapped" a nightly image from an empty file, whereas Squeak > continues to use a "continuous evolution" model. And there are more reasons I > probably not aware of. > Here is the Pharo Vision document circa 2012 which inspired me > https://hal.inria.fr/hal-01879346/document > > >> It looks like a bad use of energy in a community that is small and needs to >> use its human resources efficiently. >> > > Trying to go one way and dealing with continual pushback and conflict around > that is also bad energy. > > >> I want to help, but need to port first from VW, and I’m trying to choose >> Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo >> could be much faster with broad use of Spec2. >> >> >> >> 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, a memory manager (which share an object representation), and an assorted collection of plugins and platform support. 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. >> This change would effectively create more devs willing to work on any >> problem. This change would also prevent fracturing of feature-sets across >> the two Smalltalks from happening in the first place. >> > > I personally had the inspiration that Squeak might be based off the Pharo > Headless Bootstrap, > but in the end I didn't find the time to push this further. > > >> Squeak and Pharo GUI styles are different. So be it. Can’t the GUI >> frameworks and conventions be separated in the same image, and configured as >> desired in GUI sections of Settings? >> > > Pharo currently can use both Morphic and GTK3 for its GUI backend. > Possibly the GTK3 backend would provide some speed benefit (??) > > cheers -ben >
