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

Re: [Pharo-dev] PetitParser speed and cost of PPFailure

by Holger Freyther

> On 17 Aug 2015, at 13:03, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > Dear Jan, > As the compiler is not production ready and as we are looking for a use cases, I can import your grammar and let you know how to make it working with our tool and what would be the performance gain. In that case, I would need some test cases and benchmark inputs from you. sorry for the delay. The parser/tests are contained in the OsmoSIP code and there is a metacello configuration[1] as well. The code does load in a Pharo3.0 image (and it should work in Pharo4.0 as well). As for benchmarks the closes would be to parse specific messages. E.g. three of them of the SIPParserTest, >>#authorizationData, >>#resultUnauthorized >>#statusResponseData class >>#exampleYateBye Not a good test corpus (1 request, three responses) but it should give you a ballpark figure if things go more quick. You might want to undo my hack I did in commit #18 [2]. kind regards holger [1] http://smalltalkhub.com/#!/~osmocom/SIP/source [2] http://smalltalkhub.com/#!/~osmocom/SIP/diff/OsmoSIP-HolgerHansPeterFreythe…

Aug. 30, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Mark Rizun

As far as I'm concerned, it's not based on my tool. 30 ÑÐµÑÐ¿. 2015 3:34 Ð¿Ð¿ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> Ð¿Ð¸ÑÐµ: > Is this based on Mark's Rewrite Tool? > > On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> Small experiment: >> >> 1) add this method to Object: >> >> deprecated: anExplanationString rule: aRule >> | builder ast rewriteRule method | >> builder := RBCompositeRefactoryChange named: 'deprecation'. >> method := thisContext sender sender method. >> ast := method ast copy. >> rewriteRule := RBParseTreeRewriter new replace: aRule key with: >> aRule value. >> >> (rewriteRule executeTree: ast) ifTrue: [ >> builder compile: rewriteRule tree formattedCode in: method >> methodClass classified: method protocol ]. >> builder execute. >> >> 2) to see it in action, add it to #ifNotNilDo: in UndefinedObject: >> >> ifNotNilDo: aBlock >> "Please use #ifNotNil: instead" >> self >> deprecated: 'Please use #ifNotNil: instead' >> rule: '`@receiver ifNotNilDo: `@statements'-> >> '`@receiver ifNotNil: `@statements'. >> ^ self >> >> >> â> open a browser and see how it fixes code magically. >> >> The only problem is that it does a whole-method refactoring while it >> should only affect the node >> that triggered the deprecation. Else there could be wrong transformations >> if the same selector >> is used but only one of the implementations need to be rewritten, while >> if we are able to rewrite >> the exact sender, we can do it fully automatically. >> >> Marcus >> > >

Aug. 30, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by Yuriy Tymchuk

Yes, but the situation is weird, because if you look at the variable in the debugger - everything is ok. Is there a way to understand what has not mutated? Uko > On 30 Aug 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: > > may be code executing the check did not get mutated when the system changed shape. > > Le 30/8/15 11:00, Marcus Denker a Ã©crit : >>> On 30 Aug 2015, at 10:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> So the byte symbol comes from the âpositionâ inst var of the superclass. Iâm not completely sure how it works on low level, but I guess that because you a a new variable, the others shift and it accesses the value that is actually mapped to another variable. Is it the issue of my implementation? How can I improve it? >>> >> The class builder is normally supposed to fix that transparently: You add var, all methods are recompiled and all instances are migrated. There could be bugs there. >> >>> Uko >>> >>>> On 28 Aug 2015, at 10:50, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> When I add an iv to Model I get a ByteSymbol>>entity: >>>> >>>> QANautilusPluggin>>initialize >>>> >>>> changeHandler := GLMAsyncTask new >>>> priority: Processor activePriority - 1; >>>> doInBackground: [ morph entity: self currentEntity ]; >>>> yourself >>>> >>>> And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) >>>> >>>> Yuriy do you use thread? >>>> >>>> Stef >>>> >>>> >>>> >>> >> >> > >

Aug. 30, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Peter UhnÃ¡k

Is this based on Mark's Rewrite Tool? On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Small experiment: > > 1) add this method to Object: > > deprecated: anExplanationString rule: aRule > | builder ast rewriteRule method | > builder := RBCompositeRefactoryChange named: 'deprecation'. > method := thisContext sender sender method. > ast := method ast copy. > rewriteRule := RBParseTreeRewriter new replace: aRule key with: > aRule value. > > (rewriteRule executeTree: ast) ifTrue: [ > builder compile: rewriteRule tree formattedCode in: method > methodClass classified: method protocol ]. > builder execute. > > 2) to see it in action, add it to #ifNotNilDo: in UndefinedObject: > > ifNotNilDo: aBlock > "Please use #ifNotNil: instead" > self > deprecated: 'Please use #ifNotNil: instead' > rule: '`@receiver ifNotNilDo: `@statements'-> '`@receiver > ifNotNil: `@statements'. > ^ self > > > â> open a browser and see how it fixes code magically. > > The only problem is that it does a whole-method refactoring while it > should only affect the node > that triggered the deprecation. Else there could be wrong transformations > if the same selector > is used but only one of the implementations need to be rewritten, while if > we are able to rewrite > the exact sender, we can do it fully automatically. > > Marcus >

Aug. 30, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by stepharo

