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

Re: [Pharo-dev] Blog post on the new Fast Table

by Sven Van Caekenberghe

Seems like a huge step forward. Good examples. Hopefully we can keep it simple and principled. > On 02 Jul 2015, at 12:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I made a small blog post explaining a bit of the new fast table. > This is to encourage you to start using it and help me finish it :) > > http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo > > cheers, > Esteban

July 2, 2015

Blog post on the new Fast Table

by Esteban Lorenzano

Hi, I made a small blog post explaining a bit of the new fast table. This is to encourage you to start using it and help me finish it :) http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo <http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo> cheers, Esteban

July 2, 2015

Re: [Pharo-dev] [Demo] Yet Another Quake Editor

by Marcus Denker

> On 02 Jul 2015, at 11:35, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > > If I can say something, The configuration itself is not the problem. > > The problem come from: > On Pharo 4.0: > We have a configurationOfOSWindow in the image. > The version of Metacello included in the image will not fetch the last configurationOfOSWindow if it is already in the image. > > Solution: > - Update Metacello in Pharo 4.0 --> the bug entry is open so be patient :-) This will not happen if nobody pushes. Marcus

July 2, 2015

Re: [Pharo-dev] [Demo] Yet Another Quake Editor

by Jean Baptiste Arnaud

If I can say something, The configuration itself is not the problem. The problem come from: On Pharo 4.0: We have a configurationOfOSWindow in the image. The version of Metacello included in the image will not fetch the last configurationOfOSWindow if it is already in the image. Solution: - Update Metacello in Pharo 4.0 --> the bug entry is open so be patient :-) Or Uninstall explicitly (not in the configuration it is ugly) ConfigurationOfOSWindow. If that still do not work that mean you have some specific need update the configuration with your need :-), my job jenkins for Thales doing uninstall ConfigurationOfOSWindow that and that work fine. Really amazing Ronie :-). > On 01 Jul 2015, at 15:05, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Amazing stuff. I would appreciate is some effort put in Woden can be redirected to construct good configuration. > > Uko > > >> On 01 Jul 2015, at 14:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Yes, this is important to improve Woden. >> >> Alexandre >> >> >>> On Jul 1, 2015, at 5:37 AM, Merwan Ouddane <merwanouddane(a)gmail.com> wrote: >>> >>> Awesome :) >>> >>> On mer., 2015-07-01 at 05:34 -0300, Ronie Salgado wrote: >>>> Hello Everyone, >>>> >>>> >>>> I started making a Quake style level editor using Woden. I made an >>>> initial demo in this video: >>>> >>>> https://youtu.be/YDLwGNlAy5U >>>> >>>> >>>> I am creating an user interface similar to the one present in Blender. >>>> Currently I have these commands: >>>> >>>> >>>> G: Grab tool >>>> >>>> S: Scale tool >>>> >>>> E: Expand tool >>>> >>>> X: Delete selected >>>> >>>> Shift-A: Add block >>>> >>>> >>>> Greetings, >>>> >>>> Ronie >>>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

July 2, 2015

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

by Henrik Johansen

> On 02 Jul 2015, at 7:03 , Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Henrik, > > Le 02/07/2015 01:57, Henrik Sperre Johansen a Ã©crit : >> Thierry Goubier wrote >>> Le 01/07/2015 21:29, Sven Van Caekenberghe a Ã©crit : >>>> >>>>> On 01 Jul 2015, at 21:23, Thierry Goubier < >> >>> thierry.goubier@ >> >>> > wrote: >>>>> >>>>> Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : >>>>>> >>>>>>> On 01 Jul 2015, at 21:07, Thierry Goubier >>>>>>> < >> >>> thierry.goubier@ >> >>> > 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. >>> >>> >>> >>>> 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 >> >> You *cannot* look at deliver: in isolation, add:/remove: are the other >> pieces of the same puzzle. > > Yes, I suspected that as well. > >> You may optimize for either delivery performance or subscription >> performance, the important point is that subscriptions considered while >> delivering cannot change during delivery. >> >> Optimized for delivery speed, you swap the entire subcriptions instvar when >> add:/remove: (but you also need monitor use in add:/remove: to resolve >> simultaneous modifications by multiple threads ), and can then deliver: to >> the current subscriptions using do: >> >> Optimized for subscription speed, you add/remove to subscriptions inline >> (protected by a monitor), and maintain immutable delivery by iterating on a >> copy of the subscriptions * >> >> The current implementation is, as you see, optimized for subscription speed. >> It's been discussed before to offer both, as they are both valuable to >> different use cases, or even swap between them based on some heuristic, but >> none have found the time/need. > > This is why my original point was to question the need for a change. As you point out, there is a lot to take care of when touching this code. > >> Cheers, >> Henry >> >> P.S. deliver:to:startingAt: is NOT only called with index 1, look at the >> recursive call in the ifCurtailed: block. >> Basically, it ensures all subscribers are processed even when you encounter >> an exception in on of the subscription handlers. > > Well noted; I didn't consider that. Would forking the announcement delivery change that behavior? The whole thread at http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057… <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057…> is a good read for insight into the thoughts behind the current implementation. While some of Lukas' complaints that related to artifacts of the live migration has been resolved, many of the decisions made wrt optimization target/robust delivery are still valid. My thoughts are now as they were then wrt. forking delivery, it makes code both harder to debug, and is (imho) not a good tradeoff between performance/clarity and percieved benefit. I'd rather the handler be responsible for the decision of whether it is heavy enough to be forked off in order to not block other delivery, than enforce it as a default. I haven't searched for the related thread, but the fork-on-exception behaviour was eventually argued down to only apply for UnhandledErrors. The ifCurtailed: block is still somewhat useful, it lets you do things like put halts in handlers, and still be certain remaining subscribers are notified if you close the debugger, rather than proceed. Cheers, Henry

