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

1$ Recognizer in Pharo

by stepharo

Now that we have gestures we can interface recognisers. Thanks Thales for the sponsoring. http://youtu.be/Ghxgv8c9OWM Stef

July 1, 2015

Re: [Pharo-dev] [Pharo-users] Modern Events Touch and Gestures in Pharo.

by stepharo

Hi Jeff Le 30/6/15 22:35, J.F. Rick a Ã©crit : > Awesome! There's a reasonable chance that I can contribute to this (or > at least utilize it), depending on what contracts I get. If I do get > that in the near future, who do I contact about contributing? Off course. Pharo is open and welcoming. We need to have feedback on it. Merwan did all the work with JB :) and now you can have a native window with bloc inside and events :) This is not in the main image. We are waiting for Igor refactoring of OSWindow (should come soon) and we will push the changes of Igor as well as the gestures. Stef > > Cheers, > > Jeff > > On Tue, Jun 30, 2015 at 1:18 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Thanks Thales for the sponsoring. > > https://youtu.be/eNrbH8A5nyY > > Stef and the rmod team >

July 1, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 97cb1d: 50149

by stepharo

Thanks alain!!!! Yes ThreePhaseButton is stepping all the time (wrong architecture) Le 1/7/15 17:32, GitHub a Ã©crit : > 50149 > 15879 No more stepping and huge buttons on a right pane for browsing variables > https://pharo.fogbugz.com/f/cases/15879

July 1, 2015

Re: [Pharo-dev] Seeking help to build an accordion widget for GUI of sQuick

by Nicolai Hess

