- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Deprecator

by Dale Henrichs

haha! On Thu, Jul 24, 2014 at 10:01 AM, Ben Coman <btc(a)openinworld.com> wrote: > Dale Henrichs wrote: > > ohoh:) > > Deprair > Deprecair > > > Deprecare = Depreca(tion), care (of) > > > > DeDeprecate > > > On Thu, Jul 24, 2014 at 9:11 AM, 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. >> >> >> >> >> 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] DO NOT COMMIT TO PHARO TEAM IN SMALLTALKHUB

by nicolas petton

Hi guys, I will fix it together with Esteban later tonight. I do not have my machine right now so I can't put it down, but please follow esteban's advice and do not commit to any project of the pharo team :) Cheers, Nico Le 24 juil. 2014 18:43, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > the subject says it all :) > (it is broken, Iâm working on fixing it) > > Esteban > > >

July 24, 2014

Re: [Pharo-dev] Deprecator

by Ben Coman

July 24, 2014

Re: [Pharo-dev] Deprecator

by Dale Henrichs

ohoh:) Deprair Deprecair DeDeprecate On Thu, Jul 24, 2014 at 9:11 AM, 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. > > > > > 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] Context merge and external frameworks

by Stephan Eggermont

ClÃ©ment wrote: >If there is something clever we can do in the Pharo image to help for this migration, let us know. The first thing to do is to walk smalltalkhub, squeak source and ss3 packages to check which ones have those extensions. I assume a MooseMonticelloHTTPImporter can be used for that Stephan

July 24, 2014

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