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

[pharo-project/pharo-core] 44e865: 50427

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 44e86539965e57dfff6671e65eeb5ff289a8b945 https://github.com/pharo-project/pharo-core/commit/44e86539965e57dfff6671e6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-09 (Mon, 09 Nov 2015) Changed paths: M Kernel.package/ProtoObject.class/instance/debugging/doOnlyOnce_.st M Kernel.package/ProtoObject.class/instance/debugging/rearmOneShot.st A Manifest-Core.package/TheManifestBuilder.class/instance/accessing/browsedEnvironment.st M Manifest-Core.package/TheManifestBuilder.class/instance/adding%2Fremoving/removeRejectClass_.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/dateOf_forSelector_.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/removeAllItem_selector_.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/removeObsoleteFalsePositiveOf_.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/unwrap_.st R Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/declareVariableNode_.st M Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitStorePopIntoTempNode_.st M Reflectivity.package/extension/CompiledMethod/instance/metaLinkOptions.st A Reflectivity.package/extension/RBMethodNode/instance/metaLinkOptions.st A Reflectivity.package/extension/Set/instance/metaLinkOptions.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50426.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50427.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50426.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50427.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showSourceWithConverter_.st M Tool-Base.package/AbstractTool.class/instance/class/compileANewClassFrom_notifying_startingFrom_.st Log Message: ----------- 50427 16958 Fix name analysis RF https://pharo.fogbugz.com/f/cases/16958 16954 Smalltalk globals cleaning in ProtoObject and Tools https://pharo.fogbugz.com/f/cases/16954 16956 DNU from Syntaxhighligher tries to parse method in VersionBrowser https://pharo.fogbugz.com/f/cases/16956 http://files.pharo.org/image/50/50427.zip

Nov. 9, 2015

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

by Thierry Goubier

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 >

Nov. 9, 2015

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

by Mariano Martinez Peck

> > > > 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. " 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 :) Thanks!!! -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2015

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

by Thierry Goubier

