December 2024 - Pharo-dev - lists.pharo.org

Re: "Evaluation of SUnit" â New blog post on all: objects all: theTime

by Yanni Chiu

Hi Koen, I understand that as a writer, something like âNobody thought about automatingâ¦â does more to draw a reader in to reading more of the article, than something like âNobody had ever published a public domain framework that â¦â. As your reply says, your intended meaning may be âpublished â¦ for the first timeâ, but I think very few readers would take that meaning. In my own experience, automated testing was a concept I encountered from earlier programmers, and Richardâs post also confirms that automated testing was commonly known. Youâre right about the âopen sourceâ environment of the early 90âs. Employees/programmers were unlikely to publish code into the public domain at that time. I think Kent was in a unique position to tour various Smalltalk teams, distill out key processes and techniques, and publish about it. SUnit is a great distillation of the idea. The actual unit test framework code is not the key idea. People knew of using automated test suites. But flipping to another browser and adding a #testZZZ method, while coding for your development task, is something that seems to just emerge from the Smalltalk environment - once you determine that you want to have a test suite to help you code. Previously, some statically defined test suite, perhaps written by others, is used to verify code. By putting the #testZZZ definitions in the hands of the developer, the whole waterfall coding model is upended. Regards, Yanni On Sun, Dec 29, 2024 at 10:44 AM Koen De Hondt < koen(a)all-objects-all-the-time.st> wrote: > Hi Yanni, > > Thank you for sharing your story. It gives another view on history. Maybe > you should share it with a wider audience. > > As always, the people publishing about something for the first time get > the credits. > > When I wrote "Nobody thought about automating that process. Until Kent > Beck did.â, I meant that he was the one who published about SUnit for the > first time (and that is why I linked to the publication). I am sure that > many other people, like you and George, had tools to automate tests, in one > form or another. After all, Smalltalkers build their own tools to automate > repetitive tasks. That is a super power Smalltalkers have compared to > developers using other programming languages. > > You write about 1993. Back then, it was hard to share > code/projects/software with the world. These days, people put their code in > a public repo. But still that does not prove that the underlying ideas are > original. It just proves that they did something creative with those ideas, > just like in 1993. But at least it is clear for the rest of the community > who is building software based on those ideas. > > So I think publishing work â even early work â, in the form of code or > written documents, is crucial to keep a trace of where ideas originate. > > Thanks again for sharing. I like stories about the history of software > development and I enjoyed your story. > > Best regards, > Koen > > > On 22 Nov 2024, at 23:10, Yanni Chiu <yannix7db(a)gmail.com> wrote: > > > > The blog post has "Nobody thought about automating that process. Until > > Kent Beck did." That is not accurate, AFAIK. I believe it was in Kent > > Beck's original EXtreme Programming book where he says the practices > > were gathered from various Smalltalk shops he consulted at during the > > Smalltalk heyday in the early 90's. > > > > For what it's worth, here's the history I know. Around 1993, in > > Toronto, I was working at Footprint Software on VisualBanker (a suite > > of code to support banking that 4 of the 5 major Canadian banks > > bought). With my programming buddy (no "pair programming" at the time) > > our task was to build a persistence framework (supporting Relational, > > ObjectFiler, and in-memory). > > > > My task in a previous job was to convert (the AT&T Unix) C compiler to > > support the "new" ANSI C standard. Thankfully, I was provided with a > > test suite of C code, so that if it compiled without errors, then the > > compiler was standard compliant. So, looking for something similar to > > the ANSI C test suite I'd encountered, I set up test cases where all > > methods starting with "test" would be run, and ran the tests against > > all the backend data stores. The next day, my programming buddy > > (George), who started at 6am (to have a faster commute) tells me this > > test thing is great, and shows me the UI he built so we could just > > push a button. We can check the same behaviour for all backends, and > > we can coordinate our code changes through the tests (to mitigate our > > different schedule). > > > > A year later, the company's product was deemed slow, so they > > contracted Kent Beck to review our code base. He eventually comes > > around to us. We showed him what we did with tests, and then he just > > paused for about a minute staring out the window. We thought we were > > doing something really bad. A few months later, George said to me "did > > you see the SUnit thing posted on comp.lang.smalltalk". The basic > > "test"-prefixed test cases were there, but with the addition of the > > setUp and tearDown concept. > > > > Every once in a while I think to write this up. The "Nobody thought > > about automating..." words pushed me over this time. Maybe 15 years > > ago, I was able to find the original comp.lang.smalltalk SUnit > > posting, but could not locate it this time when I wanted to verify the > > dates. > > > > Yanni Chiu, > > Smalltalk oldtimer, Toronto > > > > On Fri, Nov 22, 2024 at 8:58â¯AM Koen De Hondt > > <koen(a)all-objects-all-the-time.st> wrote: > >> > >> Dear Pharo users and developers, > >> > >> I wrote a blog post in which I evaluate SUnit. > >> > >> Enjoy reading it! > >> > >> Ciao, > >> Koen > >> >

