- Pharo-dev - lists.pharo.org

Re: Pharo Launcher & Monticello & Code Repositories

by stephane ducasse

Hi benoit happy new year and sorry not seeing your email before > On 12 Nov 2024, at 18:31, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > 1) I've been using Pharo Launcher 3.2 on Windows 10 for a while and it seems like there's a problem with launching images starting with version 11. It just doesn't work. Any hint? Can you provide more information so that we can see what we can do. > 2) On a totally different subject, is there a package to be able load the Monticello Browser tool back into the image starting with Pharo 11? It's really annoying to deprive users from easily loading code from all the repos still using the Monticello format! I do not know. We do not support mcz loading. We sincerely understand that it can be painful but we cannot rewrite all the old tools. Embrace Git and Iceberg is a super nice tool for that. We are working on removing morphic and this is a large effort. If you want I can pair program with you to port one of your projects to github. > 3) Finally, is there a preferred ***central*** repository to store Pharo code? Something like Squeaksource was, or RubyGems (for Ruby) or Cincom Public Repository (VisualWorks Smalltalk) ? We always wanted to do that but we got stuck launching a market place. The idea is that you publish your code anywhere you want on github, gitlabâ¦. and you publish a description of such project in the marketplace. We did not have the manpower to launch this project. If you want to help we can tell you what we designed: the simplest thing that could work - a git repo. Now christophe should have the information somewhere. S

Jan. 7, 2025

Re: [Pharo-users] "Evaluation of SUnit" â New blog post on all: objects all: theTime

by stephane ducasse

Thanks for sharing it with us. It is great! > 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 >> 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

Jan. 7, 2025

Re: Cannot commit to github in Pharo12

by Aik-Siong Koh

Jan. 6, 2025

Re: Cannot commit to github in Pharo12

by Cyril FERLICOT-DELBECQUE

This is weird because this error happens if a class is exported with the Tonel format in a package (aka a Folder) but has a different package in the metadata of the class. But here I'm checking the repo and things seems good [image.png] The folder is StCad-Geo and the category is StCad-Geo-GEO (which is the tag also). >From the debugger you got I was expecting this class to have StMath-GEO as category... -- Cyril Ferlicot-Delbecquehttps://ferlicot.fr On Friday, January 3rd, 2025 at 10:58 PM, Aik-Siong Koh <askoh(a)askoh.com> wrote: > In Pharo12, I click/Sources/Git Repository Browser/ > In the Git Repository Browser, I see > *SuperApp Uncommitted changes, 1 incoming, 1 main > I Select/SuperApp. > RightClick/Commit/ > I get the following error. Please advise. > Thanks. > Aik-Siong Koh

Jan. 6, 2025

Re: Cannot commit to github in Pharo12

by Aik-Siong Koh

Guillermo: Thank you very much for helping. https://github.com/aiksiongkoh/SuperApp Aik-Siong Koh Guillermo Polito wrote: > Hi Aik-Siong Koh, > > would you please share with us: > > - the repository if open source > - some instructions to reproduce > > G > >> Le 3 janv. 2025 Ã 10:58â¯PM, Aik-Siong Koh <askoh(a)askoh.com> a Ã©crit : >> >> In Pharo12, I click/Sources/Git Repository Browser/ >> In the Git Repository Browser, I see >> *SuperApp Uncommitted changes, 1 incoming, 1 main >> I Select/SuperApp. >> RightClick/Commit/ >> I get the following error. Please advise. >> Thanks. >> Aik-Siong Koh >> <mnhmbfjhogmnehhc.png>

Jan. 6, 2025

Re: Cannot commit to github in Pharo12

by Guillermo Polito

Hi Aik-Siong Koh, would you please share with us: - the repository if open source - some instructions to reproduce G > Le 3 janv. 2025 Ã 10:58â¯PM, Aik-Siong Koh <askoh(a)askoh.com> a Ã©crit : > > In Pharo12, I click/Sources/Git Repository Browser/ > In the Git Repository Browser, I see > *SuperApp Uncommitted changes, 1 incoming, 1 main > I Select/SuperApp. > RightClick/Commit/ > I get the following error. Please advise. > Thanks. > Aik-Siong Koh > <mnhmbfjhogmnehhc.png>

Jan. 6, 2025

Cannot commit to github in Pharo12

by Aik-Siong Koh

In Pharo12, I click/Sources/Git Repository Browser/ In the Git Repository Browser, I see *SuperApp Uncommitted changes, 1 incoming, 1 main I Select/SuperApp. RightClick/Commit/ I get the following error. Please advise. Thanks. Aik-Siong Koh

Jan. 3, 2025

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