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

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

How to load with Iceberg?

by Alexandre Bergel

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

Iceberg: success and fail

by Serge Stinckwich

Hi all, I was able to do my first commit with Iceberg on github ! So this is great. I'm trying now to move an existing project on SmalltalkHub on github. I made a local repository and when I try a package in this repo, I have the following error. I can put the error report on Iceberg issue tracker if needed. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 26, 2016

Re: [Pharo-dev] About better communication in the community

by Pavel Krivanek

Dne pÃ¡tek 26. srpna 2016 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> napsal(a): > Hi Stef, > > 2016-08-25 3:48 GMT-03:00 stepharo <stepharo(a)free.fr > <javascript:_e(%7B%7D,'cvml','stepharo(a)free.fr');>>: > >> Hi hernan >> >> Could you reply to my mail? Because what is important is how we can make >> progres. >> > > Ok, here it is :) > > >> About GT I have some concerns too now I see also a lot of improvements. I >> love GTInspector and we should remove EyeInspector. >> >> I want to have once brick is out another minimal environment not based on >> anything so that we can have a back-door to debug when the other tools have >> a problems. >> > > Cool you are considering this situation. > > >> Now some answers: >> >> >> >> Then it makes no sense raise any form of criticism, or the board, if by >> definition lobby groups silence any possible mistake. >> >> No this is wrong. You can criticize as I criticize but you should give >> clear actionable points. >> Else this is Oh XX is bad. >> Tell us how we can address your problems and we will try. >> Without clear feedback we cannot act. >> >> > I'm afraid my english is good enough to provide clear feedback. I try to > do my best without offending anyone (see below) > > > >> 2. Features that goes inside Pharo are not decided by vote. They have to >>> add value and share the Pharo vision (pointed in the vision document who is >>> not slightly updated but still guides our steps). We try to reach consensus >>> and if it is not possible, then we decide. Yes, is like thatâ¦ Iâm sorry for >>> not being perfect democratic but this was never the idea of Pharo (it *has* >>> a benevolent dictatorâ¦ who by the way is not me but a group, the board). >>> >>> >> Ok, now people can see one reason why Pharo is light years from the >> popularity of other OSS. I don't get how do you expect success with Pharo >> if you never change your mindset... I read a lot of papers and see KDE, >> gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never >> *ever* read something like that, specially now where OSS literature is >> considering distributed democracy. >> >> Sorry but >> - you would be surprised by how many people would vote to get GT >> tools inside Pharo :) >> > > In my opinion is because it is biased by the same people who is behind, or > invested time testing/fixing it, and we are few to have a valuable N. This > will never be fair, newbies will ignore the old inspector/explorer (yes, > the old one from Squeak) was just fine and was easily understandable and > extensible just adding a few methods. And, I repeat in my opinion, a new > inspector isn't really a high priority for our world problems (big data is, > for example), much less a framework.... So that's my view on it. > > But that's all, decision was taken. Now we have to move on. > > >> - then I do not know what to tell you because I'm quite sure that >> Apache or Mozilla are not managed by vote of people. >> > > Just a few references you, or the board, may consider for the future : > > Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote > KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve > important issues " > Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes > votes with no vetos are required to commit a change " > Mozilla : "A review and super-review process is required for most code > changes." > > http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf > > "It is important to keep users involved in the process and not treat them > as second-class citizens." > Richard P. Gabriel > http://www.dreamsongs.com/IHE/IHE-52.html > > > >> In the end, time will tell, but can you cite another successful open >> source project with such "model"? >> >> Sorry I do not have the time to know. >> We want an doit model: doing in things should be more important than suh >> having needs (even if clients and users are important) >> > 4. You have a very negative opinion about our design choices. Thatâs ok, >>> but we are not going to remove GT just because you dislike it. >>> >> >> It's not because of just my dislike. It's because it was never proposed >> for inclusion (it was just decided), it is because you make it almost >> impossible to uninstall it, and because it was integrated very early like >> an enhacement/future/vision set of tools without any votes, or >> high-resistance policy like many Open-Source projects, and judging by the >> volume of mails it required a lot of of time of beta-testing by many users. >> >> You mean beside me someone was not really happy? >> Seriously? >> Now you can not use Spotter so I do not see the problem. >> The Debugger is working well. >> Playground looks like a default workspace. >> Then GTInspector works perfectly for me. >> > > To be clear, it's not against GT specifically (I don't like it, too slow, > takes too much space, etc) but the integration process behind, where the > board delivered it and seemed to said f**ck you this must be loved, deal > with it if don't. But then we don't have an easy way too uninstall it, I > have to spend days investigating how to remove it disabling settings in > specific order, and without leaving obsolete instances all around. So > what's my proposal for a next release? > > Respect the freedom of choice for people which is not obligated to love > all your tools, by providing an uninstall option (if the tool is not really > essential) > As the side-effect of the bootstrap process we are increasing granularity of the configurations of the reloaded system. Partly simply because of practical reasons. It is easier to maintain smaller subsystems. So now we are generating as intermediate steps in our bootstrap/reload process images without tools, with non-GT tools and with GT. Now these images are very far from being clean because we need firstly focus on other things but we already removed package dependencies caused by extension methods. If you want clean images without GT tools as soon as possible, your help is welcome. -- Pavel > > >> >> I would love to have the time to invite you, or any GT developer, to work >> with me just one week with real DNA data, and see how well GT goes... >> >> >> Please do a skype sharing session with Andrei and Doru. I'm sure that >> they will love to do it. >> So I take your words and urge you do it. >> It will help you to get out your frsutration and I'm sure that GT will >> improve. >> So a clear win/win situation. >> > > This is hard for me because I'm sure at this point Andrei and Doru should > be angry with me for ciriticizing their work. But I will try to make some > use cases these days and share with you so I can show you specifically what > I'm talking about. > > >> >> Maybe I should be sorry for not being as obedient and blindly accepting >> all board decisions as the word of God, as many on this list. >> >> Can you imagine one moment that people like it? >> >> > I know people like it. This is not against people but against conformity. > I am saying the board, at some point, may have to reflect on if decisions > taken and results obtained aren't masked by "likes" and **may be** raising > questions like if we want to compete with Python because with such a crappy > eval they have hundreds of libraries used by millions, and we are still > discussing why there isn't uninstallers. > > >> >> >> Understood, what makes me most sad is users almost accepted they cannot >> do better and if they do, their work will never be integrated by default. >> >> No do better. >> Why I started Spec when ther was Glamour. Why Alain was working on >> Calipso? >> I would love that someone comes and tell me: take XX it is super hyper >> cool UI Builder. >> >> > Me too, and by this point we should really ask ourselves why we don't have > yet a cool UI Builder. > > HernÃ¡n > > Instead, non-voters decisions discourages users to be rewarded for their >> creativity, and imposes many others to work free "supporting" tools which >> were imposed de facto. >> >> >>> So again, I cannot stress this enough: Is my job to say no. I know I >>> hurt some people but social development is complicated. >>> I do not think I do a bad job :) >>> >>> >> Me neither, but you cannot expect conformity from all of us. >> >> HernÃ¡n >> >> >> >>> cheers! >>> Esteban >>> >>> On 24 Aug 2016, at 09:38, stepharo <stepharo(a)free.fr >>> <javascript:_e(%7B%7D,'cvml','stepharo(a)free.fr');>> wrote: >>> >>> Hi Hernan >>> >>> First thanks for your email because we may disagree but we often agree. >>> :) so this is an email for me. >>> >>> Hi Stef, >>> >>> Good communication implies being clear when writing about sensitive >>> topics, especially when communicating through virtual channels. I am not in >>> Europe, so I cannot discuss these things with you face to face. >>> >>> This is what we want to change with montly videos meeting. >>> >>> Therefore is not clear to me (and others) what are your policies in many >>> subjects. Lately I also delayed the release of packages because my lack of >>> motivation around this community, specially when discussions exists around >>> three or fourth topics for months. >>> >>> >>> Like what? >>> Let us know because we do not >>> >>> Another "motivational" case for me. I stopped to report bugs in fogbuz >>> because I felt there was too much "Won't fix" for me (specifically by a >>> person but I won't go there...) even in cases where it was ilogical. Then I >>> felt tired of reading "It's like that. Invalid". >>> >>> This is a pity. >>> I know the feeling because some of mine are close too. You are not the >>> only victim of the "Issue closing syndrom" ;). >>> And I would like the syndrome to be more human friendly. Thanks for >>> raising this point. >>> >>> Now two points >>> - You should always send a mail to the mailing-list and that we >>> discuss your points. >>> >>> - Now what will happen if we all open bugs and none of us works on >>> the open bugs. >>> So what is the solution for you. I mean it concretely. How to deal with >>> dying >>> >>> Looking at bugs is really difficult. There are not enough people looking >>> and fixing bugs. >>> >>> About features. >>> >>> What's the policy about voting for default features in next Pharo >>> images? Let's suppose I am a VM/core Pharo maintainer and I want to include >>> MySuperPackage into a Pharo release, which nobody needs (and I don't care), >>> but it is useful to me.... there will ever be voting there? (note it >>> doesn't makes sense if you are a group of 50 always supporting your work) >>> >>> >>> It does not really work because engineers are paid for certain task. >>> >>> Images are becoming huge (at least for my workflows). There will be >>> (more) packages included by default (for promotion?) ? >>> >>> Thanks to raise this point because I mentioned it also to the board. So >>> I like when I'm not alone. >>> Now we should not see look only at the size. Doing nothing is size zero >>> :) >>> The point is what are the functionalities delivered. >>> >>> Three points: >>> - what are the key things we want? >>> keybinding, settings, cool inspector cool.... >>> >>> - how many duplicated functionality can we remove: >>> for example I want to merge MCDefinitions with Ring with >>> RBDefinition >>> we removed pseudo* >>> but this is a lot of work >>> >>> The goal is to throw many system when bloc and brick are >>> ready >>> >>> - what is the list of things that you would remove? >>> >>> - with the bootstrap and all the packages of the image managed with >>> Cargo plus the git management >>> we believe that we will be able to manage a set of images with >>> minimal images. >>> - this is several years that we are working on this goal. >>> Believe me this is the vision document not for the sake of >>> it. >>> >>> How do you plan to manage if some people want the Tests be removed from >>> the official Image? (Personally I never run them) >>> >>> - then you use a jenkins job to produce your image where you unload >>> the tests. >>> >>> Another example, what happens if another research group came with a >>> better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate >>> first your tool to mark territory? >>> >>> >>> No this is not a question of territory. Doru and GT does not do that >>> in that spirit. >>> RMOD too. We do something when we think that this is better. >>> For example Epicea is three years of work of Martin, Fuel was so >>> nice that we could not lose it. >>> You see Ghost got changed by denis, Seamless got rewritten from >>> scratch. >>> >>> >>> Who decides? For example (IIRC) TxText and Twisty. >>> >>> Igor looked at Twisty seriously and I do not think that it could >>> handle large cobol files. >>> >>> (you see funnily denis is doing the same with Seamless - He rewrote >>> it from scratch while >>> nick worked on it for several years). >>> >>> Igor wanted to have a stream-based API that could work on modern >>> command-oriented videos card framework. >>> My team (on our own money if you understand what it means) >>> paid Igor to build TxText (and I can tell you that I would have >>> prefered him to do something else). >>> >>> >>> The same applies if anyone came with another rewrite of classic >>> Smalltalk Workspace, Debugger and Inspector tools, what would you do with >>> GT? GT stays because it came before and others would be optional? >>> >>> No this is not like that. >>> If you are better or answer better needs. >>> >>> There will be anything like PEPs? >>> >>> I would love but will people have the energy to implement them? >>> I would definitively encourage you as a community to raise points on >>> what you need. >>> >>> If someone can answer me I think that would be an example of good >>> communication. >>> >>> Hernan I always answered your emails. I always consider your work >>> (and you know it for other reasons and by my facts) after I'm not always in >>> agreement as I'm not always in agreement with other board members and this >>> is how live happens. >>> What is clear is that the most important aspects is to continue to >>> communicate. This is why the board is launching >>> this initiative and I would love to see it taken by people even for >>> their projects. >>> >>> >>> >>> HernÃ¡n >>> >>> >>> 2016-08-24 1:51 GMT-03:00 stepharo <stepharo(a)free.fr >>> <javascript:_e(%7B%7D,'cvml','stepharo(a)free.fr');>>: >>> >>>> Hi guys >>>> >>>> the board got a good discussion at ESUG about how to improve and a lot >>>> of the discussion turned around improving communication. We got some ideas >>>> that we will propose soon but I would like to get *your* ideas. >>>> >>>> If you have idea about improving communication around pharo please tell >>>> us. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>> >>> >>> >> >> >

