- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Sven Van Caekenberghe

> On 05 Sep 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: > > > > Le 5/9/15 19:18, Yuriy Tymchuk a Ã©crit : >> In fact you couldnât spot the issue by just looking at the patch :) there was a very strange thing that could be fixed with one line, but to identify it Iâve spent probably 1.5 hours :) > > sure this is not my point. > my point is that we need to be able to know what changed. Right now I see a title and I do not have the time to click on each github link. > I want to see diffs right in front of my nose. I know very little about git, but the first thing that I tried worked: git clone https://github.com/pharo-project/pharo-core.git cd pharo-core/ git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 I assume that we could put that textual information in the mail. In my terminal, it is coloured, but I still think that the github page is much better: https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… (It happens that this commit changed quite a lot) > Stef >> >> Uko >> >>> On 05 Sep 2015, at 19:03, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> >>> >>> 2015-09-05 11:48 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> How can I see the changes? >>>> Our process is not good. Most of us do not get any chance understanding what is changing. >>>> >>> >>> -> download the image before it was added >>> -> merge the slice. >>> >>> Yes, our process is not goodâ¦ but from a review perspective, this issue is the best we can do. >>> *two* reviews, both from people actively contributing to exactly that part of the system. >>> >>> If we require more, we will be back at a process where due to Fear we do nothing. >>> >>> >>> Nautilus is a difficult beast, you all know. Even if you look close at the merge diff you may >>> miss some important relation that only really visible during debugging. >>> I did some test when reviewing this fix. But really, there are so many >>> ways do you need to consider >>> - different ways for opening nautilus >>> - navigate with keys and mouse >>> - selecting updating / changes from other browser and system changes. >>> - refactorings >>> >>> It is really not that easy and I am happy that Franck and Yuri are actually trying to >>> improve Nautilus. >>> you can not easily tests all and make the changes and reviews bullet proof. >>> >>> >>> nicolai >>> >>> >>> >>>> >>>>> Hi, >>>>> >>>>> This is a side effect of >>>>> >>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >>>>> >>>>> (which was reviewed by two people, so not obvious). >>>>> >>>>> What happened is that #updatePackageGroupAndClassList calls itself via #selectedClass: leading to a loop. >>>>> >>>>> Should be easy to fix for the people involved in case 16475. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> On Sat, Sep 5, 2015 at 8:51 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> Hi >>>>> >>>>> I do not know if this is linked to recent changes but we cannot remove classes or move them to another package. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Marcus Denker -- denker(a)acm.org >>>>> http://www.marcusdenker.de >> >

Sept. 5, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Bernardo Ezequiel Contreras

Excuse me, but what about the following messages MessageBrowser browse: ({WeakSubscriptionBuilder>>#on:do:. WeakSubscriptionBuilder>>#on:send:to:}) should be deprecated, or not? On Sat, Sep 5, 2015 at 5:24 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > in announcer we have > > when: anAnnouncementClass send: aSelector to: anObject > "Declare that when anAnnouncementClass is raised, anObject should > receive the message aSelector. > When the message expects one argument (eg #fooAnnouncement:) the > announcement is passed as argument. > When the message expects two arguments (eg > #fooAnnouncement:announcer:) both the announcement and the announcer > are passed as argument" > > ^ self subscribe: anAnnouncementClass send: aSelector to: anObject > > > could we reduce the cognitive load and make sure that the API is only one > protocol for example when: send: to:? > I found it confusing and I have to check that this is indeed the same. > I think that having one way is far enough. > > What do you think? > Stef > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Sept. 5, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Ferlicot D. Cyril

Le 05/09/2015 21:39, stepharo a Ã©crit : > > > Le 5/9/15 16:49, Yuriy Tymchuk a Ã©crit : >> I can give you a short explanation for the sake of more people knowing >> how Nautilus works. > Yes please if you have some time. > What I do not like is that we pass nil to indicate that there is no > selection. I was thinking that an hierarchy of null objects could help > but this is difficult to > foresee if it will make sense. > I also that all the logic update without reselecting is complex. > I started to read the code and also move some condition about the model > to the model class :). > I would like to do just a simple pass reading all the code and not > changing much to get now yet another better feel of nautilus. > I will also remove the Nautilus help. > I would like to rename the NautilusRefactoring because it is not about > nautilus but about RB. > >> >> Regarding diffs and knowledge sharing, we should have a normal code >> review support with something like gerrit. > > thomas was working on a code review tool and skip is taking over so I > hope that we will have it. >> >> Uko >> > > I am also interesting for the informations about Nautilus :) Each time I try to check some code from it it's Hell! -- Cyril

Sept. 5, 2015

GroupAnnouncer?

by stepharo

Hi A final thought from my reading of Nautilus and related. I'm thinking that we could merge GroupAnnouncer into class side Group. Because I do not see the point to have a singleton and a subclass of Announcer. Stef

Sept. 5, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Tudor Girba

