March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by stepharo

I'm ok with examplar too. PS: From far it looks like a bikeshed discussion :) > Alex wrote: >> I agree with Doru. Just checked the image and it seems that there is already quite a number of methods with <example> annotation that behave exactly >the same behaviour described by Doru. > Yes - there are more for a simple reason: because Doru created them according to HIS OWN definition to solely return instances. > And they come in as GT extension methods. > > Would my opinion/points are more valid if we had more examples tagged <example> tags to mark all example methods? > >> So maybe we could continue having <example> to show how to create a valid instance of the class that have some >> value and can work? One benefit is that we could based on <example> show some usefull preview of the class in inspector. > The point is that we could do this preview with <exampleInstance> or <exemplar> as well! We do not lose anything! > > So with two different tags: > - <example> for general examples > - and <exemplar> <exampleInstance> for valid instances > > we would catch TWO FLIES INSTEAD OF JUST ONE: we would not be dependent on exampleXXX selector naming > to mark example methods as it is now also in Pharo 4 AND we could do the preview in the new GT tools!!! > > Also with <exampleInstance> or <exemplar> we would also make it more clear that it returns an instance > for a preview! > > In non-technical terms this would be a WIN-WIN for Tudor and me ;) > >> Assume having a MultistateButtonMorph with <example> pragma. You can inspect MultistateButtonMorph (class) and >> will get as preview morph instance of the button. > It is not that I do not understand this. I know that by providing instance examples this would also be > a step forward on the GT/tools side. > > I would not like to see only ONE step backward and only ONE forward when we can do TWO MOVES forward. > Is this so hard to understand? > > If Tudor agrees on either <examplar> <sample> or <exampleInstance> he will get a beer. > Should I buy you a beer as well to convince you? ;) > > Thx > T. > > > > > >

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by stepharo

