November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Woe unto thee who assigns to class-side #name!

by stepharo

I would start to remove for real name from Object :) Stef Le 9/11/15 13:05, Sean P. DeNigris a Ã©crit : > Ben Coman wrote >> But Class has an instance variable 'name', >> and Class subclasses --> {ProtoObject class} > He he, of course. Thanks for the clarification! > > > Ben Coman wrote >> should that instance variable and accessors be renamed to 'classname'? > YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha > ha). This is an obscure and scary bug, because it prevents all operations on > the package, so one can not even commit or file out the package. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp485973… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Nov. 9, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

Le 09/11/2015 17:38, Mariano Martinez Peck a Ã©crit : > Thierry, I have a last question. My last requirement will basically be > to find ANY node that would match the regex *oldSelector* and rename it > to *newSelector* being that.. a literal string, a literal symbol, a > message send, a tempVar name, a comment, etc... I guess there is a > simpler way that defining rewrite for each type of node right? > I can always do a "(methodSource substrings detect: [:each | each > matches: '*oldSelector'] ifNone: [#()] ) each2: [:each2 | copReplace. > .... ] I think that if it is really everywhere, then it may works better to just do text replace (methodSource copyReplaceAll: 'oldSelector' with: 'newSelector'). But remember that it will touch everything (pragmas, varNames, comments, etc.) > but RB is probably better. It gives you more control to what you will change. But then you will have to write rewrites for all types of nodes (around 6 or 7?). > Any clues in this last requirement? Well, one thing which may be interesting would be to consider encapsulating the rewrites in refactoring commands, and bring them as a composite change, so that you could launch a rewrite, recover all those method changes, apply (execute) them, check the result with the possibility of undoing them. But I'm not familiar with that part of RB. I do consider it could become significant with EPICEA. It has been a long term project to have AltBrowser make all coding actions as refactoring commands so that EPICEA could log them properly, but its only partly there (and has been for years now)... and EPICEA is not yet here as well (but could be soon). Thierry

Nov. 9, 2015

Re: [Pharo-dev] How to integrate change on class Point

by Marcus Denker

I think it would be enough to do it when the shape of the class changes (adding/removing variables). Marcus > On 09 Nov 2015, at 12:07, stepharo <stepharo(a)free.fr> wrote: > > so when does it report it? When we redefine a method? > > > Le 9/11/15 12:05, Marcus Denker a Ã©crit : >>> On 08 Nov 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: >>> >>> There is a trick >>> Tx henrik >>> DangerousClassNotifier disable :) >>> >> Yes, but we should actually fix the class builder to not raise the error when just changing a commentâ¦ >> but then, this happens not often so I did not yet even report an issue for it. >> >> Marcus >> > >

Nov. 9, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Mariano Martinez Peck

