September 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #721: 2449-Automatic-rewriting-of-deprecated-code-needs-feedback-to-developers-whose-code-is-changed

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #721 was: SUCCESS. The Pull Request #4539 was integrated: "2449-Automatic-rewriting-of-deprecated-code-needs-feedback-to-developers-whose-code-is-changed" Pull request url: https://github.com/pharo-project/pharo/pull/4539 Issue Url: https://github.com/pharo-project/pharo/issues/2449 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 10, 2019

[Pharo 8.0] Build #720: 4542-update-rfEnsure

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #720 was: SUCCESS. The Pull Request #4543 was integrated: "4542-update-rfEnsure" Pull request url: https://github.com/pharo-project/pharo/pull/4543 Issue Url: https://github.com/pharo-project/pharo/issues/4542 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 10, 2019

Re: [Pharo-dev] Floating-point numbers with non-decimal radix

by James Foster

Jim, Youâve done an excellent job of summarizing the issues and providing strong arguments. For my part, while consistency is important, simplicity is also important. To that end, a new syntax would need to bring a lot of value to justify the additional cognitive load. So unless you can get `^` to act as the exponent prefix, Iâd be skeptical of a new syntax. For me, the idea that an Integer (and not a Float) can have a radix is sufficient and consistent. James > On Sep 9, 2019, at 3:13 PM, Jim Sawyer <jas(a)cruzio.com> wrote: > > > --- > Regarding the specification of floating point numbers with radix ~= 10, > and in particular the question raised by James Foster(Gemstone). > > Summarizing the comments from James Foster, Nicolas Collier, Prof Stef Ducasse; > followed by some arguments with a lot of hand waving, > in order to agree with and support what Nicolas said at the outset: > this deserves a new syntax. > --- > Question: How should it work? > > The literal 16rFF is 255 (aSmallInteger). > Pharo permits lowercase hexadecimal digits, > so the literal 16rff is also taken to be 255. > The literal 1.23e3 is 1230.0 (aSmallDouble in GemStone). > Pharo also permits floating point numbers to have a radix, > so that e.g. both 2r1.111e3 and 2r1111 are taken to be 15. > This makes certain grammars for numbers ambiguous, because > upon encountering either an $E or an $e during the parse > of a number, we find two possible interpretations: > Is this a hexadecimal digit > or an exponent marker? > > James identified four possible solutions: > > > 1) Distinguish by letter case > uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. > 2) Allow exponents on base ten numbers only > 3) Distinguish by range > radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] > 4) Develop a new syntax for floats that does not use > either the letter $e or the letter $E to mark an exponent > > Many implementations of Smalltalk use solution #1, > whereas Pharo currently uses solution #3. > > The result is that any number expressed in other dialects > will port to Pharo without issue, while certain expressions for > numbers that are recognized in Pharo become ambiguous > when ported to other dialects. > The most practical âfixâ is for Pharo to adopt > the more âpopularâ solution. > > <tl;dr><outcry> > > Even so, I submit that this is not the right thing to do. > But only because it is a hack, on top of a hack, on top of a > design error that went unnoticed for far too long, and really > ought to be corrected, for a number of reasons, viz.: > 1) The root cause of the problem is an ambiguous grammar. > 2) This ambiguity is unique to Smalltalk. > It does not occur in any other language, as far as I know. > 3) The source of the ambiguity is the design decision which > introduced a consistent syntax for expressing numbers in > different bases by directly specifying the desired radix, > instead of choosing from the very limited sets of special cases > provided by other languages.. > One is usually limited to binary, octal, decimal, and hexadecimal, > with a unique syntactic form required for expression in each base. > We get Bâ01â for binary, \001 for octal, #01 or %01 for hex, > and the unadorned 1, left for (the most privileged) decimal form. > Introducing a consistent form for specifying alternate bases > was itself a great design decision. > At the same time, however, a change was introduced which impacted > some very long standing properties of numeric representations, and > the effect of that change was perhaps not fully considered. > As we go about the task of correcting such a latent error, we should > take enough time to more fully consider the particulars that brought us here. > > 4) Smalltalk is a spectacularly consistent design and a spectacularly consistent > language to work in. Increasing the consistency of such a language is arguably > the right thing to do at every opportunity. This is not always the most popular thing > to doâbut it is usually the most honorable. > And the most useful, in the long term. > Practically speaking. > > 5) Of the four solutions (or cases), we can arguably eliminate three. > > 1) Distinguish by letter case > uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. > 2) Allow exponents on base ten numbers only > > 3) Distinguish by range > radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] > > 4) Develop a new syntax for floats that does not use > either the letter $e or the letter $E to mark an exponent > > In other domains and languages, numerical values are specified with digits only. > In such contexts, using a letter as a syntactic marker is reasonable. > Once we adopt the specifiable-radix form > (radix)r(rigits) > in which numerical values are expressed using digits AND letters, > it becomes far less reasonable to use letters as a marker. > > Case (1) : > > Differentiation based on the case of letters is fine where the use of > letters is pervasive and capitalization is itself generically meaningful, > e.g. certain shorthand notations used in regular expressions > (%h signifying a match of any lowercase hexadecimal, with > %H signifying a match of any uppercase hexadecimal). > Whereas using capitalization to distinguish âa valueâ from âa syntactic marke' > is a very poor use of character classes, of pixels, and of synaptic gaps, because > the association is made without mnemonic support of any kind. Such ârulesâ > require rote memorization, i.e. perfect match of an arbitrary fact. The hidden > assumption--that any âskillâ involved is both ubiquitous and evenly distributedâ > is, alas, unfounded. > > Case (2) > Disallowing exponents for all bases other than 10 is > a) inconsistent > b) contrary to the point of consistently specifying the desired radix. > c) lazy > > Case (3): > Differentiating meaning based on a particular range of values > makes for a great explanation of the âdiscoveredâ effect, but is somewhat > frightening to consider using *on purpose*. If we were to adopt anything of this ilk, > a better crossover of ranges would be > radix <= 10 Values are confined to the set of digits (ascii 16r30-16r39) > and $E are exponent markers. See also $s, $d, and $q. > radix >= 11 Letters are required for use as extended values > as determined by the radix. > We cannot imagine using non-letter characters for this case. > Therefore, no exponents for bases above 10. > > This leaves us with solution (4), create a new syntax for marking the exponent. > Because the other solutions are hacks. Practicalâsure. But hacks, nonetheless. > Abominable. > > 7) As Nicolas pointed out, this issue deserves a new syntax. > The moment we adopted the specifiable-radix solution, > we needed to also abandon the use of the letter $e for marking exponents. > Now is our chance to make it right. > </tl;dr></outcry> > > Ideas? > > > -Jim Sawyer > > > > > <https://www.avg.com/internet-security> > This email has been checked for viruses by AVG antivirus software. > www.avg.com <https://www.avg.com/internet-security> > <x-msg://32/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Sept. 10, 2019

