June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Ben Coman

On Tue, Jun 23, 2015 at 12:59 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Jun 22, 2015 at 11:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Peter, >> >> there was no agreement - so we rolled back for Pharo 4 to discuss/decide for Pharo 5. >> >> I communicated already how I would solve it to get IMHO a consistent and >> easy understandable solution: >> >> 1. executable example >> ===================== >> We talk about executable code here: an "example" in the traditional Smalltalk sense >> means ONLY a runnable piece of code to demonstrate something. Since a long time and not only in Pharo this >> is typically done in methods with prefix "example". It is important to note that these methods COULD BUT >> MUST NOT RETURN an instance. Usually such a method is only there to demonstrate code. >> >> These methods with the "example" in the name are currently honored by Nautilus with the >> clickable icon. See SystemProgressMorph>>exampleChangeLabel or others. >> >> => To not be limited to the prefix in the method name I proposed to be able >> to additionally use the <example> pragma to mark example methods. >> This way you can choose the method name freely to give an example to others >> on how to use them. >> >> 2. returning examples >> ===================== >> While some example methods just demo code and code usage (like "Job example" or "BorderedMorph exampleGradient") >> a subset of them directly return an instance of the method defining class (like LabelMorph>>example). >> >> The idea of the GT Tools is to call these methods and display the return value as inspectable "instances" in the tools, >> so for instance if you inspect class VirtualMachine or Character you get a tab entitled "E.g." where you can click on >> these sample instances. >> >> GT and (because GT )now latest Pharo currently still uses "gtExample" method prefix or <gtExample> pragma to mark such methods and there >> is also to wish to remove the "gt" prefix. But with this we would have a clash with the other "exampleXXX" usage. >> >> => I would propose to mark the code examples that return an instance with an <exemplar> method. >> >> According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." >> Urban dictionary defines <exemplar> as "a typical or standard model or specimen" >> >> So I proposed and still propose >> - "exampleXXX" prefixed methods and <example> pragma for traditional examples as used in other Smalltalks and Pharo before >> - "exemplarXXX" prefixed methods and <exemplar> pragma (mark code that return an instance always) for the future inspection >> of exemplars in the tools > > Sorry. I'm going to have to play the native english speaker card here. > I could live with it, but "examplar" just doesn't sound right for this. > > * Dictionary meanings are useful, but meaning can be skewed without > contemporary context. > * Dictionaries cover a lot of corner cases, some inherited from a > hundred years ago, and language evolves. They may remain technically > correct and understandable, but not sound "right". > * I've probably only seen the word used couple of times in my life, > never in this context. > * I notice its also a German word. I expect its hard to disassociate > from its common German usage. Sorry, after English stole it from > German, it probably corrupted it. > * Check its synonyms: "epitome, perfect example, shining example, > model, paragon, ideal...". This is its contemporary meaning and I > guess the returned sample won't be expected to be the "best most > perfect sample". It will just be "some sample" or a "basic sample" > for you to inspect. > * "Sample" is 2 characters shorter than "Exemplar" to fit in label of > the GT tab. I presume its useful to match the tab label with the > pragma. > > cheers -ben btw, I bumped into an interesting resource (which incidentally supports my case but is probably generally useful)... http://sentence.yourdictionary.com/exemplar

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Ben Coman

On Mon, Jun 22, 2015 at 11:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Peter, > > there was no agreement - so we rolled back for Pharo 4 to discuss/decide for Pharo 5. > > I communicated already how I would solve it to get IMHO a consistent and > easy understandable solution: > > 1. executable example > ===================== > We talk about executable code here: an "example" in the traditional Smalltalk sense > means ONLY a runnable piece of code to demonstrate something. Since a long time and not only in Pharo this > is typically done in methods with prefix "example". It is important to note that these methods COULD BUT > MUST NOT RETURN an instance. Usually such a method is only there to demonstrate code. > > These methods with the "example" in the name are currently honored by Nautilus with the > clickable icon. See SystemProgressMorph>>exampleChangeLabel or others. > > => To not be limited to the prefix in the method name I proposed to be able > to additionally use the <example> pragma to mark example methods. > This way you can choose the method name freely to give an example to others > on how to use them. > > 2. returning examples > ===================== > While some example methods just demo code and code usage (like "Job example" or "BorderedMorph exampleGradient") > a subset of them directly return an instance of the method defining class (like LabelMorph>>example). > > The idea of the GT Tools is to call these methods and display the return value as inspectable "instances" in the tools, > so for instance if you inspect class VirtualMachine or Character you get a tab entitled "E.g." where you can click on > these sample instances. > > GT and (because GT )now latest Pharo currently still uses "gtExample" method prefix or <gtExample> pragma to mark such methods and there > is also to wish to remove the "gt" prefix. But with this we would have a clash with the other "exampleXXX" usage. > > => I would propose to mark the code examples that return an instance with an <exemplar> method. > > According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." > Urban dictionary defines <exemplar> as "a typical or standard model or specimen" > > So I proposed and still propose > - "exampleXXX" prefixed methods and <example> pragma for traditional examples as used in other Smalltalks and Pharo before > - "exemplarXXX" prefixed methods and <exemplar> pragma (mark code that return an instance always) for the future inspection > of exemplars in the tools Sorry. I'm going to have to play the native english speaker card here. I could live with it, but "examplar" just doesn't sound right for this. * Dictionary meanings are useful, but meaning can be skewed without contemporary context. * Dictionaries cover a lot of corner cases, some inherited from a hundred years ago, and language evolves. They may remain technically correct and understandable, but not sound "right". * I've probably only seen the word used couple of times in my life, never in this context. * I notice its also a German word. I expect its hard to disassociate from its common German usage. Sorry, after English stole it from German, it probably corrupted it. * Check its synonyms: "epitome, perfect example, shining example, model, paragon, ideal...". This is its contemporary meaning and I guess the returned sample won't be expected to be the "best most perfect sample". It will just be "some sample" or a "basic sample" for you to inspect. * "Sample" is 2 characters shorter than "Exemplar" to fit in label of the GT tab. I presume its useful to match the tab label with the pragma. cheers -ben

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Tudor Girba

