- Pharo-dev - lists.pharo.org

A/B Testing the latest VM on the Pharo repository PRs

by Guillermo Polito

Hi all, TL;DR; I propose we start testing the latest VMs on PRs to the Pharo repository in a "semi-randomâ way. The idea is to earn some confidence while having a small impact on all of you. ==== We need to slowly start pushing the latest VM version, right now hosted in the pharoX branch of the VM repository. This branch so far has all our latest work on the VM for at least one year. Some highlights Interpreter variable auto-localization (Feat/automatic localizationÂ pharo-vm#371 <https://github.com/pharo-project/pharo-vm/pull/371>) Slang cleanups and improvements (Clean slang warningsÂ pharo-vm#413 <https://github.com/pharo-project/pharo-vm/pull/413>, Fix while statement printingÂ pharo-vm#265 <https://github.com/pharo-project/pharo-vm/pull/265>, CastÂ pharo-vm#230 <https://github.com/pharo-project/pharo-vm/pull/230>, Clean slang warningsÂ pharo-vm#413 <https://github.com/pharo-project/pharo-vm/pull/413>, Switch translation to CAST, and testsÂ pharo-vm#311 <https://github.com/pharo-project/pharo-vm/pull/311>, Add several CAST translations and testsÂ pharo-vm#307 <https://github.com/pharo-project/pharo-vm/pull/307>, Fix type inference testsÂ pharo-vm#291 <https://github.com/pharo-project/pharo-vm/pull/291>) SIMD support in the JIT (Speed up object initialization in AArch64 using SIMD instructionsÂ pharo-vm#421 <https://github.com/pharo-project/pharo-vm/pull/421>, SIMD bytecodesÂ pharo-vm#444 <https://github.com/pharo-project/pharo-vm/pull/444>) Initial work on the perm space (Composed image formatÂ pharo-vm#377 <https://github.com/pharo-project/pharo-vm/pull/377>, Composed image format: C translationÂ pharo-vm#388 <https://github.com/pharo-project/pharo-vm/pull/388>, Refactoring of Snapshot and Loading of ImagesÂ pharo-vm#372 <https://github.com/pharo-project/pharo-vm/pull/372>, Perm space on imageÂ pharo-vm#416 <https://github.com/pharo-project/pharo-vm/pull/416>, New & old remembered setsÂ pharo-vm#418 <https://github.com/pharo-project/pharo-vm/pull/418>) Many many bugfixes â¦ To not disrupt anybodyâs work, I propose to make some kind of AB testing on the CI, only impacting PRs to the Pharo repository. odd builds (1,3,5,â¦) use the latest VM even builds (2,4,6,â¦) use the stable VM This will make sure that: the latest VM will be tested in a complex scenario (load code, run testsâ¦) people that have a problem can re-run their builds to get a stable run Iâve made the following PR that follows this idea https://github.com/pharo-project/pharo/pull/11678 G

Sept. 14, 2022

This week (36/2022) on the Pharo Issue Tracker

by Marcus Denker

We merged 24 PRs last week. Features ======== [improvement] add microsecond to API #11493 https://github.com/pharo-project/pharo/pull/11493 - adding entries in the debug world menu to enable / disable all breakpoints in the image #11614 https://github.com/pharo-project/pharo/pull/11614 - Adding an API in OCBytecodeToASTCache, RBMethodNode and RBBlockNode to map AST nodes to a pc range. #11651 https://github.com/pharo-project/pharo/pull/11651 Speed ===== - 11597-RPackagetoTagName-possibly-creates-an-extra-symbol #11604 https://github.com/pharo-project/pharo/pull/11604 Git/Iceberg =========== - Treat trait class side definitions like class class side definitions too #1609 https://github.com/pharo-vcs/iceberg/pull/1609 - Fix/1426: ZnInvalidUTF8 when reading a commit message #1611 https://github.com/pharo-vcs/iceberg/pull/1611 - When the remote server cuts the connection or there is an issue in thâ¦ #1613 https://github.com/pharo-vcs/iceberg/pull/1613 - Only compute critiques when needed #1610 https://github.com/pharo-vcs/iceberg/pull/1610 Fixes ===== - 11635-Compiler-eval-an-expression-with-halt-and-bindings-opens-Emergency-Evaluator #11637 https://github.com/pharo-project/pharo/pull/11637 - Attempt to fix scrolling behavior in RubAbstractTextArea & friends #11583 https://github.com/pharo-project/pharo/pull/11583 - Fix leaking subscriptions in SpRubFindReplaceService #11608 https://github.com/pharo-project/pharo/pull/11608 - Make explicit hostname and port work with bitbucket #11585 https://github.com/pharo-project/pharo/pull/11585 - Fix behavior of sum: on collections of doubles #11600 https://github.com/pharo-project/pharo/pull/11600 - FTTableMorph: Allow expansion/collapse of nodes using arrow keys #11644 https://github.com/pharo-project/pharo/pull/11644 - [Quick review] fix #11265: Underscore in class name breaks text completion #11487 https://github.com/pharo-project/pharo/pull/11487 - FTTableMorph: Pass some keyboard events to the filter field if it is focused #11647 https://github.com/pharo-project/pharo/pull/11647 Cleanup ======= - RubAbstractTextArea: Avoid a superfluous isNotNil in handleEdit: #11645 https://github.com/pharo-project/pharo/pull/11645 - Cleanups necessary in FreeType #11636 https://github.com/pharo-project/pharo/pull/11636 - 11558-leadingChar-is-provided-but-unused #11654 https://github.com/pharo-project/pharo/pull/11654 Comments ========= - Expand class comment for Set #11642 https://github.com/pharo-project/pharo/pull/11642 - Update vm links with the new pharo-vm repo #11652 https://github.com/pharo-project/pharo/pull/11652 - 11612-RBComment-class-comment #11653 https://github.com/pharo-project/pharo/pull/11653 Pharo 10 ======== - backportPharo10-11635-Compiler-eval-an-expression #11638 https://github.com/pharo-project/pharo/pull/11638 Pharo 9 ======== - Use iceberg 2.0.5.1 #11596 https://github.com/pharo-project/pharo/pull/11596

