- Pharo-dev - lists.pharo.org

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

by Nicolai Hess

2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > If you attache a certain action such as "result openInWorldâ to a pragma > such as <interactiveExample>, it implies that when I have a different > resulting object that should be spawned with a different message (for > example, a Roassal view should be opened with "result open"), I should use > a different pragma. That will quickly lead to an explosion of pragmas. > > > > Cheers, > > Doru > > > > I would not attach any action to a pragma, but instead let the different > tools decide what to do. The pragma is just used to differentiate what the > method execution returns: > > > > <example> or <exampleCode> - a code or script example - don't care about > the returned object. A tool like Nautilus just provides a way to execute > the code ("play" - icon) nothing more. > > <script> - a code snippet for a more general use case (example or class > initialization). A tool like Nautilus just provices a way to execute the > code and for example, like it is now, show a growl notification with the > result > > <sample> or <sampleInstance> - code to create an instance. A tool like > Nautilus can just provide a way to execute the code and open an inspector > on the result. (The inspector itself can react differently for > > a morph -> inspectors morph tab > > a roassal view -> inspector tab for roassal view > > â¦. > > The inspector has the instance and can react to it. But, how can Nautilus > know what to do without the instance? For that you would need static > information. > by the pragma name ? <example> -> execute <sample> -> execute and inspect <script> -> execute and show a growl information with the returned value. > > Doru > > > > I am for <example> for the first case, <exampleCode> is good as well, > but I like <example> more, and it is not uncommon to call some "code > examples" just "examples" > > <sample> for a method that creates "the interesting object", > <sampleInstance> is fine as well. > > > > > > > > > > > > > > > On Aug 19, 2016, at 10:32 AM, stepharo <stepharo(a)free.fr> wrote: > > > > > > > > > > > > Le 19/8/16 Ã 10:18, Tudor Girba a Ã©crit : > > >> Hi, > > >> > > >> I strongly believe that the interaction should not be hardcoded in > the example pragma name. That is because you will want all sorts of > interactions once you go beyond the surface. For example, a Roassal > visualization, a Bloc element, and a Morph are all interesting from an > interaction point of view, but there are different ways to open them (and > having it polymorphic does not quite make sense). > > > > > > sorry but I cannot understand what you mean. > > > You suggest to use example > > > but not to have it polymorphic? > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >> > > >>> On Aug 19, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: > > >>> > > >>> Let me know. I do not care about examplar or sample. > > >>> > > >>> Let us pick one that works well. I thought about prototype but this > is too close to prototype based language. > > >>> > > >>> So we could get > > >>> > > >>> <interactiveExample> > > >>> > > >>> <sample>/<instance>/ > > >>> > > >>> > > >>> Le 19/8/16 Ã 01:59, Ben Coman a Ã©crit : > > >>>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo > > >>>> <emaringolo(a)gmail.com> wrote: > > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > > >>>>>> 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? > > >>>>> Semantically it is correct, but for me, also maybe by not being a > > >>>>> native English speaker, sounds weird. > > >>>>> > > >>>>> I'd use something like "sample". However I'll be fine with whatever > > >>>>> you choose. But I'd choose something that doesn't sound weird to > > >>>>> native English readers, we already have some cases of that. > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> > > >>>>> Esteban A. Maringolo > > >>>>> > > >>>> In the previous thread I argued against <exemplar> and for <sample>, > > >>>> but I'm not so strong in my conviction to push it again :). The > > >>>> former is a little exotic, but is sufficient -- and perhaps its > useful > > >>>> <example> and <exemplar> sound similar with just a minor difference > at > > >>>> the end. > > >>>> > > >>>> P.S. In terms of discover-ability about this difference, a passing > > >>>> thought is it would be nice for newcomers to be able to hover over a > > >>>> code like a pragma and get a tool tip popup. > > >>>> > > >>>> cheers -ben > > >>>> > > >>>> > > >>> > > >> -- > > >> www.tudorgirba.com > > >> www.feenk.com > > >> > > >> "Next time you see your life passing by, say 'hi' and get to know > her." > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "It's not how it is, it is how we see it." > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > >

Aug. 19, 2016

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

by Tudor Girba

