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

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

by Shaping

Hi Shaping, Hey Ronie. About the latency, it may be because of the default idle time. Try running the following: ProcessorScheduler idleTime: 1000 I did the eval in Pharo 9, and the selection is still sluggish. I added some zeros and also tried 1. The different values donât seem to make any difference. By the release of Pharo 7 the idle time was increased to 50 ms in order to reduce the CPU usage on the cloud and reduce costs. Ok. If I remember correctly Ben Coman did a PR that changes the way the delays are scheduled in order to select the most appropriate time for sleeping, but since the PR was to close to a Pharo release, it was decided to not be included for safeness reasons. We should resurrect that change soon because the default latency is really bad. If the sleeping is happening and the associated delay above is also happening when sleeping/idle-time happens, then shouldnât we see variations in latency with changes in the number above? I must not be understanding something. When you click or double-click on a spot in a text editor on a word, these basic things happen: 1. A mouse event containing the pixel location clicked is emitted. 2. The event handler looks up which bounding rectangle or which line and character range for an given font contains the word to be highlighted. Ultimately you get a bounding rectangle. 3. The event handler renders the new colored background and then renders the text again on top of the new background, probably on a bitmap/DIB section (flicker-free double buffering). Then the finished bitmap is blitted to the device context, and we see the result. Where do you think the slowness is? My bet is (2); then maybe (1). Are you saying (1) is the problem? Iâm thinking (3) is always fast. But I could wrong about that. Iâve not looked at any code. Someone must know. Shaping El dom., 17 may. 2020 a las 7:03, Robert (<robert.withers(a)pm.me <mailto:robert.withers@pm.me> >) escribiÃ³: Hi Shaping, I can't comment on parallelizing the VM. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model. On 5/16/20 11:29 PM, Shaping wrote: Hi Shaping, Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) On 5/16/20 8:47 AM, Shaping wrote: Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. Who oversees stuff like this? Specifically, why donât we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimatelyâa nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time. Why wasnât this done when Tonel was first created? The Pharo dev probably didnât see it as good use of dev time. I kindly suggest that this attitude change for all contributors to both Smalltalks. How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things? I couldn't get distracted from my core work. Sure, I feel the same. I imaging that most of us do. NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, In my Pharo 9 I have a bit these bits: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load In Squeak I can now ensureRecentMetacello, which I was not able to before. Installer ensureRecentMetacello. Metacello new baseline: 'MagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'; load However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring ...FAILED->BaselineOfMagicMouse I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus: spec name: 'BaselineOfMagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'. At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak. Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo. Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; project: 'Cryptography'; install: 'ProCryptoTests-1-1-1'; project: 'Cryptography'; install: 'CapabilitiesLocal'; project: 'Oceanside'; install: 'ston-config-map'; project: 'Cryptography'; install: 'SSLLoader; project: 'Cryptography'; install: 'Raven'. Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo... If there is genuine respect for the value of Squeak and Pharo on both sides Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that.. K, r -- Kindly, Robert

May 17, 2020

Pharo 7.0.5

by Sven Van Caekenberghe

Hi, Is there any intention of officially releasing Pharo 7.0.5 ? There are 18 commits after 7.0.4 https://github.com/pharo-project/pharo/compare/v7.0.4...Pharo7.0 I need the following https://github.com/pharo-project/pharo/pull/5079 which is one of the 18 commits Zinc HTTP Components is currently partially broken on Pharo 9 because #digitAt: was replaced by #byteAt: and #digitAt: is now removed. In order to fix this I could start using #byteAt: as far back as 7.0.5 and add it myself for even older Pharo versions using my Zinc-Pharo-Forward-Compatibility package. What has to happen to make it possible to release 7.0.5 ? More testing ? Where is the artefact to test ? Thx, Sven

May 17, 2020

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

by Shaping

