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

This week (06/2024) on the Pharo Issue Tracker

by Marcus Denker

# Pharo11 - Tolerate halt when handling a OSWindowEvent #16095 https://github.com/pharo-project/pharo/pull/16095 # Networking - Improved error handling around sending data in Socket/SocketStream (fixes #15614) #15984 https://github.com/pharo-project/pharo/pull/15984 # Tools - New settings browser #681 https://github.com/pharo-spec/NewTools/pull/681 - File Dialog: Add dynamic preview #682 https://github.com/pharo-spec/NewTools/pull/682 - Add DoIt in background and a toolbar button to cancel the current exeâ¦ #672 https://github.com/pharo-spec/NewTools/pull/672 # Graphics - Add #scale and #formSet:at:sourceRect:rule: to Canvas hierarchies and #blendAlphaScaled for Form #16090 https://github.com/pharo-project/pharo/pull/16090 - Make ScalingCanvas avoid converting a Form in a FormSet for lookup in the FormMapping #16089 https://github.com/pharo-project/pharo/pull/16089 - Tolerate halt when handling a OSWindowEvent #16088 https://github.com/pharo-project/pharo/pull/16088 # Refactoring Eingine - Refactor: extract method transformation build transformations #16125 https://github.com/pharo-project/pharo/pull/16125 - Cleanup: push down instance variable breaking changes #16113 https://github.com/pharo-project/pharo/pull/16113 - Refactor: make pull up class variable same as pull up instance variable #16112 https://github.com/pharo-project/pharo/pull/16112 - Refactor: remove method new architecture #16107 https://github.com/pharo-project/pharo/pull/16107 - Refactor: remove preconditions from extract method's buildTransformations #16102 https://github.com/pharo-project/pharo/pull/16102 - Refactor: remove unused swap method refactoring #16101 https://github.com/pharo-project/pharo/pull/16101 - Refactor: preconditions of add method and migrate to new architecture #16098 https://github.com/pharo-project/pharo/pull/16098 - RB: Just renamed two classes #16097 https://github.com/pharo-project/pharo/pull/16097 # Bootstrap - Avoid merged tags without abbrev parameter for vm download in bootstrap script #16124 https://github.com/pharo-project/pharo/pull/16124 - Avoid merged tags for vm download in bootstrap script #16121 https://github.com/pharo-project/pharo/pull/16121 - Update bootstrap process to refer to Pharo12 #16021 https://github.com/pharo-project/pharo/pull/16021 # Cleanup - 15965-CI-Failing-tests-on-the-CI-ReleaseTeststestThatThereAreNoSelectorsRemainingThatAreSentButNotImplemented #16115 https://github.com/pharo-project/pharo/pull/16115 - 16053-RGMethodDefinitionstoreOn-should-not-be-an-extension #16116 https://github.com/pharo-project/pharo/pull/16116 - 16057-Cleanup-use-cascaded-nextPutAll-in-LocaleIDstoreOn #16100 https://github.com/pharo-project/pharo/pull/16100 - Array>>#displayString should be part of Kernel and not an override from NewTools #16069 https://github.com/pharo-project/pharo/pull/16069 - Display methods should be in "displaying" protocol #16058 https://github.com/pharo-project/pharo/pull/16058

Feb. 9, 2024

Open PhD position on debugging at Inria Lille

by Steven Costiou

Hello, we have a PhD position opening at Lille, France. See all details here: https://recrutement.inria.fr/public/classic/fr/offres/2024-07154 Steven. _Summary of the research proposal:_ ### Application development inevitably introduces bugs. Often, it's not clear why a code change introduced a bug. To find this cause-and-effect relationship and debug more efficiently, developers can sometimes rely on the existence of a previous version of the code without the bug. Yet, traditional debugging tools are not designed for this kind of work, making it a tedious operation. In this thesis, we propose an approach that enables us to understand and to debug an application in a LIVE SYSTEM, such as Pharo or Python, by comparing two executions with different results: one execution succeeds and the other fails. Based on this hypothesis, we propose in this thesis to answer the following challenges: - How to detect divergence, i.e. different behavior between two executions of a program? - How can we reduce the cost in time, memory and energy consumption of detecting divergence(s) on long executions? - What are the criteria for deciding whether a divergence is normal or unauthorized? - What about detecting multiple divergences in the same program? - What abstractions are needed to compare two executions of a program and detect divergences? To meet these challenges, in addition to a precise state-of-the-art on debugging techniques, the PhD student will study concrete cases of program execution and propose a tool to be integrated into Pharo.

Feb. 8, 2024

Open Call: Object-Centric Breakpoints experiment

by Steven Costiou

Dear Community, as part of a research project in the EVREF team, we are looking for people to participate to an empirical experiment on object-centric breakpoints - a debugging tool present in Pharo 9. Many people from the community already participated, and we thank them very much ð We are still looking for participants, we need 40 people to do the experiment! Please help us, in return it helps us understand better our tools and their impact and therefore build better tools for the Pharo community! For those who want to know a bit more, see my original email below. For those who just want to jump at the experiment, you can go there https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd Thanks in advance ð Steven. --- We would like to invite you to participate to our experimental study on Object-Centric Breakpoints. This study aims to evaluate and to understand how Object-Centric Breakpoints impacts the debugging activity. This experiment takes place in **Pharo 9**. In this experiment, we ask you to solve 2 debugging tasks, one with standard Pharo tools and one other with Object-Centric Breakpoints. Between the two tasks, you will have to follow a tutorialand warmup tasks to learn how to use the tool. **How to Participate:** All instructions are here, please read them carefully: https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd **About the Experiment:** The experiment last between 40 minutes and 2 hours. Participants should have experience with Pharo development and debugging. We recommend having more than 6 months experience in Pharo and debugging in general. You will gain insights into the Object-Centric Breakpoints approach and contribute to advancements in debugging research. Help us to build better debugging tools that help you debug! **Some constraints:** - You are not allowed to load external tools and baselines, but you can use anything that is in the base image - Please do the experiment in one shot if possible without interruptions - The experiment sends anonymous data to our inria server, please make sure that you have a valid internet connection - Please try to use the object-centric breakpoints when the experimental framework asks you to **Notes:** Participation is voluntary, and everything is anonymous. You can abandon the experiment at any point (and your data will be discarded). For any question, you can contact us: steven.costiou(a)inria.fr and valentin.bourcier(a)inria.fr Thank you for considering participating in our study. Your contribution will be valuable in advancing the field of debugging and helping us understand what tools we need to build for Pharo. Sincerely, Steven and Valentin, EVREF team, Inria

