- Pharo-dev - lists.pharo.org

CI is down

by monty

https://ci.inria.fr/pharo

Aug. 25, 2016

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

by Tudor Girba

Hi, I just tried again, and the latest GToolkit image does contain FileSystem class >> gtExampleZip: Inspect this: Smalltalk gtExamplesContained select: [ :each | each method methodClass instanceSide = FileSystem ] This is the image: https://ci.inria.fr/moose/job/gtoolkit/5595/artifact/gtoolkit.zip Cheers, Doru > On Aug 25, 2016, at 11:40 PM, Tudor Girba <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. 25, 2016

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

by Tudor Girba

Hi Nicolai, Thanks a lot for the feedback. Please letâs continue. See more inline. > On Aug 25, 2016, at 6:34 PM, Nicolai Hess <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."

Aug. 25, 2016

Re: [Pharo-dev] problem with Epicea and #name

by Tudor Girba

Hi, > On Aug 25, 2016, at 10:03 PM, stepharo <stepharo(a)free.fr> wrote: > > > > Le 25/8/16 Ã 14:10, Tudor Girba a Ã©crit : >> Hi Martin, >> >> Thanks a lot for the quick response. >> >> As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). > + 1 > Even the king of Pharo is doing errors :) No no. We have agreed that there many kings :)) Doru > Stef >> >> Cheers, >> Doru >> >> >>> On Aug 25, 2016, at 1:19 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >>> >>> Hi Martin, >>> >>> To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. >>> >>> Don't worry there is no inconvenience :). >>> Thanks for looking into this. >>> >>> GTExampleOrganizer instance reset. >>> GTExampleOrganizer instance stopThoroughly. >>> GTExampleOrganizer stop. >>> Smalltalk garbageCollect. >>> self assert: GTExample allSubInstances isEmpty. >>> self assert: GTExampleMethod allSubInstances isEmpty. >>> >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'GToolkit'; >>> package: 'GT-InspectorExtensions-Core'; >>> package: 'GT-Inspector'; >>> load. >>> >>> Cheers, >>> Andrei >>> >>> On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? >>> I'm sorry for the inconvenience. >>> MartÃn >>> >>> >>> El 25/8/2016 7:18, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: >>> Hi, >>> >>> When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? >>> >>> Cheers, >>> Andrei >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by Tudor Girba

Hi, > On Aug 25, 2016, at 10:10 PM, stepharo <stepharo(a)free.fr> wrote: > >>>> Hi, >>>> >>>> There exists already a method for that: >>>> Symbol>>asClassInEnvironment: >>>> >>>> But, what if we introduce: >>>> >>>> Symbol>>asClassFrom: anObject >>>> ^ self asClassInEnvironment: anObject class environment >>>> >>>> ? >>> The problem is asClass unary. >>> >>> All the tools should be parametrized by an environment. >> Yes, but asClassFrom: would not be unary but would save us from typing an extra "class environment" :). > Yes I see. > But inside Pharo core tools we are ready to type > environment as a message that dispatch to something else than a symbol. Sure. >>>> This would allow us to still script and be dynamic. >>>> >>>> Furthermore, as #asClass is meant to be mainly used for convenience, not performance, I would also propose to make it lookup in thisContext and take the environment from there. I know that his might sound like magic, but it would be the default that we are looking for (to always lookup through the current environment dynamically). >>> argh I will die....:) >>> No use of thisContext or only in the scripting package. >>> :D >>> >>> Yes, yes. I just talked with Guille. Moving these scripting methods outside of the Kernel is clearly a must. > I think that each time you use them we will preempt cross compilation and others. Yes, we agree that this method should not be used inside code. >>> I was just thinking that we can make it so that we do not break any code while still making it dynamic. > I do not like your definition of dynamic. Sending a message to an object is dynamic. > What you imply is compact. I can understand it when typing in playground. By dynamic I meant the dispatch through âself class environmentâ or âself environmentâ which is what people will use by default. >>> Like with scripting solutions there is a performance penalty, but that is fine if people choose to pay it (like in the case of Symbol>>#value:). > Yes for scripts. Not for core code. > Since people tend to be a bit lazy I think that having rules will make sense. Definitely. Doru >>> >>> Cheers, >>> Doru >>> >>> >>>> What do you think? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>> >>>>> Just my 2 cents: >>>>> >>>>> >>>>> instead of >>>>> >>>>> #name asClass >>>>> >>>>> we have to use >>>>> >>>>> self class environment at: #name. >>>>> >>>>> >>>>> Maybe instead of #at: we can have #classNamed:? Or something similar? Because 1) itâs not obvious that the method will give you a class, what if in the future and environment can also have a mapping of something else like packages? >>>>> >>>>> Uko >>>>> >>>>>> On 25 Aug 2016, at 07:21, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> Hi guys >>>>>> >>>>>> We got a meeting at ESUG with all the compiler guys and james from gemstone. >>>>>> >>>>>> Our goal is to have a full tool suite that can be parametrized by environments (so that >>>>>> >>>>>> we can compile code in other space, or compile other code inside pharo). >>>>>> >>>>>> I personnally started this effort one decade ago. Now the introduction >>>>>> >>>>>> of #asClass and friend is simply destroying all our efforts. There was a discussion >>>>>> >>>>>> in the past but we are not listened. >>>>>> >>>>>> We will >>>>>> >>>>>> - packaged these extensions in a separate package >>>>>> >>>>>> - add rules to ban the use of such method in Pharo >>>>>> >>>>>> - fix all the use (again) to use the correct way to do it. >>>>>> >>>>>> >>>>>> I can understand that for scripting this is easier but it cannot be at that cost and impact. >>>>>> >>>>>> I hope that we will understand but we have to do something else than >>>>>> >>>>>> fixing code that breaks our effort. >>>>>> >>>>>> >>>>>> Stef, Marcus, Guille and Luc >>>>>> >>>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "It's not what we do that matters most, it's how we do it." >>>> >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Aug. 25, 2016

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

