June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Privacy sendDiagnosticsAndUsageData should be ternary, not binary

by Andrei Chis

On Wed, Jun 8, 2016 at 9:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 7/6/16 Ã 12:00, Andrei Chis a Ã©crit : > > Hi Peter, > > On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary. >> >> Because right now if I refuse sending the data I will be asked again >> every single time. >> > > Indeed right now, at least in Spotter, the notification is shown every > time it is opened in > a new image, even if the setting was explicitly set. It was done like this > as a reminder, > especially if you have the setting set to true. > > > Andrei for the shortcut reporter we put a number of show. Like that the > user will be reminder a number > of times and the system will get calm. May be you could do the same > In a new image the message to send usage data is shown only once. Indeed we could add a counter but that would have to maintain state between images. > >> So the proper behavior (imho) should be: >> >> ask Privacy for the settingâ¦ if the setting is not defined, then show a >> popup. >> If the setting is defined then respect it and do not show another popup. >> > > The current behaviour with showing the notification in Spotter and > Nautilus should be a temporary one. > Ideally we just need a single uniform way of showing this notification > plus the option to control > and see the data that each tool wants to record at a fined-grained level. > > >> >> Also it would be nice to know what happens with the data. >> > > We store it on a server and use it for various analyses. > > what can you tell us on processor use in Spotter. > Not right at this moment. I'm way to busy with other urgent things. Some older results were discussed here: http://scg.unibe.ch/scgbib?query=Kube15a&display=abstract Just for these result to carry more value we still need more people to send data. Right now few do. Cheers, Andrei > > It is also publicly available: GTEventTool default download. > > >> I mean my projects are open source so "sendSourceCode" shouldn't be an >> issueâ¦ but what you can possibly learn from it? >> Why not just analyze the content of SmalltalkHub/GitHub? >> > > Because if you have the setting enabled it does not always work to map > different actions that with the code that you are working on. > > Cheers, > Andrei > > >> >> Peter >> >> > >

June 9, 2016

Re: [Pharo-dev] Story of one small fix

by Denis Kudriashov

So does we all agree to commit fixes for external packages by slices without new configs? 2016-06-09 9:42 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > 2016-06-08 19:40 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> ***THANKS*** Pavel. >> >> Yes it is the best way to make sure that nobody wants to work at this >> level. We discussed this problem during the last board meeting. This is why >> I proposed the following process. >> >> When the core Pharo developers are in need to change a package they >> should do it without updating the external package configurations. >> >> And the external developers should check and merge the changes from the >> Pharo repo and when they want >> >> release a new configuration that we will integrate. >> > But the problem is that for bootstrap we need updated configurations (or > somenting like it) because we want to load all system correctly from them. > So even for such small changes we need to update them somehow. Moreover, we > want to test incomming slices with bootstrap. That means that for every new > slice we need to create temporary configurations and run bootstrap-load > process on them. > > So it is clear that we need configurations that will be created and > managed automatically and will enable swapping of repositories. We had > already several discussions on this theme and from my point of view we need: > > - own separate repository for every semi-external project. So something > like fork for Pharo. With GIT it will be natural, for the management by MC > it will be only a temporary step. > > - own configuration that will be aware only of Pharo and will be fully > automatically managed > > Pharo developers will provide only slices and will not care about > configuraitons at all. It will mean that maintainers of semi-external > projects will loose part of the controll and will need to care of sync with > own development repository but it is nothing new. Even now Pharo makes own > forks of some projects but it is not so visible. > > >> For me this is clear (for example for the icon: fix) I do not do anything >> if this is with the process you describe because it is insane. >> >> In fact fixing this process is part of the job description for your >> position. >> >> It was >> >> - republishing automatically changes and the configuration >> >> - working on package validation (making sure that the catalog does >> not get full of not working project) >> >> - bootstrap :) >> > > Of course I am aware of it :-) > > -- Pavel > >> >> Stef >> >> Le 8/6/16 Ã 11:05, Pavel Krivanek a Ã©crit : >> >> Hi, >> >> we had in the system circular package dependency between Catalog and >> GTools and we decided to solve it by simple moving of one method from >> one package to other one. However, these two packages are external packages >> managed by configurations. That means that we needed move the method, save >> dirty packages and fix both configurations. >> >> For the catalog we have very simple configuration because it manages only >> one package (and dependency on STON). ConfigurationOfGTInspectorCore was >> more complicated because the repository already included newer development >> version of the modified package so we needed to merge. But because we are >> not the maintainers, we cannot know if the change in this package is not >> requiring changes in other packages provided by the configuration. >> Well, the new configurations were prepared and copied into inbox. We >> needed to create next two issues for updating of the configuration in the >> system. We did it and integrated all together in one update. But that is >> not all... >> ConfigurationOfGTInspectorCore is used by three other configurations ( >> ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and >> ConfgurationOfGTDebugger) that specify number of >> ConfigurationOfGTInspectorCore version. In ideal state you should create >> new versions of the configurations but that means that you need to modify >> configurations of all other configurations that use them. It is simpler >> just modify current configuration and upgrade required version number of >> GTInspectorCore. That means to create three next issues, each for one >> configuration, create new configuration versions (and check and merge the >> newer versions in the home repository if needed), copy them to the inbox, >> wait for the review and hope that during integration the Integrator will >> not create new versions of some packages. If yes, you need to update >> configurations again. >> >> So at the end you have at least six issues because you wanted to change >> package for one method that has still the same content and is placed in the >> same class... And it can be worse. Both of these external projects have >> public access to the repository and are managed the same way (not mixing MC >> with GIT). >> >> As you see, it is crazy and unmaintainable. >> >> It is clear that we need to change the process. We need to discuss it >> deeply and some of the results may touch maintainers of the external >> projects integrated in Pharo but please keep in mind that the current >> system is clearly bad. >> >> Cheers, >> -- Pavel >> >> >> >> >

