- Pharo-dev - lists.pharo.org

Context merge and external frameworks

by ClÃ©ment Bera

Dear pharoers, As some of you may know, ContextPart and MethodContext have been merged into a single class Context for over a month in Pharo 4. The separation between these two classes was historical: back in the old times there was BlockContext as a second subclass of ContextPart for non closures images (images before 2009). This separation makes no sense any more. Now there may be some projects that have method extensions on the class MethodContext or ContextPart and that needs to be fixed. For example, when I try to load Seaside30 in Pharo 40, I get the warning that Seaside depends on ContextPart (probably for Continuations). Dependencies on ContextPart or on MethodContext should be moved to Context. If there is something clever we can do in the Pharo image to help for this migration, let us know. Regards, ClÃ©ment

July 24, 2014

Re: [Pharo-dev] Deprecator

by Camille Teruel

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 ;) > > 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] Deprecator

by stepharo

Camille Ammonite is not that sezzy :) May be autoRepair selfRepair :) 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' > <http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main%27> > 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] Morphic Core dependencies

by stepharo

> [ Morphic-Core ] WorldMorph>>mouseDown: evt > super mouseDown: evt. > self currentWindow ifNotNil: [ :topWindow | > SystemWindow passivateTopWindow ] > > creates another dependencies to Morphic-Widgets-Windows > > > I can see this dependencies as Undeclared in the generated image. > > > There is also > > slideBackToFormerSituation: that could be omve to morphic-base > because it refers to transformation morph. > > > It is very ugly dependency because we need this classes only for one > uncommon case. If it is possible, I would gladly to remove this > obsucre code and not add the next one :-) 100% agreed. We can remove the sliding :) > > > Pavel why don't we use > https://github.com/pharo-project/pharo-workingRoadmaps > > to share possible ideas? > > > I would prefer some on-line solution. Eg. wiki on Google Code that is > still active... But this is online :) you can edit the file online if you want. Have a look because I created a log so that I can record all the problems I see. Stef > > -- Pavel > > > > > > On 24/7/14 14:24, stepharo wrote: > > Hi pavel > > this is related to your interrogations about system window > > Gofer it > smalltalkhubUser: 'BaptisteQuide' project: > 'PackageDependenciesAnalysis'; > configuration; > loadStable > > > >

July 24, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by stepharo

> > one problem is that SystemWindow/isSystemWindow is hardcoded on so > many places... yes but let us make a list to evaluate it. Because Smalltalk was hardcoded and PackageInfo and Preferences and we killed them all :). Stef > > > Tools > ============================ > The current image generated by this configuraton will > crash as soon as you try to press some keyboard button. > The reason is in the method Morph>>#handleKeystroke. This > method contains this code to support Keymapping > > Smalltalk tools shortcuts handleKeystroke: anEvent > inMorph: self. > > > I think that keymapping should not be a tool but the default > way to change and control shortcuts. > Do you have a take on this? > > > +1. Although it can still be improved, keymapping is better than > any other option we have and we should promote it as the default > mechanism. > Cheers, > Doru > > > I checked the package dependensies of Keymappings and Keymapping-Core, > Keymapping-KeyCombinations and Keymapping-Pragmas. The only ugly > dependency is on MenuRegistration (that is dependent on several other > packages). > Becuase this is only one place where the Keymappings are used in > Morphic-Core, I whould prefer to add a class variable named > ShortcutsHandler to Morph and register Keymappings here (or let it be > nil for Morphic-Core) Yes it looks nice. but For morphic-core you do not want to have shortcut. > > -- Pavel > > > > The #tools message is part of Tool-Base package and need > to be there because it uses lazy evaluation that creates a > ToolRegistry instance. Because Tool-Base is not loaded in > the minimal nor Morphic-Core image, it raises DNU > > Solutions: > - introduce some safer form like Smalltalk withToolsDo: > [:tools | ...]. In this case it will not be able to look > if the class variable "Tools" is nil (because of lazy > evaluation) but it will need to do some ugly check of > presence of ToolRegistry class or something similar. In > this case we will produce more unimplemented calls (on > several places in the image because withToolsDo: may be > handy in other cases too) > > - something different :) > > Cheers, > -- Pavel > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

July 24, 2014

Re: [Pharo-dev] [Pharo4] Weekend Project 1: Cleanup Low-Level animation code

by stepharo

Marcus I pushed it to the git pharo-workingRoadmaps Stef On 24/7/14 11:04, stepharo wrote: > Yes marcus may be we should add that description to pharo roadmaps on > github. > I like to document design problems that I encounter but cannot fix fast. > > Stef > > On 24/7/14 10:28, Marcus Denker wrote: >> Hi, >> >> Now with holidays comingâ¦ maybe someone wants to do a small Pharo >> related Project with impact on the future? >> >> Here is suggestion 1. >> >> Context: cleanup graphics. (so e.g. one could replace the canvas later). >> >> Details >> ====== >> Morphic has some very arcane code for animating moving morphs >> around that bypasses layers. >> >> DisplayObject has these methods: >> >> follow:while: >> follow:while:bitsBehind:startingLoc: >> slideFrom:to:nSteps:delay: >> slideWithFirstFrom:to:nSteps:delay: >> displayOnPort:at:rule: >> >> They are used by morphic for some not really important animation that >> for sure >> can be directly done by moving the morphs as morphs around. Bypassing >> and directly using low level (not even Canvas level) functionality is >> for sure not needed. >> >> On the Morph level the users are: >> >> slideBackToFormerSituation: >> vanishAfterSlidingTo:event: >> animationForMoveSuccess: >> >> What to do? >> >> -> rewrite the morphic level code to just move the morphs around. >> -> delete all the code from DisplayObject >> -> review âGrafPortâ usage, as this might have been the last client. >> >> >> Marcus >> > > >

