February 2025 - Pharo-users

Pharo News of the Week 06/2025

by Marcus Denker

# Pharo News of the Week 06/2025 - [ANN] GSoC 2025 Mentors/Topics needed: https://www.pharo.org/news/2025-01-30-GSOC2025.html - [ANN] We are now on bluesky: https://bsky.app/profile/pharoproject.bsky.social - [ANN] and of course mastodon since a long time: https://mastodon.social/@pharoproject If you want to add your news to this list, use this form: https://tinyurl.com/4c89buy4 # The week on the Pharo Issue Tracker # Pharo 11 - Update version in #documentBrowser for BaselineOfPharo for Pharo 11 to âv1.0.4â #17766 https://github.com/pharo-project/pharo/pull/17766 # Pharo 12 - Backport changes to not restore ffi methods if they are not installed #17780 https://github.com/pharo-project/pharo/pull/17780 # Fixes - Fix opening of the Dependency analyzer #17763 https://github.com/pharo-project/pharo/pull/17763 - Fix browsing of methods in Epicea #17764 https://github.com/pharo-project/pharo/pull/17764 - Do not resume running process #17777 https://github.com/pharo-project/pharo/pull/17777 - Fixing browse in KMDescriptionPresenter #17776 https://github.com/pharo-project/pharo/pull/17776 - Fix cursor navigation #17772 https://github.com/pharo-project/pharo/pull/17772 - Fix save image dialog default values #17767 https://github.com/pharo-project/pharo/pull/17767 - 17563-propertyAtput-looks-bogus, #17754 https://github.com/pharo-project/pharo/pull/17754 # Features - Addition of new setting for using SpClosedWindowListPresenter or not #17757 https://github.com/pharo-project/pharo/pull/17757 # Code Completion - Branch: addingSetterToCoHeuristic #17782 https://github.com/pharo-project/pharo/pull/17782 # VM - Remove debugging code #911 https://github.com/pharo-project/pharo-vm/pull/911 - Simplify signal handler space calculation: use SIGSTKSZ, posix defined #910 https://github.com/pharo-project/pharo-vm/pull/910 # Newtools - changed menu bug display and updated baseline #970 https://github.com/pharo-spec/NewTools/pull/970 - Update world menu entry for the finder #982 https://github.com/pharo-spec/NewTools/pull/982 - Fix selection in save file presenter #980 https://github.com/pharo-spec/NewTools/pull/980 - Unsubscribe if user dont want to use the presenter anymore #977 https://github.com/pharo-spec/NewTools/pull/977 - Started to pass the stApplication in the open method #976 https://github.com/pharo-spec/NewTools/pull/976 - Moved IRMethod extension to OCIRMethod #975 https://github.com/pharo-spec/NewTools/pull/975 - Memory leak fix #972 https://github.com/pharo-spec/NewTools/pull/972 - adds property to morph when closed and remove it when unhidden #971 https://github.com/pharo-spec/NewTools/pull/971 # Tests - Skipping two tests to get the green bar for now. #17743 https://github.com/pharo-project/pharo/pull/17743 - Fix and improve WindowAnnouncementTest #17773 https://github.com/pharo-project/pharo/pull/17773 - Fix testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses #17769 https://github.com/pharo-project/pharo/pull/17769 # Website - Update community.md: add bluesky link #84 https://github.com/pharo-project/pharo-website/pull/84 # Cleanups - Branch: 17675-Opal-Extension-symbolic-to-Debugging-Core #17735 https://github.com/pharo-project/pharo/pull/17735 - Branch: 17672-Rename-formatter-in-EFtests-to-avoid-spurious-sender-clash #17736 https://github.com/pharo-project/pharo/pull/17736 - Remove String>>isValidSelector #17741 https://github.com/pharo-project/pharo/pull/17741 - 17746-remove-ClassdeprecationRefactorings, Fixes #17746 #17747 https://github.com/pharo-project/pharo/pull/17747 - 17742-isSelectorSymbol-should-be-renamed-isUsedAsSelectorSymbol #17748 https://github.com/pharo-project/pharo/pull/17748 - 17667-remove-display-of-empty-sharedVariables-from-class-default-tempâ¦ #17749 https://github.com/pharo-project/pharo/pull/17749 - Branch: 17750-FormasText-from-MD-to-Form, #17751 https://github.com/pharo-project/pharo/pull/17751 - Branch: FixKMLeftInstanceVariable, #17758 https://github.com/pharo-project/pharo/pull/17758 - Removed Stuff linked to the presenter #17761 https://github.com/pharo-project/pharo/pull/17761 - Clean tool registry2 #17765 https://github.com/pharo-project/pharo/pull/17765

