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

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 17 November 2014 12:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 15 Nov 2014, at 10:49 , stepharo <stepharo(a)free.fr> wrote: > > I get dizzy (may be time to go to sleep) but I wonder > why do we need to check first the the window changed and after that it got > closed? > Especially since whenWindowChanged: presuppose that we have access to > window. > Am I missing something? > > self whenWindowChanged: [ :w | > > w whenClosedDo: [ self clear ] ]. > > > ComposableModel>>whenWindowChanged: aBlock > window whenChangedDo: aBlock > > > WindowModel>>whenClosedDo: aBlock > > isClosedHolder whenChangedDo: [:value | > value ifTrue: [ aBlock value ] ] > > > IMHO, APIs that, in essence, glue together announcers and non-self > subscribers, are bad, it's an extra level of indirection with little gains. > (And quite a few restrictions) > Let the announcers be resolvable, and leave it to subscribers to do the > actual subscribing. > > To me, it looks like ValueHolders are being used for the sake of using > ValueHolders, rather than delivering events in the simplest way possible... > Say you do something like > > WindowModel >> announcer > windowAnnouncer := Announcer new > > WindowModel >> createWindow > window := blahblah. > window announcer when: GenericWindowEvent do: [:event self announcer > announce: event ]- > > And all the modelling widgets are free to respond to any window events by > subscribing to the models windowAnnouncer, rather than registering blocks > for value holders linked to single type changes. > > users of whenClosedDo: would instead do something like (usually in an > initialize method where it's passed as a windowModel parameter) > windowModel announcer when: WindowClosed do: aBlock > and as such, the code that starts with self whenWindowChanged (I assume in > the initialize method on a ComposableModel subclass?) > window announcer when: WindowClosed do: [self clear] > > After your post, i think i figured, where i see the design flaw. And can articulate it: - the widget model can expose certain properties , like extent, color etc to its controller - the controller model can expose certain properties of domain object to the widget (for example if we take a list model, it could be: list size, list items, selected item index etc) - both controller and widget models can expose various events to any interested party(es) via subscription mechanism To me it is clear that properties are not events.. They are conceptually distinct, and there's different mechanisms how and where you use them: you treat one as data, and other as behavior. Yes, smalltalk largely blurs the distinction between data & behavior since everything is an object, but i think this is the case where you want to keep distinction clear: - the fact that you should be able to customize your reaction on different events by implementing different behavior, don't means that you should turn that into property e.g. "property which holds a block that will be evaluated when something happens". No, that's complete nonsense.. when you having announcement mechanism, you can simply react to announced event the way you want. And you certainly don't want to react on events like 'what we gonna do when someone changes the block that will be evaluated when certain event triggered'. Because you want to react on user events, not to events that trigger when your application changes the way it wants to handle the events, nor the events that trigger when when your application changes the way it wants to handle the events, that trigger when your application changes the way it wants to handle the events, nor the events that trigger when when your application changes the way it wants to handle the events, that trigger when when your application changes the way it wants to handle the events, that trigger when your application changes the way it wants to handle the events ... (you get an idea :) For example look at: AbstractWidgetModel subclass: #CheckBoxModel instanceVariableNames: 'actionWhenActivatedHolder actionWhenDesactivatedHolder stateHolder labelClickableHolder labelHolder' classVariableNames: '' category: 'Spec-Core-Widgets' It is clear that actionWhenActivatedHolder and actionWhenDesactivatedHolder are events which should just be announced by widget, that anyone would want to handle. period. you don't need ValueHolder(s) to hold blocks running in case of such events. Phew...

Nov. 17, 2014

Re: [Pharo-dev] [smalltalk-research] Re: Julia vs Pharo

by Alexandre Bergel

