- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Squeak and Pharo why the fork

by Stephen Davies

Hi, It's worth mentioning Cuis which has a radical commitment to simplification - at the expense of power I suspect but more understandable for a begginer, I find. On Sat, 16 May 2020, 10:57 Shaping, <shaping(a)uurda.org> wrote: > Hi Jimmie. > > > > 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. > > > > 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. > > Applied basic research is most of what I do. I still want a clean, > modular environment. I donât see how that interferes with creative verve. > It should help if only by limiting confusion and clarifying configurational > choices. > > 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. > > What are the specific changes that Squeak folks donât want to make? > > Squeak/Pharo is a configurable environment. We can still have a quasi-OS > world if we want that. What specific aspects of the analytic and creative > experience break or degrade for Squeak users with these specific changes, > and also cannot be preserved by loading the right Smalltalk packages? > > 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. > > This points to needing more modularity, not less. We want to unload all > that we donât want, in small or big pieces, easily and confidently, without > breaking anything. It sounds easy, but itâs not. I think this should be > one of the Consortiumâs main goals. > > 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. > > Image minimization is a useful feature. A Squeak user would want this > too, at least when deploying. > > 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. > > Logical and utilitarian. > > 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. > > What are the specific problems? Anyone? > > 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. > > > > Shaping > > > > > > > > >

May 16, 2020

[Pharo 9.0] Build #298: toolsMenu

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

There is a new Pharo build available! The status of the build #298 was: FAILURE. The Pull Request #6345 was integrated: "toolsMenu" Pull request url: https://github.com/pharo-project/pharo/pull/6345 Issue Url: https://github.com/pharo-project/pharo/issues/toolsMenu Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 16, 2020

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

by Shaping

I forgot to mention that Pharo Zinc with all those primitives produces an HTTP data transfer rate (CSV data) twice as fast as VWâs HTTP client. I tested it many times. Pharo HTTP (Zinc) is consistently 2x faster than VW HTTP. This is probably more about the judicious use of primitives than the execution engine, JIT, or MM. This is another good reason to do a port. Also, Pharoâs WebSocket implementation works very well, and is a standalone Smalltalk client. No such thing exists in VW. Itâs all JS, which has been a source of frustration, and is another good reason to port. Shaping Hi Eliot. Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and thatâs still too long. I canât track the latency in VW 8.3.2. Itâs too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. Itâs very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharos repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isnât as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I donât, but I find subject interesting, and would like to pursue it. Iâm trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). Itâs not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Shaping

May 16, 2020

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

by Shaping

Hi Eliot. Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? 1. Double-click text selection in both Squeak and Pharo shows a 75-100 ms latency (eye-balled, estimated) between end of double click (button up on second click) and time of highlighting of selected text. It could be as low as 60 ms, but I doubt it, and thatâs still too long. I canât track the latency in VW 8.3.2. Itâs too short, probably 30 ms or less, and is under my noise floor. Notepad latencies are even lower. The difference between VW and Notepad is not enough to complain about. Neither is noticeable in passing. The difference between VW and Pharo/Squeak latencies is a little painful/distracting. Itâs very much in your face, and you are keenly aware that you are waiting for something to happen before you can resume your thoughts about the code. 2. Stepping in the Pharo debugger is slow (Squeak is fine). The latencies between the step-click event and selection of the next evaluable is a solid 100 ms (again estimated). Feels more like 150-175 ms much of the time. This is actually hard to work with. Where is VisualWorks significantly faster than either Squeak or Pharo? VW 8.3.2 faster: 1. Text selection. 2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses). Pharos repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isnât as smooth as it could be (because text/cursor rendering is a not efficient?). This is a minor issue, not a practical problem. I did the test in a workspace in both cases. Pharo 9 same or faster: Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster. Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time. If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times. This action is never faster in VW. Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2. Instant--delightful. Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? No, I donât, but I find subject interesting, and would like to pursue it. Iâm trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak). Itâs not a good time for excursions, but here I am playing with Squeak/Pharo, anyway. I want to dig deeper at some future date. Do you have a specific procedure you like to use when benchmarking the VW VM? Shaping

May 16, 2020

Squeak and Pharo why the fork

by Shaping

Hi Jimmie. 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. 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. Applied basic research is most of what I do. I still want a clean, modular environment. I donât see how that interferes with creative verve. It should help if only by limiting confusion and clarifying configurational choices. 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. What are the specific changes that Squeak folks donât want to make? Squeak/Pharo is a configurable environment. We can still have a quasi-OS world if we want that. What specific aspects of the analytic and creative experience break or degrade for Squeak users with these specific changes, and also cannot be preserved by loading the right Smalltalk packages? 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. This points to needing more modularity, not less. We want to unload all that we donât want, in small or big pieces, easily and confidently, without breaking anything. It sounds easy, but itâs not. I think this should be one of the Consortiumâs main goals. 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. Image minimization is a useful feature. A Squeak user would want this too, at least when deploying. 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. Logical and utilitarian. 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. What are the specific problems? Anyone? 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. Shaping

