- Pharo-dev - lists.pharo.org

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

by Marcus Denker

We merged 60 PRs, closed 76 issues Features ======== - Add #ensureOpen to Trascript to not open multiple transcripts while sâ¦ #12588 https://github.com/pharo-project/pharo/pull/12588 - Improve ReImplementedNotSentRule to ignore self calls + add tests #12585 https://github.com/pharo-project/pharo/pull/12585 - Adding an accessor for the root nodes of the settings browser #12521 https://github.com/pharo-project/pharo/pull/12521 Speed ===== - Disable setting formatIncompleteIdentifiers by default #12475 https://github.com/pharo-project/pharo/pull/12475 Fixes ===== - 12418-MCMethodDefinition-asSymbol-error-when-catString-isNil-loading-BaselineOf #12589 https://github.com/pharo-project/pharo/pull/12589 - Improve robustess of DependencyAnalyzer #12581 https://github.com/pharo-project/pharo/pull/12581 - 12518-ImageCleaner-shareLiterals-shouldnt-consider-Strings-and-Symbols-the-same #12529 https://github.com/pharo-project/pharo/pull/12529 - fix #12573: Error due to deprecated wantsStepsIn: on "senders of" #12574 https://github.com/pharo-project/pharo/pull/12574 - Fix DrTest UI when plugin selection change #12468 https://github.com/pharo-project/pharo/pull/12468 - Fix #12408, remove containerTabs from the notebook and not from the owner submorphs #12464 https://github.com/pharo-project/pharo/pull/12464 - Extract set up now classify setUp in #running #12512 https://github.com/pharo-project/pharo/pull/12512 Compiler ======== - Compiler: enable optionInlineTimesRepeat and optionInlineRepeat by default #12604 https://github.com/pharo-project/pharo/pull/12604 - add a "parse plugin" mechanism to OpalCompiler #12429 https://github.com/pharo-project/pharo/pull/12429 Refactoring Engine ================== - FindAndReplaceRefactoring is a transformation #12495 https://github.com/pharo-project/pharo/pull/12495 - Cleanup unused refactorings #12531 https://github.com/pharo-project/pharo/pull/12531 Tools ===== - Use the list of VM parameters from the pharo image. #448 https://github.com/pharo-spec/NewTools/pull/448 - Improved debugger symbol diff in failing tests #462 https://github.com/pharo-spec/NewTools/pull/462 - fix test of Sindarin when timesRepeat: is optimized #461 https://github.com/pharo-spec/NewTools/pull/461 - Integrating JumpToCaret command from Sindarin to the advanced step menu in the debugger toolbar #428 https://github.com/pharo-spec/NewTools/pull/428 - 377-Uncategorised-method-in-StDebuggerCommandtransform #433 https://github.com/pharo-spec/NewTools/pull/433 - Double click on the debugger stack browse the method #460 https://github.com/pharo-spec/NewTools/pull/460 - Spotter Insert selection setting #454 https://github.com/pharo-spec/NewTools/pull/454 - Fix spotter bug while clicking a header #455 https://github.com/pharo-spec/NewTools/pull/455 - Simplifying code in settings commands #459 https://github.com/pharo-spec/NewTools/pull/459 - Debugger-Actions are legacy code from the previous debugger. #458 https://github.com/pharo-spec/NewTools/pull/458 CI related ========== - fix transcript output testIgnoreDeprecationWarnings #12603 https://github.com/pharo-project/pharo/pull/12603 - skip the test testNewProcessTaskRunnerRunsInNewProcessEveryTime on the CI #12530 https://github.com/pharo-project/pharo/pull/12530 Documentation ============= - 12498-Documentation-fix-for-Dictionary--keysAndValuesDo #12580 https://github.com/pharo-project/pharo/pull/12580 - add block ast node stats code as class comment #12606 https://github.com/pharo-project/pharo/pull/12606 - comment to explicit class size initialize behavior #12463 https://github.com/pharo-project/pharo/pull/12463 Cleanup ======= - Remove debugger actions #12515 https://github.com/pharo-project/pharo/pull/12515 - 5500-Ban-rule-on-testReadComputedSlotCompiled #12523 https://github.com/pharo-project/pharo/pull/12523 - 11142-TestRunner--classNamesNotUnderTest-is-sent-but-not-implemented #12525 https://github.com/pharo-project/pharo/pull/12525 - Remove SourceCodeFont setting that has no effect #12522 https://github.com/pharo-project/pharo/pull/12522 - Stepping mecanisme should be used by model and morph. But it is curreâ¦ #12510 https://github.com/pharo-project/pharo/pull/12510 - 12080-Dead-code-viewContentsInWorkspace #12524 https://github.com/pharo-project/pharo/pull/12524 - remove dead code with wikiStyleHelp: pragma #12582 https://github.com/pharo-project/pharo/pull/12582 - Add <ignoreForCoverage> to methods generated by the manifest builder #12583 https://github.com/pharo-project/pharo/pull/12583 - Rename PlatformIndependentEnvironment into NullOSEnvironment #12520 https://github.com/pharo-project/pharo/pull/12520 - extract return from ifTrueifFalse expression #12561 https://github.com/pharo-project/pharo/pull/12561 - 22 x cleanups of the kind Cleanup: Condense Reflectivity packages #12601 https://github.com/pharo-project/pharo/pull/12601 - Remove use of deprecated classes #1351 https://github.com/pharo-spec/Spec/pull/1351 - Remove use of deprecated classes #1351 https://github.com/pharo-spec/Spec/pull/1351