Hi Shaping, I can't comment on parallelizing the VM. Thatâs mostly what the thread is for, ultimately. The refcaps are needed by the concurrent collector. Some interesting memory-management options are surfacing soon with Verona. That scheme is supposed to eliminate the cost of tracing refs to mutable objects in many small heaps. This is the main cost of having all the small heaps with Orca protocol. Verona should fix this. I need to look into it further before discussing the details. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model. Sorry for the delay. Iâve not read the e-mail yet. Iâll be a bit longer. Thanks for the patience. Shaping On 5/16/20 11:29 PM, Shaping wrote: Hi Shaping, Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) On 5/16/20 8:47 AM, Shaping wrote: Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. Who oversees stuff like this? Specifically, why donât we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimatelyâa nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time. Why wasnât this done when Tonel was first created? The Pharo dev probably didnât see it as good use of dev time. I kindly suggest that this attitude change for all contributors to both Smalltalks. How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things? I couldn't get distracted from my core work. Sure, I feel the same. I imaging that most of us do. NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, In my Pharo 9 I have a bit these bits: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load In Squeak I can now ensureRecentMetacello, which I was not able to before. Installer ensureRecentMetacello. Metacello new baseline: 'MagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'; load However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring ...FAILED->BaselineOfMagicMouse I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus: spec name: 'BaselineOfMagicMouse'; repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'. At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak. Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo. Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; project: 'Cryptography'; install: 'ProCryptoTests-1-1-1'; project: 'Cryptography'; install: 'CapabilitiesLocal'; project: 'Oceanside'; install: 'ston-config-map'; project: 'Cryptography'; install: 'SSLLoader; project: 'Cryptography'; install: 'Raven'. Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo... If there is genuine respect for the value of Squeak and Pharo on both sides Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that.. K, r -- Kindly, Robert

May 17, 2020

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

by Shaping

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eric Gade Sent: Saturday, 16 May, 2020 10:49 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Squeak and Pharo why the fork On Sat, May 16, 2020 at 11:19 AM Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > wrote: But lets also consider something at least as important as all the other points... "resourcing". Assuming all technical and political issues were dealt with, who will do this reintegration work? Assuming You were at a point where you were familiar with both platforms to be capable of doing the work, would You be willing to put aside your other interests to do at least 50% of that work? I know Pharo has the consortium, which funds some of the work that goes on. I also know that Squeak has a foundation, but that it barely keeps the servers running. Even if there were just one open source Smalltalk out there, resources are limited. VM developers, especially, need to be compensated somehow. I have often wondered why there is not some Patreon like option for the developers of the Opensmalltalk-vm or similar unity efforts. I would gladly part with $20/mo or whatever to ensure that development happens in a coherent and agreeable way. In short, I don't think this is just about "people doing the work." Most smalltalkers can't do the VM work, for example. It requires a lot of knowledge and experience. People have day jobs, and that saps not only their time, but their mental capacity to program. I'm thinking small amounts of money from members of the community would go further in enhancing the big parts of these systems than minor, scattered programming contributions. But that's just my $0.02. This does sound more realistic and more sustainable. Shaping

May 17, 2020

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

by Shaping

On Sat, 16 May 2020 at 16:57, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: 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? 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? I'm mainly focused on Pharo but I respect the Squeak heritage and monitor their mail list, chipping in when I can - so I have felt comfortable sharing the general philosophical differences between Squeak and Pharo as I understand them. But as to specifics, you'd probably need someone from Squeak to pair-review the Pharo changelogs [1] with you - and that might not even capture everything. [1] https://github.com/pharo-project/pharo-changelogs But lets also consider something at least as important as all the other points... "resourcing". Assuming all technical and political issues were dealt with, who will do this reintegration work? The work should be distributed amongst those who know the frameworks best, like them and need to use them, and who want one image and the ease it bringsâwhich should be a bunch of people. Or, Iâd have to work with those folks to get up to speed on those frameworks to learn whatâs different, whatâs broken, what can change, what canât change, etc. Doing it all myself even with plenty of consulting seems less efficient. Selfish drivers are important. Community/collective drivers are also important. Balance. Donât leave out the first, or nothing will happen. Assuming You were at a point where you were familiar with both platforms to be capable of doing the work, would You be willing to put aside your other interests to do at least 50% of that work? Probably not for the next year, because of whatâs currently in my queue. Because otherwise discussion around it with the idea that others do it is pointless. :) I see several devs doing the work. One dev probably canât do it. At least one dev should be watching the big picture and presenting results/problems/decision-points. The big picture may not be as big as Iâm thinking. It could be bigger too. I need details. I have one firm detail now: 1. Squeak folks need Tonel. Ergo, port the latest Tonel to the latest Squeak. And two fuzzy details: 1. We need testable criteria to determine how indispensable/always-in-the-image/nonmodular a framework shall be. Itâs an interesting topic. I donât know how itâs currently handled. Development seems organic and wild-west in both camps: if you can get it done on your own time and it provides utility, it can probably get into the main trunk somehow. Is that how it works? 2. Metacello sucks a little for brevity, and Monticello seems to offer some nicer features. And so what do we do here? Fix the Monticello/Metacello frameworks on both sides, or move all to Git? Whatâs wrong with Metacello? Is it too verbose? Can an SME/heavy user defend it and compare it to Monitcello? I want to know what is most valuable about Squeak, and I mean specific features and tools. We can turn either Pharo or Squeak into a world-like Quasi-OS. Thatâs not an argument for greater technical value. It just a mode of use. I can tell you want I like about Squeak (please Squeak folks, add to this), but Iâm almost Squeak-green again after 16 years absence: 1. Flat quick GUIs for development. I just like snap. What can I say. It helps me focus. Iâve sensitive to what I consider to be temporal defects (annoying little pauses). That doesnât mean I like Morphic. I like what I can see and touch, and I like the speed. 2. Debugger is normal (quick). 3. The VM params and stats. I want to work on the VM. I want to do that with nice-looking, quick tools. I thought Pharo would be the best for that. But Squeak seems to be the main tool for VM dev. Note, last year I personally did have the inspiration and intention of investigating the differences between Squeak and the Pharo Bootstrap to understand the possibility of Squeak bootstrapping off the Pharo Bootstrap, so there might one day they might have a common non-gui system - but other interests ended up having a stronger hold on me. Realistically its not something I'll get to any time soon. I too find the common bootstrapping interesting. My personal priority is efficient, thorough parallelization of the VM. I need huge compute-scale, and it has to happen in a dynamic language, the best one. Thatâs going to keep me busy for a while, and I canât even start that for some time (months). Shaping