Thierry, I have a last question. My last requirement will basically be to find ANY node that would match the regex *oldSelector* and rename it to *newSelector* being that.. a literal string, a literal symbol, a message send, a tempVar name, a comment, etc... I guess there is a simpler way that defining rewrite for each type of node right? I can always do a "(methodSource substrings detect: [:each | each matches: '*oldSelector'] ifNone: [#()] ) each2: [:each2 | copReplace. .... ] but RB is probably better. Any clues in this last requirement? On Mon, Nov 9, 2015 at 11:01 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-11-09 14:45 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >>> >>> Pharo 4.0 as well. I made a mistake in my example :(, so I'm adding more >>> test cases to check ;). >>> >>> | tree | >>> RBParseTreeRewriter new >>> replace: '``@object `oldSelector `{:node | node selector asString >>> matchesRegex: ''.*oldSelector.*''}' >>> with: '`{RBMessageNode receiver: ``@object selector: (`oldSelector >>> copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: >>> #()}'; >>> executeTree: >>> (tree := RBParser >>> parseMethod: >>> 'DoIt ^ [:proxy | >>> proxy at: #oldSelector. >>> proxy preoldSelector. >>> self preoldSelector oldSelectorPost. >>> proxy preoldSelector: proxy. >>> proxy oldSelectorAnotherMethod. >>> proxy do: ''oldSelectorAndSomething''. >>> "a comment with #oldSelector " >>> ]'). >>> tree newSource. >>> >>> >> >> Thanks, that worked much better! >> >> Here you have a much larger example/test: >> >> | rewriter tree oldSeletor newSelector | >> "closure method sourceCode" >> tree := RBParser parseMethod: 'DoIt ^ [:proxy | >> | oldSelector oldSelectorsuffix prefixoldSelector prefixoldSelectorSuffix >> | >> oldSelector := 1. >> oldSelectorsuffix := 1. >> prefixoldSelector := 1. >> prefixoldSelectorSuffix := 1. >> proxy at: #oldSelector. >> proxy at: #oldSelectorSuffix. >> proxy at: #prefixoldSelector. >> proxy at: #prefixoldSelectorSuffix. >> proxy oldSelector. >> proxy oldSelectorSuffix. >> proxy prefixoldSelector. >> proxy prefixoldSelectorSuffix. >> proxy do: ''oldSelector''. >> proxy do: ''oldSelectorSuffix''. >> proxy do: ''prefixoldSelector''. >> proxy do: ''prefixoldSelectorSuffix''. >> "a comment with #oldSelector " >> "a comment with #oldSelectorSuffix " >> "a comment with #prefixoldSelector " >> "a comment with #prefixoldSelectorSuffix " >> ]'. >> oldSeletor := #oldSelector. >> newSelector := #newSelector. >> >> rewriter := RBParseTreeRewriter new >> replace: '``@object `oldSelector `{:node | node selector asString >> matchesRegex: ''.*oldSelector.*''}' >> with: '`{RBMessageNode receiver: ``@object selector: (`oldSelector >> copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: >> #()}'. >> >> rewriter executeTree: tree. >> tree newSource >> >> >> I think I only miss the literal ones (for example proxy at: #oldSelector >> and the rest) which previously were catched by " RBParseTreeRewriter >> replaceLiteral: oldSeletor with: newSelector. " >> > > Yes, I didn't focus on this one. Didn't understood why it was there :) > > Something like, for the match: > '`#aLiteral {:node | node value isSymbol and: [node value > matchesRegex: '.*oldSelector.*'] }' > > I think it could be simplified; the #copyReplaceAll: probably works just > all well on all message sends. > > RBParseTreeRewriter new > replace: '``@object `oldSelector' > with: '`{RBMessageNode receiver: ``@object selector: (`oldSelector > copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: > #()}'; > > > >> >> I guess I can apply a similar logic for with the regex. I will see if I >> can came up with that. If you happen to know how ;););) >> >> Yes, I will go to Smalltalks and I will give a talk. So I will ask him if >> there are remaining questions! >> BTW, later on today I will send you an screenshot to show you where you >> helped me :) >> > > Cool! Lucky you. Have fun :) > > Thierry > > >> >> Thanks!!! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2015