when can we have DrTests

by ducasse

I desesperately need it.

Sept. 10, 2019

[Pharo 8.0] Build #719: Fix bug introduced with Spec2 migration.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #719 was: FAILURE. The Pull Request #4538 was integrated: "Fix bug introduced with Spec2 migration." Pull request url: https://github.com/pharo-project/pharo/pull/4538 Issue Url: https://github.com/pharo-project/pharo/issues/4529 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 10, 2019

Re: [Pharo-dev] Floating-point numbers with non-decimal radix [Pharo-dev Digest, Vol 77, Issue 5]

by ducasse

Thanks Jim we will have to take the time to check. Now it is also important to understand the usage because adding a new syntax for 0.01% of the cases is not super efficient. We will carefully read your analysis and come back to it. > On 10 Sep 2019, at 00:13, Jim Sawyer <jas(a)cruzio.com> wrote: > > > --- > Regarding the specification of floating point numbers with radix ~= 10, > and in particular the question raised by James Foster(Gemstone). > > Summarizing the comments from James Foster, Nicolas Collier, Prof Stef Ducasse; > followed by some arguments with a lot of hand waving, > in order to agree with and support what Nicolas said at the outset: > this deserves a new syntax. > --- > Question: How should it work? > > The literal 16rFF is 255 (aSmallInteger). > Pharo permits lowercase hexadecimal digits, > so the literal 16rff is also taken to be 255. > The literal 1.23e3 is 1230.0 (aSmallDouble in GemStone). > Pharo also permits floating point numbers to have a radix, > so that e.g. both 2r1.111e3 and 2r1111 are taken to be 15. > This makes certain grammars for numbers ambiguous, because > upon encountering either an $E or an $e during the parse > of a number, we find two possible interpretations: > Is this a hexadecimal digit > or an exponent marker? > > James identified four possible solutions: > > > 1) Distinguish by letter case > uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. > 2) Allow exponents on base ten numbers only > 3) Distinguish by range > radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] > 4) Develop a new syntax for floats that does not use > either the letter $e or the letter $E to mark an exponent > > Many implementations of Smalltalk use solution #1, > whereas Pharo currently uses solution #3. > > The result is that any number expressed in other dialects > will port to Pharo without issue, while certain expressions for > numbers that are recognized in Pharo become ambiguous > when ported to other dialects. > The most practical âfixâ is for Pharo to adopt > the more âpopularâ solution. > > <tl;dr><outcry> > > Even so, I submit that this is not the right thing to do. > But only because it is a hack, on top of a hack, on top of a > design error that went unnoticed for far too long, and really > ought to be corrected, for a number of reasons, viz.: > 1) The root cause of the problem is an ambiguous grammar. > 2) This ambiguity is unique to Smalltalk. > It does not occur in any other language, as far as I know. > 3) The source of the ambiguity is the design decision which > introduced a consistent syntax for expressing numbers in > different bases by directly specifying the desired radix, > instead of choosing from the very limited sets of special cases > provided by other languages.. > One is usually limited to binary, octal, decimal, and hexadecimal, > with a unique syntactic form required for expression in each base. > We get Bâ01â for binary, \001 for octal, #01 or %01 for hex, > and the unadorned 1, left for (the most privileged) decimal form. > Introducing a consistent form for specifying alternate bases > was itself a great design decision. > At the same time, however, a change was introduced which impacted > some very long standing properties of numeric representations, and > the effect of that change was perhaps not fully considered. > As we go about the task of correcting such a latent error, we should > take enough time to more fully consider the particulars that brought us here. > > 4) Smalltalk is a spectacularly consistent design and a spectacularly consistent > language to work in. Increasing the consistency of such a language is arguably > the right thing to do at every opportunity. This is not always the most popular thing > to doâbut it is usually the most honorable. > And the most useful, in the long term. > Practically speaking. > > 5) Of the four solutions (or cases), we can arguably eliminate three. > > 1) Distinguish by letter case > uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. > 2) Allow exponents on base ten numbers only > > 3) Distinguish by range > radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] > > 4) Develop a new syntax for floats that does not use > either the letter $e or the letter $E to mark an exponent > > In other domains and languages, numerical values are specified with digits only. > In such contexts, using a letter as a syntactic marker is reasonable. > Once we adopt the specifiable-radix form > (radix)r(rigits) > in which numerical values are expressed using digits AND letters, > it becomes far less reasonable to use letters as a marker. > > Case (1) : > > Differentiation based on the case of letters is fine where the use of > letters is pervasive and capitalization is itself generically meaningful, > e.g. certain shorthand notations used in regular expressions > (%h signifying a match of any lowercase hexadecimal, with > %H signifying a match of any uppercase hexadecimal). > Whereas using capitalization to distinguish âa valueâ from âa syntactic marke' > is a very poor use of character classes, of pixels, and of synaptic gaps, because > the association is made without mnemonic support of any kind. Such ârulesâ > require rote memorization, i.e. perfect match of an arbitrary fact. The hidden > assumption--that any âskillâ involved is both ubiquitous and evenly distributedâ > is, alas, unfounded. > > Case (2) > Disallowing exponents for all bases other than 10 is > a) inconsistent > b) contrary to the point of consistently specifying the desired radix. > c) lazy > > Case (3): > Differentiating meaning based on a particular range of values > makes for a great explanation of the âdiscoveredâ effect, but is somewhat > frightening to consider using *on purpose*. If we were to adopt anything of this ilk, > a better crossover of ranges would be > radix <= 10 Values are confined to the set of digits (ascii 16r30-16r39) > and $E are exponent markers. See also $s, $d, and $q. > radix >= 11 Letters are required for use as extended values > as determined by the radix. > We cannot imagine using non-letter characters for this case. > Therefore, no exponents for bases above 10. > > This leaves us with solution (4), create a new syntax for marking the exponent. > Because the other solutions are hacks. Practicalâsure. But hacks, nonetheless. > Abominable. > > 7) As Nicolas pointed out, this issue deserves a new syntax. > The moment we adopted the specifiable-radix solution, > we needed to also abandon the use of the letter $e for marking exponents. > Now is our chance to make it right. > </tl;dr></outcry> > > Ideas? > > > -Jim Sawyer > > > > > <https://www.avg.com/internet-security> > This email has been checked for viruses by AVG antivirus software. > www.avg.com <https://www.avg.com/internet-security> > <x-msg://193/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Sept. 10, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by ducasse

