- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 2e9b0a: 60170

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 2e9b0a0178db3977e9f8df789d609e509c855977 https://github.com/pharo-project/pharo-core/commit/2e9b0a0178db3977e9f8df78… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-05 (Fri, 05 Aug 2016) Changed paths: A Announcements-Core.package/Announcement.class/instance/initialization/prepareForDelivery.st M Announcements-Core.package/SubscriptionRegistry.class/instance/announcing/deliver_.st M Announcements-Tests-Core.package/AnnouncementMockC.class/definition.st A Announcements-Tests-Core.package/AnnouncementMockC.class/instance/accessing/announcingCounter.st A Announcements-Tests-Core.package/AnnouncementMockC.class/instance/initialization/initialize.st A Announcements-Tests-Core.package/AnnouncementMockC.class/instance/initialization/prepareForDelivery.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testPreparationAnnouncementDelivery.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testPreparationAnnouncementDeliveryWhenNoSubscriptions.st A Collections-Strings.package/Symbol.class/instance/announcements/prepareForDelivery.st A Kernel-Tests.package/DateAndTimeTest.class/instance/tests - offset/testReadFromDefaultOffsetNotSpecified.st A Kernel-Tests.package/DateAndTimeTest.class/instance/tests - offset/testReadFromDefaultOffsetSpecified.st M Kernel.package/DateAndTime.class/class/input/readFrom_.st A Kernel.package/DateAndTime.class/class/input/readFrom_defaultOffset_.st M Kernel.package/DateAndTime.class/class/input/readTimezoneOffsetFrom_.st A Kernel.package/DateAndTime.class/class/input/readTimezoneOffsetFrom_default_.st A Nautilus-Tests.package/MethodWidgetTest.class/README.md A Nautilus-Tests.package/MethodWidgetTest.class/definition.st A Nautilus-Tests.package/MethodWidgetTest.class/instance/mock/foo.st A Nautilus-Tests.package/MethodWidgetTest.class/instance/tests/testElementInCacheShouldBeNotNil.st A Nautilus.package/MethodIsScriptAction.class/instance/order/actionStateToCache.st M NautilusRefactoring.package/ChangesBrowserTest.class/instance/tests/testInitializeWidgets.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60169.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60170.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60169.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60170.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60170 18816 Failing test: ChangesBrowserTest.testInitializeWidgets https://pharo.fogbugz.com/f/cases/18816 18846 <script:> and <script> pragmas do not always work https://pharo.fogbugz.com/f/cases/18846 18782 Add DateAndTime class>>readFrom:defaultOffset: https://pharo.fogbugz.com/f/cases/18782 18870 Delivery preparation hook for announcement https://pharo.fogbugz.com/f/cases/18870 http://files.pharo.org/image/60/60170.zip

Aug. 5, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

by Martin Dias

Hi Stef, good, I take note. I improved filters in the recent releases and will continue improving. Martin On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > Thanks Martin. > > We missed yesterday: show only the latest version of every entities. :) > > > Setf > > > Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : > > On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com> wrote: >>> >>> >>> Log Message: >>> ----------- >>> 60163 >>> 18831 Integrate new Epicea version >>> https://pharo.fogbugz.com/f/cases/18831 >>> >>> ChangeLog for this: >> >> - Case 18813: Implement redo and undo of protocol addition and removal. >> >> - Case 18612: disable drag&drop until TreeModel supports it correctly. >> >> - Case 18384: Redo and undo: show on any selection (not only when all >> selected entries are code changes). >> >> - Enhancement: Improve lost changes detection; show only the events >> actually lost. >> >> - Enhancement: Pass on filters. >> >> - Clean up: Do not show the "absent entry" item anymore since it was not >> useful at all. >> >> - Clean up: Remove unused "commit tags" in log browser. >> >> - Clean up: Remove unused tests. They were good idea, we can re-introduce >> them but working and covering more cases. >> >> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s >> hierarchy. It is more meaningful. >> >> - Workaround: Hide "Open in Sorter" menu action since it is useless until >> Treemodel drag&drop is fixed. >> >> >> >> 18768 Inlined method const could be implemented by metalinks >>> https://pharo.fogbugz.com/f/cases/18768 >>> >>> 18835 Update RBParser-Nodes class comments >>> https://pharo.fogbugz.com/f/cases/18835 >>> >>> http://files.pharo.org/image/60/60163.zip >>> >>> >>> >> >> > >

