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

Re: [Pharo-dev] Platform OS event code

by Ronie Salgado

Hi Stef, The code we developed is not completely committed into my SmalltalkHub repository, specifically the changes to Morphic. The VM changes, have all been committed into my github repository at: https://github.com/ronsaldo/pharo-vm/ The API, except for the integration with Morphic are in my SmalltalkHub repository: http://smalltalkhub.com/#!/~ronsaldo/OSWindow The full image, with a compiled version of the custom VM for Linux, can be found here: https://www.dropbox.com/s/hng4fqzf2yq4hwn/OSWindow.zip More documentation, I will write about it when starting making my website soon. Greetings, Ronie Salgado 2014-01-28 Pharo4Stef <pharo4Stef(a)free.fr> > Hi ronie > > where can we find the event code that you develop with igor ? > > Tx > Stef >

Jan. 28, 2014

Platform OS event code

by Pharo4Stef

Hi ronie where can we find the event code that you develop with igor ? Tx Stef

Jan. 28, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Pharo4Stef

may be in addition we could add layout returning a default value. Stef On 28 Jan 2014, at 13:47, Martin Dias <tinchodias(a)gmail.com> wrote: > > So, what to do? > - Don't send ClassModifiedClassDefinition in SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? > - Implement Trait>>layout ? > - Test for oldClassDefinition isTrait in ClassModifiedClassDefinition>>isPropagating ? > > > > I discussed with Camille and we think it's better this other alternative: to fix class builder to only announce ClassModifiedClassDefinition for the class that really changed its definition. For the subclasses, it won't be announced. This way, it's not necessary to check if it is a propagation. We can remove the two implementors and the unique sender. > > I verified that this was the behavior of "old class builder" (in Pharo 2). Do you agree? > > I can submit a slice this afternoon. > > MartÃn

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Pharo4Stef

> On 28 Jan 2014, at 13:53, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> Ben >> >> I still think that it would have been good to discuss the valueHolder changes in Spec >> before doing it. > > This has been discussed for 2-3 days before I made it actually. Where? because I do not talk about just the question of sean about the name. But the impact. >> Because it broke the tools of people that used Spec like martin and clement >> as well as the documentation ignaccio wrote. We should be cautious about other people too. > > It actually did not break anything. ah so you did not remove asValueHolder. > And it had been reverted two days ago ok good then. > > Ben

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Sven Van Caekenberghe

On 28 Jan 2014, at 18:47, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > I do not know if I publish it somewhere but when I try to make UserManager I added reset on the class side to avoid such code. Yes that would be better, but it is not in the image as far as I can see... > Stef > > On 28 Jan 2014, at 00:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Yes, I just tested: >> >> UserManager instVarNamed: 'default' put: nil. >> UserManager initialize. >> >> fixes the release tests. >> >> I have to go to bed though ;-) >> >> Thx! >> >> Sven >> >> On 28 Jan 2014, at 00:54, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again >>> >>> Ben >>> >>> On 27 Jan 2014, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> OK, I will try and trust you and Sean. >>>> >>>> Well, it is in 30 726, but there are 2 regressions found: >>>> >>>> ReleaseTests.ReleaseTest.testObsoleteClasses >>>> ReleaseTests.ReleaseTest.testUnknownProcesses >>>> >>>> on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong.... >>>> >>>>> On 28 Jan 2014, at 00:13, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>> >>>>>> On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> Are the compatible ? >>>>>>> Does one have to come before the other ? >>>>>>> Are they both needed ? >>>>>> >>>>>> I think we should drop >>>>>>> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder >>>>>> >>>>>> and integrate >>>>>>> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements >>>>>> >>>>>> For at least two reasons: >>>>>> - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) >>>>>> - I do not have to review it :P >>>>>> >>>>>> Ok maybe the second point is not that relevant LOL >>>>>> Just that I am sure that the fix I proposed works well with Spec. >>>>>> And I an pretty sure the other will break it :) >>>>>> >>>>>> I was not aware of another case related to this. >>>>>> It is not flagged Spec nor my name, so there is no way for me to guess it exists. >>>>>> >>>>>> Ben >>>>> >>>> >>>> >>> >> >> > >

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Pharo4Stef

I do not know if I publish it somewhere but when I try to make UserManager I added reset on the class side to avoid such code. Stef On 28 Jan 2014, at 00:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I just tested: > > UserManager instVarNamed: 'default' put: nil. > UserManager initialize. > > fixes the release tests. > > I have to go to bed though ;-) > > Thx! > > Sven > > On 28 Jan 2014, at 00:54, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again >> >> Ben >> >> On 27 Jan 2014, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> OK, I will try and trust you and Sean. >>> >>> Well, it is in 30 726, but there are 2 regressions found: >>> >>> ReleaseTests.ReleaseTest.testObsoleteClasses >>> ReleaseTests.ReleaseTest.testUnknownProcesses >>> >>> on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong.... >>> >>>> On 28 Jan 2014, at 00:13, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> >>>>> On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> Are the compatible ? >>>>>> Does one have to come before the other ? >>>>>> Are they both needed ? >>>>> >>>>> I think we should drop >>>>>> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder >>>>> >>>>> and integrate >>>>>> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements >>>>> >>>>> For at least two reasons: >>>>> - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) >>>>> - I do not have to review it :P >>>>> >>>>> Ok maybe the second point is not that relevant LOL >>>>> Just that I am sure that the fix I proposed works well with Spec. >>>>> And I an pretty sure the other will break it :) >>>>> >>>>> I was not aware of another case related to this. >>>>> It is not flagged Spec nor my name, so there is no way for me to guess it exists. >>>>> >>>>> Ben >>>> >>> >>> >> > >