torsten I'm confused. Did you use the <example> pragmas before? Because I was the one in favor to remove this ugly gt in front of gtExample Stef Le 25/3/15 17:32, Torsten Bergmann a Ã©crit : > Hi Tudor, > > >However, I think there is significantly more value in examples that do return > objects. > > Yet again: no doubt that they may be of value. This is not the point. > If they provide "more value" > than methods that do not return an instance depends on what you want > to achieve with them. > But please accept the fact that they are NOT THE ONLY WAYof giving > "examples" on system usage > to others. There are in fact others as well. > Regarding your script suggestion: > Examples and script have in common is that they can be executed - but > that does not > automagically makes them the same. An example is CONCEPTUALLY not the > same as a > script. > The purpose of creating a script is a different from the purpose of > creating an example. > A script is something I ran, an example is something that is > explicitly provided for others > to learn from it. > >Until now, nobody is really using the <example> except the code that > is packaged in GT > > So you state that I'm nobody. Sad that my code does not count... :( > > Is this really your argument that we now start counting and decide > upon the number of methods that use this > already? Do you really want the community to decide on that base in > the future? Then we would had to write > only ugly code because the ugly code outwighted the the number of > clean code in the past when we forked > from Squeak. > > Again: this discussion is not about number of usage, it is about > getting cleaner and about the > correct naming. > > The <example> tag as it was integrated from my side solves the problem > of not relying on exampleXXX for > tagging general code examples. You in parallel also used the same tag > name for something that is more > specific: an example method that returns an example instance/exemplar. > >Nevertheless, please, let's focus on the release that comes in a few days. > Especially because of the release in a few days I bring this topic up. > When we keep it that way people will > use it and we can hardly change it afterwards.Thats why I want a > solution now and not defer this simple > decision (it is nothing more) afterwards. > >we could remove the <example> pragma check from isExampleMethod > > Why should we? You yourself wrote in the issue tracker that it is > not good to only rely on > selector names starting with exampleXXX. > > >The word example is based on previous research. > Which say what? Academics is always right and in this context it now has to be like YOU stated? > Please do not always get to far from the basic issue itself. We do not discuss how valuable this is - > we know that already. > > BTW: I have a degree in software technologies as well and support the idea of using congrete > example objects. I agree with you in all the benefits, the underestimated power, etc. and would > like to see Pharo move forward not only there. The most underestimated power is in its > metaprogramming facilities. > > The term "Example" is very general and in the Smalltalk contextalready and often usedto provide > "example" methods. Some of them provide instances, others not. > You talk only about the first subset: the examples who provide concrete instances. > So we should name them accordingly: EXEMPLAR or EXAMPLEOBJECT in thecontext of OOP. > I still stay with my proposal, we should stay consistent and name/mark things what they are: > 1. general "examples" as <example> which solves the "not rely on > method names" issue > 2. and marking example method that are specifically returning an > example instance with > <exampleInstance> or <exemplar> or <sample> as Ben suggested > > If it is a effort/time problem of changing the methods providing such > example methods in the GT repo > I offer to do this change. > > As Pharo is not only YOURS and not only MINE I would like to see more > opinions or proposals from > others. ;) > > Thanks > T. >

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by stepharo

+1 release release release :) Le 25/3/15 14:33, Tudor Girba a Ã©crit : > The word example is based on previous research. For example: > - Modeling Examples to Test and Understand Software, Markus Gaelli, > PhD Thesis, 2006 > http://scg.unibe.ch/archive/phd/gaelli-phd.pdf > - JExample: Exploiting Dependencies Between Tests to Improve Defect > Localization, Kuhn etal, 2008 > http://scg.unibe.ch/archive/papers/Kuhn08aJExample.pdf > (Phexample is also available on SmalltalkHub) > > The idea is that you learn from concrete (examples) to abstract, and > objects are but examples of classes. I think this is a powerful > concept that is underutilized and I also think that we will see more > of it in the future if we support it a first class concept in our tools. > > Nevertheless, please, let's focus on the release that comes in a few days. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 1:40 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > > On Wed, Mar 25, 2015 at 7:34 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi Torsten, > > I think there can be some value in having example code that > shows things beyond just returning an object. However, I think > there is significantly more value in examples that do return > objects. That is why I would want to have example for the more > valuable piece, and to eliminate confusions I would not even > call the others example, but another word, like script: > > exampleThatReturnsOneObject > <example> > ^ ... > > snippetThatDoesOrShowsSomething > <script> / <exampleScript> / <exampleCode> > ^ ... > > I still think that <script> is enough. The goal of these > methods is to get the person to run them and observe the side > effect, without reusing the result. That is what scripts > typically do. It should be enough. As for the example* > methods, most of them can be nicely decomposed into an > <example> and possibly a <script>. It would be enough. > > > > I'm not sure of the correct solution, but this semantic doesn't > feel right to me. I've never thought I needed to inspect the > result of an example. An example "does something", like a doIt. I > want it to "show" me something. If the aim of the example was to > give an object to Inspect, then it should explicitly open an > Inspector. > > To me a script is definitely NOT an example. A script is > something that provides convenience for performing system > maintenance. For example, it might change system state by > resetting a cache. > > The word that I feel best applies to Doru's need is <sample>, to > return a fully initialised sample instance that you can play with > in the Inspector. When you double-click a method so tagged you > can think of it as "give me a sample" of yourself. > > cheers -ben > > > > Here is more reasons why I would not change <example> now. > Until now, nobody is really using the <example> except the > code that is packaged in GT. The only problematic part is: > > TigerDemo>> runDemo > <example> > ^ self new runDemo > > But this one does not even fit your definition of an example > of code. It's merely a way to trigger the running of the > instance. It so happens that the class is an example for > something else, but this code is not an example. It's a > script. So, it should be: > TigerDemo>> runDemo > <script> > ^ self new runDemo > (this solution is already committed in the Athens repo) > > This would not even be a new interpretation. In the image, > there already exists scripts that trigger an example class: > DynamicSpecExample>> openOnNil > <script: '(DynamicSpecExample object: nil) open'> > ... > ui openWithSpecLayout: layout. > > Btw, the <example> check in the > CompiledMethod>>isExampleMethod was added after the discussion > about introducing <example> and this tended to unify the > meaning with the current example* selectors. We did not catch > this distinction at that time, but it is clearly a mismatch. > So, the actual intention of <example> did not change at all, > but isExampleMethod enforces a new contract on the original one. > > So, really, let's not make a larger thing than we have to out > of this. We really have *one* problem that is not even a > problem. The solution from Athens should be fine now, and we > could remove the <example> pragma check from isExampleMethod > for now. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 9:57 AM, Torsten Bergmann > <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > Hi Tudor, > > stay serious: the methods you are talking about were > introduced as GT extension following YOUR definition of > an example. > > We could argue what/who was first with <example>, who > discussed/patented it first, who has to change the most > code now ... but would it move us forward? We do not need > a long discussion, we need a solution. > > The situation is that we have a conflict in the usage of > <example> Pragma: > > We wanted a way to find out the examples given in > methods (often hidden in the image and external packages) > and also remove the limitation that they have to start > with exampleXXX. > So I took action to be able to explicitly mark methods > that are intended by the author as > an "example" by using the <example> pragma. This was > integrated in Pharo 4 and is also in use, not in > the image but in loadable packages already. My > definition of an example is "a general code example". > > You had another discussion in the context of GT Tools > about renaming the <gtExample> into > <example> and also meanwhile took action to use use > <example>. > > But you also put the ADDITIONAL meaning behind the > pragma that methods marked with <example> > should always return an initialized object. > > And this last part is the only part where our point of > views collide. There is no need to explain from your side > that it is often valuable to have such example methods > that return initialized instance. One can use > them to construct other initialized instances, ... > > Anything I say is that not all "examples" and "example > methods" are providing such example instances. > So we can not (and should not) ignore the fact that not > all methods intended by the author as "examples" > follow this additional definition/requirement. > > So the only difference in our point of view is that you > want to mark all of them equally with > <example> and assume that all of them return an instance > of the same class while I will not > because not all examples do that. Some of them are just > example methods to demonstrate how > to use the class or combine objects or do some action > where the return value of the method is > uninteresting. > > So in your definition of <example> pragma you talk about > the need for marking methods > with "example instances" while I talk about more general > examples (examples of code) that > can but do not necessarily have to provide such > initialized instances. > > > So my proposal is simple and should satisfy both needs: > ======================================================= > > 1. The <example> Pragma can used to mark a method as an > "example" method. An example > is a method that is intended as an "example of code": > > tryThisOut > <example> > > Transcript show: 'An example on how to write to > the transcript' > > > 2. The <exampleInstance> Pragma can be used to mark > methods that return an > an example instance: > > anInstanceA > <exampleInstance> > > ^$A > > > This will solve the issue easily and it will be more clear > as THE INTENTION OF THE PRAGMA in > both cases FITS WITH THE NAME. Also a tool can query for > one or both pragmas and decide if > if it wants to inspect/display the result after performing > the method or just run it. > > So this is my proposal to satisfy both POV's. You can > argue agains it but not without > making another proposal that satisfies both needs. > > Thanks > T. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by stepharo

