- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to load with Iceberg?

by Thierry Goubier

Le 26/08/2016 Ã 22:23, serge.stinckwich(a)gmail.com a Ã©crit : > I got the same commit when I use Iceberg. It's part of the gitfiletree setup (shared with filetree, and probably libgit as well). We need to set a few properties inside the git repo, and it has to be done as a commit to be recorded by git. Thierry > EnvoyÃ© de mon iPhone > >> Le 26 aoÃ»t 2016 Ã 21:39, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : >> >> Hi! >> >> How can I load a version using Iceberg? >> >> I managed to open the history of a repo, but I cannot load a version. >> By the way, I see a commit with the comment âgitfiletree repository propertiesâ. What is that? I have never made this commit. >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

Aug. 26, 2016

Re: [Pharo-dev] WideString and commits

by Cyril Ferlicot D.

Le 25/08/2016 Ã 22:02, stepharo a Ã©crit : > > > Le 25/8/16 Ã 16:55, Nicolas Cellier a Ã©crit : >> Do we now since when? > > unfortunately not. > @Cyril this is in Pharo50? > This is at least in Pharo 6. I tested it on Windows and Mac. When I will get some free time I will try in Pharo 5. It at least work in Pharo 4 because when I get the problem I file out the packages and commit it in a Pharo 4 image. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Aug. 26, 2016

Re: [Pharo-dev] How to load with Iceberg?

by serge.stinckwich＠gmail.com

I got the same commit when I use Iceberg. EnvoyÃ© de mon iPhone > Le 26 aoÃ»t 2016 Ã 21:39, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > > Hi! > > How can I load a version using Iceberg? > > I managed to open the history of a repo, but I cannot load a version. > By the way, I see a commit with the comment âgitfiletree repository propertiesâ. What is that? I have never made this commit. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Aug. 26, 2016

Nautilus support for class method tests, and a bugfix for test result icons not resetting when a method is modified

by monty

https://pharo.fogbugz.com/f/cases/18974/

Aug. 26, 2016

Re: [Pharo-dev] How to load with Iceberg?

by Damien Pollet

Le vendredi 26 aoÃ»t 2016, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > > By the way, I see a commit with the comment âgitfiletree repository > propertiesâ. What is that? I have never made this commit. > it's made automatically when you first use the repo. Have a look at the diff, there should be only a couple metadata there -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2016

Layouts in bloc

by Alexandre Bergel

Hi! Consider this piece of code: -=-=-=-=-=-= space := BlSpace new. space root layout: BlLinearLayout horizontal. 10 timesRepeat: [ | e | e := (BlRectangle new extent: 20 @ 20) asElement. e background: Color random. space root addChild: e. ]. space root children withIndexDo: [ :e :index | e translateBy: (index * 30) @ 10 ]. space show -=-=-=-=-=-= It produces the following: Apparently, the manual translation has no effect (which is okay, I am at the stage of understanding the semantics of Bloc). If I do not specify a layout, the translation works. Is there a way to have the layout, and still be able to manually translate the elements? I have the impression that yes, but not with the layouts provided currently? I have seen a demo of some roassal layouts in Bloc. Where are they? Can I play with them? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2016

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

by Nicolai Hess

