There is an issue about incorporating Squeak arithmetic changes in Pharo:
��
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> 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
��
��
��
��
��
��
��
��
��
--