Dec. 31, 2024

"Comparing SUnit with RSpec" â New blog post on all: objects all: theTime

by Koen De Hondt

Dear Pharo users and developers, After my previous blog post on SUnit, I added a follow-up post <https://all-objects-all-the-time.st/#/blog/posts/11> on the comparison of SUnit and RSpec for Ruby. Happy reading! This will be my last post for 2024. Happy holidays and all the best for 2025. Ciao, Koen

Dec. 29, 2024

Re: "Evaluation of SUnit" â New blog post on all: objects all: theTime

by Koen De Hondt

Hi Yanni, Thank you for sharing your story. It gives another view on history. Maybe you should share it with a wider audience. As always, the people publishing about something for the first time get the credits. When I wrote "Nobody thought about automating that process. Until Kent Beck did.â, I meant that he was the one who published about SUnit for the first time (and that is why I linked to the publication). I am sure that many other people, like you and George, had tools to automate tests, in one form or another. After all, Smalltalkers build their own tools to automate repetitive tasks. That is a super power Smalltalkers have compared to developers using other programming languages. You write about 1993. Back then, it was hard to share code/projects/software with the world. These days, people put their code in a public repo. But still that does not prove that the underlying ideas are original. It just proves that they did something creative with those ideas, just like in 1993. But at least it is clear for the rest of the community who is building software based on those ideas. So I think publishing work â even early work â, in the form of code or written documents, is crucial to keep a trace of where ideas originate. Thanks again for sharing. I like stories about the history of software development and I enjoyed your story. Best regards, Koen > On 22 Nov 2024, at 23:10, Yanni Chiu <yannix7db(a)gmail.com> wrote: > > The blog post has "Nobody thought about automating that process. Until > Kent Beck did." That is not accurate, AFAIK. I believe it was in Kent > Beck's original EXtreme Programming book where he says the practices > were gathered from various Smalltalk shops he consulted at during the > Smalltalk heyday in the early 90's. > > For what it's worth, here's the history I know. Around 1993, in > Toronto, I was working at Footprint Software on VisualBanker (a suite > of code to support banking that 4 of the 5 major Canadian banks > bought). With my programming buddy (no "pair programming" at the time) > our task was to build a persistence framework (supporting Relational, > ObjectFiler, and in-memory). > > My task in a previous job was to convert (the AT&T Unix) C compiler to > support the "new" ANSI C standard. Thankfully, I was provided with a > test suite of C code, so that if it compiled without errors, then the > compiler was standard compliant. So, looking for something similar to > the ANSI C test suite I'd encountered, I set up test cases where all > methods starting with "test" would be run, and ran the tests against > all the backend data stores. The next day, my programming buddy > (George), who started at 6am (to have a faster commute) tells me this > test thing is great, and shows me the UI he built so we could just > push a button. We can check the same behaviour for all backends, and > we can coordinate our code changes through the tests (to mitigate our > different schedule). > > A year later, the company's product was deemed slow, so they > contracted Kent Beck to review our code base. He eventually comes > around to us. We showed him what we did with tests, and then he just > paused for about a minute staring out the window. We thought we were > doing something really bad. A few months later, George said to me "did > you see the SUnit thing posted on comp.lang.smalltalk". The basic > "test"-prefixed test cases were there, but with the addition of the > setUp and tearDown concept. > > Every once in a while I think to write this up. The "Nobody thought > about automating..." words pushed me over this time. Maybe 15 years > ago, I was able to find the original comp.lang.smalltalk SUnit > posting, but could not locate it this time when I wanted to verify the > dates. > > Yanni Chiu, > Smalltalk oldtimer, Toronto > > On Fri, Nov 22, 2024 at 8:58â¯AM Koen De Hondt > <koen(a)all-objects-all-the-time.st> wrote: >> >> Dear Pharo users and developers, >> >> I wrote a blog post in which I evaluate SUnit. >> >> Enjoy reading it! >> >> Ciao, >> Koen >>

