- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by stepharo

tx mark. I know now I found strange that they push that. Now apparently this is not in the new doc. On 16/7/14 16:56, Mark Bestley wrote: > > You don't have to write the check it is just defensive programming > you can just do > > -(void)someMethod { > if ( [delegate operationShouldProceed] ) { > // do something appropriate > > } } > > then if the delegate does not have operationShouldProceed you get a > selector not found error - which will crash the program. So similar to > smalltalk except that would get a debugger here. > > So depends how certain you have a good delegate or if there is > something you can do if you don't. > > Mark > > On 16/07/2014 09:58, stepharo wrote: >> I found strange to force user to write >> >> Before invoking a delegation method, make sure the delegate implements >> it by sending it a >> >> respondsToSelector: message. >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> >> - (void)someMethod { >> >> if ( [delegate respondsToSelector:@selector(operationShouldProceed)] ){ >> >> if ( [delegate operationShouldProceed] ) { >> // do something appropriate >> >> } } >> >> } >> >> I'm reading also on bindings (could be like valueHolder) and >> targetAction. >> I think that I will have to read that several times :) >> >> https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/C… >> >> >> Stef >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> On 16/7/14 10:48, stepharo wrote: >>> Hi >>> >>> In the quest for a better UI framework :), I was re rereading about >>> delegate in Cocoa. >>> A delegating object will delegate certain operations to a delegate >>> object (check the attachment). >>> Now I was wondering why this is not a simple delegation they wrote: >>> >>> The delegating object sends a message only if the delegate implements >>> the method. It makes this discovery by invoking the NSObject method >>> respondsToSelector: in the delegate first. >>> >>> Cocoa Fundamentals Guide (TP40002974 6.0.0) >>> >> > >

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by stepharo

:) I was not even at this level. Many people confuses delegation and forwarding. I remember that I helped removing some errors in books I reviewed. Stef On 16/7/14 20:07, Eliot Miranda wrote: > > > > On Wed, Jul 16, 2014 at 1:48 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > In the quest for a better UI framework :), I was re rereading > about delegate in Cocoa. > A delegating object will delegate certain operations to a delegate > object (check the attachment). > Now I was wondering why this is not a simple delegation they wrote: > > The delegating object sends a message only if the delegate > implements the method. It makes this discovery by invoking the > NSObject method respondsToSelector: in the delegate first. > > Sad that this framework confuses delegation and forwarding. What it > describes as delegation is merely forwarding. Delegation is quite > different; self is bound to the delegator when running delegated > methods. When (as in Self) one object delegates to another, sends to > self in the second object bind to methods in the first object, the > delegator. In forwarding, self is bound to the object the message is > forwarded to (i.e. normal Smalltalk & ObjectiveC semantics). > > -- > best, > Eliot

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by stepharo

I checked and the new doc does not refer to delegate. I will read the target action and others Stef On 16/7/14 11:04, Esteban Lorenzano wrote: > btwâ¦ while I think cocoa fundamentals is good reading, it is marked as > a retired document. > I think the replace doc is this one: > > https://developer.apple.com/library/mac/documentation/general/conceptual/Co… > > (but since I still do not read it, I donât know if is a good replacement) > > Esteban > > On 16 Jul 2014, at 10:58, stepharo <stepharo(a)free.fr> wrote: > >> I found strange to force user to write >> >> Before invoking a delegation method, make sure the delegate >> implements it by sending it a >> >> respondsToSelector: message. >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> - (void)someMethod { >> >> if ( [delegate respondsToSelector:@selector(operationShouldProceed)] ){ >> >> if ( [delegate operationShouldProceed] ) { >> // do something appropriate >> >> } } >> >> } >> >> I'm reading also on bindings (could be like valueHolder) and >> targetAction. >> I think that I will have to read that several times :) >> >> https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/C… >> >> Stef >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> On 16/7/14 10:48, stepharo wrote: >>> Hi >>> >>> In the quest for a better UI framework :), I was re rereading about >>> delegate in Cocoa. >>> A delegating object will delegate certain operations to a delegate >>> object (check the attachment). >>> Now I was wondering why this is not a simple delegation they wrote: >>> >>> The delegating object sends a message only if the delegate >>> implements the method. It makes this discovery by invoking the >>> NSObject method respondsToSelector: in the delegate first. >>> >>> Cocoa Fundamentals Guide (TP40002974 6.0.0) >>> >> >

July 16, 2014

Re: [Pharo-dev] [ANN] Ephestos - Using and Coding Blender from inside Pharo

by Sebastian Sastre

On Jul 16, 2014, at 12:27 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > One suggestion about the edition of the video. Show some of the > results during the first 30 seconds, and then explain the whole > process to get there. > It's like the cooking shows, where they show the cake already made, > and then the whole process to make it. +1 about using that format. First and quick you show the what, then you take your time to show the how in all its details Congratulations for achieving that, youâre doing a great job and there is huge potential in it! sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

July 16, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Eliot Miranda

Hi Oscar, On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. CallaÃº <oscar.apollo(a)gmail.com> wrote: > Hi guys, > > I'm running some experiments in Pharo. My data is aprox. 1.3GB. > When I load my image on Mac, everything works perfectly. But, when I try to > load the same image on Windows, I get this error: > > Unable to commit memory (1326649344 bytes requested) > > I tried the Pharo VM, cogMT and NBcog with and without the option > > AddressSpaceLimit = 2048 > > in the ini file > > Please help. > What OS are you using? Have you read e.g. http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).… ? -- best, Eliot

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by Eliot Miranda

On Wed, Jul 16, 2014 at 1:48 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > In the quest for a better UI framework :), I was re rereading about > delegate in Cocoa. > A delegating object will delegate certain operations to a delegate object > (check the attachment). > Now I was wondering why this is not a simple delegation they wrote: > > The delegating object sends a message only if the delegate implements > the method. It makes this discovery by invoking the NSObject method respondsToSelector: > in the delegate first. > Sad that this framework confuses delegation and forwarding. What it describes as delegation is merely forwarding. Delegation is quite different; self is bound to the delegator when running delegated methods. When (as in Self) one object delegates to another, sends to self in the second object bind to methods in the first object, the delegator. In forwarding, self is bound to the object the message is forwarded to (i.e. normal Smalltalk & ObjectiveC semantics). -- best, Eliot