by Tudor Girba

Hi, > On Aug 25, 2016, at 5:31 PM, Gour <gour(a)atmarama.com> wrote: > > On Thu, 25 Aug 2016 09:05:45 +0200 > stepharo <stepharo(a)free.fr> wrote: > >> Yes but we cannot do much > > OK. I got it...do you believe it makes sense for a noob to create acount > in case there are some low-hanging fruits to pick? It definitely does! We are all noobs in many parts in our system. But, if you take your time and are willing to dig, the system is kind enough to reveal itself to you :). That is the beauty of this world. Please join us. Just dive :). Cheers, Doru > > Sincerely, > Gour > > -- > From wherever the mind wanders due to its flickering and unsteady > nature, one must certainly withdraw it and bring it back under > the control of the self. > > > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

> Ah, I am using that a lot to parametrize software. > > On one hand Pharo is breaking with the past, on the other one it > sticks with it as much as possible? #MeConfused asHell. > This has nothing to do with complying with the past. Do you think seriously that if we could replace self class env: #foo but #foo asClass and get the same we would not do it? Since you know that we are smart guys, I let you as an exercise to understand why we are picky about not using it. > #SomeSymbol asClass looks very practical and cleaner that looking the > class dictionary with at: #SomeSymbol > No but I will let you try to find a bit by yourself before telling it to you why ;D Some hints: if you do not want that we succeed to - be able to compile pharo code inside a different namespace, object space, - be able to compile the compiler code modified to be able to recompile itself - be able to use our tools to compile code for another system like Gemstone then yes let us use a solution with 7 letters less because it is not cleaner but shorter. Stef > Phil > > Phil > > > Le 25 aoÃ»t 2016 07:22, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > Hi guys > > We got a meeting at ESUG with all the compiler guys and james from > gemstone. > > Our goal is to have a full tool suite that can be parametrized by > environments (so that > > we can compile code in other space, or compile other code inside > pharo). > > I personnally started this effort one decade ago. Now the introduction > > of #asClass and friend is simply destroying all our efforts. There > was a discussion > > in the past but we are not listened. > > We will > > - packaged these extensions in a separate package > > - add rules to ban the use of such method in Pharo > > - fix all the use (again) to use the correct way to do it. > > > I can understand that for scripting this is easier but it cannot > be at that cost and impact. > > I hope that we will understand but we have to do something else than > > fixing code that breaks our effort. > > > Stef, Marcus, Guille and Luc > >

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

