Re: [Pharo-dev] /

[Ben Coman]

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] About PythonDocTest for Pharo

[Denis Kudriashov]

2016-08-18 13:32 GMT+02:00 stepharo :

> withExtension: aString
>
> "Returns a new file reference with a different file extension"


Does this comment is really needed?
I only see extra word "different". And rest is same as method name. IMHO we
should rename method to "withDifferentExtension:" and remove comment.

Re: [Pharo-dev] About PythonDocTest for Pharo

[Denis Kudriashov]

Hi.

2016-08-18 9:34 GMT+02:00 stepharo :

> withExtension: aString
>
> "Returns a new file reference with a different file extension"
>
> 
> value: '/tmp/file.log' asFileReference >
>
> ^ self withPath: (self path withExtension: aString)
>
>
> So let me know what you think.
> - tell me that we have already test unit (yes the ones I wrote too)
> => they do not have the same purpose
>

I am sorry, but I want to said it: we have tests. Why tests are not for
same purpose? (I would say they include it).

As Tudor said:

"they are way too disconnected from the code"


And this needs to be solved.
We already have nice feature in Nautilus: it shows "test icon" on covered
methods. We could extends this idea to simplify test visibility.

Proposed solution is much simpler. But how much it is practical? How many
code could use it?
For simple cases like String methods is super nice. But could you imaging
it for Seaside code? or Morphic?

Re: [Pharo-dev] /

[Esteban A. Maringolo]

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

Re: [Pharo-dev] /

[Nicolai Hess]

2016-08-18 22:45 GMT+02:00 Denis Kudriashov :

>
> 2016-08-18 19:50 GMT+02:00 stepharo :
>
>> Hi
>>
>> Why not use  pragma in the way you propose for ? Why
>> we need two?
>>
>>
>> Apparently from the old discussion, people like  to prompt and
>> open the example
>> when this is something visual. This is ok for me.
>>
>
> Ok, let's distinguish them. Scripts are scripts (maybe 

Re: [Pharo-dev] /

[Tudor Girba]

Hi,

I am happy to see the concept of an example method catching attention again.

As explained before, the GTExample was already present in the Pharo image, but 
it was introduced more as a helper for testing GT extensions. Now, I just 
created an issue for removing GTExamples from the GT-Inspector package and from 
the main Pharo image:
https://pharo.fogbugz.com/f/cases/18965/Remove-GTExample-from-the-GT-Inspector-package

Cheers,
Doru


> On Aug 18, 2016, at 10:45 PM, Denis Kudriashov  wrote:
> 
> 
> 2016-08-18 19:50 GMT+02:00 stepharo :
>> Hi
>> 
>> Why not use  pragma in the way you propose for ? Why we 
>> need two?
> 
> Apparently from the old discussion, people like  to prompt and open 
> the example 
> when this is something visual. This is ok for me. 
> 
> Ok, let's distinguish them. Scripts are scripts (maybe 

Re: [Pharo-dev] /

[Denis Kudriashov]

2016-08-18 19:50 GMT+02:00 stepharo :

> Hi
>
> Why not use  pragma in the way you propose for ? Why we
> need two?
>
>
> Apparently from the old discussion, people like  to prompt and
> open the example
> when this is something visual. This is ok for me.
>

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

Re: [Pharo-dev] /

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


Stephan

Re: [Pharo-dev] /

[stepharo]

A little blog post to explain

https://wordpress.com/post/pharoweekly.wordpress.com/1190

Stef

Re: [Pharo-dev] /

[stepharo]

Le 18/8/16 à 21:31, stepharo a écrit :

Hi all

I implemented the  to behave as suggested by torsten and it 
is available in less than 5 min (I loved it). An example is JUST a 
class method returning an instance.

examplar is JUST... :)



CTGrid class >> grid22

"self grid22"
| grid1 |
grid1 := self new: 2.
grid1 atRow: 1 atColumn: 1 put: 1.
grid1 atRow: 1 atColumn: 2 put: 3.
grid1 atRow: 2 atColumn: 1 put: 2.
grid1 atRow: 2 atColumn: 2 put: 4.
^ grid1

You can use this method as any class method in the past. NOTHING new!!
So in particular your test can use it to build a fixture (yes reuse). 
You can use this method in several test cases (yes reuse).



Now nautilus supports nicely  methods: you can execute them 
and get a cool GTInspector open on them. So this is similar to the 
method exampleSomething from Nautilus point of view. And now people 
can use example to create/open/... their lovely examples (that may not 
return instances). And we get examplar methods that must return an 
instance but can behave as example from Nautilus perspective.


https://pharo.fogbugz.com/f/cases/18964/support-examplar

If you want to try you can load the CTGrid packages

ScriptLoader new unloadPackageNamed: 'Collections-Grid'.
ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'.
"Because there were not good and will be removed from the image"
Gofer it
url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main';
configurationOf: 'Grid';
loadStable

Click on class side of CTGrid and press the triangle and yes you get 
an inspector on this instance.


Stef





Le 18/8/16 à 14:38, stepharo a écrit :

Hi

In my projects I start to do the following:

I create  class method that returns an prototypical instance.