check sven repo. > On 10 Sep 2019, at 00:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > monty-3 wrote >> I will move it to github, if that makes things easier for everyone else. > > Hi! Was this ever done? I couldn't find it on GH but maybe I'm looking in > the wrong place... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 10, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Sean P. DeNigris

monty-3 wrote > I will move it to github, if that makes things easier for everyone else. Hi! Was this ever done? I couldn't find it on GH but maybe I'm looking in the wrong place... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 9, 2019

Re: [Pharo-dev] Floating-point numbers with non-decimal radix [Pharo-dev Digest, Vol 77, Issue 5]

by Jim Sawyer

--- Regarding the specification of floating point numbers with radix ~= 10, and in particular the question raised by James Foster(Gemstone). Summarizing the comments from James Foster, Nicolas Collier, Prof Stef Ducasse; followed by some arguments with a lot of hand waving, in order to agree with and support what Nicolas said at the outset: this deserves a new syntax. --- Question: How should it work? The literal 16rFF is 255 (aSmallInteger). Pharo permits lowercase hexadecimal digits, so the literal 16rff is also taken to be 255. The literal 1.23e3 is 1230.0 (aSmallDouble in GemStone). Pharo also permits floating point numbers to have a radix, so that e.g. both 2r1.111e3 and 2r1111 are taken to be 15. This makes certain grammars for numbers ambiguous, because upon encountering either an $E or an $e during the parse of a number, we find two possible interpretations: Is this a hexadecimal digit or an exponent marker? James identified four possible solutions: 1) Distinguish by letter case uppercase $E is a hexadecimal digit lowercase $e is a marker signifying an exponent. 2) Allow exponents on base ten numbers only 3) Distinguish by range radix >= 15 ifTrue: [$e is the hexadecimal digit ]ifFalse: [$e is a marker signifying exponent] 4) Develop a new syntax for floats that does not use either the letter $e or the letter $E to mark an exponent Many implementations of Smalltalk use solution #1, whereas Pharo currently uses solution #3. The result is that any number expressed in other dialects will port to Pharo without issue, while certain expressions for numbers that are recognized in Pharo become ambiguous when ported to other dialects. The most practical âfixâ is for Pharo to adopt the more âpopularâ solution. <tl;dr><outcry> Even so, I submit that this is not the right thing to do. But only because it is a hack, on top of a hack, on top of a design error that went unnoticed for far too long, and really ought to be corrected, for a number of reasons, viz.: 1) The root cause of the problem is an ambiguous grammar. 2) This ambiguity is unique to Smalltalk. It does not occur in any other language, as far as I know. 3) The source of the ambiguity is the design decisionwhich Â introduced a consistent syntax for expressing numbers in Â different bases by directly specifying the desired radix, instead of choosing from the very limited sets of special cases provided by other languages.. One is usually limited to binary, octal, decimal, and hexadecimal, with a unique syntactic form required for expression in each base. We get Bâ01â for binary, \001 for octal, #01 or %01 for hex, and the unadorned 1, left for (the most privileged) decimal form. Introducing a consistent form for specifying alternate bases was itself a great design decision. At the same time, however, a change was introduced which impacted some very long standing properties of numeric representations, and the effect of that change was perhaps not fully considered. As we go about the task of correcting such a latent error, we should Â takeenough time to more fully consider the particulars that brought us here. 4) Smalltalk is a spectacularly consistent design and a spectacularly consistent language to work in.Increasing the consistency of such a language is arguably Â the right thing to do at every opportunity.This is not always themost popular thing to doâbut it is usually the most honorable. And the most useful, in the long term.Practically speaking. 5) Of the four solutions (or cases), we can arguably eliminate three. 1) Distinguish by letter case uppercase $E is a hexadecimal digit lowercase $e is a marker signifying an exponent. 2) Allow exponents on base ten numbers only 3) Distinguish by range radix >= 15 ifTrue: [$e is the hexadecimal digit ]ifFalse: [$e is a marker signifying exponent] 4) Develop a new syntax for floats that does not use either the letter $e or the letter $E to mark an exponent In other domains and languages, numerical values are specified with digits only. In such contexts, using a letter as a syntactic marker is reasonable. Once we adopt the specifiable-radix form (radix)r(rigits)in which numerical values are expressed using digits AND letters, it becomes far less reasonable to use letters as a marker. Case (1) : Differentiation based on the case of letters is fine where the use of letters is pervasive and capitalization is itself generically meaningful, e.g. certain shorthand notations used in regular expressions (%h signifying a match of any lowercase hexadecimal, with %H signifying a match of any uppercase hexadecimal). Whereas using capitalization to distinguish âa valueâ from âa syntactic marke' is a very poor use of character classes, of pixels, and of synaptic gaps, because the association is made without mnemonic support of any kind. Such ârulesâ require rote memorization, i.e. perfect match of an arbitrary fact.The hidden assumption--that any âskillâ involved is both ubiquitous and evenly distributedâ is, alas, unfounded. Case (2) Disallowing exponents for all bases other than 10 is a) inconsistent b) contrary to the point of consistently specifying the desired radix. c) lazy Case (3): Differentiating meaning based on a particular range of valuesmakes for a great explanation of the âdiscoveredâ effect, but is somewhat frighteningto consider using *on purpose*.If we were to adopt anything of this ilk,a better crossover of ranges would be radix <= 10Values are confined to the set of digits (ascii 16r30-16r39) and $E are exponent markers.See also $s, $d, and $q. radix >= 11Letters are required for use as extended values as determined by the radix. We cannot imagine using non-letter characters for this case. Therefore, no exponents for bases above 10. This leaves us with solution (4), create a new syntax for marking the exponent. Because the other solutions are hacks.Practicalâsure.But hacks, nonetheless.Abominable. 7) As Nicolas pointed out, this issue deserves a new syntax. The moment we adopted the specifiable-radix solution, we needed to also abandon the use of the letter $e for marking exponents. Now is our chance to make it right. </tl;dr></outcry> Ideas? -Jim Sawyer ------------------------------------------------------------------------ AVG logo <https://www.avg.com/internet-security> This email has been checked for viruses by AVG antivirus software. www.avg.com <https://www.avg.com/internet-security> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- This email has been checked for viruses by AVG. https://www.avg.com

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Denis Kudriashov