Hi ben in fact having an example and inspecting is really good. I would like to have all the classes having at least one (for the non abstract ones) because we could make sure that they run use them for cheap type inferences and a lot more. Stef Le 25/3/15 13:40, Ben Coman a Ã©crit : > > > On Wed, Mar 25, 2015 at 7:34 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi Torsten, > > I think there can be some value in having example code that shows > things beyond just returning an object. However, I think there is > significantly more value in examples that do return objects. That > is why I would want to have example for the more valuable piece, > and to eliminate confusions I would not even call the others > example, but another word, like script: > > exampleThatReturnsOneObject > <example> > ^ ... > > snippetThatDoesOrShowsSomething > <script> / <exampleScript> / <exampleCode> > ^ ... > > I still think that <script> is enough. The goal of these methods > is to get the person to run them and observe the side effect, > without reusing the result. That is what scripts typically do. It > should be enough. As for the example* methods, most of them can be > nicely decomposed into an <example> and possibly a <script>. It > would be enough. > > > > I'm not sure of the correct solution, but this semantic doesn't feel > right to me. I've never thought I needed to inspect the result of an > example. An example "does something", like a doIt. I want it to > "show" me something. If the aim of the example was to give an object > to Inspect, then it should explicitly open an Inspector. > > To me a script is definitely NOT an example. A script is something > that provides convenience for performing system maintenance. For > example, it might change system state by resetting a cache. > > The word that I feel best applies to Doru's need is <sample>, to > return a fully initialised sample instance that you can play with in > the Inspector. When you double-click a method so tagged you can think > of it as "give me a sample" of yourself. > > cheers -ben > > > > Here is more reasons why I would not change <example> now. Until > now, nobody is really using the <example> except the code that is > packaged in GT. The only problematic part is: > > TigerDemo>> runDemo > <example> > ^ self new runDemo > > But this one does not even fit your definition of an example of > code. It's merely a way to trigger the running of the instance. It > so happens that the class is an example for something else, but > this code is not an example. It's a script. So, it should be: > TigerDemo>> runDemo > <script> > ^ self new runDemo > (this solution is already committed in the Athens repo) > > This would not even be a new interpretation. In the image, there > already exists scripts that trigger an example class: > DynamicSpecExample>> openOnNil > <script: '(DynamicSpecExample object: nil) open'> > ... > ui openWithSpecLayout: layout. > > Btw, the <example> check in the CompiledMethod>>isExampleMethod > was added after the discussion about introducing <example> and > this tended to unify the meaning with the current example* > selectors. We did not catch this distinction at that time, but it > is clearly a mismatch. So, the actual intention of <example> did > not change at all, but isExampleMethod enforces a new contract on > the original one. > > So, really, let's not make a larger thing than we have to out of > this. We really have *one* problem that is not even a problem. The > solution from Athens should be fine now, and we could remove the > <example> pragma check from isExampleMethod for now. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 9:57 AM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Hi Tudor, > > stay serious: the methods you are talking about were > introduced as GT extension following YOUR definition of > an example. > > We could argue what/who was first with <example>, who > discussed/patented it first, who has to change the most > code now ... but would it move us forward? We do not need a > long discussion, we need a solution. > > The situation is that we have a conflict in the usage of > <example> Pragma: > > We wanted a way to find out the examples given in methods > (often hidden in the image and external packages) > and also remove the limitation that they have to start with > exampleXXX. > So I took action to be able to explicitly mark methods that > are intended by the author as > an "example" by using the <example> pragma. This was > integrated in Pharo 4 and is also in use, not in > the image but in loadable packages already. My definition > of an example is "a general code example". > > You had another discussion in the context of GT Tools about > renaming the <gtExample> into > <example> and also meanwhile took action to use use <example>. > > But you also put the ADDITIONAL meaning behind the pragma > that methods marked with <example> > should always return an initialized object. > > And this last part is the only part where our point of views > collide. There is no need to explain from your side > that it is often valuable to have such example methods that > return initialized instance. One can use > them to construct other initialized instances, ... > > Anything I say is that not all "examples" and "example > methods" are providing such example instances. > So we can not (and should not) ignore the fact that not all > methods intended by the author as "examples" > follow this additional definition/requirement. > > So the only difference in our point of view is that you want > to mark all of them equally with > <example> and assume that all of them return an instance of > the same class while I will not > because not all examples do that. Some of them are just > example methods to demonstrate how > to use the class or combine objects or do some action where > the return value of the method is > uninteresting. > > So in your definition of <example> pragma you talk about the > need for marking methods > with "example instances" while I talk about more general > examples (examples of code) that > can but do not necessarily have to provide such initialized > instances. > > > So my proposal is simple and should satisfy both needs: > ======================================================= > > 1. The <example> Pragma can used to mark a method as an > "example" method. An example > is a method that is intended as an "example of code": > > tryThisOut > <example> > > Transcript show: 'An example on how to write to the > transcript' > > > 2. The <exampleInstance> Pragma can be used to mark methods > that return an > an example instance: > > anInstanceA > <exampleInstance> > > ^$A > > > This will solve the issue easily and it will be more clear as > THE INTENTION OF THE PRAGMA in > both cases FITS WITH THE NAME. Also a tool can query for one > or both pragmas and decide if > if it wants to inspect/display the result after performing the > method or just run it. > > So this is my proposal to satisfy both POV's. You can argue > agains it but not without > making another proposal that satisfies both needs. > > Thanks > T. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