Dec. 29, 2024

files.pharo.org scheduled downtime

by Christophe Demarey

Dear Pharo users, We would like to inform you that the files.pharo.org service will be unavailable due to an electrical maintenance intervention in the server room. Downtime Schedule (CET): Start: Thursday, January 2nd, 6:00 PM End: Friday, January 3rd, 10:00 AM We apologize for any inconvenience this may cause and thank you for your understanding. Best regards, The Pharo team Ps: Pharo Launcher and smalltalk-ci uses this service to get fresh Pharo images.

Dec. 23, 2024

Pharo News of the Week 51/2024

by Marcus Denker

# Pharo News of the Week 51/2024 - [ANN] pharox-dependency-visualizer: This tool helps understand/untangle dependencies https://github.com/ironirc/pharox-dependency-visualizer - [ANN] A Pharo/Bloc port of the example code from The Nature of Code book by Daniel Shiffman https://github.com/lucretiomsp/nature-of-code-pharo - [ANN] Pharo UFFI binding with the rtmidi library https://github.com/ironirc/pharo-rtmidi - [ANN] Poster from Audio Developer Conference 2024: "Phausto: fast and accessible DSP programming in Pharo" https://hal.science/hal-04813572v1/file/ADC2024-poster.pdf The weekly newsletter takes a break for the rest of the year. We wish already a happy new year and will be back in the second week of January.! # The week on the Pharo Issue Tracker # Pharo 12 - Fix compiler literals p12 #17532 https://github.com/pharo-project/pharo/pull/17532 # VM - Fixes for 10.3.2 #885 https://github.com/pharo-project/pharo-vm/pull/885 - Enhancement(versionning): Extract full semantic version from git #884 https://github.com/pharo-project/pharo-vm/pull/884 # Features - Breakpoints in debugger #920 https://github.com/pharo-spec/NewTools/pull/920 - Sorting items in bag inspector by default #915 https://github.com/pharo-spec/NewTools/pull/915 - Using the dedicated pointers to image #1647 https://github.com/pharo-spec/Spec/pull/1647 # Fixes - Fix: #17531: We can use string instead of symbols in slot in class definition #17531 #17537 https://github.com/pharo-project/pharo/pull/17537 - fix-SDL-default-renderer-by-platform #17517 https://github.com/pharo-project/pharo/pull/17517 # Refactoring Engine - Fix RBClassRegexRefactoring #17552 https://github.com/pharo-project/pharo/pull/17552 - rename asMethodPreamble (dated concept) to asMethodSignature #17547 https://github.com/pharo-project/pharo/pull/17547 - fix #17543: [RB] Comment on RBClassRegexRefactoring and superclass is wrong #17545 https://github.com/pharo-project/pharo/pull/17545 - Cleaning ReDriver #17541 https://github.com/pharo-project/pharo/pull/17541 - Fixing the rename from call site. #17536 https://github.com/pharo-project/pharo/pull/17536 # Compiler - Fix: #17524 MOve OCASTSemanticCleaner to its only user: Reflectivity #17546 https://github.com/pharo-project/pharo/pull/17546 - improve comment of private method scanToken #17539 https://github.com/pharo-project/pharo/pull/17539 - Deprecate IRFix #17538 https://github.com/pharo-project/pharo/pull/17538 - Improving opal comment4 #17530 https://github.com/pharo-project/pharo/pull/17530 - Better comment in opal #17526 https://github.com/pharo-project/pharo/pull/17526 - Deprecate RBParser and RBPatternParser. #17514 https://github.com/pharo-project/pharo/pull/17514 # Comments - Better class comment for commentTestCase #17540 https://github.com/pharo-project/pharo/pull/17540

Dec. 20, 2024

Pharo News of the Week 50/2024

by Marcus Denker

