August 2022 - Pharo-dev - lists.pharo.org

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

Re: Platform Packages vs. Git Branches

by Dale Henrichs

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 :) 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. 29, 2022

Re: Platform Packages vs. Git Branches

by Max Leske

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. 29, 2022

This week (34/2022) on the Pharo Issue Tracker MD Marcus Denker

by Marcus Denker

We merged 28 PRs this week: Improvements ============ - Optimize setting of initial position in PositionableStream>>on: #11555 https://github.com/pharo-project/pharo/pull/11555 - Rotten green tests plugin for DrTests #11513 https://github.com/pharo-project/pharo/pull/11513 Git Support ========= - Updating Libgit2 Bindings to version 2.2.6 #1605 https://github.com/pharo-vcs/iceberg/pull/1605 - Fix Pharo's #11370: Cannot commit when adding a class instance variable #1597 https://github.com/pharo-vcs/iceberg/pull/1597 - Update Iceberg to 2.0.8 #11581 https://github.com/pharo-project/pharo/pull/11581 Cleanups ======== - Cleanup typo in ASTCache>>#at: #11557 https://github.com/pharo-project/pharo/pull/11557 - README.md and Bootstrap cleanup #11453 https://github.com/pharo-project/pharo/pull/11453 - Update class comment of AsciiCharSet #11575 https://github.com/pharo-project/pharo/pull/11575 - Class comment for RBCommentToken #11571 https://github.com/pharo-project/pharo/pull/11571 - Categorize RBShortAssignmentToken>>#length like superclass #11569 https://github.com/pharo-project/pharo/pull/11569 - Just some formatting in a package comment #11560 https://github.com/pharo-project/pharo/pull/11560 - RBScanner>>#isSelectorNonBinary improve with script: pragma #11567 https://github.com/pharo-project/pharo/pull/11567 - Enhance isUnary method comment #11541 https://github.com/pharo-project/pharo/pull/11541 - Fixes: #11526 and #11527: Refactoring2-core merge and baseline fix #11529 https://github.com/pharo-project/pharo/pull/11529 - Typo in class comment of AllProtocol #11573 https://github.com/pharo-project/pharo/pull/11573 - Cleanup AthensBalloonPaint and AthensBalloonGradientPaint #11579 https://github.com/pharo-project/pharo/pull/11579 - Small cleanups in Object #11594 https://github.com/pharo-project/pharo/pull/11594 - Improve #basicSize documentation and add tests #11590 https://github.com/pharo-project/pharo/pull/11590 - Cleanup ReferenceFinder>>#searchIndicesIn: #11592 https://github.com/pharo-project/pharo/pull/11592 - Removed empty abstractCompletionEngine class #11562 https://github.com/pharo-project/pharo/pull/11562 - Stream should be declared as abstract class #11553 https://github.com/pharo-project/pharo/pull/11553 - PositionableStream should be declared as abstract class #11551 https://github.com/pharo-project/pharo/pull/11551 - EncodedCharSet should return true for #isAbstract #11549 https://github.com/pharo-project/pharo/pull/11549 Pharo10 ======= - Updating version of Iceberg to 2.0.7, for libgit 1.4.4 -- Backport to Pharo 10 #11545 https://github.com/pharo-project/pharo/pull/11545 - Creates Graphical UI for AndreasProfiler and TimeProfiler #11532 https://github.com/pharo-project/pharo/pull/11532 Pharo9 ======= - Upgrade iceberg to 2.0.7 -- backport to Pharo 9 #11546 https://github.com/pharo-project/pharo/pull/11546 - Update Iceberg to 2.0.8 #11582 https://github.com/pharo-project/pharo/pull/11582

Aug. 26, 2022

Re: Platform Packages vs. Git Branches

by Dale Henrichs

I have some thoughts... Depending upon the pace of relative development keep in mind that merging changes between platform branches could present interesting problems whereas the package-based approach allows one to copy a method (if the algorithm is too platform-specific --- this the area where merging gets interesting, especially if there are a number of methods involved), or a class (if the class needs to be replaced on a platform by platform basis) or insert extension methods and/or supplementary classes with relative ease... Also, keep in mind that CI on GitHub is a critical component of cross-platform project support. Over the years being able to rely on Travis runs to highlight platform specific issues in a PR is extremely valuable to keeping the port up-to-date --- it helps reinforce the cross-platform nature of the project for contributors and allows platform maintainers to be involved in the process while the iron is hot ... If Github actions can be written that would run actions for multiple branches on the basis of a PR on a different branch, then this "requirement" might be satisfied. In the very early days of using github and Smalltalk, I used the branch per platform approach for FileTree[1] (so it was the first multi-platform project for me) ... and if you look at the network graph[2], jump to the end and scroll backwards, you will find that the merges between branches stopped in the very early days and in the end they were effectively two separate projects (in more ways than one) that diverged quite a bit over time. The big problem with that effort was there was never a good definition of the common code base and the "common code" diverged over time to the point where a merge was not feasible ... We didn't have cross-branch CI with travis-ci so I imagine that the experiment my have turned out better if the platform branches and most importantly the common code, could have been been kept in synch by concurrent testing ... If multi-branch CI is possible the major sticking point would be the "automatic merge" that would be required in the case of merge conflicts ... and this becomes a bigger issue when the developer of the contribution does not have the ability to run local tests of manually merged conflicts (yikes) ... with a package-based approach if a test fails due to platform-specific issue, a topic branch for the issue can be created and the original contributor and a platform expert can collaborate on a solution on the same topic branch until the tests are passing ... this is basically the approach that has been taken with all of the multi-platform projects that I've been involved in over the last decade and it "works" ... not perfect by any means, but certainly functional ... Dale [1] https://github.com/dalehenrich/filetree [2] https://github.com/dalehenrich/filetree/network On Thu, Aug 25, 2022 at 7:16 AM <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. 25, 2022

Re: Platform Packages vs. Git Branches

by James Foster

My thought is that the âGit wayâ would be to have an âabstractâ project for the shared code and separate âconcreteâ projects for each of the dialects. Within each dialect-specific project include the shared code as a submodule. See https://stackoverflow.com/questions/12883543/how-to-organize-cross-platform…. > On Aug 25, 2022, at 4:16 PM, 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. 25, 2022