March 2021 - Pharo-dev - lists.pharo.org

Re: Improving Variable Shadow model

by Marcus Denker

We merged this and did the next step: 8009-Rule-required-for-shadowed-variables #8917 https://github.com/pharo-project/pharo/pull/8917 Thus the Code critique now correctly shows shadowed variables even for the case where the argument of a closure shadows an other variables. â¢ The rule of course can now be further improved to exactly tell the user what is shadowed â¢ We should add a rule that checks of instance or class vars shadow globals (which needs further refinement on the shadow model) â¢ We should add a release test to make sure we have no shadowed vars in the system â both on the level of methods and on the level of Classes but that is for the future > On 29 Mar 2021, at 16:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The issue tracker entry "Rule required for shadowed variables" [#8009](https://github.com/pharo-project/pharo/issues/8009) > > It reads: > > ___ > > > In the CI output log for PRs on Pharo 9 issues I see the following warnings on Roassal classes: > > SystemNotification: RSCanvas>>numberOfEdges(edges is shadowed) > SystemNotification: RSCanvas>>numberOfEdges(edges is shadowed) > SystemNotification: RSCanvas>>numberOfNodes(nodes is shadowed) > SystemNotification: RSCanvas>>numberOfNodes(nodes is shadowed) > SystemNotification: RSComposite>>numberOfEdges(edges is shadowed) > SystemNotification: RSComposite>>numberOfEdges(edges is shadowed) > SystemNotification: RSComposite>>numberOfNodes(nodes is shadowed) > SystemNotification: RSComposite>>numberOfNodes(nodes is shadowed) > SystemNotification: RSShape>>printOn:(model is shadowed) > SystemNotification: RSShape>>printOn:(model is shadowed) > > which means we have local variables (or block variable) in a method with the same name as an existing ivar in the class. > > These cases should be cleaned in Rossal3 for the Pharo 9 image - for that I opened https://github.com/ObjectProfile/Roassal3/issues/321 on Roassal3 issue tracker. > > But it would be good if we could have a Lint rule that shows that problem so one can avoid it: > > **Side note:** Yes - there already is a rule called ReTempVarOverridesInstVarRuleTest - but this is only for temps > and does not cover variables in blocks like in > > ```Smalltalk > numberOfEdges > "Return the number of edges contained in the container" > ^ self privateEdges > ifNil: [ 0 ] > ifNotNil: [ :edges | edges size ] > ``` > when "edges" is already an instance variable > > ___ > > So how is ReTempVarOverridesInstVarRuleTest implemented? > > ```Smalltalk > check: aMethod forCritiquesDo: aCriticBlock > | ivarNames problemTemps| > ivarNames := aMethod methodClass instVarNames. > ivarNames ifEmpty: [ ^ self ]. > > problemTemps := ((aMethod ast arguments, aMethod ast temporaries) > select: [ :node |ivarNames includes: node name]). > problemTemps do: [ :node | > aCriticBlock cull: (self critiqueFor: aMethod about: node) ] > ``` > > So, this test is done purely on the results of the compilation, it just checks if temps are overriding the instance vars. > It just does not care about blocks, nor class variables or globals. > > We could now, for this issue, recurse into the compiled block closures, but that would make the code quite complex. > > To see a better solution, let's check who actually prints out the log message in the build. Just searching for a substring will > lead us to OCShadowVariableWarning>>#variable:shadows: > > ```Smalltalk > variable: varNode shadows: semVar > compilationContext interactive > ifTrue: [ > OCSemanticError new > node: node; > compilationContext: compilationContext; > messageText: self stringMessage; > signal ] > ifFalse: [ self showWarningOnTranscript ]. > > ``` > > This is an exception raised by the AST visitor that does name analysis, OCASTSemanticAnalyzer: > > ```Smalltalk > variable: variableNode shadows: semVar > compilationContext optionSkipSemanticWarnings ifTrue: [ ^semVar ]. > ^ OCShadowVariableWarning new > node: variableNode; > shadowedVar: semVar; > compilationContext: compilationContext; > signal > ``` > > This method is called whever we lookup a Variable name to create a Variable object describing it: > > ```Smalltalk > declareVariableNode: aVariableNode as: anOCTempVariable > | name var | > name := aVariableNode name. > var := scope lookupVarForDeclaration: name. > var ifNotNil: [ > "Another variable with same name is visible from current scope. > Warn about the name clash and if proceed add new temp to shadow existing var" > self variable: aVariableNode shadows: var ]. > var := scope addTemp: anOCTempVariable. > aVariableNode binding: var. > ^ var > ``` > > This means: in non-interactive mode, we just log the error and compile while allowing shadowing. In interactive mode > we forbid it (we raise a OCSemanticError exception that will be displayed in the code editor). > > What could we now do to improve the model of shadowing variables? The best thing would be if we could add the fact that > a variable shadows another to the semantic information. That is, it should be modeled as part of the variable. > > We do not need much: just add this information as a property would be perfectly enough. This way we can add a test method > (that check if the property exists). On the level of the Code Critique rule it will be very simple: just get all variables > that are defined (args, temps, args of blocks) and check if they are shadowing. That's easy! > > So what is needed to implement it? > > We first need to make sure we hand over one more parameter to #variable:shadows: and call it later: right now, in > interactive mode, we never create a Variable at all. There is no problem to delay that and tag the variable correctly: > > ```Smalltalk > variable: aVariable shadows: shadowedVariable inNode: variableNode > aVariable shadowing: shadowedVariable. > compilationContext optionSkipSemanticWarnings ifTrue: [ ^aVariable ]. > ^ OCShadowVariableWarning new > node: variableNode; > shadowedVar: aVariable; > compilationContext: compilationContext; > signal > ``` > > with: > > ```Smalltalk > declareVariableNode: aVariableNode as: anOCTempVariable > | name var shadowed | > name := aVariableNode name. > var := scope lookupVarForDeclaration: name. > var ifNotNil: [ > "Another variable with same name is visible from current scope" > shadowed := var. > ]. > var := scope addTemp: anOCTempVariable. > aVariableNode binding: var. > shadowed ifNotNil: [self variable: var shadows: shadowed inNode: aVariableNode]. > ^ var > ``` > > > To be able to tag Variables, we implement > > > ```Smalltalk > shadowing: anotherVariable > self propertyAt: #shadows put: anotherVariable > ``` > > and > > ```Smalltalk > "testing" > isShadowing > ^self hasProperty: #shadows > ``` > > We do this on Variables, which means that we can later introduce Variable shadow tagging even for instance variables and Class Variables > > How do we now test this? > > One idea is to rewrite ReTempVarOverridesInstVarRule>>#check:forCritiquesDo: to use #isShadowing. ReTempVarOverridesInstVarRuleTest > is green, we have something that is reado to commit. > > Let's try > > ```Smalltalk > check: aMethod forCritiquesDo: aCriticBlock > > | problemTemps | > problemTemps := aMethod temporaryVariables select: [ :var | > var isShadowing ]. > problemTemps do: [ :var | > aCriticBlock cull: > (self critiqueFor: aMethod about: var definingNode) ] > ``` > > And: Success! This is now a first PR to be done [see here](https://github.com/pharo-project/pharo/pull/8909). > > This does not yet provide the Rule and the Release Test for shadowing vars in general, but it is a very nice first step that we can build upon next. >

