- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 618ef8: 60485

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 618ef8b3bdc5576186f37dbbfb5d389406491be3 https://github.com/pharo-project/pharo-core/commit/618ef8b3bdc5576186f37dbb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-05-11 (Thu, 11 May 2017) Changed paths: M ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version822_.st M Epicea.package/EpMonitor.class/instance/announcement handling/behaviorRemoved_.st M Epicea.package/EpMonitor.class/instance/private/subscribeToSystemAnnouncer.st M EpiceaBrowsers.package/EpApplyVisitor.class/instance/visitor/visitClassAddition_.st M EpiceaBrowsers.package/EpApplyVisitor.class/instance/visitor/visitClassModification_.st A EpiceaBrowsers.package/EpLostChangesDetector.class/class/instance creation/new.st A EpiceaBrowsers.package/EpLostChangesDetector.class/class/instance creation/newWithLog_.st M EpiceaBrowsers.package/EpLostChangesDetector.class/class/system startup/startUp_.st M EpiceaBrowsers.package/EpLostChangesDetector.class/definition.st R EpiceaBrowsers.package/EpLostChangesDetector.class/instance/accessing/browserIfLostChanges_.st M EpiceaBrowsers.package/EpLostChangesDetector.class/instance/accessing/lostChanges.st R EpiceaBrowsers.package/EpLostChangesDetector.class/instance/accessing/monitorLog.st R EpiceaBrowsers.package/EpLostChangesDetector.class/instance/accessing/monitorLog_.st M EpiceaBrowsers.package/EpLostChangesDetector.class/instance/accessing/openBrowserIfLostChanges.st A EpiceaBrowsers.package/EpLostChangesDetector.class/instance/initialization/initializeWithLog_.st A EpiceaBrowsers.package/EpLostChangesDetector.class/instance/testing/hasLostChanges.st A EpiceaBrowsersTests.package/EpApplyTest.class/instance/tests/testClassAdditionWithMetaclassInstanceVariablesChanged.st M EpiceaBrowsersTests.package/EpLostChangesDetectorTest.class/instance/tests/testDetectInEmptyLog.st M EpiceaBrowsersTests.package/EpLostChangesDetectorTest.class/instance/tests/testDetectNoChange.st M EpiceaBrowsersTests.package/EpLostChangesDetectorTest.class/instance/tests/testDetectOneChange.st M EpiceaBrowsersTests.package/EpRevertTest.class/instance/tests/testClassRemoval.st M Komitter.package/RemotesManager.class/instance/private/buildRoots.st R Ombu.package/OmBlockFileStore.class/class/as yet unclassified/example.st R Ombu.package/OmBlockFileStore.class/class/as yet unclassified/exampleOriginal.st A Ombu.package/OmCurrentGlobalName.class/README.md A Ombu.package/OmCurrentGlobalName.class/definition.st M Ombu.package/OmDeferrer.class/class/system startup/shutDown_.st A Ombu.package/OmEntryReader.class/class/instance creation/newForStore_.st M Ombu.package/OmEntryReader.class/definition.st A Ombu.package/OmEntryReader.class/instance/accessing/store.st A Ombu.package/OmEntryReader.class/instance/initialization/initializeWithStore_.st R Ombu.package/OmEntryReader.class/instance/reading/entryPositionsOn_do_.st R Ombu.package/OmEntryReader.class/instance/reading/nextEntryFrom_.st A Ombu.package/OmEntryWriter.class/class/instance creation/newForStore_.st M Ombu.package/OmEntryWriter.class/definition.st A Ombu.package/OmEntryWriter.class/instance/accessing/store.st A Ombu.package/OmEntryWriter.class/instance/initialization/initializeWithStore_.st M Ombu.package/OmFileStore.class/instance/private/newEntryReader.st M Ombu.package/OmFileStore.class/instance/private/newEntryWriter.st M Ombu.package/OmFileStore.class/instance/testing/isOutdated.st M Ombu.package/OmReference.class/class/ston persistence/fromSton_.st M Ombu.package/OmReference.class/instance/ston persistence/stonOn_.st M Ombu.package/OmSTONEntryReader.class/instance/reading/nextEntry.st M Ombu.package/OmSTONEntryWriter.class/instance/writing/on_nextEntryPut_.st M Ombu.package/OmSessionStore.class/instance/initialization/initializeWithBaseLocator_.st R Ombu.package/OmSessionStore.class/instance/initialization/subscribeToSnapshotDone.st A Ombu.package/OmStoreFactory.class/class/system startup/shutDown_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60484.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60485.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60484.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60485.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60485 20047 in Versioner (or Komitter), RemotesManager needs to list just remotes https://pharo.fogbugz.com/f/cases/20047 20005 Epicea: Integrate release 8.2.2 https://pharo.fogbugz.com/f/cases/20005 http://files.pharo.org/image/60/60485.zip

