Bug description
For the latest P14, I encountered that it did not include settings for all the rules I have banned via settings (which normally works automatically when I create a new image). I changed the code critics rule settings (Section Quality Assistant) to "false" for the rules I wanted to ban and finaly reset the rule cache. Then I noticed that there is no more "save settings" button, but instead only an "Export" button. After export, 2 files that were new to me had been created, named "system-settings.stonX.st" with X being 1 and 2. These files contain several StartupAction entries, also including my rule settings. So far ok, as my image behaved according to changed code critics rules. When I started the saved image for the next time, I first ran into one DNU resulting from a StartupAction entry executed at end of image load:
Class StPulse didNotUnderstand: #resetHistory:
After inspecting this class, I noticed that the message presumably would be working was #resetHistory without argument. When I tried that, I ended up with the next failure on the same pattern (class method called with one argument not existing, equivalent zero-arg method however existing).
Overall, the following classes and selectors were affected in the following files:
- system-settings.ston1.st
- Class StPulse: #resetHistory(:), #resetSize(:)
- system-settings.ston2.st
- Class ReRuleManager: #resetWithInform(:)
- Class IceTipCredentialsSettings: #editButtonAction(:)
To Reproduce
"Export" any settings such that the files mentioned above will be created. Then the generated code for the mentioned StartupAction entries should be wrong, at least for build:
Pharo-14.0.0+SNAPSHOT.build.732.sha.a83e1162ba04be9a0f0eda10610aef3ef43a1dd5 (64 Bit)
7 July 2026
Expected behavior
First of all, there should be no code exported that fails due to DNU.
On a second glance, IMHO the whole construction will be a future source of many failures - e.g. when I restart a P14 image created only a few weeks ago, I now get an error dialog due to an option that has been introduced recently in a different way, and now is included in StartupActions that are not supported by earlier releases (in my case: GraphicFontSettings did not understand: #font:). As all images use the same startup preferences, you cannot even expect older images of the same main version to be still working after you once exported the latest version of settings.
Last but not least the code design of dealing with StartupAction is very low quality IMHO. Using Smalltalk globals at: #SomeClass along with #perform: is technicall general, without doubt, but at a high risk. And what is that clumsy globals at: good for, if for a #perform:with: argument, the simple class name is used as literal? I would really prefer a kind of StartupAction implementation that uses a class name, a startupAction selector and optional arguments instead doing that barebone direct calls. Then any class that wants to support startup actions should implement something like startupAction: aSelector arguments: args handler: aBlock and then can delegate back to the StartupAction in case of a newly introduced option that is called for an older pharo release. Maybe even a version id "from" should be included in the startupAction:* signature. And yes, that is a bit more work than just generating (Smalltalk globals at: #MyClass) perform: selector, but the current kind of solution just delegates every problem to the pharo user (like me in this case) which can be expected to strongly multiply in the future, as it will be harder, not easier, to find out which settings are valid for which releases.
Version information:
OS: W11, Pharo-14.0.0+SNAPSHOT.build.732.sha.a83e1162ba04be9a0f0eda10610aef3ef43a1dd5 (64 Bit)
7 July 2026
Further context
As the author of issue 18558, @belaroesener, worked on that issue on my behalf, I am really interested to know what is the supported way to control quality assistant rule settings in advance before creating a new image. For my first P14 release at start of June, the system-settings.ston still worked to ban the rules configured there. For the current release, it seems to me that this file is ignored, at least concerning the rule settings (else I would not have been run into the issue here). What is the official way to inject own rule settings as early as possible?
Bug description
For the latest P14, I encountered that it did not include settings for all the rules I have banned via settings (which normally works automatically when I create a new image). I changed the code critics rule settings (Section Quality Assistant) to "false" for the rules I wanted to ban and finaly reset the rule cache. Then I noticed that there is no more "save settings" button, but instead only an "Export" button. After export, 2 files that were new to me had been created, named "system-settings.stonX.st" with X being 1 and 2. These files contain several
StartupActionentries, also including my rule settings. So far ok, as my image behaved according to changed code critics rules. When I started the saved image for the next time, I first ran into one DNU resulting from a StartupAction entry executed at end of image load:Class StPulse didNotUnderstand: #resetHistory:After inspecting this class, I noticed that the message presumably would be working was #resetHistory without argument. When I tried that, I ended up with the next failure on the same pattern (class method called with one argument not existing, equivalent zero-arg method however existing).
Overall, the following classes and selectors were affected in the following files:
To Reproduce
"Export" any settings such that the files mentioned above will be created. Then the generated code for the mentioned
StartupActionentries should be wrong, at least for build:Pharo-14.0.0+SNAPSHOT.build.732.sha.a83e1162ba04be9a0f0eda10610aef3ef43a1dd5 (64 Bit)
7 July 2026
Expected behavior
First of all, there should be no code exported that fails due to DNU.
On a second glance, IMHO the whole construction will be a future source of many failures - e.g. when I restart a P14 image created only a few weeks ago, I now get an error dialog due to an option that has been introduced recently in a different way, and now is included in StartupActions that are not supported by earlier releases (in my case:
GraphicFontSettings did not understand: #font:). As all images use the same startup preferences, you cannot even expect older images of the same main version to be still working after you once exported the latest version of settings.Last but not least the code design of dealing with
StartupActionis very low quality IMHO. UsingSmalltalk globals at: #SomeClassalong with#perform:is technicall general, without doubt, but at a high risk. And what is that clumsyglobals at:good for, if for a #perform:with: argument, the simple class name is used as literal? I would really prefer a kind of StartupAction implementation that uses a class name, a startupAction selector and optional arguments instead doing that barebone direct calls. Then any class that wants to support startup actions should implement something likestartupAction: aSelector arguments: args handler: aBlockand then can delegate back to the StartupAction in case of a newly introduced option that is called for an older pharo release. Maybe even a version id "from" should be included in thestartupAction:*signature. And yes, that is a bit more work than just generating(Smalltalk globals at: #MyClass) perform: selector, but the current kind of solution just delegates every problem to the pharo user (like me in this case) which can be expected to strongly multiply in the future, as it will be harder, not easier, to find out which settings are valid for which releases.Version information:
OS: W11, Pharo-14.0.0+SNAPSHOT.build.732.sha.a83e1162ba04be9a0f0eda10610aef3ef43a1dd5 (64 Bit)
7 July 2026
Further context
As the author of issue 18558, @belaroesener, worked on that issue on my behalf, I am really interested to know what is the supported way to control quality assistant rule settings in advance before creating a new image. For my first P14 release at start of June, the system-settings.ston still worked to ban the rules configured there. For the current release, it seems to me that this file is ignored, at least concerning the rule settings (else I would not have been run into the issue here). What is the official way to inject own rule settings as early as possible?