2016-08-25 23:40 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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 <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-25 8:47 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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 a > documentation and from testing point of view, and it does seem to work. > > > > 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 > > > > <gtExample> > > < > > description: 'Create a new file or override an existing file with some > contents. Open and close the stream safely' > > > > > ^ > > 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 above - is not, at least not as > executable code on the FileSystm class). > > I do not understand this last point. > > Just because an object does not have a visual appearance like a Morph > does, does not make it uninteresting from an interaction point of view. The > inspector already can provide the views. We also have the possibility of > adding custom actions that can be installed as menu items. Even for a > morph, I sometimes want to not look at its default appearance, but at its > submorphs. Thus, I do not see the confusion. > > Nevertheless, the example does not have to be on the class side. It can be > in any class you want and you can associate it with a subject. For example, > all Roassal examples are in dedicated classes. There are hundreds of > methods, so putting them all on the class side of a domain class would not > work at all. We showed the example on the class side because that is a > pattern that people used for a long time and it is a reasonable place when > you have only a handful of examples. The rationale is that an example is a > way to instantiate a class, so having it on the class side is not far > fetched. Also, if you put it on the class side, you get by default the > class as a subject for the examples it contains which is quite natural. > > > > http://gtoolkit.org/doc/Examples/examples.html > > > > That being said, you can get it with the full GToolkit in Pharo 6.0: > > > > Is this based on the recent Pharo 6.0? > > > > GTExamplesReleaseTests are failing for me > > Yes, these are yellow. > > > > Where did you test this? I get some Object>>#name deprecation warnings > when browsing for examples refering a class, for example on > > class FileSystem and menu entry "Browse Examples refering FileSystem" > (maybe a Pharo 5.0 version?) > > I tested in Pharo 6.0 (60188), but we just got a problem that was reported > related to Epicea and Martin is looking at it. > > > > The example on the examples.html side isn't actually in the image right? > > Yes, itâs not there yet. > > > > The browsing examples of a package (context menu on nautilus package > pane) does not work or I don't understand why it does not find any examples > at all. > > The World menu "Browse All Examples" does not contain the class > FileSystem, although FileSystem>>gtExampleZip is a gtExample, this is > because > > the example method is in an extension package, should all gtExample > methods be class extensions ? This is handled differently for different > packages. > > Hmm. When I "Browse All Examples" I get a Nautilus with FileSystem > class>>gtExampleZip in my image. But, indeed, in the latest GToolkit image, > this example is missing. > > > > The code pane context menu of a sendersOf Message browser is broken > (debug menu). > > I do not understand what menu item you refer to. Could provide a > screenshot. > > > > > From the web-side: > > > > "Furthermore, Nautilus, the World-Menu, all Rub-Text-Editors as well as > Spotter and Inspector provide access to retrieve, browse and navigate > examples from entities within the world" > > I can not find it, not in inspector, Rub-Text-Editors, only in Nautilus. > > In Nautilus and in RubText you get it in the GT-Examples menu (Browse > examples with subject â¦). > > The Inspector is not yet there, but we are adding it. > > > > And the menu entries are ... unfortunate (see screenshot), what you put > in, the whole source as menu label? > > Hmm. Something is strange there. I get the name of a method, not the > source code. What image are you in? > Ah, it always uses the "selected text" for building the menu label, in this example screenshot, I 've selected the whole method. Hm. But I don't know how it would find the selected method anyway. If I selecte the method #append: and select Browse examples with subject #append: or Browse examples with literal: #append: it opens a browser on class Text ander there is a Text class>>#gtExampleSimple, but it does not contain #append: not as a literal or as a message send. I did another test: select the message "asText" and choose Browse Examples with literal #asText It opens a browse with some more classes/example methods but I can not see *any* relation between this example methods and the text I selected. > > > > run "run the example and return its return-value" > > > > debug > > "same run, but open debugger if the example failsâ > > returnValue > > "the return-value" > > Executing run/debug/inspect returnValue does not seem to make any > different when called from nautilus. It always gives > > an inspector on a dictionary holding the gtexample and its > gtexampleresult (is this a bug?) > > Yes. > > > > Glossary: > > "Example: an example is a tiny stub object representing a GT-Example. It > holds the references to its dependencies, subjects and many other entities. > " > > What are "many other entities" this is a bit unclear > > Icon, Label, Provider, and others that you can add through custom > annotations if you want to. This part is not yet clear. > > > > "After-method: the after-method is a method that is performed right > after the example." > > After the example ? I thought an example is a "tiny stub *object*", how > can it run? > > How it is run after I run an example for inspection, after I closed the > inspector? > > Not yet. At this point, inspecting does not prevent triggering of the > cleanup method, but it would certainly be interesting to get there. > > Cheers, > Doru > > > http://gtoolkit.org/#install > > (easiest is to download the ready made image for now) > > > > For those that are at ESUG, I will try to provide a short overview > during the Show Us Your Project session from today. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Reasonable is what we are accustomed with." > > > > > > > > <gtexample_menu.png> > > -- > www.tudorgirba.com > www.feenk.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > >

Aug. 26, 2016

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

by Nicolai Hess