July 16, 2014

Re: [Pharo-dev] Pharo Not For The Enterprise

by stepharo

On 16/7/14 17:55, Damien Cassou wrote: > On Wed, Jul 16, 2014 at 5:03 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Can we have another book? LaserGame would fit in fine too. > > I would vote to put your chapter in an existing book for now: either > UpdatedPharoByExample or EnterprisePharo. That way you benefit from > the architecture in place (the jenkins job for example). Then, we can > always move the chapter someplace else. In Fun with Pharo: the Next Fun Book :)

July 16, 2014

Re: [Pharo-dev] Pharo Not For The Enterprise

by stepharo

On 16/7/14 17:41, kilon alios wrote: > Well not everything in there is an Enterprise solution so I think it > would be better if renamed to "Pharo Bible" or "Pharo Encyclopedia" , > for example Pharo Sound is not exactly Enterprise material, though its > my favorite chapter :) Yes it should be called Pharo Limbo and once chapters are ready to get out they should be dispatched to the corresponding book > By the way great work and thanks for reminding to try this out now, I > keep forgetting. > > This can go also inside our Updated PBE as a nice chapter, its after > all ... an example ;) I would prefer to keep Pharo by Example as close as the current one and produce - Fun With Pharo - Pharo for the entreprise - Laser Game Tutorial > > > On Wed, Jul 16, 2014 at 6:03 PM, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > Can we have another book? LaserGame would fit in fine too. > > I've started writing a chapter explaining PhlappyBird > > !PhlappyBird > > PhlappyBird is a smalltalk clone of the well-known little game. It > is a nice example of building a small Morphic application and well > suited for a tutorial. > +file://figures/PhlappyBird.png+ > > !! The top level window > > The top level window is a SystemWindow containing a game scene and > a button to restart the game. The scene will be recreated when the > button is pressed, and it is easiest to just have an instance > variable refering to it. > > [[[ > SystemWindow subclass: #PhlappyBirdGame > instanceVariableNames: 'scene' > classVariableNames: '' > category: 'PhlappyBird' > ]]] > > The game can be started by typing ==PhlappyBirdGame play <DoIt>==. > That creates a new game, opens it window in te world and sets its > width and height. > > [[[ > PhlappyBirdGame class>>play > PhlappyBirdGame new > openInWorld; > extent: 298@510. > ]]] > > In Pharo, ==new== calls ==initialize==. In the initialization, the > scene is created, the window is given a title and made > unresizable, the scene is told that when the space key is pressed > the bird should flap its wings and the restart button is added. > > [[[ > PhlappyBirdGame>>initialize > super initialize. > scene := self newScene. > self > setLabel: 'Phlappy Bird'; > beUnresizeable; > on: Character space do: [ scene flapTheBird ]; > addMorph: self createRestartButton > frame: (0(a)0.92 corner: 1@1) > ]]]. > > The ==addMorph:frame:== message is the morphic implementation of > the composite pattern. All Morphs can be composites. Most Morphs > use ==addMorph:fullFrame:== where the frame provides a layout > object, but a SystemWindow adds a simpler variant where a > proportional layout can be used with a rectangle with values > between 0 and 1 for the relative size. The button takes the 8% of > the bottom part of the user-draw area of the window. > The scene takes the rest. > > [[[ > PhlappyBirdGame>>newScene > | newScene | > newScene := Scene new. > self > addMorph: newScene > frame: (0@0 corner: 1(a)0.92) > ^ newScene > ]]] > > !!! The restart button > The button is a ==PluggableButtonMorph==. A PluggableButtonMorph > is a themeable button, that takes colors, borders and corner > radius from the currently selected theme. > > ;SystemWindow is also a theme-aware object. > > [[[ > PhlappyBirdGame>>createRestartButton > ^ PluggableButtonMorph > on: self > getState: nil > action: #restartPressed > label: #restartButtonLabel > ]]] > > The PluggableButtonMorph will react to being clicked by performing > the ==restartPressed== action method on its model (self), and gets > its label from the ==restartButtonLabel== method. The label is > just a string. A PluggableButtonMorph can show a binary value, and > by ==setState: nil== it is indicated that this is just a plain button. > > [[[ > PhlappyBirdGame>>restartButtonLabel > ^ 'New Game' > ]]] > > When the button is pressed, the current scene is removed as > submorph from the window and a new one is created and added. > [[[ > PhlappyBirdGame>>restartPressed > scene delete. > scene := self newScene. > ]]] > >

