- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] <example>/<examplar>

by Nicolai Hess

2016-08-18 22:45 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> Why not use <example> pragma in the way you propose for <examplar>? Why >> we need two? >> >> >> Apparently from the old discussion, people like <example> to prompt and >> open the example >> when this is something visual. This is ok for me. >> > > Ok, let's distinguish them. Scripts are scripts (maybe <script> is better > name than <example>?) > > I thought that we don't need two options because in practice <example> > only opens morph or inspector. And for morphs we already have morph tab in > inspector. So morph examples could be easily converted to <examplar> > without any loss. > > some <example> methods don't just show a morph that you want to inspect, but a Morph that you want to interact with. And not all Morphs render well in the inspectors Morph tab. <script> - execute some code, don't care about the return value <example> - create an (UI/Morph)-example you can interact with <exemplar> - create an example instance. I like all three of them and can see a value for every single one. > In my proposal we can get the best of both worlds. >> - instance to use in tests >> - instance to learn and tweak with GTInspector >> - examples that we can see opening. > > > >

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by Tudor Girba

Hi, I am happy to see the concept of an example method catching attention again. As explained before, the GTExample was already present in the Pharo image, but it was introduced more as a helper for testing GT extensions. Now, I just created an issue for removing GTExamples from the GT-Inspector package and from the main Pharo image: https://pharo.fogbugz.com/f/cases/18965/Remove-GTExample-from-the-GT-Inspec… Cheers, Doru > On Aug 18, 2016, at 10:45 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)free.fr>: >> Hi >> >> Why not use <example> pragma in the way you propose for <examplar>? Why we need two? > > Apparently from the old discussion, people like <example> to prompt and open the example > when this is something visual. This is ok for me. > > Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?) > > I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss. > > In my proposal we can get the best of both worlds. > - instance to use in tests > - instance to learn and tweak with GTInspector > - examples that we can see opening. > > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by Denis Kudriashov

2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > Why not use <example> pragma in the way you propose for <examplar>? Why we > need two? > > > Apparently from the old discussion, people like <example> to prompt and > open the example > when this is something visual. This is ok for me. > Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?) I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss. > In my proposal we can get the best of both worlds. > - instance to use in tests > - instance to learn and tweak with GTInspector > - examples that we can see opening.

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by Stephan Eggermont

On 18/08/16 14:38, stepharo wrote: > Hi > > In my projects I start to do the following: > > I create <examplar> class method that returns an prototypical instance. Nice. Excellent inititive. I'm not a native speaker, and <exemplar> does not sound like the right name for this to me. That might be me being dutch. Native speakers, is this the right name to use? Stephan

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

A little blog post to explain https://wordpress.com/post/pharoweekly.wordpress.com/1190 Stef

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

Le 18/8/16 Ã 21:31, stepharo a Ã©crit : > Hi all > > I implemented the <examplar> to behave as suggested by torsten and it > is available in less than 5 min (I loved it). An example is JUST a > class method returning an instance. examplar is JUST... :) > > CTGrid class >> grid22 > <examplar> > "self grid22" > | grid1 | > grid1 := self new: 2. > grid1 atRow: 1 atColumn: 1 put: 1. > grid1 atRow: 1 atColumn: 2 put: 3. > grid1 atRow: 2 atColumn: 1 put: 2. > grid1 atRow: 2 atColumn: 2 put: 4. > ^ grid1 > > You can use this method as any class method in the past. NOTHING new!! > So in particular your test can use it to build a fixture (yes reuse). > You can use this method in several test cases (yes reuse). > > > Now nautilus supports nicely <examplar> methods: you can execute them > and get a cool GTInspector open on them. So this is similar to the > method exampleSomething from Nautilus point of view. And now people > can use example to create/open/... their lovely examples (that may not > return instances). And we get examplar methods that must return an > instance but can behave as example from Nautilus perspective. > > https://pharo.fogbugz.com/f/cases/18964/support-examplar > > If you want to try you can load the CTGrid packages > > ScriptLoader new unloadPackageNamed: 'Collections-Grid'. > ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'. > "Because there were not good and will be removed from the image" > Gofer it > url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main'; > configurationOf: 'Grid'; > loadStable > > Click on class side of CTGrid and press the triangle and yes you get > an inspector on this instance. > > Stef > > > > > > Le 18/8/16 Ã 14:38, stepharo a Ã©crit : >> Hi >> >> In my projects I start to do the following: >> >> I create <examplar> class method that returns an prototypical instance. >> >> I use such methods in my tests as fixture. >> >> Then I would like to have nautilus presenting to me the <examplar> >> with a little triangle and when I press >> >> on them I get an inspector on them. >> >> This way I get the same behavior than with default <example> methods >> that open an widget, image.... >> >> If we agree on that >> >> - I can take all the <example> and turn them if necessary into >> examplar. >> >> - extend Nautilus to send an inspect to the result of examplar >> tagged method. >> >> I think that we can achieve a lot in terms of discovery with such >> simple changes. >> >> Stef >> >> PS: I reread the old thread and I think that this is a reasonable >> approach that makes >> >> the pro instances (like me) and the pro examples showing some things >> (like me) happy. >> >> >> > > >

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

