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

[pharo-project/pharo-core]

by GitHub

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

Jan. 30, 2014

[pharo-project/pharo-core] 3f52ee: 30731

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 3f52ee8bc11b2d045bf19eed9e1f5d635d5cf36e https://github.com/pharo-project/pharo-core/commit/3f52ee8bc11b2d045bf19eed… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-30 (Thu, 30 Jan 2014) Changed paths: M OpalCompiler-Core.package/extension/BlockClosure/instance/sourceNode.st M OpalCompiler-Core.package/extension/MethodContext/instance/sourceNode.st A OpalCompiler-Tests.package/MethodMapTests.class/instance/testing - ast mapping/deadContext.st M OpalCompiler-Tests.package/MethodMapTests.class/instance/testing - ast mapping/testBlockSourceNode.st A OpalCompiler-Tests.package/MethodMapTests.class/instance/testing - ast mapping/testBlockWithEnclosedBlockSourceNode.st A OpalCompiler-Tests.package/MethodMapTests.class/instance/testing - ast mapping/testBlockWithTempsSourceNode.st A OpalCompiler-Tests.package/MethodMapTests.class/instance/testing - ast mapping/testDeadContextSourceNode.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script384.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30731.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/ImageCleaner.class/instance/api/cleanUpForProduction.st R Tools.package/ImageCleaner.class/instance/cleaning/classesForCleanUpInProduction.st A Tools.package/ImageCleaner.class/instance/cleaning/helpPackages.st M Tools.package/ImageCleaner.class/instance/cleaning/packagesForCleanUpInProduction.st A Tools.package/ImageCleaner.class/instance/cleaning/testPackages.st M Tools.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st Log Message: ----------- 30731 12732 #sourceNode broken https://pharo.fogbugz.com/f/cases/12732 12751 Improve #cleanUpForProduction https://pharo.fogbugz.com/f/cases/12751 12750 Uppercase/lowercase different in config browser menu vs. buttons https://pharo.fogbugz.com/f/cases/12750 http://files.pharo.org/image/30/30731.zip

Jan. 30, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Frank Shearar

On 30 January 2014 14:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I have nothing invested in the new name, but I think the current discussion > is off-track... > > > Henrik Sperre Johansen wrote >> No, its purpose is to *hold* a *value* in a single place > > That's the purpose of a regular variable. Nothing is gained storage-wise > > > Henrik Sperre Johansen wrote >> through which multiple users can access it. > > This also has nothing to do with access. If you have access to the wrapper, > you could have access to the underlying value > > > Henrik Sperre Johansen wrote >> It *is* by no means a *variable*, nor does it *react* to anything in and >> of itself. > > My argument with ValueHolder is that it doesn't give a clue as to the only > added value it provides over a regular variable, which is change > notification. You mentioned that you could poll, but then why not just poll > an accessor to a regular variable? Then, when I googled it, I found on > wikipedia that "value holder" is already in use in computer science > regarding lazy initializationâ¦ So that was out. > > You're relating to these names as if we are inventing something new. > ReactiveVariable came as a result of googling to see if there is a computer > science term that applies to what we're actually doing. Reactive variables > from FRP seemed close. The C# Reactive Extensions library would call this an Observable. You Subscribe to an Observable, and in this case when the value wrapped by the Observable changes, subscribers learn of the change. frank > So I think this is where we're at: > - Ben already changed it on the Spec side, which is why I objected to "I > don't like it". To ask him to go through the work to change it again, there > should be qualitative benefit. If we do find a valid argument, > MonitoredValue seems closest so far to revealing the intention, but even > that is thin. It can be monitored, but doesn't have to be. It's more like > MonitorableValue (pseudo-English, not an actual suggestion). > - "reactive variable" seems to be an existing term, so let's not argue as to > whether we think the world should change the term, but only if the way it's > already used accurately describes our situation here. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740370.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 30, 2014

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

by Alexandre Bergel

