There is an issue about incorporating Squeak arithmetic changes in Pharo: https://github.com/pharo-project/pharo/issues/3322 I start to understand what could be done and could not find time to do the changes. You are welcome if you want to help. Arithmetic speed is important if most of one’s work is math and modeling. 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? 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. 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? It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. 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? Shaping On Fri, May 15, 2020 at 12:48 PM Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: Hi all. Squeak 5.3: Time millisecondsToRun: [ 100000 factorial ] 6250 Pharo 8: Time millisecondsToRun: [ 100000 factorial ] 7736 Why the difference? Squeak 5.3 release notes describe arithmetic improvements. Nice. I crunch very big numbers, and these improvements therefore have value. Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo? Playing with Squeak 5.3, I’ve noticed that the GUI is snappier. Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer. (Still that’s some work I prefer not to do.) Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2. I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs. The obvious question is: Will Squeak be improving GUI look/behavior and speed with Spec2? If not, can I load Spec2 into Squeak so that I can do new GUI work there? Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word. I thought I’d entered a wormhole. So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies. This matters to me. I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem. Can text-selection speed be improved to the level of VW’s? Can someone sketch the algo used and/or point me to the right class/methods. The Squeak debugging experience step-to-step is much quicker. The latencies in Pharo after button- release are very long. I estimate 100 to 150 ms. That’s too long for me to work productively. I lose my mental thread with many of those delays, and have to restart the thought. It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs). Is speeding up the Pharo debugger with Spec2 a priority? I can’t think of a better GUI-related priority for Pharo. Not speed-related: - How can I load additional fonts into Squeak? Pharo does this with the font dialog’s Update button. - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge? Some of the Squeak panes have this; others don’t. I want leading-edge action in all panes, and wish the feature were in Preferences/Settings. Shaping -- Serge Stinckwic ​h​ https://twitter.com/SergeStinckwich ​

Arithmetic changes proposed in Squeak have no relationships to VM. The question below is about both the VM and a common basic class-set. Math-related classes/methods are assumed to be part of that common class-set. Why is that not so? Shaping On Fri, May 15, 2020 at 2:09 PM Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: There is an issue about incorporating Squeak arithmetic changes in Pharo: https://github.com/pharo-project/pharo/issues/3322 I start to understand what could be done and could not find time to do the changes. You are welcome if you want to help. Arithmetic speed is important if most of one’s work is math and modeling. 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? 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. 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? It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. 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? Shaping On Fri, May 15, 2020 at 12:48 PM Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: Hi all. Squeak 5.3: Time millisecondsToRun: [ 100000 factorial ] 6250 Pharo 8: Time millisecondsToRun: [ 100000 factorial ] 7736 Why the difference? Squeak 5.3 release notes describe arithmetic improvements. Nice. I crunch very big numbers, and these improvements therefore have value. Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo? Playing with Squeak 5.3, I’ve noticed that the GUI is snappier. Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer. (Still that’s some work I prefer not to do.) Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2. I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs. The obvious question is: Will Squeak be improving GUI look/behavior and speed with Spec2? If not, can I load Spec2 into Squeak so that I can do new GUI work there? Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word. I thought I’d entered a wormhole. So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies. This matters to me. I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem. Can text-selection speed be improved to the level of VW’s? Can someone sketch the algo used and/or point me to the right class/methods. The Squeak debugging experience step-to-step is much quicker. The latencies in Pharo after button- release are very long. I estimate 100 to 150 ms. That’s too long for me to work productively. I lose my mental thread with many of those delays, and have to restart the thought. It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs). Is speeding up the Pharo debugger with Spec2 a priority? I can’t think of a better GUI-related priority for Pharo. Not speed-related: - How can I load additional fonts into Squeak? Pharo does this with the font dialog’s Update button. - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge? Some of the Squeak panes have this; others don’t. I want leading-edge action in all panes, and wish the feature were in Preferences/Settings. Shaping -- Serge Stinckwic ​h​ https://twitter.com/SergeStinckwich ​ -- Serge Stinckwic ​h​ https://twitter.com/SergeStinckwich ​

Hi Eliot. Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and that’s still too long. I can’t track the latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. It’s very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharos repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isn’t as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I don’t, but I find subject interesting, and would like to pursue it. I’m trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). It’s not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Shaping

