- Pharo-dev - lists.pharo.org

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

by stepharo

Igor please use your energy helping us. Stef Le 1/4/16 22:47, Igor Stasenko a Ã©crit : > > > On 1 April 2016 at 21:52, stepharo <stepharo(a)free.fr > <mailto:stepharo@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 >> <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. > > > > > -- > Best regards, > Igor Stasenko.

April 2, 2016

Xtreams: Which Repository

by Sean P. DeNigris

There are: 1. http://www.squeaksource.com/Xtreams, from which the Pharo 4 Config Browser loads 2. http://smalltalkhub.com/#!/~juampi/Xtreams/, which claims to be porting Xtreams to "Pharo 6" 3. https://github.com/mkobetic/Xtreams Does anyone know: - Who is working on #2 and what is its status relative to the two other repos? - Is #3 currently useful? - How far are each of these from the latest code in VW? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-Which-Repository-tp4887888.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 2, 2016

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

by Igor Stasenko

On 2 April 2016 at 03:06, Robert Withers <robert.w.withers(a)gmail.com> wrote: > Good to see you again, Igor. Would it make sense to define instVar > initializers in the class object allowing the install of init forwarders in > the object slots on VM for a Squeak-style implicitly typed dependency > injection? Welcome. > > I would certainly recommend to construct objects prefilled with sane defaults, especially taking advantage of having extra niceties from VM, and especially when it about UI domain, where insane complexity knocking to your doors right from the beginning. But alas, due to inherent nature of UI that tends to be complex, often you need to generate a whole subgraph of objects, and therefore you are limited in choice: basically you have to carefully design a multi-stage initialization procedure, sorting out all chickens and their eggs, before giving things away for later use. That is doable and once you define in your object soup who gonna make a first move, you defining the order of initialization and consequently the constraints of being able to access certain properties during partial initialization or not. Else, if you not define any constraints, and let things grow naturally, sure you will end up using on-do-nothing more and more often, up to the point that you find youself unable to initialize any object without taking 'advantage' provided by such pattern. :) > --- > robert > > On Apr 1, 2016, at 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Another approach would be to prefill the object with initial default > values, so that it has no any inconsistency right from its birth. Even if > your next statement has 99.9% chance to override these defaults, you > eliminating this 0.01% that causing nil errors. That, of course, raising > another problem - that you might be dealing with 'wrong' initial state, but > it is much less harmful than dealing with nils popping out of nowhere. > > > On 2 April 2016 at 02:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >> >>> >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. >>> >>> >>> >> Amen. Simply avoid using objects in incomplete state to prevent errors >> like we see in this topic. That means, you should not mess with object's >> properties until it is fully initialized, that's what #initialize for. >> If you have coupling and chicken and egg problem like parent/child >> relationship - you shall again make sure nobody accessing that couple from >> outside while it is still in inconsistent state, and then once it is fully >> initialized - you don't need to guard against silly nil errors, because >> everything is set up. >> And in that couple, you can split things on stages, making sure that on >> initial stage, you again don't use/access not yet initialized properties. >> You need a plan, to be able to not put cart in front of the horse and >> that is much better than putting it that way and then trying to deal with >> it in a way like on-do-nothing pattern. >> >> Once again, one way or another - you don't need to use on-do-nothing, if >> you doing things right. And if you need it - then that indicates that you >> got a problem, and instead of solving and fixing it, you bury it under >> "catch-all and shut-up" gravestone :) >> >> >>> Best regards, >>> >>> Henrik >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.

April 2, 2016

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

by Robert Withers

Good to see you again, Igor. Would it make sense to define instVar initializers in the class object allowing the install of init forwarders in the object slots on VM for a Squeak-style implicitly typed dependency injection? Welcome. --- robert > On Apr 1, 2016, at 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Another approach would be to prefill the object with initial default values, so that it has no any inconsistency right from its birth. Even if your next statement has 99.9% chance to override these defaults, you eliminating this 0.01% that causing nil errors. That, of course, raising another problem - that you might be dealing with 'wrong' initial state, but it is much less harmful than dealing with nils popping out of nowhere. > > >> On 2 April 2016 at 02:20, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >>> On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >>> >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. >>> >> >> Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for. >> If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up. >> And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties. >> You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern. >> >> Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :) >> >>> Best regards, >>> >>> Henrik >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.

April 2, 2016

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

by Igor Stasenko

Another approach would be to prefill the object with initial default values, so that it has no any inconsistency right from its birth. Even if your next statement has 99.9% chance to override these defaults, you eliminating this 0.01% that causing nil errors. That, of course, raising another problem - that you might be dealing with 'wrong' initial state, but it is much less harmful than dealing with nils popping out of nowhere. On 2 April 2016 at 02:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > >> >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. >> >> >> > Amen. Simply avoid using objects in incomplete state to prevent errors > like we see in this topic. That means, you should not mess with object's > properties until it is fully initialized, that's what #initialize for. > If you have coupling and chicken and egg problem like parent/child > relationship - you shall again make sure nobody accessing that couple from > outside while it is still in inconsistent state, and then once it is fully > initialized - you don't need to guard against silly nil errors, because > everything is set up. > And in that couple, you can split things on stages, making sure that on > initial stage, you again don't use/access not yet initialized properties. > You need a plan, to be able to not put cart in front of the horse and that > is much better than putting it that way and then trying to deal with it in > a way like on-do-nothing pattern. > > Once again, one way or another - you don't need to use on-do-nothing, if > you doing things right. And if you need it - then that indicates that you > got a problem, and instead of solving and fixing it, you bury it under > "catch-all and shut-up" gravestone :) > > >> Best regards, >> >> Henrik >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 1, 2016

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

by Igor Stasenko

On 2 April 2016 at 01:07, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > You are more than welcome to come back. > > Thank you. > 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. > > Arguable. Sometimes "Purge the heretics" tactic works better to teach people to not make code smells. Sometimes don't. :) In any case, i never target personalities, if you know me, i only target bad, smelly code. Yeah, i maybe overreacting and using harsh wording.. But that just to underscore my attitude towards the subject.. but never towards people. Because i know, most of people that contributing here having good intentions, so there's no point to do any personal attacks. > 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." > > > -- Best regards, Igor Stasenko.

April 1, 2016

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

by Igor Stasenko

On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > >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. > > > Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for. If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up. And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties. You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern. Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :) > Best regards, > > Henrik > -- Best regards, Igor Stasenko.

April 1, 2016

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