Sept. 12, 2022

Re: Equality/Hash Modification and Image Rehashing

by sean＠clipperadams.com

Daniel Slomovits wrote: > A user working on their own application and modifying a #=/#hash implementation there has a very straightforward way to resolve the problemâ"reboot" their own application, tearing down and rebuilding any structures it uses. For a developer in the common usage, as distinct from a user, I suspect you may be right that itâs not too much of an issue. However, Smalltalk tends to erase that distinction and there seems to be a solid community who are both user and developer and âdo brain surgery on themselvesâ regularly. I am such a user and got surprised and a little damaged by this gotcha. > The thing is that the `Set/Dictionary allSubInstances do: #rehash` approach > is extremely heavy-handed. I agree. That would be one way to mitigate. Iâm interested in others e.g. a code critic or warning in the browser like some refactoring have.

Sept. 7, 2022

Smalltalks Workshop 2022: call for papers!

by Mariano Martinez Peck

Greetings everyone, This year, in addition to traditional technical talks, FAST has organized a Workshop [1] where researchers are invited to submit papers, which will be evaluated by specialized reviewers. We have chosen the Workshop format to let authors get early qualified feedback of their work without preventing them from presenting in other conferences or publications, since this format does not imply exclusive submission. [1] https://smalltalks2022.fast.org.ar/registration/call-for-papers Greetings, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Sept. 5, 2022

This week (35/2022) on the Pharo Issue Tracker

by Marcus Denker

Fixes ===== - Revert "Optimize setting of initial position in PositionableStream>>on:" #11606 https://github.com/pharo-project/pharo/pull/11606 - OSSDL2FormRenderer: Release texture manually to avoid spike in memory usage #11610 https://github.com/pharo-project/pharo/pull/11610 - OSSDL2FormRenderer: Fix DNU on start #11617 https://github.com/pharo-project/pharo/pull/11617 - Fixing Broken Refactoring Test #11619 https://github.com/pharo-project/pharo/pull/11619 - SpRubFindReplaceDialog: Clear selection on close #11602 https://github.com/pharo-project/pharo/pull/11602 Speedup ======= - Improving the speed of the compiler when compiling methods with a lot of literals #11615 https://github.com/pharo-project/pharo/pull/11615 Cleanups ======== - Categorize test classes. No modification #11607 https://github.com/pharo-project/pharo/pull/11607 - Small cleanups in fluid builders #11628 https://github.com/pharo-project/pharo/pull/11628 - FluidBuilder should be abstract #11626 https://github.com/pharo-project/pharo/pull/11626 - Cleanup: remove Point3 class #11624 https://github.com/pharo-project/pharo/pull/11624 - Small cleanups in FluidClassBuilder-Tests package #11632 https://github.com/pharo-project/pharo/pull/11632 - Rename temp variable in RBScanner(class)>>#on: method #11547 https://github.com/pharo-project/pharo/pull/11547

Sept. 2, 2022

Change notification: squeaksource.com migration to new service provider today

by David T. Lewis