1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and that’s still too long. I can’t track the latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. It’s very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Neither of these unequivocally demonstrates VM performance. I know. This comment is not about the VM. VM performance is another issue. This comment is only about general usability as a function of the latencies, whatever the cause. Both are more likely to derive from overall GUI architecture. Yup. In particular, VW’s display architecture is a direct stimulus-response i/o model where input results in a transformation producing immediate rendering, whereas Morphic is an animation architecture where input results in a new state but no rendering. The Morphic GUI is rendered separately on every “step” of the system. Okay. Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that. How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits? Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharo’s repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isn’t as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I don’t, but I find the subject interesting, and would like to pursue it. I’m trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). It’s not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Any VM. Express the benchmark as a block. If the benchmark is not trying to measure JIT and/or GC overhead then before the block is run make sure to put the vm in some initialized state wrt hitting and/or GC, eg by voiding the JIT code cache, How is the JIT code cache cleared? and/or forcing a scavenge or a global GC. Then run the block twice, reporting it’s second iteration, to ensure all code is JITted. Okay, so the above procedure tests execution-engine efficiency apart from JIT and GC efficiency. If attempting to measure JIT and/or GC overhead then do the same wet getting the vm to some baseline consistent initial state Baseline state: the only thing that comes to mind here is Collect All Garbage. and then ensure, through the relevant introspection primitives, What are these? What state features am I introspecting after the test? Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. that after the benchmark has run the events desired to be benchmarked have actually taken place. I’m thinking most checks on state will involve running more Smalltalk, not just primitives. If a micobenchmark then ensure that eg loop, block invocation, arithmetic, overheads are either minimised wrt the code being benchmarked or subtracted from the code being benchmarked. Okay. i.e. make sure the benchmark is repeatable (benchmark an initial used state). make sure the benchmark measures what is intended to be benchmarked and not some overhead. Right. I don’t see how to guarantee some known starting state except to collect all garbage. Shaping

Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that. Given that both Pharo and Squeak useorphic and hence nothing have the same tender-in-step architecture isn’t the fact that they show the sane performance issue evidence that points to precisely this being the cause? Yes, but not architecture, by which I think you mean the pushing of events versus the fixed-frequency regular loop in Morphic. I would expect a big variation in the Morphic case, but I don’t know what the fixed frequency is; it could well under the noise floor. My first thought would be that getting the damage rects is the problem, but I’ve not seen the code. How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits? My understanding is that damage rectangles are retrieved, Right, but this is the potentially slow part—the retrieving or perhaps more specifically mapping a point to a rectangle containing a contiguous sequence of non-whitespace character (a word). combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles. You can read the gods for yourself. It’ll be a while. …. I just tried some new experiments. I should have thought of these earlier. Character insertion and cursoring in any direction by one character have the same latency. Collecting the damage rectangle at the cursor position and around the selected word are both taking about the same time as far as I can tell with my eye, and this time is longer than in VW or any Windows app. But VW doesn’t use the Windows message queue directly. All incoming Windows events are converted to Smalltalk equivalents and are queued on the Smalltalk side. And it works well. Why not mimic that pattern to get the extra speed? Does something in Squeak/Pharo architecture prevent us from doing that? How do we set a multi-process time profiler running so that we don’t need to eval blocks to get tallies. I just want to use the editor and watch method hit distribution. I see the Time profiler window; it seems to need a code snippet to work. How is the JIT code cache cleared? Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. Okay. Can’t remember how it’s done in VW. CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod flushCachedVMCode] Baseline state: the only thing that comes to mind here is Collect All Garbage. There’s also Smalltalk garbageCollectMost which just runs a scavenge. IIRC someInstance has a side effect of running a scavenge in VW. Okay. and then ensure, through the relevant introspection primitives, What are these? What state features am I introspecting after the test? Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm parameterAt: and senders. Okay. I see this list: parameterAt: parameterIndex "parameterIndex is a positive integer corresponding to one of the VM's internal parameter/metric registers. Answer with the current value of that register. Fail if parameterIndex has no corresponding register. VM parameters are numbered as follows: 1 end (v3)/size(Spur) of old-space (0-based, read-only) 2 end (v3)/size(Spur) of young/new-space (read-only) 3 end (v3)/size(Spur) of heap (read-only) 4 nil (was allocationCount (read-only)) 5 nil (was allocations between GCs (read-write) 6 survivor count tenuring threshold (read-write) 7 full GCs since startup (read-only) 8 total milliseconds in full GCs since startup (read-only) 9 incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 10 total milliseconds in incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 11 tenures of surving objects since startup (read-only) 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use 20 utc microseconds at VM start-up (actually at time initialization, which precedes image load). 21 root table size (read-only) 22 root table overflows since startup (read-only) 23 bytes of extra memory to reserve for VM buffers, plugins, etc (stored in image file header). 24 memory threshold above which shrinking object memory (rw) 25 memory headroom when growing object memory (rw) 26 interruptChecksEveryNms - force an ioProcessEvents every N milliseconds (rw) 27 number of times mark loop iterated for current IGC/FGC (read-only) includes ALL marking 28 number of times sweep loop iterated for current IGC/FGC (read-only) 29 number of times make forward loop iterated for current IGC/FGC (read-only) 30 number of times compact move loop iterated for current IGC/FGC (read-only) 31 number of grow memory requests (read-only) 32 number of shrink memory requests (read-only) 33 number of root table entries used for current IGC/FGC (read-only) 34 number of allocations done before current IGC/FGC (read-only) 35 number of survivor objects after current IGC/FGC (read-only) 36 millisecond clock when current IGC/FGC completed (read-only) 37 number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC (read-only) 38 milliseconds taken by current IGC (read-only) 39 Number of finalization signals for Weak Objects pending when current IGC/FGC completed (read-only) 40 BytesPerOop for this image 41 imageFormatVersion for the VM 42 number of stack pages in use 43 desired number of stack pages (stored in image file header, max 65535) 44 size of eden, in bytes 45 desired size of eden, in bytes (stored in image file header) 46 machine code zone size, in bytes (Cog only; otherwise nil) 47 desired machine code zone size (stored in image file header; Cog only; otherwise nil) 48 various header flags. See getCogVMFlags. 49 max size the image promises to grow the external semaphore table to (0 sets to default, which is 256 as of writing) 50-51 nil; reserved for VM parameters that persist in the image (such as eden above) 52 root table capacity 53 number of segments (Spur only; otherwise nil) 54 total size of free old space (Spur only, otherwise nil) 55 ratio of growth and image size at or above which a GC will be performed post scavenge 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only) 61 number of stack page divorces since startup (read-only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil) 64 the number of methods that currently have jitted machine-code 65 whether the VM supports a certain feature, MULTIPLE_BYTECODE_SETS is bit 0, IMMTABILITY is bit 1 66 the byte size of a stack page 67 the max allowed size of old space (Spur only; nil otherwise; 0 implies no limit except that of the underlying platform) 68 the average number of live stack pages when scanned by GC (at scavenge/gc/become et al) 69 the maximum number of live stack pages when scanned by GC (at scavenge/gc/become et al) 70 the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION) 71 the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)" Shaping

