August 2016 - Pharo-dev - lists.pharo.org

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

by stepharo

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." > > > > > >

Aug. 19, 2016

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

by Esteban Lorenzano

apply / revert sounds good to me. Esteban > On 19 Aug 2016, at 09:37, stepharo <stepharo(a)free.fr> wrote: > > good to me. > Import is good. Apply to. > > After I'm not sure I understand redo :) > > > Tx for the new release > Le 19/8/16 Ã 04:13, Martin Dias a Ã©crit : >> Hi Stef, I come back to your observation about the words Redo and Undo used in Epicea menu. You proposed to use Import and Revert instead. >> >> Originally I chose redo/undo because they are very well known terms in text editing UIs, but it is true that they are different: in regular UIs you can't select an arbitrary operation in the history and redo or undo it, like in Epicea. So other names can be more adequate... >> >> any other opinion? >> >> >> Martin >> >> ps: other alternative is apply+"apply inverse" >> >> ps2: I'm preparing a major update in Epicea's UIs, which already has some renames. >> >> <Mail Attachment.png> >> â >> >> >> >> El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >> >> >> Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : >>> Hi Stef, good, I take note. I improved filters in the recent releases and will continue improving. >> >> Thanks Martin >> >> I have problems with the menu item names :) >> To me redo looks strange >> when I get a crash I want to import the changes not redo them. >> Then I do not get what undo means (yes I know this is probably revert) >> May be some pharoers have better names than mine. >> >> Stef >> >>> >>> Martin >>> >>> On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> Thanks Martin. >>> >>> We missed yesterday: show only the latest version of every entities. :) >>> >>> >>> Setf >>> >>> >>> Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : >>> >>> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: >>> >>> >>> Log Message: >>> ----------- >>> 60163 >>> 18831 Integrate new Epicea version >>> https://pharo.fogbugz.com/f/cases/18831 <https://pharo.fogbugz.com/f/cases/18831> >>> >>> ChangeLog for this: >>> >>> - Case 18813: Implement redo and undo of protocol addition and removal. >>> >>> - Case 18612: disable drag&drop until TreeModel supports it correctly. >>> >>> - Case 18384: Redo and undo: show on any selection (not only when all selected entries are code changes). >>> >>> - Enhancement: Improve lost changes detection; show only the events actually lost. >>> >>> - Enhancement: Pass on filters. >>> >>> - Clean up: Do not show the "absent entry" item anymore since it was not useful at all. >>> >>> - Clean up: Remove unused "commit tags" in log browser. >>> >>> - Clean up: Remove unused tests. They were good idea, we can re-introduce them but working and covering more cases. >>> >>> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. It is more meaningful. >>> >>> - Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel drag&drop is fixed. >>> >>> >>> >>> 18768 Inlined method const could be implemented by metalinks >>> https://pharo.fogbugz.com/f/cases/18768 <https://pharo.fogbugz.com/f/cases/18768> >>> >>> 18835 Update RBParser-Nodes class comments >>> https://pharo.fogbugz.com/f/cases/18835 <https://pharo.fogbugz.com/f/cases/18835> >>> >>> http://files.pharo.org/image/60/60163.zip <http://files.pharo.org/image/60/60163.zip> >>> >>> >>> >>> >>> >>> >>> >> >> >

Aug. 19, 2016

Re: [Pharo-dev] FileTree export format on Windows

by Sven Van Caekenberghe

> On 19 Aug 2016, at 09:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I just ran into a quite nasty issue when using GitFileTree on Windows with the FileTree export format. > > Apparently there are reserved names on Windows: > > > CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9 > > And I had an âauxâ and âaux:â methods in Pharo, which were attempted to be exported as âaux.stâ and âaux..stâ, but silently failed. The silently fails part is really bad ! > There are also other rules https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conven… which might break binary selectors (I havenât tried those). > > I am not sure how I am supposed to deal with this, but assuming Pharo wants to support all platforms, this should be resolved in some manner; in the meantime I will use some alternative name. > > Thanks, > Peter

