This week (47/2020) on the Issue Tracker

MD
Marcus Denker
Fri, Nov 20, 2020 10:23 AM

Pharo8

HOT-FIX: Support GitHub Personal Access Tokens. This was already merged in
Pharo9 before.

First class Variables

Work continues: some small improvements (e.g. primitve error variables) and cleanups

ReadOnly Literals

Some cleanups... all literals added as literals
are read only, no special code needed anymore.

Graphics

Small Improvements

Fixes

Cleanups

And lots of small cleanups. As always, these are not important
in itself as single items. But over time, taking them all together, they do matter.

Pharo8 ====== HOT-FIX: Support GitHub Personal Access Tokens. This was already merged in Pharo9 before. - Merge Iceberg v1.6.10 in Pharo 8 #7732 https://github.com/pharo-project/pharo/pull/7732 First class Variables ================ Work continues: some small improvements (e.g. primitve error variables) and cleanups - MetaLinks-Cleanup-Variables2 #7742 https://github.com/pharo-project/pharo/pull/7742 - Variables defined with #primitive:error: are shown as undefined, fixes 7748 #7749 https://github.com/pharo-project/pharo/pull/7749 - Cleanup-SystemDictionary-varlookup #7746 https://github.com/pharo-project/pharo/pull/7746 - 7731-OCUndeclaredVariableWarning-isUninitialized-with-NonInteractiveUIManager #7745 https://github.com/pharo-project/pharo/pull/7745 - DoItVariable instead of ForeignVariable and tests #7710 https://github.com/pharo-project/pharo/pull/7710 ReadOnly Literals ============== Some cleanups... all literals added as literals are read only, no special code needed anymore. - Compiler-compile-all-Literals-readOnly #7631 https://github.com/pharo-project/pharo/pull/7631 - #isReadOnlyLiteral is not needed anymore #7767 https://github.com/pharo-project/pharo/pull/7767 - 7740-CI-32bit-testIsImmediateObject #7744 https://github.com/pharo-project/pharo/pull/7744 Graphics ======== - Add support for creating OpenGL ES contexts #7750 https://github.com/pharo-project/pharo/pull/7750 - Disable the dpi based computation screen scale factor computation in OS X #7747 https://github.com/pharo-project/pharo/pull/7747 Small Improvements ================== - 7755 re excessive arguments rule should exclude ffi callouts https://github.com/pharo-project/pharo/pull/7757 - ReLiteralArrayContainsCommaRule should ignore all UFFI selectors #7754 https://github.com/pharo-project/pharo/pull/7754 Fixes ===== - Allow catalog json to be served from GitHub and other #7738 https://github.com/pharo-project/pharo/pull/7738 - Duplicate API from Behavior to RGBehavior. #7743 https://github.com/pharo-project/pharo/pull/7743 Cleanups ========= And lots of small cleanups. As always, these are not important in itself as single items. But over time, taking them all together, they do matter. - Move ReAsClassRule to GeneralRules #7759 https://github.com/pharo-project/pharo/pull/7759 - 5457-environmentKeyNotFound-looks-deadcode #7773 https://github.com/pharo-project/pharo/pull/7773 - ObjectsAsMethodsTest-move-to-Kernel-Tests #7762 https://github.com/pharo-project/pharo/pull/7762 - Typo #7766 https://github.com/pharo-project/pharo/pull/7766 - DeadCode-Cleanup-Finder #7734 https://github.com/pharo-project/pharo/pull/7734 - FFICompilerPlugin-Simpler #7726 https://github.com/pharo-project/pharo/pull/7726 - Small cleanup on ReMissingSuperSendsRule #7761 https://github.com/pharo-project/pharo/pull/7761 - Typo in RGBehaviorDefinition>>#soleInstance #7752 https://github.com/pharo-project/pharo/pull/7752 - Another cleanup pass on DoubleLinkedList package #7736 https://github.com/pharo-project/pharo/pull/7736 - Cleanup System-Support-Tests #7729 https://github.com/pharo-project/pharo/pull/7729 - BaseStreamTest had just one subclass. Move the tests there and remove… #7739 https://github.com/pharo-project/pharo/pull/7739 - NautilusRefactoring-DeadcodeClean #7723 https://github.com/pharo-project/pharo/pull/7723 - Introduce package Collections-Sequenceable-Tests #7719 https://github.com/pharo-project/pharo/pull/7719 - Move-isHaltNode-to-AST #7765 https://github.com/pharo-project/pharo/pull/7765
MD
Marcus Denker
Fri, Nov 20, 2020 11:25 AM

