- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Nicolai Hess

2016-09-16 13:42 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Why don't you just change nautilus to have two text areas, one with the > test corresponding to the method and the other one with the method's code ? > > You're saying: > *Their values is active documentation that can be automatically validated.* > That can also be applied to test we've already had with SUnit. If the only > difference you want is to display the test next to the method, then it's an > IDE problem, nothing has to be changed but the IDE. > This is what I thought first, we already have the association between methods and tests, Nautilus can detect if there is a corresponding test , for example browse Fraction>>truncated, it will show a test icon, that will run the test FractionTest>>#testTruncated. This works already good, and I think we don't need special comments or pragmas for this. But what stef wants is 1. Method docs with examples, so a user can see an example usage of a method (sunit test methods sometimes aren't good "examples") 2. We already had (and still have) some method docs where the example code just won't work anymore because the methods or classes used by the example were removed, renamed. So, it would be good if we can extract these examples and run them automatically to make sure they are still working. But yes, maybe we can still solve this with better Tools, not working only on the plain text in comments. > > In python they have no other choices than putting tests in comments > because their IDE is a text editor, they cannot create other panes or > anything like that. > > On Fri, Sep 16, 2016 at 1:21 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> Hi, >> >> I was thinking on the metro way to work, and I also saw that this >> discussion is actually split in multiple threads, so it was not easy to >> follow :). >> >> Some of my feelings about this: >> >> - Pragmas are nice because they are easy to "interpret". Parsing them is >> already provided. However, putting expressions or long examples into them >> starts to be awkward. It seems it's pushin the syntax too much, isn't it? >> >> - Comments are nice because they are ignored! But right now comments are >> simple plain text. This thread is to convert *some* comments into >> executable examples. But this should be just some comments and not all of >> them, am I right? So what happens when we want to have comments written in >> Pillar for example? What I mean is that having examples is just an example >> of something we would like to do with comments. >> >> But we can also imagine having comment interpreters. Something like this: >> >> ">>>PillarDoc >> !This is a Pillar title >> And I'm just a paragraph >> And I can link a class like @Object. >> " >> >> >> ">>>ExampleDoc >> self assert: '/foo/gloops.taz' asFileReference basename equals: >> 'gloops.taz' >> " >> >> >> We could have for class comment >> >> ">>>UMLDescription >> UMLClass named: 'Visitor' >> >> Arrow from: >> >> But this can start to be complex >> " >> >> What I like from this is that: >> - comments that do not specify an interpreter are just plain old text. >> Thus backward compatible. >> - comments that specify an interpreter that is not present, are just >> plain old text. A decoupling as it happens with the settings. >> - an ExampleDoc interpreter can be just a test case instance, thus we >> could use assertions instead of special >>> messages. >> >> I do not know because all the comments should be pillar compatible. >> If you do not use pillar commands you just get plain text. >> You see we can easily detect comment too: if a text contains >>> then it >> is a doc >> >> Then >> ExampleDoc >> is an extra syntax. >> >> I'm not found with the >> self assert: >> because it feels like something coming out of nowhere. We will have to >> explain: yes self is bound to an instance of the testCase... >> and to me this is implementation details: >> if I give expr1 and expr2 the implementation can build self assert: >> expr1 equals: expr2 >> >> I liked the simplicity of nicolai' solution >> I would just have a comment and a message >>> so that we >> => nearly no syntax change >> => something really lightweight and optional >> >> >> What I care is that >> >> - we get simple examples right in the method >> - one line no more. >> - that these examples are correct and always validated (I do not see >> them as tests), their values is more in the correct documentation >> than the tests. They are basic output. I do not want to have full >> code in the method, in that case this should go one class side example >> or plain tests. >> >> >> Things that would require more thought: >> - there is an overlap between these interpreted comments and pragmas... >> There are for sure cases that solutions can be imagined with both. >> >> I do not think that expressions can fit inside pragmas >> >> - there is an overlap between examples and test cases. I saw many >> people that argued that already. I am not against examples, but I think we >> should (whichever implementation is chosen) draw a line and set some >> guidelines. >> >> To me I do not care that they are tests. >> Their values is active documentation that can be automatically validated. >> I do not expect to run them but the system >> can garantee that they are correct. >> >> Stef, probably you have already in mind when you want a test case and >> when an example and what's the distance. It would be good if we can >> transform that implicit thought in something explicit (maybe even a lint >> rule in the future?) >> >> I do not get what you mean here. >> >> For me a test is a scenario. >> If I do that and that then this happens >> a test can use a class example >> >> Now for me a test should not rely one a online part of method comment. >> >> >> These onliners are just make the method comments better. >> >> >> >> >> >> Guille >> >> -------- Original Message -------- >> >> Hi nicolai >> >> >> I was thinking that I would prefer to have >> >> >> "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`" >> >> >> instead of >> ` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- >> suceeds, no output >> >> So that we can use ` in the future in plain code. >> Also it has the advantage that it is backward compatible. >> >> Else we could have >> >> `` >> But I do not know. >> >> Tell me what you think. >> >> I would love to browse the complete system to convert existing one liner >> with such >> >> Stef >> >> >> Ok, this is a quick hack ( do not look at the code :), yes using regex >> here is a bit fragil) >> >> You can add code in comments between backticks (`) >> The formatter will highlight the text like smalltalk code (or not if it >> is not valid code). >> + an icon styler with an icon showing a warning icon for faulty code or >> an information icon otherwise >> you can click on the icon, >> >> if the code is an association >> >> expression -> result >> >> it executes the expression and compares it with the result, (with >> assert:equals: ) opens debugger if it fails and does >> nothing otherwise >> >> if the code is just an expression, it opens an inspector. >> >> This is just one way to do some tests and experiments with this idea, don >> 't yet know if this is a good idea or if >> we can / should find a better way to connect code with examples. >> >> first result, I find expressions in comments, highlighted as code, >> confusing :) >> >> (file in attached cs in a recent pharo 6.0 and look at the method >> AbstractFileReference>>#baseName . Or >> add an expression with backticks in a method comment >> ` your code here ` >> >> >> >> >>> >>> Stef >>> >>> >>> >> >> >> >> >

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Denis Kudriashov

2016-09-16 13:42 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Why don't you just change nautilus to have two text areas, one with the > test corresponding to the method and the other one with the method's code ? > > You're saying: > *Their values is active documentation that can be automatically validated.* > That can also be applied to test we've already had with SUnit. If the only > difference you want is to display the test next to the method, then it's an > IDE problem, nothing has to be changed but the IDE. > > In python they have no other choices than putting tests in comments > because their IDE is a text editor, they cannot create other panes or > anything like that. > It is of course true. But Stef suggestion is really much much simpler. It is just convention how to write examples inside comments. Then tools could work with them and Nicolai already provide simple extension for Nautilus. We already has a lot of comments with examples inside. Making them discoverable and testable will be nice.

Sept. 16, 2016

Re: [Pharo-dev] Maintainer of TxText: action needed

by Tudor Girba

As of now, I do not think there is any maintainer of TxText. Doru > On Sep 16, 2016, at 1:28 PM, stepharo <stepharo(a)free.fr> wrote: > > Marcus we should integrate it. > > > Le 16/9/16 Ã 13:22, Marcus Denker a Ã©crit : >> Hi, >> >> Whoever maintains TxTxt: there is a fix ready since 19 July 2016. >> >> Can we get this into the system, please? >> >> >> https://pharo.fogbugz.com/f/cases/18788/TxTextStyler-do-not-work >> >> (or we should give up in this being maintained âexternallyâ) >> > > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by ClÃ©ment Bera

Why don't you just change nautilus to have two text areas, one with the test corresponding to the method and the other one with the method's code ? You're saying: *Their values is active documentation that can be automatically validated.* That can also be applied to test we've already had with SUnit. If the only difference you want is to display the test next to the method, then it's an IDE problem, nothing has to be changed but the IDE. In python they have no other choices than putting tests in comments because their IDE is a text editor, they cannot create other panes or anything like that. On Fri, Sep 16, 2016 at 1:21 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi, > > I was thinking on the metro way to work, and I also saw that this > discussion is actually split in multiple threads, so it was not easy to > follow :). > > Some of my feelings about this: > > - Pragmas are nice because they are easy to "interpret". Parsing them is > already provided. However, putting expressions or long examples into them > starts to be awkward. It seems it's pushin the syntax too much, isn't it? > > - Comments are nice because they are ignored! But right now comments are > simple plain text. This thread is to convert *some* comments into > executable examples. But this should be just some comments and not all of > them, am I right? So what happens when we want to have comments written in > Pillar for example? What I mean is that having examples is just an example > of something we would like to do with comments. > > But we can also imagine having comment interpreters. Something like this: > > ">>>PillarDoc > !This is a Pillar title > And I'm just a paragraph > And I can link a class like @Object. > " > > > ">>>ExampleDoc > self assert: '/foo/gloops.taz' asFileReference basename equals: > 'gloops.taz' > " > > > We could have for class comment > > ">>>UMLDescription > UMLClass named: 'Visitor' > > Arrow from: > > But this can start to be complex > " > > What I like from this is that: > - comments that do not specify an interpreter are just plain old text. > Thus backward compatible. > - comments that specify an interpreter that is not present, are just > plain old text. A decoupling as it happens with the settings. > - an ExampleDoc interpreter can be just a test case instance, thus we > could use assertions instead of special >>> messages. > > I do not know because all the comments should be pillar compatible. > If you do not use pillar commands you just get plain text. > You see we can easily detect comment too: if a text contains >>> then it > is a doc > > Then > ExampleDoc > is an extra syntax. > > I'm not found with the > self assert: > because it feels like something coming out of nowhere. We will have to > explain: yes self is bound to an instance of the testCase... > and to me this is implementation details: > if I give expr1 and expr2 the implementation can build self assert: > expr1 equals: expr2 > > I liked the simplicity of nicolai' solution > I would just have a comment and a message >>> so that we > => nearly no syntax change > => something really lightweight and optional > > > What I care is that > > - we get simple examples right in the method > - one line no more. > - that these examples are correct and always validated (I do not see > them as tests), their values is more in the correct documentation > than the tests. They are basic output. I do not want to have full code > in the method, in that case this should go one class side example > or plain tests. > > > Things that would require more thought: > - there is an overlap between these interpreted comments and pragmas... > There are for sure cases that solutions can be imagined with both. > > I do not think that expressions can fit inside pragmas > > - there is an overlap between examples and test cases. I saw many people > that argued that already. I am not against examples, but I think we should > (whichever implementation is chosen) draw a line and set some guidelines. > > To me I do not care that they are tests. > Their values is active documentation that can be automatically validated. > I do not expect to run them but the system > can garantee that they are correct. > > Stef, probably you have already in mind when you want a test case and when > an example and what's the distance. It would be good if we can transform > that implicit thought in something explicit (maybe even a lint rule in the > future?) > > I do not get what you mean here. > > For me a test is a scenario. > If I do that and that then this happens > a test can use a class example > > Now for me a test should not rely one a online part of method comment. > > These onliners are just make the method comments better. > > > > > > Guille > > -------- Original Message -------- > > Hi nicolai > > > I was thinking that I would prefer to have > > > "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`" > > > instead of > ` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- > suceeds, no output > > So that we can use ` in the future in plain code. > Also it has the advantage that it is backward compatible. > > Else we could have > > `` > But I do not know. > > Tell me what you think. > > I would love to browse the complete system to convert existing one liner > with such > > Stef > > > Ok, this is a quick hack ( do not look at the code :), yes using regex > here is a bit fragil) > > You can add code in comments between backticks (`) > The formatter will highlight the text like smalltalk code (or not if it is > not valid code). > + an icon styler with an icon showing a warning icon for faulty code or an > information icon otherwise > you can click on the icon, > > if the code is an association > > expression -> result > > it executes the expression and compares it with the result, (with > assert:equals: ) opens debugger if it fails and does > nothing otherwise > > if the code is just an expression, it opens an inspector. > > This is just one way to do some tests and experiments with this idea, don > 't yet know if this is a good idea or if > we can / should find a better way to connect code with examples. > > first result, I find expressions in comments, highlighted as code, > confusing :) > > (file in attached cs in a recent pharo 6.0 and look at the method > AbstractFileReference>>#baseName . Or > add an expression with backticks in a method comment > ` your code here ` > > > > >> >> Stef >> >> >> > > > >

