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

[pharo-project/pharo-core] 933576: 40089

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9335766a37c60b53abc83940ce87887d7db68aa2 https://github.com/pharo-project/pharo-core/commit/9335766a37c60b53abc83940… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-16 (Wed, 16 Jul 2014) Changed paths: R Graphics-Display Objects.package/Form.class/class/instance creation/fromUserWithExtent_.st M Komitter.package/extension/MCHttpRepository/class/pharoLocations.st M Monticello.package/MCHttpRepository.class/class/instance creation/inboxRepository.st R Morphic-Base.package/extension/Rectangle/class/originFromUser_.st R Morphic-Base.package/extension/Rectangle/class/originFromUser_grid_.st R ScriptLoader40.package/ScriptLoader.class/instance/accessing/inboxRepository30.st M ScriptLoader40.package/ScriptLoader.class/instance/mc related utils/addHomeRepositoryToAllPackages.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script89.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40089.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40089 11287 Form class>>fromUserWithExtent: freezes because Rectangle class>>originFromUser:grid: is broken. https://pharo.fogbugz.com/f/cases/11287 13550 Should remove the 30 inbox from pharo 40alpha https://pharo.fogbugz.com/f/cases/13550 http://files.pharo.org/image/40/40089.zip

July 16, 2014

[pharo-project/pharo-core]

by GitHub

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

July 16, 2014

[pharo-project/pharo-core] 7e48f5: 40088

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 7e48f55b0a31b59bfbd74421e3ea03f36c69c935 https://github.com/pharo-project/pharo-core/commit/7e48f55b0a31b59bfbd74421… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-16 (Wed, 16 Jul 2014) Changed paths: R FreeType.package/FreeTypeFontProvider.class/class/class initialization/unload.st R FuelTests.package/FLBasicSerializationTest.class/instance/tests/testTimestamp.st R KernelTests.package/DateAndTimeDosEpochTest.class/instance/tests/testAsTimeStamp.st R KernelTests.package/DateAndTimeEpochTest.class/instance/tests/testAsTimeStamp.st R KernelTests.package/DateAndTimeLeapTest.class/instance/tests/testAsTimeStamp.st R KernelTests.package/DateAndTimeUnixEpochTest.class/instance/tests/testAsTimeStamp.st R KernelTests.package/TimeStampTest.class/README.md R KernelTests.package/TimeStampTest.class/definition.st R KernelTests.package/TimeStampTest.class/instance/coverage/classToBeTested.st R KernelTests.package/TimeStampTest.class/instance/coverage/selectorsToBeIgnored.st R KernelTests.package/TimeStampTest.class/instance/private/timestampClass.st R KernelTests.package/TimeStampTest.class/instance/running/setUp.st R KernelTests.package/TimeStampTest.class/instance/running/tearDown.st R KernelTests.package/TimeStampTest.class/instance/tests/testAccessing.st R KernelTests.package/TimeStampTest.class/instance/tests/testArithmetic.st R KernelTests.package/TimeStampTest.class/instance/tests/testArithmeticAcrossDateBoundary.st R KernelTests.package/TimeStampTest.class/instance/tests/testComparing.st R KernelTests.package/TimeStampTest.class/instance/tests/testConverting.st R KernelTests.package/TimeStampTest.class/instance/tests/testDate.st R KernelTests.package/TimeStampTest.class/instance/tests/testFromString.st R KernelTests.package/TimeStampTest.class/instance/tests/testInstanceCreation.st R KernelTests.package/TimeStampTest.class/instance/tests/testMinusDays.st R KernelTests.package/TimeStampTest.class/instance/tests/testMinusSeconds.st R KernelTests.package/TimeStampTest.class/instance/tests/testMinusSecondsOverMidnight.st R KernelTests.package/TimeStampTest.class/instance/tests/testPlusDays.st R KernelTests.package/TimeStampTest.class/instance/tests/testPlusSeconds.st R KernelTests.package/TimeStampTest.class/instance/tests/testPlusSecondsOverMidnight.st R KernelTests.package/TimeStampTest.class/instance/tests/testPrintOn.st R KernelTests.package/TimeStampTest.class/instance/tests/testPrinting.st R KernelTests.package/TimeStampTest.class/instance/tests/testReadFromA1.st R KernelTests.package/TimeStampTest.class/instance/tests/testSorting.st R KernelTests.package/TimeStampTest.class/instance/tests/testStoreOn.st R KernelTests.package/TimeStampTest.class/instance/tests/testTime.st R KernelTests.package/TimeStampTest.class/instance/tests/testTimeStamp.st R KernelTests.package/TimeTest.class/instance/tests/testAsTimeStamp.st R KernelTests.package/TimeTest.class/instance/tests/testTimeStamp.st R KernelTests.package/TimespanTest.class/instance/tests/testAsTimeStamp.st R Morphic-Core.package/Morph.class/class/initialize-release/unload.st M NautilusCommon.package/AnnotationPanePlugin.class/instance/private/buildString.st M NautilusCommon.package/IgorsPlugin.class/instance/as yet unclassified/buildString.st R Network-UUID.package/UUIDGenerator.class/instance/random seed/makeSeedFromSound.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script88.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40088.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40088 13564 Fix all users of TimeStamp: remove Tests, change two remaining clients https://pharo.fogbugz.com/f/cases/13564 13562 remove UUIDGeneration seed generation from sound input https://pharo.fogbugz.com/f/cases/13562 13561 remove some unload class methods https://pharo.fogbugz.com/f/cases/13561 http://files.pharo.org/image/40/40088.zip

July 16, 2014

[pharo-project/pharo-core]

by GitHub

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

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by Esteban Lorenzano

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. > > > - (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 > > > 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. >> >> >> >

July 16, 2014

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