Question: are these mails interesting? Do they have enough information added to
have value?

On 20 Nov 2020, at 11:23, Marcus Denker marcus.denker@inria.fr wrote:

Pharo8

HOT-FIX: Support GitHub Personal Access Tokens. This was already merged in
Pharo9 before.

First class Variables

Work continues: some small improvements (e.g. primitve error variables) and cleanups

ReadOnly Literals

Some cleanups... all literals added as literals
are read only, no special code needed anymore.

Graphics

Small Improvements

Fixes

Cleanups

And lots of small cleanups. As always, these are not important
in itself as single items. But over time, taking them all together, they do matter.

Question: are these mails interesting? Do they have enough information added to have value? > On 20 Nov 2020, at 11:23, Marcus Denker <marcus.denker@inria.fr> wrote: > > > Pharo8 > ====== > HOT-FIX: Support GitHub Personal Access Tokens. This was already merged in > Pharo9 before. > > - Merge Iceberg v1.6.10 in Pharo 8 #7732 > https://github.com/pharo-project/pharo/pull/7732 > > > First class Variables > ================ > > Work continues: some small improvements (e.g. primitve error variables) and cleanups > > - MetaLinks-Cleanup-Variables2 #7742 > https://github.com/pharo-project/pharo/pull/7742 > > - Variables defined with #primitive:error: are shown as undefined, fixes 7748 #7749 > https://github.com/pharo-project/pharo/pull/7749 > > - Cleanup-SystemDictionary-varlookup #7746 > https://github.com/pharo-project/pharo/pull/7746 > > - 7731-OCUndeclaredVariableWarning-isUninitialized-with-NonInteractiveUIManager #7745 > https://github.com/pharo-project/pharo/pull/7745 > > - DoItVariable instead of ForeignVariable and tests #7710 > https://github.com/pharo-project/pharo/pull/7710 > > > ReadOnly Literals > ============== > > Some cleanups... all literals added as literals > are read only, no special code needed anymore. > > - Compiler-compile-all-Literals-readOnly #7631 > https://github.com/pharo-project/pharo/pull/7631 > > - #isReadOnlyLiteral is not needed anymore #7767 > https://github.com/pharo-project/pharo/pull/7767 > > - 7740-CI-32bit-testIsImmediateObject #7744 > https://github.com/pharo-project/pharo/pull/7744 > > > Graphics > ======== > > - Add support for creating OpenGL ES contexts #7750 > https://github.com/pharo-project/pharo/pull/7750 > > - Disable the dpi based computation screen scale factor computation in OS X #7747 > https://github.com/pharo-project/pharo/pull/7747 > > > Small Improvements > ================== > > - 7755 re excessive arguments rule should exclude ffi callouts > https://github.com/pharo-project/pharo/pull/7757 > > - ReLiteralArrayContainsCommaRule should ignore all UFFI selectors #7754 > https://github.com/pharo-project/pharo/pull/7754 > > > Fixes > ===== > - Allow catalog json to be served from GitHub and other #7738 > https://github.com/pharo-project/pharo/pull/7738 > > - Duplicate API from Behavior to RGBehavior. #7743 > https://github.com/pharo-project/pharo/pull/7743 > > > Cleanups > ========= > And lots of small cleanups. As always, these are not important > in itself as single items. But over time, taking them all together, they do matter. > > - Move ReAsClassRule to GeneralRules #7759 > https://github.com/pharo-project/pharo/pull/7759 > > - 5457-environmentKeyNotFound-looks-deadcode #7773 > https://github.com/pharo-project/pharo/pull/7773 > > - ObjectsAsMethodsTest-move-to-Kernel-Tests #7762 > https://github.com/pharo-project/pharo/pull/7762 > > - Typo #7766 > https://github.com/pharo-project/pharo/pull/7766 > > - DeadCode-Cleanup-Finder #7734 > https://github.com/pharo-project/pharo/pull/7734 > > - FFICompilerPlugin-Simpler #7726 > https://github.com/pharo-project/pharo/pull/7726 > > - Small cleanup on ReMissingSuperSendsRule #7761 > https://github.com/pharo-project/pharo/pull/7761 > > - Typo in RGBehaviorDefinition>>#soleInstance #7752 > https://github.com/pharo-project/pharo/pull/7752 > > - Another cleanup pass on DoubleLinkedList package #7736 > https://github.com/pharo-project/pharo/pull/7736 > > - Cleanup System-Support-Tests #7729 > https://github.com/pharo-project/pharo/pull/7729 > > - BaseStreamTest had just one subclass. Move the tests there and remove… #7739 > https://github.com/pharo-project/pharo/pull/7739 > > - NautilusRefactoring-DeadcodeClean #7723 > https://github.com/pharo-project/pharo/pull/7723 > > - Introduce package Collections-Sequenceable-Tests #7719 > https://github.com/pharo-project/pharo/pull/7719 > > - Move-isHaltNode-to-AST #7765 > https://github.com/pharo-project/pharo/pull/7765
SP
Sean P. DeNigris
Fri, Nov 20, 2020 4:25 PM

