December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ListModel announcer insanity

by stepharo

Nautilus is not using Spec. And yes we need to do a pass on it and simplify it. Stef Le 15/12/14 14:54, phil(a)highoctane.be a Ã©crit : > > > Le 15 dÃ©c. 2014 13:00, "Henrik Johansen" <henrik.s.johansen(a)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 >

Dec. 15, 2014

Re: [Pharo-dev] Spec TabManager clipping issues

by stepharo

Probably hard coded length instead of asking the fonts. Le 14/12/14 23:32, Peter UhnÃ¡k a Ã©crit : > Hi, > > there seems to be some weird clipping issue in Spec's tabs. > The issue is in Pharo4; Pharo3 works fine. > > Pharo4: > > â > Pharo3: > > â > Peter

Dec. 15, 2014

Re: [Pharo-dev] ListModel announcer insanity

by stepharo

Hi henrik What you see is my mistake, I did not get the time to review to code of Spec. Now we should fix it. A while ago I sent a report about the number of Announcers. Now we need help to clean Spec because we are all fully juggling with other duties. I would like to come up with a roadmap. Any suggestions for a roadmap is welcome. I would like to reduce the API - remove as many as "whenChangedDo:" as possible. - revisit announcers because I do not see why the composableModel could not hold the announcer used by the valueHolders and then be shared. Stef Le 15/12/14 13:00, Henrik Johansen 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). > > Cheers, > Henry >

Dec. 15, 2014

[pharo-project/pharo-core] 3a75cc: 40416

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3a75ccaa8823084df99b8dc50ab033515829200b https://github.com/pharo-project/pharo-core/commit/3a75ccaa8823084df99b8dc5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-15 (Mon, 15 Dec 2014) Changed paths: M NativeBoost-Core.package/NBFFICallout.class/instance/accessing/resolveType_.st M Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarButtonMenu_.st A Polymorph-Widgets.package/extension/SystemWindow/instance/taskbarCloseAllToRight.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script416.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40416.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40416 14627 Taskbar > Close all > windows to right https://pharo.fogbugz.com/f/cases/14627 14626 Fix is required in NBFFICallout>>resolveType: to pass NBSQLite3s tests https://pharo.fogbugz.com/f/cases/14626 http://files.pharo.org/image/40/40416.zip

Dec. 15, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 15, 2014

Re: [Pharo-dev] ListModel announcer insanity

by phil＠highoctane.be

Le 15 dÃ©c. 2014 13:00, "Henrik Johansen" <henrik.s.johansen(a)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

Dec. 15, 2014

Re: [Pharo-dev] jenkins and static analysis

by Christophe Demarey

Le 15 dÃ©c. 2014 Ã 12:17, Norbert Hartl a Ã©crit : > >> Am 15.12.2014 um 12:05 schrieb Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >> Wellâ¦ there is this job: https://ci.inria.fr/pharo/view/3.0-Analysis/job/Pharo-3.0-CodeCritics/plot/… >> >> Itâs a bit complicated, but in Pharo4 rule checking got much easier, so you can script something buy yourself, or I can help you. The main question is what do you want to obtain? >> > Back then there was a mapping from lint warnings and errors to a checkstyle format file which can be feeded into the checkstyle plugin on jenkins. That would be fine. > I wouldn't be sad if the categories of lint rules could be seen in the jenkins graph. That might be possible to do but that is hard to configure on the job. The missing thing is an output for the Jenkins Violations plugin (https://wiki.jenkins-ci.org/display/JENKINS/Violations) We could have our own type (critics) or just re-use one (ex: pmd). I also wanted to do that but did not get the time yet. I also want that critics are checked in the same time as tests in jenkins jobs.

Dec. 15, 2014

ListModel announcer insanity

by Henrik Johansen

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). Cheers, Henry

Dec. 15, 2014

Re: [Pharo-dev] [Pharo-users] About Pharo books

by phil＠highoctane.be

We could do a git repo with all books as sumbodules and huge pillar.conf to build the Pharo encyclopedia... Le 15 dÃ©c. 2014 12:21, "kilon alios" <kilon.alios(a)gmail.com> a Ã©crit : > great work guys, thank you for your hard work. I would prefer it if I > could find all documentation in one place and I dont have to look into 10 > books to find what i want. Maybe have the books and one central place with > all documentation ? > > > On Mon, Dec 15, 2014 at 12:50 PM, Luc Fabresse <luc.fabresse(a)gmail.com> > wrote: >> >> Hi Guys, >> >> I've just pushed some commits >> in SquareBracketAssociates/PharoReadyForReviews >> and now it compiles. >> I will do it for the new repos: PharoInProgress and PharoLimbo soon. >> >> @Stef, now https://github.com/pillar-markup/book-skeleton to have the >> latest pillar compilation tool chain. >> >> Cheers, >> >> #Luc >> >> 2014-12-12 21:50 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>> Hi guys >>> >>> I spent a couple of days cleaning PharoForTheEntreprise. So do not >>> stress if you chapters are not where they >>> were used to be :). >>> >>> Here is what I did now there are three stages for Chapters: >>> >>> - Limbo (some notes) >>> - WorkInProgress >>> - ReadyForReviews >>> >>> At the end of this flow we are thinking about the following books: >>> >>> - Entreprise Pharo: a Web Perspective >>> (Zinc, Neo.....) >>> - Spec >>> We decided to write a separate little book >>> >>> - Pharo: The Hidden Parts >>> The ideas is to have many little chapters on not common >>> aspects >>> >>> Stef >>> >>> PS: currently doing a pass on Smacc >>> >>>

Dec. 15, 2014

Re: [Pharo-dev] [Pharo-users] About Pharo books

by kilon alios

great work guys, thank you for your hard work. I would prefer it if I could find all documentation in one place and I dont have to look into 10 books to find what i want. Maybe have the books and one central place with all documentation ? On Mon, Dec 15, 2014 at 12:50 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Guys, > > I've just pushed some commits > in SquareBracketAssociates/PharoReadyForReviews > and now it compiles. > I will do it for the new repos: PharoInProgress and PharoLimbo soon. > > @Stef, now https://github.com/pillar-markup/book-skeleton to have the > latest pillar compilation tool chain. > > Cheers, > > #Luc > > 2014-12-12 21:50 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >> Hi guys >> >> I spent a couple of days cleaning PharoForTheEntreprise. So do not stress >> if you chapters are not where they >> were used to be :). >> >> Here is what I did now there are three stages for Chapters: >> >> - Limbo (some notes) >> - WorkInProgress >> - ReadyForReviews >> >> At the end of this flow we are thinking about the following books: >> >> - Entreprise Pharo: a Web Perspective >> (Zinc, Neo.....) >> - Spec >> We decided to write a separate little book >> >> - Pharo: The Hidden Parts >> The ideas is to have many little chapters on not common >> aspects >> >> Stef >> >> PS: currently doing a pass on Smacc >> >>

Dec. 15, 2014