+1 Norbert
> Am 26.05.2018 um 10:57 schrieb Tudor Girba <tu...@tudorgirba.com>: > > Hi, > > I do not know what you mean by Glamour. Glamour is stable since years. If you > refer to the Glamorous Toolkit, then perhaps the problem comes from the fact > that the existing tools and the new generation share the same name. However, > what is integrated now has nothing to do with what is being developed > separately. As for Beacon, I am using it since two years, and it is as stable > as software can get. > > The problems you describe have nothing to do with Beacon, but with > Announcements. If Announcements are not safe to use, we should work on that. > Beacon is an application that uses that mechanism. > > What should be rewritten are all the references to Transcript, and likely the > creation of dedicated Signals. This can be done gradually, and should not > delay anything else. > > And just to make it clear: while the stack logging is a useful too, its main > purpose is to be an example to show how a dedicated Signal can enable > advanced debugging and monitoring options. > > Cheers, > Doru > > >> On May 26, 2018, at 9:00 AM, Guillermo Polito <guillermopol...@gmail.com> >> wrote: >> >> Hi all, >> >> Just to state my position about the integration of Beacon. My main concern >> now is that I do not want to it become Glamour. >> I do not want to integrate a new tool that will be half integrated and not >> maintained because "the future is elsewhere". >> >> If people would like to introduce Beacon, I'd like to have at least the >> following questions answered: >> - What tools/core libraries of Pharo should be rewritten using Beacon? >> - And which ones do not? >> - **Who** is going to take care for those integrations/rewritings? >> - How will this delay (even more) the release of Pharo 7? >> >> Then, more on the technical side. Beacon uses *global* announcers as its >> log/event delivery technique. It gives people an easy way to log a full >> stack (with all objects it references). While all this is nice, it may >> generate memory leaks, people may need to have a "Logger manager" to see >> connected loggers and detect problems... >> - What are the tools/techniques that we have to develop to manage connected >> loggers/appenders efficiently? >> - What are the tools/techniques that we have to develop to detect and avoid >> memory leaks more efficiently? >> - **Who** is going to implement them? >> >> If I put this side by side with the versionning questions above, this ones >> have more weight to me... >> >> Cheers, >> Guille > > -- > www.tudorgirba.com > www.feenk.com > > "Some battles are better lost than fought." > > > > >
