June 2013 - Pharo-dev - lists.pharo.org

looking at initialization of LayoutProperties :)

by StÃ©phane Ducasse

Morph>>assureLayoutProperties | props | props := self layoutProperties. props ifNil:[ props := LayoutProperties new initializeFrom: self. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ self layoutProperties: props]. ^props LayoutProperties >> initializeFrom: defaultProvider "Initialize the receiver from a default provider" self hResizing: defaultProvider hResizing. self vResizing: defaultProvider vResizing. self disableTableLayout: defaultProvider disableTableLayout. ok up here. Morph>>hResizing "Layout specific. This property describes how the receiver should be resized with respect to its owner and its children. Possible values are: #rigid - do not resize the receiver #spaceFill - resize to fill owner's available space #shrinkWrap - resize to fit children " | props | props := self layoutProperties. ^props ifNil:[#rigid] ifNotNil:[props hResizing]. arghâ¦. Stef

June 25, 2013

[update 2.0] #20608

by Esteban Lorenzano

20608 ----- 10888 Backport 2.0: Compound Extension Methods Unpackaged https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… 10730 Fix for stack serialization with Fuel https://pharo.fogbugz.com/f/cases/10730/Fix-for-stack-serialization-with-Fu… 10994 Backport 2.0: Delays do not work properly directly on image startup https://pharo.fogbugz.com/f/cases/10994/Backport-2-0-Delays-do-not-work-pro… Diff information: http://ss3.gemstone.com/ss/Pharo20/RPackage-Tests-EstebanLorenzano.111.diff http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.216.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1348.diff http://ss3.gemstone.com/ss/Pharo20/FuelTests-EstebanLorenzano.316.diff http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.767.diff

June 25, 2013

layoutProperties strange initialization

by StÃ©phane Ducasse

Morph>>assureLayoutProperties | props | props := self layoutProperties. props == self ifTrue: [props := nil]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ props ifNil: [ props := LayoutProperties new initializeFrom: self. self layoutProperties: props ]. ^props May be for a possible subclass that may return ^ self MorphExtension>>layoutProperties ^layoutProperties layoutProperties "Return the current layout properties associated with the receiver" ^ extension ifNotNil: [ extension layoutProperties] Do not read assureTableProperties :)

June 25, 2013

Re: [Pharo-dev] Is the merge tool broken in 30126?

by StÃ©phane Ducasse

On Jun 25, 2013, at 11:08 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-25, at 11:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Jun 25, 2013, at 11:01 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> strange, I have freetype enabled by default and I don't have problems, >>> are you mergning stuff with utf-8 characters? :P >> >> Can you try my slice :) >> Because I thought the same but on my machine it is endless. > > no problem here, so maybe you have a strange font you use by default ;) I just took the latest image and StartupLoader default executeAtomicItems: { StartupAction name: 'Settings' code: [ "Skip the integration path (So everything works there without noise)" ('.' asFileReference fullName beginsWith: '/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoHarvestingFixes/30/Integration') ifFalse: [ Author fullName: 'StephaneDucasse'. CodeHolder showAnnotationPane: true. Deprecation raiseWarning: true. SHPreferences setStyleTableNamed: 'Tango'. Debugger alwaysOpenFullDebugger: true. PolymorphSystemSettings showDesktopLogo: false. FreeTypeSystemSettings loadFt2Library: true. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] ] runOnce: true. }. So I will not use FreeType

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Camille Teruel

On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: > > On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> the isBlah is not optimal now it is just there and we cannot rewrite everything. >>> I still think that is: is a nice way to kill some of the isPlague in Object. >> >> I still don't see what you solve, and the idea to use symbols for #is: is also >> wrong, for me that's going back to string-based programming. > > well, that's basically my argument agains #is: > IMO is also an important performance issue in many cases, because is replacing a simple send with a string comparison and that can provoke slowdowns in some places (no idea where, this is just theoretical :)... > Of course, as "pharo designers" we should be careful on not overpopulate Object with isBlah methods... but sometimes they are needed :) +1. Indeed, sometimes they are needed. You can't replace every isXXX send with a new visitor or dispatching by adding more and more extension methods all over the place (including Object BTW). Yet a fair amount of these methods can be removed. I think that a lot of these methods exist only because people think that isKindOf:/isMemberOf: are always evil, and its not true. There is at least three cases were I don't feel guilty using isKindOf:/isMemberOf: : - In unit tests - In #= methods - When I really want to ensure that an object is an instance of a specific class (see MethodContext>>#privRefreshWith: for example). This poor's man type checking can be replace with typed slots (that end up using isKindOf/isMemberOf: anyway). If we agree on that we can remove many #isXXX methods. Then there is some #isXXX methods that do not belong to Object (ex: #isTransferable belongs to Morph) and others that can be removed just by refactoring senders. We can also move some of them to extension methods, that doesn't solve the problem but it's a better packaging. Anyway I don't want to rely on #is: method because it conflates a lot of selectors into one. > TL;DR: I agree with Camillo :) > >> >> anyway, this topic has been discussed with enough hot air so far and no progress, >> which means it is absolutely not important. there are more urgent things to done... > >