# Pharo News of the Week 50/2024 - [ANN] MasterLu is your electronic music teacher in Pharo: https://github.com/lucretiomsp/MasterLu - [ANN] ESUG 2024: Show Us Your Project playlist https://www.youtube.com/playlist?list=PLJ5nSnWzQXi89jwnBCmGPh9xG6shuvuwb # The week on the Pharo Issue Tracker # Fixes - Fix crash of Mac on 4K display #17496 https://github.com/pharo-project/pharo/pull/17496 - Adding fallback code in the allocation primitives basicNewTenured, basicNewTenured: #17492 https://github.com/pharo-project/pharo/pull/17492 - DynamicLoader: unsing LoadLibraryW instead old LoadLibrary in windows #17479 https://github.com/pharo-project/pharo/pull/17479 - Fix #17471: custom Job interruption #17474 https://github.com/pharo-project/pharo/pull/17474 # VM - Fixes for 10.3.2 #885 https://github.com/pharo-project/pharo-vm/pull/885 - Enhancement(versionning): Extract full semantic version from git #884 https://github.com/pharo-project/pharo-vm/pull/884 # Refactoring Engine - Created new driver for tempToIV refactoring #17490 https://github.com/pharo-project/pharo/pull/17490 - Deprecate RBParser and RBPatternParser. #17514 https://github.com/pharo-project/pharo/pull/17514 # CI - Skip some socket tests on windows #17498 https://github.com/pharo-project/pharo/pull/17498 - Fix release tests #17497 https://github.com/pharo-project/pharo/pull/17497 # Documentation - Update README.md #919 https://github.com/pharo-spec/NewTools/pull/919

Dec. 13, 2024

Re: [Pharo-vm] New VM Release v10.3.2

by Norbert Hartl