Feb. 7, 2025

Re: "Book release: Application Building with Spec 2.0" â New blog post on all: objects all: theTime

by stephane ducasse

Thanks. I have some other books under preparation :) S > On 1 Feb 2025, at 23:51, Mark O'Donoghue <mark.odonoghue.2010(a)gmail.com> wrote: > > Congratulation Stephane on completing this book. > > I feel it is crucial. It removes a major hurdle for new, part time and/or returning programmers to get what they need with a UI for their Pharo programs. > > For me, it also helps me advocating for Pharo with my colleagues. > > Cheers > Mark > > On Sun, 2 Feb 2025, 12:07 am stephane ducasse, <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> Thanks. >> Writing this book was a daunting huge difficult exhausting task that took me around 4 years or more. >> >> This publisher is managed using a not so great Php software and I can tell you that you can feel it when >> you have to manage the books. >> >> S >> >>> On 30 Jan 2025, at 17:51, giorgio ferraris <giorgio.ferraris(a)gmail.com <mailto:giorgio.ferraris@gmail.com>> wrote: >>> >>> hello!, >>> >>> Thank you for the answer, I ordered the book today, please note that it still seems that is written in French. >>> >>> happy smalltalking >>> >>> >>> giorgio >>> >>> On Thu, Nov 7, 2024 at 1:23â¯PM Koen De Hondt <koen(a)all-objects-all-the-time.st <mailto:koen@all-objects-all-the-time.st>> wrote: >>>> Hi Giorgio, >>>> >>>> Thank you for reporting the issue. >>>> >>>> Yes, it is an error. We saw it a few days ago, but it has not been fixed yet. >>>> >>>> Best regards, >>>> Koen >>>> >>>>> On 7 Nov 2024, at 12:27, giorgio ferraris <giorgio.ferraris(a)gmail.com <mailto:giorgio.ferraris@gmail.com>> wrote: >>>>> >>>>> hello, >>>>> >>>>> The Amazon site says that the language is French. Is that an error? >>>>> >>>>> thanks >>>>> >>>>> ciao >>>>> >>>>> giorgio >>>>> >>>>> <Screenshot 2024-11-07 at 12.25.47.png> >>>>> >>>>> On Thu, Nov 7, 2024 at 6:32â¯AM Koen De Hondt <koen(a)all-objects-all-the-time.st <mailto:koen@all-objects-all-the-time.st>> wrote: >>>>>> Dear Pharo users and developers, >>>>>> >>>>>> It required an enormous effort to review, rewrite, and extend it, but I am happy to announce that it is finally here: the book on application building in Pharo with Spec 2.0. >>>>>> >>>>>> I wrote a blog post about it <https://all-objects-all-the-time.st/#/blog/posts/9>. Happy reading! >>>>>> >>>>>> Ciao, >>>>>> Koen >>>> >> >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> >> 06 30 93 66 73 >> >> "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes >> >> >> >> >> StÃ©phane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes

Feb. 6, 2025

Pharo Association 2024 Review

by tesonep＠gmail.com