2015-07-01 18:30 GMT+02:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > Hello All :) > > I am a newbie in Pharo and have started to build my first application i.e. > an offline text search application namely searchQuick. You all are welcome > to fork the code (https://github.com/jig08/sQuick_new) , try the infancy > application and send in suggestions. > Currently, I have built the basic structure of the application using Morphs > and have a lot to cover on the GUI part. > sQ basically returns the list of file titles from the pre-loaded text files > present in the resource folder when a string is searched for. > I plan to build an accordion widget (https://jqueryui.com/accordion/) or > something similiar to view the results. I seek help on the implementation > of > this part. > Looking forward to a positive response. > We have expander morphs : WidgetExamples exampleOtherControls but not with jQueries nice animation/transition. > > Regards > Jigyasa > > > > -- > View this message in context: > http://forum.world.st/Seeking-help-to-build-an-accordion-widget-for-GUI-of-… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

July 1, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Thierry Goubier

Le 01/07/2015 21:29, Sven Van Caekenberghe a Ã©crit : > >> On 01 Jul 2015, at 21:23, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : >>> >>>> On 01 Jul 2015, at 21:07, Thierry Goubier >>>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Le 01/07/2015 20:49, Sven Van Caekenberghe a Ã©crit : >>>>> Reading the code from SubscriptionRegistry>>#deliver: is seems to >>>>> me that *on each announcement* a new array is created with the >>>>> subscriptions that want to handle the announcement. That strikes >>>>> me as pretty inefficient. >>>> >>>> But, when tracing code which is a heavy user of announcements such >>>> as MC loads, it just does not register as a loss compared to the >>>> time lost processing those announcements. >>>> >>>> Do you have time profiles where #deliver: register as a significant >>>> contributor? I don't. >>> >>> No, I don't either. I said 'when reading the code'. Still, it seems >>> odd. >> >> A few other things are odd in this code. >> >>> I use Announcements for logging, then speed of handling is (could be) >>> an issue (as is multi-threaded access). >> >> Agreed. >> >> What I would do with that code is: >> * get rid of #deliver:to:startingAt: because it is only called starting at 1. >> * inline #subscriptionsHandling: into #deliver: >> * inline #deliver:to: as well into #deliver: (as a combined loop) >> * Check that I get the expected speed benefit (I'm probably down at half as many lines as the previous structure, so I win on clarity/compact) > > Totally agree. > >> It seems that the code may have been structured that way to be able to memoize (ok, to cache) the list of interested subscribers, and it turned out it had no sufficient impact on performance to justify managing the associated caching logic. > > Maybe, there is also the comment > > "using a copy, so subscribers can unsubscribe from announcer " Oh, unsubscribe in the code processing an announcement? > but the price to pay for this seems to high to me. And I'm not entirely sure it protects completely against any race condition there. Thierry

July 1, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Sven Van Caekenberghe

> On 01 Jul 2015, at 21:23, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : >> >>> On 01 Jul 2015, at 21:07, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 01/07/2015 20:49, Sven Van Caekenberghe a Ã©crit : >>>> Reading the code from SubscriptionRegistry>>#deliver: is seems to >>>> me that *on each announcement* a new array is created with the >>>> subscriptions that want to handle the announcement. That strikes >>>> me as pretty inefficient. >>> >>> But, when tracing code which is a heavy user of announcements such >>> as MC loads, it just does not register as a loss compared to the >>> time lost processing those announcements. >>> >>> Do you have time profiles where #deliver: register as a significant >>> contributor? I don't. >> >> No, I don't either. I said 'when reading the code'. Still, it seems >> odd. > > A few other things are odd in this code. > >> I use Announcements for logging, then speed of handling is (could be) >> an issue (as is multi-threaded access). > > Agreed. > > What I would do with that code is: > * get rid of #deliver:to:startingAt: because it is only called starting at 1. > * inline #subscriptionsHandling: into #deliver: > * inline #deliver:to: as well into #deliver: (as a combined loop) > * Check that I get the expected speed benefit (I'm probably down at half as many lines as the previous structure, so I win on clarity/compact) Totally agree. > It seems that the code may have been structured that way to be able to memoize (ok, to cache) the list of interested subscribers, and it turned out it had no sufficient impact on performance to justify managing the associated caching logic. Maybe, there is also the comment "using a copy, so subscribers can unsubscribe from announcer " but the price to pay for this seems to high to me. > Thierry > >> >>> Thierry >>> >>> (who discovered that RPackageOrganizer>>#rpackageNamed: could >>> register as heavy on a MC load :( when tracing a MC load)

July 1, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Thierry Goubier

Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : > >> On 01 Jul 2015, at 21:07, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Le 01/07/2015 20:49, Sven Van Caekenberghe a Ã©crit : >>> Reading the code from SubscriptionRegistry>>#deliver: is seems to >>> me that *on each announcement* a new array is created with the >>> subscriptions that want to handle the announcement. That strikes >>> me as pretty inefficient. >> >> But, when tracing code which is a heavy user of announcements such >> as MC loads, it just does not register as a loss compared to the >> time lost processing those announcements. >> >> Do you have time profiles where #deliver: register as a significant >> contributor? I don't. > > No, I don't either. I said 'when reading the code'. Still, it seems > odd. A few other things are odd in this code. > I use Announcements for logging, then speed of handling is (could be) > an issue (as is multi-threaded access). Agreed. What I would do with that code is: * get rid of #deliver:to:startingAt: because it is only called starting at 1. * inline #subscriptionsHandling: into #deliver: * inline #deliver:to: as well into #deliver: (as a combined loop) * Check that I get the expected speed benefit (I'm probably down at half as many lines as the previous structure, so I win on clarity/compact) It seems that the code may have been structured that way to be able to memoize (ok, to cache) the list of interested subscribers, and it turned out it had no sufficient impact on performance to justify managing the associated caching logic. Thierry > >> Thierry >> >> (who discovered that RPackageOrganizer>>#rpackageNamed: could >> register as heavy on a MC load :( when tracing a MC load) >> > > > >

July 1, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Sven Van Caekenberghe

> On 01 Jul 2015, at 21:07, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 01/07/2015 20:49, Sven Van Caekenberghe a Ã©crit : >> Reading the code from SubscriptionRegistry>>#deliver: is seems to me >> that *on each announcement* a new array is created with the >> subscriptions that want to handle the announcement. That strikes me >> as pretty inefficient. > > But, when tracing code which is a heavy user of announcements such as MC loads, it just does not register as a loss compared to the time lost processing those announcements. > > Do you have time profiles where #deliver: register as a significant contributor? I don't. No, I don't either. I said 'when reading the code'. Still, it seems odd. I use Announcements for logging, then speed of handling is (could be) an issue (as is multi-threaded access). > Thierry > > (who discovered that RPackageOrganizer>>#rpackageNamed: could register as heavy on a MC load :( when tracing a MC load) >

July 1, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Thierry Goubier

Le 01/07/2015 20:49, Sven Van Caekenberghe a Ã©crit : > Reading the code from SubscriptionRegistry>>#deliver: is seems to me > that *on each announcement* a new array is created with the > subscriptions that want to handle the announcement. That strikes me > as pretty inefficient. But, when tracing code which is a heavy user of announcements such as MC loads, it just does not register as a loss compared to the time lost processing those announcements. Do you have time profiles where #deliver: register as a significant contributor? I don't. Thierry (who discovered that RPackageOrganizer>>#rpackageNamed: could register as heavy on a MC load :( when tracing a MC load)

July 1, 2015

SubscriptionRegistry>>#deliver:

by Sven Van Caekenberghe

Reading the code from SubscriptionRegistry>>#deliver: is seems to me that *on each announcement* a new array is created with the subscriptions that want to handle the announcement. That strikes me as pretty inefficient. Sven

July 1, 2015