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

Re: [Pharo-dev] Catching Exceptions without any notice

by Henrik Nergaard

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize: >Initialize > self height: [ :morph | morph owner height ]. No. ownerChanged self height: owner height. â¦â¦â¦â¦.. One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand. If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images. ThatMorph new exportAsPng. Best regards, Henrik

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Tudor Girba

Hi Igor, You are more than welcome to come back. Too much acidity is good neither for you nor for the people around you :). Letâs be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans. Cheers, Doru > On Apr 1, 2016, at 10:51 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 1 April 2016 at 09:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Nice to hear from you Igor. I am glad to see you around here. > > Hi, Doru. Yeah, i am considering whether i want to return to things i left, or not. So, expect more of my acid sarcasm in future. Maybe :) > > I do not see how your quote applies to the current case given that the original authors did not leave anywhere, but perhaps it was a joke, and I did not get it. > > We all will leave sooner or later. The only what matters is what we left behind :) > > Cheers, > Doru > > > > On Apr 1, 2016, at 5:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > A perfect example of careless programming. > > "I'll do it my way, and if it causing any problems, i don't care and i will just ignore them. And it's not my problem anyways, i went to something else already, since this part is works and DONE" > > :) > > > > On 30 March 2016 at 14:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Please don't do this: > > > > updateHeight > > "no need to care about height, when it's logic is not customized" > > self layout isHeightCustom ifFalse: [ ^ self ]. > > [ self bounds: (self brickBounds withHeight: self customHeight) ] > > on: Exception > > do: [ "just skip and do nothing" ] > > > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible. > > see > > GLMBrickGeometryTrait>>#updateHeight > > GLMBrickGeometryTrait>>#updateWidth > > > > And if you log out the raised exception, you see some calls to > > not initialized fonts and a ZeroDevide and some more errors. > > The above catch, catches and hides wrong / to late initialized objects. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Eliot Miranda

Hi Aliaksei, Hi Stef, On Fri, Apr 1, 2016 at 2:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Thanks for feedback :) > > Indeed, this is a nice case to learn from. That piece of code was written > when I just started working with pharo after coming from Java world. > > Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late > initialized objects. For example, imagine a Morph with height that is equal > to owner's height. In this case one would write in #initialize: > > initialize > self height: [ :morph | morph owner height ]. > > After setting an object as a new height, it gets evaluated and in case of > example before throws DNU because owner is obviously still nil. > > Trying to improve overall readability I decided to ignore all errors in > that kind of blocks instead of putting ifNil:ifNotNil: in hundred places. > > Also, I could not imagine that Warning is actually an Exception and > exception (in its common sense) is an Error. However, I had in mind that > later that kind of code smell should be replaced at least by custom error > handler, like we have now in spotter that catches all errors allowing not > buggy processors to do their work. > Btw, in first versions of spotter it was the same: it catched exception > instead of error but more experienced colleges suggested to not do it like > that. > > Nevertheless, later I realized that blocks are evil, and instead of trying > to work with nils it's much easier and cleaner to just put an assertion. > > As a hotfix, I will replace Exception to Error tomorrow. (bad, but > still...) > > Don't hesitate to post code smells, at least we can make jokes of them :) > :-). Stef, no one is "bashing someone". We /must/ be able to criticise code if we want the code base to get better, and this code was bad. Aliaksei responded to the criticism positively and did not take it personally. But the interesting point is that Aliaksei and people like him are clearly skilled programmers but they are coming to Pharo (or Squeak, or Smalltalk in general) from other systems, and if we as a community are successful in promoting Pharo, Squeak, Newspeak et al, we can expect many more people like Aliaksei to come to our community and want to contribute. So I wonder if we have the energy and resource to write brief documentation on good style vs bad style aimed at the experienced OO programmer who is trying Smalltalk for the first time. I think this is an important demographic to serve, and I think the form of the documentation would be considerably different to normal introductory texts; it can use a much steeper learning curve and can go from "here's how you do it", to "here's how to do it right" and "here's how not to do it", very quickly; something that the usual introductory texts stay away from, leaving these important topics to "advanced" course materials. Cheers > Alex > Cheers! > On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > >> Please don't do this: >> >> updateHeight >> "no need to care about height, when it's logic is not customized" >> self layout isHeightCustom ifFalse: [ ^ self ]. >> [ self bounds: (self brickBounds withHeight: self customHeight) ] >> on: Exception >> do: [ "just skip and do nothing" ] >> >> This makes debugging GLM/Brick ui/layout code with "self haltOnce" >> impossible. >> see >> GLMBrickGeometryTrait>>#updateHeight >> GLMBrickGeometryTrait>>#updateWidth >> >> And if you log out the raised exception, you see some calls to >> not initialized fonts and a ZeroDevide and some more errors. >> The above catch, catches and hides wrong / to late initialized objects. >> > -- _,,,^..^,,,_ best, Eliot

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Aliaksei Syrel

