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

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

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

by Andrei Chis

To push it you need to make a version for that project. Then if that version only fixes a single bug you can put the issue on "fix review needed" and fill in the fields ConfigurationOf and ConfigurationVersion from the issue. Alternatively, if you need to integrate more issues, you can put those issues on fixed upstream and create a new issue that you put on "fix review needed", fill in ConfigurationOf and ConfigurationVersion and add in the description the issues that it addresses. For gtools we usually uses the second approach and integrate when there are 2-3 issues on fixed upstream. I can make a new version for glamour to integrate on monday (I'm travelling tomorrow) but if you want you can give it a try. Creating a new version for glamour with versioner should be easy :) Cheers, Andrei On Sat, Sep 5, 2015 at 8:51 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > 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

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

by stepharo

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 > >> On 05 Sep 2015, at 15:46, stepharo <stepharo(a)free.fr> wrote: >> >> As you wish. Thanks for your time. >> >> Now I will get really frustrated because I will not know simply what you did and I will have missed a good occasion >> to learn something. This is what sending the diff in text simply give us. >> >> Stef >> >> >> Le 5/9/15 14:09, Yuriy Tymchuk a Ã©crit : >>> I found the issue. Fix almost ready. Should I reopen the case, or create a new one? >>> >>> Uko >>> >>> >>> >>>> On 05 Sep 2015, at 13:59, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 05-09-15 08:51, stepharo wrote: >>>>> Hi >>>>> >>>>> I do not know if this is linked to recent changes but we cannot remove >>>>> classes or move them to another package >>>> I can move them to another package using drag-and-drop (issue 16488) >>>> in 50305 >>>> >>>> >>>> Stephan >>>> >>>> >>> >> > >

Sept. 5, 2015

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

by stepharo

Le 5/9/15 20:46, Peter UhnÃ¡k a Ã©crit : > Just because looking at a patch isn't as powerful doesn't make it > useless. There are still benefits > > * you are more aware of code changes > * you can still spot conceptual problems > * it's dead simple; the mail literally arrives at your doorsteps and > all you need to do is look > > of course this isn't replacing proper review, but there is big still > value in it. 100% what I want to say. I will allocate time on a goodies that take a slice and produce a diff > > But even the "regular" process could be improved. > >> -> download the image before it was added >> -> merge the slice. >> > For example I have startup script, that for images that have name > "issuenumber - verify" on startup automatically opens MCBrowser on the > slice so I can merge with two clicks. > (It's not automerged because I want to test behavior before and after > loading the slice.) > > Since I'm mostly verifying my own fixes, I generally don't look at the > changesets, but maybe you could autoopen a diff or something... > Or even add a category to PharoLauncher "Pharo - To Review" so I > wouldn't even need to type in the issue number. > > Peter

Sept. 5, 2015