2016-08-26 0:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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 <tudor(a)tudorgirba.com> 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 <nicolaihess(a)gmail.com> > wrote: > >> > >> > >> > >> 2016-08-25 8:47 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> 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 a > documentation and from testing point of view, and it does seem to work. > > > > > >> 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 > >> > >> <gtExample> > >> < > >> description: 'Create a new file or override an existing file with some > contents. Open and close the stream safely' > >>> > >> ^ > >> 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 above - is not, at least not as > executable code on the FileSystm class). > > > > I do not understand this last point. > > > > Just because an object does not have a visual appearance like a Morph > does, does not make it uninteresting from an interaction point of view. The > inspector already can provide the views. We also have the possibility of > adding custom actions that can be installed as menu items. Even for a > morph, I sometimes want to not look at its default appearance, but at its > submorphs. Thus, I do not see the confusion. > > > > Nevertheless, the example does not have to be on the class side. It can > be in any class you want and you can associate it with a subject. For > example, all Roassal examples are in dedicated classes. There are hundreds > of methods, so putting them all on the class side of a domain class would > not work at all. We showed the example on the class side because that is a > pattern that people used for a long time and it is a reasonable place when > you have only a handful of examples. The rationale is that an example is a > way to instantiate a class, so having it on the class side is not far > fetched. Also, if you put it on the class side, you get by default the > class as a subject for the examples it contains which is quite natural. > > > > > >> http://gtoolkit.org/doc/Examples/examples.html > >> > >> That being said, you can get it with the full GToolkit in Pharo 6.0: > >> > >> Is this based on the recent Pharo 6.0? > >> > >> GTExamplesReleaseTests are failing for me > > > > Yes, these are yellow. > > > > > >> Where did you test this? I get some Object>>#name deprecation warnings > when browsing for examples refering a class, for example on > >> class FileSystem and menu entry "Browse Examples refering FileSystem" > (maybe a Pharo 5.0 version?) > > > > I tested in Pharo 6.0 (60188), but we just got a problem that was > reported related to Epicea and Martin is looking at it. > > > > > >> The example on the examples.html side isn't actually in the image right? > > > > Yes, itâs not there yet. > > > > > >> The browsing examples of a package (context menu on nautilus package > pane) does not work or I don't understand why it does not find any examples > at all. > >> The World menu "Browse All Examples" does not contain the class > FileSystem, although FileSystem>>gtExampleZip is a gtExample, this is > because > >> the example method is in an extension package, should all gtExample > methods be class extensions ? This is handled differently for different > packages. > > > > Hmm. When I "Browse All Examples" I get a Nautilus with FileSystem > class>>gtExampleZip in my image. But, indeed, in the latest GToolkit image, > this example is missing. > > > > > >> The code pane context menu of a sendersOf Message browser is broken > (debug menu). > > > > I do not understand what menu item you refer to. Could provide a > screenshot. > > > >> > >> From the web-side: > >> > >> "Furthermore, Nautilus, the World-Menu, all Rub-Text-Editors as well as > Spotter and Inspector provide access to retrieve, browse and navigate > examples from entities within the world" > >> I can not find it, not in inspector, Rub-Text-Editors, only in Nautilus. > > > > In Nautilus and in RubText you get it in the GT-Examples menu (Browse > examples with subject â¦). > > > > The Inspector is not yet there, but we are adding it. > > > > > >> And the menu entries are ... unfortunate (see screenshot), what you put > in, the whole source as menu label? > > > > Hmm. Something is strange there. I get the name of a method, not the > source code. What image are you in? > > > > > >> run "run the example and return its return-value" > >> > >> debug > >> "same run, but open debugger if the example failsâ > >> returnValue > >> "the return-value" > >> Executing run/debug/inspect returnValue does not seem to make any > different when called from nautilus. It always gives > >> an inspector on a dictionary holding the gtexample and its > gtexampleresult (is this a bug?) > > > > Yes. > > > > > >> Glossary: > >> "Example: an example is a tiny stub object representing a GT-Example. > It holds the references to its dependencies, subjects and many other > entities. " > >> What are "many other entities" this is a bit unclear > > > > Icon, Label, Provider, and others that you can add through custom > annotations if you want to. This part is not yet clear. > > > > > >> "After-method: the after-method is a method that is performed right > after the example." > >> After the example ? I thought an example is a "tiny stub *object*", how > can it run? > >> How it is run after I run an example for inspection, after I closed the > inspector? > > > > Not yet. At this point, inspecting does not prevent triggering of the > cleanup method, but it would certainly be interesting to get there. > > > > Cheers, > > Doru > > > >> http://gtoolkit.org/#install > >> (easiest is to download the ready made image for now) > >> > >> For those that are at ESUG, I will try to provide a short overview > during the Show Us Your Project session from today. > >> > >> Cheers, > >> Doru > >> > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Reasonable is what we are accustomed with." > >> > >> > >> > >> <gtexample_menu.png> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "No matter how many recipes we know, we still value a chef." > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > >

Aug. 26, 2016

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

by Nicolai Hess

2016-08-25 23:40 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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 <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-25 8:47 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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 a > documentation and from testing point of view, and it does seem to work. > > > > 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 > > > > <gtExample> > > < > > description: 'Create a new file or override an existing file with some > contents. Open and close the stream safely' > > > > > ^ > > 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 above - is not, at least not as > executable code on the FileSystm class). > > I do not understand this last point. > Not that important, it is just a feeling, I can not better explain > > Just because an object does not have a visual appearance like a Morph > does, does not make it uninteresting from an interaction point of view. The > inspector already can provide the views. We also have the possibility of > adding custom actions that can be installed as menu items. Even for a > morph, I sometimes want to not look at its default appearance, but at its > submorphs. Thus, I do not see the confusion. > > Nevertheless, the example does not have to be on the class side. It can be > in any class you want and you can associate it with a subject. For example, > all Roassal examples are in dedicated classes. There are hundreds of > methods, so putting them all on the class side of a domain class would not > work at all. We showed the example on the class side because that is a > pattern that people used for a long time and it is a reasonable place when > you have only a handful of examples. The rationale is that an example is a > way to instantiate a class, so having it on the class side is not far > fetched. Also, if you put it on the class side, you get by default the > class as a subject for the examples it contains which is quite natural. > > > > http://gtoolkit.org/doc/Examples/examples.html > > > > That being said, you can get it with the full GToolkit in Pharo 6.0: > > > > Is this based on the recent Pharo 6.0? > > > > GTExamplesReleaseTests are failing for me > > Yes, these are yellow. > > > > Where did you test this? I get some Object>>#name deprecation warnings > when browsing for examples refering a class, for example on > > class FileSystem and menu entry "Browse Examples refering FileSystem" > (maybe a Pharo 5.0 version?) > > I tested in Pharo 6.0 (60188), but we just got a problem that was reported > related to Epicea and Martin is looking at it. > It is not epicea that is calling #name see stacktrace (shortened): ByteSymbol(Object)>>deprecated:on:in: ByteSymbol(Object)>>name GTExample>>isReferencing: [ :example | example isReferencing: aLiteral ] in GTExampleNavigation class>>browseExamplesReferencing: in Block: [ :example | example isReferencing: aLiteral ] [ :example | aBlock value: example ] in GTExampleNavigation class>>browseExamples:select: in Block: [ :example | aBlock value: example ] OrderedCollection>>select: GTExampleNavigation class>>browseExamples:select: GTExampleNavigation class>>browseExamplesReferencing: [ GTExampleNavigation browseExamplesReferencing: aLiteral ] in GTExampleNautilusPackageMenu(GTAbstractExampleMenu)>>browseExamplesReferencing:builder: in Block: [ GTExampleNavigation browseExamplesReferencing: .... > > > > The example on the examples.html side isn't actually in the image right? > > Yes, itâs not there yet. > > > > The browsing examples of a package (context menu on nautilus package > pane) does not work or I don't understand why it does not find any examples > at all. > > The World menu "Browse All Examples" does not contain the class > FileSystem, although FileSystem>>gtExampleZip is a gtExample, this is > because > > the example method is in an extension package, should all gtExample > methods be class extensions ? This is handled differently for different > packages. > > Hmm. When I "Browse All Examples" I get a Nautilus with FileSystem > class>>gtExampleZip in my image. But, indeed, in the latest GToolkit image, > this example is missing. > > > > The code pane context menu of a sendersOf Message browser is broken > (debug menu). > > I do not understand what menu item you refer to. Could provide a > screenshot. > Yes, see attachd file, or debugger stack: MorphicTextAdapter(Object)>>doesNotUnderstand: #text GTExampleRubEditor>>menuFor: GTExampleRubEditor class>>menuFor: [ prg methodClass theNonMetaClass perform: prg methodSelector with: menu ] in [ :prg | self currentRoot: self while: [ prg methodClass theNonMetaClass perform: prg methodSelector with: menu ] ] in PragmaMenuBuilder>>collectRegistrations in Block: [ prg methodClass theNonMetaClass... [ aBlock value ] in PragmaMenuBuilder>>currentRoot:while: in Block: [ aBlock value ] BlockClosure>>ensure: PragmaMenuBuilder>>currentRoot:while: [ :prg | self currentRoot: self while: [ prg methodClass theNonMetaClass perform: prg methodSelector with: menu ] ] in PragmaMenuBuilder>>collectRegistrations in Block: [ :prg | ... OrderedCollection>>do: PragmaCollector>>do: PragmaMenuBuilder>>collectRegistrations PragmaMenuBuilder>>buildTree PragmaMenuBuilder>>menuSpecAt: PragmaMenuBuilder>>menuSpec [ builder menuSpec asMenuMorph ] in FallbackMenu>>debug in Block: [ builder menuSpec asMenuMorph ] BlockClosure>>ensure: FallbackMenu>>debug FallbackMenu(Object)>>perform:orSendTo: [ | selArgCount | "show cursor in case item opens a new MVC window" (selArgCount := selector numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount = arguments size ifTrue: [ target perform: selector withArguments: arguments ] ifFalse: [ target perform: selector withArguments: (arguments copyWith: evt) ]. self showShortcut ]. self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ | selArgCount |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>handleMouseUp: MouseButtonEvent>>sentTo: [ ^ anEvent sentTo: self ] in MorphicEventDispatcher>>dispatchEvent:with: in Block: [ ^ anEvent sentTo: self ] > > > > > From the web-side: > > > > "Furthermore, Nautilus, the World-Menu, all Rub-Text-Editors as well as > Spotter and Inspector provide access to retrieve, browse and navigate > examples from entities within the world" > > I can not find it, not in inspector, Rub-Text-Editors, only in Nautilus. > > In Nautilus and in RubText you get it in the GT-Examples menu (Browse > examples with subject â¦). > > The Inspector is not yet there, but we are adding it. > > > > And the menu entries are ... unfortunate (see screenshot), what you put > in, the whole source as menu label? > > Hmm. Something is strange there. I get the name of a method, not the > source code. What image are you in? > > > > run "run the example and return its return-value" > > > > debug > > "same run, but open debugger if the example failsâ > > returnValue > > "the return-value" > > Executing run/debug/inspect returnValue does not seem to make any > different when called from nautilus. It always gives > > an inspector on a dictionary holding the gtexample and its > gtexampleresult (is this a bug?) > > Yes. > > > > Glossary: > > "Example: an example is a tiny stub object representing a GT-Example. It > holds the references to its dependencies, subjects and many other entities. > " > > What are "many other entities" this is a bit unclear > > Icon, Label, Provider, and others that you can add through custom > annotations if you want to. This part is not yet clear. > > > > "After-method: the after-method is a method that is performed right > after the example." > > After the example ? I thought an example is a "tiny stub *object*", how > can it run? > > How it is run after I run an example for inspection, after I closed the > inspector? > > Not yet. At this point, inspecting does not prevent triggering of the > cleanup method, but it would certainly be interesting to get there. > > Cheers, > Doru > > > http://gtoolkit.org/#install > > (easiest is to download the ready made image for now) > > > > For those that are at ESUG, I will try to provide a short overview > during the Show Us Your Project session from today. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Reasonable is what we are accustomed with." > > > > > > > > <gtexample_menu.png> > > -- > www.tudorgirba.com > www.feenk.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > >

Aug. 26, 2016

iceberg: create repository?

by Alexandre Bergel

Hi! I think the following window can be improved: Do I want to import or create a repository? I think the button title has to be changedâ¦ Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2016