- Pharo-dev - lists.pharo.org

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

Re: About removing class side initialization

by Noury Bouraqadi

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

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

by Marcus Denker

This week (04/2024) on the Pharo Issue Tracker # Pharo 11 - [Backport] Improve the way to know if a class includes a trait #15987 https://github.com/pharo-project/pharo/pull/15987 # Fixes - Fix: #16011 adding the lost return #16012 https://github.com/pharo-project/pharo/pull/16012 - Improve the way to know if a class includes a trait #15986 https://github.com/pharo-project/pharo/pull/15986 - Fix for Wrong text selection: selection selects an extra character #16010 https://github.com/pharo-project/pharo/pull/16010 - Fix #15997: Enhancement: Add printOn: on PragmaAndShortCutRegistrationItem #15998 https://github.com/pharo-project/pharo/pull/15998 - Fix #15994: morphicUIManager is missing #15995 https://github.com/pharo-project/pharo/pull/15995 - Add missing caret in #textToDisplay method. #15992 https://github.com/pharo-project/pharo/pull/15992 # Refactoring Engine - Refactorings: second pass on preconditions #16017 https://github.com/pharo-project/pharo/pull/16017 - Fix ReDoNotSendSuperInitializeInClassSideRule in Calypso #16007 https://github.com/pharo-project/pharo/pull/16007 - Enh/drivers #16004 https://github.com/pharo-project/pharo/pull/16004 # Cleanup - Remove gofer references #16008 https://github.com/pharo-project/pharo/pull/16008 - Categorize methods in Metacello #16005 https://github.com/pharo-project/pharo/pull/16005

Jan. 29, 2024

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

by Marcus Denker

# Fixes - 15941-WeakLayout--isWords-is-unknown-and-break-tests #15942 https://github.com/pharo-project/pharo/pull/15942 - Fix class and trait definition printing to consider package tags #15935 https://github.com/pharo-project/pharo/pull/15935 - Extend FFIExternalStructureReferenceHandle with tfPointerAddress #15666 https://github.com/pharo-project/pharo/pull/15666 - Fix a bug in return simulation #15632 https://github.com/pharo-project/pharo/pull/15632 # Speed - Speedup Float and Integer comparison #15949 https://github.com/pharo-project/pharo/pull/15949 # Metacello - Add back currentlyLoadedClassesInVersion in metacello registrations #15943 https://github.com/pharo-project/pharo/pull/15943 - Fix metacello override cases #15938 https://github.com/pharo-project/pharo/pull/15938 - Deprecate MetacelloIgnorePackageLoaded #15937 https://github.com/pharo-project/pharo/pull/15937 - Unify access to projectReferenceSpec #15934 https://github.com/pharo-project/pharo/pull/15934 - Deprecate Gofer #15897 https://github.com/pharo-project/pharo/pull/15897 # Refactoring Engine - Refactor: pass on refactoring preconditions #15954 https://github.com/pharo-project/pharo/pull/15954 # Cleanup - Display cleanups #15945 https://github.com/pharo-project/pharo/pull/15945 - Cleaning delay and time dependencies. #15944 https://github.com/pharo-project/pharo/pull/15944

Jan. 23, 2024

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

by Marcus Denker

# Feature - Add Search filter to Epicea #15842 https://github.com/pharo-project/pharo/pull/15842 # Fixes - fix #15893 bad system commitish #15894 https://github.com/pharo-project/pharo/pull/15894 # Refactoring Engine - Fix order of rename. #15921 https://github.com/pharo-project/pharo/pull/15921 - Remove old RBRenameMethodRefactoring (unused) #15920 https://github.com/pharo-project/pharo/pull/15920 - Fixed lost menu for rename method #15915 https://github.com/pharo-project/pharo/pull/15915 - Renaming drivers #15909 https://github.com/pharo-project/pharo/pull/15909 - 2023 12 29 rename method driver #15881 https://github.com/pharo-project/pharo/pull/15881 # Metacello - More Metacello simplifications #15888 https://github.com/pharo-project/pharo/pull/15888 # Cleanup / Documentation - Fixed obvious unnecessary users of duration. #15854 https://github.com/pharo-project/pharo/pull/15854 - Feature/Integer documentation #15911 https://github.com/pharo-project/pharo/pull/15911 - Doing a pass on comments and protocol to improve understanding the mock #15917 https://github.com/pharo-project/pharo/pull/15917 - Cleanup: more notNil / ifNotNil cases #15901 https://github.com/pharo-project/pharo/pull/15901

Jan. 23, 2024

This week (52/2023) on the Pharo Issue Tracker

by Marcus Denker