July 2, 2015

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

by Thierry Goubier

Hi Henrik, Le 02/07/2015 01:57, Henrik Sperre Johansen a Ã©crit : > Thierry Goubier wrote >> Le 01/07/2015 21:29, Sven Van Caekenberghe a Ã©crit : >>> >>>> On 01 Jul 2015, at 21:23, Thierry Goubier < > >> thierry.goubier@ > >> > wrote: >>>> >>>> Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : >>>>> >>>>>> On 01 Jul 2015, at 21:07, Thierry Goubier >>>>>> < > >> thierry.goubier@ > >> > 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. >> >> >> >>> 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 > > You *cannot* look at deliver: in isolation, add:/remove: are the other > pieces of the same puzzle. Yes, I suspected that as well. > You may optimize for either delivery performance or subscription > performance, the important point is that subscriptions considered while > delivering cannot change during delivery. > > Optimized for delivery speed, you swap the entire subcriptions instvar when > add:/remove: (but you also need monitor use in add:/remove: to resolve > simultaneous modifications by multiple threads ), and can then deliver: to > the current subscriptions using do: > > Optimized for subscription speed, you add/remove to subscriptions inline > (protected by a monitor), and maintain immutable delivery by iterating on a > copy of the subscriptions * > > The current implementation is, as you see, optimized for subscription speed. > It's been discussed before to offer both, as they are both valuable to > different use cases, or even swap between them based on some heuristic, but > none have found the time/need. This is why my original point was to question the need for a change. As you point out, there is a lot to take care of when touching this code. > Cheers, > Henry > > P.S. deliver:to:startingAt: is NOT only called with index 1, look at the > recursive call in the ifCurtailed: block. > Basically, it ensures all subscribers are processed even when you encounter > an exception in on of the subscription handlers. Well noted; I didn't consider that. Would forking the announcement delivery change that behavior? > * There's a pathological case when you don't protect the delivery by the > monitor, where the behaviour is strictly speaking different for an initially > empty, and a non-empty IdentitySet if an adding thread was interrupted in > atNewIndex:put:, due to tally = 0 check in Set do:, but from deliverys > perspective, a subscription is always there or not. Thanks, Thierry

July 2, 2015

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

by Henrik Sperre Johansen

Thierry Goubier wrote > Le 01/07/2015 21:29, Sven Van Caekenberghe a Ã©crit : >> >>> On 01 Jul 2015, at 21:23, Thierry Goubier < > thierry.goubier@ > > wrote: >>> >>> Le 01/07/2015 21:11, Sven Van Caekenberghe a Ã©crit : >>>> >>>>> On 01 Jul 2015, at 21:07, Thierry Goubier >>>>> < > thierry.goubier@ > > 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. > > > >> 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 You *cannot* look at deliver: in isolation, add:/remove: are the other pieces of the same puzzle. You may optimize for either delivery performance or subscription performance, the important point is that subscriptions considered while delivering cannot change during delivery. Optimized for delivery speed, you swap the entire subcriptions instvar when add:/remove: (but you also need monitor use in add:/remove: to resolve simultaneous modifications by multiple threads ), and can then deliver: to the current subscriptions using do: Optimized for subscription speed, you add/remove to subscriptions inline (protected by a monitor), and maintain immutable delivery by iterating on a copy of the subscriptions * The current implementation is, as you see, optimized for subscription speed. It's been discussed before to offer both, as they are both valuable to different use cases, or even swap between them based on some heuristic, but none have found the time/need. Cheers, Henry P.S. deliver:to:startingAt: is NOT only called with index 1, look at the recursive call in the ifCurtailed: block. Basically, it ensures all subscribers are processed even when you encounter an exception in on of the subscription handlers. * There's a pathological case when you don't protect the delivery by the monitor, where the behaviour is strictly speaking different for an initially empty, and a non-empty IdentitySet if an adding thread was interrupted in atNewIndex:put:, due to tally = 0 check in Set do:, but from deliverys perspective, a subscription is always there or not. -- View this message in context: http://forum.world.st/SubscriptionRegistry-deliver-tp4835238p4835329.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 1, 2015

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

by Merwan Ouddane

On 30/06/2015 22:35, J.F. Rick wrote: > 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? I will maintain it for a while, if you have any suggestions or questions, don't hesitate :) > > 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-users] 1$ Recognizer in Pharo

by Merwan Ouddane

The DollarP is available too: (Gofer it smalltalkhubUser: 'MerwanOuddane' project: 'DollarPRecognizer'; package: 'DollarPRecognizer') load. On 02/07/2015 00:02, Sven Van Caekenberghe wrote: > Cool, cool, cool ! > >> On 01 Jul 2015, at 23:52, stepharo <stepharo(a)free.fr> wrote: >> >> >> 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] 1$ Recognizer in Pharo

by Sven Van Caekenberghe

Cool, cool, cool ! > On 01 Jul 2015, at 23:52, stepharo <stepharo(a)free.fr> wrote: > > > Now that we have gestures we can interface recognisers. > Thanks Thales for the sponsoring. > > http://youtu.be/Ghxgv8c9OWM > > Stef >

July 1, 2015