[pharo-project/pharo-core] 939106: 50428

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9391069b3916e079f28d63bdbfb0eb44eecd537a https://github.com/pharo-project/pharo-core/commit/9391069b3916e079f28d63bd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-09 (Mon, 09 Nov 2015) Changed paths: M Monticello.package/MCPackageManager.class/class/system changes/managersForCategory_do_.st A Nautilus.package/AbstractNautilusUI.class/instance/accessing/title_.st R Nautilus.package/AbstractNautilusUI.class/instance/protocol/title_.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/defaultClassDescriptor.st M Nautilus.package/AbstractNautilusUI.class/instance/test creation/buildTestClassDefinitionFrom_.st M Nautilus.package/NautilusUI.class/instance/open/open.st M Nautilus.package/PackageTreeNautilusUI.class/instance/source code area/defaultClassDescriptor.st M Nautilus.package/extension/Class/instance/definitionForNautilus.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50427.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50428.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50427.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50428.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/AbstractClassInstaller.class/instance/traits/copyTraitCompositionFrom_to_.st A Slot.package/ClassModificationPropagation.class/instance/private/copyTraitCompositionAndMethods.st A Slot.package/ClassModificationPropagation.class/instance/public/apply.st M Tool-Base.package/AbstractTool.class/class/private/defineClassTemplate.st M Tool-Base.package/AbstractTool.class/class/private/defineTraitTemplate.st M Traits.package/TClass.class/class/instance creation/templateForSubclassOf_category_.st A Traits.package/TClass.class/instance/subclass creation/subclass_instanceVariableNames_classVariableNames_package_.st A Traits.package/TClass.class/instance/subclass creation/subclass_instanceVariableNames_classVariableNames_poolDictionaries_package_.st A Traits.package/TClass.class/instance/subclass creation/subclass_uses_instanceVariableNames_classVariableNames_poolDictionaries_package_.st A Traits.package/Trait.class/class/instance creation/named_uses_package_.st Log Message: ----------- 50428 14109 When removing an ivar from a class, all packages of classes that are subclasses are Dirty https://pharo.fogbugz.com/f/cases/14109 16952 Change class template creation https://pharo.fogbugz.com/f/cases/16952 15542 Monticello marks a package dirty if you install an extension method package with a name starting with the first packages name https://pharo.fogbugz.com/f/cases/15542 http://files.pharo.org/image/50/50428.zip

Nov. 9, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 9, 2015

Re: [Pharo-dev] How to integrate change on class Point

by stepharo

so when does it report it? When we redefine a method? Le 9/11/15 12:05, Marcus Denker a Ã©crit : >> On 08 Nov 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: >> >> There is a trick >> Tx henrik >> DangerousClassNotifier disable :) >> > Yes, but we should actually fix the class builder to not raise the error when just changing a commentâ¦ > but then, this happens not often so I did not yet even report an issue for it. > > Marcus >

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Ben Coman