Hi, > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > If you attache a certain action such as "result openInWorldâ to a pragma such as <interactiveExample>, it implies that when I have a different resulting object that should be spawned with a different message (for example, a Roassal view should be opened with "result open"), I should use a different pragma. That will quickly lead to an explosion of pragmas. > > Cheers, > Doru > > I would not attach any action to a pragma, but instead let the different tools decide what to do. The pragma is just used to differentiate what the method execution returns: > > <example> or <exampleCode> - a code or script example - don't care about the returned object. A tool like Nautilus just provides a way to execute the code ("play" - icon) nothing more. > <script> - a code snippet for a more general use case (example or class initialization). A tool like Nautilus just provices a way to execute the code and for example, like it is now, show a growl notification with the result > <sample> or <sampleInstance> - code to create an instance. A tool like Nautilus can just provide a way to execute the code and open an inspector on the result. (The inspector itself can react differently for > a morph -> inspectors morph tab > a roassal view -> inspector tab for roassal view > â¦. The inspector has the instance and can react to it. But, how can Nautilus know what to do without the instance? For that you would need static information. Doru > I am for <example> for the first case, <exampleCode> is good as well, but I like <example> more, and it is not uncommon to call some "code examples" just "examples" > <sample> for a method that creates "the interesting object", <sampleInstance> is fine as well. > > > > > > > > On Aug 19, 2016, at 10:32 AM, stepharo <stepharo(a)free.fr> wrote: > > > > > > > > Le 19/8/16 Ã 10:18, Tudor Girba a Ã©crit : > >> Hi, > >> > >> I strongly believe that the interaction should not be hardcoded in the example pragma name. That is because you will want all sorts of interactions once you go beyond the surface. For example, a Roassal visualization, a Bloc element, and a Morph are all interesting from an interaction point of view, but there are different ways to open them (and having it polymorphic does not quite make sense). > > > > sorry but I cannot understand what you mean. > > You suggest to use example > > but not to have it polymorphic? > >> > >> Cheers, > >> Doru > >> > >> > >> > >>> On Aug 19, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Let me know. I do not care about examplar or sample. > >>> > >>> Let us pick one that works well. I thought about prototype but this is too close to prototype based language. > >>> > >>> So we could get > >>> > >>> <interactiveExample> > >>> > >>> <sample>/<instance>/ > >>> > >>> > >>> Le 19/8/16 Ã 01:59, Ben Coman a Ã©crit : > >>>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo > >>>> <emaringolo(a)gmail.com> wrote: > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > >>>>>> 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? > >>>>> Semantically it is correct, but for me, also maybe by not being a > >>>>> native English speaker, sounds weird. > >>>>> > >>>>> I'd use something like "sample". However I'll be fine with whatever > >>>>> you choose. But I'd choose something that doesn't sound weird to > >>>>> native English readers, we already have some cases of that. > >>>>> > >>>>> Regards, > >>>>> > >>>>> > >>>>> Esteban A. Maringolo > >>>>> > >>>> In the previous thread I argued against <exemplar> and for <sample>, > >>>> but I'm not so strong in my conviction to push it again :). The > >>>> former is a little exotic, but is sufficient -- and perhaps its useful > >>>> <example> and <exemplar> sound similar with just a minor difference at > >>>> the end. > >>>> > >>>> P.S. In terms of discover-ability about this difference, a passing > >>>> thought is it would be nice for newcomers to be able to hover over a > >>>> code like a pragma and get a tool tip popup. > >>>> > >>>> cheers -ben > >>>> > >>>> > >>> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Next time you see your life passing by, say 'hi' and get to know her." > >> > >> > >> > >> > >> > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Aug. 19, 2016

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

by Nicolai Hess

