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

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

by Sean P. DeNigris

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 4. Local co-ordinates 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 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. 26, 2014

build validation shows wrong slice loaded

by Max Leske

In 12259 I had validation warnings and so I went and looked at that page for the first time (pretty cool btw!). The problem with issue 12259 is now that there are multiple slices in there. The validation performed on the image has been done correctly with my version of the slice, but all the messages on the page say that itâs Damienâs slice (which doesnât contain the same code and would produce completely different results). So, my guess is, that the name is somehow being cached (?) or something. It would be nice to have the validation show the correct slice to avoid others spending the extra 20 minutes until theyâve figured it outâ¦ :) Cheers, Max

Jan. 26, 2014

Re: [Pharo-dev] Pharoers in San Francisco

by Eliot Miranda

That would be lovely! We could meet in the mission. I know of a great Tapas place on 22nd & Valencia that's great for say 8 to 10 people. Eliot (phone) On Jan 26, 2014, at 12:53 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Hi guys > > I will visit San francisco and I was wondering if some of you are living there. > Because we could meet. > > Stef

Jan. 26, 2014

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

by J.F. Rick

I've spent a considerable amount of time fighting with Morphic trying to get TouchUI and Athens rendering working. Based on that, my feeling is that getting Athens thoroughly integrated into Morphic is key. The way Morphic used to work is that a morph would signal itself as changed, marking its bounds as needing to get redrawn. Once a UI cycle, all the dirty areas would get summed together and any morphs within those bounds would be asked to redraw. Part of the way this worked is by using a clipping canvas. Thus, a morph could decide whether it or its submorphs needed to get drawn based on the clipping area. This was a quite efficient process. Using AthensWrapMorph to move my applications to Athens, I've seen how the speed advantages of Athens can disappear without such a process. Since there is no clipping canvas, all morphs get redrawn for each draw cycle. Compounding the problem, each changed message triggers a redraw. While Athens rendering can be blazingly fast, doing it 48 (actual number for one of my apps) times as many times as necessary does make it seem slow. Another problem is with animation. Athens gives us the possibility to do some really nice animations. So far, I haven't found a way to do these in a way where it doesn't block out the interface. Having support for animations that don't slow down the interface would be a great ground competency to have for Morphic. To me, integrating Athens thoroughly into Morphic and allowing Morphic to take advantage of the speed and flexibility is the next step. After that, event handling should be addressed. Debugging events is a giant pain and part of it is that there is a ton of reflection and event handling happening in an event handler rather than the object itself. Sometimes it isn't clear how the event handler is being created and trying to figure out where something is set becomes frustrating. Anyway, that's my experience. Jeff On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > Sean > Iâm trying to understand how we could work together to share forces on > cleaning morphic. > Now it is not easy because some of the changes are crosscutting many > packages. > If somebody has an idea. > > Stef > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 26, 2014

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

by Tudor Girba

Indeed, I figured that one out, although after I load the code, there is nothing like this (the method is removed from the package). Anyway, the real problem is the Trait one, like I described in my follow up emails. Cheers, Doru On Sun, Jan 26, 2014 at 5:00 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-01-26 Tudor Girba <tudor(a)tudorgirba.com> > > Hi, >> >> If I execute the following code in 30720: >> Gofer new >> smalltalkhubUser: 'Moose' project: 'MooseAlgos'; >> configuration; >> loadDevelopment. >> >> I get an emergency evaluator with a strange Original error: >> MessageNotUnderstood Trait>>layout. >> >> Can anyone have a look at the first one? It seems to be related to some >> deep code changes because the same code works find in 30714. >> >> And also there seems to be something related to a nsWriteStream: message >> somewhere that breaks the Spec debugger in the same process and this is why >> we get an Emergency evaluator instead of the debugger. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > Looks like something in your project rewrites Collection>>flatCollect: from > using writeStream to nsWriteStream. > Although I can not find anything that implements nsWriteStream. > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014

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

by Nicolai Hess

