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

[Pharo-project] Canvas repackaging (WAS: Re: [update 2.0] #20404)
by Pavel Krivanek Nov. 18, 2012

Nov. 18, 2012

>> On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 20404 >>> ----- >>> >>> Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic >>> http://code.google.com/p/pharo/issues/detail?id=6994 >> >> This fix has very interesting consequence when loading Morphic. >> Because when the Morphic package is loaded, it firstly loads >> Form>>#defaultCanvasClass that calls "Display defaultCanvasClass". But >> Display is a Form too so before the DisplayScreen implementation >> (^FormCanvas) is loaded too, it can lead and leads to infinite >> recursion. >> > I actually wonder if we need all the indirection (defaultCanvasClass and friends). > > I looked at the senders, and it is not used everywhere... Canvas sometimes is rerenced > directly, sometimes not. > > In addition, Canvas should not be in Morpic but there should be a Canvas package that > Morphic *uses* but that is completely independend of Morphic. > > Marcus Does it make sense to create two packages. One for abstract Canvas and second for Form-based Canvas classes? The current (abstract) Canvas implementation seems to be messed with direct Forms support too. Can for example someone from Athens tell something to this topic? However because of atomic loading the repackaging of Canvas classes may not solve this issue and we need to return FormCanvas in Form>>defaultCanvasClass directly. -- Pavel

1 1

[Pharo-project] [update 2.0] #20404
by Marcus Denker Nov. 18, 2012

Nov. 18, 2012

20404 ----- Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic http://code.google.com/p/pharo/issues/detail?id=6994 Issue 6993: update Pharo Kernel generation http://code.google.com/p/pharo/issues/detail?id=6993 Issue 6991: Move #cleanUpForProduction to its own class http://code.google.com/p/pharo/issues/detail?id=6991 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.980.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.735.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1284.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.88.diff -- Marcus Denker -- http://marcusdenker.de

2 3

[Pharo-project] [Issue Tracker] Status
by Marcus Denker Nov. 18, 2012

Nov. 18, 2012

- Open issues: 385 http://code.google.com/p/pharo/issues/list?can=2 - Tagged for 2.0: 133 http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0 - Tagged for 1.4: 21 http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4 Issues with solution that need to be reviewed: 4 http://code.google.com/p/pharo/issues/list?can=2&q=status=HumanReviewNeeded Failing Tests: 4 http://code.google.com/p/pharo/issues/list?can=2&q=status=FailingTest -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 2.0] #20406
by Marcus Denker Nov. 18, 2012

Nov. 18, 2012

20406 ----- Issue 6995: remove TextStyle class>>#initDefaultFontsAndStyle http://code.google.com/p/pharo/issues/detail?id=6995 Issue 6482: switch to fullscreen is dependent on Morphic http://code.google.com/p/pharo/issues/detail?id=6482 Diff information: http://ss3.gemstone.com/ss/Pharo20/Text-MarcusDenker.36.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.90.diff -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 2.0] #20405
by Marcus Denker Nov. 18, 2012

Nov. 18, 2012

20405 ----- Issue 6978: UpdateStreamer and UpdateStreamerTest should be in own packages http://code.google.com/p/pharo/issues/detail?id=6978 Issue 6977: Move LoadUpdatesCommandLineHandler close to UpdateStreamer http://code.google.com/p/pharo/issues/detail?id=6977 Issue 6967: move TestRunnerCommandLineHandler into HudsonBuildTools20 http://code.google.com/p/pharo/issues/detail?id=6967 Issue 6993: update Pharo Kernel generation http://code.google.com/p/pharo/issues/detail?id=6993 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.481.diff http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Core-MarcusDenker.2.diff http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Tests-MarcusDenker.2.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.737.diff http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.61.diff http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.191.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.9.diff -- Marcus Denker -- http://marcusdenker.de

2 2

Re: [Pharo-project] about sharing class binding and others
by Fernando Olivero Nov. 18, 2012

Nov. 18, 2012

I love Marcus idea, classes aren't globals any more, and to access them is simply another message send to a receiver: the environment. ( like the lobby in Self ) . Fernando On Sat, Nov 17, 2012 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > The alternative to the current scheme would be to not hard-code the > class at all in the method at compile time. > > > > Instead of looking up the class and compiling the shared literal > association, we could compile a message send > > to the current environment. > > > > self class environment at: #NameOfClass > > > > And it should be noted that this could be evaluated at Jit-compile > time... the same is true for ivar offsets. There > > is no reason why these should be visible at the image level. The image > could talk about names and let the runtime > > translator infrastucture do the lookups needed for making a static > version that is fast. > > Yes I would like to measure that too. > My benchmarks were to measure the worse case where we have to manually > update the methods each time the class is modified. > > >

3 2

[Pharo-project] [update 2.0] #20403
by Marcus Denker Nov. 17, 2012

Nov. 17, 2012

20403 ----- Issue 6989: Move DebuggerMethodMap to Compiler package http://code.google.com/p/pharo/issues/detail?id=6989 Issue 6988: Run #cleanUpForRelease in postscript http://code.google.com/p/pharo/issues/detail?id=6988 Issue 6894: Add Error tolerant parsing to RB http://code.google.com/p/pharo/issues/detail?id=6894 Diff information: http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1252.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.360.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.103.diff -- Marcus Denker -- http://marcusdenker.de

3 8

[Pharo-project] [update 2.0] #20403
by Marcus Denker Nov. 17, 2012

Nov. 17, 2012

20403 ----- Issue 6989: Move DebuggerMethodMap to Compiler package http://code.google.com/p/pharo/issues/detail?id=6989 Issue 6894: Add Error tolerant parsing to RB http://code.google.com/p/pharo/issues/detail?id=6894 Diff information: http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1253.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.361.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.104.diff -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] pharo-2.0-tests Â» win - Build # 484 - Failure!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr Nov. 17, 2012

Nov. 17, 2012

1 0

[Pharo-project] pharo-2.0-tests Â» linux - Build # 482 - Failure!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr Nov. 17, 2012

Nov. 17, 2012

1 0