- Pharo-dev - lists.pharo.org

Squeak and Pharo why the fork - was: Squeak and Pharo speed differences

by Jimmie Houchin

On 5/15/20 5:26 AM, Shaping wrote: > I donât understand the split.Â It looks silly.Â Maybe someone can > explain the split in terms of technical/architectural advantages, if > any exist. > > Cheers, > > Shaping > I began using Squeak about 20 years ago. And then Pharo when it started. I will explain as best as I can. The differences do have bearing on architecture and technical things but at the beginning the basis of it all is philosophy. Differences in what you want Squeak/Pharo to be, where you want it go. Squeak is from Apple Smalltalk. Smalltalk is not simply a language, but began as an OS, an environment and a language. It ran directly on the hardware. Then Smalltalk was ported to operating systems. But still took with it a very OS like environment and world view. It was the world. This was very much Squeak. Squeak was the world. It was an amazing and interesting environment. It could play mp3s, had MIDI capabilities. It was a very interesting multimedia environment. Bright, colorful, creative.Â But it was also a very productive programming environment to build whatever you wanted to build. All of the people involved in Squeak, loved the productivity of the Smalltalk language and the live environment. You had debates about "Pink plane" vs "Blue plane". What was the direction of the community and the artifact Squeak. There were two large communities with differing opinions on direction. Alan Kay The Computer Revolution Hasn't Happened Yet OOPSLA 97 Keynote (VPRI 0719) https://www.youtube.com/watch?v=aYT2se94eU0 """ https://pab-data.blogspot.com/2007/03/what-colour-do-you-like-your-objects.… In Alan Kay's keynote speech at OOPSLA in 1997 he talks about a blue plane and a pink plane. The pink plane represents ideas which are an incremental improvement of existing ideas. The blue plane which runs orthogonal to the pink represents revolutionary ideas that break the old way of doing things, setting you off in a new direction. """ Many people had projects and ideas which were very able to be done in Squeak, but did not want the entire OS-like image. ... Maybe I want a web server.Â I don't need to play multimedia files. Have a GUI. etc. Insert your own application here. People wanted to build businesses around what they could do with Squeak. The Pink plane community wanted to begin to clean up Squeak. Break it up into parts which could be reloaded. It wanted a much more modular environment which allowed you to build the image you want for the purpose you intend. The Blue plane community didn't see any problems with the way it was. They liked it and still do. It fit what they wanted to do with Squeak/Smalltalk. Frequently more research oriented and less business oriented. Then in the midst of all this you have overlap in individuals who understand both. You also had personality differences and disagreements which developed over years. Eventually the Pink plane community forked and created Pharo. The foundational community of Squeak (Blue plane) did not want to make the changes the Pink plane community wanted or required. Pharo is now 12 years or so into its journey. It is not easy losing weight and still keep working. But that is the goal of Pharo. Keep reducing until the entire system can be built up from a base image. And when it gets there. We don't have a problem with from that foundation, being able to build it back up into a Squeak-like image. I have numerous projects which I am doing in Pharo. One is a trading application. I personally want as little in my image as possible which does not have to do with my trading application. It desires to be as fast as possible, run without failure, and as memory and cpu efficient as I can make it to be in Pharo. I could make and run this application in Squeak. But it would include much that I don't need and don't want. And that is the case in Pharo currently as well. But Pharo has its philosophy and its direction that it is moving towards. At some point in time my trading application will what I want it to be with very little unused code in the image. That might not be until Pharo 10+. I don't know. But there is a vision within Pharo for people to build such applications. I have not used Squeak in years. And nothing I write here is meant to speak badly about Squeak. I like the Squeak community. They are full of great people. And I do not know how accurate what I write is to the current Squeak. My apologies for any inaccuracies or errors. Pharo in general is much more pro-business. It is an explicit goal of Pharo. https://pharo.org/about https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf Both websites give you a feel for who the community is and the orientation of their goals. As much as re-unification would be nice. I don't know that it will happen. At a minimum, not until the Squeak community could build Squeak from a Pharo kernel image. Then it would be possible. But I don't think likely. This is just my generalizations in an effort to answer your question. There are people who are in both communities. Both communities in general attempt to cooperate when we can. Both are communities with friendly, amazing people. And both communities have people who have been doing this for a very long time, and that is a very good thing. Both are completely open source projects which will allow you to do whatever you want within your abilities and resources. Basically it is simply this. Different visions for the direction of the project and the pursuit of those directions for an extended period of time. This email is an simplification of a lot discussions and debates over a period of years which finally lead to a fork of Squeak. Hope this helps. Jimmie Houchin

May 15, 2020

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

by Eliot Miranda

Hi Shaping, _,,,^..^,,,_ (phone) > On May 15, 2020, at 2:18 AM, Shaping <shaping(a)uurda.org> wrote: > > ï»¿ > 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> 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. Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? Where is VisualWorks significantly faster than either Squeak or Pharo? Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? > 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

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