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

Re: [Pharo-dev] QualityAssistant v0.4

by Sean P. DeNigris

Uko2 wrote > I am developing a tool called QualityAssistant, which displays current > critics about your code in SystemBrowser, Inspector and Spotter. Holy crap - this tool is /Amazing/! It highlights the offending code and even has a button to fix automatically if possible!!! +1 to integration ----- Cheers, Sean -- View this message in context: http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821143.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by Damien Cassou

Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: > Current approach does not forbid the creation of global notification system and I will work on it, as soon as Iâm done with higher priority tasks, or we can hack something together during ESUG. Your feedback is very important, and while you donât see the requested feature available yet, it has influenced the design decisions taken during the development :) :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Thierry Goubier

Le 22/04/2015 14:47, Andrei Chis a Ã©crit : > > > On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 22/04/2015 10:21, Andrei Chis a Ã©crit : > > > > On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > in fact I just checked and Versioner already does that: > right button > on monticello over a configuration gives you a: âcreate > development/release versionâ. > So only thing we need is to use the tools we already created :) > > > But this only works for releasing simple configurations that do not > depend on other configurations. > This would work for rubric, for example, but not for other > configurations we have in gtools. > > > I believe GTTools is certainly a poster case for trying to make that > process simpler. > > I would really be interested to see how a combination of simpler > configurations, baselines, tags and branches would look. A kind of > hierarchical modeling where you only have configurations at the moment. > > > One *issue* with GTools is that they still go through a lot of changes. > They are far from their final version :). Which is perfectly fine by my book; it just makes it a bit more crucial to get the process right :) > For a stable project (for example Zinc) where bugs/features are less > frequent one only needs to integrate once in a while. > This makes working with configurations very easy: there were no > complaints about this process until GTools. Yes, I agree. > With GTools we need to develop and integrate at a fastest rate. > Still, developing and integrating GTools into pharo just by using slices > and merging commits from Pharo back to the projects' repos would take a > lot of effort. And this is the key of the discussion: we need a way to streamline the process to make it easier (and, if possible, avoid changing anciliary information such as the configuration as stored in another repository). > Right now the problem with configurations is that it takes time from > when a fix is available until it is integrated. Still, until now, with > one exception, we more > or less, sync with pharo quite often. You're the test bench :) > Reducing the number of configurations, offering a one click solution for > releasing a new version, plus a tool that show a diff for a > configuration would make this process quite easy. What I know is this: If you manipulate branches and tags (as in git), what you can do is delegate part/all of the configuration update to your SCM. - Write a configuration which targets a BaselineOf and a tag (say v2.0.*) in your development repository. Do not write any package information in the configuration, write just the package names and dependencies in the BaselineOf. From now on, the Configuration will not change. - In that branch, release regular versions, naming them v2.0.<n>, as often as you like (nobody will bother if you release v2.0.113 :)) - Add as many feature branches you'd like for your internal development, merging into the v2 as you want. - Update the BaselineOf if necessary (adding a new package, changing dependencies). - Ask Pharo to integrate or merge the latest v2.0.<n> (which consist of running the ConfigurationOf: nothing less, nothing more)(*). - Merge back pharo/main stuff if any, packaged as a set of packages (a SLICE, why not: a pull request would be easier, but it is not that different). Until you switch branches and main version, you won't change that configuration again and you will never have to write (or generate) a version with all packages version numbers again. (*) Does anybody knows if we can use Metacello to merge instead of loading? Thierry > Cheers, > Andrei > > > Thierry > > > > Cheers, > Andrei > > > > On 22 Apr 2015, at 08:50, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> > wrote: > > > > and btwâ¦ of course I agree repositories need to be > added, and > configurations kept in image. > > > > cheers, > > Esteban > > > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> > wrote: > >> > >> I disagree with your proposal. > >> It will be a mess, nobody will merge (because there > will be no > point on doing it) and we will not move out from a > monolithic system. > >> What I propose is not an invention, is how big projects > workâ¦ > what you have to take into account is that any project > under the > Pharo umbrella does not have an owner, but a maintainer. > That means > if Alan is on vacation or he does not has the time to do > the new > configuration, anyone can doit. > >> > >> Yes, it can look slow, but that is because you are too > used to > the old workflow, and because right now system is not modular. > >> The method I propose will enhance modularity (while the > older > will, at least, not help), which means with time, changes > will be > applied just in one module and not along the full system > like now. > >> > >> Of course with proper tools this will be faster, but I > very much > prefer people telling me âI need thisâ (thatâs why I did the > integrator app, and modified the monkey to take and validate > configurations), and we do it, that we abandon our pursuit of > modularity because is uncomfortable at the beginning. > >> > >> We can modify also monticello or versioner (better > monticello > because everything will be closer, but using versioner > API) to do a > âsave new versionâ which would be more or less the same as > a slice, > but for a configuration, and it will: > >> > >> - save the packages associated to the configuration > >> - create a new version > >> - save the new configuration > >> > >> this will not be to much work (I think I can have it in > a couple > of days), it will help the process (because eventually > everything > should be managed through configurations (or PPM > configurations), > and it will allow us to keep a process that is better and > validated.. > >> > >> TL;DR: Better enhance the tools than drop the process. > >> > >> Esteban > >> > >>> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr> > <mailto:stepharo@free.fr <mailto:stepharo@free.fr>>> wrote: > >>> > >>> Esteban > >>> I was thinking about the following this night. > >>> > >>> While I understand that we want configuration only it > will slow > us down like hell. > >>> > >>> Example > >>> with guille we wanted to fix a problem (I do not > remember which > one) > >>> we need a change to be done in rubric so we will have to > publish the change in rubric repo > >>> - (find it and add it) so the rubric repo should be > there before > >>> - then one guy of rubric should have a look > >>> - then merge > >>> - then publish an issue with a configuration > >>> - then only then we can work > >>> => result why do we need sync for me and guille to > continue to > work??? > >>> => what if Alain in on vacation? > >>> we stop working? > >>> => Remember: We did Pharo especially because people > in squeak > did not want that we change > >>> packages. > >>> > >>> Alternate process > >>> - we do a fix we publish it in Pharo and yes this touches > Rubric and > >>> - we integrate it in Pharo head > >>> - then the guy from rubric merge in their trunk when > they want. > >>> it should be part of the their process to merge > always > with pharo trunk > >>> - At that point they can report a problem > >>> - then they produce at their speed a new configuration > >>> - then we integrate when ready their change > >>> > >>> > >>> Stef > >>> > >>> > >> > > > > > > > >

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by Yuriy Tymchuk

Thank you Doru. > On 22 Apr 2015, at 15:00, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I only took a brief look, but I think that reaching the no-input-required situation is a major step forward. > > Nice job. Keep it up. > > Cheers, > Doru > > > On Wed, Apr 22, 2015 at 8:58 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi everyone! > > Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter. > > Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects. > > Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code. > > Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues> > > Have a nice week! > Uko > > <critics.jpg> > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by Yuriy Tymchuk

> On 22 Apr 2015, at 14:19, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > kilon alios <kilon.alios(a)gmail.com> writes: > >> you definetly got feedback from me with one feature request you did not >> reply ;) > > same from me: in my opinion, the notifications should not be part of the > code browser because we can also code in the inspector and the debugger. > I think they should appear at the bottom of the Pharo window. I remember this request, Damien. After it Iâve added also information about critics in the inspector and spotter. At the moment I havenât done anything with debugger, but I will definitely look into it. QualityAssitant was showing global notifications at the beginning, but this imposes other kind of problem: how do you deal with many entities that change simultaneously? Another example is when you load package with Monticello, as code is in fact modified, and you are spammed with notifications. This is why I decided to step down and now the main goal of QualityAssistant is to assure that you can ask each entity about itâs quality and receive the critics. Then tools like SystemBrowser, Inspector or Debugger can implement a view section that displays this property of an entity. Current approach does not forbid the creation of global notification system and I will work on it, as soon as Iâm done with higher priority tasks, or we can hack something together during ESUG. Your feedback is very important, and while you donât see the requested feature available yet, it has influenced the design decisions taken during the development :) Cheers. Uko > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by Tudor Girba