Dear Pharo Association members, Pharoers and Smalltalkers from all over the world We are writing you to thank you again for your support of the Pharo Association. With your help, we are able to perform a lot of activities to increase the impact of Pharo, enlarge its community and have a better programming life for everyone. For the people who are not members of the association, we take the opportunity to tell you all the accomplishments of the association last year and invite you to participate in any of the forms our association provides. We want to profit this time of the year to tell you the most important actions that the association has supported the last years. - *Infrastructure for Pharo: *as an association, we support the maintenance of the infrastructure used by Pharo. We provided the funds for the hosting of Pharo services (website, file server, mailing lists) and domains. Most of the services that we daily use are supported by your help. Thanks for allowing the community to use the Pharo Launcher or getting an image from ZeroConf. - *Conference Sponsoring:* we all love to go to nice conferences and much more if there is Pharo-related content on it. This year as it is tradition we supported the *ESUG 2024 *conference. Having a place to interchange and to publish all the advances in Pharo is key to its development. - *Summer School: *With the objective of extending the Pharo community, in 2024, we sponsored a summer school at Split, Croatia about advanced object-oriented design with Pharo. Due to the nice reception and results, this year we are again sponsoring a summer school in February at Montpellier. - *Pharo Music: *Smalltalk has been always a language close to the arts, and Pharo is not an exception. This year, we heavily sponsored the development of Phausto, Coypu and CoypuIDE. *Phausto <https://github.com/lucretiomsp/phausto>* is a library and API that allows to use the FAUST compiler and its libraries (Functional Audio Stream) inside Pharo. *Coypu <https://github.com/lucretiomsp/Coypu>* is a package with methods and classes for Pharo designed for programming music on-the-fly, and it has its *IDE <https://github.com/pharo-graphics/CoypuIDE>* developed in Bloc. This tools has been presented in numerous technical and musical conferences, and in all of them they have generated a lot of attention and interest. We are much than happy with the results we are obtaining. - *Student Sponsoring:* we sponsored the access of students using Pharo to Summer Schools and visits to labs. We sponsored also the food and drinks of small meetings where students can learn and play with Pharo. This sponsoring is particularly important because often the labs are not allowed to pay trips of students, limiting the access to international students. Because of that, we sponsored students from Argentina (2), Serbia, Madagascar (3), Chile, and Bolivia. Without your support we would not be able to plant Pharo seeds all over the world. Your help is base to increase the community and to help all the people interested in Pharo. - *Book Sponsoring: *During last year, we have sponsored the write of 4 new books about Pharo. These books covers subjects for newcomers and experts, going from the style of code, testing and UI creation. All the books are available to the community (*https://books.pharo.org/ <https://books.pharo.org/>*) and even you can get a physical copy. We consider that we need to provide the material to let all the people interested to grow in their Pharo experience. We want to thank you again for your support as all the support we are getting are from our members. We remember you that you can renew or increase your subscription at *https://association.pharo.org <https://association.pharo.org/>*. Your support is really important for us because it enables us to do actions that would be almost impossible to do. Finally we remember you that we are always open to listen your opinions and suggestions, and to receive requests for sponsoring or support at *association(a)pharo.org <association(a)pharo.org>*. Sorry if you have got this mails from different channels. Thank you so much again, and we desired you and excellent new year! *Pharo Association*

Feb. 5, 2025

Re: "Subject in SUnit Tests" â New blog post on all: objects all: theTime

by Russ Whaley

