- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About asClass and friend

by Luc Fabresse

2016-08-26 9:10 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self environmentAt: #Blah > > Object>>environmentAt: aSymbol > ^ self class environmentAt: aSymbol > > Object class>>environmentAt: aSymbol > ... > > The idea is that we can then customize name resolution, per object, per > class and per module in the future. > > > +1 > > > 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). > I would start simple as said before, re-package it and add a rule as > suggested by Denis. > Now, I am not sure that making asClass supporting name resolution in > another environment is really useful. > And if we do it using thisContext, some developers may use that instead of > "obj environmentAt: XXX" which would be bad. > > > I dislike a lot the thisContext resolution idea. > If is bad is badâ¦ and it will be bad also for scripting. I know, now it > does not looks like adding value, but think about: #asClass is monolithic > and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way > of thinking problems in Pharo thus inducing confusion for non expert users. > this is my feeling too. Luc > Esteban > > > my 2KÄ, > > #Luc > > 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> >> >> > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: >> > >> > Thanks doru. >> > >> > I do not like when people think that we are complaining just because >> something changes. >> > >> > It should change for the better and we all agree on that. >> >> Certainly. There are many points of view and many constraints. This is >> why it is so important that we all bring forward those constraints because >> only like this we can reach a global maximum. >> >> So, about asClass, everyone agrees that it should be moved to another >> package. The open questions are: >> - do we add an automatic deprecation for those that use it in code, or >> - do we make use of thisContext to retrieve the environment? >> (or both) >> >> Also, what about the asClassInEnvironment: method? Can it be used in >> code, or do we better discourage its usage altogether? I am thinking that >> if we have to write: >> #MyClass asClassInEnvironment: self class environment >> is even longer than: >> self environment at: #MyClass >> so, I think there is little point to it. >> >> In fact, for scripting what I find useful is not so much less characters, >> but the lack of parentheses, hence unary methods. That is why asClass is >> worth being salvaged for scripting (even with a solution that is slower >> with thisContext), but the rest maybe can be removed. What do you think? >> >> Cheers, >> Doru >> >> > >> > Stef >> > >> > >> >>>>>> 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." >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> > >

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by Esteban Lorenzano

> On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the past ;-)): > > self environmentAt: #Blah > > Object>>environmentAt: aSymbol > ^ self class environmentAt: aSymbol > > Object class>>environmentAt: aSymbol > ... > > The idea is that we can then customize name resolution, per object, per class and per module in the future. +1 > > 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). > I would start simple as said before, re-package it and add a rule as suggested by Denis. > Now, I am not sure that making asClass supporting name resolution in another environment is really useful. > And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad. I dislike a lot the thisContext resolution idea. If is bad is badâ¦ and it will be bad also for scripting. I know, now it does not looks like adding value, but think about: #asClass is monolithic and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way of thinking problems in Pharo thus inducing confusion for non expert users. Esteban > > my 2KÄ, > > #Luc > > 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: > Hi, > > > > > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > Thanks doru. > > > > I do not like when people think that we are complaining just because something changes. > > > > It should change for the better and we all agree on that. > > Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum. > > So, about asClass, everyone agrees that it should be moved to another package. The open questions are: > - do we add an automatic deprecation for those that use it in code, or > - do we make use of thisContext to retrieve the environment? > (or both) > > Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: > #MyClass asClassInEnvironment: self class environment > is even longer than: > self environment at: #MyClass > so, I think there is little point to it. > > In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think? > > Cheers, > Doru > > > > > Stef > > > > > >>>>>> 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 <mailto:yuriy.tymchuk@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 <mailto:stepharo@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 <http://www.tudorgirba.com/> > >>>>>> www.feenk.com <http://www.feenk.com/> > >>>>>> > >>>>>> "It's not what we do that matters most, it's how we do it." > >>>>>> > >>>>>> > >>>>>> > >>>> -- > >>>> www.tudorgirba.com <http://www.tudorgirba.com/> > >>>> www.feenk.com <http://www.feenk.com/> > >>>> > >>>> "Quality cannot be an afterthought." > >> -- > >> www.tudorgirba.com <http://www.tudorgirba.com/> > >> www.feenk.com <http://www.feenk.com/> > >> > >> "Every thing has its own flow." > >> > >> > >> > >> > >> > >> > >> > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "Every thing should have the right to be different." > > > > > >

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by Luc Fabresse