Feb. 10, 2023

GSoC idea: a code generation model for smalltalk

by Nicolas Anquetil

hello, this paper : "An Empirical Comparison of Pre-Trained Models of Source Code" https://arxiv.org/pdf/2302.04026.pdf studied "19 recently-developed pre-trained models of source code" I am a complete noob in this domain, but wouldn't it be possible to use one of these to train it on smalltalk code and get an advanced code completion tool from that ? nicolas

Feb. 9, 2023

[Help needed] Please check your old issue tracker entries!

by Marcus Denker

Hi, We waste a lot of time with - turning prose descriptions of fixes into code - trying to fix bugs that are already fixed - trying to understand issues that have just not enough infos One thing that would help: If everyone would regularly check their old issue tracker entries. I think what happens is that when bugs get fixed, everyone assumes that of course the issue gets closed, too But that is not happening due to multiple reasons: - Duplicated entries. The *other one* was closed, but not yours - Fixes happening e.g. due to code rewrites The easiest is to use the created_by feature: https://github.com/pharo-project/pharo/issues/created_by/MarcusDenker - check if the issue is still relevant - has it been fixed? - is the description understandable? - if it has a suggestion of a fix, do a PR. (it is much harder to turn prose into code than you would think!) Marcus

Feb. 8, 2023

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

by Marcus Denker

We merged 39 PRs and closed 77 issues. If you want to help, there are 29 PRs: https://github.com/pharo-project/pharo/pulls Features ======== - Introduce new string comparison primitive #12504 https://github.com/pharo-project/pharo/pull/12504 - Profiler: simplify world menu #12501 https://github.com/pharo-project/pharo/pull/12501 - ReSentNotImplementedRule: take Pragma into account #12295 https://github.com/pharo-project/pharo/pull/12295 - 12431 Better user experience for final dot critique and cleaning #12455 https://github.com/pharo-project/pharo/pull/12455 - Fix #3067: Float>>#closeTo: does not use Float>>epsilon as default precision #12451 https://github.com/pharo-project/pharo/pull/12451 - Fix #3332: New package committed by Iceberg is always dirty #12453 https://github.com/pharo-project/pharo/pull/12453 - Fix #12287 adding group model to parent window #12446 https://github.com/pharo-project/pharo/pull/12446 - Improving the ChangesBrowser presenter #12438 https://github.com/pharo-project/pharo/pull/12438 - [improvement] better default hierarchy display #11053 https://github.com/pharo-project/pharo/pull/11053 - Complete symbols #11918 https://github.com/pharo-project/pharo/pull/11918 - convert numpad keys with NumLock turned off #12258 https://github.com/pharo-project/pharo/pull/12258 Speed ===== - 12128-Poor-performance-with-large-WriteStreams #12205 https://github.com/pharo-project/pharo/pull/12205 Fixes ===== - Honor theme changed events #12473 https://github.com/pharo-project/pharo/pull/12473 - fix: DeprecateClassCommand DNU #12494 https://github.com/pharo-project/pharo/pull/12494 - Fix conflict between formatter and rules: spaces before new lines #12448 https://github.com/pharo-project/pharo/pull/12448 - 11968-Clean-Blocks-Jobowner-assumes-valid-outerContext #12055 https://github.com/pharo-project/pharo/pull/12055 - Re-introduce list morph shortcuts using keydown #12386 https://github.com/pharo-project/pharo/pull/12386 CI related ========== - 12508-CI-failing-test-RBReplaceSubtreeTransformationTesttestTransformOneOfManyStatements #12509 https://github.com/pharo-project/pharo/pull/12509 - 12440-CI-failing-test-testClassSideInitializeMethodNeedsToBeInClassInitializationProtocol #12442 https://github.com/pharo-project/pharo/pull/12442 - Fix dependencies tests #12449 https://github.com/pharo-project/pharo/pull/12449 Cleanups ======== - Fix #3172: parseTreeFor: asymbol should be renamed parseTreeOfMethodNamed: aSymbol #3172 #12452 https://github.com/pharo-project/pharo/pull/12452 - Removed duplicated line form RubSmalltalkEditor>>tallySelection #12437 https://github.com/pharo-project/pharo/pull/12437 - Extracting the logic of screenshot and selection #11254 https://github.com/pharo-project/pharo/pull/11254 - Review if #scanToken: in RBScanner is still needed #11554 https://github.com/pharo-project/pharo/pull/11554 - Clean some duplication logic by extracting Smalltalk tools into a sepâ¦ #12085 https://github.com/pharo-project/pharo/pull/12085 - move emit from Announcement to Object #12266 https://github.com/pharo-project/pharo/pull/12266 Trivial Cleanups ================ - 9 x cleanups of the kind Cleanup: Condense NECompletion packages #12485 https://github.com/pharo-project/pharo/pull/12485 - 2x cleanups of the kind extract return from ifTrue: ifFalse: and remove white spaces #12476 https://github.com/pharo-project/pharo/pull/12476