May 17, 2020

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

by Ronie Salgado

Hi Shaping, About the latency, it may be because of the default idle time. Try running the following: ProcessorScheduler idleTime: 1000 > By the release of Pharo 7 the idle time was increased to 50 ms in order to reduce the CPU usage on the cloud and reduce costs. If I remember correctly Ben Coman did a PR that changes the way the delays are scheduled in order to select the most appropriate time for sleeping, but since the PR was to close to a Pharo release, it was decided to not be included for safeness reasons. We should resurrect that change soon because the default latency is really bad. Best regards, Ronie El dom., 17 may. 2020 a las 7:03, Robert (<robert.withers(a)pm.me>) escribiÃ³: > > > Hi Shaping, I can't comment on parallelizing the VM. I was waiting to hear > from you regarding 'CapabilitiesLocal' and its ref-cap state transition > model. > On 5/16/20 11:29 PM, Shaping wrote: > > Hi Shaping, > > Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) > > On 5/16/20 8:47 AM, Shaping wrote: > > Can you tell me about those efforts? I know the VM is one, maybe the > biggest. What else do Squeak folks work on? > > I also understand why the developers of the new Pharo preferences tree > did not like to invest the same effort in Squeak. What incentive would they > have? > > > > Make all features (GUIs/frameworks) loadable into a new, mostly empty > image. > > > > Andso, here we have the biggest challenge to doing such sharing. You say > all features should be loadable into either image. The issue is that Pharo > has driven forwards in creating new load formats, such as Tonel. I tried to > load up the Tonel format, but failed. > > > > Who oversees stuff like this? > > Specifically, why donât we now make Tonel avaibable on Squeak, with the > objective of equalizing access to source code, so that we can use one image > ultimatelyâa nice steady gradual drift toward one image, so that no one is > in too much pain at any one point in time. > > Why wasnât this done when Tonel was first created? The Pharo dev probably > didnât see it as good use of dev time. I kindly suggest that this > attitude change for all contributors to both Smalltalks. > > How long is the list of format-related code/frameworks that need to be > equalized, so that Squeak and Pharo can always load the same things? > > I couldn't get distracted from my core work. > > Sure, I feel the same. I imaging that most of us do. > > NO EFFORTS have been made to have Squeak able to load such formats, and > the Pharo folks have deprecated the existing Montecello load format, > > In my Pharo 9 I have a bit these bits: > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfAida'; > > load. > > (Smalltalk at: #ConfigurationOfAida) load. > > > > Metacello new > > baseline:'Seaside3'; > > repository: 'github://SeasideSt/Seaside:master/repository'; > > load > > In Squeak I can now ensureRecentMetacello, which I was not able to before. > > Installer ensureRecentMetacello. > > Metacello new > baseline: 'MagicMouse'; > repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'; > load > > However, I still choke on the Metacello #baseline:; #repository:. #load. > It prints to the Transcript > > gofer repository error: 'GoferRepositoryError: > UndefinedObject>>isAlphaNumeric'...ignoring > ...FAILED->BaselineOfMagicMouse > > I get a debugger on > MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: > packageSpec gofer: gofer > > The Gofer is pointing to a > MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as > its only repo. The packageSpec is thus: > > spec > name: 'BaselineOfMagicMouse'; > repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'. > > At one time I had found what caused the #isAlphaNumeric error (I think an > empty stream). The point is that I cannot load with Metacello in Squeak. > > Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL > and Raven. This works in Squeak but not in Pharo. > > Installer ss > project: 'Cryptography'; install: 'ProCrypto-1-1-1'; > project: 'Cryptography'; install: 'ProCryptoTests-1-1-1'; > project: 'Cryptography'; install: 'CapabilitiesLocal'; > project: 'Oceanside'; install: 'ston-config-map'; > project: 'Cryptography'; install: 'SSLLoader; > project: 'Cryptography'; install: 'Raven'. > > Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), > thus unloadable in Pharo... > > > > *If there is genuine respect for the value of Squeak and Pharo on both > sides * > > Good question! We shall see. The feeling to me is a couple of stiff french > fingers being sent Squeak's way. There is probably a french word for that.. > > K, r > -- > > Kindly, > Robert > >