Hi, We are working on a more elaborate model for examples, but we need a bit more time to get to a rounder solution. Cheers, Doru On Mon, Jun 22, 2015 at 12:49 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-06-22 12:03 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> there was a long discussion about the meaning of example* methods and >> <example> pragmas, however I do not know what was the final resolution. >> >> Basically I am interested in two use-cases >> >> 1. executable example (the one where Nautilus shows nice play icon) >> This is as I understand only through example* naming (on class-side). >> > > Yes, but I would like to use a pragma again and don't rely naming > convention, we just wasn't able to agree on one. > > >> >> 2. returning examples (example that returns some value that I can reuse) >> Is this what <example> pragma is for? How would I go about naming it >> considering that having play icon there would be counter-productive (user >> would be clicking on it and nothing would happen). >> > > Inspector and spotter use gtExample* names in addition to an <gtExample> > pragma. > <gtExample> -> for finding those methods > gtExample*name -> for not getting the play icon. > > This is less than perfect. > > >> >> Thanks, >> Peter >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 22, 2015

Proposed fix for RFB. Please review

by Christer Assmundsson

Hi all, I have fixed (?) an issue in RFB server that seems to solve a problem I had with initiating a session. After the fix it works at least with UltraVnc. Still not with tightVnc though, has to be some other problem with that. As I'm not very experienced with pharo I'd like to have somebody elses eyes on it before checking it in to SmaltalkHub (if I even have access to that). Quality status on the fix is "works on my machine" At the start of RFBSession>> sendFramebufferUpdate | updateRegion nRects sendCursor sendPosition | preferredEncoding ifNil: [^self]. "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< new code" self beginUpdate. ... Reasoning: Until we know what encoding to use, we can't send updates. Just discard them. It will be picked up later. Technical: Futher down in the method we call "countRects" which is not set until we set encoding, and therefore the method fails with DNU. Please let me know how I should proceed. Best regards, Christer

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Damien Cassou

Ben Coman <btc(a)openinworld.com> writes: > I'll revisit my previous suggestion. In real life... > > * a "sample" is a real object you can hold. You ask a supplier to > "send you a sample" of their product so you can inspect it before you > buy lots. In an industrial factory, you "take a sample" to take an > item from the process stream to the lab to analyse. Both of these are > real objects you can hold. In addition, Digital Signal Processing > does sampling, it doesn't do exampling. > > * an "example" is one step removed from real life objects. The maths > teacher works through an example. Someone's behaviour can set a good > example. A programming script can provide an example of how to do > something. People say "for example, how about my hypothetical** > situation". None of these refer to a real object. Now you can use > "example" to refer to real objects, but usually second hand when you > are describing a general characteristic. It doesn't have the same > concrete semantic of a real object as "sample". I like this vocabulary. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

June 22, 2015

<example> pragmas and example* methods use-cases

by Torsten Bergmann

