Hi Thierry,
On Sat, Oct 4, 2014 at 11:32 PM, Thierry Goubier <thierry.goub...@gmail.com> wrote: > 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 >> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>> 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 :) You should take into account that with Pharo we are moving towards configurations. That is why Glamour and GT will remain as separate projects loaded via configurations. I actually do not mind more people making decisions. In fact, the Moose development doesn't happen through an inbox, but by directly committing. And we work with the latest development version, not the stable one. We started with the stable one in Pharo to smoothen the integration. It will take a bit of time to find a rhythm that works, but I definitely think this is the right direction. > 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 Oh. I remember :). I thought you encountered a more recent bug. > > >> 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...). Sounds interesting. I never looked at it. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