Thanks for feedback :) Indeed, this is a nice case to learn from. That piece of code was written when I just started working with pharo after coming from Java world. Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to owner's height. In this case one would write in #initialize: initialize self height: [ :morph | morph owner height ]. After setting an object as a new height, it gets evaluated and in case of example before throws DNU because owner is obviously still nil. Trying to improve overall readability I decided to ignore all errors in that kind of blocks instead of putting ifNil:ifNotNil: in hundred places. Also, I could not imagine that Warning is actually an Exception and exception (in its common sense) is an Error. However, I had in mind that later that kind of code smell should be replaced at least by custom error handler, like we have now in spotter that catches all errors allowing not buggy processors to do their work. Btw, in first versions of spotter it was the same: it catched exception instead of error but more experienced colleges suggested to not do it like that. Nevertheless, later I realized that blocks are evil, and instead of trying to work with nils it's much easier and cleaner to just put an assertion. As a hotfix, I will replace Exception to Error tomorrow. (bad, but still...) Don't hesitate to post code smells, at least we can make jokes of them :) Cheers Alex On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > Please don't do this: > > updateHeight > "no need to care about height, when it's logic is not customized" > self layout isHeightCustom ifFalse: [ ^ self ]. > [ self bounds: (self brickBounds withHeight: self customHeight) ] > on: Exception > do: [ "just skip and do nothing" ] > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" > impossible. > see > GLMBrickGeometryTrait>>#updateHeight > GLMBrickGeometryTrait>>#updateWidth > > And if you log out the raised exception, you see some calls to > not initialized fonts and a ZeroDevide and some more errors. > The above catch, catches and hides wrong / to late initialized objects. >

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Igor Stasenko

On 1 April 2016 at 09:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Nice to hear from you Igor. I am glad to see you around here. > > Hi, Doru. Yeah, i am considering whether i want to return to things i left, or not. So, expect more of my acid sarcasm in future. Maybe :) > I do not see how your quote applies to the current case given that the > original authors did not leave anywhere, but perhaps it was a joke, and I > did not get it. > > We all will leave sooner or later. The only what matters is what we left behind :) > Cheers, > Doru > > > > On Apr 1, 2016, at 5:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > A perfect example of careless programming. > > "I'll do it my way, and if it causing any problems, i don't care and i > will just ignore them. And it's not my problem anyways, i went to something > else already, since this part is works and DONE" > > :) > > > > On 30 March 2016 at 14:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Please don't do this: > > > > updateHeight > > "no need to care about height, when it's logic is not customized" > > self layout isHeightCustom ifFalse: [ ^ self ]. > > [ self bounds: (self brickBounds withHeight: self customHeight) ] > > on: Exception > > do: [ "just skip and do nothing" ] > > > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" > impossible. > > see > > GLMBrickGeometryTrait>>#updateHeight > > GLMBrickGeometryTrait>>#updateWidth > > > > And if you log out the raised exception, you see some calls to > > not initialized fonts and a ZeroDevide and some more errors. > > The above catch, catches and hides wrong / to late initialized objects. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > > > -- Best regards, Igor Stasenko.

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Igor Stasenko