> Am 11.12.2024 um 15:51 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi Norbert, the patch has not been merged yet. > > Are we talking about the same? > > the pharo-10 branch still has the issue The PR looks much better. But now I notice that with the compile and install options documented on github the vm in build/dist does not include some libraries, e.g, libcrypto.* libssl.* etc. How is the packaging done for the archives on files.pharo.org? thanks, Norbert > >> Le 11 dÃ©c. 2024 Ã 3:50â¯PM, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : >> >> >> >>> Am 11.12.2024 um 15:19 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> >>> >>>> Am 05.12.2024 um 13:49 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> Also, anybody having a couple of minutes to test and help, if you see this issue locally, could you >>>> - build a VM (https://github.com/pharo-project/pharo-vm/) checking out tag v10.3.2 >>>> - run locally the failing tests >>>> >>>> This information could help us reduce the search space, and identify if itâs just the build environment or there is something else we have to deal with. >>>> >>> It seems you have figured it out. Since I started to compile my own vm I cannot build anything on my jenkins. >>> >>> In order to at least confirm a few things I've built a little infrastructure for me to generate vms in different combinations. I went down the rabbit hole and tried v10.21, v10.3.1 and v10.3.2 under debian 12 and all failed. Then I downgraded gcc to gcc-11 and retried. All are still failing. I read that the gcc 12 and gcc 11 more or less the same in that regard. Sadly it is not easy to go much back from where I am. I need to check on the jenkins and this is based on debian 12. So I could retry with older gccs but I'm not sure what will be the outcome. >>> Right now I'm retrying with pharo-10 HEAD because your commit message sounded it is worth it (well, nothing else works) >>> >> Running a vm from HEAD build let's it live longer but in the end it collapses as well. What is really wild now is that I cannot use the old binaries anymore. I have segfaults there, too. So I'm a bit out of ideas >> >> Norbert >

Dec. 11, 2024

Re: [Pharo-vm] New VM Release v10.3.2

by Norbert Hartl

> Am 11.12.2024 um 15:51 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi Norbert, the patch has not been merged yet. > > Are we talking about the same? > > the pharo-10 branch still has the issue Ah right, I think I got so confused throughout the day that reading the PR made me think it has been merged already. Will try with the PR branch. Norbert > >> Le 11 dÃ©c. 2024 Ã 3:50â¯PM, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : >> >> >> >>> Am 11.12.2024 um 15:19 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> >>> >>>> Am 05.12.2024 um 13:49 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> Also, anybody having a couple of minutes to test and help, if you see this issue locally, could you >>>> - build a VM (https://github.com/pharo-project/pharo-vm/) checking out tag v10.3.2 >>>> - run locally the failing tests >>>> >>>> This information could help us reduce the search space, and identify if itâs just the build environment or there is something else we have to deal with. >>>> >>> It seems you have figured it out. Since I started to compile my own vm I cannot build anything on my jenkins. >>> >>> In order to at least confirm a few things I've built a little infrastructure for me to generate vms in different combinations. I went down the rabbit hole and tried v10.21, v10.3.1 and v10.3.2 under debian 12 and all failed. Then I downgraded gcc to gcc-11 and retried. All are still failing. I read that the gcc 12 and gcc 11 more or less the same in that regard. Sadly it is not easy to go much back from where I am. I need to check on the jenkins and this is based on debian 12. So I could retry with older gccs but I'm not sure what will be the outcome. >>> Right now I'm retrying with pharo-10 HEAD because your commit message sounded it is worth it (well, nothing else works) >>> >> Running a vm from HEAD build let's it live longer but in the end it collapses as well. What is really wild now is that I cannot use the old binaries anymore. I have segfaults there, too. So I'm a bit out of ideas >> >> Norbert >

Dec. 11, 2024

Re: [Pharo-vm] New VM Release v10.3.2

by Guillermo Polito

Hi Norbert, the patch has not been merged yet. Are we talking about the same? the pharo-10 branch still has the issue > Le 11 dÃ©c. 2024 Ã 3:50â¯PM, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > > >> Am 11.12.2024 um 15:19 schrieb Norbert Hartl <norbert(a)hartl.name>: >> >> >> >>> Am 05.12.2024 um 13:49 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Also, anybody having a couple of minutes to test and help, if you see this issue locally, could you >>> - build a VM (https://github.com/pharo-project/pharo-vm/) checking out tag v10.3.2 >>> - run locally the failing tests >>> >>> This information could help us reduce the search space, and identify if itâs just the build environment or there is something else we have to deal with. >>> >> It seems you have figured it out. Since I started to compile my own vm I cannot build anything on my jenkins. >> >> In order to at least confirm a few things I've built a little infrastructure for me to generate vms in different combinations. I went down the rabbit hole and tried v10.21, v10.3.1 and v10.3.2 under debian 12 and all failed. Then I downgraded gcc to gcc-11 and retried. All are still failing. I read that the gcc 12 and gcc 11 more or less the same in that regard. Sadly it is not easy to go much back from where I am. I need to check on the jenkins and this is based on debian 12. So I could retry with older gccs but I'm not sure what will be the outcome. >> Right now I'm retrying with pharo-10 HEAD because your commit message sounded it is worth it (well, nothing else works) >> > Running a vm from HEAD build let's it live longer but in the end it collapses as well. What is really wild now is that I cannot use the old binaries anymore. I have segfaults there, too. So I'm a bit out of ideas > > Norbert

Dec. 11, 2024

Re: [Pharo-vm] New VM Release v10.3.2

by Norbert Hartl

> Am 11.12.2024 um 15:19 schrieb Norbert Hartl <norbert(a)hartl.name>: > > > >> Am 05.12.2024 um 13:49 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Also, anybody having a couple of minutes to test and help, if you see this issue locally, could you >> - build a VM (https://github.com/pharo-project/pharo-vm/) checking out tag v10.3.2 >> - run locally the failing tests >> >> This information could help us reduce the search space, and identify if itâs just the build environment or there is something else we have to deal with. >> > It seems you have figured it out. Since I started to compile my own vm I cannot build anything on my jenkins. > > In order to at least confirm a few things I've built a little infrastructure for me to generate vms in different combinations. I went down the rabbit hole and tried v10.21, v10.3.1 and v10.3.2 under debian 12 and all failed. Then I downgraded gcc to gcc-11 and retried. All are still failing. I read that the gcc 12 and gcc 11 more or less the same in that regard. Sadly it is not easy to go much back from where I am. I need to check on the jenkins and this is based on debian 12. So I could retry with older gccs but I'm not sure what will be the outcome. > Right now I'm retrying with pharo-10 HEAD because your commit message sounded it is worth it (well, nothing else works) > Running a vm from HEAD build let's it live longer but in the end it collapses as well. What is really wild now is that I cannot use the old binaries anymore. I have segfaults there, too. So I'm a bit out of ideas Norbert

Dec. 11, 2024