Agreed. A little knowledge of how it is to be used can go a long way. I seem to have a mental block on creating traits. I am sure my code and applications would benefit - but I just canât seem to understand what they are and how to design/implement them. Russ Whaley whaley.russ(a)gmail.com On Tue, Feb 4, 2025 at 2:23â¯AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > I too like to use random data in test cases but you also have to use > edge cases that random data tend to avoid. > It is painful to recall the millions of successful tests of my > Dictionary implementation that failed to detect that > "Dictionary new: 0" created a non-functional object. ((self pvtHash: > key) \\ capacity) + 1" did not work well when > capacity was 0. 0 size, 0 capacity, 0 room left, any edge case. > Conversely, you have to avoid special cases > sometimes: when testing x ./ y and y \ x for Quaternions, you want to > make sure y isZero not. > > One thing I would like some advice on is testing traits. I understand > about testing classes and about testing > methods in classes (though I am never thorough enough), but how do you > test a method that isn't bound to > a particular context, where the thing that reveals a mistake may be a > class it will be combined with in the > future that doesn't exist yet? What is considered good practice? > > On Tue, 4 Feb 2025 at 05:25, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > > > Folks, I really appreciate (and learn from) these types of conversations > - especially on testing where I struggle for consistency and completeness. > > > > I tend to agree that my testing focuses on methods, however the majority > of my âfailuresâ revolve around insufficient object values that eventually > have my tests failing - Iâve defaulted to generating âdataâ as randomly as > I can early on, however non-realistic, and running tests a few thousand > times to point out assumptions I make in my methods. > > > > Thanks for discussions! > > > > Russ Whaley > > whaley.russ(a)gmail.com > > > > > > On Thu, Jan 23, 2025 at 5:02â¯AM Richard O'Keefe <raoknz(a)gmail.com> > wrote: > >> > >> This makes the assumption that there is, most of the time, a single, > >> unique, object that the test is clearly about. > >> I hasten to admit that my unit testing practice needs a lot to be > desired. > >> But it has not been my experience that there *is* any such object much > >> of the time. > >> For example, to test a method, I will sometimes create two equal > >> objects, manipulate one of them in the > >> old trusted way, manipulate the other in the new way, and then see if > >> the objects are equal again. > >> Which then is *the* subject? > >> The answer is neither, because what the test is *about* is not an > >> object, but a method. > >> Or again, I open a stream to a new file, create a complex object, > >> persist it on the stream, close > >> the stream, open another stream reading from the file, reconstitute an > >> object from it, and then > >> check that the two objects are isomorphic. Which is *the* subject? > >> Neither, because what I am testing is the encoding and decoding > >> methods, not the objects. > >> > >> The key paragraph is this one: > >> <quote> > >> One could argue that there is not always a single object under test. > >> In some situations that is correct, for instance when testing the > >> interaction between objects. But in my experience, most unit tests > >> have a single object under test. > >> </quote> > >> > >> And it is *this* that we really need a blog post on. I am very ready > >> to believe that you are a much better tester than I am. > >> (That wouldn't be hard.) But *something* interesting is going on when > >> I think in terms of testing classes and methods to > >> the point where I find the idea of testing a particular object almost > >> incomprehensible, yet you think this is the norm. > >> I take some comfort from the fact that the Gherkin language in > >> Cucumber (and why oh which has nobody bothered to > >> write down a proper grammar, let alone even an informal semantics, for > >> it? How am I supposed to know what is and what > >> is not legal Gherkin?) goes out of its way to conceal the existence > >> of subjects, should they exist, from test reviewers, and > >> calls what a test is about a "feature". > >> > >> Here are two tests for the Quaternion class: > >> testMultiplicationByScalarCommutes > >> sampleExactScalars do: [:x | > >> sampleExactQuaternions do: [:y | > >> self assert: (x*y) = (y*x)]]. > >> > >> testMultiplicationOfPowersCommutes > >> sampleExactQuaternions do: [:x | > >> |y z| > >> y := x squared. > >> z := x cubed. > >> self assert: (y*z) = (z*y)]. > >> > >> These two methods test important properties of the #* method. > >> > >> Here's another one, part of testing the test data.. > >> > >> testExactScalarsAreExactScalars > >> sampleExactScalars do: [:each | > >> self assert: each isScalar. > >> self assert: each isExact]. > >> > >> This tests the *methods* #isScalar and #isExact, and indirectly the > >> code that generates the test data. > >> It's not about any particular object. Nor is it about *one* method. > >> It's very hard to write a test case that > >> tests only one method. In fact my own rather embarrassing experience > >> is that when a test case of mine > >> failed it quite often wasn't the method I thought I was testing that > >> was wrong. Returning to the > >> persistence example, it's not testing #saveOn: (object saveOn: > >> byteStream) or #restore (byteStream restore). > >> It's testing that the two methods are properly related. It would be > >> wrong to call it #testSaveOn: and it > >> would be wrong to call it #testRestore. There's a distinction here: > >> it *is* possible to write methods to test > >> #saveOn: by itself, by writing various objects and checking that you > >> get the right bytes. But if the external > >> representation is changed (and I need to change it), the tests for > >> #saveOn: and #restore as such will have > >> to be rewritten, while the tests for #saveOn: and #restore *together* > will not. > >> > >> Cucumber offers an insight here, I think. A scenario in Gherkin is > >> not a test case for an object. > >> Nor is it a test case for a method. It is a test case for a composite > >> *behaviour* of a system, > >> at some contextually appropriate level of detail. > >> > >> Brian Marick had some lovely stickers. One of them reads "An example > >> would be handy about now." > >> > >> I note that your blog post *did* provide an example of testing Date. > >> In which none of your test cases used 'subject'. > >> I entirely agree with you that the three methods have good > >> intention-revealing names. > >> What we actually need is some examples where 'subject' pays off. > >> > >> > >> > >> On Mon, 20 Jan 2025 at 04:04, Koen De Hondt > >> <koen(a)all-objects-all-the-time.st> wrote: > >> > > >> > Dear Pharo users and developers, > >> > > >> > In my series of blog posts on testing, I added a follow-up post about > a dedicated name for the object under test in SUnit tests, the âsubject". > >> > > >> > Happy reading! > >> > > >> > Ciao, > >> > Koen > >> > >