Hi all I implemented the <examplar> to behave as suggested by torsten and it is available in less than 5 min (I loved it). An example is JUST a class method returning an instance. CTGrid class >> grid22 <examplar> "self grid22" | grid1 | grid1 := self new: 2. grid1 atRow: 1 atColumn: 1 put: 1. grid1 atRow: 1 atColumn: 2 put: 3. grid1 atRow: 2 atColumn: 1 put: 2. grid1 atRow: 2 atColumn: 2 put: 4. ^ grid1 You can use this method as any class method in the past. NOTHING new!! So in particular your test can use it to build a fixture (yes reuse). You can use this method in several test cases (yes reuse). Now nautilus supports nicely <examplar> methods: you can execute them and get a cool GTInspector open on them. So this is similar to the method exampleSomething from Nautilus point of view. And now people can use example to create/open/... their lovely examples (that may not return instances). And we get examplar methods that must return an instance but can behave as example from Nautilus perspective. https://pharo.fogbugz.com/f/cases/18964/support-examplar If you want to try you can load the CTGrid packages ScriptLoader new unloadPackageNamed: 'Collections-Grid'. ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'. "Because there were not good and will be removed from the image" Gofer it url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main'; configurationOf: 'Grid'; loadStable Click on class side of CTGrid and press the triangle and yes you get an inspector on this instance. Stef Le 18/8/16 Ã 14:38, stepharo a Ã©crit : > Hi > > In my projects I start to do the following: > > I create <examplar> class method that returns an prototypical instance. > > I use such methods in my tests as fixture. > > Then I would like to have nautilus presenting to me the <examplar> > with a little triangle and when I press > > on them I get an inspector on them. > > This way I get the same behavior than with default <example> methods > that open an widget, image.... > > If we agree on that > > - I can take all the <example> and turn them if necessary into > examplar. > > - extend Nautilus to send an inspect to the result of examplar > tagged method. > > I think that we can achieve a lot in terms of discovery with such > simple changes. > > Stef > > PS: I reread the old thread and I think that this is a reasonable > approach that makes > > the pro instances (like me) and the pro examples showing some things > (like me) happy. > > >

Aug. 18, 2016

Re: [Pharo-dev] About PythonDocTest for Pharo

by stepharo