June 25, 2013

Re: [Pharo-dev] Is the merge tool broken in 30126?

by Camillo Bruni

On 2013-06-25, at 11:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 25, 2013, at 11:01 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> strange, I have freetype enabled by default and I don't have problems, >> are you mergning stuff with utf-8 characters? :P > > Can you try my slice :) > Because I thought the same but on my machine it is endless. no problem here, so maybe you have a strange font you use by default ;)

June 25, 2013

Re: [Pharo-dev] Is the merge tool broken in 30126?

by StÃ©phane Ducasse

On Jun 25, 2013, at 11:01 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > strange, I have freetype enabled by default and I don't have problems, > are you mergning stuff with utf-8 characters? :P Can you try my slice :) Because I thought the same but on my machine it is endless. Stef >> apparently it is broken when I enable >> FT2 >> >> So I removed it and it works. >> >> Stef >> >> On Jun 25, 2013, at 10:39 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >>> Because I cannot merge my fix 10735 to understand the conflicts ;( the merge tools does not show up. >>> I will see how I can recover my work because I spent some hours on it. >>> >>> Stef >> >> > >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Esteban Lorenzano

On Jun 25, 2013, at 10:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 June 2013 10:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On Jun 25, 2013, at 10:47 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 25 June 2013 10:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>>> >>>>> On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> the isBlah is not optimal now it is just there and we cannot rewrite everything. >>>>>> I still think that is: is a nice way to kill some of the isPlague in Object. >>>>> >>>>> I still don't see what you solve, and the idea to use symbols for #is: is also >>>>> wrong, for me that's going back to string-based programming. >>>> >>>> well, that's basically my argument agains #is: >>>> IMO is also an important performance issue in many cases, because is replacing a simple send with a string comparison and that can provoke slowdowns in some places (no idea where, this is just theoretical :)... >>>> Of course, as "pharo designers" we should be careful on not overpopulate Object with isBlah methods... but sometimes they are needed :) >>>> >>> yes, but please, do that, after you remove rest of isXXX methods in Object :) >> >> which rest? >> > > Object selectors select: [ :each | each beginsWith: 'is' ] > > #(#isThisEverCalled #isMorphicEvent #isCollection #isSpecLayout > #isCodeCompletionAllowed #isComplex #isTransferable #isLiteral > #isKindOf: #isInterval #isMorphicModel #isStream #isMorph #isPoint > #isTrait #isCompiledMethod #isCharacter #isMessageSend #isText > #isBlock #isRectangle #isContext #isBehavior #isArray > #isVariableBinding #isColorForm #isSymbol #isDictionary #isHeap > #isNumber #isSystemWindow #isThisEverCalled: #isString #isNotNil > #isRingObject #isMethodProperties #isInteger #isFraction #isColor #is: > #isClosure #isFloat #isMemberOf: #isForm #isSelfEvaluating) > > you welcome :) I know that... but my point is that many of them are ok, and are clearer that some more obscure #is: implementation. I do not see the win on remove them, honestly... IMO is an unnecessary clean that contributes to create less readable core, in the best of cases. > >>> >>>> TL;DR: I agree with Camillo :) >>> >>> >>>> >>>>> >>>>> anyway, this topic has been discussed with enough hot air so far and no progress, >>>>> which means it is absolutely not important. there are more urgent things to done... >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

June 25, 2013

Re: [Pharo-dev] Is the merge tool broken in 30126?

by Camillo Bruni

strange, I have freetype enabled by default and I don't have problems, are you mergning stuff with utf-8 characters? :P On 2013-06-25, at 10:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > apparently it is broken when I enable > FT2 > > So I removed it and it works. > > Stef > > On Jun 25, 2013, at 10:39 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> Because I cannot merge my fix 10735 to understand the conflicts ;( the merge tools does not show up. >> I will see how I can recover my work because I spent some hours on it. >> >> Stef > >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

> > Object selectors select: [ :each | each beginsWith: 'is' ] > > #(#isThisEverCalled #isMorphicEvent #isCollection #isSpecLayout > #isCodeCompletionAllowed #isComplex #isTransferable #isLiteral > #isKindOf: #isInterval #isMorphicModel #isStream #isMorph #isPoint > #isTrait #isCompiledMethod #isCharacter #isMessageSend #isText > #isBlock #isRectangle #isContext #isBehavior #isArray > #isVariableBinding #isColorForm #isSymbol #isDictionary #isHeap > #isNumber #isSystemWindow #isThisEverCalled: #isString #isNotNil > #isRingObject #isMethodProperties #isInteger #isFraction #isColor #is: > #isClosure #isFloat #isMemberOf: #isForm #isSelfEvaluating) > > you welcome :) Yes those are the ones I was talking about. I would like to understand how we can remove them. Stef

June 25, 2013