May 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Squeak and Pharo speed differences

by Shaping

Squeak 5.3: Time millisecondsToRun: [ 100000 factorial ] 6250 Pharo 8: Time millisecondsToRun: [ 100000 factorial ] 7736 Why the difference? I have no idea. But I have to say that IN MY MACHINE: Squeak 5.3, just downloade: Time millisecondsToRun: [ 100000 factorial ]. 6289 Pharo (9, regular VM): Time millisecondsToRun: [ 100000 factorial ]. "3585" Pharo 9 64-bit: Time millisecondsToRun: [ 100000 factorial ]. 4074 My time is comparable to yours. This surprises me more than you, in fact because I was expecting similar times (VM is the same, after all). The algos are different: Pharo 8: Integer>>factorial "Answer the factorial of the receiver." self = 0 ifTrue: [^ 1]. self > 0 ifTrue: [^ self * (self - 1) factorial]. self error: 'Not valid for negative integers' Pharo 9: Integer>>factorial | nex nexnext acc | "Guard for know cases (0,1,2,error)" self < 3 ifTrue: [ ^ self < 0 ifTrue: [ self error: 'Not valid for negative integers' ] ifFalse: [ self > 0 ifTrue: [ self ] ifFalse: [ 1 ] ] ]. acc := 2. nex := 2. nexnext := 10. self // 2 - 1 timesRepeat: [ nex := nex + nexnext. nexnext := nexnext + 8. acc := acc * nex ]. self odd ifTrue: [ acc := acc * self ]. ^ acc In any case, no user of Pharo or Squeak will ever complain that the VM and math classes are too efficient. Why is there not always just one basic image and VM for both? Basically, all this benchmarks are very unreliable and depend a lot on the machine you are running and ultimately, "weather conditions". 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? In general , since VM is the same, if changes are in VM they are already in Pharo. Okay. By âin generalâ do you mean that forked deviations from a single target VM are few and transient/short-lived? 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? I donât know about Squeak, this is not the appropriate place to ask Squeak questions. Where else would we discuss both? On the Squeak list? Would mentioning Pharo there also be inappropriate? Is there a list where both a discussed? Iâm still discussing some Squeak issues with Robert in the context of parallelization of the VM. That doesnât seem to be a problem. He even suggested that I work on the VM in Squeak, which I might do. So he mentioned Squeak; that seems harmless. I donât understand the split. It looks silly. Maybe someone can explain the split in terms of technical/architectural advantages, if any exist. But yes, Pharo is in a battle to improve its GUI (we are basically rewriting all tools with Spec2, but even that some times is not enough since Morphic has become bloated, so our fight for performant tools is constant. Pharo 9 will replace all glamour based tools (Playground, inspector and debugger), plus some more old tools, and all will improve there I think (GTTools are cool, but Glamour was slow). The GT stuff is pretty good even if slow. Do you mean that the same GT GUIs will be re-implemented in Spec2 for greater speed, or will there also be other changes to those GUIs? 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. I donât knowâ¦ Iâm sure is possible, but someone has to do it :) What I can tell you is that text model/operation is a big concern for us... Yes, it seems very important. Itâs the only thing stopping my port. 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. Yes, it is a priority, but it is still a WIP. Part of this problems has nothing to do with GUIâ¦ thing is even if âdebuggerâ is same concept, our debugger and the old debugger (which squeak continued) have a complete different machinery behindâ¦ still, yes we are working. Yes, so it seems. The Squeak debugger is as nimble and quick as the new Pharo Launcher. Why wasnât the Squeak debugger adapted to Pharo when the speed difference was noticed? Itâs not a small difference, and if the slowness is not mostly about a text rendering problem, then adapting the Squeak debugger architecture to Pharo makes sense. Not speed-related: - How can I load additional fonts into Squeak? Pharo does this with the font dialogâs Update button. Youâll have to ask in squeak list, the sis not the appropriate place for that :) Okay. - 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. I do not understand what that is. Itâs the behavior I notice first in any GUI interaction. Leading-edge mouse event == button down Trailing-edge mouse event == button up. So I want all mouse actions to be on the button-down event. Itâs already done in some places, but the lack of uniformity is a speed problem. Still, I guess the right answer would be: if it is not there, being (both) open source projects that are sustained by communities, and being you part of the community, I think it would be a nice contribution for everybody if you absolute need this and you invest some time on doing it. It would not be something that needs development. Iâm looking for the spot in the code to make the change. Itâs very simple. I figure someone knows it because theyâve tweaked it already. That would save some time. I think I made the change myself in an older Pharo. I forgot where I did it. Cheers, Shaping

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Esteban Lorenzano

