- Pharo-dev - lists.pharo.org

Call for presentation @ ESUG 2024

by stephane ducasse

Dear friends Please distribute the following call ESUG 2024 Call for Presentations from 8 to 11 July 2024 Lille France https://esug.github.io https://esug.github.io/2024-Conference/conf2024.html You can support the ESUG conference in many different ways: - Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ - Submit a talk, software to the award competition, or a paper to IWST http://https://esug.github.io/2024-Conference/IWST2024.html - Attend the conference. We'd like to beat the previous record of attendance (180 people at Koln 2019)! - Students can get free registration and hosting if they enroll in the the Student Volunteers program. See below. ## Developers Forum: International Smalltalk Developers Conference We are looking for YOUR experience on using Smalltalk. You will have 30 min for presentations and 45 min for hands-on tutorials. The list of topics for the normal talks and tutorials includes, but is not limited to the following: - XP practices, Development tools, Experience reports - Model-driven development, Web development, Team management - Meta-Modeling, Security, New libraries & frameworks - Educational material, Embedded systems and robotics - SOA and Web services, Interaction with other programming languages - Teaching Pearls and Show us Your Business We added two types of sessions in addition to the regular talks and ''Show us your project'' sessions. - Show your business in a 10-minute session (Get prepared!!) - Teaching pearls: we want some sessions on how to teach some design aspects. We want your tip and tricks to teach Smalltalk or OOP. We expect to have several 10 to 15-minute sessions aggregated. ### How to submit? Make a Pull Request here https://github.com/ESUG/esug.github.io/tree/source/2024-Conference/talks [Or but only if you are not connected to the worldâ¦ send an email to stephane.ducasse(a)inria.fr] Title: [ESUG 2024] Please follow the template below the email will be automatically processed! Name: Email: Abstract: Bio: ## Call for Student Volunteers Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. Pay attention: the places are limited so do not wait till the last minute to apply. Conference details: Send an email to Steven Costiou <steven.costiou at inria.fr> and Oleksandr Zaitsev <olk.zaytsev at gmail.com> with: title: [ESUG 2024 Student] name, gender, university/school, country, email address short description of you and why you are interested in participating For which period is accommodation covered? Accommodation is covered from Sunday from 8 to 11 July 2024 (including nights from Sunday to Monday and from Wednesday to Thursday ). Students will be hosted in student rooms. ESUG additionally covers the lunches during the week and one dinner. Duties include handling registration as people arrive at the conference, filling coffee machines, collecting presentation slides for ESUG right after the presentation is given, being present at an information desk to answer questions, and generally being helpful. Student volunteering makes the conference better, takes a fairly small amount of time, and doesn't significantly interfere with enjoying and learning from the conference. Please note, that this role requires discipline and constant attention to all attendees. Information about hotel Student Volunteer rooms are booked at (to be announced). If you are a student volunteer, do not book yourself, we have arranged the booking already!

Feb. 13, 2024

Re: A little post Why class number is an idiotic quality metric?

by stephane ducasse

https://pharoweekly.wordpress.com/2024/02/10/why-class-number-is-an-idiotic… > On 10 Feb 2024, at 10:13, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > > https://wordpress.com/post/pharoweekly.wordpress.com/4226 > > > 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 > > > > > 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. 11, 2024

Re: A little post Why class number is an idiotic quality metric?

by James Foster

For those that didn't write the post, here is a linkâ¦ https://pharoweekly.wordpress.com/2024/02/10/why-class-number-is-an-idiotic… James > On Feb 10, 2024, at 1:13â¯AM, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > > https://wordpress.com/post/pharoweekly.wordpress.com/4226 > > > 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. 11, 2024

A little post Why class number is an idiotic quality metric?

by stephane ducasse

https://wordpress.com/post/pharoweekly.wordpress.com/4226 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. 10, 2024

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

Re: About removing class side initialization