Hi, I only took a brief look, but I think that reaching the no-input-required situation is a major step forward. Nice job. Keep it up. Cheers, Doru On Wed, Apr 22, 2015 at 8:58 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone! > > Probably most of you know, that I am developing a tool called > QualityAssistant, which displays current critics about your code in > SystemBrowser, Inspector and Spotter. > > Iâm happy to tell you that there is a new release v0.4 which does not > require you to do any previous setup! Just load it from configuration > browser (pharo 4 & 5) and it will start giving you feedback. More details > can be found here: > https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you > are upgrading from older version, it is recommended to load > QualityAssistant into a fresh image, because multiple announcement and > process changes may cause exceptions in old objects. > > Even if you are an experienced programmer you can find QualityAssistant > useful for instantly spotting typos or making sure that you didnât forget > some details about your code. > > Please give me a feedback about your experience, as I want to make it even > more useful. Either write me an email, or open an entry at: > https://github.com/Uko/QualityAssistant/issues > > Have a nice week! > Uko > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by Fabrizio Perin

2015-04-22 14:52 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > I think that feedback should be as close as possible to the place it > relates to :) > > +1

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by Tudor Girba

I think that feedback should be as close as possible to the place it relates to :) Doru On Wed, Apr 22, 2015 at 2:19 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > kilon alios <kilon.alios(a)gmail.com> writes: > > > you definetly got feedback from me with one feature request you did not > > reply ;) > > same from me: in my opinion, the notifications should not be part of the > code browser because we can also code in the inspector and the debugger. > I think they should appear at the bottom of the Pharo window. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by Yuriy Tymchuk