Feb. 2, 2024

This week (05/2024) on the Pharo Issue Tracker

by Marcus Denker

# Fixes - Fixes for browsing a package from a repository using Calypso #16009 https://github.com/pharo-project/pharo/pull/16009 - add a missing method ClyOldMessageBrowserAdapter #16083 https://github.com/pharo-project/pharo/pull/16083 - Fix String method causing multiple problems #16081 https://github.com/pharo-project/pharo/pull/16081 - SycBrowseClassCommand fix for Browse to class in method editor #16066 https://github.com/pharo-project/pharo/pull/16066 - Deprecations from SUnit testcases should be raised #16036 https://github.com/pharo-project/pharo/pull/16036 - Fixing object class initialize #16033 https://github.com/pharo-project/pharo/pull/16033 - adding an ifEmpty guard in RubTextSegmentMorph>>#computeStraightVertices to prevent a random CI crash #16016 https://github.com/pharo-project/pharo/pull/16016 # Enhancements - Use newtools for progressbars #16075 https://github.com/pharo-project/pharo/pull/16075 - Expand the dependency analyzer roots by default #16074 https://github.com/pharo-project/pharo/pull/16074 - Rework MorphTreeMorph, MorphTreeNodeMorph and SimpleHierarchicalListMorph to remove sends of #treeExpandedForm and #treeUnexpandedForm #16043 https://github.com/pharo-project/pharo/pull/16043 - Make FTBasicTreeListItem use a FormSet for the expand/collapse toggle #16037 https://github.com/pharo-project/pharo/pull/16037 - Move the call of the Deprecation>>transform to the Deprecation>>defaultAction #16040 https://github.com/pharo-project/pharo/pull/16040 # Refactoring Engine - Cleanup: RBMetaclass>>#realName: #16061 https://github.com/pharo-project/pharo/pull/16061 - Cleanup: small refactoring cleanups #16048 https://github.com/pharo-project/pharo/pull/16048 - Refactor: remaining preconditions #16044 https://github.com/pharo-project/pharo/pull/16044 - Refactor: rename preconditions of pacakge refactoring #16028 https://github.com/pharo-project/pharo/pull/16028 - Refactor: another pass on cleaning and splitting preconditions #16026 https://github.com/pharo-project/pharo/pull/16026 - Refactor: VariableRefactoring doesn't override preconditions #16023 https://github.com/pharo-project/pharo/pull/16023 - Refactor: change method name preconditions #16022 https://github.com/pharo-project/pharo/pull/16022 - Refactor refactoring preconditions #16020 https://github.com/pharo-project/pharo/pull/16020 # Cleanups - Change #notNil into #isNotNil in Fuel test packages #16071 https://github.com/pharo-project/pharo/pull/16071 - Cleanup: Fix lint in MetaLinkAnonymousClassBuilderTest>>#testCompileCâ¦ #16063 https://github.com/pharo-project/pharo/pull/16063 - Replaced aCollection asOrderedCollection copy to OrderedCollection withAll: aCollection #16032 https://github.com/pharo-project/pharo/pull/16032 - Add two tests for the class StringTest #16031 https://github.com/pharo-project/pharo/pull/16031 - Fix #16024 remove dead code #16025 https://github.com/pharo-project/pharo/pull/16025

Feb. 2, 2024

Re: About removing class side initialization

by Guillermo Polito

> El 31 ene 2024, a las 15:36, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > For both #isAbstract and #initialize, one can understand both as cases where we have to use behavior for something that should actually be a kind o declarative property of the objects. > > - isAbstract > > This is a property of the class. > > - initialize > > This is a property of the Variable. Itâs really unfortunate to have to fall back on code execution for that. What the initalize does is to say There is out there indeed code that uses class side initialize methods to initialize class variables to constants. But that is not the only case. Some class side initalizes have complex initializations. Some are used to register the loaded class to some registration mechanism. > >> On 31 Jan 2024, at 15:03, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> >> This is indeed an issue I'd like to see solved. >> Class initialization is just an instance of a more general isssue. >> In SUnit, defining abstract classes is dirty. The code often looks like this >> MyTestClass class>>#isAbstract >> ^self == MyTestClass >> In PharoJS we face the issue of class specific methods. Upon transpiling to JS, we want to perform some actions for some classes and not their subclasses. >> A possible solution is to introduce class specific properties through an extra-layer of metaclasses. Yes, I agree. I would like to have two levels of âMetaclassesâ. Actually, one metaclass that is the traditional metaclass defining the class behavior. One âcompanionâ object where we can define domain concerns. The companion object should respect the double hierarchy, but it will not class anymore with the meta-behaviour in the class! We will be able to freely program there without mistakenly overriding critical behavior from classes :). And we will be able to define metaclasses with really specific behavior for a single class in the hierarchy chain. G

Feb. 1, 2024