> I'd love to be able to do something like this: > aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2. > Speaking of which, it would be nice if orientation could be included into the equation. Roassal2 will exactly feature this. E.g., -=-=-=-=-=-=-=-=-=-= | e v | v := RTView new. e := (RTBox new color: Color green; width: 150; height: 120) element. v add: e. e when: TRMouseClick do: [ :evt | | anim | anim := RTResizeMove new toExtent: (50 @ 30) during: 3 on: e. v addAnimation: anim. ]. e @ RTDraggable. v open -=-=-=-=-=-=-=-=-=-= 3 means the time taken by the square to shrink. This is based on the work of Viva. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 30, 2014

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

by Alexandre Bergel

Jeff, just wondering: would it make sense to have all the events processes in a new host window? For most of the thing we are doing with visualization, having an external host window will not be a problem, and as far as I can see, this may solve many problem related to io/events/... Alexandre On Jan 26, 2014, at 1:55 PM, J.F. Rick <self(a)je77.com> wrote: > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 30, 2014

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

by Marcus Denker

On 30 Jan 2014, at 15:53, btc(a)openinworld.com wrote: > I was going to say... > As an alternative to nibbling at the edges of Morphic, now that we have PharoKernel3.0-FromTopShrink, which presumably unloads Morphic, I wonder what is involved in loading Juan's SimpleMorphic [1] & [2] > > ...but actually it looks like SimpleMorphic was already integrated in 2010 [3]. (I'd be curious if someone could provide a summary of that.) > The problem is that is was in there and the not used. There was no idea how to migrate from one to the other. > However perhaps the idea still applies since 2010 Juan seems to have improved Morphic further [4]. > The problem is that it is his thing. He does it for Cuis, not for Pharo. Itâs always a bad idea to try to run after someones stuff if that someone has other plans (e.g. that happened with Tweak, too) Marcus

Jan. 30, 2014

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

by btc＠openinworld.com

Jan. 30, 2014

Re: [Pharo-dev] Issues 12717 and 12684

by Sean P. DeNigris

I have nothing invested in the new name, but I think the current discussion is off-track... Henrik Sperre Johansen wrote > No, its purpose is to *hold* a *value* in a single place That's the purpose of a regular variable. Nothing is gained storage-wise Henrik Sperre Johansen wrote > through which multiple users can access it. This also has nothing to do with access. If you have access to the wrapper, you could have access to the underlying value Henrik Sperre Johansen wrote > It *is* by no means a *variable*, nor does it *react* to anything in and > of itself. My argument with ValueHolder is that it doesn't give a clue as to the only added value it provides over a regular variable, which is change notification. You mentioned that you could poll, but then why not just poll an accessor to a regular variable? Then, when I googled it, I found on wikipedia that "value holder" is already in use in computer science regarding lazy initializationâ¦ So that was out. You're relating to these names as if we are inventing something new. ReactiveVariable came as a result of googling to see if there is a computer science term that applies to what we're actually doing. Reactive variables from FRP seemed close. So I think this is where we're at: - Ben already changed it on the Spec side, which is why I objected to "I don't like it". To ask him to go through the work to change it again, there should be qualitative benefit. If we do find a valid argument, MonitoredValue seems closest so far to revealing the intention, but even that is thin. It can be monitored, but doesn't have to be. It's more like MonitorableValue (pseudo-English, not an actual suggestion). - "reactive variable" seems to be an existing term, so let's not argue as to whether we think the world should change the term, but only if the way it's already used accurately describes our situation here. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740370.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2014

Re: [Pharo-dev] [ANN] GitFileTree with no git command line at all

by Torsten Bergmann

There is no MCFileTreeGitRepository(class)>>fromZnUrl: method when loading cleanly from a config browser in Pharo 3.0 latest. So your example in the announcement will not work. I guess this is due to ConfigurationOfGitFileTree-ThierryGoubier.8 in MetaRepoForPharo30 but there is a more recent "ConfigurationOfGitFileTree-ThierryGoubier.9" which loads the new package "MonticelloFileTree-Git-ThierryGoubier.51". Can you please copy the new config to MetaRepoForPharo30... Thx T.

Jan. 30, 2014

Re: [Pharo-dev] [Review]: Case 12737 Morph sends mouseUp twice to handlers

by btc＠openinworld.com

Jan. 30, 2014