Aug. 19, 2016

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

by Tudor Girba

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). 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."

Aug. 19, 2016

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

by stepharo

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 > >

Aug. 19, 2016

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

by stepharo

> > Ok, let's distinguish them. Scripts are scripts (maybe <script> is > better name than <example>?) > > I thought that we don't need two options because in practice > <example> only opens morph or inspector. And for morphs we already > have morph tab in inspector. So morph examples could be easily > converted to <examplar> without any loss. > @Denis there was a long debate a while ago and I do not want to rediscuss it. Personnally I have no preconceived points on naming. I want just a way to get instance and that people are happy and that the solution stay ridiculously simple. > > some <example> methods don't just show a morph that you want to > inspect, but a Morph that you want to interact with. And not all > Morphs render well in the inspectors Morph tab. > > <script> - execute some code, don't care about the return value > <example> - create an (UI/Morph)-example you can interact with > <exemplar> - create an example instance. > I like all three of them and can see a value for every single one. @Nicolai Me too. So we are in sync :) I wonder where we can document that. I would have changed <example> into <popupExample>/<interactiveExample> And it is not a dogma for me. Just to make sure that we move on. Because I got student changing my "<examplar>" not tagged method to add an inspect call, not fun when running my tests :) but it was clear that they wanted to have an inspector to tweak the object. > In my proposal we can get the best of both worlds. > - instance to use in tests > - instance to learn and tweak with GTInspector > - examples that we can see opening. > > > >

Aug. 19, 2016

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

by stepharo

good to me. Import is good. Apply to. After I'm not sure I understand redo :) Tx for the new release Le 19/8/16 Ã 04:13, Martin Dias a Ã©crit : > > Hi Stef, I come back to your observation about the words Redo and Undo > used in Epicea menu. You proposed to use Import and Revert instead. > > Originally I chose redo/undo because they are very well known terms in > text editing UIs, but it is true that they are different: in regular > UIs you can't select an arbitrary operation in the history and redo or > undo it, like in Epicea. So other names can be more adequate... > > any other opinion? > > > Martin > > ps: other alternative is apply+"apply inverse" > > ps2: I'm preparing a major update in Epicea's UIs, which already has > some renames. > > > â > > > > > El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> escribiÃ³: > > > > Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : >> Hi Stef, good, I take note. I improved filters in the recent >> releases and will continue improving. > > Thanks Martin > > I have problems with the menu item names :) > To me redo looks strange > when I get a crash I want to import the changes not redo them. > Then I do not get what undo means (yes I know this is probably revert) > May be some pharoers have better names than mine. > > Stef > >> >> Martin >> >> On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Thanks Martin. >> >> We missed yesterday: show only the latest version of every >> entities. :) >> >> >> Setf >> >> >> Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : >> >> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com >> <mailto:noreply@github.com>> wrote: >> >> >> Log Message: >> ----------- >> 60163 >> 18831 Integrate new Epicea version >> https://pharo.fogbugz.com/f/cases/18831 >> <https://pharo.fogbugz.com/f/cases/18831> >> >> ChangeLog for this: >> >> - Case 18813: Implement redo and undo of protocol >> addition and removal. >> >> - Case 18612: disable drag&drop until TreeModel supports >> it correctly. >> >> - Case 18384: Redo and undo: show on any selection (not >> only when all selected entries are code changes). >> >> - Enhancement: Improve lost changes detection; show only >> the events actually lost. >> >> - Enhancement: Pass on filters. >> >> - Clean up: Do not show the "absent entry" item anymore >> since it was not useful at all. >> >> - Clean up: Remove unused "commit tags" in log browser. >> >> - Clean up: Remove unused tests. They were good idea, we >> can re-introduce them but working and covering more cases. >> >> - Clean up: Rename #displayWidget to #asMorph in >> EpLogBrowserItem''s hierarchy. It is more meaningful. >> >> - Workaround: Hide "Open in Sorter" menu action since it >> is useless until Treemodel drag&drop is fixed. >> >> >> >> 18768 Inlined method const could be implemented by >> metalinks >> https://pharo.fogbugz.com/f/cases/18768 >> <https://pharo.fogbugz.com/f/cases/18768> >> >> 18835 Update RBParser-Nodes class comments >> https://pharo.fogbugz.com/f/cases/18835 >> <https://pharo.fogbugz.com/f/cases/18835> >> >> http://files.pharo.org/image/60/60163.zip >> <http://files.pharo.org/image/60/60163.zip> >> >> >> >> >> >> >> > >

