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

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

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