- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Improving the documentation model

by Hilaire

Le 21/04/2015 15:11, stephan a Ã©crit : > TL;DR: Some roadmap ideas. Looks like a lot of work. > Comments and improvements welcome: > We should replace the Pillar document format > by a better one, suitable for WYSIWYG editing and > creating long documents. People mentioned Lyx[1] and there is TeXmacs[2] as well. [1] https://en.wikipedia.org/wiki/LyX [2] https://en.wikipedia.org/wiki/GNU_TeXmacs -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

April 22, 2015

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

by Thierry Goubier

Le 22/04/2015 09:02, Esteban Lorenzano a Ã©crit : > 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 :) My position would be that, as in large projects with external upstream, the version of the external project you integrate is not exactly the same as the external one. You have a process of pushing fixes upstream, and merging the versions from the external project into yours. If you have good merge support, this is an easy process. Also remember that we have to deal with long-lived integration processes with a significant memory; large configurations with lots of versions may become a concern after a while (and for the current image, it doesn't mean much to have access to all that history). We saw that with package history; it may be nice to plan for that now. Another idea/possibility is to consider Baselines; given that a possible evolution for Pharo is towards versionning systems which handles branches and tags properly, baselines make that process significantly simpler than configurations by letting one only describe the dependencies between packages and sub-projects, and not their specific version numbers. A key evaluation to see if that works is: can a Minimal image can be rebuilt easily up to a full image, at any point (i.e. at least is all the information related to external projects easily available). A second one would be: if we had a git based process, how would that be? Could considering that (planning for branches, basically) make our current process simpler? Thierry > > >> 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] Integration process in presence of "external" project

by Esteban Lorenzano

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

QualityAssistant v0.4

by Yuriy Tymchuk

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 Have a nice week! Uko

April 22, 2015

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

by Esteban Lorenzano

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