2014-01-26 Tudor Girba <tudor(a)tudorgirba.com> > Hi, > > If I execute the following code in 30720: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > configuration; > loadDevelopment. > > I get an emergency evaluator with a strange Original error: > MessageNotUnderstood Trait>>layout. > > Can anyone have a look at the first one? It seems to be related to some > deep code changes because the same code works find in 30714. > > And also there seems to be something related to a nsWriteStream: message > somewhere that breaks the Spec debugger in the same process and this is why > we get an Emergency evaluator instead of the debugger. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > Looks like something in your project rewrites Collection>>flatCollect: from using writeStream to nsWriteStream. Although I can not find anything that implements nsWriteStream.

Jan. 26, 2014

[pharo-project/pharo-core] afb94f: 30721

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: afb94f06cdf5e57d46bff52dcdf69ce0d6ce0573 https://github.com/pharo-project/pharo-core/commit/afb94f06cdf5e57d46bff52d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-26 (Sun, 26 Jan 2014) Changed paths: A Collections-Support.package/Association.class/instance/testing/analogousCodeTo_.st A KernelTests.package/AdditionalMethodStateTest.class/instance/tests/testAnalogousCodeTo.st M KeyChain.package/PharoUserPermissions.class/instance/protocol/isRoot_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script374.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30721.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TClass.class/instance/subclass creation/variableByteSubclass_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/variableByteSubclass_uses_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/variableSubclass_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/variableSubclass_uses_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/variableWordSubclass_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/variableWordSubclass_uses_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/weakSubclass_instanceVariableNames_classVariableNames_category_.st A Traits.package/TClass.class/instance/subclass creation/weakSubclass_uses_instanceVariableNames_classVariableNames_category_.st Log Message: ----------- 30721 12077 MNU in AdditionalMethodState>>analogousCodeTo: https://pharo.fogbugz.com/f/cases/12077 12712 make sure that all class definition messages without "poolDictionaries" part exist https://pharo.fogbugz.com/f/cases/12712 12711 ReleaseTest #testObsoleteClasses fails https://pharo.fogbugz.com/f/cases/12711 (with postscript) http://files.pharo.org/image/30/30721.zip

Jan. 26, 2014

[pharo-project/pharo-core]

by GitHub

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

Jan. 26, 2014

Fwd: [regression reporter]regression occurred

by Sven Van Caekenberghe

Camillo (as you wrote this stuff), The test below often fails on the CI servers, timing tests are brittle there. Is this test necessary the way it is written now, what do you think ? Sven Begin forwarded message: > From: no-reply(a)ci.inria.fr > Subject: [regression reporter]regression occurred > Date: 26 Jan 2014 16:17:25 GMT+1 > To: marcus.denker(a)inria.fr, estebanlm(a)gmail.com, sven(a)stfx.eu > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/labe… > > 1 regressions found. > KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond

Jan. 26, 2014

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

by Tudor Girba

I looked some more. If I remove the check from the below message it seems to work fine (essentially, re-establishing the code from before). MCPackageManager class>>classModified: anEvent anEvent isPropagation ifTrue: [ ^ self ]. self managersForClass: anEvent classAffected do:[ :mgr | mgr modified: true ]. It seems that the isPropagation was added as an optimization mechanism, but I cannot understand its meaning. Anyone? Could we figure out the issue that was related to the commit? Cheers, Doru On Sun, Jan 26, 2014 at 4:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yep, I can confirm. > Looks like latest update broke something. > > Esteban > > On 26 Jan 2014, at 15:50, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > If I execute the following code in 30720: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > configuration; > loadDevelopment. > > I get an emergency evaluator with a strange Original error: > MessageNotUnderstood Trait>>layout. > > Can anyone have a look at the first one? It seems to be related to some > deep code changes because the same code works find in 30714. > > And also there seems to be something related to a nsWriteStream: message > somewhere that breaks the Spec debugger in the same process and this is why > we get an Emergency evaluator instead of the debugger. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 26, 2014