I would not be that pessimistic. We have to go step by step. I have not had a look at SciSmalltalk. But can the section "15.1 Simple bootstraping exerciseâ of http://bogumilkaminski.pl/files/julia_express.pdf <http://bogumilkaminski.pl/files/julia_express.pdf> be written in SciSmalltalk? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 16, 2014, at 12:42 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Sun, Nov 16, 2014 at 1:45 AM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Hi Serge! >> >> Thanks for sharing this. >> >> I indeed believe that scientific computing will play a big role in Pharo adoption by a large public > > The problem is that you need to invest at least 5 years of work before > having some impact in this domain. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag >

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 17 November 2014 11:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > On 15 Nov 2014, at 10:41 , stepharo <stepharo(a)free.fr> wrote: > > > > initializePresenter > > "Used to specify the subwidgets, and/or to bind them together" > > "By default, do not do anything" > > > > extentHolder whenChangedDo: [:ex | > > self widget ifNotNil: [:widget | > > (widget respondsTo: #extent:) > > ifTrue: [ widget extent: ex ]]]. > > > > > > may be by design the ifNotNil should not be needed and the respondsTo > too.... > > > > pffff. > > > > I don't get it, doesn't the presenter already have an initialize: method > that gets passed in its model? > > So a more "proper" thing to do is > PresenterClassesThatCaresAboutExtent >> initializeFromModel: myModel > myModel extentHolder when: ChangedValue do: [:ann | self extent: > ann newValue] > > The controller and presenter(or view) are always in 1:1 correspondence, not one to many. The idea that you can easily swap out presenter, leaving controller intact is IMO wrong. You either drop both of them and create another pair, if you want, but you never drop only one of them because, by nature, they form a very strong relationship.. which goal is: properly represent the domain object in GUI. For domain object(s), however there's no 1:1 correspondence between domain object its views.. single domain object can have multiple different views. But that in fact means it can have multiple pairs of controller+presenters at once. My point that there's no need for things like 'windowChanged' , where window role is a view in MVC (or MVP) models, to be handled by controller, since it is never changes for single pair of controller and presenter during their lifetime, once initialized and set up. Cheers, > Henry > -- Best regards, Igor Stasenko.

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Henrik Johansen

> On 15 Nov 2014, at 10:49 , stepharo <stepharo(a)free.fr> wrote: > > I get dizzy (may be time to go to sleep) but I wonder > why do we need to check first the the window changed and after that it got closed? > Especially since whenWindowChanged: presuppose that we have access to window. > Am I missing something? > > self whenWindowChanged: [ :w | > w whenClosedDo: [ self clear ] ]. > > > ComposableModel>>whenWindowChanged: aBlock > window whenChangedDo: aBlock > > > WindowModel>>whenClosedDo: aBlock > > isClosedHolder whenChangedDo: [:value | > value ifTrue: [ aBlock value ] ] > IMHO, APIs that, in essence, glue together announcers and non-self subscribers, are bad, it's an extra level of indirection with little gains. (And quite a few restrictions) Let the announcers be resolvable, and leave it to subscribers to do the actual subscribing. To me, it looks like ValueHolders are being used for the sake of using ValueHolders, rather than delivering events in the simplest way possible... Say you do something like WindowModel >> announcer windowAnnouncer := Announcer new WindowModel >> createWindow window := blahblah. window announcer when: GenericWindowEvent do: [:event self announcer announce: event ]- And all the modelling widgets are free to respond to any window events by subscribing to the models windowAnnouncer, rather than registering blocks for value holders linked to single type changes. users of whenClosedDo: would instead do something like (usually in an initialize method where it's passed as a windowModel parameter) windowModel announcer when: WindowClosed do: aBlock and as such, the code that starts with self whenWindowChanged (I assume in the initialize method on a ComposableModel subclass?) window announcer when: WindowClosed do: [self clear] Cheers, Henry 1004

Nov. 17, 2014

Re: [Pharo-dev] ValueHolder analysis

by Henrik Johansen

> On 15 Nov 2014, at 10:41 , stepharo <stepharo(a)free.fr> wrote: > > initializePresenter > "Used to specify the subwidgets, and/or to bind them together" > "By default, do not do anything" > > extentHolder whenChangedDo: [:ex | > self widget ifNotNil: [:widget | > (widget respondsTo: #extent:) > ifTrue: [ widget extent: ex ]]]. > > > may be by design the ifNotNil should not be needed and the respondsTo too.... > > pffff. > I don't get it, doesn't the presenter already have an initialize: method that gets passed in its model? So a more "proper" thing to do is PresenterClassesThatCaresAboutExtent >> initializeFromModel: myModel myModel extentHolder when: ChangedValue do: [:ann | self extent: ann newValue] Cheers, Henry

Nov. 17, 2014

Re: [Pharo-dev] [Vm-dev] Reproducible VM crash with excessive garbage collection

by Max Leske

> On 17.11.2014, at 10:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-11-16 17:46 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > > Hi. > > I may have discovered a bug in the PharoVM (stable and latest), which may have been around for at least two years (I had a very similiar situation about two years ago with Fuel). > > I have a test that fails when a particular method contains â3 timesRepeat: [ Smalltalk garbageCollect ]â. In order to be sure that itâ not the #timesRepeat message thatâs causing the crash, I replaced that with multiple âSmalltalk garbageCollectâ sends. > > The test Iâm talking about ObsoleteTest>>testFixObsoleteSharedPools. To make the test crash the VM, simply add a couple of garbageCollects at the end of SmalltalkImage>>fixObsoleteSharedPools. I tried to come up with a little script to demonstrate the issue but I can only reproduce the problem with Nautilus (which makes me suspect that the problem is related to Nautilus). > > Steps to reproduce: > 1. get a fresh image and the latest vm: > curl get.pharo.org/40+vmLastest <http://get.pharo.org/40+vmLastest> | bash && ./pharo-ui Pharo.image > 2. open the class browser and navigate to SmalltalkImage>>fixObsoleteSharedPools > 3. Append ten âself garbageCollectâ statements to the method. > 4. navigate to ObsoleteTest>>testFixObsoleteSharedPools and click on the test runner icon to the left of the method name. > > I can reproduce this with the Mac VM (OS X 10.10) as well as with the linux VM (Ubuntu 12.04.1). > > Iâve opened an issue for this: https://pharo.fogbugz.com/f/cases/14478/Reproducible-VM-crash-with-excessiv… <https://pharo.fogbugz.com/f/cases/14478/Reproducible-VM-crash-with-excessiv…> > > > Cheers, > Max > > > Can not reproduce this on linux with may own vm build from an older version (on ubuntu 10.04) > > /home/nicolai/devel/pharo-vm/pharo-vm/results/pharo > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> > > Unix built on Oct 14 2014 20:55:01 Compiler: 4.4.3 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> > NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 > > > reproducable on ubuntu 12.? 64 bit (32 bit latest vm): > --------------- > /home/nicolai/Downloads/pharo-vm/pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> Jenkins build #14876 > > Unix built on Nov 13 2014 00:43:51 Compiler: 4.6.3 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> Jenkins build #14876 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 > > > both with image 40370 Thanks Nicolai

Nov. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 0635d1: 40371

by Ben Coman

Marcus Denker wrote: > > > I can confirm those failing tests, in both slice.4 and slice.9, > so strange they didn't show up in the Validator report. > > Now if its less work, you can revert to the original code by doing > "Delay newCodeEnabled: false", and both tests will pass. It late > here, so I'll work on fixing those tests tomorrow. > > > The problem is that we now have a wrong version in the build while > getting a correct one does not work due to the failure of the shrink pass. > > Maybe for now reverting is the best, and then dealing with the issue as > one change and not two. > > Marcus > I am only guessing at possibilities without knowing all that is involved. Whatever you think is best practice / least effort. btw, slice.10 resolves those failing tests. cheers -ben

Nov. 17, 2014

Re: [Pharo-dev] [Vm-dev] Reproducible VM crash with excessive garbage collection

by Nicolai Hess

2014-11-16 17:46 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > Hi. > > I may have discovered a bug in the PharoVM (stable and latest), which may > have been around for at least two years (I had a very similiar situation > about two years ago with Fuel). > > I have a test that fails when a particular method contains â3 timesRepeat: > [ Smalltalk garbageCollect ]â. In order to be sure that itâ not the > #timesRepeat message thatâs causing the crash, I replaced that with > multiple âSmalltalk garbageCollectâ sends. > > The test Iâm talking about ObsoleteTest>>testFixObsoleteSharedPools. To > make the test crash the VM, simply add a couple of garbageCollects at the > end of SmalltalkImage>>fixObsoleteSharedPools. I tried to come up with a > little script to demonstrate the issue but I can only reproduce the problem > with Nautilus (which makes me suspect that the problem is related to > Nautilus). > > Steps to reproduce: > 1. get a fresh image and the latest vm: > curl get.pharo.org/40+vmLastest | bash && ./pharo-ui Pharo.image > 2. open the class browser and navigate to > SmalltalkImage>>fixObsoleteSharedPools > 3. Append ten âself garbageCollectâ statements to the method. > 4. navigate to ObsoleteTest>>testFixObsoleteSharedPools and click on the > test runner icon to the left of the method name. > > I can reproduce this with the Mac VM (OS X 10.10) as well as with the > linux VM (Ubuntu 12.04.1). > > Iâve opened an issue for this: > https://pharo.fogbugz.com/f/cases/14478/Reproducible-VM-crash-with-excessiv… > > > Cheers, > Max > > Can not reproduce this on linux with may own vm build from an older version (on ubuntu 10.04) /home/nicolai/devel/pharo-vm/pharo-vm/results/pharo NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Unix built on Oct 14 2014 20:55:01 Compiler: 4.4.3 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 81b5d19917dcb78f22482a780deec48c53738396 Date: 2014-09-20 14:36:18 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> NBCoInterpreter NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 NBCogit NativeBoost-CogPlugin-HolgerHansPeterFreyther.21 uuid: e0df6e2d-5694-40e2-8035-dc217200b424 Oct 14 2014 reproducable on ubuntu 12.? 64 bit (32 bit latest vm): --------------- /home/nicolai/Downloads/pharo-vm/pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 https://github.com/pharo-project/pharo-vm.git Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14876 Unix built on Nov 13 2014 00:43:51 Compiler: 4.6.3 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 27d505ceffde98d854ed887903a2a94908637a49 Date: 2014-11-04 12:04:48 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14876 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Nov 13 2014 both with image 40370

Nov. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 0635d1: 40371

by Marcus Denker

> > I can confirm those failing tests, in both slice.4 and slice.9, > so strange they didn't chow up in the Validator report. > > Now if its less work, you can revert to the original code by doing "Delay > newCodeEnabled: false", and both tests will pass. It late here, so I'll > work on fixing those tests tomorrow. > The problem is that we now have a wrong version in the build while getting a correct one does not work due to the failure of the shrink pass. Maybe for now reverting is the best, and then dealing with the issue as one change and not two. Marcus

Nov. 17, 2014

WhatsUp from: 2014-11-17 until: 2014-11-30

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-11-30 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Nov. 17, 2014