2015-11-09 13:58 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Nov 9, 2015 at 6:07 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> 2015-11-09 6:38 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Mariano, >>> >>> Le 09/11/2015 01:13, Mariano Martinez Peck a Ã©crit : >>> >>>> >>>> >>>> On Fri, Nov 6, 2015 at 1:59 PM, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> ... >>> >>>> >>>> Hi Thierry, >>>> >>>> I am trying to achieve a similar case like the one I commented in this >>>> post but I am unable to find the way. >>>> Previously I wanted to replace say the literal #oldSelector to >>>> #newSelector. Now, I need to use regular expressions. I mean, I would >>>> need to find matches of '*oldSelector*' and do the replace with >>>> 'newSelector'. For example, the search may find >>>> '*pre*oldSelector*post*' and I want it to be replaced by >>>> '*pre*newSelector*post'. *And of course, I don't know in advance what >>>> pre and post strings there could be. >>>> >>> >>> What you need to do there is to use a match block after the @selector >>> >>> `{:node | node selector matches: '.*oldSelector.*'} >>> >>> Which would mean that your patterns become: >>> >>> rewriter >>> replace: '``@object `oldSelector {:node | node selector matches: >>> '.*oldSelector.*'}' >>> with: '``@object `newSelector {:node | node selector }'. >>> >> > > OK, thanks for the explanation. > > > >> >>> Wait, not entirely sure. I think you need to add a dictionary in the >>> block to give the with: argument the pre and post string. And I'm not sure >>> about the regular expression above as well. >>> >>> I need to have access to the SmaCC code source, so I'll answer to you a >>> bit later. >> >> >> Ok, here is a first try that make a change pre and post included: >> >> | tree | >> RBParseTreeRewriter new >> replace: '`@object `oldSelector `{:node | node selector asString >> matchesRegex: ''.*oldSelector.*''}' >> with: '`@object newSelector'; >> executeTree: >> (tree := RBParser >> parseMethod: >> 'DoIt ^ [:proxy | >> proxy at: #oldSelector. >> proxy preoldSelector. >> proxy oldSelectorAnotherMethod. >> proxy do: ''oldSelectorAndSomething''. >> "a comment with #oldSelector " >> ]'). >> tree newSource >> >> But it does not replace yet the right selector. >> > > > Yes, this one replaced both #oldSelector and #preoldSelector to > #newSelector right? > > > >> For that, I will recreate a message send: >> >> | tree | >> RBParseTreeRewriter new >> replace: '`object `oldSelector `{:node | node selector asString >> matchesRegex: ''.*oldSelector.*''} `@args' >> with: '`{RBMessageNode receiver: `object selector: (`oldSelector selector >> copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: >> `@args}'; >> executeTree: >> (tree := RBParser >> parseMethod: >> 'DoIt ^ [:proxy | >> proxy at: #oldSelector. >> proxy preoldSelector. >> proxy oldSelectorAnotherMethod. >> proxy do: ''oldSelectorAndSomething''. >> "a comment with #oldSelector " >> ]'). >> tree newSource >> >> > > Thanks Thierry for your efforts. Very much appreciated. > I tried the above but still did not work. I executed the very same example > of yours (I pasted it) but the #newSource was: > > DoIt ^ [:proxy | > proxy at: #oldSelector. > proxy preoldSelector. > proxy oldSelectorAnotherMethod. > proxy do: 'oldSelectorAndSomething'. > "a comment with #oldSelector " > ] > > I am trying in Pharo 4.0. And you? > 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. > >> Now, I haven't tested with arguments on the message. >> > > Yes..that's a different story. But for the time being, I can live without > that :) > I'm trying it, but I end up in a subscriptOutOfBounds: error :( > > >> >> Look how you can use pattern variables inside the blocks :) >> >> This is very cool and extremely powerfull. >> >> > Yes, I saw it. I wasn't aware of that. Super powerful but I think it has > some learning curve to master it, right? > Me too... Time to ask for some help. Thierry > > >> Thierry >> >> >> >> >>> >>> >>> >>>> Also..do you know where can I find some more info about RB? For example, >>>> if I read this: >>>> >>>> rewriter >>>> replace: '``@object ' , oldSeletor >>>> with: '``@object ' , newSelector. >>>> >>>> Where can I read that ``@object means XXX .. ? >>>> >>> >>> There is a first level of explanation in the Pharo for the Enterprise >>> book; but, yes the pattern language is fairly complex. >>> >>> Are you going to Smalltalks? John Brant is there and will give a talk on >>> RB and SmaCC (two talks, I believe). >>> >>> Thierry >>> >>> >>> Thanks in advance! >>>> >>>> >>>> >>>> Or a cascade: a RBParseTreeSearcher which matches blocks; on >>>> each block node you activate a rewriter. >>>> >>>> However, there is an issue in rewriting blocks contents, because >>>> it supposes that the method defining the block is recompiled; >>>> it's significantly harder to make changes to the code of live >>>> blocks (change the bytescode itself? What if the block has >>>> multiples instances?). >>>> >>>> Thierry >>>> >>>> >>>> If not, I think my easiest path is to automatically compile >>>> dummy/temporal classes/methods from the rules, perform the >>>> refactor, then move source from methods to block closures, >>>> and finally remove created classes. >>>> >>>> Any pointer is appreciated. >>>> >>>> best, >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 9, 2015

Re: [Pharo-dev] Code critic very bugged ?

by Dimitris Chloupis