Aug. 26, 2016

Re: [Pharo-dev] How to know the uncommitted changes?

by Alexandre Bergel

Double clicking also work. Cool! Alexandre > On Aug 26, 2016, at 12:26 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Yes, do a synchronize on the repository. > > > Le 26 aoÃ»t 2016 12:24, "Alexandre Bergel" <alexandre.bergel(a)me.com> a Ã©crit : > Hi! > > It would be great that right-clicking on an uncommitted change that I have an option to see the differences with the local repository. > > Is there a way to know this? > > Cheers, > Alexandre > > <Screen Shot 2016-08-26 at 12.22.13 PM.png> > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2016

Re: [Pharo-dev] About Pharo 60

by Dimitris Chloupis

My Christmas list is divided to 2 sections a) What I want from you b) What I am going to deliver *What I want from you* ------------------------------------ The things I want from Pharo are centered on the high priorities a) 64 bit version b) Bloc /SDL c) FFI documentation / stabilization Its fine if you deliver after christmas or even a year later, I am in no hurry. *What I am going to deliver ( Unreal 4 for Pharo)* ------------------------------------ Because previously I wanted to target the iOS and Android markets for my games, I could not included Pharo in my plans because both iOS and Android demands a single executable and no DLLs . However I discovered that as a market Steam alone is as large , so I will be targeting Steam instead since my games are more suited for PC (strategy / adventure / rpg) anyway. Windows and Macos will be my focus. This means I can now use Pharo with Unreal (One also big reason to choose Steam and drop iOS and Android) , which further means that around Christmas Ephestos v1 most likely will be released which will allow for Pharo to be used as a scripting engine for Unreal for people who want to create games or other kind of interactive graphics / multimedia. But I make no promises because I am still learning Unreal , however because already my socket bridge worked well for using python libraries from Pharo, I will do something similar for Unreal too. In long term I am considering also a Pharo to C++ transpiler but that is a low priority for now. Essentially Ephestos will be the basis upon which I will be building my commercial games so its a very long term project. Disclaimer: Knowledge of Unreal will be required On Wed, Aug 24, 2016 at 8:00 AM stepharo <stepharo(a)free.fr> wrote: > Hi > > We have some ideas (because people are working on items) for the Pharo 6 > roadmap > > and we will consolidate them soon and propose them to you. > > but I would like to know two kinds of points > > - what are the points you are working on and that would deserve > more focus and help from the community? > > (these points are important because like that you could go > faster and this is a good feeling to get done for example) > > - what would be points where (if magically we would get more > resources - to not dream if this is not you > > there is a high chance that we will not make it) it would be > nice to get some changes > > > Please pay attention that if you type too fast and come up with a > christmas list well it will stay a christmas list and will just make the > thread larger for nothing. > > Stef > > >

