- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] QualityAssistant v0.4

by Cyril Ferlicot

Good job ! :D Really usefull On 22 April 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> > > -- Cheers Cyril Ferlicot

April 22, 2015

Re: [Pharo-dev] TDD and BDD

by Sean P. DeNigris

Miguel Moquillon wrote >> In summary, the intent of BDD is to be "TDD Done Right". > I don't agreed with your assumption: there is a difference > philosophically both in theory and in practice. In actuality, it is a bit overstated, because one key insight of BDD was to bring /all/ stakeholders into TDD. "In order that... as a... I want..." was intended as a way to have the customer write a spec that would become an executable part of the test framework. But, they're also not as totally independent as you describe. In fact, Dan North, the inventor of BDD has explained it such - that BDD = TDD if your whole team are programmers, but BDD includes: TDD if the stakeholders include non-programmers. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-and-BDD-tp4820612p4821109.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by Sean P. DeNigris

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. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Improving-the-documentation-model-tp4820814p4821107.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by Esteban Lorenzano

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- <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>

April 22, 2015

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

by Esteban Lorenzano

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] Integration process in presence of "external" project

by Pavel Krivanek

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] Integration process in presence of "external" project

by Esteban Lorenzano

> 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] Integration process in presence of "external" project

by Guillermo Polito

Well, I agree with Esteban and Thierry in the fact that making our lives easier to manage now by pushing changes into the Pharo/main branch will make things harder in the long run. I think we can see this as a case of two dependent configurations ConfigurationOfPharo (which does not exist but as the ad-hoc list of packages in Pharo/main) ConfigurationOfRubric => depends on ConfigurationOfPharo Stef, I'd manage it like this: - push the change we have into rubric - open an issue number X asking for the integration of rubric with that feature - open an issue Y that depends on X with the other slice of changes And here the main problem that we will have is that if we do not integrate quickly these fixes, then slices can age and become not valid. Alternatively, we can do it in several steps, avoiding the dependency: - push the change into rubric - push the part of the change into pharo that does not break the current version of rubric (avoid the renames/removals of methods) - when both are integrated we do the last step that integrates the last set of changes El miÃ©., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier < thierry.goubier(a)gmail.com> escribiÃ³: > 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. > > 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 Thierry Goubier

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. 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 Thierry Goubier

Le 22/04/2015 10:26, Andrei Chis a Ã©crit : > > > On Wed, Apr 22, 2015 at 7:47 AM, 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 > > > This kind of process will be a pain for those that have to merge the > changes back to their repos. > I did this for a while when I was synching the debugger repo with Pharo > and even if I only had to merge maybe one slice a day it was kind of > annoying. The thing is, if you are not doing it, you're asking someone else to do it for you. So, some of the possibilities are: - Decouple a bit upstream from Pharo/main, not merging everything from there immediately. Wait to see the fixes and changes to stabilize, then extract and merge. - Wait for Pharo/main to pushes fixes to you upstream. So that Pharo/main has a duty of collecting the changes, making them all in a nice pack, and send them your way. A good thing is to adjust the process so that pushing things back and forth is easing the task of everybody involved (motivation!). For example, if an hypothetical Stef (not the true one :)) is changing and fixing things in Rubric inside Pharo/main, it will make merging Rubric newest version harder. So, a good thing would be to make that hypothetical Stef in charge of merging the new Rubric version as well. If he finds it a pain, then he will ease his tasks by sending his fixes nicely packaged to the Rubric maintainer, so that the Rubric manager can merge that with the newest version and send it back to Pharo/main for integration by our hypothetical Stef :) However, it would be allways possible for an external project to make it easier to fix in their project directly than in Pharo/main, but for that they need to be very reactive (make sure that fixes are propagated back very fast in Pharo/main) and make the process as easy as possible for an external contributor... Note that, in such a process, having good tools count. This is one of the reasons for using places like bitbucket or github: they do really support that kind of process (pull requests, branches, issues, server-based merge and CI check, etc...). We could recreate that with http repositories, but with a significant amount of work. Regards, Thierry > > Cheers, > Andrei > > > Stef > > >

April 22, 2015