and surprise surprise the problem is still here even though I dont install Ephestos and Smacc so we can exclude that as the reason too, now I am testing getting images and libraries via pharolauncher maybe its command line handles of pharo that causes this. Looks like this bug is here to stay but I will not surrender and will not give up !!!! On Mon, Nov 9, 2015 at 1:55 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2015-11-09 12:39 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Hi, >> >> One thing I see there is a DNU #hasBindingOf: for spec toolsâ¦ I have a >> fix for the that I will >> commit today. >> > > Thanks! > > this one is really annoying. > > Thierry > > >> >> Marcus >> >> On 08 Nov 2015, at 08:57, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> ah I forgot about that one, yes it does here it is >> >> http://pastebin.com/uW4AMphu >> >> On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>> >>>> Hey guys I try to use shortcuts and arrow keys with nautilus and I get >>>> this every time >>>> >>>> MNU : receiver of doSemanticsAnalysis: is nil >>>> >>>> in ASTCache at: aCompiledMethod >>>> >>>> I would paste the full stack but it keeps throwing me MNUs when I try >>>> to do anything with the debugger. Seems like a pretty major bug , am I the >>>> only one experiencing this ? >>>> >>> >>> does the pharodebug.log contain the stack trace? >>> >>> >>> >>>> >>>> I am on macos Yosemite using latest pharo 5 image and stable vm with >>>> >>>> wget -O- get.pharo.org/50+vm | bash >>>> >>>> >>>> >>

Nov. 9, 2015

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

by Mariano Martinez Peck