may be code executing the check did not get mutated when the system changed shape. Le 30/8/15 11:00, Marcus Denker a Ã©crit : >> On 30 Aug 2015, at 10:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> So the byte symbol comes from the âpositionâ inst var of the superclass. Iâm not completely sure how it works on low level, but I guess that because you a a new variable, the others shift and it accesses the value that is actually mapped to another variable. Is it the issue of my implementation? How can I improve it? >> > The class builder is normally supposed to fix that transparently: You add var, all methods are recompiled and all instances are migrated. There could be bugs there. > >> Uko >> >>> On 28 Aug 2015, at 10:50, stepharo <stepharo(a)free.fr> wrote: >>> >>> When I add an iv to Model I get a ByteSymbol>>entity: >>> >>> QANautilusPluggin>>initialize >>> >>> changeHandler := GLMAsyncTask new >>> priority: Processor activePriority - 1; >>> doInBackground: [ morph entity: self currentEntity ]; >>> yourself >>> >>> And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) >>> >>> Yuriy do you use thread? >>> >>> Stef >>> >>> >>> >> > >

Aug. 30, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by stepharo

I just added an instance variable to Model. Le 28/8/15 11:34, Yuriy Tymchuk a Ã©crit : > Wow, this is weird. > > Yes, GLMAsyncTask spawns a process. I use it not to block the ui in nautilus while critics are retrieved. So when you switch to a new method it changes pluginâs critic list to âloading progress morphâ and runs the task with a lower priority. If in ui you go through methods, it simply reschedules the task to check different critics. When you stop working with UI it calculates the critics and shows them to you. > > For me its weird that you get DNU for symbol while `morph` should be a QANautilusPluginMorph. Did I do something very evil not knowing about all the concurrent/morphic black magic? > > Uko > >> On 28 Aug 2015, at 10:50, stepharo <stepharo(a)free.fr> wrote: >> >> When I add an iv to Model I get a ByteSymbol>>entity: >> >> QANautilusPluggin>>initialize >> >> changeHandler := GLMAsyncTask new >> priority: Processor activePriority - 1; >> doInBackground: [ morph entity: self currentEntity ]; >> yourself >> >> And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) >> >> Yuriy do you use thread? >> >> Stef >> >> >> > >

Aug. 30, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by Marcus Denker

> On 30 Aug 2015, at 10:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > So the byte symbol comes from the âpositionâ inst var of the superclass. Iâm not completely sure how it works on low level, but I guess that because you a a new variable, the others shift and it accesses the value that is actually mapped to another variable. Is it the issue of my implementation? How can I improve it? > The class builder is normally supposed to fix that transparently: You add var, all methods are recompiled and all instances are migrated. There could be bugs there. > Uko > >> On 28 Aug 2015, at 10:50, stepharo <stepharo(a)free.fr> wrote: >> >> When I add an iv to Model I get a ByteSymbol>>entity: >> >> QANautilusPluggin>>initialize >> >> changeHandler := GLMAsyncTask new >> priority: Processor activePriority - 1; >> doInBackground: [ morph entity: self currentEntity ]; >> yourself >> >> And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) >> >> Yuriy do you use thread? >> >> Stef >> >> >> > >

Aug. 30, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by Yuriy Tymchuk

So the byte symbol comes from the âpositionâ inst var of the superclass. Iâm not completely sure how it works on low level, but I guess that because you a a new variable, the others shift and it accesses the value that is actually mapped to another variable. Is it the issue of my implementation? How can I improve it? Uko > On 28 Aug 2015, at 10:50, stepharo <stepharo(a)free.fr> wrote: > > When I add an iv to Model I get a ByteSymbol>>entity: > > QANautilusPluggin>>initialize > > changeHandler := GLMAsyncTask new > priority: Processor activePriority - 1; > doInBackground: [ morph entity: self currentEntity ]; > yourself > > And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) > > Yuriy do you use thread? > > Stef > > >

Aug. 30, 2015

Re: [Pharo-dev] Nautilus and Work group

by stepharo

Le 25/8/15 08:52, Torsten Bergmann a Ã©crit : > Nautilus in Pharo 5 now includes per default a group "Configuration" > and "Work". I would like to slowly rename it "Project" > > But one has to manually put new work into the "Work" group. If you load the configuration via the catalog browser and use the correct action the group is created for you. This is the same if you use the message loadAndCreateGroupInNautilus when loading a configuration Somebody should create a commandline handler > Would it > make sense to put newly created packages automagically into this > group as typically one is working on them? > > > > >

Aug. 30, 2015

[Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

Hi, Small experiment: 1) add this method to Object: deprecated: anExplanationString rule: aRule | builder ast rewriteRule method | builder := RBCompositeRefactoryChange named: 'deprecation'. method := thisContext sender sender method. ast := method ast copy. rewriteRule := RBParseTreeRewriter new replace: aRule key with: aRule value. (rewriteRule executeTree: ast) ifTrue: [ builder compile: rewriteRule tree formattedCode in: method methodClass classified: method protocol ]. builder execute. 2) to see it in action, add it to #ifNotNilDo: in UndefinedObject: ifNotNilDo: aBlock "Please use #ifNotNil: instead" self deprecated: 'Please use #ifNotNil: instead' rule: '`@receiver ifNotNilDo: `@statements'-> '`@receiver ifNotNil: `@statements'. ^ self â> open a browser and see how it fixes code magically. The only problem is that it does a whole-method refactoring while it should only affect the node that triggered the deprecation. Else there could be wrong transformations if the same selector is used but only one of the implementations need to be rewritten, while if we are able to rewrite the exact sender, we can do it fully automatically. Marcus

Aug. 30, 2015