>>> Hi, >>> >>> There exists already a method for that: >>> Symbol>>asClassInEnvironment: >>> >>> But, what if we introduce: >>> >>> Symbol>>asClassFrom: anObject >>> ^ self asClassInEnvironment: anObject class environment >>> >>> ? >> The problem is asClass unary. >> >> All the tools should be parametrized by an environment. > Yes, but asClassFrom: would not be unary but would save us from typing an extra "class environment" :). Yes I see. But inside Pharo core tools we are ready to type environment as a message that dispatch to something else than a symbol. >>> This would allow us to still script and be dynamic. >>> >>> Furthermore, as #asClass is meant to be mainly used for convenience, not performance, I would also propose to make it lookup in thisContext and take the environment from there. I know that his might sound like magic, but it would be the default that we are looking for (to always lookup through the current environment dynamically). >> argh I will die....:) >> No use of thisContext or only in the scripting package. >> :D >> >> Yes, yes. I just talked with Guille. Moving these scripting methods outside of the Kernel is clearly a must. I think that each time you use them we will preempt cross compilation and others. >> >> I was just thinking that we can make it so that we do not break any code while still making it dynamic. I do not like your definition of dynamic. Sending a message to an object is dynamic. What you imply is compact. I can understand it when typing in playground. >> Like with scripting solutions there is a performance penalty, but that is fine if people choose to pay it (like in the case of Symbol>>#value:). Yes for scripts. Not for core code. Since people tend to be a bit lazy I think that having rules will make sense. >> >> Cheers, >> Doru >> >> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> Just my 2 cents: >>>> >>>> >>>> instead of >>>> >>>> #name asClass >>>> >>>> we have to use >>>> >>>> self class environment at: #name. >>>> >>>> >>>> Maybe instead of #at: we can have #classNamed:? Or something similar? Because 1) itâs not obvious that the method will give you a class, what if in the future and environment can also have a mapping of something else like packages? >>>> >>>> Uko >>>> >>>>> On 25 Aug 2016, at 07:21, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Hi guys >>>>> >>>>> We got a meeting at ESUG with all the compiler guys and james from gemstone. >>>>> >>>>> Our goal is to have a full tool suite that can be parametrized by environments (so that >>>>> >>>>> we can compile code in other space, or compile other code inside pharo). >>>>> >>>>> I personnally started this effort one decade ago. Now the introduction >>>>> >>>>> of #asClass and friend is simply destroying all our efforts. There was a discussion >>>>> >>>>> in the past but we are not listened. >>>>> >>>>> We will >>>>> >>>>> - packaged these extensions in a separate package >>>>> >>>>> - add rules to ban the use of such method in Pharo >>>>> >>>>> - fix all the use (again) to use the correct way to do it. >>>>> >>>>> >>>>> I can understand that for scripting this is easier but it cannot be at that cost and impact. >>>>> >>>>> I hope that we will understand but we have to do something else than >>>>> >>>>> fixing code that breaks our effort. >>>>> >>>>> >>>>> Stef, Marcus, Guille and Luc >>>>> >>>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > >

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

Yes this is what I was thinking too :) > Hi > > 2016-08-25 8:52 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Furthermore, as #asClass is meant to be mainly used for > convenience, not performance, I would also propose to make it > lookup in thisContext and take the environment from there. I know > that his might sound like magic, but it would be the default that > we are looking for (to always lookup through the current > environment dynamically). > > > We could also make #asClass as "always deprecated" method with > automatic rewriting. So in tools people will always see that it is > better to not use it. > But for scripting it will work normally. Also if people will commit > such code it will become dirty very fast and always. And they will > need to fix it >

Aug. 25, 2016

Re: [Pharo-dev] problem with Epicea and #name

by stepharo

Le 25/8/16 Ã 14:10, Tudor Girba a Ã©crit : > Hi Martin, > > Thanks a lot for the quick response. > > As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). + 1 Even the king of Pharo is doing errors :) Stef > > Cheers, > Doru > > >> On Aug 25, 2016, at 1:19 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> Hi Martin, >> >> To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. >> >> Don't worry there is no inconvenience :). >> Thanks for looking into this. >> >> GTExampleOrganizer instance reset. >> GTExampleOrganizer instance stopThoroughly. >> GTExampleOrganizer stop. >> Smalltalk garbageCollect. >> self assert: GTExample allSubInstances isEmpty. >> self assert: GTExampleMethod allSubInstances isEmpty. >> >> Gofer new >> smalltalkhubUser: 'Moose' project: 'GToolkit'; >> package: 'GT-InspectorExtensions-Core'; >> package: 'GT-Inspector'; >> load. >> >> Cheers, >> Andrei >> >> On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? >> I'm sorry for the inconvenience. >> MartÃn >> >> >> El 25/8/2016 7:18, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: >> Hi, >> >> When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? >> >> Cheers, >> Andrei >> > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > >

Aug. 25, 2016