On Mon, Nov 9, 2015 at 4:07 AM, stepharo <stepharo(a)free.fr> wrote: > mariano did you try the tool developed by mark rizun? > because I always fail to get the expression correct. > I wasn't aware of this tool. I am checking it right now. Unfortunately, the smalltalk hub page has no documentation. So I must search a bit first. > We spent some times trying to document the pattern language but to us it > is not really coherent. > Jean-Christophe was expert in parse tree rewriting and he got lost. > > There is a chapter in PharoInProgress. > > I could not find it. Could you please send me the link? Thanks! > We are prototyping alternatives because we need better tools. > > Stef > > Le 9/11/15 06:38, Thierry Goubier a Ã©crit : > > Hi Mariano, >> >> Le 09/11/2015 01:13, Mariano Martinez Peck a Ã©crit : >> >>> >>> >>> On Fri, Nov 6, 2015 at 1:59 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> ... >> >>> >>> Hi Thierry, >>> >>> I am trying to achieve a similar case like the one I commented in this >>> post but I am unable to find the way. >>> Previously I wanted to replace say the literal #oldSelector to >>> #newSelector. Now, I need to use regular expressions. I mean, I would >>> need to find matches of '*oldSelector*' and do the replace with >>> 'newSelector'. For example, the search may find >>> '*pre*oldSelector*post*' and I want it to be replaced by >>> '*pre*newSelector*post'. *And of course, I don't know in advance what >>> pre and post strings there could be. >>> >> >> What you need to do there is to use a match block after the @selector >> >> `{:node | node selector matches: '.*oldSelector.*'} >> >> Which would mean that your patterns become: >> >> rewriter >> replace: '``@object `oldSelector {:node | node selector matches: >> '.*oldSelector.*'}' >> with: '``@object `newSelector {:node | node selector }'. >> >> Wait, not entirely sure. I think you need to add a dictionary in the >> block to give the with: argument the pre and post string. And I'm not sure >> about the regular expression above as well. >> >> I need to have access to the SmaCC code source, so I'll answer to you a >> bit later. >> >> >>> Also..do you know where can I find some more info about RB? For example, >>> if I read this: >>> >>> rewriter >>> replace: '``@object ' , oldSeletor >>> with: '``@object ' , newSelector. >>> >>> Where can I read that ``@object means XXX .. ? >>> >> >> There is a first level of explanation in the Pharo for the Enterprise >> book; but, yes the pattern language is fairly complex. >> >> Are you going to Smalltalks? John Brant is there and will give a talk on >> RB and SmaCC (two talks, I believe). >> >> Thierry >> >> Thanks in advance! >>> >>> >>> >>> Or a cascade: a RBParseTreeSearcher which matches blocks; on >>> each block node you activate a rewriter. >>> >>> However, there is an issue in rewriting blocks contents, because >>> it supposes that the method defining the block is recompiled; >>> it's significantly harder to make changes to the code of live >>> blocks (change the bytescode itself? What if the block has >>> multiples instances?). >>> >>> Thierry >>> >>> >>> If not, I think my easiest path is to automatically compile >>> dummy/temporal classes/methods from the rules, perform the >>> refactor, then move source from methods to block closures, >>> and finally remove created classes. >>> >>> Any pointer is appreciated. >>> >>> best, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> > > -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Dimitris Chloupis

Well from my side I must say that as a power user, (after 2 years of coding in pharo I no longer consider myself a pharo begineer) I find the class template ugly, very impractical and quite pharo and smalltalk unfriendly. After I release ChronosManager my next tool will be Cyclops a gui tool that will unite workspace , system browser , debugger , inspector and spotter under one GUI front end. Obviously its a long term project but will offer a radically diffirent workflow from the one that pharo currently offers including an alternate to the class templates amongsts many other ideas I currently have . I agree that IDE tools can be used on a need/want to use basis , so it may be better to keep the template as it is since so many people seem to like it and just offer alternative approaches that one can install and unistall on choice easily. There is no one ring to rule them all. Each person thinks and work differently and a great IDE must accommodate such flexibility. On Mon, Nov 9, 2015 at 11:36 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> >> 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. >> > > You'd better explain it that way given how it is implemented now. > > I don't think the package + tags choice improved anything there compared > to package + sets of packages, especially regarding categories (we could > have a one to one relation between category and package, which would be way > simpler to explain). > > And now we need a higher abstraction than packages, the one represented > for now by 'a group of packages loaded by a configuration or a baseline'. > > I'd say 'missed opportunity'. Now, I'd say no to any RPackage redesign, so > we'll have to live with it and repatch the rest of the system (and the > documentation). > > >> >> >> 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. >> > > Then, if you consider what you're asking for, I won't agree with it :) It > clearly shows your IDE is defficient there. > > >> >> >> (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. >> > > Now, why not? As I said, write a wizard behind the addClass. > > Like that, it's out of the way if we don't want to use it :) > > >> >> >> >> 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 :( >> > > Well, take for example: > > SmaCCCodeGenerator subclass: #SmaCCSmalltalkCodeGenerator > instanceVariableNames: 'isExpressions parseTreeCache category splitIndex' > classVariableNames: 'MaxJumpSize' > poolDictionaries: '' > category: 'SmaCC-Development' > > If you right click on parseTreeCache, you can get as menu items: > > [image: Images intÃ©grÃ©es 1] > > Look: intelligent GUI, text template ;) > > >> >> 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) >> > > But you loose the message, as Peter pointed out. > > Mind you, those ideas in a class creation dialog, fine. > > Thierry > > >> >> 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 Thierry Goubier

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. We're talking of classes here, that is well predefined entities with a large API that one should not override... Now, about name in Object... Thierry > > > > ----- > 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 Mariano Martinez Peck

On Mon, Nov 9, 2015 at 6:07 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-11-09 6:38 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Mariano, >> >> Le 09/11/2015 01:13, Mariano Martinez Peck a Ã©crit : >> >>> >>> >>> On Fri, Nov 6, 2015 at 1:59 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> ... >> >>> >>> Hi Thierry, >>> >>> I am trying to achieve a similar case like the one I commented in this >>> post but I am unable to find the way. >>> Previously I wanted to replace say the literal #oldSelector to >>> #newSelector. Now, I need to use regular expressions. I mean, I would >>> need to find matches of '*oldSelector*' and do the replace with >>> 'newSelector'. For example, the search may find >>> '*pre*oldSelector*post*' and I want it to be replaced by >>> '*pre*newSelector*post'. *And of course, I don't know in advance what >>> pre and post strings there could be. >>> >> >> What you need to do there is to use a match block after the @selector >> >> `{:node | node selector matches: '.*oldSelector.*'} >> >> Which would mean that your patterns become: >> >> rewriter >> replace: '``@object `oldSelector {:node | node selector matches: >> '.*oldSelector.*'}' >> with: '``@object `newSelector {:node | node selector }'. >> > OK, thanks for the explanation. > >> Wait, not entirely sure. I think you need to add a dictionary in the >> block to give the with: argument the pre and post string. And I'm not sure >> about the regular expression above as well. >> >> I need to have access to the SmaCC code source, so I'll answer to you a >> bit later. > > > Ok, here is a first try that make a change pre and post included: > > | tree | > RBParseTreeRewriter new > replace: '`@object `oldSelector `{:node | node selector asString > matchesRegex: ''.*oldSelector.*''}' > with: '`@object newSelector'; > executeTree: > (tree := RBParser > parseMethod: > 'DoIt ^ [:proxy | > proxy at: #oldSelector. > proxy preoldSelector. > proxy oldSelectorAnotherMethod. > proxy do: ''oldSelectorAndSomething''. > "a comment with #oldSelector " > ]'). > tree newSource > > But it does not replace yet the right selector. > Yes, this one replaced both #oldSelector and #preoldSelector to #newSelector right? > For that, I will recreate a message send: > > | tree | > RBParseTreeRewriter new > replace: '`object `oldSelector `{:node | node selector asString > matchesRegex: ''.*oldSelector.*''} `@args' > with: '`{RBMessageNode receiver: `object selector: (`oldSelector selector > copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: > `@args}'; > executeTree: > (tree := RBParser > parseMethod: > 'DoIt ^ [:proxy | > proxy at: #oldSelector. > proxy preoldSelector. > proxy oldSelectorAnotherMethod. > proxy do: ''oldSelectorAndSomething''. > "a comment with #oldSelector " > ]'). > tree newSource > > Thanks Thierry for your efforts. Very much appreciated. I tried the above but still did not work. I executed the very same example of yours (I pasted it) but the #newSource was: DoIt ^ [:proxy | proxy at: #oldSelector. proxy preoldSelector. proxy oldSelectorAnotherMethod. proxy do: 'oldSelectorAndSomething'. "a comment with #oldSelector " ] I am trying in Pharo 4.0. And you? > Now, I haven't tested with arguments on the message. > Yes..that's a different story. But for the time being, I can live without that :) > > Look how you can use pattern variables inside the blocks :) > > This is very cool and extremely powerfull. > > Yes, I saw it. I wasn't aware of that. Super powerful but I think it has some learning curve to master it, right? > Thierry > > > > >> >> >> >>> Also..do you know where can I find some more info about RB? For example, >>> if I read this: >>> >>> rewriter >>> replace: '``@object ' , oldSeletor >>> with: '``@object ' , newSelector. >>> >>> Where can I read that ``@object means XXX .. ? >>> >> >> There is a first level of explanation in the Pharo for the Enterprise >> book; but, yes the pattern language is fairly complex. >> >> Are you going to Smalltalks? John Brant is there and will give a talk on >> RB and SmaCC (two talks, I believe). >> >> Thierry >> >> >> Thanks in advance! >>> >>> >>> >>> Or a cascade: a RBParseTreeSearcher which matches blocks; on >>> each block node you activate a rewriter. >>> >>> However, there is an issue in rewriting blocks contents, because >>> it supposes that the method defining the block is recompiled; >>> it's significantly harder to make changes to the code of live >>> blocks (change the bytescode itself? What if the block has >>> multiples instances?). >>> >>> Thierry >>> >>> >>> If not, I think my easiest path is to automatically compile >>> dummy/temporal classes/methods from the rules, perform the >>> refactor, then move source from methods to block closures, >>> and finally remove created classes. >>> >>> Any pointer is appreciated. >>> >>> best, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2015

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

by Marcus Denker

> On 09 Nov 2015, at 09:29, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-11-09 13:05 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > 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. > > Are you sure it would eliminate the gotcha? Can't you trigger it again with self classname: 1? > > I'd feel a bit safer with some defensive programming (an assert: in class>>#name?). And I like the elegance of AClass name. > Yes, I feel the same. We should check for these cases but we should not make the APIs horrible. Marcus

Nov. 9, 2015