Feb. 4, 2025

Re: About String and Symbol equality

by Richard O'Keefe

No, String is NOT a special case in the ANSI standard, which is what I was specifically writing about. WideString is not in the standard, thank goodness (although at the time the standard was made, it was already clear that at least 16-bit characters were needed). The ANSI rule perfectly fits the semantics of all the ANSI classes and it only applies to sequences defined in the standard, as I thought was clear. It doesnât apply to numbers, for example. Other than the coherence requirements, there are no constraints on non-standard classes. The rule I quoted about âsame classâ can of course be overridden for specific cases, but in the ANSI stansrd there is no overriding that would justify âxâ = #x. Really, strings of 21-bit codes are the ârealâ strings and other kinds of string are just storage optimisations. It is much simpler if there is one sort of string. For what itâs worth, in my Smalltalk implementation Symbol is not a subclass of String. That way I donât have to worry about what Symbol>>at:put: does. (They do have a common abstract superclass.) On Tue, 4 Feb 2025 at 10:36â¯PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On 3 Feb 2025, at 06:33, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > Not that anyone else probably cares, but the ANSI standard says > > - for All objects x y, x = y if and only if y = x. > > The Smalltalk-80 mixup over String and Symbol violated this, > > âXâ = #x but #x ~= âxâ. > > - two sequences are = iff they are the same size, corresponding elements > are =, AND they are instances of the same class. > > That seems to be a very limited view of equality (that the class has to be > the same for all definitions of equality). > > To me that means it models more the technical detail of Implementation, > not the Domain. > > > - String is not a special case. > > > > But String *is* a special case: > > 'hello' asWideString = 'hello' "true" > 'hello' asWideString class = 'hello' class "false" > > > Marcus

Feb. 4, 2025

Re: About String and Symbol equality

by Marcus Denker

> On 3 Feb 2025, at 06:33, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Not that anyone else probably cares, but the ANSI standard says > - for All objects x y, x = y if and only if y = x. > The Smalltalk-80 mixup over String and Symbol violated this, > âXâ = #x but #x ~= âxâ. > - two sequences are = iff they are the same size, corresponding elements are =, AND they are instances of the same class. That seems to be a very limited view of equality (that the class has to be the same for all definitions of equality). To me that means it models more the technical detail of Implementation, not the Domain. > - String is not a special case. > But String *is* a special case: 'hello' asWideString = 'hello' "true" 'hello' asWideString class = 'hello' class "false" Marcus

Feb. 4, 2025

Re: "Subject in SUnit Tests" â New blog post on all: objects all: theTime

by Richard O'Keefe