June 9, 2016

Re: [Pharo-dev] Story of one small fix

by Pavel Krivanek

2016-06-08 19:40 GMT+02:00 stepharo <stepharo(a)free.fr>: > ***THANKS*** Pavel. > > Yes it is the best way to make sure that nobody wants to work at this > level. We discussed this problem during the last board meeting. This is why > I proposed the following process. > > When the core Pharo developers are in need to change a package they should > do it without updating the external package configurations. > > And the external developers should check and merge the changes from the > Pharo repo and when they want > > release a new configuration that we will integrate. > But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them. So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need: - own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step. - own configuration that will be aware only of Pharo and will be fully automatically managed Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible. > For me this is clear (for example for the icon: fix) I do not do anything > if this is with the process you describe because it is insane. > > In fact fixing this process is part of the job description for your > position. > > It was > > - republishing automatically changes and the configuration > > - working on package validation (making sure that the catalog does not > get full of not working project) > > - bootstrap :) > Of course I am aware of it :-) -- Pavel > > Stef > > Le 8/6/16 Ã 11:05, Pavel Krivanek a Ã©crit : > > Hi, > > we had in the system circular package dependency between Catalog and > GTools and we decided to solve it by simple moving of one method from one > package to other one. However, these two packages are external packages > managed by configurations. That means that we needed move the method, save > dirty packages and fix both configurations. > > For the catalog we have very simple configuration because it manages only > one package (and dependency on STON). ConfigurationOfGTInspectorCore was > more complicated because the repository already included newer development > version of the modified package so we needed to merge. But because we are > not the maintainers, we cannot know if the change in this package is not > requiring changes in other packages provided by the configuration. > Well, the new configurations were prepared and copied into inbox. We > needed to create next two issues for updating of the configuration in the > system. We did it and integrated all together in one update. But that is > not all... > ConfigurationOfGTInspectorCore is used by three other configurations ( > ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and > ConfgurationOfGTDebugger) that specify number of > ConfigurationOfGTInspectorCore version. In ideal state you should create > new versions of the configurations but that means that you need to modify > configurations of all other configurations that use them. It is simpler > just modify current configuration and upgrade required version number of > GTInspectorCore. That means to create three next issues, each for one > configuration, create new configuration versions (and check and merge the > newer versions in the home repository if needed), copy them to the inbox, > wait for the review and hope that during integration the Integrator will > not create new versions of some packages. If yes, you need to update > configurations again. > > So at the end you have at least six issues because you wanted to change > package for one method that has still the same content and is placed in the > same class... And it can be worse. Both of these external projects have > public access to the repository and are managed the same way (not mixing MC > with GIT). > > As you see, it is crazy and unmaintainable. > > It is clear that we need to change the process. We need to discuss it > deeply and some of the results may touch maintainers of the external > projects integrated in Pharo but please keep in mind that the current > system is clearly bad. > > Cheers, > -- Pavel > > > >

June 9, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] bb7382: 60072

by Marcus Denker

> On 08 Jun 2016, at 19:46, stepharo <stepharo(a)free.fr> wrote: > > >> 60072 >> 18451 Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo: >> https://pharo.fogbugz.com/f/cases/18451 >> >> > > Is there a rule for such case? > Indeed, there are! RBRuleIfNotEmptyDo RBRuleIfNotNilDo Added in Pharo5, so we can deprecate these methods in Pharo6. (Maybe we can use them as a reason to add the âautomatic rewrite deprecationâ in Pharo6â¦ with the idea that it says âthis is departed, but I can fix it for youâ. At runtime we can do that with 100% correctness.) Marcus

June 9, 2016

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Esteban Lorenzano

