- Pharo-dev - lists.pharo.org

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

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

by Andrei Chis

In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). This allows for very simple configurations with clear dependencies. Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity. Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. I would still like to have different configurations for Glamour and Rubric as they are separate projects. So we can have just three configurations (each one for a separate project that can be released independent of the others): ConfigurationOfGToolkitCore ----> ConfigurationOfGlamourCore ---------> ConfigurationOfRubric This would make releasing a new version easier with the current support from versioner. Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case. Cheers, Andrei On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > exactly. > what we need in the long term is a complete better integration process. > I dream to have a git pharo project with submodules and pull requests. > > Slowly the tools are coming, but this will take time to implement. > In the mean time, we need to do all the steps we can to allow us to > achieve the modularisation goal. > Even if they look not easy because we are still building it, or too used > to previous ways of doing it. > > Esteban > > > On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > And do not forget that with better Pharo modularization it will start > > to be a problem on more lower level. When eg. Morphic will be an > > "exteranal" Pharo package. > > > > -- Pavel > > > > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > >> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> > >> 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. > >> > >> > >> then you have two options: > >> > >> 1) you rewrite your configurations to not need nested configurations. > This > >> is not recommendable in huge projects like Seaside, but things like > GTools > >> are easily (I did a quick check and your 3 configurations have in total > 7 > >> packagesâ¦ would not be a problem to have them without nesting projects > and > >> just using the packages). In fact, this is how Dale recommends using > >> configurations (if I understood him right). > >> 2) we enhance the tools to also allow the commit of nested packages. > >> > >> I think both approaches needs to be done: you donât need unnecessary > >> complexity in your configurations and we need to add some nesting > support to > >> commit new version. > >> > >> What is not admisible, IMO, is to do something that is wrong just > because it > >> looks easier in the short term (and I say âin short termâ because what > looks > >> easier now will generate a lot of problems in the future). > >> > >> cheers, > >> Esteban > > > > >

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by Damien Cassou

Sean P. DeNigris <sean(a)clipperadams.com> writes: > Damien Cassou-2 wrote >> what I don't like about WYSIWYG word processors is that they hide the >> content. I want to control my content. I want to immediately see if a >> line is a section title (semantically) or if it's just bold and huge. I >> want to immediately see if a section title is automatically numbered or >> if the number was written manually. >> ... >>> And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the >>> sense >>> that, users have to indicate *semantic* intentions like emphasis by >>> selecting different fonts, versus something like HTML 4/5, where the >>> actual >>> intention is declared (EMPH tags, QUOTE tags, etc). >> I agree that this is a very important point. > > These are very valid critiques of current non-OOP, pink plane approaches, > but in fact there is no inherent conflict between WYSIWYG and e.g. Pillar. > If we start from our intentions, either from the list I started or your own, > it's easy to see how to have it all. Yes, in a rich text editor, one doesn't > know if it's just "bold and big" or a section title. But we are not talking > about jerry rigging a generic editor such as Word to do something for which > it was never intended. We could, as a start, and an easy bridge between the > two POVs, create a Pillar WYSIWYG editor, where the only options are > semantic. So the menu choice/button/whatever would be all domain related, so > when you saw "big and bold", you would be confident that it was just a > visual cue for a section title, which is important because visual thinking > is an important process - and separate from the intellectual processing of > syntax. Making a richer interface does not have to mean giving anything up. ok for me. -- 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] [Moose-dev] QualityAssistant v0.4

by Damien Cassou

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

April 22, 2015

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

by kilon alios

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> 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> 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> 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 > > <critics.jpg> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >

April 22, 2015

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

by Yuriy Tymchuk

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> 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 > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

April 22, 2015