May 11, 2017

Re: [Pharo-dev] [Zinc] How do I set the entry limit for ZnMultiValueDictionary?

by Max Leske

Hi Sven, I'm unsure about where to set the dynamic variables. I don't really want to do that in my WAApplication as it's not application logic. I could subclass ZnZincStreamingServerAdaptor... Do you have any suggestions? Cheers, Max > On 11 May 2017, at 13:05, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 11 May 2017, at 11:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Max, >> >> First thank you for the feedback, the discussion so far and your patches. I studied them carefully. >> >> Still, I decided to take another road, implementation wise. >> >> You see, the reason a global setting does not make sense is that there can (and are) multiple Zn clients and servers active in the same image, and each should be independent, not be influenced by configuration changes in others. This is why the use of dynamic variables fits so well. >> >> I refactored the current situation a bit and added the necessary high level hooks. I moved the default to each dynamic variable class itself, removed it from ZnConstants, and added options to both ZnClient and ZnServer. >> >> Please test (code committed in bleedingEdge) and let me know if it works for you (especially then #defaultEncoder part). Maybe we have to iterate more over this to fully support your use case. > > I will. Thanks Sven! > >> >> Regards, >> >> Sven >> >> PS: One resource limit not yet moved under the new scheme is the maximum line length (currently set to 4096). >> >>> On 6 May 2017, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>> On 5 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Max, >>>> >>>>> On 5 May 2017, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm performing a legal request that has more than 4000 parameters. This causes the Zinc server to return 400: Bad Request because ZnMultiValueDictionary is limited to 256 entries by default. >>>>> >>>>> The dictionary has the option to remove the limit or to adjust it with a dynamic variable. Unfortunately, I don't see any way to properly configure this without monkey patching Zinc. Ideally, I'd like to remove the limit (which can't be done through the dynamic variable by the way because when the dynamic variable answers nil, the default will be set to 256). >>>>> >>>>> The first thing that comes to mind is to move this setting to ZnConstants, but then I don't see any way to configure ZnConstants either (ZnConstants is referenced directly by its users). Maybe ZnConstants could be changed to hold a concrete constants class (itself by default). >>>>> >>>>> In any case, I think this setting should be configurable and the configuration should be possible through one single entry point, together with options like #codec. >>>>> >>>>> Thoughts? >>>>> >>>>> Cheers, >>>>> Max >>>> >>>> You are the first one to complain about this limit. >>>> >>>> This one and other resource limits exist to protect the client/server against abuse and attacks. >>> >>> I'm aware of that but have not other way to do this right now. We have mod_security with a higher value configured for that. >>> >>>> >>>> I think what is needed is something like ZnServer>>#withMaximumEntitySizeDo: which uses the server option #maximumEntitySize. Would that work for you, you think ? >>> >>> Yes, it would. I've implemented the change, closely following the semantics of #withMaximumEntitySizeDo:. While I was working on that I discovered another problem I had which I also fixed by dispatching to ZnConstants. The problem being, that I set the codec on the server to GRNullCodec, but ZnPercentEncoder would still always use a ZnUTF8Encoder to decode requests. The result was an error when the server tried to write wide strings onto the stream (usually ZnUTF8Encoder: UTF-8 -> WideString, GRPharoUtf8Codec: WideString -> UTF-8). >>> >>> I've attached the patches. >>> >>> A couple of notes: >>> - #defaultMaximumNumberOfDictionaryEntries and #maximumDictionaryEntries: have the same implementation, which is unnecessary in my opinion but I've copied the code from #maximumEntitySize:. >>> - I'm not sure whether storing the option a second time on ZnServer makes sense, but, again, I stuck to the existing implementation >>> - #withMaximumNumberOfDictionaryEntriesDo: also checks the dynamic variable, which is overkill I think, as ZnConstants does the same thing. Again, I stuck to the existing implementation (which means that ZnConstants is actually thread agnostic and references to dynamic variables should probably all be on ZnConstants) >>> >>> >>> Cheers, >>> Max >>> >>>> >>>> Sven