Hi, My point of view is: 1) in code/core, we should use (we already said that with Camille in the past ;-)): self environmentAt: #Blah Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol Object class>>environmentAt: aSymbol ... The idea is that we can then customize name resolution, per object, per class and per module in the future. 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). I would start simple as said before, re-package it and add a rule as suggested by Denis. Now, I am not sure that making asClass supporting name resolution in another environment is really useful. And if we do it using thisContext, some developers may use that instead of "obj environmentAt: XXX" which would be bad. my 2KÄ, #Luc 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > > > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Thanks doru. > > > > I do not like when people think that we are complaining just because > something changes. > > > > It should change for the better and we all agree on that. > > Certainly. There are many points of view and many constraints. This is why > it is so important that we all bring forward those constraints because only > like this we can reach a global maximum. > > So, about asClass, everyone agrees that it should be moved to another > package. The open questions are: > - do we add an automatic deprecation for those that use it in code, or > - do we make use of thisContext to retrieve the environment? > (or both) > > Also, what about the asClassInEnvironment: method? Can it be used in code, > or do we better discourage its usage altogether? I am thinking that if we > have to write: > #MyClass asClassInEnvironment: self class environment > is even longer than: > self environment at: #MyClass > so, I think there is little point to it. > > In fact, for scripting what I find useful is not so much less characters, > but the lack of parentheses, hence unary methods. That is why asClass is > worth being salvaged for scripting (even with a solution that is slower > with thisContext), but the rest maybe can be removed. What do you think? > > Cheers, > Doru > > > > > Stef > > > > > >>>>>> 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." > >> > >> > >> > >> > >> > >> > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > > >

Aug. 26, 2016

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

by Gour

On Fri, 26 Aug 2016 14:27:24 +0800 Ben Coman <btc(a)openinworld.com> wrote: > Definitely. And not necessarily that you *solve* an issues, but that > I found a benefit from "goal directed learning". That's a good point! > When I started using Pharo I learned a lot from: * trying to reproduce > issues - which also benefits core developers if you can gather more > complete symptom info * testing other people's solutions - putting > halts in the changed code and simultaneously stepping through the > original and solution code. Actually I was surprised at far into the > depths of the system this led me sometimes and how accessible they > were. Look for issue marked "Fixed - review needed" Thank you. It seems that I'm ahead of new (learning) experience provided by "inspired by Smalltalk" environment. :-) Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated â for him there is no duty.

Aug. 26, 2016

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

by Gour

On Thu, 25 Aug 2016 23:06:51 +0200 Tudor Girba <tudor(a)tudorgirba.com> wrote: > It definitely does! We are all noobs in many parts in our system. Heh, I'm for the whole 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 :). OK, thank you for encouraging me...I'm going to create it. ;) Sincerely, Gour -- A person is said to be established in self-realization and is called a yogÄ« [or mystic] when he is fully satisfied by virtue of acquired knowledge and realization. Such a person is situated in transcendence and is self-controlled. He sees everything â whether it be pebbles, stones or gold â as the same.

Aug. 26, 2016

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

by Ben Coman

On Thu, Aug 25, 2016 at 11: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 account > in case there are some low-hanging fruits to pick? Definitely. And not necessarily that you *solve* an issues, but that I found a benefit from "goal directed learning". When I started using Pharo I learned a lot from: * trying to reproduce issues - which also benefits core developers if you can gather more complete symptom info * testing other people's solutions - putting halts in the changed code and simultaneously stepping through the original and solution code. Actually I was surprised at far into the depths of the system this led me sometimes and how accessible they were. Look for issue marked "Fixed - review needed" cheers -ben

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by Tudor Girba

Hi, > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: > > Thanks doru. > > I do not like when people think that we are complaining just because something changes. > > It should change for the better and we all agree on that. Certainly. There are many points of view and many constraints. This is why it is so important that we all bring forward those constraints because only like this we can reach a global maximum. So, about asClass, everyone agrees that it should be moved to another package. The open questions are: - do we add an automatic deprecation for those that use it in code, or - do we make use of thisContext to retrieve the environment? (or both) Also, what about the asClassInEnvironment: method? Can it be used in code, or do we better discourage its usage altogether? I am thinking that if we have to write: #MyClass asClassInEnvironment: self class environment is even longer than: self environment at: #MyClass so, I think there is little point to it. In fact, for scripting what I find useful is not so much less characters, but the lack of parentheses, hence unary methods. That is why asClass is worth being salvaged for scripting (even with a solution that is slower with thisContext), but the rest maybe can be removed. What do you think? Cheers, Doru > > Stef > > >>>>>> 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." >> >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

Thanks doru. I do not like when people think that we are complaining just because something changes. It should change for the better and we all agree on that. Stef >>>>> 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. 26, 2016

UIprocess around when loading broken code

by stepharo

Hi yesterday I started to port omnibase to pharo and it uses the old API apicall: so it breaks when loading. I got some windows showing errors and after the image was full of new UIProcess. Can someone try to reproduce it and I think that we should fix it? Stef

Aug. 26, 2016

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

by Martin Dias

ok, ok, thanks ;-) Loading latest ConfigurationOfEpicea from Epicea's repo and load bleedingEdge fixes the #name issue in the script. Tomorrow I can release the new version. Martin On Thu, Aug 25, 2016 at 6:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. 26, 2016