- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Cocoa delegate

by stepharo

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 Esteban Lorenzano

(if I understood fine your question): because ObjC uses informal protocols to define delegates, and an informal protocol might or might not be complete (it just define a collection of methods that you might have). is informal because user could want to define just a part of the protocol (in the example, just windowShouldClose:) and not the many objects the delegate protocol defines. and it is not an abstract class with empty methods because then you force user to extend a particular class (and you cannot not use any arbitrary object as a delegate) Esteban ps: is possible that Cocoa uses delegates and we can use just blocksâ¦ I donât knowâ¦ but the delegating idea is to not pollute apps with thousands of subclasses of widgets with minimal variations (like something we know) :) On 16 Jul 2014, at 10:48, 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. > > > > <Screen Shot 2014-07-16 at 10.47.04.pdf>

July 16, 2014

About Cocoa delegate

by stepharo

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

Roassal2 :: RTAbstractRegularTreeLayout - What is the use of leftGap/topGap?

by Guillaume Larcheveque

It is used in #doExecute: but I didn't notice any change when I defined it. -- *Guillaume Larcheveque*

July 16, 2014

Re: [Pharo-dev] New Cog VMs available

by stepharo

Hi eliot Thanks! I'm really eager to read about the new become implementation. 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

July 16, 2014

Re: [Pharo-dev] Can i be added to Pharo/Pharo40Inbox?

by Marcus Denker

On 16 Jul 2014, at 00:41, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > hi all, > i don't have access to the inbox, could someone add me to the project, please? > my username is vonbecmann. > > MCSmalltalkhubRepository > owner: 'Pharo' > project: 'Pharo40Inbox' > user: '' > password: ââ Doneâ¦ we really need to fix the bug that makes the âpublicâ flag of the repo not persistentâ¦ Marcus

July 16, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Eliot Miranda

On Jul 15, 2014, at 1:50 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > 2014-07-15 17:30 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2014-07-15 20:27 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >>> I find the "... it" suffix obsolete. "Delete it", "Do it", "Print it", >>> etc. >>> >>> Maybe it made sense in the past, but today it feels weird. >>> There is no "Cut it", "Paste it", etc... nor similar in other software. >>> IMO, if the menu is contextual, the context already applies the "it" >>> (subject). > >> Did you notice "it" is only mentionned when you will evaluate (do it / print >> it / debug it / ... )? >> Otherwise, if it's just text editing there is no it. >> So there is a sort of logic. IMO that makes sense, because evaluating is a >> special action. > > I did notice. > > And I believe the "print-it", "do-it" and similar are there because of > historical reasons I don't know, but were carried over without > questioning it, maybe since ST-80 . :) > > Why make a distinction between copying text and > evaluating/profiling/debugging it? I only saw this in Smalltalk. ?? I'd be more than annoyed if copying the text "rm -rf *" evaluated it too... > > Esteban A. Maringolo >

July 16, 2014

Can i be added to Pharo/Pharo40Inbox?

by Bernardo Ezequiel Contreras

hi all, i don't have access to the inbox, could someone add me to the project, please? my username is vonbecmann. MCSmalltalkhubRepository owner: 'Pharo' project: 'Pharo40Inbox' user: '' password: '' Thanks. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

July 15, 2014

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

by kilon alios

Its far from production ready but I am too excited to keep to myself. I present to you Ephestos. Ephestos is a socket bridge that communicates with Blender the most popular and most powerful open source 3d application. http://www.blender.org/ The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already. Even though Ephestos is in total less than 200 lines of code it can already communicate with blender and affect blender properties. Blender properties are basically instance variables for any kind of blender object, 3d object, material, textures etc So already you can affect a huge deal of blender . Unfortunately Blender operators seem to crash Blender , probably I am doing something stupid that I will fix. Blender operators are for performing blender actions so they are very important. I have made a simple video demo of it that can be watched here https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be To use it you need first the Blender addon which can be found here https://github.com/kilon/pyEphestos The code should be inside a folder named "pyEphestos" and placed in Blender addons directory which is located for Macos in Application Support/Blender/VersionsOfBlender/scripts/addons and in Windows should be in App Data/Roaming/..... or you can place it inside the blender folder in similar sub directory You also need the Pharo code which can be found here http://www.smalltalkhub.com/#!/~kilon/Ephestos/ As I said it is far from production ready , but it works. The good news is that the socket communication is blazing fast, at least compared to what I expected. I was able to perform 1000 connections under a second. And each connection carries a 1024 bytes messages , thats a lot of code. Should be possible to pass thousands of lines of code under a second to Blender. My only worry is blender itself since it tends to be very crashy in the areas I am pushing. By the way Always press esc after you enable Ephestos in Blender to close the socket or else it wont free it and next time you wont be able to open the socket and you will have to restart your OS. And do not make an error with the string passed . I need to add an exception for it so it wont crash blender.

July 15, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Esteban A. Maringolo

2014-07-15 17:30 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2014-07-15 20:27 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> I find the "... it" suffix obsolete. "Delete it", "Do it", "Print it", >> etc. >> >> Maybe it made sense in the past, but today it feels weird. >> There is no "Cut it", "Paste it", etc... nor similar in other software. >> IMO, if the menu is contextual, the context already applies the "it" >> (subject). > Did you notice "it" is only mentionned when you will evaluate (do it / print > it / debug it / ... )? > Otherwise, if it's just text editing there is no it. > So there is a sort of logic. IMO that makes sense, because evaluating is a > special action. I did notice. And I believe the "print-it", "do-it" and similar are there because of historical reasons I don't know, but were carried over without questioning it, maybe since ST-80 . :) Why make a distinction between copying text and evaluating/profiling/debugging it? I only saw this in Smalltalk. Esteban A. Maringolo

July 15, 2014