- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

Hi Nicolai, Did we clarify this issue? Is there something else I can help (or maybe to disturb/annoy :)) with ? Cheers, Doru > On Aug 10, 2016, at 5:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Oh man :). Ok I think got it now. Thanks for the patience. I see the confusion: the agreement was that we will override the shortcut in the Spotter text-input. So, letâs go for this. > > The layering thing was supposed to be a separate issue. > > Cheers, > Doru > > > >> On Aug 10, 2016, at 12:05 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-08-09 23:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >>> On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>>> On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> Hi, >>>> >>>>> >>>>> Hey Doru, >>>>> about what "two issues" are we talking? My only issue for now is, >>>>> what shortcut shold we use for moving the cursor forward/backward word. Even if we introduce a new layer, at some point in time you need to >>>>> define: If the user types the CTRL+LEFT -key, even if we call it differently, some action happens, dive-out or move-backward-word ? >>>>> At the moment (on windows) you can use both to move word-by-word: >>>>> ctrl+left/right and alt+left/right, because this is how it is defined in rubrics action/cmdaction map. >>>>> >>>>> If we want to clean this up and use the kmdispatcher registration, I think we don't want to use both ctr and alt again, right? >>>>> So, someone has to take the decision. >>>>> I myself would prefer >>>>> ctrl+left/right because this is what (all) many other programs are using on windows. Fine. But recently Spotter changed its >>>>> dive in / dive out shortcut to use ctrl+left/right. >>>>> Therefor I am asking you, why, and whether we want to keep it or not. If we want to keep it, we may >>>>> - just overwrite the binding for the textfield -> not good, I think, you wouldn't be able to do word-by-word movements in the textfield anymore >>>>> - overwrite the binding and use another binding for word-by-word moving, but just in spotters text field >>>>> Or we revert that change and use the old shortcuts again. >>>>> (And what to use for mac and linux?) >>>>> >>>>> but I am getting really tired of asking, and will do something else instead. >>>> >>>> The short answer: we will override the keybinding in the text morph for now. This will mean that we cannot move word by word in the text field using #control, but it will be consistent with all other platforms. Could you open an issue for this, please? >>>> >>>> >>>> consistens on all platforms may not be the expectation for all users. Some users only working on a windows platform may want to have consistent behavior for all tools (applications). >>> >>> Well, you wanted a decision :). >>> >>> >>>> On top of that, we will externalize all GTSpotter shortcuts through settings: >>>> https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externa… >>>> >>>> I really don't know why that. >>> >>> Because we do not have a generic KMDispatcher mechanism :). >>> >>> yes and it does not make much sense as not all shortcuts are handled by the kmdispatcher, thats why cleaning this >>> up and I think it would be better to do this instead of implementing yet another only-for-this-tool solution. >> >> Ok. What should I do? >> >> >>>> We don't need a way to make Spotter shortcuts configurable, but *all* shortcuts. >>>> That is why I try to move all shortcut definitions to the kmdispatcher, but it yet again took 2 month just to discuss what shortcut to use for cursor movement. >>> >>> I am not sure I understand. Was this me that stalled the discussion? If yes, it was not intentional. Is there anything I can do about this subject? >>> >>> The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have a great idea, just let us add some new layers" :( >> >> I think I miss something because I do not see how the layers have anything to do with the cursor movement. Or do you mean for diving in Spotter? I still think that the layers idea is a relevant one and does not conflict with anything we talked about here. >> >> Ok once again. >> ctrl+arrow and meta+arrow both do cursor movements in rubrik, but it is registered on the action/cmd-map (RubTextEditor>>defaultCommandKeymapping) >> ctrl+arrow do dive-in/dive-out in spotter, this is registered on spotters window, and this takes precedence over rubrics crtrl+Arrow handling because : >> >> 1. kmdispatcher looks in rubrics editor kmregistry -> no action >> 2. kmdispatcher looks in rubrics morph kmregistry -> no action >> .... up the morphs owner chain until it reaches spotter >> x. kmdispatcher looks in spotters window morph kmregistry -> Action! Dive-in / Dive-out >> >> Now! If I move ctrl+Arrow shortcut registration for cursor movement from rubrics action/-cmd-map to its kmdispatcher registration, the following happens >> 1. kmdispatcher looks in rubrics editor kmregistry -> Action ! move the cursor >> >> -> no spotter dive-in/dive-out anymore :-( >> >> two solutions: >> use a different shortcut for cursor movement (that is what I aksed in this thread, and why I opened issue 18432) >> use a different shortcut for spotter (this is why I started this thread and asked why this was changed at all) >> overwrite spotters shortcut registration (just like now, but not on spotters window, but on the text field (I opened now a fogbugz issue 18900)) >> >> anyway, you said, you want to wait with changing spotters shortcut registration until we have the new layers, therefore I can only wait until that >> happens. >> >> >> >> >> In any case, I did not mean to confuse anyone. Please take the lead concerning the KMDispatcher and I can review if you want. >> >> Doru >> >> >> >>> Cheers, >>> Doru >>> >>> >>>> >>>> Long answer: As explained before, the shortcut changed in the process of making all shortcuts uniform when Guille introduced #meta instead of #command (like it was before). The thing is that currently: >>>> - #command means #alt on Win and #command on Mac, and >>>> - #meta means #control on Win and #command on Mac. >>>> >>>> But, #command should be a low level key, not a portable one. It should not have a meaning on Windows, because the key does not exist on that platform. >>>> >>>> Moving to make keybindings uniform is a good thing, but only having #meta is not enough for situation like the one you mention. That is why I am proposing to introduce a #secondaryMeta as a platform-independent modifier that would mean #alt on Win and #control on Mac. We could use that one more consistently. Is this a better explanation? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Presenting is storytelling." >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "One cannot do more than one can do." >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "When people care, great things can happen." > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Aug. 19, 2016

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