Le 28/07/2015 23:40, Igor Stasenko a écrit :
On 28 July 2015 at 22:27, Thierry Goubier <[email protected]
<mailto:[email protected]>> wrote:
Hi Igor,
Le 28/07/2015 18:35, Igor Stasenko a écrit :
On 27 July 2015 at 18:31, Thierry Goubier
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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
