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

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

by stepharo

nicolai esteban restarted the server and it sounds better. I proposed to copy the inbox and flush it also. 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] pharo4 inbox (nearly) empty?

by btc＠openinworld.com

July 24, 2014

[pharo-project/pharo-core]

by GitHub

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

July 24, 2014

[pharo-project/pharo-core] c48491: 40123

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c4849128db83ff8b14df87f710c678eb11435dc3 https://github.com/pharo-project/pharo-core/commit/c4849128db83ff8b14df87f7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-24 (Thu, 24 Jul 2014) Changed paths: A Deprecated40.package/extension/ToolRegistry/instance/shortcuts.st R Keymapping-Core.package/KMShortcutHandler.class/class/tools/registerToolsOn_.st A Morphic-Core.package/Morph.class/class/shortcuts/shortcutsHandler.st A Morphic-Core.package/Morph.class/class/shortcuts/shortcutsHandler_.st M Morphic-Core.package/Morph.class/definition.st M Morphic-Core.package/Morph.class/instance/event handling/handleKeystroke_.st A Morphic-Core.package/Morph.class/instance/shortcuts/shortcutsHandler.st M Morphic-Widgets-Tree.package/MorphTreeListManager.class/instance/selection change/noteRemovalOfAll_.st M Morphic-Widgets-Tree.package/MorphTreeMorph.class/instance/updating/noteRemovalOfAll_.st M Morphic-Widgets-Tree.package/MorphTreeNodeMorph.class/instance/initialization/initWithContents_prior_forList_indentLevel_.st M Morphic-Widgets-Tree.package/MorphTreeNodeMorph.class/instance/updating/toggleExpandedState.st M Nautilus.package/AbstractNautilusUI.class/class/menu/classesMenu_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/class/insertSubclass.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/class/insertSuperclass.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/inst var/moveInstVarToClass_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/method/moveMethodToClassFor_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/private-class/privateInsertSubclassFor_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/private-class/privateInsertSuperclassFor_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/private-inst var/privateMoveInstVarToClass_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/private-method/privateMoveMethodToClassFor_.st M NautilusRefactoring.package/extension/ClassDescription/instance/instVarRefactoring_.st M NautilusRefactoring.package/extension/ClassDescription/instance/methodRefactoring_.st M NautilusRefactoring.package/extension/ClassDescription/instance/refactoringSubmenu_.st A Refactoring-Core.package/RBAddClassRefactoringTest.class/README.md A Refactoring-Core.package/RBAddClassRefactoringTest.class/definition.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/README.md A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/class/as yet unclassified/model_variable_class_oldClass_.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/definition.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/instance/accessing/oldClass_.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/instance/preconditions/preconditions.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/instance/transforming/collectSendersOfInstVar.st A Refactoring-Core.package/RBMoveInstVarToClassRefactoring.class/instance/transforming/transform.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/README.md A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/class/instance creation/method_class_.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/class/instance creation/model_method_class_.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/definition.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/initialize-release/method_class_.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/preconditions/preconditions.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/printing/storeOn_.st A Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/transforming/transform.st M Refactoring-Tests-Core.package/RBFooLintRuleTest.class/README.md M Refactoring-Tests-Core.package/RBFooLintRuleTest.class/definition.st A Refactoring-Tests-Core.package/RBFooLintRuleTest.class/instance/as yet unclassified/foo.st A Refactoring-Tests-Core.package/RBMoveInstVarToClassTest.class/README.md A Refactoring-Tests-Core.package/RBMoveInstVarToClassTest.class/definition.st A Refactoring-Tests-Core.package/RBMoveInstVarToClassTest.class/instance/failure tests/testMoveInstVarToClassAlreadyDefined.st A Refactoring-Tests-Core.package/RBMoveMethodToClassTest.class/README.md A Refactoring-Tests-Core.package/RBMoveMethodToClassTest.class/definition.st A Refactoring-Tests-Core.package/RBMoveMethodToClassTest.class/instance/failure tests/testMethodAlreadyDefined.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script123.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40123.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40123 13539 receiver of "NodeModel" is Nil https://pharo.fogbugz.com/f/cases/13539 13681 replace Smalltalk tools shortcuts with Morph shortcutHandler https://pharo.fogbugz.com/f/cases/13681 13682 Pack of simple refactorings https://pharo.fogbugz.com/f/cases/13682 http://files.pharo.org/image/40/40123.zip

July 24, 2014

pharo4 inbox (nearly) empty?

by Nicolai Hess

July 24, 2014

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