As part of an overall project to move squeak.org services to a new service provider (hetzner.com) the https://squeaksource.com server will be migrated today, 31 August, beginning at 20:00 UTC. Due to time required for DNS updates to propagate, the change will take effect over a number of hours (expect up to one day). This is the general purpose squeaksource.com server, and does not affect http://source.squeak.org, which will be migrated separately at a later date. What you need to know: For most people, no change will be noticed. Read access to repositories will continue with little or no interruption. If you are committing updates to existing projects, there is a risk of those updates being committed to the "wrong" server during the transition period. No data or files will be lost, but some updates may need to be re-applied. The squeaksource.com administrator will be watching for this and will either fix any missing updates or request the affected project administrator to do so. If you are a project administrator or if you are planning to create a new project on squeaksource.com, please avoid making changes during the transition period. In the event of problems, please report the concern here on the squeak-dev list. If you do not have access to that list, you can report the concern to lewis(a)mail.msen.com. Dave

Aug. 31, 2022

Re: Equality/Hash Modification and Image Rehashing

by Sven Van Caekenberghe

A use case in the system is #stonPostReferenceResolution for Dictionary and Set. You could have a look at that (it is an edge case, but still). > On 30 Aug 2022, at 19:00, sean(a)clipperadams.com wrote: > > From Pharo Discord: > > IIUC when I change the comparison behavior of a class (i.e. reimplement #= and #hash), sets containing those objects start acting oddly e.g. happily storing duplicates of equal objects and failing to find objects they contain. A solution seems to be Set allSubInstances do: #rehash. > > Is my understanding correct? If so, I find it odd that I've been using and researching Smalltalk for well over a decade and I never remember reading/hearing about this. I wonder if it can be baked into the IDE somehow e.g. via a critic... > > And stephan responded: > > The mailing list posts about that I remember were at the time where the number of object bits used for the hash were increased. > > Following up on his clue, I found this old post, which seems to confirm my suspicion. This seems like a serious trap for users to fall into (Iâm having flashbacks to my C++ days lol). So, can/should we somehow handle this in the IDE? Something like a refactoring (that has a confirmation window) that gives you the choice to rehash image collections when redefining these methods? > > In a 1GB image, `Set allSubInstances do: #rehash` is almost instantaneous and `Dictionary allSubInstances do: #rehash` takes several seconds. >

Aug. 30, 2022

Re: Equality/Hash Modification and Image Rehashing

by Daniel Slomovits

Everything you say is true, but I don't consider it nearly as serious a trap as you say, because I wouldn't generally expect a "user" (that is, a developer not explicitly working on Pharo itself) to modify the #=/#hash implementation of a system class (that is, one included in the base image and instances of which may be expected to exist at all times). A user working on their own application and modifying a #=/#hash implementation there has a very straightforward way to resolve the problemâ"reboot" their own application, tearing down and rebuilding any structures it uses. For the applications I work on this is very easy, because it needs to be in order for tests to set up a clean environment each run. For a developer who *is* explicitly working on Pharo, I think appropriate comments in the #=/#hash implementations of classes critical to the functioning of the image (most obviously the default implementation in [Proto]Object) would be enough (and may already exist). I know in Dolphin Smalltalk there are comments in the #identityHash methods explaining the related point that a binary-filed collection may need to be rehashed on load as its contents will not have the same identities and thus #identityHash-es. Dolphin also changed the number of hash bits similar to what stephan mentioned, and this definitely involved jumping through some hoops to perform safely. More generally, I think this is something anyone with a solid computer science background and/or experience working on language implementations would be expected to pick up by osmosis and/or reasoning from first principles. I don't mean this as an insult to people who just want to write cool apps, but, those are exactly the people who are unlikely to encounter the problem, or if they do, will shrug, restart everything, and the problem will go away. That said, there's certainly nothing wrong with some good comments. The thing is that the `Set/Dictionary allSubInstances do: #rehash` approach is extremely heavy-handed. I suppose it should be largely safe, though to be certain it would need to be done at very high priority to avoid the possibility of concurrent modification (and even then there is a theoretical window of vulnerability). But the cost/benefit analysis feels pretty marginal IMO for making it a part of the IDE. One refinement, if it were to be addedâif there are no instances of the class which is being modified, no rehashing can possibly be needed, and in fact in most cases I would expect this to be true. One could additionally scan Sets for instances of that class before rehashing them, which might not actually be vastly more performant but would reduce the heavy-handedness of the operation. On Tue, Aug 30, 2022 at 1:01 PM <sean(a)clipperadams.com> wrote: > From Pharo Discord: > > IIUC when I change the comparison behavior of a class (i.e. reimplement #= > and #hash), sets containing those objects start acting oddly e.g. happily > storing duplicates of equal objects and failing to find objects they > contain. A solution seems to be Set allSubInstances do: #rehash. > > Is my understanding correct? If so, I find it odd that I've been using and > researching Smalltalk for well over a decade and I never remember > reading/hearing about this. I wonder if it can be baked into the IDE > somehow e.g. via a critic... > > And stephan responded: > > The mailing list posts about that I remember were at the time where the > number of object bits used for the hash were increased. > > ------------------------------ > > Following up on his clue, I found this old post > <https://lists.pharo.org/empathy/thread/LKCE5UXYPXPLVOGNZYW64BWHYJY5NMHQ?has…>, > which seems to confirm my suspicion. This seems like a serious trap for > users to fall into (Iâm having flashbacks to my C++ days lol). So, > can/should we somehow handle this in the IDE? Something like a refactoring > (that has a confirmation window) that gives you the choice to rehash image > collections when redefining these methods? > > In a 1GB image, `Set allSubInstances do: #rehash` is almost instantaneous > and `Dictionary allSubInstances do: #rehash` takes several seconds. >