March 30, 2021

Menu separators on Glamour fastTable not working

by Federico.Balaguer

Hello! I came across a problem with Glamour's fastTables, menu separators are not displayed. I have a running example based on PBE2CodeEditor example that shows the problem. I am not sure whether it makes sense to share that here. I spent a couple of hours trying to find the code that generate the menues with no luck (subclasses of GLMMorphicWidgetRenderer) . Could someone give me a hint where to look at? Thanks! Federico -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 30, 2021

Improving Variable Shadow model

by Marcus Denker

The issue tracker entry "Rule required for shadowed variables" [#8009](https://github.com/pharo-project/pharo/issues/8009) It reads: ___ In the CI output log for PRs on Pharo 9 issues I see the following warnings on Roassal classes: SystemNotification: RSCanvas>>numberOfEdges(edges is shadowed) SystemNotification: RSCanvas>>numberOfEdges(edges is shadowed) SystemNotification: RSCanvas>>numberOfNodes(nodes is shadowed) SystemNotification: RSCanvas>>numberOfNodes(nodes is shadowed) SystemNotification: RSComposite>>numberOfEdges(edges is shadowed) SystemNotification: RSComposite>>numberOfEdges(edges is shadowed) SystemNotification: RSComposite>>numberOfNodes(nodes is shadowed) SystemNotification: RSComposite>>numberOfNodes(nodes is shadowed) SystemNotification: RSShape>>printOn:(model is shadowed) SystemNotification: RSShape>>printOn:(model is shadowed) which means we have local variables (or block variable) in a method with the same name as an existing ivar in the class. These cases should be cleaned in Rossal3 for the Pharo 9 image - for that I opened https://github.com/ObjectProfile/Roassal3/issues/321 on Roassal3 issue tracker. But it would be good if we could have a Lint rule that shows that problem so one can avoid it: **Side note:** Yes - there already is a rule called ReTempVarOverridesInstVarRuleTest - but this is only for temps and does not cover variables in blocks like in ```Smalltalk numberOfEdges "Return the number of edges contained in the container" ^ self privateEdges ifNil: [ 0 ] ifNotNil: [ :edges | edges size ] ``` when "edges" is already an instance variable ___ So how is ReTempVarOverridesInstVarRuleTest implemented? ```Smalltalk check: aMethod forCritiquesDo: aCriticBlock | ivarNames problemTemps| ivarNames := aMethod methodClass instVarNames. ivarNames ifEmpty: [ ^ self ]. problemTemps := ((aMethod ast arguments, aMethod ast temporaries) select: [ :node |ivarNames includes: node name]). problemTemps do: [ :node | aCriticBlock cull: (self critiqueFor: aMethod about: node) ] ``` So, this test is done purely on the results of the compilation, it just checks if temps are overriding the instance vars. It just does not care about blocks, nor class variables or globals. We could now, for this issue, recurse into the compiled block closures, but that would make the code quite complex. To see a better solution, let's check who actually prints out the log message in the build. Just searching for a substring will lead us to OCShadowVariableWarning>>#variable:shadows: ```Smalltalk variable: varNode shadows: semVar compilationContext interactive ifTrue: [ OCSemanticError new node: node; compilationContext: compilationContext; messageText: self stringMessage; signal ] ifFalse: [ self showWarningOnTranscript ]. ``` This is an exception raised by the AST visitor that does name analysis, OCASTSemanticAnalyzer: ```Smalltalk variable: variableNode shadows: semVar compilationContext optionSkipSemanticWarnings ifTrue: [ ^semVar ]. ^ OCShadowVariableWarning new node: variableNode; shadowedVar: semVar; compilationContext: compilationContext; signal ``` This method is called whever we lookup a Variable name to create a Variable object describing it: ```Smalltalk declareVariableNode: aVariableNode as: anOCTempVariable | name var | name := aVariableNode name. var := scope lookupVarForDeclaration: name. var ifNotNil: [ "Another variable with same name is visible from current scope. Warn about the name clash and if proceed add new temp to shadow existing var" self variable: aVariableNode shadows: var ]. var := scope addTemp: anOCTempVariable. aVariableNode binding: var. ^ var ``` This means: in non-interactive mode, we just log the error and compile while allowing shadowing. In interactive mode we forbid it (we raise a OCSemanticError exception that will be displayed in the code editor). What could we now do to improve the model of shadowing variables? The best thing would be if we could add the fact that a variable shadows another to the semantic information. That is, it should be modeled as part of the variable. We do not need much: just add this information as a property would be perfectly enough. This way we can add a test method (that check if the property exists). On the level of the Code Critique rule it will be very simple: just get all variables that are defined (args, temps, args of blocks) and check if they are shadowing. That's easy! So what is needed to implement it? We first need to make sure we hand over one more parameter to #variable:shadows: and call it later: right now, in interactive mode, we never create a Variable at all. There is no problem to delay that and tag the variable correctly: ```Smalltalk variable: aVariable shadows: shadowedVariable inNode: variableNode aVariable shadowing: shadowedVariable. compilationContext optionSkipSemanticWarnings ifTrue: [ ^aVariable ]. ^ OCShadowVariableWarning new node: variableNode; shadowedVar: aVariable; compilationContext: compilationContext; signal ``` with: ```Smalltalk declareVariableNode: aVariableNode as: anOCTempVariable | name var shadowed | name := aVariableNode name. var := scope lookupVarForDeclaration: name. var ifNotNil: [ "Another variable with same name is visible from current scope" shadowed := var. ]. var := scope addTemp: anOCTempVariable. aVariableNode binding: var. shadowed ifNotNil: [self variable: var shadows: shadowed inNode: aVariableNode]. ^ var ``` To be able to tag Variables, we implement ```Smalltalk shadowing: anotherVariable self propertyAt: #shadows put: anotherVariable ``` and ```Smalltalk "testing" isShadowing ^self hasProperty: #shadows ``` We do this on Variables, which means that we can later introduce Variable shadow tagging even for instance variables and Class Variables How do we now test this? One idea is to rewrite ReTempVarOverridesInstVarRule>>#check:forCritiquesDo: to use #isShadowing. ReTempVarOverridesInstVarRuleTest is green, we have something that is reado to commit. Let's try ```Smalltalk check: aMethod forCritiquesDo: aCriticBlock | problemTemps | problemTemps := aMethod temporaryVariables select: [ :var | var isShadowing ]. problemTemps do: [ :var | aCriticBlock cull: (self critiqueFor: aMethod about: var definingNode) ] ``` And: Success! This is now a first PR to be done [see here](https://github.com/pharo-project/pharo/pull/8909). This does not yet provide the Rule and the Release Test for shadowing vars in general, but it is a very nice first step that we can build upon next.

March 29, 2021

Progress Report -> Refactoring Project - ( March 22 - 26 )

by Evelyn Cusi Lopez

Hello all, Last week I did these tasks: - Fix issue: "Improve Extract SetUp Refactoring <https://github.com/pharo-project/pharo/issues/8853>", now this refactoring can find and replace #setUp occurrences in all methods tests. Check PR to know the changes <https://github.com/pharo-project/pharo/pull/8877>. You can see the new behavior of refactoring in the following video: https://www.youtube.com/watch?v=feKsdci0dL4 - Fix issue: "Add preview to extract method Refactoring <https://github.com/pharo-project/pharo/issues/8851>". Check PR to know the changes <https://github.com/pharo-project/pharo/pull/8898>. You can see the new behavior of refactoring in the following video: https://www.youtube.com/watch?v=J0Qexh9l034 - Fix issues: "Replace senders refactoring can only replace senders with same amount of arguments #5851 <https://github.com/pharo-project/pharo/issues/5851>" and " Improving refactoring: how to merge on method usage into another #2493 <https://github.com/pharo-project/pharo/issues/2493>", now we can replace method's senders with different amount of arguments . Check PR to know the changes <https://github.com/pharo-project/pharo/pull/8903>. You can see the new behavior of refactoring in the following video: https://www.youtube.com/watch?v=zPzUHFWWpV4 - Start to fix RB - Improve instance variable refactoring #8665 <https://github.com/pharo-project/pharo/issues/8665> Tasks for this week: - Finish to fix: RB - Improve instance variable refactoring #8665 <https://github.com/pharo-project/pharo/issues/8665> - Fix issue: Extract method in the superclass is not fully working #8871 <https://github.com/pharo-project/pharo/issues/8871> - Add option to use scopes in refactorings. - Add previews for refactoring, using a scope's selector to apply the refactoring. - Fix issue: move to component refactoring issue. <https://github.com/pharo-project/pharo/issues/8499> - Fix issue: Inline senders refactoring does not correctly manage errors #6218 <https://github.com/pharo-project/pharo/issues/6218> Regards, Evelyn C.

March 29, 2021

This week (12/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 20 Pull Requests and closed 18 Issue tracker entries this week. https://github.com/pharo-project/pharo/pulse Refactoring Infrastructure ============ - RB - Rename vars traits #8848 https://github.com/pharo-project/pharo/pull/8848 - RB - Improve extract method #8847 https://github.com/pharo-project/pharo/pull/8847 - RB - Remove senders of method Refactoring #8843 https://github.com/pharo-project/pharo/pull/8843 - RB - Add comments to RBRemoveAllSendersRefactoring #8857 https://github.com/pharo-project/pharo/pull/8857 - RB - Fix message of Extract Method Refactoring #8872 https://github.com/pharo-project/pharo/pull/8872 Fixes ===== - 8655-SurfacePluginDLL-is-crashing-with-the-headless-VM-at-restart #8804 https://github.com/pharo-project/pharo/pull/8804 - Fluid class should propose trait: + trait: TEmpty as a default #8674 https://github.com/pharo-project/pharo/pull/8674 - Fix 8855: Paste shortcut (cmd/ctrl+V) conflicts with new calypso shortcut #8856 https://github.com/pharo-project/pharo/pull/8856 - in white theme, ghost text should be darker (otherwise is not visible) #8859 https://github.com/pharo-project/pharo/pull/8859 - 8762-Compiler-Evaluating-an-expression-with-error-with-a-requestor-leads-to-primitive-fail #8800 https://github.com/pharo-project/pharo/pull/8800 - 6526-RGTraitDescriptionStrategy-invoke-methods-that-do-not-exist-announcer #8841 https://github.com/pharo-project/pharo/pull/8841 - Little fix in OSWindowGestureHandler>>trackFinger: #8881 https://github.com/pharo-project/pharo/pull/8881 Features ======== Just two methods added to get information from the system - Add CairoLibrary>>versionString #8880 https://github.com/pharo-project/pharo/pull/8880 - Add VirtualMachine>>#freeSize #8868 https://github.com/pharo-project/pharo/pull/8868 Cleanups and Refactorings ==================== - Update-ReleaseTests #8849 https://github.com/pharo-project/pharo/pull/8849 - Categorize uncategorized methods in classes starting with H #8858 https://github.com/pharo-project/pharo/pull/8858 - comment typos #8866 https://github.com/pharo-project/pharo/pull/8866 - Simplify SystemVersion class>>#current #8863 https://github.com/pharo-project/pharo/pull/8863 - [Calypso] Refactor and bugfix on ClySystemEnvironment #8867 https://github.com/pharo-project/pharo/pull/8867 - add test for Array2D zeros method #8873 https://github.com/pharo-project/pharo/pull/8873

March 26, 2021

Proposal: Simplify How Pragmas are stored

by Marcus Denker

In Pharo9, we have speed up Pragma access. https://blog.marcusdenker.de/speeding-up-pragma-access https://blog.marcusdenker.de/speeding-up-pragma-access-part-ii I think we further improve things, this time with regard to how Pragmas are stored in the method objects. **Describe the problem** Pragmas are stored mixed with associations in the AdditionalMethodState. I propose to store all Pragmas as one pre-allocated array as a property #pragmas instead. This will speedup both pragma access and property access and will radically simplify the code. **Classes involved** CompiledMethod, AdditionalMethodState, Compiler backed **Current Situation** This is how Pragmas are now stored. It is a bit strange: - if there is a pragma, we create a method with an AdditionalMethodState object, referenced from the second-last literal. - This is a variable subclass, implementing a dictionary, no hashing, just linear search (that is ok as dicts <10 are faster without hashing most likely) - What is *very* strange: it contains associations (for properties) and Pragmas, mixed. This means that all code very odd as it has to always check: ```smalltalk propertyAt: aKey ifAbsent: aBlock "Answer the property value associated with aKey or, if aKey isn't found, answer the result of evaluating aBlock." 1 to: self basicSize do: [:i | | propertyOrPragma "<Association|Pragma>" | propertyOrPragma := self basicAt: i. (propertyOrPragma isAssociation and: [propertyOrPragma key == aKey]) ifTrue: [^propertyOrPragma value]]. ^aBlock value ``` while we have a second api that gives us either a pragma or a property, whatever it finds first: ```smalltalk at: aKey ifAbsent: aBlock "Answer the property value or pragma associated with aKey or, if aKey isnt found, answer the result of evaluating aBlock." 1 to: self basicSize do: [:i | | propertyOrPragma "<Association|Pragma>" | (propertyOrPragma := self basicAt: i) key == aKey ifTrue: [^propertyOrPragma isAssociation ifTrue: [propertyOrPragma value] ifFalse: [propertyOrPragma]]]. ^aBlock value ``` and if you ask for #pragmas (which is the main API), it has to create the array, iterating and checking for each entry: ```smalltalk pragmas "Return the Pragma objects. Properties are stored as Associations" ^ Array new: self basicSize streamContents: [ :pragmaStream | 1 to: self basicSize do: [ :i | | propertyOrPragma "<Association|Pragma>" | (propertyOrPragma := self basicAt: i) isAssociation ifFalse: [ pragmaStream nextPut: propertyOrPragma ] ] ] ``` This is slow for pragmas, the array is created on demand. This is slow for properties, as we need to check an skip pragmas when searching. For speed, the code for pragmas on CompiledMethod has to do that: ```smalltalk pragmas | selectorOrProperties | ^(selectorOrProperties := self penultimateLiteral) isMethodProperties ifTrue: [selectorOrProperties pragmas] ifFalse: [#()] ``` Just to avoid creating an empty array via the streamContents: method. Which, if you ask for pragmas of all methods, does matter. And this is what "Senders Of" does... And this is very, very strange. In the past this lead to very odd things like "sender of" for #isFFIMethod giving all method that had the property #isFFIMethod set. (I fixed that already) I propose to clean this up. **Proposal** I want to have a clear layer: properties are there to add state to CompiledMethods, the Pragma implementation just uses this lower level layer. AdditionalMethodState should have *no* code related to Pragmas. So instead of putting pragmas into the AdditionalMethodState directly, we just add one property #pragmas for those methods where pragmas are used. The compiler then pre-allocates the array and puts it there. (Pragmas are statically known, properties can be set and removed at runtime). Which means that on CompiledMethod, we just have: ```smalltalk pragmas ^ self propertyAt: #pragmas ifAbsent: [ #() ] ``` pragmas and pragmasDo: on AdditionalMethodState can be removed, we can remove the propertyAt* API there and just use the Dictionary API (which makes sense, as AdditionalMethodState is just a property dictionary with a backpointer) The only thing we need to do for this to work is to change the code in the compiler backend to be: ```smalltalk addPragma: aPragma properties ifNil: [ properties := AdditionalMethodState new ]. properties at: #pragmas ifAbsent: [ properties := properties copyWith: #pragmas -> #( ) ]. properties at: #pragmas put: ((properties at: #pragmas) copyWith: aPragma) ``` (bit ugly... need to use copyWith: as the high level API needs the compiledMethod set in the AdditionalMethodState) And some smaller changes here and there (e.g. setting the backpointer in pragmas after the compiledMethod is created). I did first implementation, It seems to work but this showed that we have to take care with the bootrap. (see [here](https://github.com/pharo-project/pharo/pull/7930/files) for the closed PR)

March 24, 2021

[ANN] Next Pharo Sprint: March 26

by Marcus Denker

We will organize a Pharo sprint / Moose dojo March 26 Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

March 24, 2021

Re: Pharo - GSOC 2021

by askoh

Congratulations indeed. Is there a mailing list to get on to be informed about Pharo GSOC 2021. I have a project at https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… but I haven't received any announcements from organizers. Please advise. Thanks, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 22, 2021

Progress Report -> Refactoring Project - ( March 15 - 19 )

by Evelyn Cusi Lopez

Hello all, Last week I did these tasks: - Fix issue: "Remove Senders Of Method" refactoring <https://github.com/pharo-project/pharo/pull/8843>. This refactoring can be useful when it is necessary to remove method's senders before eliminating it, in order not to leave corrupted code, its main function is remove all those senders whose result is not used directly. For more details check the PR comments. - Fix issue: "Improve extract method refactoring" <https://github.com/pharo-project/pharo/pull/8847>. Now works with pillar example described in the issue #8786 <https://github.com/pharo-project/pharo/issues/8786> - Fix issue: "Rename vars of traits users". <https://github.com/pharo-project/pharo/pull/8848> With the new update this refactoring now renames the instance variables written and read from the trait and its users. At the moment this refactoring correctly renames those references where the variable is read or written, for example if we have the following examples: ``` MyClass >> msg1 var1 asString MyClass >> msg2 var1 ``` the variable #var1 of #msg1 will be renamed but the instVar of #msg2 will no. - Start to add the use of scopes when we use a refactoring, to change the environment when we apply the transformation. Tasks for this week: <https://github.com/pharo-project/pharo/issues/8710> - Finish scopes in refactorings. - Add previews for refactoring, using a scope's selector to apply the refactoring. <https://github.com/pharo-project/pharo/issues/6218> - Improve extract setUp method refactoring. - Fix issue: move to component refactoring issue. <https://github.com/pharo-project/pharo/issues/8499> - Fix issue: <https://github.com/pharo-project/pharo/issues/2617>Rewritting tool fails to place a cascade inside a cascade <https://github.com/pharo-project/pharo/issues/2617> - Fix issue: Revisiting all the tests (RB) to make sure that they work in presence of fluid definition #7475 <https://github.com/pharo-project/pharo/issues/7475> Regards, Evelyn C.

March 22, 2021

This week (11/2021) on the Pharo Issue Tracker

by Marcus Denker

We merged 40 Pull requests and closed 44 open issue tracker entries. Spec v0.8.5 ============ - fixed an error on SpCodePresenter and using <meta+g>. - fixed also what happens when there is an error and we are in the middle of a <meta+g> - enhanced how styles show focus border. - added a basic spinner presenter (that is there when is visible and not there when is hidden) - handling properly the change of toolbars on window presenters - fixed shortcut printing on menu items - fixes pharo-project/pharo#8776 Roassal 0.9.7b ============= - upgrading Pharo 9 with Roassal 0.9.7b #8798 https://github.com/pharo-project/pharo/pull/8798 - Pharo should follow UML rules #8718 https://github.com/pharo-project/pharo/issues/8718 Refactoring =========== - RB - Introduce new refactoring "Copy package" #8781 https://github.com/pharo-project/pharo/pull/8781 - RB - Improve refactoring comments #8788 https://github.com/pharo-project/pharo/pull/8788 Compiler ========= - 8701-Class-references-show-incorrect-results-when-there-are-super-sends-in-blocks #8802 https://github.com/pharo-project/pharo/pull/8802 - 8694-Instance-of-DoItVariable-did-not-understand-markRead #8774 https://github.com/pharo-project/pharo/pull/8774 - Compiler-Cleanup-OCAbortCompilation #8787 https://github.com/pharo-project/pharo/pull/8787 Featues ====== - Update UnhandledError to reflect the ability for the underlying Exception to resume. #8772 https://github.com/pharo-project/pharo/pull/8772 - Add 'Add new test case' menu #8704 https://github.com/pharo-project/pharo/pull/8704 - Added the possibility to create a new method in the class definition tab #8773 https://github.com/pharo-project/pharo/pull/8773 Fixes ==== - 8185-When-fluid-class-RGClassDefinitionTest-has-one-test-failing #8780 https://github.com/pharo-project/pharo/pull/8780 - Fixes: #8773 Now we can compile methods in class pane. #8795 https://github.com/pharo-project/pharo/pull/8795 - use new evaluation method (fixes playground) #8826 https://github.com/pharo-project/pharo/pull/8826 - 8195-Moving-message-refactoring-is-broken-in-the-implementors-browser #8805 https://github.com/pharo-project/pharo/pull/8805 - 8775-Press-red-exclamation-mark-on-the-middle--raises-an-error #8777 https://github.com/pharo-project/pharo/pull/8777 - validate callback failure on exit #8610 https://github.com/pharo-project/pharo/pull/8610 - Fix #8656 Process class >> #forContext:priority: potentially crashing an image #8706 https://github.com/pharo-project/pharo/pull/8706 - Configuring the spec debugger to force contexts stepping into quick methods #8763 https://github.com/pharo-project/pharo/pull/8763 - Update misleading comments in the LibC class #8783 https://github.com/pharo-project/pharo/pull/8783 - 8669 aFloat asScaledDecimal loses precision #8784 https://github.com/pharo-project/pharo/pull/8784 - Changed ClyOldMessageBrowserAdapter>>open to using realParent to handle cases where parent is nil #8779 https://github.com/pharo-project/pharo/pull/8779 - Fixes: #7963 - does not use broken primitives. #8769 https://github.com/pharo-project/pharo/pull/8769 Issue Tracker ============= Enhance The Bug request template with Pharo version #6308 https://github.com/pharo-project/pharo/issues/6308 Modify heading Describe the bug , Describe the request #7957 https://github.com/pharo-project/pharo/issues/7957 Cleanups: Unused Variables =========================== Nearly there... - testNoUnusedInstanceVariablesLeft-down-25 #8799 https://github.com/pharo-project/pharo/pull/8799 - 8695-FTSizeRec-declares-class-variables-without-referencing #8801 https://github.com/pharo-project/pharo/pull/8801 - 1012-SpTestPresenterWithToolbar-has-class-var-that-is-not-referenced https://github.com/pharo-spec/Spec/pull/1016 - SpRoassal3InspectorPresenter has unused instance Variable #339 https://github.com/ObjectProfile/Roassal3/issues/339 Cleanup: Uncategorized Methods ============================== We added #testNoUncategorizedMethods testing for the number we have now Cleaning up will take a while, but is on the way - 8761-Add-a-release-test-for-unclassified-methods #8806 https://github.com/pharo-project/pharo/pull/8806 - Categorize uncategorized methods in classes starting with L #8832 https://github.com/pharo-project/pharo/pull/8832 - Categorize uncategorized methods in classes starting with O #8838 https://github.com/pharo-project/pharo/pull/8838 - Categorize uncategorized methods in classes starting with N #8836 https://github.com/pharo-project/pharo/pull/8836 - Categorize uncategorized methods in classes starting with I #8830 https://github.com/pharo-project/pharo/pull/8830 - Categorize uncategorized methods in classes starting with P #8840 https://github.com/pharo-project/pharo/pull/8840 - Categorize uncategorized methods in classes starting with G #8824 https://github.com/pharo-project/pharo/pull/8824 - Categorize uncategorized methods in classes starting with F #8822 https://github.com/pharo-project/pharo/pull/8822 - Categorize uncategorized methods in classes starting with E #8820 https://github.com/pharo-project/pharo/pull/8820 - Categorize uncategorized methods in classes starting with D #8819 https://github.com/pharo-project/pharo/pull/8819 - Categorize uncategorized methods in classes starting with C #8816 https://github.com/pharo-project/pharo/pull/8816 - Categorize uncategorized methods in classes starting with B #8811 https://github.com/pharo-project/pharo/pull/8811 - Categorize uncategorized methods in classes starting with A #8808 https://github.com/pharo-project/pharo/pull/8808

March 19, 2021