Jan. 28, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by Pharo4Stef

Sean this is years since I clean Morphic (may be Iâm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea? For example I have remove extract update conditional leaves into method, remove update/changed from leave morph. in your list you have items that should be first validated by an experience. And it would be good to distinguish them from the others. > Pharo4Stef wrote >> Iâm trying to understand how we could work together to share forces on >> cleaning morphic. > > Yes, this will be my focus for 4.0 and I've been thinking a lot about it. > I've spent the last few weeks studying Cuis, Self, and the L and KS stuff > from vpri. > > These are some of the experiments I want to do: > 1. infinite world a la Self > 2. remove all global references i.e. ActiveWorld, World, and ActiveHand > 3. possible remove the concept of mouse and keyboard focus entirely. This is > what Self does and it seems much cleaner. There would just be mouse and > keyboard subscribers and a Morph, let's say a text editor, would "take focus > away from itself" e.g. when there was a mouseDown outside it's bounds I do not know > 4. Local co-ordinates We talk with Alain and Nicolas and one idea could be to introduce a Morph in Bloc (composite) that has local coordinate but still offer a global computation so that we can slowly migrate code to the local > 5. Simplified layouts (maybe based on Cuis or Lesserphic) > 6. Cuis CPU-saving UI loop > 7. Direct Morph construction leading to e.g. Spec models I did not get 7 Remove update:/changed: > > I don't think the cross-cutting problem will be so bad because there doesn't > seem to be much work at this low-level. So our slices will go stale, but > should be easily merge-able. > > I think the safest way to proceed would be: > 1. Hypothesis - write up our ideas about how Morphic currently works > 2. Experiment - write tests for the current behavior > Once we have a theory about existing Morphic, we can repeat. e.g. > 3. Hypothesis - coordinates should be local to owner Morph > 4. Experiment - pick a Morph far from core i.e. nothing used in development > tools and apply. See how it works, if it makes things more clear > Now hopefully we'll have a theory that local coordinates will improve the > system, and we apply it to the whole system: > 5. Set up a hook to easily plug the new behavior in and out. e.g. (pseudo > code) > NewClass class>>#enable > Smalltalk at: #ExistingClass put: NewClass > NewClass class>>#disable > Smalltalk at: #ExistingClass put: OldClass "where OldClass is a class > var" > Maybe we can even put an error handler in the UI loop so that errors > automatically unplug the new code. > > Anyway, just some preliminary ideas... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/process-to-collaborate-on-cleaning-morphic-tp4739325p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Benjamin

On 28 Jan 2014, at 13:53, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Ben > > I still think that it would have been good to discuss the valueHolder changes in Spec > before doing it. This has been discussed for 2-3 days before I made it actually. > Because it broke the tools of people that used Spec like martin and clement > as well as the documentation ignaccio wrote. We should be cautious about other people too. It actually did not break anything. And it had been reverted two days ago Ben

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Sven Van Caekenberghe

On 28 Jan 2014, at 00:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I just tested: > > UserManager instVarNamed: 'default' put: nil. > UserManager initialize. > > fixes the release tests. in 30 728 > I have to go to bed though ;-) > > Thx! > > Sven > > On 28 Jan 2014, at 00:54, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again >> >> Ben >> >> On 27 Jan 2014, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> OK, I will try and trust you and Sean. >>> >>> Well, it is in 30 726, but there are 2 regressions found: >>> >>> ReleaseTests.ReleaseTest.testObsoleteClasses >>> ReleaseTests.ReleaseTest.testUnknownProcesses >>> >>> on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong.... >>> >>>> On 28 Jan 2014, at 00:13, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> >>>>> On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> Are the compatible ? >>>>>> Does one have to come before the other ? >>>>>> Are they both needed ? >>>>> >>>>> I think we should drop >>>>>> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder >>>>> >>>>> and integrate >>>>>> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements >>>>> >>>>> For at least two reasons: >>>>> - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) >>>>> - I do not have to review it :P >>>>> >>>>> Ok maybe the second point is not that relevant LOL >>>>> Just that I am sure that the fix I proposed works well with Spec. >>>>> And I an pretty sure the other will break it :) >>>>> >>>>> I was not aware of another case related to this. >>>>> It is not flagged Spec nor my name, so there is no way for me to guess it exists. >>>>> >>>>> Ben >>>> >>> >>> >> >

Jan. 28, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Pharo4Stef

Ben I still think that it would have been good to discuss the valueHolder changes in Spec before doing it. Because it broke the tools of people that used Spec like martin and clement as well as the documentation ignaccio wrote. We should be cautious about other people too. Stef > On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Are the compatible ? >> Does one have to come before the other ? >> Are they both needed ? > > I think we should drop >> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder > > and integrate >> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements > > For at least two reasons: > - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) > - I do not have to review it :P > > Ok maybe the second point is not that relevant LOL > Just that I am sure that the fix I proposed works well with Spec. > And I an pretty sure the other will break it :) > > I was not aware of another case related to this. > It is not flagged Spec nor my name, so there is no way for me to guess it exists. > > Ben

Jan. 28, 2014