Re: [Pharo-users] [Pharo-dev] [ann] GTExamples alpha

[Tudor Girba]

Hi,


> On Aug 26, 2016, at 10:01 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-26 0:51 GMT+02:00 Tudor Girba :
> Hi,
> 
> I just tried again, and the latest GToolkit image does contain FileSystem 
> class >> gtExampleZip:
> 
> Yes, it is there, but not listed under the FileSystem class package.
> If you open Nautilus for all gt examples (world menu -> GT Examples -> Browse 
> all examples)
> A Nautilus browser opens, but it shows mostly GT-Packages.
> And if you just open a new Nautilus window, select the FileSystem-Core 
> package and choose "Browse All Examples of Package FileSystem-Core from the 
> GT-Examples menu.
> you won't see any example. 
> It is "impractical", that you need to select the GT-Examples-Examples package 
> to actuall find the FileSystem-Core examples (and others).
> 
> Or in short
> The FileSystem examples are not in the FileSystem *package*
> And the same for other examples, you can not find all "Collections"-Examples 
> by selecting the Collection package and choose "Browse All Examples”

Indeed. Good catch. This should be rethought.

Cheers,
Doru


> Inspect this:
> Smalltalk gtExamplesContained select: [ :each |
> each method methodClass instanceSide = FileSystem ]
> 
> This is the image:
> https://ci.inria.fr/moose/job/gtoolkit/5595/artifact/gtoolkit.zip
> 
> Cheers,
> Doru
> 
> 
> > On Aug 25, 2016, at 11:40 PM, Tudor Girba  wrote:
> >
> > Hi Nicolai,
> >
> > Thanks a lot for the feedback. Please let’s continue. See more inline.
> >
> >> On Aug 25, 2016, at 6:34 PM, Nicolai Hess  wrote:
> >>
> >>
> >>
> >> 2016-08-25 8:47 GMT+02:00 Tudor Girba :
> >> Hi,
> >>
> >> Hi Doru,
> >> some questions and feedback ( I am sorry for my tone or if this sounds 
> >> negative, it isn't meant to be)
> >>
> >> Over the last coupe of years Stefan Reichhart and the rest of the GT team 
> >> worked on an implementation of examples. The work is inspired from 
> >> previous work done by Markus Gaelli and Adrian Kuhn.
> >>
> >> As one of the goals of GT is to offer a live programming environment,
> >>
> >> Isn't this what we already have, a live programming environment, I think 
> >> for newcomers (and maybe others) this needs to make be more clear, how is 
> >> different, what gap are you trying to fill.
> >>
> >> one important issue is how to move from the static code to live objects as 
> >> fast as possible.
> >>
> >> Isn't code always "static" and aren't objects always "live", how do play 
> >> gtExamples any role in this?
> >
> > What I meant is that I want to be as little as possible in the static code 
> > browser. Instead I want to write code in the presence of a bounded “self” 
> > which happens either in a debugger or in an inspector.
> >
> > The gap that examples fill is that when I look at a static code and I have 
> > examples about it, I can possibly jump to those examples and code against 
> > their result. So, instead of coding a method about a FileReference in the 
> > code browser, I will code it against an instance of a FileReference. Hence, 
> > we make live programming easier to achieve.
> >
> >
> >> That is why we worked on this library as a solution to provide a link 
> >> between the static code and live objects.
> >>
> >> From my understanding, I think this "link" between code an objects is the 
> >> real valuable new point. This is the great thing about gtExamples. link 
> >> from code (the example methods itself or methods refering a class
> >> to an example object/instance that can be inspected (the raw  object or an 
> >> object specific inspector pane).
> >> This is what I would consider the real step forward. You see a method 
> >> refering to class TextModel and Nautilus or any other tool not only offers 
> >> a method to browse all Users of this class, but too, a dedicated
> >> list of "example methods" where every example has a view for this example 
> >> instance that let the user show and interact (even for non-visual objects 
> >> through the "evaluater pane", or just see the code creating this
> >> example.
> >
> > Exactly.
> >
> >> We really miss examples, I often see questions on the mailing list 
> >> (especially about spect) that can be explained easily with an example. And 
> >> even worse, often the examples already exists, they just aren't as visible.
> >
> > Exactly. These examples are particularly amplified by the fact that we have 
> > an inspector that can provide a reacher experience through different views.
> >
> >
> >> Furthermore, this examples library also enables the definition of 
> >> assertions on the examples, and this provides the possibility of 
> >> rethinking the way we construct tests throughout our system. Tests are 
> >> great as they help us create live objects and then to assert live 
> >> properties.
> >>
> >> This whole thing sounds as if Unit-Test were a good idea but not the way 
> >> 

Re: [Pharo-users] [Pharo-dev] [ann] GTExamples alpha

[Nicolai Hess]

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

> Hi,
>
> I just tried again, and the latest GToolkit image does contain FileSystem
> class >> gtExampleZip:
>

Yes, it is there, but not listed under the FileSystem class package.
If you open Nautilus for all gt examples (world menu -> GT Examples ->
Browse all examples)
A Nautilus browser opens, but it shows mostly GT-Packages.
And if you just open a new Nautilus window, select the FileSystem-Core
package and choose "Browse All Examples of Package FileSystem-Core from the
GT-Examples menu.
you won't see any example.
It is "impractical", that you need to select the GT-Examples-Examples
package to actuall find the FileSystem-Core examples (and others).

Or in short
The FileSystem examples are not in the FileSystem *package*
And the same for other examples, you can not find all
"Collections"-Examples by selecting the Collection package and choose
"Browse All Examples"


>
> Inspect this:
> Smalltalk gtExamplesContained select: [ :each |
> each method methodClass instanceSide = FileSystem ]
>
> This is the image:
> https://ci.inria.fr/moose/job/gtoolkit/5595/artifact/gtoolkit.zip
>
> Cheers,
> Doru
>
>
> > On Aug 25, 2016, at 11:40 PM, Tudor Girba  wrote:
> >
> > Hi Nicolai,
> >
> > Thanks a lot for the feedback. Please let’s continue. See more inline.
> >
> >> On Aug 25, 2016, at 6:34 PM, Nicolai Hess 
> wrote:
> >>
> >>
> >>
> >> 2016-08-25 8:47 GMT+02:00 Tudor Girba :
> >> Hi,
> >>
> >> Hi Doru,
> >> some questions and feedback ( I am sorry for my tone or if this sounds
> negative, it isn't meant to be)
> >>
> >> Over the last coupe of years Stefan Reichhart and the rest of the GT
> team worked on an implementation of examples. The work is inspired from
> previous work done by Markus Gaelli and Adrian Kuhn.
> >>
> >> As one of the goals of GT is to offer a live programming environment,
> >>
> >> Isn't this what we already have, a live programming environment, I
> think for newcomers (and maybe others) this needs to make be more clear,
> how is different, what gap are you trying to fill.
> >>
> >> one important issue is how to move from the static code to live objects
> as fast as possible.
> >>
> >> Isn't code always "static" and aren't objects always "live", how do
> play gtExamples any role in this?
> >
> > What I meant is that I want to be as little as possible in the static
> code browser. Instead I want to write code in the presence of a bounded
> “self” which happens either in a debugger or in an inspector.
> >
> > The gap that examples fill is that when I look at a static code and I
> have examples about it, I can possibly jump to those examples and code
> against their result. So, instead of coding a method about a FileReference
> in the code browser, I will code it against an instance of a FileReference.
> Hence, we make live programming easier to achieve.
> >
> >
> >> That is why we worked on this library as a solution to provide a link
> between the static code and live objects.
> >>
> >> From my understanding, I think this "link" between code an objects is
> the real valuable new point. This is the great thing about gtExamples. link
> from code (the example methods itself or methods refering a class
> >> to an example object/instance that can be inspected (the raw  object or
> an object specific inspector pane).
> >> This is what I would consider the real step forward. You see a method
> refering to class TextModel and Nautilus or any other tool not only offers
> a method to browse all Users of this class, but too, a dedicated
> >> list of "example methods" where every example has a view for this
> example instance that let the user show and interact (even for non-visual
> objects through the "evaluater pane", or just see the code creating this
> >> example.
> >
> > Exactly.
> >
> >> We really miss examples, I often see questions on the mailing list
> (especially about spect) that can be explained easily with an example. And
> even worse, often the examples already exists, they just aren't as visible.
> >
> > Exactly. These examples are particularly amplified by the fact that we
> have an inspector that can provide a reacher experience through different
> views.
> >
> >
> >> Furthermore, this examples library also enables the definition of
> assertions on the examples, and this provides the possibility of rethinking
> the way we construct tests throughout our system. Tests are great as they
> help us create live objects and then to assert live properties.
> >>
> >> This whole thing sounds as if Unit-Test were a good idea but not the
> way that they are used today, I strongly disagree. I don't see this as a
> "rethinking the way we construct tests", yes, we can
> >> augment the current set of tests with addtional assertions on live
> objects, but this is not a replacement.
> >> "Tests are great as they help us create live objects" 

Re: [Pharo-users] [Pharo-dev] [ann] GTExamples alpha

[Tudor Girba]

Hi,

I just tried again, and the latest GToolkit image does contain FileSystem class 
>> gtExampleZip:

Inspect this:
Smalltalk gtExamplesContained select: [ :each |
each method methodClass instanceSide = FileSystem ]

This is the image:
https://ci.inria.fr/moose/job/gtoolkit/5595/artifact/gtoolkit.zip

Cheers,
Doru


> On Aug 25, 2016, at 11:40 PM, Tudor Girba  wrote:
> 
> Hi Nicolai,
> 
> Thanks a lot for the feedback. Please let’s continue. See more inline.
> 
>> On Aug 25, 2016, at 6:34 PM, Nicolai Hess  wrote:
>> 
>> 
>> 
>> 2016-08-25 8:47 GMT+02:00 Tudor Girba :
>> Hi,
>> 
>> Hi Doru,
>> some questions and feedback ( I am sorry for my tone or if this sounds 
>> negative, it isn't meant to be)
>> 
>> Over the last coupe of years Stefan Reichhart and the rest of the GT team 
>> worked on an implementation of examples. The work is inspired from previous 
>> work done by Markus Gaelli and Adrian Kuhn.
>> 
>> As one of the goals of GT is to offer a live programming environment, 
>> 
>> Isn't this what we already have, a live programming environment, I think for 
>> newcomers (and maybe others) this needs to make be more clear, how is 
>> different, what gap are you trying to fill.
>> 
>> one important issue is how to move from the static code to live objects as 
>> fast as possible. 
>> 
>> Isn't code always "static" and aren't objects always "live", how do play 
>> gtExamples any role in this?
> 
> What I meant is that I want to be as little as possible in the static code 
> browser. Instead I want to write code in the presence of a bounded “self” 
> which happens either in a debugger or in an inspector.
> 
> The gap that examples fill is that when I look at a static code and I have 
> examples about it, I can possibly jump to those examples and code against 
> their result. So, instead of coding a method about a FileReference in the 
> code browser, I will code it against an instance of a FileReference. Hence, 
> we make live programming easier to achieve.
> 
> 
>> That is why we worked on this library as a solution to provide a link 
>> between the static code and live objects.
>> 
>> From my understanding, I think this "link" between code an objects is the 
>> real valuable new point. This is the great thing about gtExamples. link from 
>> code (the example methods itself or methods refering a class
>> to an example object/instance that can be inspected (the raw  object or an 
>> object specific inspector pane).
>> This is what I would consider the real step forward. You see a method 
>> refering to class TextModel and Nautilus or any other tool not only offers a 
>> method to browse all Users of this class, but too, a dedicated
>> list of "example methods" where every example has a view for this example 
>> instance that let the user show and interact (even for non-visual objects 
>> through the "evaluater pane", or just see the code creating this
>> example.
> 
> Exactly.
> 
>> We really miss examples, I often see questions on the mailing list 
>> (especially about spect) that can be explained easily with an example. And 
>> even worse, often the examples already exists, they just aren't as visible.
> 
> Exactly. These examples are particularly amplified by the fact that we have 
> an inspector that can provide a reacher experience through different views.
> 
> 
>> Furthermore, this examples library also enables the definition of assertions 
>> on the examples, and this provides the possibility of rethinking the way we 
>> construct tests throughout our system. Tests are great as they help us 
>> create live objects and then to assert live properties.
>> 
>> This whole thing sounds as if Unit-Test were a good idea but not the way 
>> that they are used today, I strongly disagree. I don't see this as a 
>> "rethinking the way we construct tests", yes, we can
>> augment the current set of tests with addtional assertions on live objects, 
>> but this is not a replacement.
>> "Tests are great as they help us create live objects" This is not my only 
>> purpose for writing tests, often unit-tests cover methods and "private-apis" 
>> not even considered to be used on live objects. You can not (or I don't want 
>> to
>> ) write tests only on "finished lived objects" sometimes we need tests for 
>> initialiazation/private code or exception handling I don't see how we can 
>> offer this only by using example instances (yes your "rethinking" sounds 
>> like "this
>> is the better way to do tests”).
> 
> I think there is a misunderstanding here.
> 
> When I test, (1) I create one or more objects, (2) I assert against them and 
> then (3) I potentially cleanup. At least the objects from step 1 are 
> potentially interesting for documentation purposes as well. However, because 
> tests are built in a completely different environment than examples are, and 
> because they are not casually linked to the code they 

Re: [Pharo-users] [Pharo-dev] [ann] GTExamples alpha

[Tudor Girba]

Hi Nicolai,

Thanks a lot for the feedback. Please let’s continue. See more inline.

> On Aug 25, 2016, at 6:34 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-25 8:47 GMT+02:00 Tudor Girba :
> Hi,
> 
> Hi Doru,
> some questions and feedback ( I am sorry for my tone or if this sounds 
> negative, it isn't meant to be)
>  
> Over the last coupe of years Stefan Reichhart and the rest of the GT team 
> worked on an implementation of examples. The work is inspired from previous 
> work done by Markus Gaelli and Adrian Kuhn.
> 
> As one of the goals of GT is to offer a live programming environment, 
> 
> Isn't this what we already have, a live programming environment, I think for 
> newcomers (and maybe others) this needs to make be more clear, how is 
> different, what gap are you trying to fill.
>  
> one important issue is how to move from the static code to live objects as 
> fast as possible. 
> 
> Isn't code always "static" and aren't objects always "live", how do play 
> gtExamples any role in this?

What I meant is that I want to be as little as possible in the static code 
browser. Instead I want to write code in the presence of a bounded “self” which 
happens either in a debugger or in an inspector.

The gap that examples fill is that when I look at a static code and I have 
examples about it, I can possibly jump to those examples and code against their 
result. So, instead of coding a method about a FileReference in the code 
browser, I will code it against an instance of a FileReference. Hence, we make 
live programming easier to achieve.


> That is why we worked on this library as a solution to provide a link between 
> the static code and live objects.
> 
> From my understanding, I think this "link" between code an objects is the 
> real valuable new point. This is the great thing about gtExamples. link from 
> code (the example methods itself or methods refering a class
> to an example object/instance that can be inspected (the raw  object or an 
> object specific inspector pane).
> This is what I would consider the real step forward. You see a method 
> refering to class TextModel and Nautilus or any other tool not only offers a 
> method to browse all Users of this class, but too, a dedicated
> list of "example methods" where every example has a view for this example 
> instance that let the user show and interact (even for non-visual objects 
> through the "evaluater pane", or just see the code creating this
> example.

Exactly.

> We really miss examples, I often see questions on the mailing list 
> (especially about spect) that can be explained easily with an example. And 
> even worse, often the examples already exists, they just aren't as visible.

Exactly. These examples are particularly amplified by the fact that we have an 
inspector that can provide a reacher experience through different views.


> Furthermore, this examples library also enables the definition of assertions 
> on the examples, and this provides the possibility of rethinking the way we 
> construct tests throughout our system. Tests are great as they help us create 
> live objects and then to assert live properties.
> 
> This whole thing sounds as if Unit-Test were a good idea but not the way that 
> they are used today, I strongly disagree. I don't see this as a "rethinking 
> the way we construct tests", yes, we can
> augment the current set of tests with addtional assertions on live objects, 
> but this is not a replacement.
> "Tests are great as they help us create live objects" This is not my only 
> purpose for writing tests, often unit-tests cover methods and "private-apis" 
> not even considered to be used on live objects. You can not (or I don't want 
> to
> ) write tests only on "finished lived objects" sometimes we need tests for 
> initialiazation/private code or exception handling I don't see how we can 
> offer this only by using example instances (yes your "rethinking" sounds like 
> "this
> is the better way to do tests”).

I think there is a misunderstanding here.

When I test, (1) I create one or more objects, (2) I assert against them and 
then (3) I potentially cleanup. At least the objects from step 1 are 
potentially interesting for documentation purposes as well. However, because 
tests are built in a completely different environment than examples are, and 
because they are not casually linked to the code they are about, we cannot 
exploit them to the maximum potential.

The GT-Examples model offers a unification. This means that you can use the 
same mechanism for expressing both a test scenario and a documentation one. 
There is potential to be exploited here. For example, there is research that 
aims to take the all sorts of objects and try to infer types for code out of 
these. We could make this much simpler.

I understand that this is a departure from the classic way of testing, but we 
have already expressed more than 1 thousand examples both from 

Re: [Pharo-users] [Pharo-dev] [ann] GTExamples alpha

[Nicolai Hess]

2016-08-25 8:47 GMT+02:00 Tudor Girba :

> Hi,
>

Hi Doru,
some questions and feedback ( I am sorry for my tone or if this sounds
negative, it isn't meant to be)


> Over the last coupe of years Stefan Reichhart and the rest of the GT team
> worked on an implementation of examples. The work is inspired from previous
> work done by Markus Gaelli and Adrian Kuhn.
>
> As one of the goals of GT is to offer a live programming environment,


Isn't this what we already have, a live programming environment, I think
for newcomers (and maybe others) this needs to make be more clear, how is
different, what gap are you trying to fill.


> one important issue is how to move from the static code to live objects as
> fast as possible.


Isn't code always "static" and aren't objects always "live", how do play
gtExamples any role in this?



> That is why we worked on this library as a solution to provide a link
> between the static code and live objects.
>

>From my understanding, I think this "link" between code an objects is the
real valuable new point. This is the great thing about gtExamples. link
from code (the example methods itself or methods refering a class
to an example object/instance that can be inspected (the raw  object or an
object specific inspector pane).
This is what I would consider the real step forward. You see a method
refering to class TextModel and Nautilus or any other tool not only offers
a method to browse all Users of this class, but too, a dedicated
list of "example methods" where every example has a view for this example
instance that let the user show and interact (even for non-visual objects
through the "evaluater pane", or just see the code creating this
example.

We really miss examples, I often see questions on the mailing list
(especially about spect) that can be explained easily with an example. And
even worse, often the examples already exists, they just aren't as visible.


>
> Furthermore, this examples library also enables the definition of
> assertions on the examples, and this provides the possibility of rethinking
> the way we construct tests throughout our system. Tests are great as they
> help us create live objects and then to assert live properties.


This whole thing sounds as if Unit-Test were a good idea but not the way
that they are used today, I strongly disagree. I don't see this as a
"rethinking the way we construct tests", yes, we can
augment the current set of tests with addtional assertions on live objects,
but this is not a replacement.
"Tests are great as they help us create live objects" This is not my only
purpose for writing tests, often unit-tests cover methods and
"private-apis" not even considered to be used on live objects. You can not
(or I don't want to
) write tests only on "finished lived objects" sometimes we need tests for
initialiazation/private code or exception handling I don't see how we can
offer this only by using example instances (yes your "rethinking" sounds
like "this
is the better way to do tests").




> However, they do not allow us to leverage the objects we create, and this
> can be a tremendous resource for understanding systems.
>
> In our vision, examples should be everywhere and they should be explicitly
> linked to the static code they exemplify. That is why the library comes
> with an initial integration in existing tools (such as Nautilus, Spotter,
> Inspector).
>
> The current solution works well and it is the result of several rewrites.
> We think that the solution is complete in terms of features, but there are
> still several things to improve and iterate on. To this end, I kindly ask
> you to take a look at it while distinguishing between the concrete
> implementation choice (e.g., the current extensive use of pragmas) and the
> conceptual benefits of the approach.
>
> To ease the discussion, we put together a short documentation:
>

Everytime I see a gtExample method on a class I first think, shouldn't this
go to a Help or Doc or Exampels class instead. I don't know how others
thinks about this but this is my first impression.
For example, the example on your page:

FileSystem class >> #createFileOnDisk
 
 
 ^ FileSystem workingDirectory / 'test.txt'
  writeStreamDo: [ :stream | stream nextPutAll: self comment ];
  yourself

Nice, now the user can see how to use FileSystem to create a file, open
*and* close the stream safely.  But for me, this method does *not* belong
to the FileSystem class it just not make any sense to me, to have a method
(*in this class*) that opens and closes a stream. Even if this is just an
example, I would put it in a doc-page or a tutorial that can execute code.
But again , this is just my point of view.
I can not really explain it, having a example method on Morph or a widget
ui or a widget model class, that opens an example morph or widget in the
world, is for me something completly different and a valid example.
Having the same for the method