Feb. 3, 2023

Re: Code quality: tagging unsent selectors (e.g. in tests)

by Marcus Denker

Thanks, I will take some notes for a future âbetter code meta dataâ project. For now I propose to merge the PR as a first step. Marcus > On 26 Jan 2023, at 18:52, Daniel Slomovits <daniels220(a)gmail.com> wrote: > > A bit of perspective on other approaches to this problem: > > In Dolphin Smalltalk, the FFI mechanism uses #doesNotUnderstand: to implement getters and setters on external structs, so it already has a mechanism for ensuring they aren't flagged as unimplemented. In addition to the standard ClassDescription>>selectors, which is more-or-less the actual keys of the methodDictionary, there is #understoodSelectors, which is explicitly a hook to include others understood via #doesNotUnderstand:. These are then treated exactly as actually-implemented selectors, that is, they are available for autocomplete as well as not being flagged as unimplemented. > > Also, I believe the unimplemented-selectors rule applies only to non-self-sends, and there is a separate rule for self-sends which instead just asks the class if it #canUnderstand: the selector, which creates a middle ground where the selector is not "known" to the system at large, but won't be warned about if self-sent. > > The pragma approach has the advantage of being more specific, which is useful if a certain selector is valid only in a very narrow context and should still be warned about in general. Conversely, the disadvantage is that it needs to be repeated everywhere the message is sent, rather than centralized on the class where it is implemented/understood. I assume it also does not influence autocomplete. So, for cases that are valid in a broader scope, it creates the extra work of adding the pragma, and you have to type out the actual send manually, multiplied for each time it's usedâlots of repetition. Fundamentally we're running up against the limitations of a dynamically-typed language here. > > Long story short, I think both options may be useful. In my own usage I find it's about 50/50âsome cases of one-offs in a test, other cases of a widely-used class with some dynamic behavior. I do like the pragma as an improvement over rule banning for sure. Looking towards improving rule banning, I think it's very important for that to be (a) highly visible (and nothing is more visible than something that's part of the source code) and (b) manageable via source control (which metadata certainly can beâcategories, for instance, already are). Call me old-fashioned, but for all the wonders of the image, there's something to be said for having a limited set of concepts in a "dead text" format that fully describe everything about the codeâand if there are too many separate pieces of UI presenting information, it's easy to forget that some of them exist. But this is a discussion for another thread I think. > > On Thu, Jan 26, 2023 at 5:48 AM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> > On 26 Jan 2023, at 11:27, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> > >> > >> > >> >> On 26 Jan 2023, at 11:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr <mailto:nicolas.anquetil@inria.fr>> wrote: >> >> >> >> correct me if I am wrong, but one can already deactivate a rule in Nautilus on a perpackage/class/method basis. >> >> >> >> So why not use this mechanism instead of having yet another pragma >> >> >> > >> > Because disabeling the rule disables it for *all* selectors >> > >> >> (there is a whole universe of pragmas hidden in the code) >> > >> > But the pragma is less hidden than the banned rule, which is completely invisible. >> > >> >> The whole rule banning meta data storage is very very limited right nowâ¦ e.g it does never get cleaned, is never updated >> if the code it annotates changes and has many problems. >> >> The long-term solution I want to do is to improve meta-data for code storage and use it for the rule banning >> and for things we might abuse pragmas now. >> >> But that will no be soon, and there are lots of things to be taken into account for a nice design. >> >> For me the pragma is a nice intermediate solution: per selector, survives rename of method, rename of >> class, move method, is visibleâ¦ >> >> Marcus >>