Sept. 16, 2016

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

by Nicolas Passerini

On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 16 Sep 2016, at 12:43, Nicolas Passerini <npasserini(a)gmail.com> > wrote: > > > > I think it would be nice to be able to run tests in background. > > > > The easiest is to start multiple imagesâ¦ this way they can destroy > whatever without impacting you. > I think Guille has something in preparationâ¦ > > The nice aspect of this is that it runs really in parallel. > That is a nice feature, but if I am working on something and I make changes I would like to run the tests right where I am working.

Sept. 16, 2016

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

by Denis Kudriashov

Hi 2016-09-16 13:21 GMT+02:00 stepharo <stepharo(a)free.fr>: > - there is an overlap between examples and test cases. I saw many people > that argued that already. I am not against examples, but I think we should > (whichever implementation is chosen) draw a line and set some guidelines. > > To me I do not care that they are tests. > Their values is active documentation that can be automatically validated. > I do not expect to run them but the system > can garantee that they are correct. How it could work? Somebody need to press button to check all comments are valid. No?

Sept. 16, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60227 Home: https://github.com/pharo-project/pharo-core

Sept. 16, 2016

[pharo-project/pharo-core] b402df: 60227

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b402df88fd1de5a005362c220e24808cbf004c27 https://github.com/pharo-project/pharo-core/commit/b402df88fd1de5a005362c22… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-16 (Fri, 16 Sep 2016) Changed paths: M FuelTools-Debugger.package/FuelOutStackDebugAction.class/class/serialization/serializeTestFailureContext_toFileNamed_.st A Kernel.package/Context.class/instance/system simulation/stepToHome_.st M Kernel.package/Process.class/instance/changing suspended state/stepToHome_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60226.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60227.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60226.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60227.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/api/selectedClass.st Log Message: ----------- 60227 16877 another endless debugger loop https://pharo.fogbugz.com/f/cases/16877 19097 Move to instance side refactoring of class method in the sender list is mispelled https://pharo.fogbugz.com/f/cases/19097 19098 FuelOutStackDebugAction uses incorrect debugger API https://pharo.fogbugz.com/f/cases/19098 http://files.pharo.org/image/60/60227.zip

Sept. 16, 2016

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

by Denis Kudriashov

2016-09-16 12:43 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: > I think it would be nice to be able to run tests in background. > > What would be the problem? A test case that fails because you were doing > something at the same time? I think it is not so serious, it is up to you > to know which tests did you run and do nothing that would conflict with the > test run. Now you can't do anything. > I also want to load code in background.

Sept. 16, 2016

Re: [Pharo-dev] Maintainer of TxText: action needed

by stepharo

Marcus we should integrate it. Le 16/9/16 Ã 13:22, Marcus Denker a Ã©crit : > Hi, > > Whoever maintains TxTxt: there is a fix ready since 19 July 2016. > > Can we get this into the system, please? > > > https://pharo.fogbugz.com/f/cases/18788/TxTextStyler-do-not-work > > (or we should give up in this being maintained âexternallyâ) >

Sept. 16, 2016