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

Re: [Pharo-dev] Nautilus strange pattern

by Ben Coman

On Wed, Sep 9, 2015 at 4:41 AM, stepharo <stepharo(a)free.fr> wrote: > just a question that came to my mind while reading your old mail. > > > ">>>" SystemAnnouncer uniqueInstance unsubscribe: mod. "<<<added" > > Are you sure that this is to this one that Nautilus is registered? I'm not sure if its the best approach, but apart from the steps to reproduce in previous link, you can do the following experiment. In a fresh image... "(1)" SystemAnnouncer uniqueInstance inspect. "and review subscriptions tab" "(2)" window := Smalltalk tools openClassBrowser ui window. SystemAnnouncer uniqueInstance inspect. "and review subscriptions tab" "(3)" window delete. Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. SystemAnnouncer uniqueInstance inspect. "and review subscriptions tab" You will find leftover "a PackageTreeNautilusUI" subscriptions. Now repeat starting again with a fresh image, and after evaluating the following... NautilusWindow compile: 'delete | mod | mod := self model. super delete. SystemAnnouncer uniqueInstance unsubscribe: mod. mod ifNotNil: [ mod announce: (WindowClosed new window: self) ] ' "a PackageTreeNautilusUI" is now correctly absent from the SystemAnnouncer subscriptions. A further experiment before and after ammending NautilusWindow>>delete is... 20 timesRepeat: [ window := Smalltalk tools openClassBrowser ui window. window delete. ]. SystemAnnouncer uniqueInstance inspect. I've now logged https://pharo.fogbugz.com/default.asp?16525 cheers -ben

Sept. 9, 2015

Re: [Pharo-dev] garbage on transcript

by stepharo

The idea was to reduce the amount of Parsers (and models of methods) in the systemâ¦ > > I understand that. But parsing for code generation is very different > from the quick and simple parsing for syntax highlighting that Shout > provides, and if one ends up complicating the former to make it > encompass the latter then maybe that's not such a good idea. I'd > rather have a number of smaller simpler parsers than one great big > complex difficult to understand and full of special cases parser > (think... Morphic). Just a thought. Elliot when I start to think about Morphic.... :) > > Marcus > > > _,,,^..^,,,_ > best, Eliot

Sept. 8, 2015

Re: [Pharo-dev] ANSICompatibility package

by stepharo

We should have a SmalltalkCompatibility (not Ansi per se) package were we can add some methods to help migration. Stef Le 8/9/15 06:04, Ben Coman a Ã©crit : > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> Hi, >> >> is there actually such a thing like ANSICompatibility package? >> (it has been mentioned here lately, but I cannot find it) >> >> Thanks, Jan >> > I made it up for the purpose of discussion to see what interest it generated. > Should we start one ? > cheers -ben > >

Sept. 8, 2015

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

by stepharo

Me too :) I do not care that they is a registration mechanism behind. Stef Le 8/9/15 16:30, Ferlicot D. Cyril a Ã©crit : > Le 08/09/2015 10:13, Stephan Eggermont a Ã©crit : > >> When looking at the implementation, it looks as if we should >> replace all #when:send:to: by #subscribe:when:do:, not the other way >> around. >> >> Where is this all coming from? >> >> Stephan >> >> >> > I think that #when:send:to: is more explicit and more understandable, > but this is a personal opinion. >

Sept. 8, 2015

Re: [Pharo-dev] Nautilus strange pattern

by stepharo

just a question that came to my mind while reading your old mail. ">>>" SystemAnnouncer uniqueInstance unsubscribe: mod. "<<<added" Are you sure that this is to this one that Nautilus is registered? Today I discussed with esteban and we agreed that the GroupAnnouncer should be just a class instance var of the Group class. No need to have a subclass of Announcer + a singletong when we can use an announcer. Stef

Sept. 8, 2015

Re: [Pharo-dev] Nautilus strange pattern

by stepharo

Le 8/9/15 01:50, Ben Coman a Ã©crit : > On Tue, Sep 8, 2015 at 5:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> We should make sure to unregister to all announcement when the window is >> closed. > +1. Nautilus seems to leak announcements. Sorry I forgot to log an > issue already for this... > https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg31953.html > > So should I log a new issue now, sure because we should go slowly with Nautilus. I would like to get the state machine that all the if are trying to rebuild in permanence. > or do you want to pick it up under > existing work? > > cheers -ben > >> (Or is there any reason or situation in which nautilus can properly work >> after the window is closed?) >> >> 2015-09-06 10:41 GMT+02:00 stepharo <stepharo(a)free.fr>: >>> 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. 8, 2015

Re: [Pharo-dev] Nautilus strange pattern

by stepharo

Le 7/9/15 23:32, Nicolai Hess a Ã©crit : > We should make sure to unregister to all announcement when the window > is closed. > (Or is there any reason or situation in which nautilus can properly > work after the window is closed?) Yes I was thinking about this too. I took an image and removed all the window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. and tried all kind of combination I could imagine. It seemed to work but I should continue to experiment. Stef > > 2015-09-06 10:41 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > 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. 8, 2015

Re: [Pharo-dev] Two new help topics

by stepharo

Thanks alex. Le 8/9/15 20:11, Alexandre Bergel a Ã©crit : > Hi! > > I made two contribution in the Pharo inbox: > 16521 - Help topic for contributing to the catalog > 16520 - Help topic for how to contribute to Pharo basecode > > I think they are good candidates for an inclusion in the base image. > > Cheers, > Alexandre

Sept. 8, 2015

Re: [Pharo-dev] fly-by-helph on icons do not work anymore on the catalog

by stepharo

In fact I have the impression that they were broken before. Not even sure that they worked (many only when we added some of them). Stef Le 8/9/15 22:09, stepharo a Ã©crit : > Hi > > I have the impression that after > > 16496 Provide context menu icons in Catalog browser > https://pharo.fogbugz.com/f/cases/16496 > > the fly-by-help on the icons in the toolbard does not work anymore and > this is really a problem. > > Stef > > >

Sept. 8, 2015

confused about 16496 Provide context menu icons in Catalog browser

by stepharo

Hi torsten this is nice that you improve the catalog browser. 50312 16496 Provide context menu icons in Catalog browser https://pharo.fogbugz.com/f/cases/16496 Now I'm totally confused by the diff on githib. Many changes marked as additions were in fact my code and already there. So I add at lot of problems to understand what you did at the code level. Did you do something special so that all the old changes went marked as new changes? Tx Stef

Sept. 8, 2015