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

Re: [Pharo-dev] GitHub Topics

by Stephane Ducasse

super c00l I started to tag all my projects too :) On Wed, Oct 10, 2018 at 1:43 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > PR approved! We're listed at https://github.com/topics/pharo > > [image: image.png] > > > > Esteban A. Maringolo > > Esteban A. Maringolo > > > El mar., 9 oct. 2018 a las 22:31, Esteban Maringolo (<emaringolo(a)gmail.com>) > escribiÃ³: > >> El mar., 9 oct. 2018 a las 18:30, Peter Uhnak (<i.uhnak(a)gmail.com>) >> escribiÃ³: >> > >> >> Maybe there is a minimum threshold required to enable such edits. >> > issue a pull request to this repo https://github.com/github/explore >> >> Done! >> >> https://github.com/github/explore/pull/409 >> >> Esteban A. Maringolo >> >

Oct. 11, 2018

Re: [Pharo-dev] What you think about visibility of trait method in browser?

by Thierry Goubier

Hi Denis, Le jeu. 11 oct. 2018 Ã 10:24, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > Hi, > >> >> On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Hello. >>> >>> I want to ask you what you think about it. >>> - do you prefer to see trait methods by default? > > > Yes. > >>> >>> - do you want feature to hide trait methods? > > > Not necessarily. But the problem are not the methods "in traits". Read my explanation below. > >>> Current Calypso support for traits follows simple principle which I found important for me. But I can be the only guy who think this way. Maybe because I meet traits in Self. So: >>> I simply want to see in the browser what class is actually implements. If class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see its methods by default. When I open such class in the browser I want to see only code which class explicitly implements For me this logic is same as for superclass methods. > > > Well, the main problem of this approach is that traits in self are fundamentally different than traits in self. And the main answer here is not flattening or not flattening, but the idea of "trait composition". A class does not just use "some traits". It uses a trait composition, which includes also other rules like aliases, overrides and removals. With the new implementation there is also deep aliasing. And moreover, since traits are stateful, you need to support the same for slots. > > Then, regarding the current implementation, it is duplicating all the semantics of traits in the UI, and incompletely because it is not covering at all complex trait compositions. > > The problem with duplication is that then, if there is a bugz, we may have to fix it several placez. > The problem with duplication is that then, if there is a bug, we may have to fix it several places. You're making your point about the danger of duplication very clear :) Thierry > And the other problem is that Traits already provide a good API to discover all this things automatically without duplicating any of it: > - localMethods > - methods > - allMethods > > And then you can always ask the origin of a method. > > This API is of course perfectible, but I think it's better to enhance it, than to duplicate it and work it around. > > On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> And by the way, we really need to name traits with a T in the name? I always found this ugly, it makes the trait support look like a hack. > > > I don't think so :). It's just a name convention.

Oct. 11, 2018

Re: [Pharo-dev] What you think about visibility of trait method in browser?

by Guillermo Polito

Hi, > On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> I want to ask you what you think about it. >> - do you prefer to see trait methods by default? >> > Yes. > - do you want feature to hide trait methods? >> > Not necessarily. But the problem are not the methods "in traits". Read my explanation below. Current Calypso support for traits follows simple principle which I found >> important for me. But I can be the only guy who think this way. Maybe >> because I meet traits in Self. So: >> I simply want to see in the browser what class is actually implements. If >> class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see >> its methods by default. When I open such class in the browser I want to see >> only code which class explicitly implements For me this logic is same as >> for superclass methods. >> > Well, the main problem of this approach is that traits in self are fundamentally different than traits in self. And the main answer here is not flattening or not flattening, but the idea of "trait composition". A class does not just use "some traits". It uses a trait composition, which includes also other rules like aliases, overrides and removals. With the new implementation there is also deep aliasing. And moreover, since traits are stateful, you need to support the same for slots. Then, regarding the current implementation, it is duplicating all the semantics of traits in the UI, and incompletely because it is not covering at all complex trait compositions. The problem with duplication is that then, if there is a bugz, we may have to fix it several placez. The problem with duplication is that then, if there is a bug, we may have to fix it several places. And the other problem is that Traits already provide a good API to discover all this things automatically without duplicating any of it: - localMethods - methods - allMethods And then you can always ask the origin of a method. This API is of course perfectible, but I think it's better to enhance it, than to duplicate it and work it around. On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > And by the way, we really need to name traits with a T in the name? I > always found this ugly, it makes the trait support look like a hack. > I don't think so :). It's just a name convention.

Oct. 11, 2018

[Pharo 7.0-dev] Build #1328: Revert "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector"

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

There is a new Pharo build available! The status of the build #1328 was: FAILURE. The Pull Request #1902 was integrated: "Revert "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector"" Pull request url: https://github.com/pharo-project/pharo/pull/1902 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

[Pharo 7.0-dev] Build #1327: 22566-Add-a-Details-pane-to-Colors-GT-Inspector

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

There is a new Pharo build available! The status of the build #1327 was: FAILURE. The Pull Request #1901 was integrated: "22566-Add-a-Details-pane-to-Colors-GT-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/1901 Issue Url: https://pharo.fogbugz.com/f/cases/22566 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

[Pharo 7.0-dev] Build #1326: 22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage

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

There is a new Pharo build available! The status of the build #1326 was: FAILURE. The Pull Request #1900 was integrated: "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage" Pull request url: https://github.com/pharo-project/pharo/pull/1900 Issue Url: https://pharo.fogbugz.com/f/cases/22564 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

Re: [Pharo-dev] Array inspector Items view Selection broken

by Marcus Denker

> On 11 Oct 2018, at 05:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Indeed. > > The issue comes from this commit: > https://github.com/pharo-project/pharo/pull/1889 <https://github.com/pharo-project/pharo/pull/1889> > I made a revert PR https://github.com/pharo-project/pharo/pull/1902 <https://github.com/pharo-project/pharo/pull/1902> and re-opened the issue tracker entry: https://pharo.fogbugz.com/f/cases/22553/Instances-are-not-indexable-after-d… <https://pharo.fogbugz.com/f/cases/22553/Instances-are-not-indexable-after-d…> We need to fix that bugâ¦ we had already multiple issue tracker entries for it. Marcus

Oct. 11, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Christophe Demarey

Hi Phil, It could be a problem due to the introduction of a the use of a new primitive in the image some weeks ago. What is the version of Pharo Launcher you use? Did you try to update the pharo 7 vm? (you could just drop the vm folders in Documents). Christophe > Le 11 oct. 2018 Ã 08:09, phil(a)highoctane.be a Ã©crit : > > Used to work. Then does not anymore. > > Phil > <unknown.png>

Oct. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Norbert Hartl

Mine are tagged, too. And most of them have the gitattributed so is surely discovered as smalltalk > Am 11.10.2018 um 03:48 schrieb Pierce Ng <pierce(a)samadhiweb.com>: > >> On Wed, Oct 10, 2018 at 08:42:13AM -0300, Esteban Maringolo wrote: >> PR approved! We're listed at https://github.com/topics/pharo > > Great! I've tagged all my projects. > > Pierce > >

Oct. 11, 2018

Laucher cannot start a fresh 7 image

by phil＠highoctane.be

Used to work. Then does not anymore. Phil

Oct. 11, 2018