2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > If you attache a certain action such as "result openInWorldâ to a pragma > such as <interactiveExample>, it implies that when I have a different > resulting object that should be spawned with a different message (for > example, a Roassal view should be opened with "result open"), I should use > a different pragma. That will quickly lead to an explosion of pragmas. > > Cheers, > Doru > I would not attach any action to a pragma, but instead let the different tools decide what to do. The pragma is just used to differentiate what the method execution returns: <example> or <exampleCode> - a code or script example - don't care about the returned object. A tool like Nautilus just provides a way to execute the code ("play" - icon) nothing more. <script> - a code snippet for a more general use case (example or class initialization). A tool like Nautilus just provices a way to execute the code and for example, like it is now, show a growl notification with the result <sample> or <sampleInstance> - code to create an instance. A tool like Nautilus can just provide a way to execute the code and open an inspector on the result. (The inspector itself can react differently for a morph -> inspectors morph tab a roassal view -> inspector tab for roassal view .... I am for <example> for the first case, <exampleCode> is good as well, but I like <example> more, and it is not uncommon to call some "code examples" just "examples" <sample> for a method that creates "the interesting object", <sampleInstance> is fine as well. > > > > > On Aug 19, 2016, at 10:32 AM, stepharo <stepharo(a)free.fr> wrote: > > > > > > > > Le 19/8/16 Ã 10:18, Tudor Girba a Ã©crit : > >> Hi, > >> > >> I strongly believe that the interaction should not be hardcoded in the > example pragma name. That is because you will want all sorts of > interactions once you go beyond the surface. For example, a Roassal > visualization, a Bloc element, and a Morph are all interesting from an > interaction point of view, but there are different ways to open them (and > having it polymorphic does not quite make sense). > > > > sorry but I cannot understand what you mean. > > You suggest to use example > > but not to have it polymorphic? > >> > >> Cheers, > >> Doru > >> > >> > >> > >>> On Aug 19, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Let me know. I do not care about examplar or sample. > >>> > >>> Let us pick one that works well. I thought about prototype but this is > too close to prototype based language. > >>> > >>> So we could get > >>> > >>> <interactiveExample> > >>> > >>> <sample>/<instance>/ > >>> > >>> > >>> Le 19/8/16 Ã 01:59, Ben Coman a Ã©crit : > >>>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo > >>>> <emaringolo(a)gmail.com> wrote: > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > >>>>>> 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? > >>>>> Semantically it is correct, but for me, also maybe by not being a > >>>>> native English speaker, sounds weird. > >>>>> > >>>>> I'd use something like "sample". However I'll be fine with whatever > >>>>> you choose. But I'd choose something that doesn't sound weird to > >>>>> native English readers, we already have some cases of that. > >>>>> > >>>>> Regards, > >>>>> > >>>>> > >>>>> Esteban A. Maringolo > >>>>> > >>>> In the previous thread I argued against <exemplar> and for <sample>, > >>>> but I'm not so strong in my conviction to push it again :). The > >>>> former is a little exotic, but is sufficient -- and perhaps its useful > >>>> <example> and <exemplar> sound similar with just a minor difference at > >>>> the end. > >>>> > >>>> P.S. In terms of discover-ability about this difference, a passing > >>>> thought is it would be nice for newcomers to be able to hover over a > >>>> code like a pragma and get a tool tip popup. > >>>> > >>>> cheers -ben > >>>> > >>>> > >>> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Next time you see your life passing by, say 'hi' and get to know her." > >> > >> > >> > >> > >> > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > >

Aug. 19, 2016

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

by Tudor Girba

Hi, If you attache a certain action such as "result openInWorldâ to a pragma such as <interactiveExample>, it implies that when I have a different resulting object that should be spawned with a different message (for example, a Roassal view should be opened with "result open"), I should use a different pragma. That will quickly lead to an explosion of pragmas. Cheers, Doru > On Aug 19, 2016, at 10:32 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Le 19/8/16 Ã 10:18, Tudor Girba a Ã©crit : >> Hi, >> >> I strongly believe that the interaction should not be hardcoded in the example pragma name. That is because you will want all sorts of interactions once you go beyond the surface. For example, a Roassal visualization, a Bloc element, and a Morph are all interesting from an interaction point of view, but there are different ways to open them (and having it polymorphic does not quite make sense). > > sorry but I cannot understand what you mean. > You suggest to use example > but not to have it polymorphic? >> >> Cheers, >> Doru >> >> >> >>> On Aug 19, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Let me know. I do not care about examplar or sample. >>> >>> Let us pick one that works well. I thought about prototype but this is too close to prototype based language. >>> >>> So we could get >>> >>> <interactiveExample> >>> >>> <sample>/<instance>/ >>> >>> >>> Le 19/8/16 Ã 01:59, Ben Coman a Ã©crit : >>>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo >>>> <emaringolo(a)gmail.com> wrote: >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >>>>>> 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? >>>>> Semantically it is correct, but for me, also maybe by not being a >>>>> native English speaker, sounds weird. >>>>> >>>>> I'd use something like "sample". However I'll be fine with whatever >>>>> you choose. But I'd choose something that doesn't sound weird to >>>>> native English readers, we already have some cases of that. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Esteban A. Maringolo >>>>> >>>> In the previous thread I argued against <exemplar> and for <sample>, >>>> but I'm not so strong in my conviction to push it again :). The >>>> former is a little exotic, but is sufficient -- and perhaps its useful >>>> <example> and <exemplar> sound similar with just a minor difference at >>>> the end. >>>> >>>> P.S. In terms of discover-ability about this difference, a passing >>>> thought is it would be nice for newcomers to be able to hover over a >>>> code like a pragma and get a tool tip popup. >>>> >>>> cheers -ben >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Aug. 19, 2016

Re: [Pharo-dev] Abotu FileReference objects as autoevaluating ones

by Richard Sargent

