Re: [Pharo-dev] /

[Nicolai Hess]

2016-08-20 0:26 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 20, 2016, at 12:22 AM, Nicolai Hess 
> wrote:
> >
> >
> >
> > 2016-08-20 0:02 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess 
> wrote:
> > >
> > >
> > >
> > > 2016-08-19 23:13 GMT+02:00 Tudor Girba :
> > > Hi,
> > >
> > > If you attache a certain action such as "result openInWorld” to a
> pragma such as , 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:
> > >
> > >  or  - 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.
> > > 

Re: [Pharo-dev] /

[Tudor Girba]

Hi,

> On Aug 20, 2016, at 12:22 AM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-20 0:02 GMT+02:00 Tudor Girba :
> Hi,
> 
> > On Aug 19, 2016, at 11:55 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-08-19 23:13 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > If you attache a certain action such as "result openInWorld” to a pragma 
> > such as , 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:
> >
> >  or  - 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.
> > 

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

[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  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  wrote:
>> 
>> 
>> 
>> 2016-08-09 23:36 GMT+02:00 Tudor Girba :
>> Hi,
>> 
>>> On Aug 9, 2016, at 11:31 PM, Nicolai Hess  wrote:
>>> 
>>> 
>>> 
>>> 2016-08-09 22:53 GMT+02:00 Tudor Girba :
>>> Hi,
>>> 
 On Aug 9, 2016, at 10:48 PM, Nicolai Hess  wrote:
 
 
 
 2016-08-09 18:12 GMT+02:00 Tudor Girba :
 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-externalized-as-settings
 
 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 -

Re: [Pharo-dev] /

[Nicolai Hess]

2016-08-20 0:02 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 19, 2016, at 11:55 PM, Nicolai Hess 
> wrote:
> >
> >
> >
> > 2016-08-19 23:13 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > If you attache a certain action such as "result openInWorld” to a pragma
> such as , 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:
> >
> >  or  - 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.
> > 

Re: [Pharo-dev] /

[Tudor Girba]

Hi,

> On Aug 19, 2016, at 11:55 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-19 23:13 GMT+02:00 Tudor Girba :
> Hi,
> 
> If you attache a certain action such as "result openInWorld” to a pragma such 
> as , 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:
> 
>  or  - 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.
> 

Re: [Pharo-dev] /

[Nicolai Hess]

2016-08-19 23:13 GMT+02:00 Tudor Girba :

> Hi,
>
> If you attache a certain action such as "result openInWorld” to a pragma
> such as , 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:

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

Re: [Pharo-dev] /

[Tudor Girba]

Hi,

If you attache a certain action such as "result openInWorld” to a pragma such 
as , 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  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  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
>>> 
>>>
>>> 
>>>//
>>> 
>>> 
>>> Le 19/8/16 à 01:59, Ben Coman a écrit :
 On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo
  wrote:
> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont :
>> On 18/08/16 14:38, stepharo wrote:
>>> Hi
>>> 
>>> In my projects I start to do the following:
>>> 
>>> I create  class method that returns an prototypical instance.
>> Nice. Excellent inititive. I'm not a native speaker, and  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  and for ,
 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
  and  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."

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

[Richard Sargent]

stepharo wrote
> about 
> https://pharo.fogbugz.com/f/cases/18956/FileReference-printString-should-be-auto-evaluable
> 
> 
> '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-tp4911694p4911974.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] /

[Sven Van Caekenberghe]

> On 19 Aug 2016, at 17:35, Sean P. DeNigris  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
>  together with 

That makes a lot of sense, so +1

And UI stuff would then be a case of  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-td4833428.html
> 
> 
> 
> -
> 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.
> 

Re: [Pharo-dev] /

[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
 together with 
- 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-td4833428.html



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

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

[Martin Dias]

On Fri, Aug 19, 2016 at 12:14 PM, Sean P. DeNigris 
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

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

[Sean P. DeNigris]

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.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Epicea-import-revert-instead-of-redo-undo-changes-Was-Re-pharo-project-pharo-core-f57843-60163-tp4911844p4911936.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[Esteban A. Maringolo]

2016-08-19 5:47 GMT-03:00 Esteban Lorenzano :
>
> On 19 Aug 2016, at 10:43, Max Leske  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 :)

+1 here

I was thinking about apply/revert as well.

If you use git-cherry-pick its description says: "Apply the changes
introduced by some existing commits"

I prefer it.

Esteban A. Maringolo

Re: [Pharo-dev] STON and (default) line endings

[Peter Uhnak]

On Fri, Aug 19, 2016 at 02:55:08PM +0200, Sven Van Caekenberghe wrote:
> Yes it would make much more sense to default to LF EOL (maybe not on Windows) 
> in this century, but that is true for the whole image ...

I agree, but this is imho very simple and actionable change and a step forward.

Changing whole image is a much bigger issue.

Re Windows: we should make a poll among Windows users to see what makes the 
most sense for them.

Peter

> 
> > On 19 Aug 2016, at 14:49, Peter Uhnak  wrote:
> > 
> > Hi,
> > 
> > can we have a class-side configuration for STON line ending?
> > 
> > Atm if I want to output with LF instead of CR (which is always),
> > then I have to always do this
> > 
> > String streamContents: [ :stream |
> > (STON writer on: stream)
> > prettyPrint: true;
> > newLine: String lf;
> > nextPut: data
> > ].
> > 
> > I would be much happier if at least I could do this
> > 
> > STON lineEnding: String lf
> > 
> > (I could put the above in a StartupScript)
> > 
> > And then just use regular STON toStringPretty: data.
> > 
> > 
> > And I would be even happier if
> > 
> > STON class>>lineEnding
> > ^ String lf
> > 
> > or
> > 
> > STON class>>lineEnding
> > ^ OSPlatform current isWindows
> > ifTrue: [ String crlf ]
> > ifFalse: [ String lf ]
> > 
> > (Although always using LF by default might be preferable.)
> > 
> > To summarize, it would be great if we could:
> > 
> > * switch STON to LF _by default_
> > * allow users to easily switch to CR/CRLF if they need
> > 
> > Thanks,
> > Peter
> > 
> 
> 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60188
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 5dfcea: 60188

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5dfcea3320fb3b8942a80337b07de7565f30e73c
  
https://github.com/pharo-project/pharo-core/commit/5dfcea3320fb3b8942a80337b07de7565f30e73c
  Author: Jenkins Build Server 
  Date:   2016-08-19 (Fri, 19 Aug 2016)

  Changed paths:
M Kernel.package/MessageSend.class/instance/evaluating/value.st
M Kernel.package/MessageSend.class/instance/evaluating/value_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60187.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60188.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60187.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60188.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60188
18158 MessageSend should not care about obsolete classes
https://pharo.fogbugz.com/f/cases/18158

http://files.pharo.org/image/60/60188.zip

Re: [Pharo-dev] STON and (default) line endings

[Sven Van Caekenberghe]

Yes it would make much more sense to default to LF EOL (maybe not on Windows) 
in this century, but that is true for the whole image ...

> On 19 Aug 2016, at 14:49, Peter Uhnak  wrote:
> 
> Hi,
> 
> can we have a class-side configuration for STON line ending?
> 
> Atm if I want to output with LF instead of CR (which is always),
> then I have to always do this
> 
> String streamContents: [ :stream |
>   (STON writer on: stream)
>   prettyPrint: true;
>   newLine: String lf;
>   nextPut: data
> ].
> 
> I would be much happier if at least I could do this
> 
> STON lineEnding: String lf
> 
> (I could put the above in a StartupScript)
> 
> And then just use regular STON toStringPretty: data.
> 
> 
> And I would be even happier if
> 
> STON class>>lineEnding
>   ^ String lf
> 
> or
> 
> STON class>>lineEnding
>   ^ OSPlatform current isWindows
>   ifTrue: [ String crlf ]
>   ifFalse: [ String lf ]
> 
> (Although always using LF by default might be preferable.)
> 
> To summarize, it would be great if we could:
> 
> * switch STON to LF _by default_
> * allow users to easily switch to CR/CRLF if they need
> 
> Thanks,
> Peter
> 

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

[Peter Uhnak]

On Fri, Aug 19, 2016 at 02:15:06PM +0200, Oscar Nierstrasz wrote:
> 
> Hi Folks,
> 
> Does anyone else find this to be a problem? I can never tell whether I am on 
> the class or the instance side as the button toggle is non-obvious. In fact, 
> the (C) is more clearly visible on the instance side, which is counter 
> intuitive.
> 
> I would rather see the name of the button change between “Instance” and 
> “Class” so I always know where I am.

This would be imho confusing, because you would always see the opposite (it's a 
button, so the label should state what should happen when you click on it, not 
describing the current context).

But there is also another visual clue which always makes it obvious (for me at 
least) on which side I am: on class side all methods are bold.

Peter

[Pharo-dev] STON and (default) line endings

[Peter Uhnak]

Hi,

can we have a class-side configuration for STON line ending?

Atm if I want to output with LF instead of CR (which is always),
then I have to always do this

String streamContents: [ :stream |
(STON writer on: stream)
prettyPrint: true;
newLine: String lf;
nextPut: data
].

I would be much happier if at least I could do this

STON lineEnding: String lf

(I could put the above in a StartupScript)

And then just use regular STON toStringPretty: data.


And I would be even happier if

STON class>>lineEnding
^ String lf

or

STON class>>lineEnding
^ OSPlatform current isWindows
ifTrue: [ String crlf ]
ifFalse: [ String lf ]

(Although always using LF by default might be preferable.)

To summarize, it would be great if we could:

* switch STON to LF _by default_
* allow users to easily switch to CR/CRLF if they need

Thanks,
Peter

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

[Sven Van Caekenberghe]

Oscar,

> On 19 Aug 2016, at 14:15, Oscar Nierstrasz  wrote:
> 
> 
> Hi Folks,
> 
> Does anyone else find this to be a problem? I can never tell whether I am on 
> the class or the instance side as the button toggle is non-obvious. In fact, 
> the (C) is more clearly visible on the instance side, which is counter 
> intuitive.
> 
> I would rather see the name of the button change between “Instance” and 
> “Class” so I always know where I am.
> 
> Cheers,
> Oscar

You are right, toggle buttons are never very intuitive. Two way switches with 
double green/gray labels are better but take more space.

In Pharo 6 Dark Theme, there are several 'clear' differences: the blue of the 
class button selection (pressed), the title of the browser window, the changed 
template or protocols, no ?



It is not perfect, but good enough, there is no easy improvement without taking 
more space, IMHO.

Sven

[Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

[Oscar Nierstrasz]

Hi Folks,

Does anyone else find this to be a problem? I can never tell whether I am on 
the class or the instance side as the button toggle is non-obvious. In fact, 
the (C) is more clearly visible on the instance side, which is counter 
intuitive.

I would rather see the name of the button change between “Instance” and “Class” 
so I always know where I am.

Cheers,
Oscar

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

[Denis Kudriashov]

2016-08-19 10:43 GMT+02:00 Max Leske :

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


But we support to open and import changes from any image (not only owner).
Anyway we need to choose most intuitive name because undo/redo are always
raise questions (also after many times I use it). "apply" could be good too.

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

[Esteban Lorenzano]

> On 19 Aug 2016, at 10:43, Max Leske  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 :)

> 
> But that’s just an opinion.
> 
> Cheers,
> Max
> 
> 
>> On 19 Aug 2016, at 04:13, Martin Dias > > wrote:
>> 
>> 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" mailto:steph...@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 >> > 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 >> > 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 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

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

[Max Leske]

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

But that’s just an opinion.

Cheers,
Max


> On 19 Aug 2016, at 04:13, Martin Dias  wrote:
> 
> 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" mailto:steph...@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 > > 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 > > 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 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

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

[Denis Kudriashov]

2016-08-19 4:13 GMT+02:00 Martin Dias :

> ps2: I'm preparing a major update in Epicea's UIs, which already has some
> renames.
>
>
> ​
>
>
That is cool

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

[Denis Kudriashov]

Hi

2016-08-19 4:13 GMT+02:00 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.
>

Does it always work?
I could rename class A to B. Then I will rename B to C. After that how
first change could be reverted?

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

[Denis Kudriashov]

I prefer import/revert

2016-08-19 10:27 GMT+02:00 Esteban Lorenzano :

> apply / revert sounds good to me.
>
> Esteban
>
> On 19 Aug 2016, at 09:37, stepharo  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.
>
> 
> ​
>
>
>
>
> El 7/8/2016 3:16, "stepharo"  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  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  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



>>>
>>>
>>
>>
>
>
>
>
>

Re: [Pharo-dev] /

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



//


Le 19/8/16 à 01:59, Ben Coman a écrit :

On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo
 wrote:

2016-08-18 17:30 GMT-03:00 Stephan Eggermont :

On 18/08/16 14:38, stepharo wrote:

Hi

In my projects I start to do the following:

I create  class method that returns an prototypical instance.

Nice. Excellent inititive. I'm not a native speaker, and  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  and for ,
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
 and  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."

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

[Esteban Lorenzano]

apply / revert sounds good to me.

Esteban

> On 19 Aug 2016, at 09:37, stepharo  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.
>> 
>> 
>> ​
>> 
>> 
>> 
>> El 7/8/2016 3:16, "stepharo" mailto:steph...@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 >> > 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 >> > 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 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

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

[Sven Van Caekenberghe]

> On 19 Aug 2016, at 09:36, Peter Uhnák  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_conventions
>  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

Re: [Pharo-dev] /

[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  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
> 
>
> 
>//
> 
> 
> Le 19/8/16 à 01:59, Ben Coman a écrit :
>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo
>>  wrote:
>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont :
 On 18/08/16 14:38, stepharo wrote:
> Hi
> 
> In my projects I start to do the following:
> 
> I create  class method that returns an prototypical instance.
 
 Nice. Excellent inititive. I'm not a native speaker, and  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  and for ,
>> 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
>>  and  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."

Re: [Pharo-dev] /

[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



//


Le 19/8/16 à 01:59, Ben Coman a écrit :

On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo
 wrote:

2016-08-18 17:30 GMT-03:00 Stephan Eggermont :

On 18/08/16 14:38, stepharo wrote:

Hi

In my projects I start to do the following:

I create  class method that returns an prototypical instance.


Nice. Excellent inititive. I'm not a native speaker, and  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  and for ,
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
 and  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

Re: [Pharo-dev] /

[stepharo]

Ok, let's distinguish them. Scripts are scripts (maybe 

[Pharo-dev] FileTree export format on Windows

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