Re: [Pharo-dev] Squeak and Pharo speed differences
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 mailto:shap...@uurda.org> > wrote: Hi all. Squeak 5.3: Time millisecondsToRun: [ 10 factorial ] 6250 Pharo 8: Time millisecondsToRun: [ 10 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
Re: [Pharo-dev] Squeak and Pharo speed differences
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. On Fri, May 15, 2020 at 12:48 PM Shaping wrote: > Hi all. > > > > > > Squeak 5.3: > > Time millisecondsToRun: [ 10 factorial ] 6250 > > > > Pharo 8: > > Time millisecondsToRun: [ 10 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
[Pharo-dev] [Pharo 9.0] Build #297: DebugSession: removing "keep-alive" dead-code
There is a new Pharo build available! The status of the build #297 was: FAILURE. The Pull Request #6315 was integrated: "DebugSession: removing "keep-alive" dead-code " Pull request url: https://github.com/pharo-project/pharo/pull/6315 Issue Url: https://github.com/pharo-project/pharo/issues/remove Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/297/
[Pharo-dev] [Pharo 9.0] Build #296: 6351-SyntaxErrorDebugger-messes-up-display-state-when-closed
There is a new Pharo build available! The status of the build #296 was: FAILURE. The Pull Request #6352 was integrated: "6351-SyntaxErrorDebugger-messes-up-display-state-when-closed" Pull request url: https://github.com/pharo-project/pharo/pull/6352 Issue Url: https://github.com/pharo-project/pharo/issues/6351 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/296/
[Pharo-dev] [Pharo 9.0] Build #295: DeprecateObject-notify-at
There is a new Pharo build available! The status of the build #295 was: SUCCESS. The Pull Request #6348 was integrated: "DeprecateObject-notify-at" Pull request url: https://github.com/pharo-project/pharo/pull/6348 Issue Url: https://github.com/pharo-project/pharo/issues/DeprecateObject Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/295/