I too like to use random data in test cases but you also have to use edge cases that random data tend to avoid. It is painful to recall the millions of successful tests of my Dictionary implementation that failed to detect that "Dictionary new: 0" created a non-functional object. ((self pvtHash: key) \\ capacity) + 1" did not work well when capacity was 0. 0 size, 0 capacity, 0 room left, any edge case. Conversely, you have to avoid special cases sometimes: when testing x ./ y and y \ x for Quaternions, you want to make sure y isZero not. One thing I would like some advice on is testing traits. I understand about testing classes and about testing methods in classes (though I am never thorough enough), but how do you test a method that isn't bound to a particular context, where the thing that reveals a mistake may be a class it will be combined with in the future that doesn't exist yet? What is considered good practice? On Tue, 4 Feb 2025 at 05:25, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > Folks, I really appreciate (and learn from) these types of conversations - especially on testing where I struggle for consistency and completeness. > > I tend to agree that my testing focuses on methods, however the majority of my âfailuresâ revolve around insufficient object values that eventually have my tests failing - Iâve defaulted to generating âdataâ as randomly as I can early on, however non-realistic, and running tests a few thousand times to point out assumptions I make in my methods. > > Thanks for discussions! > > Russ Whaley > whaley.russ(a)gmail.com > > > On Thu, Jan 23, 2025 at 5:02â¯AM Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> This makes the assumption that there is, most of the time, a single, >> unique, object that the test is clearly about. >> I hasten to admit that my unit testing practice needs a lot to be desired. >> But it has not been my experience that there *is* any such object much >> of the time. >> For example, to test a method, I will sometimes create two equal >> objects, manipulate one of them in the >> old trusted way, manipulate the other in the new way, and then see if >> the objects are equal again. >> Which then is *the* subject? >> The answer is neither, because what the test is *about* is not an >> object, but a method. >> Or again, I open a stream to a new file, create a complex object, >> persist it on the stream, close >> the stream, open another stream reading from the file, reconstitute an >> object from it, and then >> check that the two objects are isomorphic. Which is *the* subject? >> Neither, because what I am testing is the encoding and decoding >> methods, not the objects. >> >> The key paragraph is this one: >> <quote> >> One could argue that there is not always a single object under test. >> In some situations that is correct, for instance when testing the >> interaction between objects. But in my experience, most unit tests >> have a single object under test. >> </quote> >> >> And it is *this* that we really need a blog post on. I am very ready >> to believe that you are a much better tester than I am. >> (That wouldn't be hard.) But *something* interesting is going on when >> I think in terms of testing classes and methods to >> the point where I find the idea of testing a particular object almost >> incomprehensible, yet you think this is the norm. >> I take some comfort from the fact that the Gherkin language in >> Cucumber (and why oh which has nobody bothered to >> write down a proper grammar, let alone even an informal semantics, for >> it? How am I supposed to know what is and what >> is not legal Gherkin?) goes out of its way to conceal the existence >> of subjects, should they exist, from test reviewers, and >> calls what a test is about a "feature". >> >> Here are two tests for the Quaternion class: >> testMultiplicationByScalarCommutes >> sampleExactScalars do: [:x | >> sampleExactQuaternions do: [:y | >> self assert: (x*y) = (y*x)]]. >> >> testMultiplicationOfPowersCommutes >> sampleExactQuaternions do: [:x | >> |y z| >> y := x squared. >> z := x cubed. >> self assert: (y*z) = (z*y)]. >> >> These two methods test important properties of the #* method. >> >> Here's another one, part of testing the test data.. >> >> testExactScalarsAreExactScalars >> sampleExactScalars do: [:each | >> self assert: each isScalar. >> self assert: each isExact]. >> >> This tests the *methods* #isScalar and #isExact, and indirectly the >> code that generates the test data. >> It's not about any particular object. Nor is it about *one* method. >> It's very hard to write a test case that >> tests only one method. In fact my own rather embarrassing experience >> is that when a test case of mine >> failed it quite often wasn't the method I thought I was testing that >> was wrong. Returning to the >> persistence example, it's not testing #saveOn: (object saveOn: >> byteStream) or #restore (byteStream restore). >> It's testing that the two methods are properly related. It would be >> wrong to call it #testSaveOn: and it >> would be wrong to call it #testRestore. There's a distinction here: >> it *is* possible to write methods to test >> #saveOn: by itself, by writing various objects and checking that you >> get the right bytes. But if the external >> representation is changed (and I need to change it), the tests for >> #saveOn: and #restore as such will have >> to be rewritten, while the tests for #saveOn: and #restore *together* will not. >> >> Cucumber offers an insight here, I think. A scenario in Gherkin is >> not a test case for an object. >> Nor is it a test case for a method. It is a test case for a composite >> *behaviour* of a system, >> at some contextually appropriate level of detail. >> >> Brian Marick had some lovely stickers. One of them reads "An example >> would be handy about now." >> >> I note that your blog post *did* provide an example of testing Date. >> In which none of your test cases used 'subject'. >> I entirely agree with you that the three methods have good >> intention-revealing names. >> What we actually need is some examples where 'subject' pays off. >> >> >> >> On Mon, 20 Jan 2025 at 04:04, Koen De Hondt >> <koen(a)all-objects-all-the-time.st> wrote: >> > >> > Dear Pharo users and developers, >> > >> > In my series of blog posts on testing, I added a follow-up post about a dedicated name for the object under test in SUnit tests, the âsubject". >> > >> > Happy reading! >> > >> > Ciao, >> > Koen >> >

Feb. 4, 2025