May 11, 2017

Re: [Pharo-dev] [Zinc] How do I set the entry limit for ZnMultiValueDictionary?

by Max Leske

> On 11 May 2017, at 11:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Max, > > First thank you for the feedback, the discussion so far and your patches. I studied them carefully. > > Still, I decided to take another road, implementation wise. > > You see, the reason a global setting does not make sense is that there can (and are) multiple Zn clients and servers active in the same image, and each should be independent, not be influenced by configuration changes in others. This is why the use of dynamic variables fits so well. > > I refactored the current situation a bit and added the necessary high level hooks. I moved the default to each dynamic variable class itself, removed it from ZnConstants, and added options to both ZnClient and ZnServer. > > Please test (code committed in bleedingEdge) and let me know if it works for you (especially then #defaultEncoder part). Maybe we have to iterate more over this to fully support your use case. I will. Thanks Sven! > > Regards, > > Sven > > PS: One resource limit not yet moved under the new scheme is the maximum line length (currently set to 4096). > >> On 6 May 2017, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 5 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Max, >>> >>>> On 5 May 2017, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I'm performing a legal request that has more than 4000 parameters. This causes the Zinc server to return 400: Bad Request because ZnMultiValueDictionary is limited to 256 entries by default. >>>> >>>> The dictionary has the option to remove the limit or to adjust it with a dynamic variable. Unfortunately, I don't see any way to properly configure this without monkey patching Zinc. Ideally, I'd like to remove the limit (which can't be done through the dynamic variable by the way because when the dynamic variable answers nil, the default will be set to 256). >>>> >>>> The first thing that comes to mind is to move this setting to ZnConstants, but then I don't see any way to configure ZnConstants either (ZnConstants is referenced directly by its users). Maybe ZnConstants could be changed to hold a concrete constants class (itself by default). >>>> >>>> In any case, I think this setting should be configurable and the configuration should be possible through one single entry point, together with options like #codec. >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> Max >>> >>> You are the first one to complain about this limit. >>> >>> This one and other resource limits exist to protect the client/server against abuse and attacks. >> >> I'm aware of that but have not other way to do this right now. We have mod_security with a higher value configured for that. >> >>> >>> I think what is needed is something like ZnServer>>#withMaximumEntitySizeDo: which uses the server option #maximumEntitySize. Would that work for you, you think ? >> >> Yes, it would. I've implemented the change, closely following the semantics of #withMaximumEntitySizeDo:. While I was working on that I discovered another problem I had which I also fixed by dispatching to ZnConstants. The problem being, that I set the codec on the server to GRNullCodec, but ZnPercentEncoder would still always use a ZnUTF8Encoder to decode requests. The result was an error when the server tried to write wide strings onto the stream (usually ZnUTF8Encoder: UTF-8 -> WideString, GRPharoUtf8Codec: WideString -> UTF-8). >> >> I've attached the patches. >> >> A couple of notes: >> - #defaultMaximumNumberOfDictionaryEntries and #maximumDictionaryEntries: have the same implementation, which is unnecessary in my opinion but I've copied the code from #maximumEntitySize:. >> - I'm not sure whether storing the option a second time on ZnServer makes sense, but, again, I stuck to the existing implementation >> - #withMaximumNumberOfDictionaryEntriesDo: also checks the dynamic variable, which is overkill I think, as ZnConstants does the same thing. Again, I stuck to the existing implementation (which means that ZnConstants is actually thread agnostic and references to dynamic variables should probably all be on ZnConstants) >> >> >> Cheers, >> Max >> >>> >>> Sven > >

May 11, 2017

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

by Nicolas Cellier

2017-05-11 11:34 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> 2017-05-10 13:38 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >> >> If it is a plug-in, why does it need VM recompilation? >> > >> > Internal plugins require VM recompilation. Only external plugins do not. >> >> It was more of a semantic question, I'd expect a plug-in to be that, >> pluggable, as you say external plugins are. >> Or what is the "pluggability" of such plugins? >> > > I would say there is 3 levels of pluggability: > 1 non optional internal plugin, pluggable because it can be replaced by > another internal plugin implementing the same API at VM compilation time. > Used for modularity of specific aspects of the VM. > 2 optional internal plugin, pluggable because it can be removed / added / > replaced at VM compilation time. Used to improve performance over external > plugin or to access VM functions not exposed to external plugins. > 3 external plugin, pluggable because it can be removed / added / replaced > after the VM is compiled. Used for all other plugins. > > So they're all pluggable in some way. > > External plugins have to use a well defined API for all interactions with VM. Internal plugins not only could have access to unexposed functions, but can also inline some of these functions as recently introduced by Eliot ( https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/7fa0184ef8c7c8badb…) so the performance might be a criterion of choice. >From a packaging POV, making a plugin external is a source of trouble versus embedded internal plugins. The number of possible combinations can rapidly explode (think of testing). It is essentially for letting user choose: - to not embed the plugin * because he knows he ain't gonna need it, and he wants to limit the memory footprint * or because the plugins expose some security issues - to replace a plugin with an alternative version - to produce his own plugins without bothering to recompile the whole VM (or just update the VM without the need to update the plugin because the major revision of API did not change) >> Disclaimer: I don't know about the VM internals (*), and this is not a >> complain of any sort. I just wonder it is called that way. >> >> Regards! >> >> Esteban A. Maringolo >> >> (*) I did compile a Squeak VM a decade ago (added two primitives) but >> nothing more than that. >> >> >

May 11, 2017

Re: [Pharo-dev] [Zinc] How do I set the entry limit for ZnMultiValueDictionary?

by Sven Van Caekenberghe

Hi Max, First thank you for the feedback, the discussion so far and your patches. I studied them carefully. Still, I decided to take another road, implementation wise. You see, the reason a global setting does not make sense is that there can (and are) multiple Zn clients and servers active in the same image, and each should be independent, not be influenced by configuration changes in others. This is why the use of dynamic variables fits so well. I refactored the current situation a bit and added the necessary high level hooks. I moved the default to each dynamic variable class itself, removed it from ZnConstants, and added options to both ZnClient and ZnServer. Please test (code committed in bleedingEdge) and let me know if it works for you (especially then #defaultEncoder part). Maybe we have to iterate more over this to fully support your use case. Regards, Sven PS: One resource limit not yet moved under the new scheme is the maximum line length (currently set to 4096). > On 6 May 2017, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 5 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Max, >> >>> On 5 May 2017, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I'm performing a legal request that has more than 4000 parameters. This causes the Zinc server to return 400: Bad Request because ZnMultiValueDictionary is limited to 256 entries by default. >>> >>> The dictionary has the option to remove the limit or to adjust it with a dynamic variable. Unfortunately, I don't see any way to properly configure this without monkey patching Zinc. Ideally, I'd like to remove the limit (which can't be done through the dynamic variable by the way because when the dynamic variable answers nil, the default will be set to 256). >>> >>> The first thing that comes to mind is to move this setting to ZnConstants, but then I don't see any way to configure ZnConstants either (ZnConstants is referenced directly by its users). Maybe ZnConstants could be changed to hold a concrete constants class (itself by default). >>> >>> In any case, I think this setting should be configurable and the configuration should be possible through one single entry point, together with options like #codec. >>> >>> Thoughts? >>> >>> Cheers, >>> Max >> >> You are the first one to complain about this limit. >> >> This one and other resource limits exist to protect the client/server against abuse and attacks. > > I'm aware of that but have not other way to do this right now. We have mod_security with a higher value configured for that. > >> >> I think what is needed is something like ZnServer>>#withMaximumEntitySizeDo: which uses the server option #maximumEntitySize. Would that work for you, you think ? > > Yes, it would. I've implemented the change, closely following the semantics of #withMaximumEntitySizeDo:. While I was working on that I discovered another problem I had which I also fixed by dispatching to ZnConstants. The problem being, that I set the codec on the server to GRNullCodec, but ZnPercentEncoder would still always use a ZnUTF8Encoder to decode requests. The result was an error when the server tried to write wide strings onto the stream (usually ZnUTF8Encoder: UTF-8 -> WideString, GRPharoUtf8Codec: WideString -> UTF-8). > > I've attached the patches. > > A couple of notes: > - #defaultMaximumNumberOfDictionaryEntries and #maximumDictionaryEntries: have the same implementation, which is unnecessary in my opinion but I've copied the code from #maximumEntitySize:. > - I'm not sure whether storing the option a second time on ZnServer makes sense, but, again, I stuck to the existing implementation > - #withMaximumNumberOfDictionaryEntriesDo: also checks the dynamic variable, which is overkill I think, as ZnConstants does the same thing. Again, I stuck to the existing implementation (which means that ZnConstants is actually thread agnostic and references to dynamic variables should probably all be on ZnConstants) > > > Cheers, > Max > >> >> Sven

May 11, 2017

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

by ClÃ©ment Bera

On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2017-05-10 13:38 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > > >> If it is a plug-in, why does it need VM recompilation? > > > > Internal plugins require VM recompilation. Only external plugins do not. > > It was more of a semantic question, I'd expect a plug-in to be that, > pluggable, as you say external plugins are. > Or what is the "pluggability" of such plugins? > I would say there is 3 levels of pluggability: 1 non optional internal plugin, pluggable because it can be replaced by another internal plugin implementing the same API at VM compilation time. Used for modularity of specific aspects of the VM. 2 optional internal plugin, pluggable because it can be removed / added / replaced at VM compilation time. Used to improve performance over external plugin or to access VM functions not exposed to external plugins. 3 external plugin, pluggable because it can be removed / added / replaced after the VM is compiled. Used for all other plugins. So they're all pluggable in some way. > Disclaimer: I don't know about the VM internals (*), and this is not a > complain of any sort. I just wonder it is called that way. > > Regards! > > Esteban A. Maringolo > > (*) I did compile a Squeak VM a decade ago (added two primitives) but > nothing more than that. > >

May 11, 2017

Re: [Pharo-dev] 10/05/17 - Advancing in Pharo Code Quality Support - Myroslava Romaniuk

by Cyril Ferlicot D.

Le 10/05/2017 Ã 21:14, Myroslava Romaniuk a Ã©crit : > A. Work done: > > * converted a new rule and updated my git repository > * read chapters 5 and 6 of the 'Pharo by Example' book > * started collaborating with my mentors using a Trello board > > > B. Next steps: > > * continue reading 'Pharo by Example' > * update and convert more rules > * watch more tutorials relating to my project (e.g. matchtool > tutorial, etc) > > > C. Help required: > > * I'm seeing other Pharo members also struggling with the same error > in iceberg (LGit_GIT_ERROR: error authenticating: failed connecting > agent), Ben Coman suggested notifying the pharo-dev community. I > know you're all really busy with the upcoming Pharo 6 release but > since this bug is kind of pertinent to the new release I thought > maybe I should report it on fogbugz? If yes, what priority, whom > should I notify? P.S. for me it's the same error when downloading > both the stable and the latest versions of the Pharo 6 VM. For now > I'm still making do with the 60450 version but would really like to > upgrade to a newer one and can't find the one that wouldn't cause > any errors. I'm on Win 7 (64 bit). Would appreciate some advice or > help with this Hello! I can help for this one :) SSH-agent is not working well on Windows. A workaround is to set the ssh keys before using Iceberg. To do so go to Settings -> Tools -> Software Configuration Management -> Iceberg -> Use custom SSH keys You need to check the box and to give the path of your ssh keys. For example: C:\Users\YourName\.ssh\id_rsa.pub C:\Users\YourName\.ssh\id_rsa If you don't have any SSH key, check here: https://help.github.com/articles/connecting-to-github-with-ssh/ > * also if there's any advice regarding what I should read or look at > that's connected to the work I'm doing on my GSoC project, that > would be great > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 10, 2017

Re: [Pharo-dev] GSoC 2017 Introduction

by Mark Rizun

> Mark: hey cheers, I'll definitely let you know if I have any questions. > For now, is there some documentation / tutorials at hand that I could have > a look at to have a better understanding of the tool? > There are four things that I could think of: 1. Paper that explains the tool in quite straightforward way (find pdf atached). 2. PharoInProgress book chapter <https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Rewr…> - the documentation with examples and some details of the implementation (note, some places may be not up to date). It is written using Pillar, so you have to compile it in order to get the pdf. 3. Blog posts <http://myfuncoding.blogspot.fr/2014/08/rewrite-tool.html?view=sidebar>. 4. There is also a short video tutorial <http://www.screencast.com/t/LCEl0hFl>. When you work on the match-rewrite tool, please let me know if you need any assistance.

May 10, 2017

Re: [Pharo-dev] GSoC 2017 Introduction

by Myroslava Romaniuk

Ben: thanks! Yeah Stef came to my uni to give lectures to Masters students and also a few workshops open for everyone, and I decided to go and see what it was, and I was immediately interested. Plus later Yuriy also came to give a few lectures and we got talking about what I could for Pharo, etc...and well, now I'm here working on this project :) Stef: very grateful that you introduced me to Pharo, and thanks for your suggestions! Re: pre-commit quality feedback --- have a look at the alternative final subproject section in my proposal, there it's explained in more detail. I will only do that if I have extra time though. Mark: hey cheers, I'll definitely let you know if I have any questions. For now, is there some documentation / tutorials at hand that I could have a look at to have a better understanding of the tool? On 10 May 2017 at 23:27, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 10 May 2017, at 22:15, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > I think that we should remove the thiumb up/down because nobody uses them. > > > Damn, I forgot to do thatâ¦ It would be nice to replace it with other > stuff, but yes, it wonât make much sense especially when I stop looking at > that. > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

May 10, 2017

Re: [Pharo-dev] GSoC 2017 Introduction

by Mark Rizun

- match-rewrite tool (combines features of matchtool and rewritetool, improves the process of inspecting, creating, editing and removing rules) YES YES YES. It would be great if you can also agregate the tool of mark Rizun. Hi Myroslava, I would be glad to help in case you have any questions concerning rewrite tool (or anything else). Cheers, Mark

May 10, 2017