May 16, 2020

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

by Shaping

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? In very general terms, the fork was due to their being Group A wanting to go one direction and Group B wanting to go in a different direction. i.e.... B says "We want to do X". A says "We don't want to do X." B says "We really want to do X." A says "Definitely no." B says "We really want to do X and actually we're doing it over here." Lol Thanks for the explanation. Thatâs more or less what I thought. But canât the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower? In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. I like disentangling and modularizing. I suppose this is a universal like. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, I like this too. whereas Squeak continues to use a "continuous evolution" model. Donât both groups want the automatic building and testing the Consortium is talking about recently? Iâm not sure I understand how âcontinuous evolutionâ works. Sounds like there is lots of wiggle room in that idea. Donât we need some structure? We seem to be getting that in Pharo. Iâm not sure about Squeak. The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later. I used it between 2002 to 2004, and then again just a few days ago. I like the faster debugger and the flat GUIs, but I donât need Morphic to have those dev-tool GUIs. Iâd prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice). The rest of Squeak seems messy. I do very much like the technical, concrete feel of Squeakâs details about the VM. That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization. Those VM details need a somewhat different shape/presentation. There is a beauty in Squeak, but the eviron still feels a bit rough. For example, why arenât all those preferences in a tree where you can actually find things because they are categorized. Itâs a big list. That seems very strange in 2020. Why donât Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like? I thought more would have happened in the Squeak GUI in 16 years, but Iâve not seen all of 5.3 yet. Iâm still poking around. I suppose most of the improvements are in the VM, which I imagine absorbs most of the groupâs energy. And there are more reasons I probably not aware of. Here is the Pharo Vision document circa 2012 which inspired me https://hal.inria.fr/hal-01879346/document Thank you. I will read it. Is the Consortium updating that doc? There was a doc recently from Stef that looks like it belongs in there, merged somehow. It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. Agreed. I donât understand the pushback because I donât understand Squeak folksâ objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks. They are probably fine with all that. Do Squeak folks have a document that defines âcontinuous development.â I know that VM testing is automated. I donât see how the objectives are so different, at least on the automation front. Everyone seems to agree that CI is good. 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? I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. I never liked the halo thing. Itâs okay. It seemed/seems too busy and distracting. I think Morphic and the âtoo many cooksâ problem is why I broke off in 2004. If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk. Have all your GUIs built with Morphic. Have cute little morphs stuck here and there. Knock yourself out. Donât like Morphic? Donât think itâs cute? Load the more business-like-but-not-boring Spec2. I donât see an insurmountable technical problem here. This is one of the reasons that Spec was created - to be independence layer. IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak. Iâve mentioned this a few times recentlyâof all the goofy things to prevent a port from VWâ¦..Okay, that and Pharoâs slow debugger. Two things keep me out of Pharo/Squeak. I donât love VW. I tolerate it really well. Thatâs different. :) wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening is controlled from the Image via FFI rather than the VM. I agree with the objective. This conflicts with Squeak's backward comparability goals. Okay, this is the real problem. So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence. Perhaps someone can give more details on that old code. I suppose many Squeak folks bemoan all the extra work needed for a recoding. Is this still really an issue? Maybe very little of that old code is still being used in business-critical ways. The need for a recoding may not be the big issue it once was. 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. I personally had the inspiration that Squeak might be based off the Pharo Headless Bootstrap, but in the end I didn't find the time to push this further. Thatâs a very good idea. Why donât all the Squeak folks work on it? Are you the only one pushing for this? 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? Pharo currently can use both Morphic and GTK3 for its GUI backend. Possibly the GTK3 backend would provide some speed benefit (??) Itâs a good question. Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently? Thereâs a lot of that in Morphic. I suppose itâs the main concern. Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI. Shaping

May 16, 2020

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

by Eliot Miranda

