On Sat, May 26, 2018 at 10:57 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
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.
Really? Since years we are chasing bugs and memory leaks created by glamour and spotter... And what I see is a lot of effort on debuggging those from the people in RMod to fix those. Is that what you call stable? What I'd like is that the effort of maintaining Glamour or even the Glamorous Toolkit is shared, because you have the knowledge to debug it while me, I have to develop that knowledge...
Right now in a vanilla Pharo 6 I've been using for some hours I do
GTInspector allInstances.
And I have three instances, while only one inspector is open.
��
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.
No, the problem will be there even without Announcements. Beacon relies on a global registration mechanism, otherwise it doesn't make sense.
If I register a logger in Beacon, that logger will be hanging around for ever. So we need tools to handle those.
Announcements have other problems on their own, as we were talking with Pablo the other day. They are not reentrant (what happens if an announcement is raised during the treatment of an announcement? Does it loop?), they block the caller until all announcements are processed (not so decoupled, huh :P), right now without looking at the code it's not clear to me if they can handle the subscription of arbitrary instances instead of just Announcement (sub)classes (announcer on: arbitraryObject send: ...). Not even mentioning the weak/ephemeron mess :).
��
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.
I want to be concrete, please. I do not want the Kernel to rely on Beacon nor announcements to work.
To me the idea of "all transcript usages should be rewritten" is way too abstract.
What is the list of packages that should be rewritten in Pharo? I want to be concrete.
Maybe some Transcript usages need to be removed, maybe some should be replaced.
The solution "We introduce it and eventually we replace users" will decay into "We introduce it and never replace the users" unless there is an active effort to do it, we have all seen it.
So, who is willing to do that effort?
Because, integrating Beacon into Pharo has also its drawbacks for users: People will not be able to freely install/upgrade the version of Beacon they want without putting the system in risk. On the other side, keeping it as an external library, people can have as a simple dependency whatever they need for their application.
Also, didn't we agree that in Pharo7 we should try to remove something for each thing that is added?
��
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.
So when people say "We shoud integrate Beacon", what exactly are we talking about?
��- What are the packages/features included? What loggers? What kind of events/logs?
��- What are the good/bad practices of using Beacon?
��
Cheers,
Doru
> On May 26, 2018, at 9:00 AM, Guillermo Polito <guillermopolito@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."
|
������ | Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Phone: +33 06 52 70 66 13 |