Marcus Denker-4 wrote

Question: are these mails interesting? Do they have enough information
added to
have value?

Yes! Please continue. I like that they are brief because too much detail can
be overwhelming and we can always ask questions about items that seem
interesting. IHMO the only extra info worth adding (if there's ever the
time) is the "why" - motivation and summaries of internal discussions that
we wouldn't understand just by looking at the commits...


Cheers,
Sean

Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Marcus Denker-4 wrote > Question: are these mails interesting? Do they have enough information > added to > have value? Yes! Please continue. I like that they are brief because too much detail can be overwhelming and we can always ask questions about items that seem interesting. IHMO the only extra info worth adding (if there's ever the time) is the "why" - motivation and summaries of internal discussions that we wouldn't understand just by looking at the commits... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
NB
Noury Bouraqadi
Sat, Nov 21, 2020 9:14 AM

Indeed, posting these emails is useful. It helps keeping us posted about the ongoing progress of Pharo.

I like they are grouped by topic, so it makes easier to get what it's about. Sean's suggestion would indeed understand more. Though I expect it will require more time/effort to write. Moreover, these emails are already long. I'm affraid they'll become way too long.
A solution that mixes both might be posting more often updates. But, again I expect it to be time consuming.
Thanks again Marcus and all Pharo core team,
Noury

On Nov 20 2020, at 5:25 pm, Sean P. DeNigris sean@clipperadams.com wrote:

Marcus Denker-4 wrote

Question: are these mails interesting? Do they have enough information
added to
have value?

Yes! Please continue. I like that they are brief because too much detail can
be overwhelming and we can always ask questions about items that seem
interesting. IHMO the only extra info worth adding (if there's ever the
time) is the "why" - motivation and summaries of internal discussions that
we wouldn't understand just by looking at the commits...


Cheers,
Sean

Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Indeed, posting these emails is useful. It helps keeping us posted about the ongoing progress of Pharo. I like they are grouped by topic, so it makes easier to get what it's about. Sean's suggestion would indeed understand more. Though I expect it will require more time/effort to write. Moreover, these emails are already long. I'm affraid they'll become way too long. A solution that mixes both might be posting more often updates. But, again I expect it to be time consuming. Thanks again Marcus and all Pharo core team, Noury On Nov 20 2020, at 5:25 pm, Sean P. DeNigris <sean@clipperadams.com> wrote: > Marcus Denker-4 wrote > > Question: are these mails interesting? Do they have enough information > > added to > > have value? > > Yes! Please continue. I like that they are brief because too much detail can > be overwhelming and we can always ask questions about items that seem > interesting. IHMO the only extra info worth adding (if there's ever the > time) is the "why" - motivation and summaries of internal discussions that > we wouldn't understand just by looking at the commits... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >
MD
Marcus Denker
Mon, Nov 23, 2020 3:13 PM

On 21 Nov 2020, at 10:14, Noury Bouraqadi bouraqadi@gmail.com wrote:

Indeed, posting these emails is useful. It helps keeping us posted about the ongoing progress of Pharo.

I like they are grouped by topic, so it makes easier to get what it's about. Sean's suggestion would indeed understand more. Though I expect it will require more time/effort to write. Moreover, these emails are already long. I'm affraid they'll become way too long.

A solution that mixes both might be posting more often updates. But, again I expect it to be time consuming.

Yes, writing for real takes effort…

E.g. last week I did a trivial PR after I got annoyed about seeing too many ivars tat are not used and did a first step (mostly a skipped test):

Cleanup-Unused-Ivars #7780
https://github.com/pharo-project/pharo/pull/7780

But then I realised that the core of the test:

variables := Smalltalk globals allBehaviors flatCollect: [ :each | each instanceVariables ].
variables := variables reject: [ :each | each isReferenced ].
variables := variables collect: [ :each | each definingClass ] as: Set.

actually is more interesting then being just a trivial test for a trivial cleanup… In the end it is trivial, but it is as an example for why
things like turning variables into objects is interesting:

=======

As you might be aware, we added to Pharo the concept of “Firsts class Variables” that is, there is a meta object for every variable in the system.

Historically, even though you might think that “everything is an Object” in Smalltalk, the memory constraints that existed when ST80 was created did not make reifying everything possible. Even today, this has to be done with care: for example, instances of TempVariable are only created on demand in Pharo.

As for ST80: Instance Variables are one example of things that are not Objects: The only thing that we have are the names (that is, strings) of the instance variables defined by a class. The order is fixed so that the offset of the variables in the list of all instance variable of the class hierarchy actually is the offset that the bytecode uses to access this variable.

Thus all code dealing with Variables tend to be formulated quite “low level”. It exposes a lot of implementation details: you need to find names, then the offset, then use a low level bytecode scanning method to check if a method accesses this offset.

So how do “First Class” Variables improve the situation? Let’s see what we have to do to find all classes that define an instance variable that is not accessed.

Read more: https://blog.marcusdenker.de/finding-unused-variables-an-example-for-first-class-variables

> On 21 Nov 2020, at 10:14, Noury Bouraqadi <bouraqadi@gmail.com> wrote: > > Indeed, posting these emails is useful. It helps keeping us posted about the ongoing progress of Pharo. > > I like they are grouped by topic, so it makes easier to get what it's about. Sean's suggestion would indeed understand more. Though I expect it will require more time/effort to write. Moreover, these emails are already long. I'm affraid they'll become way too long. > > A solution that mixes both might be posting more often updates. But, again I expect it to be time consuming. > Yes, writing for real takes effort… E.g. last week I did a trivial PR after I got annoyed about seeing too many ivars tat are not used and did a first step (mostly a skipped test): Cleanup-Unused-Ivars #7780 https://github.com/pharo-project/pharo/pull/7780 But then I realised that the core of the test: variables := Smalltalk globals allBehaviors flatCollect: [ :each | each instanceVariables ]. variables := variables reject: [ :each | each isReferenced ]. variables := variables collect: [ :each | each definingClass ] as: Set. actually is more interesting then being just a trivial test for a trivial cleanup… In the end it is trivial, but it is as an example for why things like turning variables into objects is interesting: ======= As you might be aware, we added to Pharo the concept of “Firsts class Variables” that is, there is a meta object for every variable in the system. Historically, even though you might think that “everything is an Object” in Smalltalk, the memory constraints that existed when ST80 was created did not make reifying everything possible. Even today, this has to be done with care: for example, instances of TempVariable are only created on demand in Pharo. As for ST80: Instance Variables are one example of things that are not Objects: The only thing that we have are the names (that is, strings) of the instance variables defined by a class. The order is fixed so that the offset of the variables in the list of all instance variable of the class hierarchy actually is the offset that the bytecode uses to access this variable. Thus all code dealing with Variables tend to be formulated quite “low level”. It exposes a lot of implementation details: you need to find names, then the offset, then use a low level bytecode scanning method to check if a method accesses this offset. So how do “First Class” Variables improve the situation? Let’s see what we have to do to find all classes that define an instance variable that is not accessed. Read more: https://blog.marcusdenker.de/finding-unused-variables-an-example-for-first-class-variables