Iâm terribly sorry Kilon, because I can not recall it, neither can I find it. Can you please tell it again? Uko > On 22 Apr 2015, at 13:29, kilon alios <kilon.alios(a)gmail.com> wrote: > > you definetly got feedback from me with one feature request you did not reply ;) > > > On Wed, Apr 22, 2015 at 2:00 PM Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > I am definitely interested in it. Let me know what I should do for this. > > I havenât got a lot of feedback from users, but I fixed problems reported by my group and Alex Bergel. The remaining reported issues are quite minor and related to how SmallLint works. Changes to SmallLint will arrive later after I figure out what the rules are about and what is the way to improve them. > > Cheers, > Uko > > > >> On 22 Apr 2015, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> > >> this is so good. >> what about integrate it to Pharo? >> >> cheers, >> Esteban >> >>> On 22 Apr 2015, at 08:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Hi everyone! >>> >>> Probably most of you know, that I am developing a tool called QualityAssistant, which displays current critics about your code in SystemBrowser, Inspector and Spotter. >>> >>> Iâm happy to tell you that there is a new release v0.4 which does not require you to do any previous setup! Just load it from configuration browser (pharo 4 & 5) and it will start giving you feedback. More details can be found here: https://github.com/Uko/QualityAssistant#quality-assistant-beta- <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are upgrading from older version, it is recommended to load QualityAssistant into a fresh image, because multiple announcement and process changes may cause exceptions in old objects. >>> >>> Even if you are an experienced programmer you can find QualityAssistant useful for instantly spotting typos or making sure that you didnât forget some details about your code. >>> >>> Please give me a feedback about your experience, as I want to make it even more useful. Either write me an email, or open an entry at: https://github.com/Uko/QualityAssistant/issues <https://github.com/Uko/QualityAssistant/issues> >>> >>> Have a nice week! >>> Uko >>> >>> <critics.jpg> >> > >> _______________________________________________ >> 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 <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Andrei Chis