July 16, 2014

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Hi Ben, Steph, On Wed, Jul 16, 2014 at 4:31 AM, Ben Coman <btc(a)openinworld.com> wrote: > stepharo wrote: > >> Hi eliot >> >> Thanks! >> I'm really eager to read about the new become implementation. >> > > There is this... > http://www.mirandabanda.org/cogblog/2013/09/13/lazy- > become-and-a-partial-read-barrier/ yes, but I've removed all the scanning of the class table post become. So that post is inaccurate now. Steph, I plan to update the SpurMemoryManager class comment and that post soon to reflect the current design. > cheers -ben > > > I could not fully understand the following but this is exciting to know >> that you removed complexity. >> >> Stef >> >> "The read barriers on method lookup (of the methodClass association in >> super >> sends, of the superclass link, of method dictionaries, method dictionary >> arrays, >> selectors and methods is cheap. So replace scanning classes and method >> dictionaries in the class table post become with read marriewrs on >> methodClass, >> superclass and method dictionary etc on lookup. >> >> The read barrier on an object from which we are going to fetch state >> (such as a >> class or method dictionary) is essentially free on modern machines >> because the >> class index and the state very likely share a cache line, and the >> register code >> for testing is so cheap compared to memory access. Further the read >> barrier on >> selectors is cheap because the method lookup cache is effective in >> reducing the >> number of message lookups and because nil entries need no check. >> >> So nuke all the followNecessaryForwardingInMethod: machinery including >> the >> cmUsesMethodClass hack. Nuke scanClassPostBecome:effects:." >> >> >> >> >> On 15/7/14 21:58, Eliot Miranda wrote: >> >>> ...at http://www.mirandabanda.org/files/Cog/VM/VM.r3041/. >>> >>> >>> The principal changes are fixing a performance regression in the 3040 >>> VMs, fixing some Spur bugs in primitiveClone/shallowCopy, and radically >>> simplifying the Spur become implementation, >>> trading the elimination of lots of post-become class table scanning for >>> adding read barriers to class hierarchy method lookup. >>> >>> >>> CogVM source as per VMMaker.oscog-eem.820/r3041 >>> >>> Put the handling of the cloning of cogged methods in the clone: >>> implementations, >>> removing it from the primitive. Add it to the pinning clone too. >>> >>> Specialize the store check trampoline generation. >>> Move it down to the relevant object representations. >>> >>> Move setting of isRemembered flag to true into SpurGenerationScavenger>> >>> remember:. Inline possibleRootStoreInto: (given that remember: is /not/ >>> inlined. Call remember directly from the ceStoreCheckTrampoline, and >>> hence have remember: answer its argument. >>> >>> Fix localization bug. Variables in initialize methods were not >>> considered >>> references (cuz there are excluded). This caused VMMaker.oscog-eem.816's >>> extraction of zero/false vars to StackInterpreter>>#initialize to cause >>> nextPollUsecs to be localized to checkForEventsMayContextSwitch:. >>> >>> Spur: >>> Fix bug in scanClassPostBecome:effects: with new lazy >>> selector following policy by... throwing it all away. >>> >>> The read barriers on method lookup (of the methodClass association in >>> super >>> sends, of the superclass link, of method dictionaries, method dictionary >>> arrays, >>> selectors and methods is cheap. So replace scanning classes and method >>> dictionaries in the class table post become with read marriewrs on >>> methodClass, >>> superclass and method dictionary etc on lookup. >>> >>> The read barrier on an object from which we are going to fetch state >>> (such as a >>> class or method dictionary) is essentially free on modern machines >>> because the >>> class index and the state very likely share a cache line, and the >>> register code >>> for testing is so cheap compared to memory access. Further the read >>> barrier on >>> selectors is cheap because the method lookup cache is effective in >>> reducing the >>> number of message lookups and because nil entries need no check. >>> >>> So nuke all the followNecessaryForwardingInMethod: machinery including >>> the >>> cmUsesMethodClass hack. Nuke scanClassPostBecome:effects:. >>> >>> Rip out the forwardingCount: measurement code. It causes >>> bad performance regressions (due to failing inlines?) >>> >>> Clean up, e.g. replace followNonImmediateField:ofObject: >>> uses with followObjField:ofObject:. >>> >>> canPinObjects can be inlined. >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> > > -- best, Eliot

July 16, 2014