May 17, 2020

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

by Shaping

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. Agreed. It was that loss of power that drove me back to Pharo. Cuis did not seem faster in any way, either, and I was expecting that for all the simplifications and Spartan approach. The main appeal is simplified code/framework study. Shaping On Sat, 16 May 2020, 10:57 Shaping, <shaping(a)uurda.org <mailto:shaping@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 17, 2020

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

by Shaping

Hi Shaping, Hi Robert. (Weâll get back to the parallelizing any day nowâ¦) On 5/16/20 8:47 AM, Shaping wrote: Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. Who oversees stuff like this? Specifically, why donât we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimatelyâa nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time. Why wasnât this done when Tonel was first created? The Pharo dev probably didnât see it as good use of dev time. I kindly suggest that this attitude change for all contributors to both Smalltalks. How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things? I couldn't get distracted from my core work. Sure, I feel the same. I imaging that most of us do. NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, In my Pharo 9 I have a bit these bits: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load So does this that mean Pharo strictly uses only Metacello and Git for version control now? from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. Yeah, thatâs not healthy for the community. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. Agreed. Thanks for plainly saying so. We need more of that. That is step number one to having features co-loadable, common load systems. Agreed. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :( It is very sad. Letâs fix it. Donât the Consortium have an interest in such things? Are the Consortium so Pharo-centric that they view Squeak as a useless blob of programming IP? I donât think so. If there is genuine respect for the value of Squeak and Pharo on both sides, allowing their continued divergence and the many attendant frustrations to mount is negligent and wasteful. Can we stop doing that? Iâm under the impression that Pharo folks want ultimately to use only Git, and that even the Metacello will be phased out. Is that correct? What is the version-control plan on Pharo, and can we implement the same planâwhatever that is--for Squeak too? Shaping

May 17, 2020

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

by John Brant

And they chose one that wasnât too optimized. There are much better versions of factorial already implemented in Smalltalk: https://medium.com/concerning-pharo/speeding-up-factorial-computation-by-ch… http://forum.world.st/Challenge-Tuning-the-large-factorial-td3588660.html Both of these pages have optimizations that eliminate 80% or more of the running time where the optimized version below only eliminates ~25% of the slow factorialâs running time. On my machine, running the factorial for 200,000 takes ~20 seconds using the old/slow algorithm (once I fixed it to be recursive on itself and not the modified factorial method), and the new factorial method takes ~15 seconds. Using the #productTo: method above, takes ~4 seconds, and using my revised version on the other page above takes ~3.5 seconds. My personal preference for a factorial included with Pharo would be the #productTo: method above. It is simple to understand and is reasonably fast. John Brant > On May 16, 2020, at 11:17 AM, Bernhard HÃ¶fner <bernhard.hoefner(a)gmx.de> wrote: > > It seems that someone needed an optimized factorial-routineâ¦ > The problem on the other hand is, that the machine friendly code is much less âdidactical" than the human friendly common implementation. To have both I propose to add the human friendly clear and short version as comment. Its a bit like some primitive methods were after the primitive call there is the smalltalk version as well (VisualWorks). > > Regards, Bernhard HÃ¶fner > >> ... >> 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 >> >> ...

May 16, 2020

Re: [Pharo-dev] splitWithin: ?

by Carlo

Similar to current String>>#findTokens: ? '| a b | c d |' findTokens: '|'. >> an OrderedCollection(' a b ' ' c d ') '| a b | c d |||' findTokens: '|'. >> an OrderedCollection(' a b ' ' c d ') On 16 May 2020, at 20:04, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: Hi We have splitOn: '| a b | c d |' splitOn: â|' >> an OrderedCollection('' ' a b ' ' c d ' â') And I think that it would be nice to have '| a b | c d |' splitWithin: â|' >> an OrderedCollection(' a b ' ' c d ' ) Do you have idea? S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

May 16, 2020