# Fixes - Fix Enlumineur Pretty Printer "One line messages" setting not showing options #15819 https://github.com/pharo-project/pharo/pull/15819 - Restore #removeMethod:inClass: method #15889 https://github.com/pharo-project/pharo/pull/15889 - Explicitly set initial focus to the query browser table during open #15880 https://github.com/pharo-project/pharo/pull/15880 - Open class browser on Cmd/Ctrl B in the message brp #15868 https://github.com/pharo-project/pharo/pull/15868 - Fix #15861: NeccVariableEntry crashs with trying to complete 'Display #15862 https://github.com/pharo-project/pharo/pull/15862 # Metacello Cleanup - Metacello Cleanup V2 #15846 https://github.com/pharo-project/pharo/pull/15846 - Christmas cleanup and modularisations V2 #15870 https://github.com/pharo-project/pharo/pull/15870 # Refactoring Engine - Fix Add argument refactoring failing in class side methods #15879 https://github.com/pharo-project/pharo/pull/15879 - Another pass on rename variable driver with caro #15829 https://github.com/pharo-project/pharo/pull/15829 # Cleanup UIManager - Replace UIManager progress bars with Job #15878 https://github.com/pharo-project/pharo/pull/15878 - Cleanups in UIManager dependencies #15836 https://github.com/pharo-project/pharo/pull/15836 # Cleanup - Better Time class comment and tests #15864 https://github.com/pharo-project/pharo/pull/15864 - Fixing class names and uncategorised methods #15853 https://github.com/pharo-project/pharo/pull/15853

Jan. 23, 2024

This week (51/2023) on the Pharo Issue Tracker

by Marcus Denker

A little bit late... # Features - Implements hierarchical senders system command #15822 https://github.com/pharo-project/pharo/pull/15822 - Shuffle tests #15581 https://github.com/pharo-project/pharo/pull/15581 # Fixes - 15801-Cmd-B-on-Transcript-raises-an-error #15802 https://github.com/pharo-project/pharo/pull/15802 - 15798-Compiler-error-when-iteration-step-is-nil #15803 https://github.com/pharo-project/pharo/pull/15803 - Fix for Calypso discard code with error and prevent to fix it #15834 https://github.com/pharo-project/pharo/pull/15834 - Make TraitedClass part of the trait composition of TraitedMetaclasses #15833 https://github.com/pharo-project/pharo/pull/15833 - Display trait icon in Calypso class definition editor #15828 https://github.com/pharo-project/pharo/pull/15828 - fix some button orders #15820 https://github.com/pharo-project/pharo/pull/15820 - Prevent logging exceptions twice when debugger is opened #15746 https://github.com/pharo-project/pharo/pull/15746 # Variables - Undeclared: inlining of declare:from: #15827 https://github.com/pharo-project/pharo/pull/15827 - UndeclaredVariable read/write: context as argument #15821 https://github.com/pharo-project/pharo/pull/15821 - #usingClasses for the Slot Hierachy #15815 https://github.com/pharo-project/pharo/pull/15815 # Refactoring Engine - Position temp definition before first occurrence of extracted expression, and always in outer scope (fixes #14611) #15781 https://github.com/pharo-project/pharo/pull/15781 - Fix rename refactoring call to support class methods. #15816 https://github.com/pharo-project/pharo/pull/15816 - Enh/refactoring pass over rename driver and tests #15808 https://github.com/pharo-project/pharo/pull/15808 # Tests - Shuffle tests #15581 https://github.com/pharo-project/pharo/pull/15581 - New source code command for running current test #15832 https://github.com/pharo-project/pharo/pull/15832 - Fix shuffle seed printing #15831 https://github.com/pharo-project/pharo/pull/15831 # Cleanup - Unify packaging of Announcement>>#affects* #15734 https://github.com/pharo-project/pharo/pull/15734 - Remove ChangeSet #15794 https://github.com/pharo-project/pharo/pull/15794 - (Re)Moved ProfilerUI package #15797 https://github.com/pharo-project/pharo/pull/15797 - Fix a few reflection: pragmas #15812 https://github.com/pharo-project/pharo/pull/15812 - fix a method that has a wrong category #15814 https://github.com/pharo-project/pharo/pull/15814 - Cleanup notNil to isNotNil in AST-CORE #15840 https://github.com/pharo-project/pharo/pull/15840

Jan. 23, 2024

Re: [ANN] New Success Story posted

by Aik-Siong Koh

Great. I have the idea of Digital Twin applied to Software https://askoh.com/#DigitalTwinS I want to translate Smalltalk to a fast language like C++. Does Moose and Famix have the ability to do that? How well? Thanks, Aik-Siong Koh Nicolas Anquetil wrote: > > Short answer: yes and yes > > longer answer: > > The migration was/is from GWT applications (therefore Java) to Angular > Typescript. > It was for a project with an industrial partner that is still using > the Moose to migrate other GWT applications. > > The research was performed by Benoit Verhaeghe (in CC) who was later > on hired by the company to continue the work. > > The migration tool is based on Moose and Famix meta-model. > In this case creates a Java model of a GWT application, then from that > it creates a model of the application GUI, and re-exports it in > Angular/TS > > Using Famix and Moose means it can handle other languages. We did > experiment from Spec to Spec-2 for example > > nicolas > > On 20/01/2024 06:57, Aik-Siong Koh wrote: >> Was the migration from Java to Angular Typescript? Moose and Pharo >> were just tools for the migration between Java and Typescript? Thanks >> Aik-Siong Koh >> >> Marcus Denker wrote: >>> There is a new âSuccess Storyâ posted on pharo.org <http://pharo.org/>: >>> >>> >>> Casino - Revolutionizing Application Migration for Berger-Levrault >>> Â Â Â Â https://www.pharo.org/success/BergerLevrault-Casino.html >>> >>> >>> If you have an idea for something like that, you can do PRs for the >>> site here: >>> Â Â Â Â https://github.com/pharo-project/pharo-website >>>

Jan. 21, 2024