On 1 April 2016 at 21:52, stepharo <stepharo(a)free.fr> wrote: > Hi > > I do not think that aliaksei is not taking care. > He is working a lot to make sure that Pharo will have a future from the UI > perspective. He is spending all his free time > on Bloc and what he is doing is massive. He rewrote the AthensCairoBack > end to optimise it for Bloc local coordinates. > I'm sure that if someone would have propose some help to him he would have > gladly accepted. > > I personnaly thank him for all the energy that he is putting into Bloc. > The talk at PharoDays was showing really nice results. > Bloc is really getting to be really nice and change the face of Pharo for > the next decades so we should encourage people doing > Bloc! > > So instead of bashing someone, I would prefer that we help him. > Yes Pharo has some code that we do not like and I have my own list. Now > the best things to do is to > improve code review and to fix when we see something wrong. > > Hi, Stef. No, it is not about whether you care about things you do or not. It is about approach. If you done something, that good indication that you care about it, isn't? But there's many ways how you doing something. I am sorry, i won't stop bashing approaches like this piece of code demonstrating. It was not a first time you seen my reaction on such piece of code (we seen that before, exactly related to "on:do: nothing" before), and i don't think you shall be surprised that my reaction is unchanged :) My take on this: on-do-nothing pattern is good only for one thing: for bug hunting and putting temporary kludges in code in order to find the root of problem. Once problem is solved, you shall remove this.. as well as any 'Transcript show:' , 'Halt once' and stuff like that. On-do-nothing really don't belongs to category of any production code that pretends to be a good quality one. Stef > > > Le 1/4/16 05:54, Igor Stasenko a Ã©crit : > > A perfect example of careless programming. > "I'll do it my way, and if it causing any problems, i don't care and i > will just ignore them. And it's not my problem anyways, i went to something > else already, since this part is works and DONE" > :) > > On 30 March 2016 at 14:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> Please don't do this: >> >> updateHeight >> "no need to care about height, when it's logic is not customized" >> self layout isHeightCustom ifFalse: [ ^ self ]. >> [ self bounds: (self brickBounds withHeight: self customHeight) ] >> on: Exception >> do: [ "just skip and do nothing" ] >> >> This makes debugging GLM/Brick ui/layout code with "self haltOnce" >> impossible. >> see >> GLMBrickGeometryTrait>>#updateHeight >> GLMBrickGeometryTrait>>#updateWidth >> >> And if you log out the raised exception, you see some calls to >> not initialized fonts and a ZeroDevide and some more errors. >> The above catch, catches and hides wrong / to late initialized objects. >> > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

April 1, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by stepharo

Hi I do not think that aliaksei is not taking care. He is working a lot to make sure that Pharo will have a future from the UI perspective. He is spending all his free time on Bloc and what he is doing is massive. He rewrote the AthensCairoBack end to optimise it for Bloc local coordinates. I'm sure that if someone would have propose some help to him he would have gladly accepted. I personnaly thank him for all the energy that he is putting into Bloc. The talk at PharoDays was showing really nice results. Bloc is really getting to be really nice and change the face of Pharo for the next decades so we should encourage people doing Bloc! So instead of bashing someone, I would prefer that we help him. Yes Pharo has some code that we do not like and I have my own list. Now the best things to do is to improve code review and to fix when we see something wrong. Stef Le 1/4/16 05:54, Igor Stasenko a Ã©crit : > A perfect example of careless programming. > "I'll do it my way, and if it causing any problems, i don't care and i > will just ignore them. And it's not my problem anyways, i went to > something else already, since this part is works and DONE" > :) > > On 30 March 2016 at 14:33, Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>> wrote: > > Please don't do this: > > updateHeight > "no need to care about height, when it's logic is not customized" > self layout isHeightCustom ifFalse: [ ^ self ]. > [ self bounds: (self brickBounds withHeight: self customHeight) ] > on: Exception > do: [ "just skip and do nothing" ] > > This makes debugging GLM/Brick ui/layout code with "self haltOnce" > impossible. > see > GLMBrickGeometryTrait>>#updateHeight > GLMBrickGeometryTrait>>#updateWidth > > And if you log out the raised exception, you see some calls to > not initialized fonts and a ZeroDevide and some more errors. > The above catch, catches and hides wrong / to late initialized > objects. > > > > > -- > Best regards, > Igor Stasenko.

April 1, 2016

Re: [Pharo-dev] [ANN] OS-Linux-CentOS

by stepharo

Hi torsten I'm trying to understand what you are doing? Are you use OSSubprocess? We will have one student starting to work on replacing bash scripts by pharo :) Stef Le 31/3/16 18:31, Torsten Bergmann a Ã©crit : > Hi, > > the OS-xxx series with (so far) > > - OS-Windows > - OS-Linux-Ubuntu > - OS-Unix > - OS-Raspbian > > now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized > pendant to "OS-Linux-Ubuntu". > > Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS > > Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" > into the Spotter search tool. > > Enjoy the video: > > https://www.youtube.com/watch?v=nAwtVeoll_k > > Bye > T. > > >

April 1, 2016

[Pharo5] [Issue tracker] Acton needed: Check issues tagged Pharo5

by Marcus Denker

Hi, The plan is to release Pharo5 soon (End of April, if possible). We have now 144 issues tagged for Pharo5, 41 of those âmust fixâ or higher. We need to go though all the 144 issues and decide: âIs this bug to bad that it does not allow for a release?â If not, we should move it to milestone âLaterâ. https://pharo.fogbugz.com/f/filters/125/5-0-All It would be good if either the original submitter or people involved in the discussion of those issues would have a look and help with taking this decision. (And of course, if you have potentialy show stopping bugs that are not in the list, this is the time to add themâ¦) Marcus

April 1, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50673 Home: https://github.com/pharo-project/pharo-core

April 1, 2016