- Pharo-dev - lists.pharo.org

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

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

by Thierry Goubier

2016-09-16 15:26 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > On 16 September 2016 at 13:42, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> 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 ? > > > Exactly, we already have that with class comments, so why not methods (and > while we're at it, package comments too) > 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? > > A separate method comment would make it clear that it's intended as API > documentation for users of the method (and then the comment inside the > method's source can be really a development comment). Another advantage is > that its syntax won't have to deal with being between quotes and all the > indentation/escapement hassles that come with inserting a syntax inside > another oneâ¦ > Good point. 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 Damien Pollet

On 16 September 2016 at 13:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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 ? Exactly, we already have that with class comments, so why not methods (and while we're at it, package comments too) A separate method comment would make it clear that it's intended as API documentation for users of the method (and then the comment inside the method's source can be really a development comment). Another advantage is that its syntax won't have to deal with being between quotes and all the indentation/escapement hassles that come with inserting a syntax inside another oneâ¦ -- 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 14:25 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 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") > I'd prefer to have a Pillar doc for my class / package / project with live code portions, with a link method to chapter. We use examples inside comments because we don't have anything better... > 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. > This one is independant of the syntax. If they are in, say, the Pillar description of the class, of course they can be tested and run everytime we save a new version of the package ? Or as a test case? What about examples that create views, windows and external files? How do we test they are still valid without making those a sunit test with a teardown? > > But yes, maybe we can still solve this with better Tools, not working only > on the plain text in comments. > Exactly. Moreover given what we're focusing on with GT. Thierry

Sept. 16, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

by Serge Stinckwich

Anyone can help here ? On Wed, Sep 14, 2016 at 7:26 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Always same error message ... > > ExternalAddress loadSymbol: 'Rf_initEmbeddedR' from: RLibrary > > returns FailedPrimitive > > On Wed, Sep 14, 2016 at 3:55 PM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: >> >> >>> -----Message d'origine----- >>> De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de >>> Serge Stinckwich >>> EnvoyÃ© : mercredi 14 septembre 2016 15:09 >>> Ã : Any question about pharo is welcome >>> Cc : scismalltalk(a)googlegroups.com; Pharo Development List >>> Objet : Re: [Pharo-users] [Pharo-dev] [ANN] RProjectConnector V2.1 >>> >>> Hi Vincent, >>> >> Hi Serge, >> >> >>> Ok I try again with the latest Pharo 6.0. >>> >>> When I evaluate: >>> >>> Gofer it smalltalkhubUser: 'VincentBlondeau' project: >>> 'RProjectConnector'; configuration; loadStable There is an error : could not >>> resolve Rconnector. Apparently there is a problem with the package name, >>> because this vincentBlondeau and not VincentBlondeau (Uppercase). Did you >>> already try your configuration in an empty Pharo 6.0 image ? :-) >> >> Not really for this one ... I corrected and it should work now ;) >>> >>> I was able to load RConnector-vincentBlondeau.72 directly from Monticello >>> repo. >>> I modify the RLibrary>>macModuleName path name to >>> /usr/local/Cellar/r/3.3.1_2/R.framework/Versions/3.3/Resources/lib/libR.dyl >>> ib >>> When I relaunch my image, I have an error: the R session is not well >>> initialized at startup. >>> >>> In RSession>>isExistsRf_initEmbeddedR I still see a reference to Alien class. >>> You are still using Alien ? >>> >> >> Because I didn't found something better before. But, I just looked at it and changed to ExternalAddress method. >> >> Can you try again with version 73 ? >> >> Thanks, >> Vincent >> >>> >>> >>> On Tue, Sep 13, 2016 at 6:25 PM, Blondeau Vincent >>> <vincent.blondeau(a)worldline.com> wrote: >>> > >>> > >>> > >>> >> -----Message d'origine----- >>> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part >>> >> de Serge Stinckwich EnvoyÃ© : vendredi 2 septembre 2016 16:44 Ã : >>> >> Pharo Development List Cc : scismalltalk(a)googlegroups.com; Any >>> >> question about pharo is welcome Objet : Re: [Pharo-dev] [ANN] >>> >> RProjectConnector V2.1 >>> >> >>> >> Great job Vincent ! >>> >> >>> > It will be great when it will work on OS X ;) >>> > >>> >> There is some problems on Mac OS X: >>> >> - when I try to load in a fresh Pharo 5.0 image, I got a DNU on: >>> >> RObjectArray class>>initElementType: >>> >> I was able to load the package after a while by loading directly the >>> >> package with the Monticello Browser >>> > >>> > Strange, I deleted these methods... Please ensure you are using a Pharo 6.0 >>> image (it should work under Pharo 5.0 too) and that version 14 of >>> ConfigurationOfRProjectConnector and version 71 of the RConnector >>> packages are loaded. >>> > >>> >> - Apparently there is still some methods using NB like: RSession >>> >> class>>checkSession or RSession class>>initEmbeddedR: >>> > >>> > Should not, it is modified ... >>> > >>> >> >>> >> I try to move the R dll close to my Pharo VM and also inside the >>> >> Plugins directory but without success ... >>> > >>> > It should be at the same location that libcairo.2.dylib >>> > >>> >> Is there a way to say where are the R dll instead of copying them ? >>> >> >>> > Didn't think so .. Maybe the VM developers knows ? >>> > >>> > >>> > Thanks! >>> > >>> > Vincent >>> > >>> > >>> >> Thank you. >>> >> >>> >> >>> >> >>> >> >>> >> On Thu, Sep 1, 2016 at 5:42 PM, Blondeau Vincent >>> >> <vincent.blondeau(a)worldline.com> wrote: >>> >> > Hello everyone, >>> >> > >>> >> > >>> >> > >>> >> > I am glad to announce the release of version 2.1 of the >>> RProjectConnector. >>> >> > >>> >> > The binding between Pharo and R (https://www.r-project.org/) is now >>> >> > translated to UFFI and so to Pharo 6.0. >>> >> > >>> >> > >>> >> > >>> >> > You can call directly your R methods from Pharo. For example, with >>> >> > the famous iris clustering example: >>> >> > >>> >> > >>> >> > >>> >> > iris := 'eval' asREval: {RObject findVar: 'iris'}. >>> >> > >>> >> > 'plot' >>> >> > >>> >> > asREval: >>> >> > >>> >> > {(iris at: 'Petal.Length'). >>> >> > >>> >> > (iris at: 'Petal.Width'). >>> >> > >>> >> > (#pch -> 21). >>> >> > >>> >> > (#xlab -> 'length'). >>> >> > >>> >> > (#ylab -> 'Width'). >>> >> > >>> >> > (#bg ->((iris at: 'Species') collect: >>> >> > [ :value | {'red'. 'green3'. 'blue'} at: value ])). >>> >> > >>> >> > (#main -> 'Edgar Anderson''s Iris Data')}. >>> >> > >>> >> > iris inspect. >>> >> > >>> >> > >>> >> > >>> >> > To use it, you should install R and copy the R libraries near the >>> >> > Pharo VM (see the documentation on SmalltalkHub >>> >> > (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for >>> >> > how to proceed). >>> >> > >>> >> > >>> >> > >>> >> > Donât forget to relaunch Pharo after the installation to be able to >>> >> > use the connector. >>> >> > >>> >> > >>> >> > >>> >> > Only basic features are implemented yet, but you can participate to >>> >> > its extension! >>> >> > >>> >> > >>> >> > >>> >> > Cheers, >>> >> > >>> >> > Vincent Blondeau >>> >> > >>> >> > >>> >> > >>> >> >>> !!!************************************************************ >>> >> ******* >>> >> > ****************** "Ce message et les piÃ¨ces jointes sont >>> >> > confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. >>> >> > Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous >>> >> > recevez ce message par erreur, merci d'en avertir immÃ©diatement >>> >> > l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant >>> >> > Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >>> >> > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les >>> >> > meilleurs efforts soient faits pour maintenir cette transmission >>> >> > exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet >>> >> > Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout >>> >> > dommage rÃ©sultant d'un virus transmis. >>> >> > >>> >> > This e-mail and the documents attached are confidential and >>> >> > intended solely for the addressee; it may also be privileged. If >>> >> > you receive this e-mail in error, please notify the sender >>> >> > immediately and destroy it. As its integrity cannot be secured on >>> >> > the Internet, the Worldline liability cannot be triggered for the >>> >> > message content. Although the sender endeavours to maintain a >>> >> > computer virus-free network, the sender does not warrant that this >>> >> > transmission is virus-free and will not be liable for any damages resulting >>> from any virus transmitted.!!!" >>> >> >>> >> >>> >> >>> >> -- >>> >> Serge Stinckwich >>> >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>> >> Every DSL ends up being Smalltalk >>> >> http://www.doesnotunderstand.org/ >>> > >>> > >>> > >>> !!!************************************************************ >>> ******* >>> > ****************** "Ce message et les piÃ¨ces jointes sont >>> > confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut >>> Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce >>> message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le >>> dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la >>> responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de >>> ce message. Bien que les meilleurs efforts soient faits pour maintenir cette >>> transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã >>> cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage >>> rÃ©sultant d'un virus transmis. >>> > >>> > This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this e-mail >>> in error, please notify the sender immediately and destroy it. As its integrity >>> cannot be secured on the Internet, the Worldline liability cannot be triggered >>> for the message content. Although the sender endeavours to maintain a >>> computer virus-free network, the sender does not warrant that this >>> transmission is virus-free and will not be liable for any damages resulting >>> from any virus transmitted.!!!" >>> >>> >>> >>> -- >>> Serge Stinckwich >>> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>> Every DSL ends up being Smalltalk >>> http://www.doesnotunderstand.org/ >> >> >> !!!************************************************************************************* >> "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >> >> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 16, 2016