Aug. 30, 2022

Equality/Hash Modification and Image Rehashing

by sean＠clipperadams.com

>From Pharo Discord: IIUC when I change the comparison behavior of a class (i.e. reimplement #= and #hash), sets containing those objects start acting oddly e.g. happily storing duplicates of equal objects and failing to find objects they contain. A solution seems to be Set allSubInstances do: #rehash. Is my understanding correct? If so, I find it odd that I've been using and researching Smalltalk for well over a decade and I never remember reading/hearing about this. I wonder if it can be baked into the IDE somehow e.g. via a critic... And stephan responded: > The mailing list posts about that I remember were at the time where the number of object bits used for the hash were increased. --- Following up on his clue, I found [this old post](https://lists.pharo.org/empathy/thread/LKCE5UXYPXPLVOGNZYW64BWHYJY5NM… "this old post"), which seems to confirm my suspicion. This seems like a serious trap for users to fall into (Iâm having flashbacks to my C++ days lol). So, can/should we somehow handle this in the IDE? Something like a refactoring (that has a confirmation window) that gives you the choice to rehash image collections when redefining these methods? In a 1GB image, \`Set allSubInstances do: #rehash\` is almost instantaneous and \`Dictionary allSubInstances do: #rehash\` takes several seconds.

Aug. 30, 2022

Re: Platform Packages vs. Git Branches

by Max Leske

On 29 Aug 2022, at 18:25, Dale Henrichs wrote: > Max, > > Yeah, your approach looks manageable ... with a well defined common code > base, both branch per platform (fuel) and platform packages (Grease) can be > used ... > > I looked at your github action code and see that you've got a solution for > triggering multi-branch runs ... workflow per branch/platform ... so I will > HAVE TO CONSIDER the branch per platform approach again :) Yeah, not perfect, but it works (reusability isn't a focus of GitHub workflows...). > > Dale > > On Mon, Aug 29, 2022 at 8:53 AM Max Leske <maxleske(a)gmail.com> wrote: > >> Hi Sean, >> >> At some point you will probably come to the same point that Seaside and >> Fuel have reached in the past: build your own abstraction layer (Grease in >> Seaside, Fuel-Platform in Fuel). There are valid arguments against this >> approach but, personally, I didn't have another choice for Fuel. >> >> Fuel setup: >> >> - A Fuel-Plaform-Core package >> - 1 Fuel-Platform package per dialect and version >> - development branch, old "release" branch, current "release" branch >> for Fuel-Platform >> - 1 Git branch for Fuel per version >> - some magic in the baselines to get Metacello to load what I want >> >> I used to have the same multiple package approach that you mentioned but >> it fell apart when I had too many packages with too many differences. >> >> Cheers, >> Max >> >> On 25 Aug 2022, at 16:16, sean(a)clipperadams.com wrote: >> >> Iâve always supported multiple platforms (e.g. different Pharo versions) >> via packages like MyProject-Plaform-Pharo9. Thinking back, the primary >> reason is that is how I saw it done by other projects. Also, I adopted the >> practice well before git was in wide use in the Pharo world. >> However, Jan Bliznicenko recently suggested an alternate workflow which >> sounds like how Pharo itself is managed: use git branches, with the primary >> branch supporting only latest Pharo, and other branches only getting >> critical bug fixes backported. >> Not sure how that would work for projects that support other dialects e.g. >> Gemstone and Squeak, since there would then be multiple âlatest versionsâ. >> Iâm interested in opinions about these options as I feel that Magritte is >> an important community asses and want to keep it compatible on as many >> platforms as possible (with as little work as possible)! I also get the >> feeling that many people keep ancient systems in production, and I wonder >> which they would prefer - a project that is stable on a Pharo version (more >> or less) when that version is released or having the latest commits, >> especially bug fixes. >> Thoughts? >> >>

Aug. 30, 2022