Hi Ben, > On May 15, 2020, at 10:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > > ï»¿ >> On Fri, 15 May 2020 at 14:09, Shaping <shaping(a)uurda.org> wrote: > >> 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? >> > > In very general terms, the fork was due to their being Group A wanting to go one direction > and Group B wanting to go in a different direction. i.e.... > B says "We want to do X". > A says "We don't want to do X." > B says "We really want to do X." > A says "Definitely no." > B says "We really want to do X and actually we're doing it over here." > > In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, whereas Squeak continues to use a "continuous evolution" model. And there are more reasons I probably not aware of. > Here is the Pharo Vision document circa 2012 which inspired me https://hal.inria.fr/hal-01879346/document > > >> It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. >> > > Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. > > >> 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? >> > > I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. > This is one of the reasons that Spec was created - to be independence layer. > IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. > > wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening > is controlled from the Image via FFI rather than the VM. This conflicts with Squeak's backward comparability goals. The VM comprises an execution engine, a memory manager (which share an object representation), and an assorted collection of plugins and platform support. The execution engine and memory manager are the core support for Smalltalk language execution and are shared 100% between Squeak and Pharo. And I have rearchitected this core, adding a JIT and a much improved object representation and memory manager. Pharo has made *no change* to this core. The assorted collection of plugins and platform support are a kit of parts which can be assembled in a variety of configurations, just as a Smalltalk image can be configured in radically different ways to develop and deploy different applications. It is therefore not true that there is a conflict in backward compatibility. The core VM is only backward compatible at a source level. Backward compatibility in the platform is no more than a configuration in the kit of parts. And the existence of the minheadless minimal core platform support alongside the transitional head Gul platform proves that there need be no conflict. The Pharo community makes great claims about how different its VM is when in fact the new work that has given us much improved performance and scalability is shared 109% between the two. >> 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. >> > > I personally had the inspiration that Squeak might be based off the Pharo Headless Bootstrap, > but in the end I didn't find the time to push this further. > > >> 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? >> > > Pharo currently can use both Morphic and GTK3 for its GUI backend. > Possibly the GTK3 backend would provide some speed benefit (??) > > cheers -ben >

May 16, 2020

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

by Shaping

> 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? The VM changes *are* in the VM code. If pharo haven't bothered to take advantage of them, that's their job to do. There are also image changes involved. Again, somebody has to do the work. > 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? Unlikely and unlikely. > > Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. Really? I can't detect any difference. And that's with the Squeak running on a Pi and VW on a big iMac. Yeah, itâs bad, and I often wonder why no one says anything about it. It definitely slows my work, and Iâm not talking about the extra time for rendering. Itâs mentally disruptive. It mostly depends on how you detect a double-click as opposed to a single, or a mouse-down-drag etc. I go by the definition of a double click: the button-up event of the second click ends the double-click event. Searching for and rendering of the selected text then begins. This takes roughly 75 to 100 ms consistently in Pharo and Squeak. > (Dolphin and VW have quick GUIs). Never used Dolphin but I disagree about the (currnet)VW GUI; I'm using both for work right now and Squeak (again, on a Pi vs the VW/iMac) seems much faster to me. Note that I was specific about the current porting problem as it relates to GUI deficiencies. The problem is not about general GUI speed (like opening and closing windows), which is okay to good in VW, and better overall in Pharo, especially in a Spec2 component (the Launcher). This problem is about text selection speed. Iâm running Windows 10 Pro on an 2.7 GHz Xeon with 96 GB. I just tried text selection again in Pharo 9 in a Playground and in VW 8.3.2âs Transcript. VW is much faster. This is stopping my port--that and the debuggerâs slowness (even slower than the text selection). The porting problem for me reduces to two little, but extremely important GUI dynamics I experience frequently when coding. > Is speeding up the Pharo debugger with Spec2 a priority? I canât think of a better GUI-related priority for Pharo. Why ask that here? (I thought I was posting to the Pharo lists too; corrected above.) Font importer. It's right there in the Apps list, second row. Yes, I found it. > > - 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. As a general UI point, leading edge action is rarely a good thing. I use leading edge single clicks all the time for most of the last 25 years of Smalltalk coding. The choice is for me as dev, not for clients. The issue is once again about high-speed continuity of gesture and thought during coding. Eliminating the delay matters. Iâve had time to try it both ways. Shaping

May 16, 2020

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

by Ben Coman

On Fri, 15 May 2020 at 14:09, Shaping <shaping(a)uurda.org> wrote: > 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?* > In very general terms, the fork was due to their being Group A wanting to go one direction and Group B wanting to go in a different direction. i.e.... B says "We want to do X". A says "We don't want to do X." B says "We really want to do X." A says "Definitely no." B says "We really want to do X and actually we're doing it over here." In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, whereas Squeak continues to use a "continuous evolution" model. And there are more reasons I probably not aware of. Here is the Pharo Vision document circa 2012 which inspired me https://hal.inria.fr/hal-01879346/document It looks like a bad use of energy in a community that is small and needs to > use its human resources efficiently. > Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. 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?* > I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. This is one of the reasons that Spec was created - to be independence layer. IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening is controlled from the Image via FFI rather than the VM. This conflicts with Squeak's backward comparability goals. 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. > I personally had the inspiration that Squeak might be based off the Pharo Headless Bootstrap, but in the end I didn't find the time to push this further. 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? > Pharo currently can use both Morphic and GTK3 for its GUI backend. Possibly the GTK3 backend would provide some speed benefit (??) cheers -ben

May 15, 2020

Re: [Pharo-dev] Squeak and Pharo why the fork - was: Squeak and Pharo speed differences

by CÃ©drick BÃ©ler

Nicely said ð > Le 15 mai 2020 Ã 17:39, Jimmie Houchin <jlhouchin(a)gmail.com> a Ã©crit : > > ï»¿ >> 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