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

Re: [Pharo-dev] Maintainer of DependencyAnalyser: Action needed

by stepharo

This is christophe! > Whoever maintains DependencyAnalyser: There is a fix ready since 22 August 2016. > > We need to get this into the system *soon*. > > https://pharo.fogbugz.com/f/cases/18963/DANode-browseClass-sends-unimplemen… > > > Marcus >

Sept. 16, 2016

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

by Eliot Miranda

Hi All, _,,,^..^,,,_ (phone) > On Sep 14, 2016, at 10:50 PM, 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 think that's not a safe conclusion. We know from Igor's use of Kieran arrays for C signatures in the UFFI, and can easily extrapolate here, that arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S expressions work for lisp. In this particular case special casing pretty printing of literal arrays in pragmas would be all that's needed to make the code look beautiful. Why throw the baby out with the bath water? It would be so easy to make this work well. The only thing I'd do would be to print like this to make it clear that the argument t is a literal Array and not some magic form of code: <expr: #(3 + 4) result: 7> > > Marcus > > > > > >

Sept. 16, 2016

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

by philippe.back＠highoctane.be

How is all of this PackageManifest mechanism working? Doc anywhere? Phil Le 16 sept. 2016 17:02, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : 2016-09-16 0:19 GMT+02:00 phil(a)highoctane.be <phil(a)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. > Why don't we have yet package comments ? I see there is some support for it in PackageManifest, I remember there was some work (people working) on support for Nautilus, no? maybe something like this, (see attached file) Nautilus comment pane on class selection -> show class comment no class selection -> show package comment (class side #description of package manifest of this package) you can even add or change the (package) comment, it will compile a proper #description method on the manifest class) > > 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#packagecomment > > 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. 16, 2016

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

by Nicolai Hess

2016-09-16 0:19 GMT+02:00 phil(a)highoctane.be <phil(a)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. > Why don't we have yet package comments ? I see there is some support for it in PackageManifest, I remember there was some work (people working) on support for Nautilus, no? maybe something like this, (see attached file) Nautilus comment pane on class selection -> show class comment no class selection -> show package comment (class side #description of package manifest of this package) you can even add or change the (package) comment, it will compile a proper #description method on the manifest class) > > 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# > packagecomment > > 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. 16, 2016

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

by Thierry Goubier

Sorry for the mistake, 2016-09-16 15:51 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > On 16 September 2016 at 15:35, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Could we have a Pillar-way of organizing comments so that, based on >> sections, one could automatically find, from a book-like comment of the >> package or the class, which section applies to a given method? > > > I guess it's like any cross-referencing or indexing systemâ¦ I'm guessing a > purely automatic system would find irrelevant matches and miss related > stuff, so it would need some human-added hints. But no one can reasonably > go through the cross-product of docs and code, adding hints, so that would > need to be crowdsourced and aggregated, a bit like the QA critiques. > If one could reference the package code (class / method) as a reference inside the Pillar comment, would that work? I'm a bit wary of an 'automatic' approach, but I'd find great to go in a fluid way from text to code and back. For those who remember, my idea would be like referencing chapters and sections of the LaTeX generation of smalltalk source code... If you reference {\ref aClass:aProtocol:aMethod} then you get a live two-way link between the comment and the code in the browser. > I'll leave this link to the Django docs: https://docs. > djangoproject.com/en/1.10/ > I recently watched a talk from I think the Django lead who was explaining > the different kinds of docs (tutorials, howtos, topic guides, and > reference). Package/class/method comments would be reference doc, but would > need to cross-ref with any other docs tooâ¦ > I'd make it simple: start with a book-like document cross-referenced with the live code, as the preferred documentation for a package. Thierry > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Sept. 16, 2016

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

by Thierry Goubier

2016-09-16 15:51 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > On 16 September 2016 at 15:35, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Could we have a Pillar-way of organizing comments so that, based on >> sections, one could automatically find, from a book-like comment of the >> package or the class, which section applies to a given method? > > > I guess it's like any cross-referencing or indexing systemâ¦ I'm guessing a > purely automatic system would find irrelevant matches and miss related > stuff, so it would need some human-added hints. But no one can reasonably > go through the cross-product of docs and code, adding hints, so that would > need to be crowdsourced and aggregated, a bit like the QA critiques. > If one could, in a Pillar doc of a package, unify the packa > > I'll leave this link to the Django docs: https://docs. > djangoproject.com/en/1.10/ > I recently watched a talk from I think the Django lead who was explaining > the different kinds of docs (tutorials, howtos, topic guides, and > reference). Package/class/method comments would be reference doc, but would > need to cross-ref with any other docs tooâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Sept. 16, 2016

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

by Nicolas Passerini

Yes, that would be great. I just wander if the increased complexity pays off... normally if I am running my tests I do not have lots of tasks in mind, I will decide what to do next after seeing that my tests are green. Maybe I just want to browse some code, I do not need super fancy features. On Fri, Sep 16, 2016 at 4:13 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > > -------- Original Message -------- > > > > 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. > > That is a cosmethic thing. > > Imagine you could run the tests on a copy of the image you were > developing. If there is an error, your development image gets notified, and > so you can then debug the error on your local environment. > >

Sept. 16, 2016

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

by Guille Polito

-------- Original Message -------- > > > On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > > On 16 Sep 2016, at 12:43, Nicolas Passerini > <npasserini(a)gmail.com <mailto:npasserini@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. That is a cosmethic thing. Imagine you could run the tests on a copy of the image you were developing. If there is an error, your development image gets notified, and so you can then debug the error on your local environment.

Sept. 16, 2016

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

by Bernardo Ezequiel Contreras

Another example: https://docs.racket-lang.org/scribble/index.html First example: https://docs.racket-lang.org/scribble/getting-started.html#%28part._first-e… On Fri, Sep 16, 2016 at 10:51 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 16 September 2016 at 15:35, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Could we have a Pillar-way of organizing comments so that, based on >> sections, one could automatically find, from a book-like comment of the >> package or the class, which section applies to a given method? > > > I guess it's like any cross-referencing or indexing systemâ¦ I'm guessing a > purely automatic system would find irrelevant matches and miss related > stuff, so it would need some human-added hints. But no one can reasonably > go through the cross-product of docs and code, adding hints, so that would > need to be crowdsourced and aggregated, a bit like the QA critiques. > > I'll leave this link to the Django docs: https://docs. > djangoproject.com/en/1.10/ > I recently watched a talk from I think the Django lead who was explaining > the different kinds of docs (tutorials, howtos, topic guides, and > reference). Package/class/method comments would be reference doc, but would > need to cross-ref with any other docs tooâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Sept. 16, 2016

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

by Damien Pollet

On 16 September 2016 at 15:35, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Could we have a Pillar-way of organizing comments so that, based on > sections, one could automatically find, from a book-like comment of the > package or the class, which section applies to a given method? I guess it's like any cross-referencing or indexing systemâ¦ I'm guessing a purely automatic system would find irrelevant matches and miss related stuff, so it would need some human-added hints. But no one can reasonably go through the cross-product of docs and code, adding hints, so that would need to be crowdsourced and aggregated, a bit like the QA critiques. I'll leave this link to the Django docs: https://docs.djangoproject.com/en/1.10/ I recently watched a talk from I think the Django lead who was explaining the different kinds of docs (tutorials, howtos, topic guides, and reference). Package/class/method comments would be reference doc, but would need to cross-ref with any other docs tooâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 16, 2016