I use such methods in my tests as fixture.

Then I would like to have nautilus presenting to me the  
with a little triangle and when I press


on them I get an inspector on them.

This way I get the same behavior than with default  methods 
that open an widget, image


If we agree on that

- I can take all the  and turn them if necessary into 
examplar.


- extend Nautilus to send an inspect to the result of examplar 
tagged method.


I think that we can achieve a lot in terms of discovery with such 
simple changes.


Stef

PS: I reread the old thread and I think that this is a reasonable 
approach that makes


the pro instances (like me) and the pro examples showing some things 
(like me) happy.

Re: [Pharo-dev] /

[stepharo]

Hi all

I implemented the  to behave as suggested by torsten and it is 
available in less than 5 min (I loved it). An example is JUST a class 
method returning an instance.


CTGrid class >> grid22

"self grid22"
| grid1 |
grid1 := self new: 2.
grid1 atRow: 1 atColumn: 1 put: 1.
grid1 atRow: 1 atColumn: 2 put: 3.
grid1 atRow: 2 atColumn: 1 put: 2.
grid1 atRow: 2 atColumn: 2 put: 4.
^ grid1

You can use this method as any class method in the past. NOTHING new!!
So in particular your test can use it to build a fixture (yes reuse). 
You can use this method in several test cases (yes reuse).



Now nautilus supports nicely  methods: you can execute them 
and get a cool GTInspector open on them. So this is similar to the 
method exampleSomething from Nautilus point of view. And now people can 
use example to create/open/... their lovely examples (that may not 
return instances). And we get examplar methods that must return an 
instance but can behave as example from Nautilus perspective.


https://pharo.fogbugz.com/f/cases/18964/support-examplar

If you want to try you can load the CTGrid packages

ScriptLoader new unloadPackageNamed: 'Collections-Grid'.
ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'.
"Because there were not good and will be removed from the image"
Gofer it
url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main';
configurationOf: 'Grid';
loadStable

Click on class side of CTGrid and press the triangle and yes you get an 
inspector on this instance.


Stef





Le 18/8/16 à 14:38, stepharo a écrit :

Hi

In my projects I start to do the following:

I create  class method that returns an prototypical instance.

I use such methods in my tests as fixture.

Then I would like to have nautilus presenting to me the  
with a little triangle and when I press


on them I get an inspector on them.

This way I get the same behavior than with default  methods 
that open an widget, image


If we agree on that

- I can take all the  and turn them if necessary into 
examplar.


- extend Nautilus to send an inspect to the result of examplar 
tagged method.


I think that we can achieve a lot in terms of discovery with such 
simple changes.


Stef

PS: I reread the old thread and I think that this is a reasonable 
approach that makes


the pro instances (like me) and the pro examples showing some things 
(like me) happy.

Re: [Pharo-dev] /

[stepharo]

Hi

Why not use  pragma in the way you propose for ? 
Why we need two?


Apparently from the old discussion, people like  to prompt and 
open the example

when this is something visual. This is ok for me.
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.

Stef


2016-08-18 14:38 GMT+02:00 stepharo >:


Hi

In my projects I start to do the following:

I create  class method that returns an prototypical
instance.

I use such methods in my tests as fixture.

Then I would like to have nautilus presenting to me the 
with a little triangle and when I press

on them I get an inspector on them.

This way I get the same behavior than with default 
methods that open an widget, image

If we agree on that

- I can take all the  and turn them if necessary into
examplar.

- extend Nautilus to send an inspect to the result of examplar
tagged method.

I think that we can achieve a lot in terms of discovery with such
simple changes.

Stef

PS: I reread the old thread and I think that this is a reasonable
approach that makes

the pro instances (like me) and the pro examples showing some
things (like me) happy.

Re: [Pharo-dev] About PythonDocTest for Pharo

[stepharo]

As I already told you and the board, I will just leave if such a 
solution get pushed into Pharo.



Hi,

I like this problem very much. I think we are not leveraging the objects we 
have in the image. Tests can help, but they are way too disconnected from the 
code and they are not really useful for detailed questions.

I am also happy that you are considering the use of pragmas for this purpose.

As you know, Stefan Reichhart and I worked on the examples engine since a 
couple of years and I think we now start to have a working solution.

I do not want 5 pragmas and dependencies between methods and examples. KISS.
Pharo tends to forget KISS far too often recently.
You know exactly what I do not want: conceptual (and code) bloat.

It think it is KISS. If you only want one feature, you use exactly one pragma 
. Nothing else. If you want more, as people do, you can get more.

But, I won’t go into a debate now. First, I would like to present what exists 
and then you can form an opinion if you want.

Just a note: there already exists in the image a first implementation of 
GTExample, and this proved very useful for testing the inspector and spotter. 
However, this was introduced without proper discussion, and as we do not want 
to impose anything we will remove the whole 1400 lines of code of the GTExample 
implementation from the GT-Inspector package as it did not belong there anyway, 
and we will make the new one available separately outside of Pharo. In this 
way, people can look at it if they want and we can have a discussion if desired.