Jan. 30, 2023

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

by Marcus Denker

This week, we merged 28 Pull requests, fixing 31 issues Fixes ===== - Update BaselineOfPharo with Roassal3 version v0.9.9L #12430 https://github.com/pharo-project/pharo/pull/12430 - checkIfMustRefresh in OmBlockFileStore>>blockForLocalNameAsInteger: #12197 https://github.com/pharo-project/pharo/pull/12197 - Fix for multiple Epicea issues #12375 https://github.com/pharo-project/pharo/pull/12375 - FIX CI issues - FFIExternalString>>#basicHandle:at: calls deprecated message #12405 https://github.com/pharo-project/pharo/pull/12405 - Fix for "Browse this version in Calypso" Error after clicking an unloaded package #12423 https://github.com/pharo-project/pharo/pull/12423 - 12410-Minimal-Image-does-not-open-ChangesFile-correctly #12411 https://github.com/pharo-project/pharo/pull/12411 - fix testTallyInstructions #12393 https://github.com/pharo-project/pharo/pull/12393 - Spotter is broken> DNU #tools #12397 https://github.com/pharo-project/pharo/pull/12397 Cleanups ======== - RubScrolledTextMorph>>#mouseWheel: sends unimplemented message #scrolâ¦ #12402 https://github.com/pharo-project/pharo/pull/12402 - 12416-Fixing-Classes-Reported-by-NoUnusedVariablesLeftTest #12417 https://github.com/pharo-project/pharo/pull/12417 - 12413-Improving-the-dependency-of-Formatter-Settings-with-EFFormatter #12414 https://github.com/pharo-project/pharo/pull/12414 - Move #asNumber from AST-Core to Kernel (where it is also already tested) #12388 https://github.com/pharo-project/pharo/pull/12388 - extract return from ifTrue:ifFalse: in Integer>>#printStringRadix: #12433 https://github.com/pharo-project/pharo/pull/12433 - 11x Cleanups of the kind Cleanup: Condense Calypso packages #12284 https://github.com/pharo-project/pharo/pull/12284 this Changelog is archived at https://github.com/pharo-project/pharo-changelogs/blob/master/weekly/2023/4…

Jan. 27, 2023

Re: Code quality: tagging unsent selectors (e.g. in tests)

by Daniel Slomovits

A bit of perspective on other approaches to this problem: In Dolphin Smalltalk, the FFI mechanism uses #doesNotUnderstand: to implement getters and setters on external structs, so it already has a mechanism for ensuring they aren't flagged as unimplemented. In addition to the standard ClassDescription>>selectors, which is more-or-less the actual keys of the methodDictionary, there is #understoodSelectors, which is explicitly a hook to include others understood via #doesNotUnderstand:. These are then treated exactly as actually-implemented selectors, that is, they are available for autocomplete as well as not being flagged as unimplemented. Also, I believe the unimplemented-selectors rule applies only to non-self-sends, and there is a separate rule for self-sends which instead just asks the class if it #canUnderstand: the selector, which creates a middle ground where the selector is not "known" to the system at large, but won't be warned about if self-sent. The pragma approach has the advantage of being more specific, which is useful if a certain selector is valid only in a very narrow context and should still be warned about in general. Conversely, the disadvantage is that it needs to be repeated everywhere the message is sent, rather than centralized on the class where it is implemented/understood. I assume it also does not influence autocomplete. So, for cases that are valid in a broader scope, it creates the extra work of adding the pragma, *and* you have to type out the actual send manually, multiplied for each time it's usedâlots of repetition. Fundamentally we're running up against the limitations of a dynamically-typed language here. Long story short, I think both options *may* be useful. In my own usage I find it's about 50/50âsome cases of one-offs in a test, other cases of a widely-used class with some dynamic behavior. I do like the pragma as an improvement over rule banning for sure. Looking towards improving rule banning, I think it's very important for that to be (a) highly visible (and nothing is more visible than something that's part of the source code) and (b) manageable via source control (which metadata certainly *can* beâcategories, for instance, already are). Call me old-fashioned, but for all the wonders of the image, there's something to be said for having a limited set of concepts in a "dead text" format that fully describe everything about the codeâand if there are too many separate pieces of UI presenting information, it's easy to forget that some of them exist. But this is a discussion for another thread I think. On Thu, Jan 26, 2023 at 5:48 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On 26 Jan 2023, at 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > > > >> On 26 Jan 2023, at 11:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> > wrote: > >> > >> correct me if I am wrong, but one can already deactivate a rule in > Nautilus on a perpackage/class/method basis. > >> > >> So why not use this mechanism instead of having yet another pragma > >> > > > > Because disabeling the rule disables it for *all* selectors > > > >> (there is a whole universe of pragmas hidden in the code) > > > > But the pragma is less hidden than the banned rule, which is completely > invisible. > > > > The whole rule banning meta data storage is very very limited right nowâ¦ > e.g it does never get cleaned, is never updated > if the code it annotates changes and has many problems. > > The long-term solution I want to do is to improve meta-data for code > storage and use it for the rule banning > and for things we might abuse pragmas now. > > But that will no be soon, and there are lots of things to be taken into > account for a nice design. > > For me the pragma is a nice intermediate solution: per selector, survives > rename of method, rename of > class, move method, is visibleâ¦ > > Marcus > >