Aug. 5, 2016

Re: [Pharo-dev] Moving Monkey quality checks to Renraku infrastructure

by Nicolai Hess

2016-08-04 18:39 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > At the moment I am moving Pharo quality tools to Renraku model. This is a > quality model that Iâve been working on and that was used so far by > QualityAssistant. > > At the moment Iâm stuck while trying to do changes in Monkey, as it is > really hard to understand how quality checks are made there. @Guille maybe > you can advise something. > > In the old model Rules were both checking code and storing the entities > that violate them. In Renraku Rules are responsible only for checking, then > for each violation they produce a critique object that is a mapping between > the rule and the entity that violates the rule. Also critiques can provide > plenty of additional information such as suggestion on how to fix the issue. > > At the moment we can skip the critiques altogether, just run the rules and > store the classes and method that violate them. But at the moment I cannot > how Monkey in implemented. I.e. where do the rules come from and what > output should be provided. > > Cheers. > Uko > Hi Uko, as far as I know (from looking at the CICommandLineHandler), the CIValidator collects a set of rules when validating an issue. Look at CIValidator class>>#pharo60 The rules are CISUnitTestsRule and PharoCriticRules pharoIntegrationLintRule harden.

Aug. 4, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

by Sean P. DeNigris

Ben Coman wrote > Thanks for the follow up post of this change log Marcus. +1!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-f57843-60163-tp4909296p49096… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 4, 2016

Moving Monkey quality checks to Renraku infrastructure

by Yuriy Tymchuk

Hi, At the moment I am moving Pharo quality tools to Renraku model. This is a quality model that Iâve been working on and that was used so far by QualityAssistant. At the moment Iâm stuck while trying to do changes in Monkey, as it is really hard to understand how quality checks are made there. @Guille maybe you can advise something. In the old model Rules were both checking code and storing the entities that violate them. In Renraku Rules are responsible only for checking, then for each violation they produce a critique object that is a mapping between the rule and the entity that violates the rule. Also critiques can provide plenty of additional information such as suggestion on how to fix the issue. At the moment we can skip the critiques altogether, just run the rules and store the classes and method that violate them. But at the moment I cannot how Monkey in implemented. I.e. where do the rules come from and what output should be provided. Cheers. Uko

Aug. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 4, 2016

[pharo-project/pharo-core] d4d6aa: 60169

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d4d6aa83744aa941695d19536e355de4d15b5284 https://github.com/pharo-project/pharo-core/commit/d4d6aa83744aa941695d1953… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-04 (Thu, 04 Aug 2016) Changed paths: A Announcements-Core.package/Announcement.class/class/public/-.st A Announcements-Core.package/AnnouncementSet.class/instance/exclusion/-.st A Announcements-Core.package/AnnouncementSetWithExclusions.class/README.md A Announcements-Core.package/AnnouncementSetWithExclusions.class/definition.st A Announcements-Core.package/AnnouncementSetWithExclusions.class/instance/initialization/initialize.st A Announcements-Core.package/AnnouncementSetWithExclusions.class/instance/initialization/initialize_.st A Announcements-Core.package/AnnouncementSetWithExclusions.class/instance/private/addExclusion_.st A Announcements-Core.package/AnnouncementSetWithExclusions.class/instance/testing/handlesAnnouncement_.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeClassWithExclusion.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeSetWithExclusion.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeSetWithExclusionOfMultipleAnnouncements.st A Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeSetWithExclusionOfSetItem.st M Metacello-MC.package/MetacelloPackageSpec.class/instance/gofer/workingCopyNameFor_.st A Morphic-Widgets-Taskbar.package/TaskbarMorph.class/instance/drawing/clipSubmorphs.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60168.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60169.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60168.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60169.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-CriticBrowser.package/CriticBrowser.class/class/instance creation/packagesMenu_.st Log Message: ----------- 60169 18861 TaskbarMorph reports damage outside its own area https://pharo.fogbugz.com/f/cases/18861 18868 Announcements subscription should supports exclusion like exceptions by minus https://pharo.fogbugz.com/f/cases/18868 18867 MetaceloPackageSpec workingCopyNameFor call name which could lead to deprecation warning when current version is array https://pharo.fogbugz.com/f/cases/18867 18865 can not open critics browser on a package from nautilus package pane menu https://pharo.fogbugz.com/f/cases/18865 http://files.pharo.org/image/60/60169.zip