+1. We already deprecated on:send:to:/on:do: and I think we should do the same for the subscribe:send:to:. Doru On Sat, Sep 5, 2015 at 10:24 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > in announcer we have > > when: anAnnouncementClass send: aSelector to: anObject > "Declare that when anAnnouncementClass is raised, anObject should > receive the message aSelector. > When the message expects one argument (eg #fooAnnouncement:) the > announcement is passed as argument. > When the message expects two arguments (eg > #fooAnnouncement:announcer:) both the announcement and the announcer > are passed as argument" > > ^ self subscribe: anAnnouncementClass send: aSelector to: anObject > > > could we reduce the cognitive load and make sure that the API is only one > protocol for example when: send: to:? > I found it confusing and I have to check that this is indeed the same. > I think that having one way is far enough. > > What do you think? > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 5, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by stepharo

> I am confused till now I have been reading that pharo does not care > about the past or does not care about being another Smalltalk > implementation and it cares only being Smalltalk inspired . What > changed in the meant time ? Why so much talk about other Smalltalks > and ANSI-Smalltalk ? Nothing we do not diverge for the fun in general. We diverge to improve (of course people can discuss it and think that we are idiots) Now if adding a method in a package can help people porting to Pharo we should not be stupid :) Stef > > On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > Ben Coman wrote > >>> Because the proper English spelling is with lowercase > > +1.... So it may be useful to have an ANSICompatibility package > > +1 to having the proper spelling (that we've fought so hard to > have) as the > only one in the image. And +1 for a compatibility package if there > is a > proven demand for such a thing. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. >

Sept. 5, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by stepharo

> > I agree with that. > To be compatible with these goals, I think my proposition just > needs to be updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. > The point is that we should not force the user to update their > code base. The rule-cased approach is compatible with that if you > transform ANSI code when it gets loaded in the image. > > > True to a point. That point being folks who want to write code that > could play in other ANSI Smalltalks - with your approach, you have > locked those people out, since they CAN'T write ansi code - only Pharo > code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - > and they'd leave to write and live in a different Smalltalk. > > Now, if you had the ANSI compatibility layer that either allowed > conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a > barrier. > > On a different topic, what would be required to amend the ANSI > standard? Maybe a Smalltalk Agreement 2016 that took the standard and > amended some parts (like fixing the spelling) so that going forward, > all Smalltalks could be standard with good English spellings? Chris ANSI is not really good. It is old. And the time investement would be enormous to improve and nobody would care. I read it with attention about strings for example. Because the String API is not really nice in any Smalltalk but this is another story. I do not expect anything from Ansi or any improvements. Let us face it when VW change syntax, added namespaces or whatever they did not care about ANSI. So adding a compatibility package is the way to go. Stef

Sept. 5, 2015

when:send:to: vs. subscribe:send:to:

by stepharo

Hi in announcer we have when: anAnnouncementClass send: aSelector to: anObject "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector. When the message expects one argument (eg #fooAnnouncement:) the announcement is passed as argument. When the message expects two arguments (eg #fooAnnouncement:announcer:) both the announcement and the announcer are passed as argument" ^ self subscribe: anAnnouncementClass send: aSelector to: anObject could we reduce the cognitive load and make sure that the API is only one protocol for example when: send: to:? I found it confusing and I have to check that this is indeed the same. I think that having one way is far enough. What do you think? Stef

Sept. 5, 2015

Nautilus cleaning ideas.

by stepharo

Hi I was reading code and I was wondering if we could have a simple NullPlugin to avoid bottom := self model plugins select: [:each | each position = #bottom ]. bottom ifEmpty: [ ^ nil ]. and bottomMorph := self buildBottomPlugins. bottomMorph ifNotNil: [ bottomHeight := bottomMorph height + 8 ]. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph ifNotNil: [ aWindow addMorph: bottomMorph fullFrame: ((0 @ 1 corner: 1 @ 1) asLayoutFrame topOffset: bottomHeight negated). bottomMorph color: Color transparent ] But I do not think that this is the solution. Just brainstorming.... I imagine that we should change the computation to go from bottomMorph := self buildBottomPlugins. bottomMorph ifNotNil: [ bottomHeight := bottomMorph height + 8 ]. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph ifNotNil: [ aWindow addMorph: bottomMorph fullFrame: ((0 @ 1 corner: 1 @ 1) asLayoutFrame topOffset: bottomHeight negated). bottomMorph color: Color transparent ] into bottomMorph := self buildBottomPlugins. bottomHeight := bottomMorph height + 8. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph addYourselfInto: aWindow. and for the Null version height returns 0 addYourselfInto: does nothing. What do you think? Stef

Sept. 5, 2015

Re: [Pharo-dev] how do I push fixed upstream?

by Nicolai Hess

notify the maintainers 2015-09-05 20:51 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > How do I push "fixed upstream"? > > Since it doesn't have "Fix Review Needed" nobody will see it, review it > and merge it. How should I mark it? Do I need to make another step? > > > https://pharo.fogbugz.com/f/cases/15920/Cannot-inspect-a-SpecTreeNodeModel-… > > Peter >

Sept. 5, 2015