December 2024 - Pharo-users

Re: [Pharo-dev] 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

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

by Richard O'Keefe

The difference between âexampleâ and âtestâ is trivial, except that Smalltalk already uses âexampleâ for, well, examples. Sample code that is intended to be read and imitated, not run for testing. The difference between âexpectâ and âassertâ is that âexpectâ asserts what to expect while âassertâ asserts what to expect. I hope that is clear. A ârich expectation languageâ doesnât strike me as a virtue. It has been a long time since I regarded ârich formatting languagesâ like Fortran or Common Lisp have as a good idea. Give me the basic building blocks I can freely combine using my existing programming language. Indeed, that was one of the great merits of sUnit: if you understand Smalltalk you understand the test cases without having to learn a whole ânother ârich languageâ. As for the logging, there are two fairly clear issues. Nothing stops you constructing such logs in Smalltalk. We could add a suitable âself log: textâ message to sUnit, which would make localisation easier. We could use pragmas. But the second point is that nothing ensuresthat such messages are true or accurate. For example, #pop DOESNâT remove the last item added to a stack, and whatâs more it shouldnât. It removes the most recently added REMAINING item, which is not at all the same thing. As for âsubjectâ, just as test cases normally check mutual consistency of multiple methods, so it is not unusual for a test case to relate to multiple objects. For example, to test the #copy method of some class, I might make an instance, copy it, change one of the copies, and check that the other did not change. Which one is *the* subject? I like a programming language that makes me think, but not one that tries to tell me how to think. Comparing RSpec with sUnit, I feel that RSpec is trying to canalise my thinking, while sUnit offers me possibilities. Above all, sUnit lets me extend it without drama. On Mon, 30 Dec 2024 at 5:01â¯AM, Koen De Hondt <koen(a)all-objects-all-the-time.st> wrote: > 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. 31, 2024

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

by Richard O'Keefe

First, automated test running was common practice in software engineering. We were doing it with shell scripts at my company back in 1985. And of course this is precisely what âexpectâ was written for, and itâs why tools like tcov/xcov exist for conventionallanguages like C. SUnit just made it *easy* . Second, why would anyone *expect* a one to one correspondence between method names and test method names? Where is it written that a test case tests or indeed can test only one method? Take a trivial example like testThatAddAdds |x m| x := testClass withAll: #(1 2 3 5). m := x size. x add: 4. self assert: x size equals: m+1. (Typed on a tablet, so pretty rough. Sorry.) Does this test #add: or #size? Iâve known tests like thisto find faults in #withAll: and in one memorable case #+ . If you want to document a link to what youâre testing, use a pragma. <test: #consistency of: #add: with: #size> and set up your UI to realize that this is a test of BOTH #add: and #size so that it should be rerun if either of them changes. On Sat, 23 Nov 2024 at 2: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 > <https://all-objects-all-the-time.st/#/blog/posts/10>. > > Enjoy reading it! > > Ciao, > Koen > >

Dec. 31, 2024

Re: Need Help with Changing Message Sends in Compiled Blocks

by Tim Mackinnon

Iâm not totally clear on what you are trying to do, but have you looked at the rewrite tool, that is meant for this kind of thing? The online help is reasonable good for this and there are quite a few msgs here describing it. You should be able to match the change you want and also limit the scope of the change, Tim > On 30 Dec 2024, at 12:56, Sebastian Jordan <sebastian.jordan(a)inria.fr> wrote: > > ï»¿TL;DR: I need help changing the message OrderedCollection new to OrderedCollection --> newTenured <-- at a specific offset in a compiled block. I can do this for regular methods, but I get an error when the method is a Block. > > Hello everyone, > > I'm trying to automatically change message sends in my code, but I'm having trouble with compiled blocks. > For example, I want to change the message OrderedCollection new to OrderedCollection --> newTenured <-- in a specific method. I have the compiled block and the offset (26) for the message I want to change. However, searching for the selector new doesn't work because there can be multiple messages with the same name, and I only want to change the one at the given offset. > > theMethod > > | tmp1 | > 1 = tmp1 something: [ "rewrite this message send" OrderedCollection new ]. > tmp1 otherStruf: [ Dictionary new "do not rewrite this meesage send" ]. > ^ self > > > I can change the message when there is no block without any problem using the IR like this: > > transformMessageSend: compiledMethodOrBlock offset: offset > > | oldSelector newSelector irSendNode ir irSequences | > oldSelector := (compiledMethodOrBlock sourceNode sourceNodeForPC: offset) selector. > newSelector := self makeNewSelector: oldSelector. > > ir := compiledMethodOrBlock ir. > irSequences := ir allSequences flatCollect: #children. > irSendNode := (irSequences select: #isSend) detect: [ :e | e selector = oldSelector ]. > irSendNode selector: newSelector. > > ^ ir generate > selector: compiledMethodOrBlock selector; > yourself > > > But I get an error with ir generate when the compiledMethodOrBlock is a Block. If it's a normal compiled method, it works as expected. > Can anyone help me with this? Thanks! > > PS: I'm not forced to do it with the IR, ir can be done by using the AST. The only thing is that I'd like to avoid doing string manipulation > > Cheers and merry christmas, > Sebastian Jordan

