- Pharo-dev - lists.pharo.org

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

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