On Mon, Nov 9, 2015 at 5:06 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Power users use the template directly (saves you one, two, three mouse >> clicks and a few mouse mouvements) > > +1 > > From student/beginner perspective I would argue that it is very valuable for > them to see that creating class is just a regular message send and not some > special syntax/magic. Adding UI would alienate them from this > knowledge/revelation. > There is a lot of empty space around the current template. It could easily fit a field based UI plus the text template next to it. Typing in the UI could dynamically recreate the text template. The template would remain the entity actually executed to create the class to demonstrate to newbies class creation is a regular message send. The UI could categorise the template parts as basic/advanced to scaffold for newbies, and power users can just bypass the UI to edit the template directly. cheers -ben > On Mon, Nov 9, 2015 at 9:47 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> >> On 09 Nov 2015, at 06:50, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> >> Le 09/11/2015 01:33, Yuriy Tymchuk a Ã©crit : >> >> >> On 08 Nov 2015, at 20:14, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Stef, >> >> I don't understand. I have never set a category in a class creation >> template for the last three years. >> >> When I teach using Pharo, I allways tell students to create a >> package, select the package in the browser and add a class there. >> >> Changing #category: for #package: (which is what the fix will be, I >> bet) is useless. >> >> >> Because what written there is not a package, itâs a package + tag. So >> it would make sense to have >> >> â¦ package: âPacakgeNameâ tag: âTagNameâ >> >> >> Trying to make it simpler for new students, I see :( >> >> >> Exactly, because you say: âeach class has in a package and can have a tag, >> and here you can define thatâ. Otherwise you have to explain that category >> is actually a magical thing that splits into a package and a tag by >> following some rules. >> >> >> >> But what Iâd really enjoy is to have a dedicated UI there. Because we >> really use class templates as templates. 90% of a time I just change >> the Superclass, Class and instance variables. >> >> >> As I said. >> >> And 9% more I also add >> a tag to the package. >> >> >> What? You don't do a 'add a tag to a package' operation? You create tags >> by side effect of a new class creation? >> >> >> Of course. >> >> >> (Your numbers don't add up to 100%. What is the one percent left for then? >> ;)) >> >> >> I guess Traits. >> >> >> So why we cannot have a UI with text fields for >> this values? Later it can be fancier e.g. classVariables are hidden >> by default and can be expanded on demand or if the are defined (I >> donât like explaining class vars to people and I donât like them from >> design point of view). Then also superclass field can have >> autocompletion only from the defined classes prioritizing the ones >> from the same package. Instance variables can be converted to slots >> really fast by lookup, etcâ¦ >> >> >> Look, you're making even more complex everytime. But you're welcome to >> try; such a GUI can be added, yes, especially behind the add Class menu item >> instead of reusing the full template. >> >> A wizard for class creation :) >> >> Note that on current Nautilus, if you use add Class in the menu, opening >> the menu will auto-select what is behind the mouse click. And the template >> is prefilled, which makes it a bit more complex to create a new clas on >> Object. >> >> >> Itâs not about creation, itâs about working with classes. >> #compile:classified: is not present in the method template because no one >> will never change it. Similarly Iâve never ever changed the `subclass:` >> keyword, so why should it be editable? Iâve never changed >> `instanceVariableNames:` keyword. Probably the only thing Iâve changed was >> adding `uses:` when working with traits. But again, why do I have to recall >> whether itâs called `uses:` or `using:` and type it between `subclass:` and >> `instanceVariableNames:`? Wy I cannot just press a button âuse traitsâ and a >> field will appear where I have to specify traits. >> >> >> >> I mean, itâs nice that we can subclass by sending a message, but we >> donât develop methods in a template like: >> >> compile: âmethodCodeâ classified: âprotocolNameâ >> >> >> I do. When the browser is broken, it's sometime the only way left :) Or >> editing Smalltalk code directly on github :) >> >> >> Yes, but you are not doing that in Nautilus, and there is probably a >> reason for that. Otherwise we can do an experiment: add #compile:classified: >> to the method editor and see if people like it. >> >> >> So maybe we make use of special UI for classes instead of plain >> code. >> >> >> Note that with smart suggestions, you can have both in the same apparently >> plain code. >> >> >> I didnât get that one :( >> >> >> But think of your usage, and also of the other usage: just beginner, new >> student. >> >> >> I donât know how the student thinks, but Iâd prefer to have 4 input >> fields: >> >> - superclass autocompleted with existing classes >> - class name >> - instance variables that will have visual separation for each var (eg: >> http://xoxco.com/projects/code/tagsinput/example.html) >> - package that will be already entered as it is now (and maybe have some >> inactive style not to distract) >> >> Uko >> >> >> And the last one will show you that our toolset is geared towards the >> power user. And this is not going to change anytime soon, to the contrary. >> >> Thierry >> >> >

Nov. 9, 2015

Re: [Pharo-dev] Woe unto thee who assigns to class-side #name!

by Ben Coman

On Mon, Nov 9, 2015 at 8:59 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-11-09 13:37 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> Thierry Goubier wrote >> > Are you sure it would eliminate the gotcha? Can't you trigger it again >> > with >> > self classname: 1? >> >> By "gotcha" I mean specifically doing something that seems normal that >> unknowningly breaks the system, added by the extra pain in this case that >> you might not find out until much later and not be able to connect the >> cause. >> >> If someone sends #classname:, or even assigns to #classname, they deserve >> a >> broken system ;) >> >> >> Thierry Goubier wrote >> > I like the elegance of AClass name. >> >> Yes it's nice, but IMHO as a tremendous price. This is a constant pain >> point >> for newbies. > > > Come on; just an assert: aString isString in #name: would certainly stop the > student doing any harm. The fix was given as... > > To restore the system: > > class instVarNamed: #name put: #MyClass. So should the assert be isSymbol? or are symbol/string interchangeable in this context? Also, before restoring the system... (Smalltalk at: #MyClass) name --> 1 so do we want to ensure the Smalltalk collection is synchronised? Perhaps this is a slots use case for a First Class Relationship [1] ? [1] https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayou… cheers -ben

Nov. 9, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 9, 2015