Le 15/12/14 22:07, phil@highoctane.be a écrit :
On Mon, Dec 15, 2014 at 9:21 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Nautilus is not using Spec.
My mistake.
It uses tons of announcements...
yes far too many. I'm writing a kind of roadmap for spec now and reading again the code because I fall apart :)
Phil
And yes we need to do a pass on it and simplify it.
Stef
Le 15/12/14 14:54, phil@highoctane.be <mailto:phil@highoctane.be> a écrit :
Le 15 déc. 2014 13:00, "Henrik Johansen" <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> a écrit : > > I thought I'd fix a small bug following https://pharo.fogbugz.com/f/cases/14604 , the DiffMorphChangeRecordConverters referenceList does not get updated to the new model's list when reverting a method, so after reverting, the left pane will always show (and compare against) the last version, rather than the previous from selected. > > No problem, as per the discussion of Spec's excessive annoucement wrapping/ValueHolder appetite, let's try do the simple thing and add a small Announcement subscription, essentially: > browser listModel announcer when: ValueChanged send: #updateReferences: to: aConverter. > > <rant> > To my surprise, that did not work. > Hmmm, must be a different announcement then, ListChanged maybe. After all, it makes sense that a MultiSelectionInList has multiple events that subscribers might be interested in. > > So I started looking at ListModel, <insert relevant explicits here>! > There are, count them and weep, *32* different NewValueModels instance variables, each with different announcers. > > In the case I was looking at, in addition to a listHolder inst var (a CollectionValueHolder), there's a listAnnouncer inst var (an Announcer), so just finding the one through which announcements are made is next to impossible (with the ListModel's own announcer, that's three different ones that would potentially make sense), at least without consulting the *offical* API; #whenListChanged: > > Turns out, in the current implementation, listAnnouncer is the one I want. > Which isn't exposed through an accessor, so you can't even use it to subscribe directly. Yay. > </rant> > > If someone has time to restructure this, I would like to suggest changing the internals radically; > - Introduce new Announcement types for all the different Value holders that make sense (SelectionChanged, ListChanged), and drop the rest. I mean, whenSortingBlockChanged: ?? Who on earth would be interested in that, and not already respond to ListChanged (or it's current equivalent) > - Reduce the amount of announcers to a saner number, say, 1 (or, in a pinch, 2).
Yeah there are "Announcement storms" going on with Spec based tools. I think that it explains a lot of the sluggishness of some tools, like Nautilus.
I saw these when doing some Nautilus plug-ins for my own use (e.g. bring back the original senders/implementors... buttons).
Squeak tools feel very very snappy in comparison. Even on a superfast PC, Pharo as some annoying delays.
Announcements are great but overusing them is receipe for serious head scratching and does not lend itself to easy discoverability of how things do work.
Phil Phil
> > Cheers, > Henry
-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller