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@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