September 2016 - Pharo-dev - lists.pharo.org

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

by stepharo

Le 15/9/16 Ã 22:16, Esteban A. Maringolo a Ã©crit : > 2016-09-15 17:09 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >> However, one thing to keep in mind is that one reason why these solutions exist is because they assume no UI environment. Thus, the only thing they have is text and the solution is built around it. >> >> In Pharo, we can think of concatenating information in the environment. If we have a casual connection between examples and the code they exemplify, the interface can provide all this information at the same time. The advantage here is that the syntax remains simple. > +1 > > I wouldn't like that syntax, nor PharoDoc (a la JavaDoc), nor anything > "polluting" the code that way. It is not polution, it is documentation. Apparently you are not the guy that got the HUGE pain to write the method comment and the chapter about FileSystem. I'm probably too stupid. To understand what each method was doing I had to TRY and ERROR. I recently try to understand certain behavior of the Date package and same syndrome. Without an example it is impossible to get **exactly** what the method is doing. So that you do not use it in your code is your style and life. Now Pharo must improve from that perspective. I do not want to read five methods with different context to understand that basename includes the extension '/foo/gloops.taz' asFileReference basename is 'gloops.taz and that name does not. Sorry but as one of the leader of Pharo if I do not have such exigence and vision for our system then I should go do something else. Stef > > The comment or examples can be attributes of the method itself, just > like the class comment are today. > > Regards! > > Esteban A. Maringolo > >

Sept. 16, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Thierry Goubier

2016-09-16 8:54 GMT+02:00 stepharo <stepharo(a)free.fr>: > > Furthermore, typical examples require more than one liners, and these >> should be factored out separately. >> > > I really like the one liners that you can find im some method comments, > like in Color class>>#wheel: > if you are new to pharo and start exploring the system, it makes fun to > see these little one lines and > just execute it. (even if they aren't onelines like in some method in > class Form). > > > Me too and what I like is that there are coupled to the method. > I find a method and I guess it will help me > and bam I read the example and I'm sure it is or not what I'm looking for. > My belief is that we have an IDE able to track metadata (here, examples) along with methods, and that there is no need to play with syntax extensions (which are a way of adding metadata to programming languages stuck in the file concept of the 60's). In short, a nice, OO way of adding information about a method / class / tag / package that the IDE knows how to relate to the code. Having the class comment pane open in Nautilus is already a step towards doing that. Regards, Thierry > > Stef > > > >> >> Cheers, >> Doru >> >> >> > >> > Marcus >> > >> > >> > >> > >> > >> > >> >> -- >> 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 stepharo

> On Fri, Sep 16, 2016 at 2:45 AM, stepharo <stepharo(a)free.fr> wrote: >> Hi all >> >> I want something similar in the spirit to PythonDocTest >> https://docs.python.org/2/library/doctest.html >> >> I'm talking about >> >> basename >> "Returns the base of the basename, >> i.e. >> /foo/gloops.taz basename is 'gloops.taz' >> / basename is '/'" >> >> Pragmas do not work well i.e., >> basename >> "Returns the base of the basename" >> <expr: '''/foo/gloops.taz'' asFileReference basename' result: >> 'gloops.taz'> >> >> >> We should invent a syntax to be put inside comments and that we can easily >> parse because we need to improve >> the use and discovery of the library. >> >> I was thinking about >> >> basename >> "Returns the base of the basename" >> " >> '/foo/gloops.taz' asFileReference basename >> >>> 'gloops.taz' >> " >> >> Do you have any idea? > basename > "Returns the base of the basename" > """ > '/foo/gloops.taz' asFileReference basename > ==> 'gloops.taz' > """ > self size == 0 > "the root node" > ifTrue: [ ^ '/']. > ^ self at: self size > > I like this idea. But a fine semantic.... > We should think of these less as "tests" > and more as "howto" snippets that are tested for correctness. > > They should show just the *simplest* was to get an object to which the > method can be sent. > Maybe they could be also displayed via the gtExample interface ?? May be. Right now I want to make sure that all the little examples that are written for example inside methods are correct. Stef > > cheers -ben > >

Sept. 16, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by stepharo

> Furthermore, typical examples require more than one liners, and > these should be factored out separately. > > > I really like the one liners that you can find im some method > comments, like in Color class>>#wheel: > if you are new to pharo and start exploring the system, it makes fun > to see these little one lines and > just execute it. (even if they aren't onelines like in some method in > class Form). Me too and what I like is that there are coupled to the method. I find a method and I guess it will help me and bam I read the example and I'm sure it is or not what I'm looking for. Stef > > > Cheers, > Doru > > > > > > Marcus > > > > > > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Every thing should have the right to be different." > > > > > >

Sept. 16, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by stepharo

> So, until know, I didn't really know what pythondoctest is about. I > first thought the "test" is about unit tests > and thought our way how we can generate or jump from methods to the > corresponding is better, > but know I understand that it is about "perform regression testing by > verifying that interactive examples are working" > And that is of course a good idea. To me this is more than that. This is having simple scenario always validated and in front of my nose when I read the code. > > > If we have ' ' then it would be good that the syntax higlighter > works with a special mode inside the ' ' > > > Not for pragma arguments, I think this would be confusing. Yes I cam to the same conclusion than marcus. > > I did some expreiments with formatting code in comments. I 'll write > shortly about it. > >> >> >> nicolai >> >> >> >> Stef >> >> >> 60220 >> 19086 do not allow expressions as pragma arguments >> https://pharo.fogbugz.com/f/cases/19086 >> <https://pharo.fogbugz.com/f/cases/19086> >> >> >> >> > >

Sept. 16, 2016

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

by Ben Coman