Jan. 26, 2023

Re: Code quality: tagging unsent selectors (e.g. in tests)

by Marcus Denker

> On 26 Jan 2023, at 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 26 Jan 2023, at 11:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: >> >> correct me if I am wrong, but one can already deactivate a rule in Nautilus on a perpackage/class/method basis. >> >> So why not use this mechanism instead of having yet another pragma >> > > Because disabeling the rule disables it for *all* selectors > >> (there is a whole universe of pragmas hidden in the code) > > But the pragma is less hidden than the banned rule, which is completely invisible. > The whole rule banning meta data storage is very very limited right nowâ¦ e.g it does never get cleaned, is never updated if the code it annotates changes and has many problems. The long-term solution I want to do is to improve meta-data for code storage and use it for the rule banning and for things we might abuse pragmas now. But that will no be soon, and there are lots of things to be taken into account for a nice design. For me the pragma is a nice intermediate solution: per selector, survives rename of method, rename of class, move method, is visibleâ¦ Marcus

Jan. 26, 2023

Re: Code quality: tagging unsent selectors (e.g. in tests)

by Marcus Denker

> On 26 Jan 2023, at 11:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > correct me if I am wrong, but one can already deactivate a rule in Nautilus on a perpackage/class/method basis. > > So why not use this mechanism instead of having yet another pragma > Because disabeling the rule disables it for *all* selectors > (there is a whole universe of pragmas hidden in the code) But the pragma is less hidden than the banned rule, which is completely invisible. Marcus

Jan. 26, 2023

Re: Code quality: tagging unsent selectors (e.g. in tests)

by Nicolas Anquetil

correct me if I am wrong, but one can already deactivate a rule in Nautilus on a perpackage/class/method basis. So why not use this mechanism instead of having yet another pragma (there is a whole universe of pragmas hidden in the code) nicolas On 26/01/2023 10:46, Marcus Denker wrote: > Hi, > > If you have in your code a message send with a selector that is not implemented anywhere, it likely will result in a DNU > > - but not if you compile a method on the fly (used in tests often) > - if the DNU is catched (e.g. for a proxy pattern) > - if the code is compatibility code, never executed in this version of the system > > > We can ban the rule, but that just stopps checking for the whole method for all selectors, what we want is to communicate that *this selector* is ok in this > special use (per method granularity is ok). > > SystemNaviation>>#allUnimplementedCalls did have the feature that one can tag selectors that should be ignored. This uses the pragma #ignoreUnimplementedCalls: > > see > Context class >> initializePrimitiveSimulators > > > <ignoreUnimplementedCalls: #(#registerPrimitiveSimulators)> > > This was used in just one method, I think because a) the rule did not take it into account and b) the terminology is just wrong (âCallâ). > > I think > > - ReSentNotImplementedRule should takes this pragma into account > - change the bad terminology âallUnimplementedCalls" > - use pragma: <ignoreNotImplementedSelectors: > > > > PR is here: https://github.com/pharo-project/pharo/pull/12295 > > > (what the PR does not yet do is to change syntax highlight to not color the selector red, this could be done later, too) -- Nicolas Anquetil RMod team -- Inria Lille

Jan. 26, 2023