Aug. 26, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

Le 26/8/16 Ã 14:40, Norbert Hartl a Ã©crit : > Hi, > > the things I want to have are 64bit, bootstrap and vector graphic > backend because these are so disruptive that it takes some time to > stabilize the whole system. But there is a roadmap for this which is > ok for me. > > For me we really need to focus on stabilizing a few things which are > (to me) very annoying: > > - cannot escape execution with cmd-. sometimes. Yes we should check that with denis > - endless loop in Context with DNU for sending the same message again > (https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop) > - spotter opening is too slow. You open spotter and when you type too > early it shows nothing and you need to close it > - unifying keyboard shortcuts > - tiny and misplaced buttons in GTDebugger :) I fully agree on this one. > - tree view in GTInspector. It is absolutely terrible that if you try > to uncollapse a tree node on the right pane and you did not hit > exactly the pane moves to the left. That is soooâ¦..!!!!!"!Â§$"%Â§%Â§% > - Nautilus method caching. You can have code views that get not > updated when the method changes and not even sometimes when you close > and reopen the browser. Do you have a scenario? I would like to see what I can do. I would like to do another pass. > - good integration of epicea. The old changes mechanism was just > broken so I'm glad epicea is in place now > > The other big thing for me is that we need to do project dependencies > right. I think the bootstrap guys know. at least we will fix the ones in the image :) > The way we reference metacello projects from other projects quickly > produces a situation that you load the maximum set in your image. We > should have guidelines how to do configurations or any other mechanism > so that not only the bootstrap can load cleanly but business project > images as well. Let's call it dependency management I think that the dependencies should be computed for us from a tool like the dependency browser and proposed to us. > > my christmas list would be: > > - runtime adaptable behaviour. Be it runtime traits, talents, etcâ¦ > - environments to separate graphs for certain dimensions like code > version, etc. > - magritte replacement with slots These ones are more researchy but I was recently rereading talents. Do you have a scenario for talents? > > > Norbert > > >> Am 24.08.2016 um 06:59 schrieb stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi >> >> We have some ideas (because people are working on items) for the >> Pharo 6 roadmap >> >> and we will consolidate them soon and propose them to you. >> >> but I would like to know two kinds of points >> >> - what are the points you are working on and that would deserve >> more focus and help from the community? >> >> (these points are important because like that you could go >> faster and this is a good feeling to get done for example) >> >> - what would be points where (if magically we would get more >> resources - to not dream if this is not you >> >> there is a high chance that we will not make it) it would be >> nice to get some changes >> >> >> Please pay attention that if you type too fast and come up with a >> christmas list well it will stay a christmas list and will just make >> the thread larger for nothing. >> >> Stef >> >> >

