- Pharo-dev - lists.pharo.org

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

Platform Packages vs. Git Branches

by sean＠clipperadams.com

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: Status update of Libgit2 and CI issues

by Nicolas Anquetil

yes indeed thanks a lot for handling this during ESUG ! nicolas On 23/08/2022 17:07, Guillermo Polito wrote: > Hi all, > > * after some hiccups, CI servers are up un running. > > See for example: > > https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=… > > * Another extra fix to an issue affecting only OSX machines is on the > pipe with backports for Pharo10 and Pharo9. > > https://github.com/pharo-project/pharo/issues/11561 > > Please, tell us if you find some other problem. > G > >> El 19 ago 2022, a las 21:31, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> escribiÃ³: >> >> >> Thank you for the update. >> I followed the thread and I imagine it was not easy to work on this >> problem. >> >> Best regards, >> >> HernÃ¡n >> >> >> El vie, 19 ago 2022 a las 16:45, Guillermo Polito >> (<guillermopolito(a)gmail.com>) escribiÃ³: >> >> A couple of weeks ago we got reported a big recurrent failure on >> CI jobs while cloning using iceberg/libgit >> https://github.com/pharo-project/pharo/issues/11481. >> >> TL;DR; So far (Friday ~17h Paris time) we managed to get >> everything up and running. A new VM is being released by our CI, >> all pull requests are issued and we should have everything >> integrated by tonight. >> >> =-=-=-=-=-=-=-= >> >> More on the situation: Errors happened randomlyÂ with >> >> ``` >> error reading from the zlib stream >> ``` >> >> or >> ``` >> bad packet length >> ``` >> >> Several people helped in getting a reliable script to reproduce >> the issue, plus some instructions to produce a reproduction >> environment using a docker container. With that in our hands, we >> managed to corner the issue to a new incompatibility between old >> libgit2 versions, ssh2, OpenSSL, and (at least) Github. >> >> After testing some configurations, we decided to upgrade the >> libgit and related binaries to newer versions: >> Â - libgit 1.4.4 >> Â - libssh 1.9.0 >> Â - OpenSSL 1.1.1k >> >> This was of course not as straightforward as we would have liked. >> Libgit2 1.4.4 was not compatible with its older versions and >> broke our ffi bindings. >> We needed to provide new VM binaries for all our major platforms, >> make a new VM release, upgrade the libgit2 bindings, and make >> releases of the libgit2 bindings, iceberg, and backport to Pharo >> 10 and Pharo 9. >> >> TL;DR; So far (Friday ~17h Paris time) we managed to get >> everything up and running. A new VM is being released by our CI, >> all pull requests are issued and we should have everything >> integrated by tonight. >> >> Libgit+related compilation instructions are updated in the VM wiki >> https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Par… >> https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… >> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… >> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… >> >> Libgit bindings Upgrade >> Â Â changes: >> https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… >> Â Â release: >> https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6 >> >> Iceberg Upgrade >> Â Â pr: https://github.com/pharo-vcs/iceberg/pull/1605 >> Â Â release: https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7 >> >> Upgrading library dependencies in the VM >> https://github.com/pharo-project/pharo-vm/pull/447 >> Â Release VM 9.0.16 >> https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16 >> >> Backports to Pharo >> Â Pharo10 https://github.com/pharo-project/pharo/pull/11545 >> Â Pharo9 https://github.com/pharo-project/pharo/pull/11546 >> >> We have left for later to upgrade library dependencies for the >> Windows VM (x86-64, ARM64). >> Of course, any help in this direction is welcome. >> >> Cheers, >> G in behalf of the team >> > -- Nicolas Anquetil RMod team -- Inria Lille

Aug. 23, 2022

Re: What, exactly, does `#=` mean?

by Nicolas Cellier

The general expectations are that = should be an equivalence relation - reflexive (a = a) = true - symmetric (a = b) = (b = a) - transitive (a = b) & (b = c) ==> (a = c) https://en.wikipedia.org/wiki/Equivalence_relation Note that = is currently not an equivalence relation for Float, because of (Float nan = Float nan) = false. Also note that Number = means that the values are equal, not necessarily that the behavior is identical. For example (1/2) = 0.5, but (1/2) printString ~= 0.5 printString, and 0.5 does not understand #denominator for example... We expect the behavior to match to some degree, but it's very application specific... In some dialects (1/10) = 0.1 even if those numbers don't share the same value (and this obviously breaks the transitivity rule). Another questionable example is (1 to: 3) = #(1 2 3). The answer might differ across Smalltalk dialects. A point of view is that they behave similarly as two sequenceable collections with equal elements. Another point of view is that the implementation cost is too high, for example for maintaining hash implication (a = b) ==> (a hash = b hash). Even, 'foobar' = #foobar is dialect specific (a false answer enables hash optimization by using identityHash for Symbol). A clear sign that there is not a unique definition... If it is about cached state, I see it as an implementation detail (an optimization), and best efforts should be made so that the optimization remains a detail, and does not leak into behavioral differences... Well, except in well known and well documented cases if we can't avoid it. Nicolas Le mar. 23 aoÃ»t 2022 Ã 15:59, James Foster <Smalltalk(a)jgfoster.net> a Ã©crit : > I donât think there is a formal definition. Iâve heard it described as > âanswers the same result when sent the same messageâ but that wouldnât work > for #âidentityHashâ, so I think it is whatever you say it is in your domain. > > By the way, I try to avoid the term âequalâ and use âequivalentâ and > âidenticalâ to describe #â=â and #â==â respectively. > > James > > On Aug 23, 2022, at 3:48 PM, sean(a)clipperadams.com wrote: > > Anyone know of a book that goes in depth explaining `#=`? > > I've always wondered what "equal" is supposed to mean. > > For example, if I have two objects representing the same person, but one > has their webpage cached as state, they represent the same entity, and are > interchangeable in many contexts, but also have a difference that may be > important in other contexts. > > Is âequalâ whatever you say it is in your domain, or is it a Smalltalk > object system concept? If the latter, what is the exact expectation? > > >

