- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: Still some issue with Bloc :-(

by stepharo

Thanks nicolai. Alain told me that he was breaking his fireplace to build a new one so not much bloc to finish the holidays :) Stef Le 30/8/15 16:09, Nicolai Hess a Ã©crit : > fixed: ready to review > > 16267 > <https://pharo.fogbugz.com/f/cases/16267/Fasttable-isn-t-visible-in-athens-i…>Fasttable > isn't visible in athens (in bloc) > > 2015-08-29 18:54 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > FastTable does not work in Bloc. You have to disable it from the > Settings to work with Nautilus. > > Cheers, > Doru > > On Sat, Aug 29, 2015 at 5:31 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Apparently there is a serious problem with the list and > FTTableContainer. > > I took a Moose 6 and did: > Gofer it > smalltalkhubUser: 'Pharo' project: 'Bloc'; > configurationOf: 'Bloc'; > loadBleedingEdge. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Brick'; > configurationOf: 'Brick'; > loadBleedingEdge. > > I do not see the classes when I select a package. A second try > opens many debuggers :-( > > How the build is done by the way? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

Aug. 30, 2015

Re: [Pharo-dev] [Moose-dev] Re: Still some issue with Bloc :-(

by Nicolai Hess

fixed: ready to review 16267 <https://pharo.fogbugz.com/f/cases/16267/Fasttable-isn-t-visible-in-athens-i…> Fasttable isn't visible in athens (in bloc) 2015-08-29 18:54 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > FastTable does not work in Bloc. You have to disable it from the Settings > to work with Nautilus. > > Cheers, > Doru > > On Sat, Aug 29, 2015 at 5:31 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> Apparently there is a serious problem with the list and FTTableContainer. >> >> I took a Moose 6 and did: >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Bloc'; >> configurationOf: 'Bloc'; >> loadBleedingEdge. >> >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Brick'; >> configurationOf: 'Brick'; >> loadBleedingEdge. >> >> I do not see the classes when I select a package. A second try opens many >> debuggers :-( >> >> How the build is done by the way? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

Aug. 30, 2015

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

by Yuriy Tymchuk

But it can be integrated with Rewrite Tool ;), itâs not so easy for everyone to write down a rewrite rule from scratch. Yes, I think that having transformation applied without re-styling will be a huge improvement. Because now there is an âautofixâ button, but I donât use it myself as it restyles all the method. Uko > On 30 Aug 2015, at 16:02, Mark Rizun <mrizun(a)gmail.com> wrote: > > 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 <mailto:i.uhnak@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 <mailto:marcus.denker@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] 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