On Fri, Sep 16, 2016 at 2:45 AM, stepharo <stepharo(a)free.fr> wrote: > Hi all > > I want something similar in the spirit to PythonDocTest > https://docs.python.org/2/library/doctest.html > > I'm talking about > > basename > "Returns the base of the basename, > i.e. > /foo/gloops.taz basename is 'gloops.taz' > / basename is '/'" > > Pragmas do not work well i.e., > basename > "Returns the base of the basename" > <expr: '''/foo/gloops.taz'' asFileReference basename' result: > 'gloops.taz'> > > > We should invent a syntax to be put inside comments and that we can easily > parse because we need to improve > the use and discovery of the library. > > I was thinking about > > basename > "Returns the base of the basename" > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > Do you have any idea? basename "Returns the base of the basename" """ '/foo/gloops.taz' asFileReference basename ==> 'gloops.taz' """ self size == 0 "the root node" ifTrue: [ ^ '/']. ^ self at: self size I like this idea. But a fine semantic.... We should think of these less as "tests" and more as "howto" snippets that are tested for correctness. They should show just the *simplest* was to get an object to which the method can be sent. Maybe they could be also displayed via the gtExample interface ?? cheers -ben

Sept. 15, 2016

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

by phil＠highoctane.be

I'd be more interested with a package level doc than a class doc or test. Package level doc is quite useful to outline how some things are working together, something which is quite hard to figure out except by reading external doc or inferring things by walking through the code or a running test. Having the ability to read about a package would be very useful. Basically, this is what Java provides. http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javadoc.html#p… Phil On Thu, Sep 15, 2016 at 8:45 PM, stepharo <stepharo(a)free.fr> wrote: > Hi all > > I want something similar in the spirit to PythonDocTest > https://docs.python.org/2/library/doctest.html > > I'm talking about > > basename > "Returns the base of the basename, > i.e. > /foo/gloops.taz basename is 'gloops.taz' > / basename is '/'" > > Pragmas do not work well i.e., > basename > "Returns the base of the basename" > <expr: '''/foo/gloops.taz'' asFileReference basename' result: > 'gloops.taz'> > > > We should invent a syntax to be put inside comments and that we can easily > parse because we need to improve > the use and discovery of the library. > > I was thinking about > > basename > "Returns the base of the basename" > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > Do you have any idea? > > I cannot not do anything and just complain that our methods are not that > well documented. > We as a community should take this and build an super cool system. > > I tried and defined >>> on Object to see if it works! > > Object >>> aResultingObject > "If the method comment contains >>> then it is a pharo documentated > test. We can check that it is true." > > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > ^ self = aResultingObject > > > Stef > > >

Sept. 15, 2016

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

by Nicolai Hess

2016-09-15 20:45 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi all > > I want something similar in the spirit to PythonDocTest > https://docs.python.org/2/library/doctest.html > > I'm talking about > > basename > "Returns the base of the basename, > i.e. > /foo/gloops.taz basename is 'gloops.taz' > / basename is '/'" > > Pragmas do not work well i.e., > basename > "Returns the base of the basename" > <expr: '''/foo/gloops.taz'' asFileReference basename' result: > 'gloops.taz'> > > > We should invent a syntax to be put inside comments and that we can easily > parse because we need to improve > the use and discovery of the library. > > I was thinking about > > basename > "Returns the base of the basename" > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > Do you have any idea? > > I cannot not do anything and just complain that our methods are not that > well documented. > We as a community should take this and build an super cool system. > > I tried and defined >>> on Object to see if it works! > > Object >>> aResultingObject > "If the method comment contains >>> then it is a pharo documentated > test. We can check that it is true." > > " > '/foo/gloops.taz' asFileReference basename > >>> 'gloops.taz' > " > > ^ self = aResultingObject > > 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. 15, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Tudor Girba

Hi, > On Sep 15, 2016, at 10:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-09-15 8:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Sep 15, 2016, at 7:50 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >>> > >>> We can change it back and maybe add support for the reformatter to not convert it to the literal array #(3 #+ 4) . > >> > >> I do not know in fact this is why I asked :) > >> Now may be my idea to use pragma to get something like pythondoctest is a bad idea > >> but I really want to have literal programming. > >> What do you think? > >> > > I like the idea to show examples/tests close to code, but pragmas are not really good... > > > >> If we have ' ' then it would be good that the syntax higlighter works with a special mode inside the ' ' > > > > it is just a string. How do you know that it contains code? > > > > Would you highlight all string in all code as if it contained code? Or would you add this just for > > Pragmas? But even there, strings are string, not code. > > > > I think we can conclude that pragmas are not a good solution to the problem, as they are far > > too limited to express code. > > I second that. > > Furthermore, typical examples require more than one liners, and these should be factored out separately. > > I really like the one liners that you can find im some method comments, like in Color class>>#wheel: > if you are new to pharo and start exploring the system, it makes fun to see these little one lines and > just execute it. (even if they aren't onelines like in some method in class Form). > I like one liners, too. But, should a documentation mechanism be confined to only work with small examples? Cheers, Doru > Cheers, > Doru > > > > > > Marcus > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Sept. 15, 2016

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

by Esteban A. Maringolo

2016-09-15 17:09 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > However, one thing to keep in mind is that one reason why these solutions exist is because they assume no UI environment. Thus, the only thing they have is text and the solution is built around it. > > In Pharo, we can think of concatenating information in the environment. If we have a casual connection between examples and the code they exemplify, the interface can provide all this information at the same time. The advantage here is that the syntax remains simple. +1 I wouldn't like that syntax, nor PharoDoc (a la JavaDoc), nor anything "polluting" the code that way. The comment or examples can be attributes of the method itself, just like the class comment are today. Regards! Esteban A. Maringolo

Sept. 15, 2016