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

DO NOT COMMIT TO PHARO TEAM IN SMALLTALKHUB

by Esteban Lorenzano

the subject says it all :) (it is broken, Iâm working on fixing it) Esteban

July 24, 2014

Re: [Pharo-dev] pharo4 inbox (nearly) empty?

by Esteban Lorenzano

no is not please do not commit anything to the Pharo umbrella right now. Esteban On 24 Jul 2014, at 18:37, Nicolai Hess <nicolaihess(a)web.de> wrote: > It is working now. > > > 2014-07-24 18:06 GMT+02:00 stepharo <stepharo(a)free.fr>: > esteban restarted the server but now the MCZ listed there are corrupted :( > > > Stef > > On 24/7/14 17:22, Nicolai Hess wrote: >> http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/main >> This is all I see in this repository: >> >> SLICE-Issue-13627-Move-Transcript-to-Tools-Transcript-StephaneDucasse.1.mcz >> Refactoring-Tests-Core-MarkRizun.98.mcz >> Transcript-StephaneDucasse.26.mcz >> Tool-Transcript-StephaneDucasse.3.mcz >> SLICE-Issue-13681-replace-Smalltalk-tools-shortcuts-with-Morph-shortcutHandler-PavelKrivanek.1.mcz >> Deprecated40-PavelKrivanek.21.mcz >> Keymapping-Core-PavelKrivanek.192.mcz >> Morphic-Core-PavelKrivanek.91.mcz >> SLICE-Issue-13682-Pack-of-simple-refactorings-MarkRizun.1.mcz >> Nautilus-MarkRizun.765.mcz >> NautilusRefactoring-MarkRizun.172.mcz >> Refactoring-Core-MarkRizun.242.mcz >> >> > >

July 24, 2014

Re: [Pharo-dev] pharo4 inbox (nearly) empty?

by Nicolai Hess

It is working now. 2014-07-24 18:06 GMT+02:00 stepharo <stepharo(a)free.fr>: > esteban restarted the server but now the MCZ listed there are corrupted :( > > > Stef > > On 24/7/14 17:22, Nicolai Hess wrote: > > http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/main > This is all I see in this repository: > > SLICE-Issue-13627-Move-Transcript-to-Tools-Transcript-StephaneDucasse.1.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/SLICE-Issue-13627-Move-Transc…> > Refactoring-Tests-Core-MarkRizun.98.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Refactoring-Tests-Core-MarkRi…> > Transcript-StephaneDucasse.26.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Transcript-StephaneDucasse.26…> > Tool-Transcript-StephaneDucasse.3.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Tool-Transcript-StephaneDucas…> > > SLICE-Issue-13681-replace-Smalltalk-tools-shortcuts-with-Morph-shortcutHandler-PavelKrivanek.1.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/SLICE-Issue-13681-replace-Sma…> > Deprecated40-PavelKrivanek.21.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Deprecated40-PavelKrivanek.21…> > Keymapping-Core-PavelKrivanek.192.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Keymapping-Core-PavelKrivanek…> > Morphic-Core-PavelKrivanek.91.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Morphic-Core-PavelKrivanek.91…> > SLICE-Issue-13682-Pack-of-simple-refactorings-MarkRizun.1.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/SLICE-Issue-13682-Pack-of-sim…> > Nautilus-MarkRizun.765.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Nautilus-MarkRizun.765.mcz> > NautilusRefactoring-MarkRizun.172.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/NautilusRefactoring-MarkRizun…> > Refactoring-Core-MarkRizun.242.mcz > <http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/Refactoring-Core-MarkRizun.24…> > > > >

July 24, 2014

Re: [Pharo-dev] this notion of submorphs is a plain bad design idea

by stepharo

I really think that we should radically simplify what we have. MenuMorph just makes me sick. Here is another example of wonderful Morphic code.... StringMorph>>boundsForBalloon "Some morphs have bounds that are way too big. This is a contorted way of making things work okay in PluggableListMorphs, whose list elements historically have huge widths" | ownerOwner | ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and: [ownerOwner isKindOf: PluggableListMorph]) ifTrue: [self boundsInWorld intersect: ownerOwner boundsInWorld ifNone: [self boundsInWorld] ] ifFalse: [super boundsForBalloon]

July 24, 2014

Re: [Pharo-dev] Deprecator

by Camille Teruel

On 24 juil. 2014, at 18:11, Ben Coman <btc(a)openInWorld.com> wrote: > Camille Teruel wrote: >> >> >> On 24 juil. 2014, at 17:05, stepharo <stepharo(a)free.fr> wrote: >> >>> Camille >>> >>> Ammonite is not that sezzy :) >> >> Because it has tentacles? :-D >> >>> May be >>> autoRepair >>> selfRepair :) >> >> Yes for example ;) > > How about 'Reprecator' because you are Rep(airing)(Dep)recations. This one is fun :) > >> >>> >>> Stef >>> On 24/7/14 14:34, Camille Teruel wrote: >>>> Hello Pharo users, >>>> >>>> I'm pleased to announce the release of Deprecator. >>>> It's a prototype of a small tool that permits you to deprecate method by annotating them with a <deprecated: ...> pragma. >>>> This pragma takes a rewrite expression as argument that specifies how to rewrite the message send to the deprecated method. >>>> If such a deprecated method is executed, a warning is thrown and a debugger opens. >>>> This debugger has a little 'Rewrite' button that permits to rewrite the sending method according to the rewrite expression and then resume the execution with the new rewritten sending method :) >>>> The implementation is a proof-of-concept and is a bit hacky here and there, but it works. >>>> >>>> Example: >>>> >>>> You have a class C with a method that you deprecate. >>>> Its rewrite expression tells that if it's executed as the result of a message send of the form: >>>> <receiver> deprecatedMethodArg1: <arg1> arg2: <arg2>, >>>> this message send should be rewritten to: >>>> <receiver> replacementMethodArg1: <arg2> arg2: <arg1>. >>>> Note you can change the order of arguments or even the receiver. >>>> >>>> C>>deprecatedMethodArg1: o1 arg2: o2 >>>> <deprecated: '`@receiver replacementMethodArg1: `@arg2 arg2: `@arg1'> >>>> ^ #deprecated >>>> >>>> C>>replacementMethodArg1: o1 arg2: o2 >>>> ^ #replacement >>>> >>>> C>>senderMethod >>>> ^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2. >>>> >>>> Then if you execute C new senderMethod, and then click on the "Rewrite" button of the debugger, then sending method is rewritten to: >>>> >>>> C>>senderMethod >>>> ^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1. >>>> >>>> and the result is #replacement. >>>> >>>> The repo is on sSmalltalkHub: >>>> MCHttpRepository >>>> location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main' >>>> user: '' >>>> password: '' >>>> >>>> I hope for comments, feature suggestions, code reviews, contributors, etc :) >>>> BTW, if you have a better name for this project let me know! >>>> For example, I thought about Ammonite because it's an extinct animal (analogy with deprecated) and it fits the sea naming theme. >>>> >>>> Cheers, >>>> Camille >>> >> >

July 24, 2014

Re: [Pharo-dev] this notion of submorphs is a plain bad design idea

by stepharo

and yes this one too items ^ submorphs select: [:m | m isKindOf: MenuItemMorph] What a fucking bad design practice! Stef

July 24, 2014

Re: [Pharo-dev] this notion of submorphs is a plain bad design idea

by stepharo

Another nice example hasItems "Answer if the receiver has menu items" ^ submorphs anySatisfy: [:each | each isKindOf: MenuItemMorph]

July 24, 2014

Re: [Pharo-dev] Deprecator

by Ben Coman

July 24, 2014

this notion of submorphs is a plain bad design idea

by stepharo

Not talking about the non polymorphic API.... like that we get such bad isKindOf: ... and brittle to package code. Stef removeStayUpBox | box ext | submorphs isEmpty ifTrue: [^self]. (submorphs first isAlignmentMorph) ifFalse: [^self]. box := submorphs first submorphs last. ext := box extent. (box isKindOf: IconicButton) ifTrue: [box labelGraphic: (Form extent: ext depth: 8); shedSelvedge; borderWidth: 0; lock]. box extent: ext. addTitle: aString icon: aForm updatingSelector: aSelector updateTarget: aTarget "Add a title line at the top of this menu Make aString its initial contents. If aSelector is not nil, then periodically obtain fresh values for its contents by sending aSelector to aTarget.." "Overridden to support menu dragging from the title-bar" | title titleContainer | title := AlignmentMorph newColumn. self setTitleParametersFor: title. "" aForm isNil ifTrue: [titleContainer := title] ifFalse: [| pair | pair := AlignmentMorph newRow. pair color: Color transparent. pair hResizing: #shrinkWrap. pair layoutInset: 0. "" pair addMorphBack: aForm asMorph. "" titleContainer := AlignmentMorph newColumn. titleContainer color: Color transparent. titleContainer vResizing: #shrinkWrap. titleContainer wrapCentering: #center. titleContainer cellPositioning: #topCenter. titleContainer layoutInset: 0. pair addMorphBack: titleContainer. "" title addMorphBack: pair]. "" aSelector ifNil: ["" aString asString linesDo: [:line | titleContainer addMorphBack: (StringMorph contents: line font: StandardFonts menuFont)]] ifNotNil: [| stringMorph | stringMorph := (aTarget perform: aSelector) asStringMorph. stringMorph font: StandardFonts menuFont. stringMorph lock. titleContainer addMorphBack: stringMorph]. "" title setProperty: #titleString toValue: aString. self addMorphFront: title. "" title useSquareCorners. title on: #mouseDown send: #mouseDownInTitle: to: self. (self hasProperty: #needsTitlebarWidgets) ifTrue: [self addStayUpIcons] addStayUpItem "Append a menu item that can be used to toggle this menu's persistence." (self valueOfProperty: #hasTitlebarWidgets ifAbsent: [ false ]) ifTrue: [ ^self ]. self addStayUpIcons. addStayUpItemSpecial "Append a menu item that can be used to toggle this menu's persistent." "This variant is resistant to the MVC compatibility in #setInvokingView:" (self valueOfProperty: #hasTitlebarWidgets ifAbsent: [ false ]) ifTrue: [ ^self ]. self addStayUpIcons.

July 24, 2014

Re: [Pharo-dev] pharo4 inbox (nearly) empty?

by stepharo

July 24, 2014