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

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Stephan Eggermont

On 06/09/15 11:11, Nicolai Hess wrote: > Does the mouseUp on JobProgressMorph work ? > I always wondered how I can stop a long running task. I don't know. Not when running tests from the TestRunner. Stephan

Sept. 6, 2015

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

by Peter UhnÃ¡k

But this is all implementation details, I'm still not sure what exactly we (Stef) want to send. * change diff after each successful CI build for an issue? * diff after the change has been integrated? Peter

Sept. 6, 2015

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

by Peter UhnÃ¡k

> > You are right, Peter. But the way the rest of the world (and many people > using git from Pharo or other Smalltalk implementations) is that you > propose patches which I believe are quite similar to commits. That would be > the equivalent of our slice, I guess. I don't think that slice has equivalence in git, because we have changes much more fine-grained. Git patch is simply a diff between two different versions. And even though github (or bitbucket) offer things like "pull requests", they are only a nicer way of presenting a diff. But this doesn't really matter, because the result will be still the same. Now what might be an interesting work flow would be when an issue is tagged > Fix Review Needed and the CI monkey validates the issue it pushes the slice > to a new IssueNNNNN branch in github and branch diff emailed from there. Unless we want to migrate from fogzbugz to github and do code-reviews there in pull requests there's really no reason to create new branches. You can just create detached commits. (But then again, creating branches is dirt cheap). Actually for a diff you don't need to even commit, because you can compare your current code to the commited one (just like in Monticello). Peter

Sept. 6, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50308 Home: https://github.com/pharo-project/pharo-core

Sept. 6, 2015

[pharo-project/pharo-core] 56e3cc: 50308

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 56e3cce6d903a8bdca1427aad2d90eb15627d7e6 https://github.com/pharo-project/pharo-core/commit/56e3cce6d903a8bdca1427aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-06 (Sun, 06 Sep 2015) Changed paths: A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkInPrimitive.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkOnPrimitive.st A Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/compileAndInstallCompiledMethod.st A Reflectivity.package/ReflectiveMethod.class/instance/evaluation/generatePrimitiveWrapper.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50308.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50308.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-System.package/SystemSystemSettings.class/class/settings/systemSettingOn_.st Log Message: ----------- 50308 16495 Reflectivity: Wrap primitive methods https://pharo.fogbugz.com/f/cases/16495 16039 put a space between numbers and units https://pharo.fogbugz.com/f/cases/16039 http://files.pharo.org/image/50/50308.zip

Sept. 6, 2015

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

by Ben Coman

On 6 Sep 2015 7:42 am, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> wrote: >> >> git clone https://github.com/pharo-project/pharo-core.git >> cd pharo-core/ >> git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > > > But this is post-integration, we want to review things before they break something, not after. > So ideally monkey reviews code on CI and if it passes the diff is sent from CI to the mailing list. > > Also these commits combine several unrelated issues, which is not good for review. > > Isn't what Squeak uses open-source and available somewhere? Can't we just reuse it? I thought the Squeak email diffs were post-commit?? Now what might be an interesting work flow would be when an issue is tagged Fix Review Needed and the CI monkey validates the issue it pushes the slice to a new IssueNNNNN branch in github and branch diff emailed from there. Cheers ben

Sept. 6, 2015

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Nicolai Hess

Does the mouseUp on JobProgressMorph work ? I always wondered how I can stop a long running task. 2015-09-02 12:25 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > We have a few morphs where #on:#mouseDown send: aMessage to: aTarget is > used where I'd expected that to be on #click. Mostly in Rubric and the > Nautilus annotations > > If a morph is supposed to behave as a button, the action should happen > on the #mouseUp, but only if the mouse pointer hasn't moved away from > the morph. That is what #click does. > > And > ExpanderTitleMorph > GrowlMorph > JobProgressMorph > react on #mouseUp instead of #click > > Stephan > > >

Sept. 6, 2015

Nautilus strange pattern

by stepharo

Hi I'm trying to understand what there is a need for this window ifNil: [^ self ] And I wonder is this is not problem due to a global announcer that would keep announcer even when the nautilus widget has been deleted. Any other suggestions? Stef classRemoved: anAnnouncement | class oldPackage | window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. class := anAnnouncement classRemoved. (self classWidget getClassesList includes: class) ifTrue: [ classRecategorized: anAnnouncement window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. self selectedPackage ifNotNil:[:selection | ({ anAnnouncement oldCategory. anAnnouncement newCategory } anySatisfy: [ :each | selection includesCategory: each ]) ifTrue: [ self updatePackageGroupAndClassList ]] classRemoved: anAnnouncement | class oldPackage | window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. class := anAnnouncement classRemoved. (self classWidget getClassesList includes: cla

Sept. 6, 2015

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

by stepharo

Le 5/9/15 22:42, Tudor Girba a Ã©crit : > +1. > > We already deprecated on:send:to:/on:do: and I think we should do the > same for the subscribe:send:to:. Thanks Doru. I thought the same. Because each time I read subscribe: my mind stops for about half or a second until I remember that this is the same as when: send: to: > > Doru > > On Sat, Sep 5, 2015 at 10:24 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@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 <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 6, 2015

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

by Tudor Girba

Hi, There is clearly no downside of having more detailed diff information available. We do not have it now, and the proposal of Stef is more than reasonable. It would be great to have someone willing to spend a bit of time helping him to achieve this. Who would like to give this a try? Cheers, Doru On Sun, Sep 6, 2015 at 10:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 6/9/15 00:33, Sven Van Caekenberghe a Ã©crit : > >> 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 went to github. > I do not want to have to type the hash and this. > How do I know that this this hash corresponds to the fixes that have been > submitted? > > Then the output is ***awful***. > So if this is that easy why can we have a mail with the diff? > > Stef > > > > > >> 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 >>>>>>> >>>>>> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 6, 2015