Aug. 23, 2022

Re: Status update of Libgit2 and CI issues

by Guillermo Polito

Hi all, * after some hiccups, CI servers are up un running. See for example: https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=… <https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=…> * Another extra fix to an issue affecting only OSX machines is on the pipe with backports for Pharo10 and Pharo9. https://github.com/pharo-project/pharo/issues/11561 <https://github.com/pharo-project/pharo/issues/11561> Please, tell us if you find some other problem. G > El 19 ago 2022, a las 21:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> escribiÃ³: > > > Thank you for the update. > I followed the thread and I imagine it was not easy to work on this problem. > > Best regards, > > HernÃ¡n > > > El vie, 19 ago 2022 a las 16:45, Guillermo Polito (<guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>) escribiÃ³: > A couple of weeks ago we got reported a big recurrent failure on CI jobs while cloning using iceberg/libgit https://github.com/pharo-project/pharo/issues/11481 <https://github.com/pharo-project/pharo/issues/11481>. > > TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and running. A new VM is being released by our CI, all pull requests are issued and we should have everything integrated by tonight. > > =-=-=-=-=-=-=-= > > More on the situation: Errors happened randomly with > > ``` > error reading from the zlib stream > ``` > > or > ``` > bad packet length > ``` > > Several people helped in getting a reliable script to reproduce the issue, plus some instructions to produce a reproduction environment using a docker container. With that in our hands, we managed to corner the issue to a new incompatibility between old libgit2 versions, ssh2, OpenSSL, and (at least) Github. > > After testing some configurations, we decided to upgrade the libgit and related binaries to newer versions: > - libgit 1.4.4 > - libssh 1.9.0 > - OpenSSL 1.1.1k > > This was of course not as straightforward as we would have liked. > Libgit2 1.4.4 was not compatible with its older versions and broke our ffi bindings. > We needed to provide new VM binaries for all our major platforms, make a new VM release, upgrade the libgit2 bindings, and make releases of the libgit2 bindings, iceberg, and backport to Pharo 10 and Pharo 9. > > TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and running. A new VM is being released by our CI, all pull requests are issued and we should have everything integrated by tonight. > > Libgit+related compilation instructions are updated in the VM wiki > https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Par… <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Par…> > https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa…> > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P…> > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P…> > > Libgit bindings Upgrade > changes: https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… <https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c…> > release: https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6 <https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6> > > Iceberg Upgrade > pr: https://github.com/pharo-vcs/iceberg/pull/1605 <https://github.com/pharo-vcs/iceberg/pull/1605> > release: https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7 <https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7> > > Upgrading library dependencies in the VM > https://github.com/pharo-project/pharo-vm/pull/447 <https://github.com/pharo-project/pharo-vm/pull/447> > Release VM 9.0.16 https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16 <https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16> > > Backports to Pharo > Pharo10 https://github.com/pharo-project/pharo/pull/11545 <https://github.com/pharo-project/pharo/pull/11545> > Pharo9 https://github.com/pharo-project/pharo/pull/11546 <https://github.com/pharo-project/pharo/pull/11546> > > We have left for later to upgrade library dependencies for the Windows VM (x86-64, ARM64). > Of course, any help in this direction is welcome. > > Cheers, > G in behalf of the team

Aug. 23, 2022

Re: What, exactly, does `#=` mean?

by James Foster

I donât think there is a formal definition. Iâve heard it described as âanswers the same result when sent the same messageâ but that wouldnât work for #âidentityHashâ, so I think it is whatever you say it is in your domain. By the way, I try to avoid the term âequalâ and use âequivalentâ and âidenticalâ to describe #â=â and #â==â respectively. James > On Aug 23, 2022, at 3:48 PM, sean(a)clipperadams.com wrote: > > Anyone know of a book that goes in depth explaining `#=`? > > I've always wondered what "equal" is supposed to mean. > > For example, if I have two objects representing the same person, but one has their webpage cached as state, they represent the same entity, and are interchangeable in many contexts, but also have a difference that may be important in other contexts. > > Is âequalâ whatever you say it is in your domain, or is it a Smalltalk object system concept? If the latter, what is the exact expectation? >

Aug. 23, 2022