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 <shap...@uurda.org <mailto:shap...@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