As I already told you and the board, I will just leave if such a solution get pushed into Pharo. >>> Hi, >>> >>> I like this problem very much. I think we are not leveraging the objects we have in the image. Tests can help, but they are way too disconnected from the code and they are not really useful for detailed questions. >>> >>> I am also happy that you are considering the use of pragmas for this purpose. >>> >>> As you know, Stefan Reichhart and I worked on the examples engine since a couple of years and I think we now start to have a working solution. >> I do not want 5 pragmas and dependencies between methods and examples. KISS. >> Pharo tends to forget KISS far too often recently. >> You know exactly what I do not want: conceptual (and code) bloat. > It think it is KISS. If you only want one feature, you use exactly one pragma <gtExample>. Nothing else. If you want more, as people do, you can get more. > > But, I wonât go into a debate now. First, I would like to present what exists and then you can form an opinion if you want. > > Just a note: there already exists in the image a first implementation of GTExample, and this proved very useful for testing the inspector and spotter. However, this was introduced without proper discussion, and as we do not want to impose anything we will remove the whole 1400 lines of code of the GTExample implementation from the GT-Inspector package as it did not belong there anyway, and we will make the new one available separately outside of Pharo. In this way, people can look at it if they want and we can have a discussion if desired. > > >>> Because this would be a significant departure from tests, we first wanted to get a more thorough documentation of the current state before opening the discussion to the community to see how this can fit in Pharo or at least in the ecosystem. I think we will have this ready in a draft form in a couple of days, and it would be great to have a critical discussion about it at ESUG. >> My plate is really full. I have a super long list of things that I want to discuss at ESUG. > Ok. > > Doru > > > >> Stef >>> Cheers, >>> Doru >>> >>> >>>> On Aug 18, 2016, at 1:32 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Tx serge >>>> >>>> - I think that we should agree on the pragma or way to express it. May be we can do the same as in Python and use a comment instead of a pragma. I prefer a pragma because we can query them easily. >>>> >>>> So any idea instead of >>>> <exp: value:> >>>> >>>> <expression: return: > >>>> >>>> withExtension: aString >>>> >>>> "Returns a new file reference with a different file extension" >>>> >>>> <exp: '/tmp/file.txt' asFileReference withExtension: 'log' >>>> >>>> value: '/tmp/file.log' asFileReference > >>>> >>>> ^ self withPath: (self path withExtension: aString) >>>> >>>> >>>> - then incrementally we can start taking on system for example FS and use it. >>>> >>>> Stef >>>> >>>> >>>> Le 18/8/16 Ã 11:51, Serge Stinckwich a Ã©crit : >>>>> On Thu, Aug 18, 2016 at 9:34 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>> Hi guys >>>>>> >>>>>> I'm fed up to get methods without comments and without little examples. In >>>>> +1 ! >>>>> We can setup a small group of people interested to build examples at ESUG. >>>>> >>>>>> FileSystem, I wrote most of the comments and I tried to add an obvious >>>>>> example: >>>>>> >>>>>> basenameWithIndicator >>>>>> "Returns the basename with the indicator appended, i.e. >>>>>> /foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo >>>>>> basenameWithIndicator is 'foo/'" >>>>>> >>>>>> ^ self basename , self indicator >>>>>> >>>>>> >>>>>> Now let us look at: >>>>>> >>>>>> withExtension: aString >>>>>> ^ self withPath: (self path withExtension: aString) >>>>>> >>>>>> >>>>>> Nice comment :( >>>>>> >>>>>> I would like to support PythonDoctest (yes we are not the only one to have >>>>>> ideas let us face is dear friends) >>>>> +1 >>>>> >>>>> https://en.wikipedia.org/wiki/Doctest >>>>> >>>>>> def multiply(a, b): >>>>>> """ >>>>>> >>> multiply(4, 3) >>>>>> 12 >>>>>> >>> multiply('a', 3) >>>>>> 'aaa' >>>>>> """ >>>>>> return a * b >>>>>> >>>>>> Because we can make sure that the comments are accurate. >>>>>> >>>>>> >>>>>> withExtension: aString >>>>>> >>>>>> "Returns a new file reference with a different file extension" >>>>>> >>>>>> <exp: '/tmp/file.txt' asFileReference withExtension: 'log' >>>>>> >>>>>> value: '/tmp/file.log' asFileReference > >>>>>> >>>>>> ^ self withPath: (self path withExtension: aString) >>>>>> >>>>>> >>>>>> It will help us to have a distinction between printOn: and displayString >>>>>> >>>>>> Typically >>>>>> >>>>>> '/tmp/file.txt' asFileReference withExtension: 'log' >>>>>> >>>>>> printString is bad >>>>>> >>>>>> since it returns File @ '/tmp/file.log' which is not an reexecutable >>>>>> expression >>>>>> >>>>>> >>>>>> >>>>>> So let me know what you think. >>>>>> - tell me that we have already test unit (yes the ones I wrote too) >>>>>> => they do not have the same purpose >>>>>> >>>>>> For me this is getting to be important. >>>>> Maybe a subset of Pharo could be defined as core with a kind of API >>>>> freeze, so we can spend some time >>>>> documenting the corresponding methods and classes. >>>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > >

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

> Hi > > Why not use <example> pragma in the way you propose for <examplar>? > Why we need two? Apparently from the old discussion, people like <example> to prompt and open the example when this is something visual. This is ok for me. In my proposal we can get the best of both worlds. - instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening. Stef > > 2016-08-18 14:38 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi > > In my projects I start to do the following: > > I create <examplar> class method that returns an prototypical > instance. > > I use such methods in my tests as fixture. > > Then I would like to have nautilus presenting to me the <examplar> > with a little triangle and when I press > > on them I get an inspector on them. > > This way I get the same behavior than with default <example> > methods that open an widget, image.... > > If we agree on that > > - I can take all the <example> and turn them if necessary into > examplar. > > - extend Nautilus to send an inspect to the result of examplar > tagged method. > > I think that we can achieve a lot in terms of discovery with such > simple changes. > > Stef > > PS: I reread the old thread and I think that this is a reasonable > approach that makes > > the pro instances (like me) and the pro examples showing some > things (like me) happy. > > >

Aug. 18, 2016

Re: [Pharo-dev] <example>/<examplar>

by Esteban Lorenzano

example is meant to be something executable from the browser (and with a visible result) while âexemplarâ will just provide a prototype. this is old discussion, sigh... Esteban > On 18 Aug 2016, at 16:25, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > Why not use <example> pragma in the way you propose for <examplar>? Why we need two? > > 2016-08-18 14:38 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > Hi > > In my projects I start to do the following: > > I create <examplar> class method that returns an prototypical instance. > > I use such methods in my tests as fixture. > > Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press > > on them I get an inspector on them. > > This way I get the same behavior than with default <example> methods that open an widget, image.... > > If we agree on that > > - I can take all the <example> and turn them if necessary into examplar. > > - extend Nautilus to send an inspect to the result of examplar tagged method. > > I think that we can achieve a lot in terms of discovery with such simple changes. > > Stef > > PS: I reread the old thread and I think that this is a reasonable approach that makes > > the pro instances (like me) and the pro examples showing some things (like me) happy. > > >

Aug. 18, 2016