On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Le 22/04/2015 10:21, Andrei Chis a Ã©crit : > >> >> >> On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> in fact I just checked and Versioner already does that: right button >> on monticello over a configuration gives you a: âcreate >> development/release versionâ. >> So only thing we need is to use the tools we already created :) >> >> >> But this only works for releasing simple configurations that do not >> depend on other configurations. >> This would work for rubric, for example, but not for other >> configurations we have in gtools. >> > > I believe GTTools is certainly a poster case for trying to make that > process simpler. > > I would really be interested to see how a combination of simpler > configurations, baselines, tags and branches would look. A kind of > hierarchical modeling where you only have configurations at the moment. One *issue* with GTools is that they still go through a lot of changes. They are far from their final version :). For a stable project (for example Zinc) where bugs/features are less frequent one only needs to integrate once in a while. This makes working with configurations very easy: there were no complaints about this process until GTools. With GTools we need to develop and integrate at a fastest rate. Still, developing and integrating GTools into pharo just by using slices and merging commits from Pharo back to the projects' repos would take a lot of effort. Right now the problem with configurations is that it takes time from when a fix is available until it is integrated. Still, until now, with one exception, we more or less, sync with pharo quite often. Reducing the number of configurations, offering a one click solution for releasing a new version, plus a tool that show a diff for a configuration would make this process quite easy. Cheers, Andrei > > Thierry > > > >> Cheers, >> Andrei >> >> >> > On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> > >> > and btwâ¦ of course I agree repositories need to be added, and >> configurations kept in image. >> > >> > cheers, >> > Esteban >> > >> >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> >> I disagree with your proposal. >> >> It will be a mess, nobody will merge (because there will be no >> point on doing it) and we will not move out from a monolithic system. >> >> What I propose is not an invention, is how big projects workâ¦ >> what you have to take into account is that any project under the >> Pharo umbrella does not have an owner, but a maintainer. That means >> if Alan is on vacation or he does not has the time to do the new >> configuration, anyone can doit. >> >> >> >> Yes, it can look slow, but that is because you are too used to >> the old workflow, and because right now system is not modular. >> >> The method I propose will enhance modularity (while the older >> will, at least, not help), which means with time, changes will be >> applied just in one module and not along the full system like now. >> >> >> >> Of course with proper tools this will be faster, but I very much >> prefer people telling me âI need thisâ (thatâs why I did the >> integrator app, and modified the monkey to take and validate >> configurations), and we do it, that we abandon our pursuit of >> modularity because is uncomfortable at the beginning. >> >> >> >> We can modify also monticello or versioner (better monticello >> because everything will be closer, but using versioner API) to do a >> âsave new versionâ which would be more or less the same as a slice, >> but for a configuration, and it will: >> >> >> >> - save the packages associated to the configuration >> >> - create a new version >> >> - save the new configuration >> >> >> >> this will not be to much work (I think I can have it in a couple >> of days), it will help the process (because eventually everything >> should be managed through configurations (or PPM configurations), >> and it will allow us to keep a process that is better and validated.. >> >> >> >> TL;DR: Better enhance the tools than drop the process. >> >> >> >> Esteban >> >> >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >>> >> >>> Esteban >> >>> I was thinking about the following this night. >> >>> >> >>> While I understand that we want configuration only it will slow >> us down like hell. >> >>> >> >>> Example >> >>> with guille we wanted to fix a problem (I do not remember which >> one) >> >>> we need a change to be done in rubric so we will have to >> publish the change in rubric repo >> >>> - (find it and add it) so the rubric repo should be there before >> >>> - then one guy of rubric should have a look >> >>> - then merge >> >>> - then publish an issue with a configuration >> >>> - then only then we can work >> >>> => result why do we need sync for me and guille to continue to >> work??? >> >>> => what if Alain in on vacation? >> >>> we stop working? >> >>> => Remember: We did Pharo especially because people in squeak >> did not want that we change >> >>> packages. >> >>> >> >>> Alternate process >> >>> - we do a fix we publish it in Pharo and yes this touches >> Rubric and >> >>> - we integrate it in Pharo head >> >>> - then the guy from rubric merge in their trunk when they want. >> >>> it should be part of the their process to merge always >> with pharo trunk >> >>> - At that point they can report a problem >> >>> - then they produce at their speed a new configuration >> >>> - then we integrate when ready their change >> >>> >> >>> >> >>> Stef >> >>> >> >>> >> >> >> > >> >> >> >> > >

April 22, 2015