March 25, 2015

Re: [Pharo-dev] String>>howManyMatch: Bug or feature ?

by stepharo

Hi noury > What is misleading is that the howManyMatch: is in String. > I believe it should be moved up to SequencableCollection Open a bug entry :) > > Noury >

March 25, 2015

Re: [Pharo-dev] could the size of Playground be reduced a bit

by stepharo

:) this is why I refrained to ask before but yes this is important. Le 25/3/15 20:05, Peter UhnÃ¡k a Ã©crit : > Â±1 > > The problem is that it is not only playground, but also an inspector. > > While I would like the window smaller in both dimensions (no script is > that wide), it would sort of break "do it and go". > One idea might be to increase it to the current size only when "do it > and go" is executed (and the inspector is not opened yet). > > Because otherwise users of it would have to resize it manually very > often - if it is the size of the original Workspace, the inspector is > utterly useless. > > Peter

March 25, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by stepharo

Hi Alain thierry did not look at Bloc :) We see it :) Stef Le 24/3/15 16:13, Alain Plantec via Pharo-dev a Ã©crit :

March 25, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by stepharo

> > One of the problem is that the Morphic replacement will probably be > less than Morphic was (or was intended to be) :( you mean less messy Surely. I think that you did not look at Bloc because we have already a lot there and much nicer. > > You'll probably tell me that for the kind of work we're doing in UI > with Pharo, we don't need the power of Morphic and I'd agree with you. > > Still, I will miss the demise of Morphic. > > Thierry

March 25, 2015

Re: [Pharo-dev] GLMBrick whats next?

by stepharo

> > All in all, you should see Brick as a pragmatic intermediary step > towards removing Morph. I agree that it can be better (what cannot > be), but I disagree we should discard GT because of it. > > > I did not say "discard GT" . Brick is in the image, but I don't want > to have it in the > core image *as another UI-library* next to what we already have - > without cleaning that up. Yes I understand the feel. This is why I'm juggling between Bloc and improving Morphic slowly too slowly. But cleaning is tedious. > You know the questions on the mailing list about what framework to use > for creating an application:pure Morphic/Polymorph/Spec/Glamour, > and yes I am sure people will come and ask "hey how can I create such > cool looking application like spotter". > It is already difficult for new people to step in, and get an idea how > to work in pharo, or find information about the different frameworks. I agree I would like to remove some :) > > Nicolai > > > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

March 25, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Peter UhnÃ¡k

> > - aaef > According to this comment it seems to be Max Leske. https://pharo.fogbugz.com/f/cases/14165/ObsoleteTest-testFixObsoleteSharedP…

March 25, 2015