by Marcus Denker

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 âthe default value of this Variable is this literal valueâ or âsend this message to the new object to set the default valueâ Anything else that you could do in #initialize is IMHO bad style. We always are proud that âEverything is an Objectâ. But as soon as we talk about the language itself, Smallkers suddenly forget everything we know about objects: Everything has to be a Class or a Method ! there is no other way! We really need to try to free ourselves from this mindset and start to model our programs better. With fluid class defintions and First Class Variables, we can do this: Object << #MyClass slots: {}; sharedVariables: { #ClassVar => InitializedClassVariable default: 1 }; package: âMyPackageâ; (this works and even is correctly stored in GIT or even when filed out) Instead of #isAbstract, we can just tag the class as Abstract, we could add a method on the classBuilder: Object << #MyClass slots: {}; sharedVariables: { }; package: âMyPackageâ; beAbtract or have some way to specify properties Object << #MyClass slots: {}; sharedVariables: { }; package: âMyPackageâ; properties: {#abstract } There is even already a property API on class, but no support on the level of the class builder / class parser yet. And of course, we have to then make sure this is stored correctly in Git. Marcus > 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. > > Noury > > > On Jan 18 2024, at 3:38 pm, David Mason <dmason(a)torontomu.ca> wrote: > I like James' suggestion. > > It shouldn't matter if someone defines a class initialize or not, or whether they call super initialize. So either Object class should have an empty one (like Object>>initialize) or Behavior>>initialize should do the right thing. > > The Smalltalk way would be for it to go in Object class, because even infrastructure code like Behavior should avoid condition checking when the dispatch rules can already solve the problem. > > ../Dave > > On Wed, 17 Jan 2024 at 22:52, James Foster via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: > Stef, > > Your comments brought to mind a few thoughts. > > First, initialize methods should, in general, be idempotent; that is, running them repeatedly should not make further changes after the first run (along the lines of your mention of lazy initialization). For example, if a variable is nil then it should be set to an empty set; if it is already a set, donât replace it. > > Second, many packaging systems have scripts for pre-load, post-load, pre-remove, and post-remove. Instead of having initialize methods on a class, we could have scripts associated with a package. (Presumably a package will be a first-class object and have methods to handle these action.) > > Third, following a model from upgrading databases, one would have a âversion numberâ stored somewhere (perhaps a class variable) and scripts that upgrade and downgrade the version. Rerunning the âupgradeâ would be idempotent since we would already be on the latest version. > > As to the specific situation, yes, there is a problem with Behavior>>#initialize that arises from Behaviorâs unique position where instances are classes and we have an unfortunate gratuitous polymorphism between instance initialization in which we are creating a new instance of Behavior (and giving it an empty method dictionary) and class initialization which is typically associated with _loading_ or _installing_ a class. Perhaps with a time machine the right solution would be separate names for these concepts (#initialize for instances, and #postLoad for classes). But really, the only place this is confusing is with Behavior, so maybe we should treat it as a special case rather than reaching for a general solution. > > I think that rather than trying to prevent calling super initialize on classes (when failing to call super initialize on instances is a common bug) or trying to prevent an initialize from reaching Behavior>>initialize (by blocking it on the class side of Object), we should simply have Behavior>>initialize recognize its special position (and unique risk for confusion) by being idempotent. That is, if we already have a method dictionary, then there is no reason to do any further initialization; just protect the existing code with a check of âare we already initialized?â (Do the simplest thing that could possible work!) > > So, while we could look at bigger solutions like package managers or image versions, we should just start by making Behavior>>#initialize smart enough to recognize its unique danger and handle the problem there. I donât like the situation in which some initialize methods _must_ call super and some initialize methods _must not_ call super. > > In fact, I could imagine that there are some times when class initialization _should_ call super. Perhaps I have an abstract superclass that builds and caches a list of its subclasses (in GemStone this would be non-trivial). When a new subclass is added and the subclass is initialized, I want the super initialize method to be called so the superclass can reinitialize its cache. Perhaps this is a contrived case, but the point is that it isnât really appropriate to put in a rule that you should not send super initialize. > > Just some ideas and thoughts to let you know Iâm reading your postsâ¦ > > James Foster > > > > On Jan 17, 2024, at 12:37â¯PM, stephane ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > > > Hi community > > > > I would like to get use your ideas. > > > > Here is the case > > > > Context: Class side initialize are not good. > > We fixed a bug with guille today (should do a PR) this bug was breaking some projects by changing the superclass of classes to Object. Radical! > > > > It was produced by the removal of DependentFields in Object and the removal of the class side Object initialize method > > Needed to initialize DependentFields (RIP). > > > > Doing so when a class was doing a super initialize it executes the Behavior>>#initialize (which reinitialize the class and its superclass) and was not reachable before because blocked by Object class>>#initialize. > > > > Two Situations. > > > > When we do a class super initialize there are two cases > > > > Case 1. the super reaches Behavior>>#initialize and your class gets killed. > > Solution 1. Easy we will define a class side initialize method to protect the execution of Behavior>>#initialize. > > Ideally raising a warning so that people can find their problems. > > > > Case 2. > > You have a little hierarchy Root and Subclass1 Subclass2 classes > > Root class defines an initialize method. > > > > You should not redefine initialize in Subclass1 and do a super initialize > > else we get a double initialize. Not easy to grasp so I guess that many people are making this mistake. > > > > Solution 2. > > Cyril added a rule in a ReleaseTest (yes this is cool and we should use more rules and not code by hand in the releaseTest) > > that checks for no class side super initialize in Pharo. > > > > Now long time ago I thought that this class initialize is not that good and that I would like to have > > a way that class state dependencies do not have to be resolved by the developers by initializing first A then B > > but that the system could do it automatically. In this case we would not need initialize by class construction. > > > > Do you have an idea how such design could be? > > > > Iâm too dead right now to think but to me it feels a bit similar to lazy initialization. > > If all the shared variables would be only accessed by lazy accessors then we do not need to initialize them statically. > > Now this is a bit extreme but this is to illustrate my wish. > > > > So let us know :) > > Stef > > > > > > > > > >

Jan. 31, 2024