Hi Peter, there was no agreement - so we rolled back for Pharo 4 to discuss/decide for Pharo 5. I communicated already how I would solve it to get IMHO a consistent and easy understandable solution: 1. executable example ===================== We talk about executable code here: an "example" in the traditional Smalltalk sense means ONLY a runnable piece of code to demonstrate something. Since a long time and not only in Pharo this is typically done in methods with prefix "example". It is important to note that these methods COULD BUT MUST NOT RETURN an instance. Usually such a method is only there to demonstrate code. These methods with the "example" in the name are currently honored by Nautilus with the clickable icon. See SystemProgressMorph>>exampleChangeLabel or others. => To not be limited to the prefix in the method name I proposed to be able to additionally use the <example> pragma to mark example methods. This way you can choose the method name freely to give an example to others on how to use them. 2. returning examples ===================== While some example methods just demo code and code usage (like "Job example" or "BorderedMorph exampleGradient") a subset of them directly return an instance of the method defining class (like LabelMorph>>example). The idea of the GT Tools is to call these methods and display the return value as inspectable "instances" in the tools, so for instance if you inspect class VirtualMachine or Character you get a tab entitled "E.g." where you can click on these sample instances. GT and (because GT )now latest Pharo currently still uses "gtExample" method prefix or <gtExample> pragma to mark such methods and there is also to wish to remove the "gt" prefix. But with this we would have a clash with the other "exampleXXX" usage. => I would propose to mark the code examples that return an instance with an <exemplar> method. According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." Urban dictionary defines <exemplar> as "a typical or standard model or specimen" So I proposed and still propose - "exampleXXX" prefixed methods and <example> pragma for traditional examples as used in other Smalltalks and Pharo before - "exemplarXXX" prefixed methods and <exemplar> pragma (mark code that return an instance always) for the future inspection of exemplars in the tools Thanks Torsten

June 22, 2015

Moose

by abdelghani ALIDRA

Hi everybody, when working with the FAMIX meta model, one must implement the previous, next, from and to methods for each class extending FAMIXAssosiation. What is the diffence between previous/from and next/to?if I make MyFamixClass>>from^previousthe same information is displayed twice in the Moose panel (because both methods are annotated with the MSEProperty in the superclass)Who can one avoid that? Regards Abdelghani

June 22, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Alexandre Bergel

This is true, however it has to be used properly. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 18, 2015, at 4:13 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > For example Roassal's RTElement exposes a dictionary to which I can add random stuff, however from my experience that gets messy fast (since I end up just manipulating symbols in structural/procedural code).

June 22, 2015

Re: [Pharo-users] Any YAML parser?

by Serge Stinckwich

http://smalltalkhub.com/#!/~JanKurs/PetitParser/packages/PetitYAML ? On Sat, Jun 20, 2015 at 4:10 PM, Julien Delplanque <julien(a)tamere.eu> wrote: > Hi everybody, > > I googled a bit for a YAML parser in Pharo but I didn't found anything. > > Does anybody wrote a YAML parser for Pharo? > > Regards, > Julien > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 22, 2015

Re: [Pharo-users] Environment-independent styler?

by Yuriy Tymchuk

My 2 cents: we need a diff model. Because for now there is TextDiffBuilder which âdiffsâ text by lines i.e. bad granularity, and there is a DiffMorph that produces nice diffs but itâs hard to reuse it in other contexts. Uko > On 22 Jun 2015, at 15:18, Martin Dias <tinchodias(a)gmail.com> wrote: > > After debugging a bit and discovering the mess around... I think the best decision is to first migrate the DiffMorph to the new text widget, and then see... > > MartÃn > > > > > On Mon, Jun 22, 2015 at 9:53 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2015-06-22 9:11 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 17 Jun 2015, at 18:54, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: > > > > Hello, > > > > Suppose that you want to show the diff between the source code of two methods. In the case that both methods are in the same class, and that such class is present in the system, then no problem: In a DiffModel, one can set a context to the smalltalk syntax styler and get a nice output. > > > > DiffModel new > > leftText: (Point >> #x) sourceCode; > > rightText: (Point >> #y) sourceCode; > > contextClass: Point; > > openWithSpec. > > > > <Screen Shot 2015-06-17 at 18.33.22.png> > > > > But what happens in the case that the class does not exist in the system? > > > > If one doesn't set any context to the styler, then the string will be shown all in black, which is not nice. A partial solution could be to set Object as a context, then the styler will color the code, but instance variables are in red: > > > > DiffModel new > > leftText: (Point >> #x) sourceCode; > > rightText: (Point >> #y) sourceCode; > > contextClass: Object; > > openWithSpec. > > > > <Screen Shot 2015-06-17 at 18.33.27.png> > > > > Which is also not nice. In my opinion, there should be a styler that just colors the code following the syntax, without checking if the variables or classes are present in the system. It would be an environment-independent styler. > > > > What do you recommend to implement this? I guess it should be easy to subclass SHTextStylerST80 and override some methods to do not check anything in the environment. > > > > What's your opinion? > > > > Right now we have the problem that we have 3 Stylersâ¦ (for the old text model one based on Shout, one AST, and one for TxText based on the AST. Ah, and Rubric subclasses the > shout one, too. Which means 4. > > One question is: could a styler fall back onto a being environment independent as soon as the environment is not set? > > Yes. With a bit of ternary logic which says that symbols are in three states: defined, undefined and unknown. First two require a context; third one applies if you don't have a context. > > Thierry >

June 22, 2015