Hi, Apples and oranges here. Yes, both are fruits (perceived speed), but thatâs the only point in common :) Apples and oranges because one thing is the overall performance of the environment and another completely different the perceived execution speed of the GUI. Still, some answers: > On 15 May 2020, at 06:47, Shaping <shaping(a)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? I have no idea. But I have to say that IN MY MACHINE: Squeak 5.3, just downloade: Time millisecondsToRun: [ 100000 factorial ]. 6289 Pharo (9, regular VM): Time millisecondsToRun: [ 100000 factorial ]. "3585" This surprises me more than you, in fact because I was expecting similar times (VM is the same, after all). Basically, all this benchmarks are very unreliable and depend a lot on the machine you are running and ultimately, "weather conditions". > 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? In general , since VM is the same, if changes are in VM they are already in 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? I donât know about Squeak, this is not the appropriate place to ask Squeak questions. But yes, Pharo is in a battle to improve its GUI (we are basically rewriting all tools with Spec2, but even that some times is not enough since Morphic has become bloated, so our fight for performant tools is constant. Pharo 9 will replace all glamour based tools (Playground, inspector and debugger), plus some more old tools, and all will improve there I think (GTTools are cool, but Glamour was slow). > 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. I donât knowâ¦ Iâm sure is possible, but someone has to do it :) What I can tell you is that text model/operation is a big concern for us... > 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. Yes, it is a priority, but it is still a WIP. Part of this problems has nothing to do with GUIâ¦ thing is even if âdebuggerâ is same concept, our debugger and the old debugger (which squeak continued) have a complete different machinery behindâ¦ still, yes we are working. > > > Not speed-related: > > - How can I load additional fonts into Squeak? Pharo does this with the font dialogâs Update button. Youâll have to ask in squeak list, the sis not the appropriate place for that :) > - 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. I do not understand what that is. Still, I guess the right answer would be: if it is not there, being (both) open source projects that are sustained by communities, and being you part of the community, I think it would be a nice contribution for everybody if you absolute need this and you invest some time on doing it. Iâm sure you will have all help you need to do it in both communities. Cheers! Esteban > > > > Shaping

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Shaping

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(a)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(a)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 â

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Serge Stinckwich

Arithmetic changes proposed in Squeak have no relationships to VM. On Fri, May 15, 2020 at 2:09 PM Shaping <shaping(a)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(a)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 â

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Shaping

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(a)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 â

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo speed differences

by Serge Stinckwich

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 <shaping(a)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 â

May 15, 2020

Squeak and Pharo speed differences

by Shaping

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

May 15, 2020

[Pharo 9.0] Build #297: DebugSession: removing "keep-alive" dead-code

by ci-pharo-ci-jenkins2＠inria.fr

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%2…

May 14, 2020

[Pharo 9.0] Build #296: 6351-SyntaxErrorDebugger-messes-up-display-state-when-closed

by ci-pharo-ci-jenkins2＠inria.fr

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%2…

May 14, 2020

[Pharo 9.0] Build #295: DeprecateObject-notify-at

by ci-pharo-ci-jenkins2＠inria.fr

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%2…

May 14, 2020