Dec. 30, 2024

Need Help with Changing Message Sends in Compiled Blocks

by Sebastian Jordan

TL;DR: I need help changing the message OrderedCollection new to OrderedCollection --> newTenured <-- at a specific offset in a compiled block. I can do this for regular methods, but I get an error when the method is a Block. Hello everyone, I'm trying to automatically change message sends in my code, but I'm having trouble with compiled blocks. For example, I want to change the message OrderedCollection new to OrderedCollection --> newTenured <-- in a specific method. I have the compiled block and the offset (26) for the message I want to change. However, searching for the selector new doesn't work because there can be multiple messages with the same name, and I only want to change the one at the given offset. theMethod | tmp1 | 1 = tmp1 something: [ "rewrite this message send" OrderedCollection new ]. tmp1 otherStruf: [ Dictionary new "do not rewrite this meesage send" ]. ^ self I can change the message when there is no block without any problem using the IR like this: transformMessageSend: compiledMethodOrBlock offset: offset | oldSelector newSelector irSendNode ir irSequences | oldSelector := (compiledMethodOrBlock sourceNode sourceNodeForPC: offset) selector. newSelector := self makeNewSelector: oldSelector. ir := compiledMethodOrBlock ir. irSequences := ir allSequences flatCollect: #children. irSendNode := (irSequences select: #isSend) detect: [ :e | e selector = oldSelector ]. irSendNode selector: newSelector. ^ ir generate selector: compiledMethodOrBlock selector; yourself But I get an error with ir generate when the compiledMethodOrBlock is a Block. If it's a normal compiled method, it works as expected. Can anyone help me with this? Thanks! PS: I'm not forced to do it with the IR, ir can be done by using the AST. The only thing is that I'd like to avoid doing string manipulation Cheers and merry christmas, Sebastian Jordan

Dec. 30, 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: [Pharo-dev] "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

2nd CfP: SLE 2025 - 18th ACM SIGPLAN International Conference on Software Language Engineering

by Andrei Chis

18th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2025) 12-13 June 2025 Koblenz, Germany https://www.sleconf.org/2025/ https://x.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE) which is devoted to the principles of software languages: their design, their implementation, and their evolution. The SLE 2025 conference will be co-located with STAF 2025 and hosted in Koblenz, Germany, on 12-13 June 2025. --------------------------- Important Dates --------------------------- * Abstract submission: Fri 7 Feb 2025 * Paper submission: Fri 14 Feb 2025 * Authors response period: Tue 1 Apr - Sat 5 Apr 2025 * Notification: Tue 15 Apr 2025 * Conference: Thu 12 June - Fri 13 June 2025 (co-located with STAF) All dates are Anywhere on Earth. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - AI-assisted language design and optimisation * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Model-based testing - AI-assisted validation * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - AI-assisted refactoring * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and emerging/promising research areas - Generative AI in language engineering (e.g., AI-based language modelling, AI-driven code generation tools) - AI and ML language engineering (e.g., ML compiler testing, code classification) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: * Research papers: These are âtraditionalâ papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. * New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. * SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. In this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations, and case study papers on the SLE topics. These can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. * Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. Workshops: Workshops will be organised by STAF. Please inform us and contact STAF 2025 organisers if you would like to organise a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the STAF 2025 Website. --------------------------- Submission --------------------------- SLE 2025 has a single submission round for papers, including a mandatory abstract registration and a rebuttal phase, where all authors of research papers will have the possibility of responding to the reviews on their submissions. Authors of accepted research papers will be invited to submit artefacts. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format âacmartâ ( https://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colours remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authorsâ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle25.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLANâs Republication Policy ( https://www.sigplan.org/Resources/Policies/Republication/) Submitters should also be aware of ACMâs Policy and Procedures on Plagiarism ( https://www.acm.org/publications/policies/plagiarism-overview) Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACMâs general principles, as stated in the ACMâs Publications Policy on Research Involving Human Participants and Subjects ( https://www.acm.org/publications/policies/research-involving-human-particip…) If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. SLEBoK papers will be reviewed on their soundness, relevance, originality, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. For research papers, authors will get a chance to respond to the reviews before a final decision is made. --------------------------- Artefact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artefacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artefacts. --------------------------- Awards --------------------------- * Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished artefact: Award for the artefact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artefact evaluation committee. * Distinguished reviewer: Award for the programme committee member that produced the most useful reviews as assessed by paper authors. * Most Influential Paper: Award for the SLE 2015 paper with the greatest impact, as judged by the SLE Steering Committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Organisation --------------------------- * General chair: GÃ¶rel Hedin, Lunds Universitet, Sweden * PC co-chair: Regina Hebig, UniversitÃ¤t Rostock, Germany * PC co-chair: Vadim Zaytsev, Universiteit Twente, The Netherlands * Publicity chair: Andrei ChiÅ, feenk gmbh, Switzerland * Local chair: Ralf LÃ¤mmel, UniversitÃ¤t Koblenz, Germany --------------------------- Contact --------------------------- For additional information, clarification, or answers to any questions, please get in touch with the program co-chairs (regina.hebig(a)uni-rostock.de and vadim(a)grammarware.net)

Dec. 20, 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