November 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] glamorous toolkit alpha.3

by Tim Mackinnon

Itâs very exciting watching the progress both in these email updates and the excellent more visual tweets. This and the progress on Pharo 7 will make for a great Xmas! Tim Sent from my iPhone > On 20 Nov 2018, at 23:08, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Another month has swooshed and now itâs time for Glamorous Toolkit alpha.3: > https://feenk.com/gt > > The key things that changed are as follows: > > - We rewrote Documenter. This was challenge, but the results are more than worth it. > One visible thing is that now the previews get cached, and as a consequence we can actually work inside the document. > But, perhaps the more impactful thing is that we can now toggle the visibility of Pillar markup. We think it significantly improves the experience and consequently, the value of the live documents. > > <gt-documenter-toggle-markup-small.gif> > > > - We advanced the work on the method Coder. To explore the boundaries, we reimagined the extract method refactoring. Thatâs : > https://twitter.com/feenkcom/status/1064823381407748096 > > - We enhanced the navigation in Playground / Inspector: > https://twitter.com/feenkcom/status/1064823381407748096 > > > A more complete list of issues we addressed is found here: > https://github.com/feenkcom/gtoolkit/milestone/1?closed=1 > > > > Have fun, > The feenk team > > -- > www.feenk.com > > âHow do you feenk today?" >

Nov. 21, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

> To make things more clear, the current implementation of Behavior >> #hash > has two negative side effects: > - behaviors stored in collections relying on the hash value (e.g. Set, > Dictionary) will have to be rehashed whenever a behavior is renamed > - objects using Behavior >> #hash to implement their own #hash, like what > Eliot just did to Message will suffer from the same issue. So Sets and > Dictionaries holding those kind of objects will have to be rehashed as > well upon the rename of the behavior. > > My questions related to this: > - why does Behavior >> #hash rely on the name instead of identity? If you mean #identityHash, then its because involving an unstable value in a #hash calculation is never a good idea. #identityHash can be different for the same class between two different images, or if the class was ever becomed or reloaded into a new image, etc. > - do we want to fix those issues mentioned above or do we just say that > one should not rename classes and expect things to work? Neither. We just say that when one renames a class to rehash all relevant HashedCollections. - Chris

Nov. 21, 2018

Re: [Pharo-dev] glamorous toolkit alpha.3

by Sean P. DeNigris

Tudor Girba-2 wrote > we can now toggle the visibility of Pillar markup Bravo!!! :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 21, 2018

Re: [Pharo-dev] [Cuis-dev] Message>>#= & Message>>#hash

by Eliot Miranda

Hi Juan, On Tue, Nov 20, 2018 at 8:00 AM Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Eliot, > > (below) > On 19/11/2018 02:32 p.m., Eliot Miranda via Cuis-dev wrote: > > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > comparison. This is, to say the least, annoying. Any objections to > implementing comparing in Message to match VisualWorks? > > _,,,^..^,,,_ > best, Eliot > > > Just added these implementations to Cuis: > > = aMessage > "Any object is equal to itself" > self == aMessage ifTrue: [ ^ true ]. > self class == aMessage class ifFalse: [ ^false ]. > selector = aMessage selector ifFalse: [ ^false ]. > lookupClass = aMessage lookupClass ifFalse: [ ^false ]. > ^args = aMessage arguments > this last line should be ^args literalEqual: aMessage arguments and this is very important :-) > > hash > "Hash is reimplemented because = is implemented." > ^selector hash bitXor: args hash > > Do they look ok? (I considered lookupClass for #=, but not for hash, as > collisions because of that seem unlikely, and in any case, grouping them > that way could be useful). > > Cheers, > > -- > Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smallt… > @JuanVuletich > > -- _,,,^..^,,,_ best, Eliot

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

Wait, Message is the one used internally by the system. It doesn't have #= and #hash because it didn't need it. *MessageSend* is the one for external use, and it already defines #= and #hash. On Mon, Nov 19, 2018 at 11:32 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages whose selectors and arguments are #= are also equal. But in Cuis, Squeak and Pharo Message inherits #= and #hash from Object, i.e. uses identity comparison. This is, to say the least, annoying. Any objections to implementing comparing in Message to match VisualWorks? > > _,,,^..^,,,_ > best, Eliot >

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

It sounds good, but an Inbox submission would go a long way to understanding exactly what you mean esp. re: understanding this special condition with the lookupClass being nil... and whether it deserves a first-class name or not... On Tue, Nov 20, 2018 at 4:10 AM Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > > On Mon, 19 Nov 2018, Eliot Miranda wrote: > > > Hi David, > > > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > > Hi All, > > > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > > comparison. This is, to say the least, annoying. Any objections to > > > implementing comparing in Message to match VisualWorks? > > > > > > > That sounds like an obviously good thing to do :-) > > > > Is the lookupClass instance variable relevant for comparisons? I am > > guessing not, since we already have #analogousCodeTo: for that type of > > comparison. > > > > > > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in > > waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. > > What about Behavior >> #hash? It uses the name of the class, which is fine > as long as you don't rename your classes while you store them in hashed > collections. > > Levente > > > > > Dave > > > > > > _,,,^..^,,,_ > > best, Eliot > > > >

Nov. 20, 2018

[Pharo 7.0-dev] Build #1409: 22685-add-value-reification-support-for-Literal-node

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

There is a new Pharo build available! The status of the build #1409 was: FAILURE. The Pull Request #2005 was integrated: "22685-add-value-reification-support-for-Literal-node" Pull request url: https://github.com/pharo-project/pharo/pull/2005 Issue Url: https://pharo.fogbugz.com/f/cases/22685 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2018

glamorous toolkit alpha.3

by Tudor Girba

Hi, Another month has swooshed and now itâs time for Glamorous Toolkit alpha.3: https://feenk.com/gt The key things that changed are as follows: - We rewrote Documenter. This was challenge, but the results are more than worth it. One visible thing is that now the previews get cached, and as a consequence we can actually work inside the document. But, perhaps the more impactful thing is that we can now toggle the visibility of Pillar markup. We think it significantly improves the experience and consequently, the value of the live documents. - We advanced the work on the method Coder. To explore the boundaries, we reimagined the extract method refactoring. Thatâs : https://twitter.com/feenkcom/status/1064823381407748096 - We enhanced the navigation in Playground / Inspector: https://twitter.com/feenkcom/status/1064823381407748096 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/1?closed=1 Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Nov. 20, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1408: Add AST dump from an existing AST

by Marcus Denker

> On 20 Nov 2018, at 11:20, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #1408 was: SUCCESS. > > The Pull Request #2001 was integrated: "Add AST dump from an existing AST" > Pull request url: https://github.com/pharo-project/pharo/pull/2001 > This is a very useful addition done by Vincent Aranega. It adds to the AST the feature to print out an expression that re-creates the AST. It adds a pane to the inspector (here it is the AST of OrderedCollection>>#do:

Nov. 20, 2018

[Pharo 7.0-dev] Build #1408: Add AST dump from an existing AST

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

There is a new Pharo build available! The status of the build #1408 was: SUCCESS. The Pull Request #2001 was integrated: "Add AST dump from an existing AST" Pull request url: https://github.com/pharo-project/pharo/pull/2001 Issue Url: https://pharo.fogbugz.com/f/cases/feature/parseDump Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2018