Aug. 19, 2016

FileTree export format on Windows

by Peter UhnÃ¡k

Hi, I just ran into a quite nasty issue when using GitFileTree on Windows with the FileTree export format. Apparently there are reserved names on Windows: > CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9 And I had an âauxâ and âaux:â methods in Pharo, which were attempted to be exported as âaux.stâ and âaux..stâ, but silently failed. There are also other rules https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conven… which might break binary selectors (I havenât tried those). I am not sure how I am supposed to deal with this, but assuming Pharo wants to support all platforms, this should be resolved in some manner; in the meantime I will use some alternative name. Thanks, Peter

Aug. 19, 2016

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

by Martin Dias

Hi Stef, I come back to your observation about the words Redo and Undo used in Epicea menu. You proposed to use Import and Revert instead. Originally I chose redo/undo because they are very well known terms in text editing UIs, but it is true that they are different: in regular UIs you can't select an arbitrary operation in the history and redo or undo it, like in Epicea. So other names can be more adequate... any other opinion? Martin ps: other alternative is apply+"apply inverse" ps2: I'm preparing a major update in Epicea's UIs, which already has some renames. â El 7/8/2016 3:16, "stepharo" <stepharo(a)free.fr> escribiÃ³: Le 5/8/16 Ã 05:28, Martin Dias a Ã©crit : Hi Stef, good, I take note. I improved filters in the recent releases and will continue improving. Thanks Martin I have problems with the menu item names :) To me redo looks strange when I get a crash I want to import the changes not redo them. Then I do not get what undo means (yes I know this is probably revert) May be some pharoers have better names than mine. Stef Martin On Wed, Aug 3, 2016 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > Thanks Martin. > > We missed yesterday: show only the latest version of every entities. :) > > > Setf > > > Le 3/8/16 Ã 11:23, Marcus Denker a Ã©crit : > > On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com> wrote: >>> >>> >>> Log Message: >>> ----------- >>> 60163 >>> 18831 Integrate new Epicea version >>> https://pharo.fogbugz.com/f/cases/18831 >>> >>> ChangeLog for this: >> >> - Case 18813: Implement redo and undo of protocol addition and removal. >> >> - Case 18612: disable drag&drop until TreeModel supports it correctly. >> >> - Case 18384: Redo and undo: show on any selection (not only when all >> selected entries are code changes). >> >> - Enhancement: Improve lost changes detection; show only the events >> actually lost. >> >> - Enhancement: Pass on filters. >> >> - Clean up: Do not show the "absent entry" item anymore since it was not >> useful at all. >> >> - Clean up: Remove unused "commit tags" in log browser. >> >> - Clean up: Remove unused tests. They were good idea, we can re-introduce >> them but working and covering more cases. >> >> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s >> hierarchy. It is more meaningful. >> >> - Workaround: Hide "Open in Sorter" menu action since it is useless until >> Treemodel drag&drop is fixed. >> >> >> >> 18768 Inlined method const could be implemented by metalinks >>> https://pharo.fogbugz.com/f/cases/18768 >>> >>> 18835 Update RBParser-Nodes class comments >>> https://pharo.fogbugz.com/f/cases/18835 >>> >>> http://files.pharo.org/image/60/60163.zip >>> >>> >>> >> >> > >

Aug. 19, 2016

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

by Ben Coman

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

Aug. 18, 2016