Hi Doru,
Le 04/10/2014 22:48, Tudor Girba a écrit :
Hi Thierry,
On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier
<[email protected] <mailto:[email protected]>> wrote:
Hi,
Le 04/10/2014 11:54, Tudor Girba a écrit :
And now you are starting to have the issue of handling
slices on GT
from Pharo: do people have to register on Moose,
resynchronize on GT
on Moose, push their slices there, wait for Moose to push a
slice to
integrate on Pharo, wait for Pharo to integrate that slice?
Something like that. Only there is no wait time to integrate in
Moose as
GT is a standalone project, and Moose simply integrates the latest
development version of all its dependencies. So, there is not
that much
difference to integrating in Pharo. Once a new stable version of
GT is
available, it will automatically be available in Pharo.
I don't think this is the way to go. It raises an additional barrier
to contributions to GT, such as:
A - I tried GTPlayground on Pharo, I had a DNU, here is the issue I
created.
A - I pushed a slice with the corrections
B - In GT development version we decided to go another way. We don't
need your slice. Please wait for the next stable version and try
again. Thank you for your contribution.
A ---
I'm not sure you'll get another contribution from A after that
exchange ;)
I do not understand your scenario. How is it any different from the
Pharo integration? If the integrator decides it's not a good fix, it
does not get integrated. There will be barely any delay.
I think you need to reread the exchange. Because Glamour main
development is kept separate from Pharo, with a Glamour stable being
pushed into Pharo, then you increase the chances that you diverges
temporarily the stable Glamour from the one in Pharo. And simply make it
costly for someone in Pharo to participate.
I don't think it would cost you much to consider that stable Glamour is
the one in Pharo, and that the development one is kept in Moose, with
merges of the development Glamour to the stable one in Pharo. You would
loose a bit of control on stable Glamour, because any maintainer of
Pharo could integrate fixes, in exchange for making it easier for
non-Moose users to contribute. Your call :)
I found that stepping through the opening sequence of GT to
debug
MorphTreeMorph a pain and had to find another way to
understand the
issue.
Can you be more specific? What did you try to achieve and did
not manage?
I was trying to find out why a MorphTreeMorph would DNU upon
GTDebugger opening ;)
I gave up and went blindly into the MorphTreeMorph code instead,
trying to solve it by luck.
Can you be more specific, please? What did you do to get a DNU?
That was at that occasion:
http://moose-dev.97923.n3.nabble.com/debugger-in-the-last-moose-tp4032413p4032415.html
I do have specific tools I can use in such circumstances
that you
don't have.
What kind of tools? I would be interested in learning about them
and the
analysis use cases they support.
I have a trace tool for those situations (and also for parser work).
What trace tool? Is an example available?
http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
My original use case was:
- Finding the bug in an error correction decoding algorithm which
worked without error, but with non-satisfying results: lower than
expected SNR.
- Has then been used very successfully to explain the algorithm.
- Was then used as the basis for a hardware design methodology by
dynamic code traces of multithreaded programs
Other use cases I use it for:
- Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text
editor errors) where halt makes the image unusable.
- Debugging code in Parsers when the code of a reduction is not
working properly (somewhere deep in the AST).
Is this more than a logger?
Part of it is a logger, to record events.
A second part of it is a code rewriting tool. You give it a method, it
adds the code to trace the execution and recompiles the method.
A third part is a viewer which links each recorded event with the
expression which generated it in the method.
(The second part could be changed to use the Opal facilities instead of
code rewriting. There is probably work to be done on the logger as well:
remote logging via RS232, Jtag probes, etc...).
Thierry