Because this would be a significant departure from tests, we first wanted to 
get a more thorough documentation of the current state before opening the 
discussion to the community to see how this can fit in Pharo or at least in the 
ecosystem. I think we will have this ready in a draft form in a couple of days, 
and it would be great to have a critical discussion about it at ESUG.

My plate is really full. I have a super long list of things that I want to 
discuss at ESUG.

Ok.

Doru




Stef

Cheers,
Doru



On Aug 18, 2016, at 1:32 PM, stepharo  wrote:

Tx serge

- I think that we should agree on the pragma or way to express it. May be we 
can do the same as in Python and use a comment instead of a pragma. I prefer a 
pragma because we can query them easily.

So any idea instead of




withExtension: aString

"Returns a new file reference with a different file extension"



^ self withPath: (self path withExtension: aString)


- then incrementally we can start taking on system for example FS and use it.

Stef


Le 18/8/16 à 11:51, Serge Stinckwich a écrit :

On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:

Hi guys

I'm fed up to get methods without comments and without little examples. In

+1 !
We can setup a small group of people interested to build examples at ESUG.


FileSystem, I wrote most of the comments and I tried to add an obvious
example:

basenameWithIndicator
 "Returns the basename with the indicator appended, i.e.
/foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
basenameWithIndicator is 'foo/'"

 ^ self basename , self indicator


Now let us look at:

withExtension: aString
 ^ self withPath: (self path withExtension: aString)