Hi. Another option is to not expose slot class names at all and use messages instead: - #first slot lazy default: 5 - #second slot boolean - #instVar3 slot weak lazy - #typedVar slot type: Integer; lazy #slot here will return SlotDefinition. And following messages will configure it or produce new instances. I think it is more simple approach than having "binary message algebra" for slots composition. Implementation of slots in that case will force developers to extend the slot definition API and therefore the parser. Ð¿Ð½, 9 ÑÐµÐ½Ñ. 2019 Ð³. Ð² 18:21, ducasse <stepharo(a)netcourrier.com>: > I would prefer that we discuss also because we need to have a design that > suits us. > I do not think Pharo will benefit to have a complex class definition. > > Stef > > > On 9 Sep 2019, at 17:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > > > >> On 9 Sep 2019, at 17:00, ducasse <stepharo(a)netcourrier.com> wrote: > >> > >> Marcus to me the point is that we should not rush this kind of things. > >> What we should think is > >> - freeze a syntax - I like the idea of guille to make sure that we > cannot have any message in the slot > >> - take the time to discuss the design, do code review, make sure > that we have tests > >> - to me a programmer should not compose slot property in the class > definition. > >> > > > > > > I will finish it and then we can discuss. > > > > Marcus > > > >

Sept. 9, 2019