Catching Exceptions without any notice
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.
Isn't catching too wide an anti-pattern? 2016-03-30 13:33 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
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.
Nicolas Cellier wrote
Isn't catching too wide an anti-pattern?
Yes! Just think of all the Exception subclasses which are *not* errors. This kind of thing effectively disables them.
2016-03-30 13:33 GMT+02:00 Nicolai Hess <
nicolaihess@
>:
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.
-- View this message in context: http://forum.world.st/Catching-Exceptions-without-any-notice-tp4887402p48874... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Do anyone really use GLM-Morphic-Brick? Because it is there just for spotter and will be deleted ASAP. We know that it is bad. Normal fix requires too many changes... On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
2016-03-30 19:54 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Do anyone really use GLM-Morphic-Brick?
We all "use" it, our tools are build with this. (inspector/debugger/playground/spotter).
Because it is there just for spotter and will be deleted ASAP.
Not only for spotter. And if our tools are build with this, people may try to use this for their own tools. This is the core image, and the core tools. What should we say? Please don't use it, but our core tools are built on this?
We know that it is bad. Normal fix requires too many changes...
No excuse.
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
Hi Nicolai, Thank you for the feedback. Just, please letâs adopt a different tone. Cheers, Doru
On Mar 31, 2016, at 8:37 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-03-30 19:54 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>: Do anyone really use GLM-Morphic-Brick?
We all "use" it, our tools are build with this. (inspector/debugger/playground/spotter).
Because it is there just for spotter and will be deleted ASAP.
Not only for spotter. And if our tools are build with this, people may try to use this for their own tools. This is the core image, and the core tools. What should we say? Please don't use it, but our core tools are built on this?
We know that it is bad. Normal fix requires too many changes...
No excuse.
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
-- www.tudorgirba.com www.feenk.com âLive like you mean it."
2016-03-31 10:51 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
Thank you for the feedback. Just, please letâs adopt a different tone.
Cheers, Doru
I am not sure what is wrong with my tone. I did not choose a random external library and starting to criticize it. This is a core component. And "Because it is there just for spotter and will be deleted ASAP. We know that it is bad. Normal fix requires too many changes." is not an excuse for badly debuggable code. I don't like to have quick-dirty-throwaway-hacks in the core. There is a real demand for debugging this code. The attached screenshot shows a common issue with inspector panes. The available space would suffice for all tabs (secodn window) but the default size shnrinks nearly all tabs (first window). The normal way to understand and trying to fix this issue, is to put some "self halt" at some point for the layout processing.But this does not work here because *all* exceptions are catched. And changing the code to actually execute the exception won't work either, becuase this will throw all other (previously cachted) exceptions (what is wrong with initializing the font property properly or checking for ZeroDivide?) And this is frustrating. And I hope no one sees and adopts this code, just because it is the way our own core tools are built. BTW, your LazyTabGroupMorph class is another bad example. It subclasses TabGroupMorph, it calls super initialize, removes all created and added morphs from its super class and recreates and replaces them with its own. nicolai
On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Do anyone really use GLM-Morphic-Brick?
Because it is there just for spotter and will be deleted ASAP.
We know that it is bad. Normal fix requires too many changes...
but catching Exception is bad because it will catch all, even Warnings and Halts. It would be less bad if it catches Error (not Exception). Still bad, but less bad :) Esteban
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess@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.
On the meantime at least change the handler to ignore the halts. ... on: Exception - Halt Should do the trick On Mar 31, 2016 06:57, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Do anyone really use GLM-Morphic-Brick?
Because it is there just for spotter and will be deleted ASAP.
We know that it is bad. Normal fix requires too many changes...
but catching Exception is bad because it will catch all, even Warnings and Halts. It would be less bad if it catches Error (not Exception). Still bad, but less bad :)
Esteban
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
On the meantime at least change the handler to ignore the halts.
... on: Exception - Halt
Should do the trick
Can someone say why ... on: Error will not improve things? Exception - Halt is just /wrong/, less wrong than Exception but still very wrong. _,,,^..^,,,_ (phone)
On Mar 31, 2016 06:57, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Do anyone really use GLM-Morphic-Brick?
Because it is there just for spotter and will be deleted ASAP.
We know that it is bad. Normal fix requires too many changes...
but catching Exception is bad because it will catch all, even Warnings and Halts. It would be less bad if it catches Error (not Exception). Still bad, but less bad :)
Esteban
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
Handling Error will be an improvement. But we don't know the rationale for handling Exception in the first place, if it's for ignoring some Warnings and Errors then changing the handler to Error would break things. I was trying to propose the less risky change, but I'm with you. The right solution is not to make the handler too broad, even handling Error is a bad smell. On Thu, Mar 31, 2016 at 11:22 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
On the meantime at least change the handler to ignore the halts.
... on: Exception - Halt
Should do the trick
Can someone say why ... on: Error will not improve things?
Exception - Halt is just /wrong/, less wrong than Exception but still very wrong.
_,,,^..^,,,_ (phone)
On Mar 31, 2016 06:57, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Do anyone really use GLM-Morphic-Brick?
Because it is there just for spotter and will be deleted ASAP.
We know that it is bad. Normal fix requires too many changes...
but catching Exception is bad because it will catch all, even Warnings and Halts. It would be less bad if it catches Error (not Exception). Still bad, but less bad :)
Esteban
On Mar 30, 2016 1:34 PM, "Nicolai Hess" <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.
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@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.
Hi, Nice to hear from you Igor. I am glad to see you around here. 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. Cheers, Doru
On Apr 1, 2016, at 5:54 AM, Igor Stasenko <siguctua@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@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."
On 1 April 2016 at 09:53, Tudor Girba <tudor@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@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@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.
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@gmail.com> wrote:
On 1 April 2016 at 09:53, Tudor Girba <tudor@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@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@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."
On 2 April 2016 at 01:07, Tudor Girba <tudor@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@gmail.com> wrote:
On 1 April 2016 at 09:53, Tudor Girba <tudor@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@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@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.
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.
+1 Especially since aliaksei took all the remarks I did on his code and he is asking for feedback. Stef
"Used for centuries to preserve meat and fish, citric acid has innumerable health benefits. It increases the acidity of the bacterial environment, making it difficult for the microbes to survive and, more importantly, to reproduce." Applies to bugs and code smells. Phil On Sat, Apr 2, 2016 at 11:45 AM, stepharo <stepharo@free.fr> wrote:
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.
+1 Especially since aliaksei took all the remarks I did on his code and he is asking for feedback.
Stef
On 2 April 2016 at 12:45, stepharo <stepharo@free.fr> wrote:
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.
+1 Especially since aliaksei took all the remarks I did on his code and he is asking for feedback.
Perfect. You working with a person who can accept and learn from criticism.. What on earth can be better than that? And if my 5 cents of acid helped to convince him, that's only makes me feel accomplished my mission :) (No pun and sarcasm intended).
Stef
-- Best regards, Igor Stasenko.
All forms of learning involve some degree criticism, and sometimes we learn the most from the hardest task masters. We all want a positive community, but we need to not fall into the trap of... "hacker forums where, out of some misguided sense of hyper-courtesy, participants are banned from posting any fault-finding with another's posts, and told âDon't say anything if you're unwilling to help the user.â The resulting departure of clueful participants to elsewhere causes them to descend into meaningless babble and become useless as technical forums. Exaggeratedly âfriendlyâ (in that fashion) or useful: Pick one. " [http://www.catb.org/esr/faqs/smart-questions.html] Its a balance to weave, but lets not be too quick on the trigger to impede someone's natural flow of thoughts. If too much burden is imposed to craft "cheerful" criticism, we might lose its contribution and the chance to learn. I learnt something from Igor's post. cheers -ben On Sat, Apr 2, 2016 at 6:07 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
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@gmail.com> wrote:
On 1 April 2016 at 09:53, Tudor Girba <tudor@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@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@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."
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@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.
On 1 April 2016 at 21:52, stepharo <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@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.
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@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@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.
On 2 April 2016 at 12:44, stepharo <stepharo@free.fr> wrote:
Igor please use your energy helping us.
I did not expected such a warm welcome and being in vain for more than a year.. Thank you all guys, you are great! Yes, as i said i feel like i want to get some involvement.. So expect more acid in future, because that is my energy taking such unordinary form sometimes :)
Stef
-- Best regards, Igor Stasenko.
I did not expected such a warm welcome and being in vain for more than a year.. Thank you all guys, you are great!
Yes, as i said i feel like i want to get some involvement.. So expect more acid in future, because that is my energy taking such unordinary form sometimes :)
I'm really happy for you. If you can help with the SDL 20 integration. I'm not sure that everything you did in last year may was integrated. In fact we did not have the time because of Spur and uFFI. In Pharo 60 we need to remove all the old event chain and only use OSWindows. Ronie will arrive a5 of April to Lille and he wants to work on Woden but also it would be good to have his FFI (with special bytecode) integrated into the JIT so I imagine that clement, eliot, esteban and ronie should talk. Stef
On 2 April 2016 at 17:31, stepharo <stepharo@free.fr> wrote:
I did not expected such a warm welcome and being in vain for more than a
year.. Thank you all guys, you are great!
Yes, as i said i feel like i want to get some involvement.. So expect more acid in future, because that is my energy taking such unordinary form sometimes :)
I'm really happy for you. If you can help with the SDL 20 integration. I'm not sure that everything you did in last year may was integrated. In fact we did not have the time because of Spur and uFFI. In Pharo 60 we need to remove all the old event chain and only use OSWindows.
Ronie will arrive a5 of April to Lille and he wants to work on Woden but also it would be good to have his FFI (with special bytecode) integrated into the JIT so I imagine that clement, eliot, esteban and ronie should talk.
I see. Thanks for heads up.
Stef
-- Best regards, Igor Stasenko.
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@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.
Hi Aliaksei, Hi Stef, On Fri, Apr 1, 2016 at 2:40 PM, Aliaksei Syrel <alex.syrel@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@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
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
On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard@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.
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@gmail.com> wrote:
On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard@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.
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@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@gmail.com> wrote:
On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard@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.
On 2 April 2016 at 03:06, Robert Withers <robert.w.withers@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@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@gmail.com> wrote:
On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard@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.
On 04/01/2016 05:40 PM, Aliaksei Syrel wrote:
Thanks for feedback :)
Nevertheless, later I realized that blocks are evil, ...
One touch of a block of evil :) https://www.youtube.com/watch?v=Fw9IqUgGlzs -- Robert . .. ... ^,^
On 2 April 2016 at 14:13, Robert Withers <robert.w.withers@gmail.com> wrote:
On 04/01/2016 05:40 PM, Aliaksei Syrel wrote:
Thanks for feedback :)
Nevertheless, later I realized that blocks are evil, ...
btw, why so?
One touch of a block of evil :)
https://www.youtube.com/watch?v=Fw9IqUgGlzs
-- Robert . .. ... ^,^
-- Best regards, Igor Stasenko.
participants (14)
-
Aliaksei Syrel -
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Gabriel Cotelli -
Henrik Nergaard -
Igor Stasenko -
Nicolai Hess -
Nicolas Cellier -
phil＠highoctane.be -
Richard Sargent -
Robert Withers -
stepharo -
Tudor Girba