Aug. 4, 2016

Re: [Pharo-dev] [ANN] MatchTool

by stepharo

Le 4/8/16 Ã 14:27, Yuriy Tymchuk a Ã©crit : > I know about all that, and Iâve tried to discuss about some kind of > collaboration, but it didnât work out. this is not a problem :) > > RBPattern nodes are straight-forward. The are just a Smalltalk code > with special nodes. Indeed > The problem about them is that it is not clear what is happening, Yes it killed me often in the past. I would like to have something super simple to be able to write rules. > because you have to create a LintRule which creates one more Rule > which creates an AST node, and then it traverses an AST and changes it > in the same timeâ¦ for me it was a lot of mess. I moved to the lowest > level and introduces a really simple API: > > matchNode := RBPatternParser parseExpression: aMatchString. > matchNode > match: anASTNode > onSuccess: [ :map | âdo something with a mapping" ] > onFailure: [ âdo something in case of failureâ ] good. Gustavo may be interested by your work. > > And you can easily debug this, and other tools can use this, for > example match tool does: > > testAST nodesDo: [ :node | âtry to match nodeâ ] > > so I can look for all possible matches. It is sad that I did not record precisely the problems that anne and JC encountered. Because now I forgot but it basically kills the enrrgy to write a nice chapter on how to use the rules so this is good that your tool is making easier to work with them. > > Iâve heard that Camille and Mark are making something super generic > for matching objects, but my problem is that I need to give people > possibility to make their rules easy, and each time I ask if I can use > something there is still work in progress. Sure my point was not to say not to do it and to use the system of Mark and Camille :) > There is another problem: for now I have no use case for matching > objects, I have a prototype of rules about objects, but sadly itâs out > of my scope. we should let them deliver and we will see. > Then how easy is the syntax? RBPatternCode is the closest you can get > to Smalltalk code, if we give people another syntax they will have to > learn something new and will resist. We will see. May be we can clone your tool and use their matcher. > Finally what infrastructure do we have around it? I always use > rubular.com <http://rubular.com> when I need to work with regex, and > now I will always use MatchTool when I need to work with the pattern > code. We should integrate your tool to the system :) > Is there any support for inspecting the matches from the new framework? I do not think so. > > So in the end Iâm always ready for collaboration and always looking > for collaboration, but at the moment I donât need some super-powerful > matching framework. For me I need something that I can understand and I can use. The problem is that with RB I never could :). I got always frustrated because I forgot a . or @t This is why I asked Mark to work on the rewrite tools using direct manipulation. > I need something easy for people to use, and this is why Iâm > refactoring rules and implementing tools like this. And it seems > easier for me to fix a bug in pattern code matching (especially as it > is easier to debug it) than adopting a new framework. Ok now Anne and JC got frustrated by it. If you can understand it then it is probably the way to go for you. > > Another example. MatchTool should definitely marry RewriteTool, > because after youâve investigated the matches you should be able to > say: "ok, and now I want to transform thisâ, and then you enter > another expression and save a rule. In fact RewriteTool inspired me a > lot. Because it is very useful, but you enter code and it is not > highlighted, so you have no clue if you made a mistake. Or you create > a âmeta variableâ and you want to know what are these `@ things and > you have to google. Or your code is finally matching, but you have no > idea what was matched to what. :) same experience here. So often I was doing everything by hand and frustrated > I really hate when I have no clue what is happening, and this is why > Iâve implemented MatchTool. Yes please. I'm sure that mark would be happy to get his tool more used. > > Cheers. > Uko > > >> On 04 Aug 2016, at 13:45, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> BTW our experience with anne and JC when they tried to document how >> the patterns were working is that there are some situations >> >> that are not clear, and this is why Camille and Mark started to work >> on another solution. >> >> I hope to get to know more soom. >> >> >> Stef >> >> >> Le 4/8/16 Ã 10:23, Yuriy Tymchuk a Ã©crit : >>> Hi everyone! >>> >>> Iâm happy to announce a new tool that can help you to understand to >>> the pattern code is working in match & rewrite rules. >>> You can read more on my blogpost: >>> http://blog.yuriy.tymch.uk/2016/08/matchtool.html >>> The tool is available for Pharo 6 from the catalog. >>> >>> <Mail Attachment.png> >>> >>> Cheers! >>> Uko >> >

Aug. 4, 2016

Re: [Pharo-dev] Stable configuration of PetitParser broken for stable PetitGui in Pharo 5

by Martin McClure

On 08/03/2016 11:14 PM, Tudor Girba wrote: > Hi, > > Thanks for the report. > > PetitParser was not yet released for Pharo 5. It comes in the following days as part of the Moose release. Excellent, thanks for the update. -Martin

Aug. 4, 2016

Re: [Pharo-dev] [ANN] MatchTool

by Yuriy Tymchuk

I know about all that, and Iâve tried to discuss about some kind of collaboration, but it didnât work out. RBPattern nodes are straight-forward. The are just a Smalltalk code with special nodes. The problem about them is that it is not clear what is happening, because you have to create a LintRule which creates one more Rule which creates an AST node, and then it traverses an AST and changes it in the same timeâ¦ for me it was a lot of mess. I moved to the lowest level and introduces a really simple API: matchNode := RBPatternParser parseExpression: aMatchString. matchNode match: anASTNode onSuccess: [ :map | âdo something with a mapping" ] onFailure: [ âdo something in case of failureâ ] And you can easily debug this, and other tools can use this, for example match tool does: testAST nodesDo: [ :node | âtry to match nodeâ ] so I can look for all possible matches. Iâve heard that Camille and Mark are making something super generic for matching objects, but my problem is that I need to give people possibility to make their rules easy, and each time I ask if I can use something there is still work in progress. There is another problem: for now I have no use case for matching objects, I have a prototype of rules about objects, but sadly itâs out of my scope. Then how easy is the syntax? RBPatternCode is the closest you can get to Smalltalk code, if we give people another syntax they will have to learn something new and will resist. Finally what infrastructure do we have around it? I always use rubular.com when I need to work with regex, and now I will always use MatchTool when I need to work with the pattern code. Is there any support for inspecting the matches from the new framework? So in the end Iâm always ready for collaboration and always looking for collaboration, but at the moment I donât need some super-powerful matching framework. I need something easy for people to use, and this is why Iâm refactoring rules and implementing tools like this. And it seems easier for me to fix a bug in pattern code matching (especially as it is easier to debug it) than adopting a new framework. Another example. MatchTool should definitely marry RewriteTool, because after youâve investigated the matches you should be able to say: "ok, and now I want to transform thisâ, and then you enter another expression and save a rule. In fact RewriteTool inspired me a lot. Because it is very useful, but you enter code and it is not highlighted, so you have no clue if you made a mistake. Or you create a âmeta variableâ and you want to know what are these `@ things and you have to google. Or your code is finally matching, but you have no idea what was matched to what. I really hate when I have no clue what is happening, and this is why Iâve implemented MatchTool. Cheers. Uko > On 04 Aug 2016, at 13:45, stepharo <stepharo(a)free.fr> wrote: > > BTW our experience with anne and JC when they tried to document how the patterns were working is that there are some situations > > that are not clear, and this is why Camille and Mark started to work on another solution. > I hope to get to know more soom. > > Stef > > Le 4/8/16 Ã 10:23, Yuriy Tymchuk a Ã©crit : >> Hi everyone! >> >> Iâm happy to announce a new tool that can help you to understand to the pattern code is working in match & rewrite rules. >> You can read more on my blogpost: http://blog.yuriy.tymch.uk/2016/08/matchtool.html <http://blog.yuriy.tymch.uk/2016/08/matchtool.html> >> The tool is available for Pharo 6 from the catalog. >> >> <Mail Attachment.png> >> >> Cheers! >> Uko >

Aug. 4, 2016