I forgot to mention that Pharo Zinc with all those primitives produces an HTTP data transfer rate (CSV data) twice as fast as VW’s HTTP client. I tested it many times. Pharo HTTP (Zinc) is consistently 2x faster than VW HTTP. This is probably more about the judicious use of primitives than the execution engine, JIT, or MM. This is another good reason to do a port. Also, Pharo’s WebSocket implementation works very well, and is a standalone Smalltalk client. No such thing exists in VW. It’s all JS, which has been a source of frustration, and is another good reason to port. Shaping Hi Eliot. Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and that’s still too long. I can’t track the latency in VW 8.3.2. It’s too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. It’s very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharos repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isn’t as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I don’t, but I find subject interesting, and would like to pursue it. I’m trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). It’s not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Shaping

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:

...

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

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." Lol Thanks for the explanation. That’s more or less what I thought. But can’t the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower? 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. I like disentangling and modularizing. I suppose this is a universal like. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, I like this too. whereas Squeak continues to use a "continuous evolution" model. Don’t both groups want the automatic building and testing the Consortium is talking about recently? I’m not sure I understand how “continuous evolution” works. Sounds like there is lots of wiggle room in that idea. Don’t we need some structure? We seem to be getting that in Pharo. I’m not sure about Squeak. The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later. I used it between 2002 to 2004, and then again just a few days ago. I like the faster debugger and the flat GUIs, but I don’t need Morphic to have those dev-tool GUIs. I’d prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice). The rest of Squeak seems messy. I do very much like the technical, concrete feel of Squeak’s details about the VM. That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization. Those VM details need a somewhat different shape/presentation. There is a beauty in Squeak, but the eviron still feels a bit rough. For example, why aren’t all those preferences in a tree where you can actually find things because they are categorized. It’s a big list. That seems very strange in 2020. Why don’t Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like? I thought more would have happened in the Squeak GUI in 16 years, but I’ve not seen all of 5.3 yet. I’m still poking around. I suppose most of the improvements are in the VM, which I imagine absorbs most of the group’s energy. 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 Thank you. I will read it. Is the Consortium updating that doc? There was a doc recently from Stef that looks like it belongs in there, merged somehow. 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. Agreed. I don’t understand the pushback because I don’t understand Squeak folks’ objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks. They are probably fine with all that. Do Squeak folks have a document that defines “continuous development.” I know that VM testing is automated. I don’t see how the objectives are so different, at least on the automation front. Everyone seems to agree that CI is good. 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. I never liked the halo thing. It’s okay. It seemed/seems too busy and distracting. I think Morphic and the “too many cooks” problem is why I broke off in 2004. If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk. Have all your GUIs built with Morphic. Have cute little morphs stuck here and there. Knock yourself out. Don’t like Morphic? Don’t think it’s cute? Load the more business-like-but-not-boring Spec2. I don’t see an insurmountable technical problem here. 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. Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak. I’ve mentioned this a few times recently—of all the goofy things to prevent a port from VW…..Okay, that and Pharo’s slow debugger. Two things keep me out of Pharo/Squeak. I don’t love VW. I tolerate it really well. That’s different. :) 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. I agree with the objective. This conflicts with Squeak's backward comparability goals. Okay, this is the real problem. So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence. Perhaps someone can give more details on that old code. I suppose many Squeak folks bemoan all the extra work needed for a recoding. Is this still really an issue? Maybe very little of that old code is still being used in business-critical ways. The need for a recoding may not be the big issue it once was. 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. That’s a very good idea. Why don’t all the Squeak folks work on it? Are you the only one pushing for this? 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 (??) It’s a good question. Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently? There’s a lot of that in Morphic. I suppose it’s the main concern. Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI. Shaping