stepharo wrote > about > https://pharo.fogbugz.com/f/cases/18956/FileReference-printString-should-be… > > > 'tmp/foo.txt' asFileReference > > > File @ tmp/foo.txt > > and it would be much much better to get back > 'tmp/foo.txt' asFileReference > > So that we can get > { 'tmp/foo.txt' asFileReference } > > { 'tmp/foo.txt' asFileReference } > > and not > "an Array(File @ tmp/foo.txt)" > > > In addition we should turn the current printOn: method into a > displayString method so that > a list of fileReference can be well display with File @ tmp/foo.txt for > example In many Smalltalk implementations, there are (at least) three behaviours for this kind of thing: #storeString, #printString, and #displayString. I would argue against conflating them. Examples: (I am not saying this is how each should work, just providing examples of how each /might/ differ to suit the different constituencies for each one's use case.) 1) #displayString '/directory/file' asFileReference displayString ==> '/directory/file' '/directory' asFileReference displayString ==> '/directory/' 2) #storeString '/directory/file' asFileReference storeString==> '/directory/file' asFileReference '/directory' asFileReference storeString==> '/directory/' asFileReference 3) #printString '/directory/file' asFileReference printString ==> FileReference(/directory/file) '/directory' asFileReference printString ==> FileReference(/directory/) -- View this message in context: http://forum.world.st/Abotu-FileReference-objects-as-autoevaluating-ones-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2016

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

by Sven Van Caekenberghe

> On 19 Aug 2016, at 17:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > stepharo wrote >> Let me know. I do not care about examplar or sample. > > In the original thread [1]: > - The most popular naming option was for some combination of > exampleInstance, exampleCode, sampleInstance, and sampleCode because they > are both natural-sounding-to-native-ears and explicit. > - There was a small (Ben and I) consensus leaning specifically toward > <exampleCode> together with <sampleInstance> That makes a lot of sense, so +1 And UI stuff would then be a case of <exampleCode> right, as side effect ? > - Exemplar (note it's not spelled exAmplar) is a bit obscure English > - There were some more exotic parameterized varieties discussed, but maybe > it's best to save those for a future evolution > > [1] > http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-t… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 19, 2016

Re: [Pharo-dev] [Cuis-dev] [Ann] Cuis is now Spur enabled!

by David T. Lewis

On Fri, Aug 19, 2016 at 12:23:51PM -0300, Juan Vuletich via Cuis-dev wrote: > Hi Folks, > > I've successfully finished the Spur conversion of Cuis. I was able to > merge all required changes to Cuis compiler and make it work in both > ObjectMemories. Cuis is now offered in Spur and pre-Spur formats. And > the best part is that they share 100% of the source code. There is no > forking! > Congratulations Juan and Eliot, this is very impressive! Dave

Aug. 19, 2016

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

by Sean P. DeNigris

stepharo wrote > Let me know. I do not care about examplar or sample. In the original thread [1]: - The most popular naming option was for some combination of exampleInstance, exampleCode, sampleInstance, and sampleCode because they are both natural-sounding-to-native-ears and explicit. - There was a small (Ben and I) consensus leaning specifically toward <exampleCode> together with <sampleInstance> - Exemplar (note it's not spelled exAmplar) is a bit obscure English - There were some more exotic parameterized varieties discussed, but maybe it's best to save those for a future evolution [1] http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-t… ----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Martin Dias

On Fri, Aug 19, 2016 at 12:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban A. Maringolo wrote > >> I think âapplyâ is better. âimportâ sounds too specific to me. I donât > >> want > >> to care where the entries come from and âimportâ implies that there may > >> be > >> something else going on (also: if thereâs an import whereâs the > export?). > > +1. Apply/revert sound right to me also. > Good! thanks; next release will have apply / revert Martin

Aug. 19, 2016

[Ann] Cuis now runs on Spur!

by juanlists＠jvuletich.org

Hi Folks, I've successfully finished the Spur conversion of Cuis. I was able to merge all required changes to Cuis compiler and make it work in both ObjectMemories. Cuis is now offered in Spur and pre-Spur formats. And the best part is that they share 100% of the source code. There is no forking! This means that there is no extra work in maintaining both flavors. So, we are not leaving anyone behind. It also means that, at deployment, you might chose between better performance and larger memory (with Spur) or smaller footprint and SqueakJS compatibility (with pre-Spur). I've just updated our GitHub repo https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev . Included are Cuis4.2-2906-spur.image and Cuis4.2-2906.image, and, as usual, the whole update stream. I wrote a brief description of the Spur conversion at Documentation/SpurConversion.md, in case you want to reproduce it, or apply it to your own Cuis images. The images seem very stable. Please test them, load your code, and report any issues. This work was enabled by Eliot Miranda and the OpenSmalltalk team who develop Spur, VMMaker and the Spur bootstrap. Thank you folks! I also used Squeak 5 as a reference implementation of Compiler and related stuff. I also want to thank the greater Squeak community for it. Some cleanup is in order. The scaffolding I did for the conversion, including dual Compilers is still in the image. I'll be cleaning it soon. I'll also be able to pay a bit more attention to unrelated suggestions and ongoing discussion at cuis-dev(a)cuis-smalltalk.org Enjoy! Cheers, Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev @JuanVuletich

Aug. 19, 2016