Nice comment :(

I would like to support PythonDoctest (yes we are not the only one to have
ideas let us face is dear friends)

+1

https://en.wikipedia.org/wiki/Doctest


def multiply(a, b):
 """
 >>> multiply(4, 3)
 12
 >>> multiply('a', 3)
 'aaa'
 """
 return a * b

Because we can make sure that the comments are accurate.


withExtension: aString

 "Returns a new file reference with a different file extension"

 

 ^ self withPath: (self path withExtension: aString)


It will help us to have a distinction between printOn: and displayString

Typically

 '/tmp/file.txt' asFileReference withExtension: 'log'

 printString is bad

 since it returns File @ '/tmp/file.log' which is not an reexecutable
expression



So let me know what you think.
 - tell me that we have already test unit (yes the ones I wrote too)
 => they do not have the same purpose

For me this is getting to be important.

Maybe a subset of Pharo could be defined as core with a kind of API
freeze, so we can spend some time
documenting the corresponding methods and classes.


--
www.tudorgirba.com
www.feenk.com

"Every thing has its own flow."










--
www.tudorgirba.com
www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

Re: [Pharo-dev] /

[Esteban Lorenzano]

example is meant to be something executable from the browser (and with a 
visible result) while “exemplar” will just provide a prototype. 

this is old discussion, sigh...

Esteban

> On 18 Aug 2016, at 16:25, Denis Kudriashov  wrote:
> 
> Hi
> 
> Why not use  pragma in the way you propose for ? Why we 
> need two?
> 
> 2016-08-18 14:38 GMT+02:00 stepharo  >:
> Hi
> 
> In my projects I start to do the following:
> 
> I create  class method that returns an prototypical instance.
> 
> I use such methods in my tests as fixture.
> 
> Then I would like to have nautilus presenting to me the  with a 
> little triangle and when I press
> 
> on them I get an inspector on them.
> 
> This way I get the same behavior than with default  methods that 
> open an widget, image
> 
> If we agree on that
> 
> - I can take all the  and turn them if necessary into examplar.
> 
> - extend Nautilus to send an inspect to the result of examplar tagged 
> method.
> 
> I think that we can achieve a lot in terms of discovery with such simple 
> changes.
> 
> Stef
> 
> PS: I reread the old thread and I think that this is a reasonable approach 
> that makes
> 
> the pro instances (like me) and the pro examples showing some things (like 
> me) happy.
> 
> 
> 

Re: [Pharo-dev] /

[Denis Kudriashov]

Hi

Why not use  pragma in the way you propose for ? Why we
need two?

2016-08-18 14:38 GMT+02:00 stepharo :

> Hi
>
> In my projects I start to do the following:
>
> I create  class method that returns an prototypical instance.
>
> I use such methods in my tests as fixture.
>
> Then I would like to have nautilus presenting to me the  with a
> little triangle and when I press
>
> on them I get an inspector on them.
>
> This way I get the same behavior than with default  methods that
> open an widget, image
>
> If we agree on that
>
> - I can take all the  and turn them if necessary into
> examplar.
>
> - extend Nautilus to send an inspect to the result of examplar tagged
> method.
>
> I think that we can achieve a lot in terms of discovery with such simple
> changes.
>
> Stef
>
> PS: I reread the old thread and I think that this is a reasonable approach
> that makes
>
> the pro instances (like me) and the pro examples showing some things (like
> me) happy.
>
>
>

Re: [Pharo-dev] About PythonDocTest for Pharo

[Tudor Girba]

Hi,

> On Aug 18, 2016, at 2:41 PM, stepharo  wrote:
> 
> Hi doru
> 
> 
>> Hi,
>> 
>> I like this problem very much. I think we are not leveraging the objects we 
>> have in the image. Tests can help, but they are way too disconnected from 
>> the code and they are not really useful for detailed questions.
>> 
>> I am also happy that you are considering the use of pragmas for this purpose.
>> 
>> As you know, Stefan Reichhart and I worked on the examples engine since a 
>> couple of years and I think we now start to have a working solution.
> I do not want 5 pragmas and dependencies between methods and examples. KISS.
> Pharo tends to forget KISS far too often recently.
> You know exactly what I do not want: conceptual (and code) bloat.

It think it is KISS. If you only want one feature, you use exactly one pragma 
. Nothing else. If you want more, as people do, you can get more.

But, I won’t go into a debate now. First, I would like to present what exists 
and then you can form an opinion if you want.

Just a note: there already exists in the image a first implementation of 
GTExample, and this proved very useful for testing the inspector and spotter. 
However, this was introduced without proper discussion, and as we do not want 
to impose anything we will remove the whole 1400 lines of code of the GTExample 
implementation from the GT-Inspector package as it did not belong there anyway, 
and we will make the new one available separately outside of Pharo. In this 
way, people can look at it if they want and we can have a discussion if desired.


>> Because this would be a significant departure from tests, we first wanted to 
>> get a more thorough documentation of the current state before opening the 
>> discussion to the community to see how this can fit in Pharo or at least in 
>> the ecosystem. I think we will have this ready in a draft form in a couple 
>> of days, and it would be great to have a critical discussion about it at 
>> ESUG.
> My plate is really full. I have a super long list of things that I want to 
> discuss at ESUG.

Ok.

Doru



> Stef
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 18, 2016, at 1:32 PM, stepharo  wrote:
>>> 
>>> Tx serge
>>> 
>>> - I think that we should agree on the pragma or way to express it. May be 
>>> we can do the same as in Python and use a comment instead of a pragma. I 
>>> prefer a pragma because we can query them easily.
>>> 
>>> So any idea instead of
>>>
>>> 
>>>
>>> 
>>> withExtension: aString
>>> 
>>>"Returns a new file reference with a different file extension"
>>> 
>>>>> 
>>>value: '/tmp/file.log' asFileReference >
>>> 
>>>^ self withPath: (self path withExtension: aString)
>>> 
>>> 
>>> - then incrementally we can start taking on system for example FS and use 
>>> it.
>>> 
>>> Stef
>>> 
>>> 
>>> Le 18/8/16 à 11:51, Serge Stinckwich a écrit :
 On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:
> Hi guys
> 
> I'm fed up to get methods without comments and without little examples. In
 +1 !
 We can setup a small group of people interested to build examples at ESUG.
 
> FileSystem, I wrote most of the comments and I tried to add an obvious
> example:
> 
> basenameWithIndicator
> "Returns the basename with the indicator appended, i.e.
> /foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
> basenameWithIndicator is 'foo/'"
> 
> ^ self basename , self indicator
> 
> 
> Now let us look at:
> 
> withExtension: aString
> ^ self withPath: (self path withExtension: aString)
> 
> 
> Nice comment :(
> 
> I would like to support PythonDoctest (yes we are not the only one to have
> ideas let us face is dear friends)
 +1
 
 https://en.wikipedia.org/wiki/Doctest
 
> def multiply(a, b):
> """
> >>> multiply(4, 3)
> 12
> >>> multiply('a', 3)
> 'aaa'
> """
> return a * b
> 
> Because we can make sure that the comments are accurate.
> 
> 
> withExtension: aString
> 
> "Returns a new file reference with a different file extension"
> 
>  
> value: '/tmp/file.log' asFileReference >
> 
> ^ self withPath: (self path withExtension: aString)
> 
> 
> It will help us to have a distinction between printOn: and displayString
> 
> Typically
> 
> '/tmp/file.txt' asFileReference withExtension: 'log'
> 
> printString is bad
> 
> since it returns File @ '/tmp/file.log' which is not an reexecutable
> expression
> 
> 
> 
> So let me know what you think.
> - tell me that we have already test unit (yes the ones I wrote too)
> => they do not have the same purpose
> 
> For me this is getting to be important.
 Maybe a subset of Pharo 

Re: [Pharo-dev] About PythonDocTest for Pharo

[stepharo]

Hi doru



Hi,

I like this problem very much. I think we are not leveraging the objects we 
have in the image. Tests can help, but they are way too disconnected from the 
code and they are not really useful for detailed questions.

I am also happy that you are considering the use of pragmas for this purpose.

As you know, Stefan Reichhart and I worked on the examples engine since a 
couple of years and I think we now start to have a working solution.
I do not want 5 pragmas and dependencies between methods and examples. 
KISS.

Pharo tends to forget KISS far too often recently.
You know exactly what I do not want: conceptual (and code) bloat.

Because this would be a significant departure from tests, we first wanted to 
get a more thorough documentation of the current state before opening the 
discussion to the community to see how this can fit in Pharo or at least in the 
ecosystem. I think we will have this ready in a draft form in a couple of days, 
and it would be great to have a critical discussion about it at ESUG.
My plate is really full. I have a super long list of things that I want 
to discuss at ESUG.


Stef

Cheers,
Doru



On Aug 18, 2016, at 1:32 PM, stepharo  wrote:

Tx serge

- I think that we should agree on the pragma or way to express it. May be we 
can do the same as in Python and use a comment instead of a pragma. I prefer a 
pragma because we can query them easily.

So any idea instead of




withExtension: aString

"Returns a new file reference with a different file extension"



^ self withPath: (self path withExtension: aString)


- then incrementally we can start taking on system for example FS and use it.

Stef


Le 18/8/16 à 11:51, Serge Stinckwich a écrit :

On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:

Hi guys

I'm fed up to get methods without comments and without little examples. In

+1 !
We can setup a small group of people interested to build examples at ESUG.


FileSystem, I wrote most of the comments and I tried to add an obvious
example:

basenameWithIndicator
 "Returns the basename with the indicator appended, i.e.
/foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
basenameWithIndicator is 'foo/'"

 ^ self basename , self indicator


Now let us look at:

withExtension: aString
 ^ self withPath: (self path withExtension: aString)


Nice comment :(

I would like to support PythonDoctest (yes we are not the only one to have
ideas let us face is dear friends)

+1

https://en.wikipedia.org/wiki/Doctest


def multiply(a, b):
 """
 >>> multiply(4, 3)
 12
 >>> multiply('a', 3)
 'aaa'
 """
 return a * b

Because we can make sure that the comments are accurate.


withExtension: aString

 "Returns a new file reference with a different file extension"

 

 ^ self withPath: (self path withExtension: aString)


It will help us to have a distinction between printOn: and displayString

Typically

 '/tmp/file.txt' asFileReference withExtension: 'log'

 printString is bad

 since it returns File @ '/tmp/file.log' which is not an reexecutable
expression



So let me know what you think.
 - tell me that we have already test unit (yes the ones I wrote too)
 => they do not have the same purpose

For me this is getting to be important.

Maybe a subset of Pharo could be defined as core with a kind of API
freeze, so we can spend some time
documenting the corresponding methods and classes.




--
www.tudorgirba.com
www.feenk.com

"Every thing has its own flow."

[Pharo-dev] /

[stepharo]

Hi

In my projects I start to do the following:

I create  class method that returns an prototypical instance.

I use such methods in my tests as fixture.

Then I would like to have nautilus presenting to me the  with 
a little triangle and when I press


on them I get an inspector on them.

This way I get the same behavior than with default  methods 
that open an widget, image


If we agree on that

- I can take all the  and turn them if necessary into 
examplar.


- extend Nautilus to send an inspect to the result of examplar 
tagged method.


I think that we can achieve a lot in terms of discovery with such simple 
changes.


Stef

PS: I reread the old thread and I think that this is a reasonable 
approach that makes


the pro instances (like me) and the pro examples showing some things 
(like me) happy.

Re: [Pharo-dev] About PythonDocTest for Pharo

[Tudor Girba]

Hi,

I like this problem very much. I think we are not leveraging the objects we 
have in the image. Tests can help, but they are way too disconnected from the 
code and they are not really useful for detailed questions.

I am also happy that you are considering the use of pragmas for this purpose.

As you know, Stefan Reichhart and I worked on the examples engine since a 
couple of years and I think we now start to have a working solution.

Because this would be a significant departure from tests, we first wanted to 
get a more thorough documentation of the current state before opening the 
discussion to the community to see how this can fit in Pharo or at least in the 
ecosystem. I think we will have this ready in a draft form in a couple of days, 
and it would be great to have a critical discussion about it at ESUG.

Cheers,
Doru


> On Aug 18, 2016, at 1:32 PM, stepharo  wrote:
> 
> Tx serge
> 
> - I think that we should agree on the pragma or way to express it. May be we 
> can do the same as in Python and use a comment instead of a pragma. I prefer 
> a pragma because we can query them easily.
> 
> So any idea instead of
>
> 
>
> 
> withExtension: aString
> 
>"Returns a new file reference with a different file extension"
> 
> 
>value: '/tmp/file.log' asFileReference >
> 
>^ self withPath: (self path withExtension: aString)
> 
> 
> - then incrementally we can start taking on system for example FS and use it.
> 
> Stef
> 
> 
> Le 18/8/16 à 11:51, Serge Stinckwich a écrit :
>> On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:
>>> Hi guys
>>> 
>>> I'm fed up to get methods without comments and without little examples. In
>> +1 !
>> We can setup a small group of people interested to build examples at ESUG.
>> 
>>> FileSystem, I wrote most of the comments and I tried to add an obvious
>>> example:
>>> 
>>> basenameWithIndicator
>>> "Returns the basename with the indicator appended, i.e.
>>> /foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
>>> basenameWithIndicator is 'foo/'"
>>> 
>>> ^ self basename , self indicator
>>> 
>>> 
>>> Now let us look at:
>>> 
>>> withExtension: aString
>>> ^ self withPath: (self path withExtension: aString)
>>> 
>>> 
>>> Nice comment :(
>>> 
>>> I would like to support PythonDoctest (yes we are not the only one to have
>>> ideas let us face is dear friends)
>> +1
>> 
>> https://en.wikipedia.org/wiki/Doctest
>> 
>>> def multiply(a, b):
>>> """
>>> >>> multiply(4, 3)
>>> 12
>>> >>> multiply('a', 3)
>>> 'aaa'
>>> """
>>> return a * b
>>> 
>>> Because we can make sure that the comments are accurate.
>>> 
>>> 
>>> withExtension: aString
>>> 
>>> "Returns a new file reference with a different file extension"
>>> 
>>> >> 
>>> value: '/tmp/file.log' asFileReference >
>>> 
>>> ^ self withPath: (self path withExtension: aString)
>>> 
>>> 
>>> It will help us to have a distinction between printOn: and displayString
>>> 
>>> Typically
>>> 
>>> '/tmp/file.txt' asFileReference withExtension: 'log'
>>> 
>>> printString is bad
>>> 
>>> since it returns File @ '/tmp/file.log' which is not an reexecutable
>>> expression
>>> 
>>> 
>>> 
>>> So let me know what you think.
>>> - tell me that we have already test unit (yes the ones I wrote too)
>>> => they do not have the same purpose
>>> 
>>> For me this is getting to be important.
>> Maybe a subset of Pharo could be defined as core with a kind of API
>> freeze, so we can spend some time
>> documenting the corresponding methods and classes.
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Every thing has its own flow."

Re: [Pharo-dev] About PythonDocTest for Pharo

[stepharo]

Tx serge

- I think that we should agree on the pragma or way to express it. May 
be we can do the same as in Python and use a comment instead of a 
pragma. I prefer a pragma because we can query them easily.


So any idea instead of




withExtension: aString

"Returns a new file reference with a different file extension"



^ self withPath: (self path withExtension: aString)


- then incrementally we can start taking on system for example FS and 
use it.


Stef


Le 18/8/16 à 11:51, Serge Stinckwich a écrit :

On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:

Hi guys

I'm fed up to get methods without comments and without little examples. In

+1 !
We can setup a small group of people interested to build examples at ESUG.


FileSystem, I wrote most of the comments and I tried to add an obvious
example:

basenameWithIndicator
 "Returns the basename with the indicator appended, i.e.
/foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
basenameWithIndicator is 'foo/'"

 ^ self basename , self indicator


Now let us look at:

withExtension: aString
 ^ self withPath: (self path withExtension: aString)


Nice comment :(

I would like to support PythonDoctest (yes we are not the only one to have
ideas let us face is dear friends)

+1

https://en.wikipedia.org/wiki/Doctest


def multiply(a, b):
 """
 >>> multiply(4, 3)
 12
 >>> multiply('a', 3)
 'aaa'
 """
 return a * b

Because we can make sure that the comments are accurate.


withExtension: aString

 "Returns a new file reference with a different file extension"

 

 ^ self withPath: (self path withExtension: aString)


It will help us to have a distinction between printOn: and displayString

Typically

 '/tmp/file.txt' asFileReference withExtension: 'log'

 printString is bad

 since it returns File @ '/tmp/file.log' which is not an reexecutable
expression



So let me know what you think.
 - tell me that we have already test unit (yes the ones I wrote too)
 => they do not have the same purpose

For me this is getting to be important.

Maybe a subset of Pharo could be defined as core with a kind of API
freeze, so we can spend some time
documenting the corresponding methods and classes.

[Pharo-dev] Abotu FileReference objects as autoevaluating ones

[stepharo]

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

Re: [Pharo-dev] Experience with FileSystem => proposal for improving user experience

[stepharo]

 Proposal two:

 We could add withoutBasename

 withoutBasename

 ^ self parent


I don't see a point of this method, why not just use #parent?

This is a helper.
parent is good for navigation now withoutBasename is good for manipulation
of parts.
It took me a while to think that I should use parent because I was looking
for something else.

So the problem then is a documentational one.

No I do not want to read a pdf to get it.



You convinced me this library is perfect and I will keep these extensions
for me.

My point is, do we want to add every possible variation and helper for every 
use case a person can think of?
I believe last year there was a lot of effort put into cleaning up String api; 
did String end up where it is with similar approach? I don't know, I haven't 
been here, that's why I am asking.

Also in other languages it is common to use `dirname` instead of parent => "asking 
for the directory name of what you have".

But as you point out in another thread, this is a documentational issue, and 
not a missing method.


I do not want to be forced to read a doc to use a system.
The system itself should be discoverable and it is not in this case.
This is why I will not write documentation of others code anymore.

 Proposal three:

 Not sure that it is worth

 (note that this is not a rename)

 withNewExtension: anExtension
 ^ self parent / self basenameWithoutExtension
 withExtension: anExtension


Is this somehow different than using #withExtension: directly?

Obviously since I'm with Sven one of the few persons that seem concerned
with such aspect.

Please, just so there is no misunderstanding. I do care about it and I am not 
fundamentally against it.
You sent your proposals, I've added my view, and I expect other people will add 
theirs, so we can collectively discuss this and act on it.


You see I could have pushed this change without discussing.
I can understand that proposal 3 is useless since this is the same.
But the others have a value to me. Now I added them in my private 
extensions and this is good.


Peter

Re: [Pharo-dev] About PythonDocTest for Pharo

[Serge Stinckwich]

On Thu, Aug 18, 2016 at 9:34 AM, stepharo  wrote:
> Hi guys
>
> I'm fed up to get methods without comments and without little examples. In

+1 !
We can setup a small group of people interested to build examples at ESUG.

> FileSystem, I wrote most of the comments and I tried to add an obvious
> example:
>
> basenameWithIndicator
> "Returns the basename with the indicator appended, i.e.
> /foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo
> basenameWithIndicator is 'foo/'"
>
> ^ self basename , self indicator
>
>
> Now let us look at:
>
> withExtension: aString
> ^ self withPath: (self path withExtension: aString)
>
>
> Nice comment :(
>
> I would like to support PythonDoctest (yes we are not the only one to have
> ideas let us face is dear friends)

+1

https://en.wikipedia.org/wiki/Doctest

> def multiply(a, b):
> """
> >>> multiply(4, 3)
> 12
> >>> multiply('a', 3)
> 'aaa'
> """
> return a * b
>
> Because we can make sure that the comments are accurate.
>
>
> withExtension: aString
>
> "Returns a new file reference with a different file extension"
>
> 
> value: '/tmp/file.log' asFileReference >
>
> ^ self withPath: (self path withExtension: aString)
>
>
> It will help us to have a distinction between printOn: and displayString
>
> Typically
>
> '/tmp/file.txt' asFileReference withExtension: 'log'
>
> printString is bad
>
> since it returns File @ '/tmp/file.log' which is not an reexecutable
> expression
>
>
>
> So let me know what you think.
> - tell me that we have already test unit (yes the ones I wrote too)
> => they do not have the same purpose
>
> For me this is getting to be important.

Maybe a subset of Pharo could be defined as core with a kind of API
freeze, so we can spend some time
documenting the corresponding methods and classes.

-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] Experience with FileSystem => proposal for improving user experience

[Peter Uhnak]

On Thu, Aug 18, 2016 at 09:35:28AM +0200, stepharo wrote:

Just so you don't misunderstand… I am not opposing those changes, I am just 
asking.

> > 
> > Proposal one:
> > 
> > We could add withoutExtension
> > 
> > withoutExtension
> > 
> >^  (self parent / self basenameWithoutExtension)
> > 
> > 
> > What is the use case for this?
> To get everything except the extension. Is it not obvious?
> How do you did it else?

What I mean is, when would you use such method?
The only use case I can see (after using FS libs for years) is to change 
extension, but we already have a method for that.

> 
> > Proposal two:
> > 
> > We could add withoutBasename
> > 
> > withoutBasename
> > 
> > ^ self parent
> > 
> > 
> > I don't see a point of this method, why not just use #parent?
> This is a helper.
> parent is good for navigation now withoutBasename is good for manipulation
> of parts.
> It took me a while to think that I should use parent because I was looking
> for something else.

So the problem then is a documentational one.

> You convinced me this library is perfect and I will keep these extensions
> for me.

My point is, do we want to add every possible variation and helper for every 
use case a person can think of?
I believe last year there was a lot of effort put into cleaning up String api; 
did String end up where it is with similar approach? I don't know, I haven't 
been here, that's why I am asking.

Also in other languages it is common to use `dirname` instead of parent => 
"asking for the directory name of what you have".

But as you point out in another thread, this is a documentational issue, and 
not a missing method.

> > 
> > Proposal three:
> > 
> > Not sure that it is worth
> > 
> > (note that this is not a rename)
> > 
> > withNewExtension: anExtension
> > ^ self parent / self basenameWithoutExtension
> > withExtension: anExtension
> > 
> > 
> > Is this somehow different than using #withExtension: directly?

> Obviously since I'm with Sven one of the few persons that seem concerned
> with such aspect.

Please, just so there is no misunderstanding. I do care about it and I am not 
fundamentally against it.
You sent your proposals, I've added my view, and I expect other people will add 
theirs, so we can collectively discuss this and act on it.

Peter

[Pharo-dev] Email bankruptcy: Can not keep up with mails

[Marcus Denker]

Hi,

Over the summer with holidays email accumulated… I started to get them down but 
there a re now still >300 unread
Pharo mails left.

I decided I will just delete them… if you expected an answer/input from me —> 
send me a private mail.

Marcus

Re: [Pharo-dev] Experience with FileSystem => proposal for improving user experience

[stepharo]

Le 17/8/16 à 22:11, Peter Uhnák a écrit :



On Wed, Aug 17, 2016 at 9:44 PM, stepharo > wrote:


Hi

I have a file


/Users/ducasse/PharoMooc/Subtitles/W1/C019SD-W1-sous-titres-EN/EN_C019SD-W1-S1.srt

and I would like to generate a new one with a different extension


/Users/ducasse/PharoMooc/Subtitles/W1/C019SD-W1-sous-titres-EN/EN_C019SD-W1-S1.vtt


Why not just myFile withExtension: 'vtt'


If you see my code you will see that I could not guess that it was 
working on a fullpath.

Of course since I did not add a proper comment to this method, there is none
and learning is always more difficult.

I really hate that we have to read and understand the implementation of 
a method to understand

what is does.

e.g.

f := '/tmp/file.txt' asFileReference.
"File @ /tmp/file.txt"
f withExtension: 'log'
"File @ /tmp/file.log"


Now I'm browsing FileReference and I do not find an easy way to do it.


It's an AbstractFileReference method.



/Users/ducasse/PharoMooc/Subtitles/W1/C019SD-W1-sous-titres-EN/


Why not just #parent? Some languages also use #dirname.


/Users/ducasse/PharoMooc/Subtitles/W1/C019SD-W1-sous-titres-EN/EN_C019SD-W1-S1


This one is the one hard to get… but how often do you need it? Is it 
worth the extra method in the API?

If just for changing the extension, then there's #withExtension:

Proposal one:

We could add withoutExtension

withoutExtension

   ^  (self parent / self basenameWithoutExtension)


What is the use case for this?

To get everything except the extension. Is it not obvious?
How do you did it else?


Proposal two:

We could add withoutBasename

withoutBasename

^ self parent


I don't see a point of this method, why not just use #parent?

This is a helper.
parent is good for navigation now withoutBasename is good for 
manipulation of parts.
It took me a while to think that I should use parent because I was 
looking for something else.


You convinced me this library is perfect and I will keep these 
extensions for me.


Proposal three:

Not sure that it is worth

(note that this is not a rename)

withNewExtension: anExtension
^ self parent / self basenameWithoutExtension
withExtension: anExtension


Is this somehow different than using #withExtension: directly?

It is the same. I will add a real comment to this method.
I hate so much libraries that do not have comments (I'm fed up to lose 
my time documenting undocumented library).


Since I stupidly wrote also the FS chapter I missed such scenario since 
I was exhausted to reverse engineer and comment.
So now this is not in the documentation. Easy and revealing the poor 
coverage of our documentation.
Obviously since I'm with Sven one of the few persons that seem concerned 
with such aspect.

Now I will not work on documenting others code anymore.


Peter

[Pharo-dev] About PythonDocTest for Pharo

[stepharo]

Hi guys

I'm fed up to get methods without comments and without little examples. 
In FileSystem, I wrote most of the comments and I tried to add an 
obvious example:


basenameWithIndicator
"Returns the basename with the indicator appended, i.e. 
/foo/gloops.taz basenameWithIndicator is 'gloops.taz', whereras /foo 
basenameWithIndicator is 'foo/'"


^ self basename , self indicator


Now let us look at:

withExtension: aString
^ self withPath: (self path withExtension: aString)


Nice comment :(

I would like to support PythonDoctest (yes we are not the only one to 
have ideas let us face is dear friends)


def multiply(a, b):
"""
>>> multiply(4, 3)
12
>>> multiply('a', 3)
'aaa'
"""
return a * b

Because we can make sure that the comments are accurate.


withExtension: aString

"Returns a new file reference with a different file extension"



^ self withPath: (self path withExtension: aString)


It will help us to have a distinction between printOn: and displayString

Typically

'/tmp/file.txt' asFileReference withExtension: 'log'

printString is bad

since it returns File @ '/tmp/file.log' which is not an 
reexecutable expression




So let me know what you think.
- tell me that we have already test unit (yes the ones I wrote too)
=> they do not have the same purpose

For me this is getting to be important.


Stef

[Pharo-dev] [Issue tracker] push on old issues needed

[Marcus Denker]

Hi,

The issue tracker is accumulating issues fast… lots of them a half-finished, 
yet saw no action for quite some time…
Keep in mind that if *you* will not look at an issue you where involved in (or 
even created), chances are that *nobody*
will look at it… it is your job to push it forward. (e.g. ask for help on the 
mailinglist or Slack…)

So please, everyone, have a look at old issues and push those forward that are 
ready or close those that are not
relevant anymore… **every single issue resolved helps!!**

https://pharo.fogbugz.com/f/filters/57/All-newest-first 



Marcus

[Pharo-dev] [pharo-project/pharo-core] 5b4669: 60187

[GitHub]

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

  Changed paths:
M 
Collections-Tests.package/SplitJoinTest.class/instance/running/testSplitJoinBoundaryCases.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/README.md
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/class/accessing/uniqueIdentifierName.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/class/testing/checksClass.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/definition.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/accessing/group.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/accessing/name.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/accessing/rationale.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/accessing/resultClass.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/running/basicCheck_.st
R 
Refactoring-Critics.package/RBClassInstVarNotInitializedRule.class/instance/running/checkClass_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60186.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60187.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60186.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60187.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Slot.package/extension/String/instance/asSlotCollection.st

  Log Message:
  ---
  60187
18953 remove Regex dependency from SplitJoinTest>>#testSplitJoinBoundaryCases
https://pharo.fogbugz.com/f/cases/18953

18916 simplify asSlotCollection for bootstrap
https://pharo.fogbugz.com/f/cases/18916

18938 Remove RBClassInstVarNotInitializedRule, it is a bad rule
https://pharo.fogbugz.com/f/cases/18938

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