Aug. 26, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

> List: > > * image size management under control Yes it requires to write a new GC so I hope that the VM team with get the ressources. > * no more gradients in that UI (even in the light theme) > * modern "Material style" UI > * FASTER Nautilus what is the problem? > * better console support (in/out) stdout and friends do not work? > * Pharo VM as something I can embed in other programs > * something like npm.js for the packages list along with external > package manager to build my images We will have that with Cargo > * integration with Hadoop ecosystem > * super easy to write REST clients and servers (including Swagger support) I think that this is not the roadmap for Pharo 60 but for the community. > > Phil > > > On Fri, Aug 26, 2016 at 10:15 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Thanks Peter > >> I cannot find the list, but there were some things we discussed >> during consortium call a month or so ago. Maybe Esteban can find it? >> >> I want for Christmas >> >> * Better Spec >> * Roadmap so we know where we are going, >> * with clean API, >> * so we can build really live UIs (where you can drag windows >> around, close them, dock them, etc. >> * so we are ready for Bloc (can be for Easter too :)) >> * Stability >> * I crash daily >> >> Obviously I can and I try to help with Spec, but I do not have >> the time or resources to lead it, and since we don't have any >> roadmap it's hard to go forward. > > I should say that I'm a bit stuck to understand where to start > and what we want to achieve. > The firs things I would do > - Reading all the code to get a feel. > - I would like to rename the class consistently a Model > should be named Presenter and the Model whose name do not contain > Model should still be renamed to contain Presenter. > > I need to review the changes made by marion and that have been > published. > > Stef > > > >> >> > >

Aug. 26, 2016