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

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

Re: [Pharo-dev] Improving the documentation model

by Damien Cassou

Dmitri Zagidulin <dmitri(a)zagidulin.net> writes: > * Extend Pillar. With a few more features, it can be on par with > Markdown and Asciidoc, and then eventually surpass it (and have nice > Pharo-specific features like detection and unit-testing of Pharo code > blocks, etc). could you please add missing features to http://www.smalltalkhub.com/#!/~Pier/Pillar > * Invest in instant-preview tech, in-image. we have this prototype already: http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td… But its author waits for TxText and Athens before investing more of his time. > This is similar to what PillarHub does, for example, by using the Ace > online editor. Take a look at the first screenshot in: > http://pillarhub.pharocloud.com/hub/pillarhub/about Side-by-side > instant preview makes it possible to have the best of both worlds, > text-based markup and WYSIWYG, without the typical WYSIWYG drawbacks > (of making distributed version control difficult, first and foremost). 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. > 3) The convenience of WYSIWYG can be provided with side-by-side instant > preview (again, see PillarHub and the numerous WYSIWYG instant-previews in > Markdown editors). Luc improved the pillar plugin for TextMate so that it has instant preview too. > 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. > - Asciidoc has the ability to do file imports (compose a larger document > out of smaller docs) Cyril implemented that in Pillar last week. > * Links. Asciidoc has semantic links both within a document, and across > different Asciidoc documents (references to chapters, sections, etc). > Pillar has within-document links, and inter-doc links are on the roadmap. Cyril has to revise that part. > * The ability to drop down to a more expressive markup (LaTeX or HTML). For > heavier-duty features like formulas and equations, all of the simple markup > languages allow the author to drop down to LaTeX and lay out formulas to > their heart's content. this is on Pillar roadmap as well: http://www.smalltalkhub.com/#!/~Pier/Pillar -- 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] TDD and BDD

by Miguel Moquillon

Le 21/04/2015 13:44, Sean P. DeNigris a Ã©crit : > Miguel Moquillon wrote >> BDD and TDD stands for different purposes with different actors... > While that's unfortunately often true in practice, there is no difference > philosophically. [T|B]DD "done right" always focuses on the user. > [...] > The "In order to..." that you're describing is the outer, high-level > acceptance test that in Ruby for example might be written with Cucumber. But > once one has a failing acceptance test, the next step in BDD is to drop down > into e.g. RSpec and write something a lot closer to a unit test, often > mocking out collaborators to drive creation of an API. > > 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. The word 'Test' in TDD doesn't mean its purpose is to test; it is a misconception. In fact TDD is a method for developers to focus on the design of their code by avoiding over-designing. In other side, BDD stands for test, more exactly functional testing. It is a safety belt to avoid both functional regressions and to ensure the written code is valid according to the requirements. So, when a functional test failed, the next step in BDD is to pass the control to the developer to fix the issue whatever its method (BDD don't cover this level). They are not related but, as you wrote in your example with Ruby, they can be used both in a project, at a different level. BDD doesn't imply TDD but yes, in practice, they are often used in conjunction. Now, some tools were inspired by BDD to provide the developers a better way to express unit tests (RSpec for example), to be more focused on the design, but they are in fact more related to TDD than BDD. Don't confound the approach with the tools. > There is no > inherent conflict, and no specific tools are technically required. Although, > since as McLuhan suggested, we become our tools, so obviously the proper > tools may be decisive, especially when first learning. There is no conflicts between TDD and BDD because they are not related and they are not concurrent. In fact they can be used both but at different level. The same with the tools. Beside that, I have a principle: don't learn an approach through a tool. But use a tool to facilitate the application of the approach. And as you wrote, indeed, the proper tool is important. Miguel Moquillon

April 22, 2015

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

by Andrei Chis

On Wed, Apr 22, 2015 at 7:47 AM, stepharo <stepharo(a)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. Cheers, Andrei > > Stef > > >

April 22, 2015

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

by Andrei Chis

On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm(a)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. Cheers, Andrei > > > On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm(a)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> > 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> 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] Improving the documentation model

by Damien Cassou

nacho <0800nacho(a)gmail.com> writes: > The other day I was thinking about this. I thought that it would be a great > idea to have a pillar rendering engine inside Pharo. > In that way the documentation written will be available in the image > WYSIWYG with no need for recompilation. The update of books will be easy, > just do a Software Update and the documentation is up to date. > a Pillar rendering, WYSIWYG editor would be great. in the following thread, I reference a prototype that does just that: http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td… -- 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