Event handling insanity
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in.. So, here is small list of problems i faced: - broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm) - debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :) - and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made. - veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies. - decrypting kilometers long event traces to see what goes where But when things finally start work properly, you feel excited :) -- Best regards, Igor Stasenko.
Hi igor I imagine that quite well. Terribly tedious. I was wondering what would be a good architecture to handle it in the future: probably the approach of guillermo wtih one image poking another one Stef Le 27/7/15 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
:)
-- Best regards, Igor Stasenko.
On 27 July 2015 at 16:31, stepharo <stepharo@free.fr> wrote:
Hi igor
I imagine that quite well. Terribly tedious. I was wondering what would be a good architecture to handle it in the future: probably the approach of guillermo wtih one image poking another one
Well, i had idea once, to implement a sandbox window.. which works completely separate from main UI and all in it is err.. sandboxed. :) Everything comes in, nothing comes out.. In that way, if something horrible happens in sandbox , it doesn't affects the hosting environment.. Unfortunately it is easy to imagine as concept, but quite hard to implement given the state of our current system. The main barrier for this is tons and tons of global state and singletons everywhere.
Stef
Le 27/7/15 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix,
but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
:)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Hi igor
I imagine that quite well. Terribly tedious. I was wondering what would be a good architecture to handle it in the future: probably the approach of guillermo wtih one image poking another one
Well, i had idea once, to implement a sandbox window.. which works completely separate from main UI and all in it is err.. sandboxed. :) Everything comes in, nothing comes out.. In that way, if something horrible happens in sandbox , it doesn't affects the hosting environment.. Unfortunately it is easy to imagine as concept, but quite hard to implement given the state of our current system. The main barrier for this is tons and tons of global state and singletons everywhere.
Yes. We will to address this one by one. First bloc will remove some of them. The bootstrap will also help. Stef
Stef
Le 27/7/15 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
:)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Mon, Jul 27, 2015 at 8:42 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
Instead of printing them to Transcript, add the Events to a global OrderedCollection. Extremely fast and now you can even instrospect them.
- decrypting kilometers long event traces to see what goes where
Filter what goes in and/or trim your global collection.
On 27 July 2015 at 18:23, Chris Muller <asqueaker@gmail.com> wrote:
On Mon, Jul 27, 2015 at 8:42 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
Instead of printing them to Transcript, add the Events to a global OrderedCollection. Extremely fast and now you can even instrospect them.
- decrypting kilometers long event traces to see what goes where
Filter what goes in and/or trim your global collection.
Well that , of course, is an option.. i was considering building some tools that i need.. But that means extra work on a tooling support, with own specialized UI.. Sure thing, if i would have years ahead, i would do it this way :) The problem is that event tracing/tracking is only one small piece of puzzle. Of course better tools would help a lot, but the scope of UI hacking is way much larger than just tracking events. -- Best regards, Igor Stasenko.
Le 27/07/2015 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events..
Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything. I don't understand. You have the tools, why don't you use them? Thierry
I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
-- Best regards, Igor Stasenko.
On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 27/07/2015 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events..
Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything.
I don't understand. You have the tools, why don't you use them?
Perhaps because i unaware of them? And while i agree that using robust tools would help, i don't see how tools can help with "unkilling" an image which you just killed by own hand because of mistake you made :) About Jejak, i only found this: http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html Where i can read bout it? It sounds very useful indeed. Thierry
I had very annoying problem with mouse move handling and processing it
correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 28-07-15 18:35, Igor Stasenko wrote:
On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier@gmail.com wrote: I don't understand. You have the tools, why don't you use them?
Perhaps because i unaware of them?
Yes, our big problem. Great tools, not enough awareness and knowledge on how to use them. Stephan
Hi Igor, Le 28/07/2015 18:35, Igor Stasenko a écrit :
On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 27/07/2015 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events..
Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything.
I don't understand. You have the tools, why don't you use them?
Perhaps because i unaware of them? And while i agree that using robust tools would help, i don't see how tools can help with "unkilling" an image which you just killed by own hand because of mistake you made :)
That one is hard to recover from. We can only trace (and use an external logging tool), or remote exception/debugging capacity.
About Jejak, i only found this: http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
The current version is hosted on github, at http://github.com/ThierryGoubier/Jejak
Where i can read bout it? It sounds very useful indeed.
There is no real paper on it; I can send you the technical report I wrote on it in 2007 at UBO, but it focuses more on how it was implemented (especially optimised) for VisualWorks. Thierry
On 28 July 2015 at 22:27, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Igor,
Le 28/07/2015 18:35, Igor Stasenko a écrit :
On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 27/07/2015 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events..
Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything.
I don't understand. You have the tools, why don't you use them?
Perhaps because i unaware of them? And while i agree that using robust tools would help, i don't see how tools can help with "unkilling" an image which you just killed by own hand because of mistake you made :)
That one is hard to recover from. We can only trace (and use an external logging tool), or remote exception/debugging capacity.
Yeah, anyways that's orthogonal to event tracing. One tools for this, another for that.. Sure tools are handy, and i am not opposed to use them if it could save my time and effort.
About Jejak, i only found this:
http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
The current version is hosted on github, at http://github.com/ThierryGoubier/Jejak
Where i can read bout it? It sounds very useful indeed.
There is no real paper on it; I can send you the technical report I wrote on it in 2007 at UBO, but it focuses more on how it was implemented (especially optimised) for VisualWorks.
This time i remember Stef's words: if it has no docs it doesn't exists. He said this about things i do, and not caring documenting it well. But same applies to situation when i want to use something, isn't? See, i would happily use anything that could help me in my adventure, unless it will means delving into separate adventure of 'discover by yourself and do some (re)search in code about how this or that great tool works and how to use it'. That's the answer to your original question, why me (or other people) don't using a great tools lying and waiting for them. Nobody cares about writing docs (including myself), that's why i don't dare asking people why they not using them. Because i know the answer :) Thierry
-- Best regards, Igor Stasenko.
Le 28/07/2015 23:40, Igor Stasenko a écrit :
On 28 July 2015 at 22:27, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Hi Igor,
Le 28/07/2015 18:35, Igor Stasenko a écrit :
On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com> <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>> wrote:
Le 27/07/2015 15:42, Igor Stasenko a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events..
Esay Igor, just use a code event tracer as for example Jejak, and all you describe below won't happen. Or an event logger, or metalinks, or anything.
I don't understand. You have the tools, why don't you use them?
Perhaps because i unaware of them? And while i agree that using robust tools would help, i don't see how tools can help with "unkilling" an image which you just killed by own hand because of mistake you made :)
That one is hard to recover from. We can only trace (and use an external logging tool), or remote exception/debugging capacity.
Yeah, anyways that's orthogonal to event tracing. One tools for this, another for that.. Sure tools are handy, and i am not opposed to use them if it could save my time and effort.
Yes, this is the hard part with tools. There is a required investment, and, specially for the tool developper, if there is little traction, then he just keep them for himself ;)
About Jejak, i only found this: http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
The current version is hosted on github, at http://github.com/ThierryGoubier/Jejak
Where i can read bout it? It sounds very useful indeed.
There is no real paper on it; I can send you the technical report I wrote on it in 2007 at UBO, but it focuses more on how it was implemented (especially optimised) for VisualWorks.
This time i remember Stef's words: if it has no docs it doesn't exists. He said this about things i do, and not caring documenting it well. But same applies to situation when i want to use something, isn't? See, i would happily use anything that could help me in my adventure, unless it will means delving into separate adventure of 'discover by yourself and do some (re)search in code about how this or that great tool works and how to use it'.
Yes, Stef is right, in a way. Documentation is also written in response to a community; if there is no response, then the documentation is not written or rots away as the Pharo versions come and go.
That's the answer to your original question, why me (or other people) don't using a great tools lying and waiting for them.
Yes. It also makes a view on efforts reinventing the wheel here and there, or not progressing much apart as engineering efforts. Engineering efforts are necessary, but, in themselves, they are a bit disappointing if you know the state of the art in that particular field.
Nobody cares about writing docs (including myself), that's why i don't dare asking people why they not using them. Because i know the answer :)
Yes and no. I told you: some of it is community response. Given the effort and response to the Metalink work underway, I thought that the pharo community was aware of what they could / should enable as tooling ;) Regards, Thierry
I've had good results debugging GUI subsystems by using the GUI of a remote system for interacting with exceptions. Something goes wrong in system A, but the exception notifier is displayed on system B, etc. It's also helpful to be able to revert methods and classes from afar, as well. For simple use cases, I've used the simulator, too. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Hi! Related to this, I find very painful to write unit tests for gui. Generating event by hand is quite tedious. Someone has worked on that direction already? Cheers Alexandre
Le 27 juil. 2015 à 10:42, Igor Stasenko <siguctua@gmail.com> a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
-- Best regards, Igor Stasenko.
abergel wrote
Related to this, I find very painful to write unit tests for gui. Generating event by hand is quite tedious. Someone has worked on that direction already?
#simulateClick and friends? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Event-handling-insanity-tp4839608p4839750.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 28 July 2015 at 11:31, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
Related to this, I find very painful to write unit tests for gui. Generating event by hand is quite tedious. Someone has worked on that direction already?
Yeah, i spent an hour playing with making benchmark on handling mouse move events.. Had quite random results, not giving any clue where the bottleneck/problem is. Decrypting & interpreting message tally is hell of a pain. Especially when it is not quite capable to show all stats about where time spent (including simple sleeping time)... or maybe because i am incapable to interpret it correctly.. which at the end gives same result: no result :)
Cheers Alexandre
Le 27 juil. 2015 à 10:42, Igor Stasenko <siguctua@gmail.com> a écrit :
Nothing here is about things to fix, but rather about how impossible to debug event handling in system that runs and relies on very same events.. I had very annoying problem with mouse move handling and processing it correctly, and i finally solved the problem after number of attempts to track down where problem lies in..
So, here is small list of problems i faced:
- broken image (image won't start up) , because i send unimplemented message in critical place, thus image simply non-responsible/crashing immediately after startup. Easy to fix (sarcasm)
- debugger window spam on every event (because of DNU/other exception). A slightly friendlier problem than above :)
- and last one, if you break some event handling/delivery, even if image "behaves" you simply left without events doing what is needed, means you got another form of a broken image, which you cannot use anymore and need to start over and revert the changes you made.
- veeeerrrrryyy slow event handling, because of printing every event into transcript , trying to see where the shit lies.
- decrypting kilometers long event traces to see what goes where
But when things finally start work properly, you feel excited :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (8)
-
Alexandre Bergel -
Chris Muller -
Craig Latta -
Igor Stasenko -
Sean P. DeNigris -
Stephan Eggermont -
stepharo -
Thierry Goubier