Re: "Subject in SUnit Tests" â New blog post on all: objects all: theTime

by Russ Whaley

Folks, I really appreciate (and learn from) these types of conversations - especially on testing where I struggle for consistency and completeness. I tend to agree that my testing focuses on methods, however the majority of my âfailuresâ revolve around insufficient object values that eventually have my tests failing - Iâve defaulted to generating âdataâ as randomly as I can early on, however non-realistic, and running tests a few thousand times to point out assumptions I make in my methods. Thanks for discussions! Russ Whaley whaley.russ(a)gmail.com On Thu, Jan 23, 2025 at 5:02â¯AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > This makes the assumption that there is, most of the time, a single, > unique, object that the test is clearly about. > I hasten to admit that my unit testing practice needs a lot to be desired. > But it has not been my experience that there *is* any such object much > of the time. > For example, to test a method, I will sometimes create two equal > objects, manipulate one of them in the > old trusted way, manipulate the other in the new way, and then see if > the objects are equal again. > Which then is *the* subject? > The answer is neither, because what the test is *about* is not an > object, but a method. > Or again, I open a stream to a new file, create a complex object, > persist it on the stream, close > the stream, open another stream reading from the file, reconstitute an > object from it, and then > check that the two objects are isomorphic. Which is *the* subject? > Neither, because what I am testing is the encoding and decoding > methods, not the objects. > > The key paragraph is this one: > <quote> > One could argue that there is not always a single object under test. > In some situations that is correct, for instance when testing the > interaction between objects. But in my experience, most unit tests > have a single object under test. > </quote> > > And it is *this* that we really need a blog post on. I am very ready > to believe that you are a much better tester than I am. > (That wouldn't be hard.) But *something* interesting is going on when > I think in terms of testing classes and methods to > the point where I find the idea of testing a particular object almost > incomprehensible, yet you think this is the norm. > I take some comfort from the fact that the Gherkin language in > Cucumber (and why oh which has nobody bothered to > write down a proper grammar, let alone even an informal semantics, for > it? How am I supposed to know what is and what > is not legal Gherkin?) goes out of its way to conceal the existence > of subjects, should they exist, from test reviewers, and > calls what a test is about a "feature". > > Here are two tests for the Quaternion class: > testMultiplicationByScalarCommutes > sampleExactScalars do: [:x | > sampleExactQuaternions do: [:y | > self assert: (x*y) = (y*x)]]. > > testMultiplicationOfPowersCommutes > sampleExactQuaternions do: [:x | > |y z| > y := x squared. > z := x cubed. > self assert: (y*z) = (z*y)]. > > These two methods test important properties of the #* method. > > Here's another one, part of testing the test data.. > > testExactScalarsAreExactScalars > sampleExactScalars do: [:each | > self assert: each isScalar. > self assert: each isExact]. > > This tests the *methods* #isScalar and #isExact, and indirectly the > code that generates the test data. > It's not about any particular object. Nor is it about *one* method. > It's very hard to write a test case that > tests only one method. In fact my own rather embarrassing experience > is that when a test case of mine > failed it quite often wasn't the method I thought I was testing that > was wrong. Returning to the > persistence example, it's not testing #saveOn: (object saveOn: > byteStream) or #restore (byteStream restore). > It's testing that the two methods are properly related. It would be > wrong to call it #testSaveOn: and it > would be wrong to call it #testRestore. There's a distinction here: > it *is* possible to write methods to test > #saveOn: by itself, by writing various objects and checking that you > get the right bytes. But if the external > representation is changed (and I need to change it), the tests for > #saveOn: and #restore as such will have > to be rewritten, while the tests for #saveOn: and #restore *together* will > not. > > Cucumber offers an insight here, I think. A scenario in Gherkin is > not a test case for an object. > Nor is it a test case for a method. It is a test case for a composite > *behaviour* of a system, > at some contextually appropriate level of detail. > > Brian Marick had some lovely stickers. One of them reads "An example > would be handy about now." > > I note that your blog post *did* provide an example of testing Date. > In which none of your test cases used 'subject'. > I entirely agree with you that the three methods have good > intention-revealing names. > What we actually need is some examples where 'subject' pays off. > > > > On Mon, 20 Jan 2025 at 04:04, Koen De Hondt > <koen(a)all-objects-all-the-time.st> wrote: > > > > Dear Pharo users and developers, > > > > In my series of blog posts on testing, I added a follow-up post about a > dedicated name for the object under test in SUnit tests, the âsubject". > > > > Happy reading! > > > > Ciao, > > Koen > > >

Feb. 3, 2025

Re: About String and Symbol equality

by Richard O'Keefe

Not that anyone else probably cares, but the ANSI standard says - for All objects x y, x = y if and only if y = x. The Smalltalk-80 mixup over String and Symbol violated this, âXâ = #x but #x ~= âxâ. - two sequences are = iff they are the same size, corresponding elements are =, AND they are instances of the same class. - String is not a special case. I note that this definition, which was a break with tradition, was agreed by all Smalltalk vendors and some famous industry representatives more than 25 years ago, which should have given people time to catch up. I do appreciate that the developers of Squeak had other maddened grizzly bears to stun, but given the confusion, anyone who used strings and symbols as elements of the same set or keys of the same dictionary was already in for a lot of pain when they tried to port their code. Any code badly affected by the proposed change was already broken (because symol equality is temporally stable and string equality isnât, among other things). Trying to support both the broken traditional and the corrected ANSI definition at the same times like a lot of effort. How would that work? On Mon, 3 Feb 2025 at 6:36â¯AM, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > Hello people > > In Pharo (following Squeak tradition) a string is equals to its symbol > representation. > e.g. > âtintinâ = #tintin > > true > > In other Smalltalk dialects this is not the case. > > We have been working (sponsored by Lifeware) to support both semantics > (yes this is a kind of > daunting task and it can raise bugs). > > Our objective is to help people make business with Pharo. So âsimpleâ > cross compatibility is something that we consider e.g. to deploy > applications in Gemstone for example. > (We would love to have a Pharo compiler working on Gemstone generating > Gemstone VM bytecodes this is why we love the work of James Foster but this > is another story). > > So since we are pragmatic people we could be convinced that the semantics > of Pharo is not good :) > and that by default we should use the semantics of GS or VW. > > The first step is to be able to choose which one to use within Pharo and > be able to switch. > We are nearly there for Pharo 13. > > The second step is to get a nice default. > And we need the help of the community for this. > > Do you have any advice, arguments for and against any of the two choices > that could be put on the table to influence our decisions for Pharo 14. > > So let us know :) > > Stef on the behalf of the Pharo consortium. > > > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > 06 30 93 66 73 > > "If you knew today was your last day on earth, what would you do > differently? ....ESPECIALLY if, by doing something different, today > might not be your last day on earth.â Calvin & Hobbes > > > > > >

Feb. 3, 2025

Re: [Pharo-dev] About String and Symbol equality

by Aik-Siong Koh

How did Pharo diverge from the other Smalltalks? Was it a good decision? stephane ducasse wrote: > Hello people > > In Pharo (following Squeak tradition) a string is equals to its symbol > representation. > e.g. > âtintinâ = #tintin > > true > > In other Smalltalk dialects this is not the case. > > We have been working (sponsored by Lifeware) to support both semantics > (yes this is a kind of > daunting task and it can raise bugs). > > Our objective is to help people make business with Pharo. So âsimpleâ > cross compatibility is something that we consider e.g. to deploy > applications in Gemstone for example. > (We would love to have a Pharo compiler working on Gemstone generating > Gemstone VM bytecodes this is why we love the work of James Foster but > this is another story). > > So since we are pragmatic people we could be convinced that the > semantics of Pharo is not good :) > and that by default we should use the semantics of GS or VW. > > The first step is to be able to choose which one to use within Pharo > and be able to switch. > We are nearly there for Pharo 13. > > The second step is to get a nice default. > And we need the help of the community for this. > > Do you have any advice, arguments for and against any of the two > choices that could be put on the table to influence our decisions for > Pharo 14. > > So let us know :) > > Stef on the behalf of the Pharo consortium. > > > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > 06 30 93 66 73 > > "If you knew today was your lastÂ day on earth, what wouldÂ youÂ do > differently? ....ESPECIALLYÂ if, by doing somethingÂ different,Â today > mightÂ notÂ be your last dayÂ on earth.â CalvinÂ & Hobbes > > > > >

Feb. 3, 2025