July 24, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Pavel Krivanek

2014-07-24 15:42 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > > 2014-07-24 15:01 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, >> >> >> On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> On 24/7/14 13:37, Pavel Krivanek wrote: >>> >>>> Hi, >>>> >>>> SystemWindows support >>>> ============================ >>>> SystemWindow is quite complex morph that requires many of other morph >>>> classes including text morphs, theming support etc. But in several >>>> situations the system windows play special role and the Morphic core >>>> classes need to be aware of them. So we have several options: >>>> >>>> - (current) do not have SystemWindow & co. in the image but let basic >>>> support of them. That will produce some unimplemented calls >>>> >>>> - create very simple SystemWindow superclass that will be part of the >>>> Morphic-Core but will not have look and possibilities of real SystemWindow >>>> >>>> - include SystemWindow and supporting classes >>>> >>> I had the same questions than you: >>> - I have the impression that systemWindow is really linked to >>> widgets. >>> >> >> I think we should go with option 2 and have a way of providing basic >> windows. SystemWindow is too much anyway. >> > > one problem is that SystemWindow/isSystemWindow is hardcoded on so many > places... > > >> >>> >>> Tools >>>> ============================ >>>> The current image generated by this configuraton will crash as soon as >>>> you try to press some keyboard button. The reason is in the method >>>> Morph>>#handleKeystroke. This method contains this code to support >>>> Keymapping >>>> >>>> Smalltalk tools shortcuts handleKeystroke: anEvent inMorph: self. >>>> >>> >>> I think that keymapping should not be a tool but the default way to >>> change and control shortcuts. >>> Do you have a take on this? >> >> >> +1. Although it can still be improved, keymapping is better than any >> other option we have and we should promote it as the default mechanism. >> >> Cheers, >> Doru >> > > I checked the package dependensies of Keymappings and Keymapping-Core, > Keymapping-KeyCombinations and Keymapping-Pragmas. The only ugly dependency > is on MenuRegistration (that is dependent on several other packages). > Becuase this is only one place where the Keymappings are used in > Morphic-Core, I whould prefer to add a class variable named > ShortcutsHandler to Morph and register Keymappings here (or let it be nil > for Morphic-Core) > https://pharo.fogbugz.com/f/cases/13681/replace-Smalltalk-tools-shortcuts-w… > > -- Pavel > > >> >> >> The #tools message is part of Tool-Base package and need to be there >>>> because it uses lazy evaluation that creates a ToolRegistry instance. >>>> Because Tool-Base is not loaded in the minimal nor Morphic-Core image, it >>>> raises DNU >>>> >>>> Solutions: >>>> - introduce some safer form like Smalltalk withToolsDo: [:tools | ...]. >>>> In this case it will not be able to look if the class variable "Tools" is >>>> nil (because of lazy evaluation) but it will need to do some ugly check of >>>> presence of ToolRegistry class or something similar. In this case we will >>>> produce more unimplemented calls (on several places in the image because >>>> withToolsDo: may be handy in other cases too) >>>> >>>> - something different :) >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

July 24, 2014

Re: [Pharo-dev] File Outs: Can We Have Unix Line Endings?

by Esteban A. Maringolo

2014-07-24 2:17 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Any reason not to? Tedious to continually do "%s/\r/\r/g"s on Mac to fix: > TextStream subclass:^M#UCTextStream^MinstanceVariableNames: > ''^MclassVariableNames: ''^MpoolDictionaries: ''^Mcategory: 'UFFA-Core'!^M! Yes please. And have an option to switch to any other ending for those who want it that way for any uncomprehensible reason :P. But Unix by default. Esteban A. Maringolo

July 24, 2014

Re: [Pharo-dev] On my way to vacation

by Marcus Denker

On 24 Jul 2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > I drive past Lille, and would be interested in spending an afternoon the 29. doing some pair programming > (and the evening preferably with some beer and a good diner). I would be hereâ¦ people are slowly leaving for holidays, but there will be still some here. So for me it would fit perfectly. > Would need to find a place to sleep for us (wife and 2 boys of 5 & 7) though. > My flat is to small for thatâ¦ -> AirBnB? But for just one night maybe too much hassle. -> For 4 people, I heard good reviews about the Suite Novotel directly at the Lille Europe station. http://www.tripadvisor.co.uk/Hotel_Review-g187178-d628635-Reviews-Suite_Nov… Around EUR 90 for a room for 4, plus EU20 or so for Parking. Marcus

July 24, 2014

Re: [Pharo-dev] Morphic Core dependencies

by Serge Stinckwich

On Thu, Jul 24, 2014 at 3:15 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2014-07-24 14:33 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Pavel >> >> [ Morphic-Core ] WorldMorph>>mouseDown: evt >> super mouseDown: evt. >> self currentWindow ifNotNil: [ :topWindow | >> SystemWindow passivateTopWindow ] >> >> creates another dependencies to Morphic-Widgets-Windows > > > I can see this dependencies as Undeclared in the generated image. > >> >> >> There is also >> >> slideBackToFormerSituation: that could be omve to morphic-base because >> it refers to transformation morph. > > > It is very ugly dependency because we need this classes only for one > uncommon case. If it is possible, I would gladly to remove this obsucre code > and not add the next one :-) > >> >> >> Pavel why don't we use >> https://github.com/pharo-project/pharo-workingRoadmaps >> >> to share possible ideas? > > > I would prefer some on-line solution. Eg. wiki on Google Code that is still > active... You could modify these roadmaps online like a Wiki. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 24, 2014