yes, this is one of my intentions: MongoTalk and Voyage are very co-dependent tools and needs to be close. for example, we have a new MongoTalk version and Voyage depends on it, but there is no stable configuration so people is having a lot of problems. Of course this is easy fixable, but if they are close we can handle it better. â¦ and the possibility of keeping a branch and going back to trunk when ready is an important plus :) cheers, Esteban > On 09 Jun 2016, at 05:43, Martin Dias <tinchodias(a)gmail.com> wrote: > > Good news, I agree in special to move mongotalk. I will appreciate to have mongotalk in github to commit changes in a fork or branch until the changes are reviewed/stable. > Martin > > El 8/6/2016 6:54, "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> escribiÃ³: > Hi, > > (this mail is intended to Voyage/MongoTalk users and collaborators) > > Iâm spending a couple of days in Cologne, at 2Denker offices and I was talking Norbert about organisation of Voyage and the NoSQL driversâ¦ As a conclusion, we want to propose to move the Voyage and MongoTalk development to github, into a common team where other NoSQL drivers can eventually arrive (Voyage will incorporate other backends that might well be there). > > One reason from this is that I do not consider appropriate to keep Voyage into my repository, because is more a community project than a personal one. I want others to be able to participate more and I think this is the right step (also Dale is porting it to Gemstone soâ¦) > > Using github we can benefit of their tools to improve our process (issue tracker, travis and appveyor, etc.) and we will improve project visibility. > > So, we wanted to create âPharoNoSQL" team, and move all thereâ¦ then we will close sthub projects to avoid confusion and we will handle configurations and baselines same way as Yuriy does with QualityAssistance (so it will be available through catalog as always). > > Opinions? > > Esteban

June 9, 2016

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Esteban Lorenzano

> On 09 Jun 2016, at 08:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > well, I think is the opposite: at this moment all active voyage developers are already using git/github (because voyage is being developed there, just in mine repository)â¦ and it happens they are also the MongoTalk active developers. I must have said: except you ;)

June 9, 2016

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Esteban Lorenzano

Hi, > On 09 Jun 2016, at 00:51, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 08/06/16 11:54, Esteban Lorenzano wrote: >> Using github we can benefit of their tools to improve our process >> (issue tracker, travis and appveyor, etc.) and we will improve >> project visibility. > > I fear that without the in-image tooling, it will be difficult > to actually get other people to contribute at the code level. > I have, and have seen others, struggled to use git-based tooling > for Pharo. well, I think is the opposite: at this moment all active voyage developers are already using git/github (because voyage is being developed there, just in mine repository)â¦ and it happens they are also the MongoTalk active developers. Also, filetree and gitfiletree are becoming more and more popular, at the point most ânewâ projects (specially those made by new people) I know are made with git as storage. And finally, more we move, more we have encourage to improve the tools, complete the missing partsâ¦ Esteban > > Stephan > >

June 9, 2016

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

by Martin Dias

Good news, I agree in special to move mongotalk. I will appreciate to have mongotalk in github to commit changes in a fork or branch until the changes are reviewed/stable. Martin El 8/6/2016 6:54, "Esteban Lorenzano" <estebanlm(a)gmail.com> escribiÃ³: Hi, (this mail is intended to Voyage/MongoTalk users and collaborators) Iâm spending a couple of days in Cologne, at 2Denker offices and I was talking Norbert about organisation of Voyage and the NoSQL driversâ¦ As a conclusion, we want to propose to move the Voyage and MongoTalk development to github, into a common team where other NoSQL drivers can eventually arrive (Voyage will incorporate other backends that might well be there). One reason from this is that I do not consider appropriate to keep Voyage into my repository, because is more a community project than a personal one. I want others to be able to participate more and I think this is the right step (also Dale is porting it to Gemstone soâ¦) Using github we can benefit of their tools to improve our process (issue tracker, travis and appveyor, etc.) and we will improve project visibility. So, we wanted to create âPharoNoSQL" team, and move all thereâ¦ then we will close sthub projects to avoid confusion and we will handle configurations and baselines same way as Yuriy does with QualityAssistance (so it will be available through catalog as always). Opinions? Esteban

June 9, 2016

Re: [Pharo-dev] Story of one small fix

by Stephan Eggermont

On 08/06/16 11:05, Pavel Krivanek wrote: > In ideal state you should create > new versions of the configurations Hi Pavel, please take a look at my earlier contributions on this subject. This is a solved problem. Stephan

June 8, 2016

Re: [Pharo-dev] Story of one small fix

by Dale Henrichs

One of the reasons that Versionner may not have been supporting baselines is that the MetacelloToolBox support for BaselineOf was not up to snuff. A couple of weeks ago I added additional support for updating a BaselineOf[1]. If additional features/support is needed from the MetacelloToolBox level I would be glad to add whatever is needed ... Dale [1] https://github.com/dalehenrich/metacello-work/issues/395 On 06/08/2016 04:57 AM, Sean P. DeNigris wrote: > Andrei Chis wrote >> Did you edited the configurations and their dependencies by hand? Since >> some time I never update them by hand, only use versioner > [Reminder]: Anyone using Git (like me for all my personal projects) can not > use Versionner because it does not handle Baselines. This will become more > and more of a problem. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Story-of-one-small-fix-tp4899815p4899885.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 8, 2016