Smalltalk › Pharo › Pharo Smalltalk Developers

Beacon for Pharo 7

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

34 messages Options

Stephan Eggermont-3

Re: Beacon for Pharo 7

Esteban Lorenzano <[hidden email]>
wrote:
.
>
> Pillar did not kill Pier.
> Pier was killed by the fact that nobody is using it (then, there is few
> efforts to maintain it).
> which is sad, because Pier was/is very powerful…
>
No. Pillar killed Pier by breaking it unnecessarily. A lot of times. No
Pillar maintainer ever looked at our Pier builds and tried fixing things in
a compatible way, or committed a fix when they broke something. Pier is
stable and works just fine. It is infrastructure and nobody makes money
with it, so maintenance is never going to be high priority.

If you take up responsibility for changing core, you make sure the higher
level still works. If you don’t want that, fork

Stephan

NorbertHartl

Re: Beacon for Pharo 7

In reply to this post by Tudor Girba-2

+1

Norbert

> Am 26.05.2018 um 10:57 schrieb Tudor Girba <[hidden email]>:
>
> 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 <[hidden email]> 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."
>
>
>
>
>

NorbertHartl

Re: Beacon for Pharo 7

In reply to this post by Denis Kudriashov

Am 26.05.2018 um 08:41 schrieb Denis Kudriashov <[hidden email]>:

2018-05-26 9:30 GMT+03:00 Stephan Eggermont <[hidden email]>:
Denis Kudriashov <[hidden email]>
wrote:
> 2018-05-25 20:03 GMT+03:00 Stephan Eggermont
<[hidden email]>:
>
>> Denis Kudriashov <[hidden email]>
>> wrote:
>>>
>>> Because when you will fix or improve Beacon-SysLog you will probably do
>> not
>>> want to update Beacon-Core version which will force you to update Pharo
>>> (where SysLog is not loaded).
>>
>> I seem to be missing something here. Why would you update the baseline for
>> that?
>>
>
> Question is not about baselines.
> Separate repositories for Core and loggers are required to version them
> separately.
> It will allow users to load Core version 1.1, SysLog version 2.0 and
> FileLogger 3.0.
> And it will allow maintainers improve these projects separately. As I was
> described the fix in SysLog will not require updating BeaconCore which is
> included in Pharo.

You do not have a use case for separate repos, but one for duplicates of
the same repo.

If two entities needs separate versioning they should be in separate repositories. Do you agree with this?

Sure, but for me that does not count for FileLogger. Your approach might be the right way theoretically. But putting a single class with a separate baseline in a separate repository is just overkill. For something like FileLogger I don‘t want to have separate versions. It is so basic and fundamental that the only thing necessary is to be able not to load it and that is fine with groups.

Furthermore if I change FileLogger and BeaconCore at the same time how can I use the changed versions together? Changing FileLogger to point to BeaconCore master and when I‘m done release a new BeaconCore version to point at from FileLogger?

I hope you see that your approach enables certain things and makes others more complicated. So I agree that not every logging client should be in the beacon repo. But there is a line to draw for which it is useful to separate and for which it is not. And for FileLogger it is not useful. Even for syslog I doubt it. For my elasticsearch logger it is of course not the right place and that need to be separate.

Btw. this is kind if a discussion I wanted to have for a long time. We need a definition of what pharo really includes. To me there is the minimal core containing only the necessary things, then there is the pharo eco system that includes all the tools the community provides and maintains. And then there are user projects that is everything else.

FileLogger is surely part of the eco system. Syslog as well

Norbert

You need that anyhow because your images depend on different
branches and versions. You might want to solve that by having only one
image responsible for source code management, and all others connecting to
that instead of using libgit directly.

Stephan

Denis Kudriashov

Re: Beacon for Pharo 7

In reply to this post by Guillermo Polito

Very good questions.

2018-05-26 10:00 GMT+03:00 Guillermo Polito <[hidden email]>:

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?

We will need to replace transcript users with Beacon signals. In simplest cases it would be:

StringSignal emit: aString

But we should try use objects instead of strings.

And we need to decide what to do with #logCr.

- And which ones do not?

Logging inside bootstrapped kernel will stay independent from Beacon.

- **Who** is going to take care for those integrations/rewritings?
- How will this delay (even more) the release of Pharo 7?

We can just include this tool without cleanup. So no delay.

Idea to finally have standard logging system extendable by third party loggers (backends).

So when users will ask how to log the answer will be the Beacon and a link to the place with existing loggers.

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...

It is simple inspector on Beacon instance. We can add world menu entry to open it.

It is based on Announcer inspector. So any improvements will improve announcer in general.

- 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

NorbertHartl

Re: Beacon for Pharo 7

In reply to this post by Stephan Eggermont-3

> Am 26.05.2018 um 11:02 schrieb Stephan Eggermont <[hidden email]>:
>
> Esteban Lorenzano <[hidden email]>
> wrote:
> .
>>
>> Pillar did not kill Pier.
>> Pier was killed by the fact that nobody is using it (then, there is few
>> efforts to maintain it).
>> which is sad, because Pier was/is very powerful…
>>
> No. Pillar killed Pier by breaking it unnecessarily. A lot of times. No
> Pillar maintainer ever looked at our Pier builds and tried fixing things in
> a compatible way, or committed a fix when they broke something. Pier is
> stable and works just fine. It is infrastructure and nobody makes money
> with it, so maintenance is never going to be high priority.

How can pillar kill pier? Pillar is a wonderful effort to rescue a good document model that was burried in a CMS. And pillar is not a CMS. So either you need a CMS and you use pier or you need a document model and you use pilkar. The requirements are completely different so one cannot kill the other.

Norbert
>
> If you take up responsibility for changing core, you make sure the higher
> level still works. If you don’t want that, fork
>
>

Guillermo Polito

Re: Beacon for Pharo 7

In reply to this post by Tudor Girba-2

Hi,

On Sat, May 26, 2018 at 10:57 AM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Denis Kudriashov

Re: Beacon for Pharo 7

In reply to this post by NorbertHartl

2018-05-26 12:19 GMT+03:00 Norbert Hartl <[hidden email]>:

Am 26.05.2018 um 08:41 schrieb Denis Kudriashov <[hidden email]>:

2018-05-26 9:30 GMT+03:00 Stephan Eggermont <[hidden email]>:
Denis Kudriashov <[hidden email]>
wrote:
> 2018-05-25 20:03 GMT+03:00 Stephan Eggermont
<[hidden email]>:
>
>> Denis Kudriashov <[hidden email]>
>> wrote:
>>>
>>> Because when you will fix or improve Beacon-SysLog you will probably do
>> not
>>> want to update Beacon-Core version which will force you to update Pharo
>>> (where SysLog is not loaded).
>>
>> I seem to be missing something here. Why would you update the baseline for
>> that?
>>
>
> Question is not about baselines.
> Separate repositories for Core and loggers are required to version them
> separately.
> It will allow users to load Core version 1.1, SysLog version 2.0 and
> FileLogger 3.0.
> And it will allow maintainers improve these projects separately. As I was
> described the fix in SysLog will not require updating BeaconCore which is
> included in Pharo.

You do not have a use case for separate repos, but one for duplicates of
the same repo.

If two entities needs separate versioning they should be in separate repositories. Do you agree with this?

Sure, but for me that does not count for FileLogger. Your approach might be the right way theoretically. But putting a single class with a separate baseline in a separate repository is just overkill. For something like FileLogger I don‘t want to have separate versions. It is so basic and fundamental that the only thing necessary is to be able not to load it and that is fine with groups.
Furthermore if I change FileLogger and BeaconCore at the same time how can I use the changed versions together? Changing FileLogger to point to BeaconCore master and when I‘m done release a new BeaconCore version to point at from FileLogger?
I hope you see that your approach enables certain things and makes others more complicated. So I agree that not every logging client should be in the beacon repo. But there is a line to draw for which it is useful to separate and for which it is not. And for FileLogger it is not useful. Even for syslog I doubt it. For my elasticsearch logger it is of course not the right place and that need to be separate.
Btw. this is kind if a discussion I wanted to have for a long time. We need a definition of what pharo really includes. To me there is the minimal core containing only the necessary things, then there is the pharo eco system that includes all the tools the community provides and maintains. And then there are user projects that is everything else.
FileLogger is surely part of the eco system. Syslog as well

Ok. I agree

Norbert
You need that anyhow because your images depend on different
branches and versions. You might want to solve that by having only one
image responsible for source code management, and all others connecting to
that instead of using libgit directly.

Stephan

Denis Kudriashov

Re: Beacon for Pharo 7

In reply to this post by Guillermo Polito

2018-05-26 12:26 GMT+03:00 Guillermo Polito <[hidden email]>:

Also, didn't we agree that in Pharo7 we should try to remove something for each thing that is added?

But it is not the case. We do not have logging system in Pharo. So Beacon will not replace anything. It is new feature

Tudor Girba-2

Re: Beacon for Pharo 7

In reply to this post by Guillermo Polito

Hi,

Yes, Glamour is stable since years. Yes, we did have some leak issues that appeared along the way. Last year, we discovered that a memory leak came from Rubric (specifically there was a global variable in it). People saw inspectors laying around, so naturally, the issue was seen as being due to GT. And now there is another one, which is still under investigation. For me, the main issue is not the memory leak, but the fact that we have no tool to reason about them.

I am not being vague about what needs to change in the image, but I think there are people that are better equipped for answering that. For example, Denis provided a concrete answer that the Kernel should not use Beacon. But, to facilitate the conversation:

(SystemNavigation default allGlobalRefsOn: #Transcript)
reject: [ :each | each package name = #Kernel ]

gets us 124 methods, and

(((SystemNavigation default allGlobalRefsOn: #Transcript)
reject: [ :each | each package name = #Kernel ])
groupedBy: [:each | each package name ])

returns 58 packages.

When we talk about integrating Beacon, we talk at most about:
spec
package: #'Beacon-Core';
package: #'Beacon-Core-GT' with: [
spec requires: #('Beacon-Core' ). ];
package: #'Beacon-Core-Tests' with: [
spec requires: #('Beacon-Core' ). ];
package: #'Beacon-Syslog';
package: #'Beacon-File’;
package: #'Beacon-Zinc'.

where, Beacon-Syslog and Beacon-File must not necessarily be in the image.

I do agree with the idea of requiring something to be removed when we add something new. However, in this case, Beacon adds a new capability, and I do not see how this rule would apply.

Cheers,
Doru

> On May 26, 2018, at 11:26 AM, Guillermo Polito <[hidden email]> wrote:
>
> Hi,
>
> On Sat, May 26, 2018 at 10:57 AM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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
>
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

NorbertHartl

Re: Beacon for Pharo 7

In reply to this post by Guillermo Polito

To be honest you sound a bit harsh. And I‘m not sure I can remember that such kind of arguments have ever been exchanged before something was integrated.

You want to have a concrete definition. But you just said you don‘t want the core the rely neither on Beacon nor on Announcements. So maybe it would be good to define what is in the core so we can understand?

I hope we can agree that having a logging system is a good thing. And I hope Beacon is considered the best candidate for it. In order to make it so we designed the core to be minimal for easy integration. The only consumers included in the system are the memory logger and the transcript logger. So the dependencies are none because Transcript is here to stay for the time being. Transcript logger can also be the default fallback so the system appears like it is today.

One of the biggest decisions might be what method names are allowed to be highjacked by a logging framework. Will there be something like Object>>#log: (#emit:) ??? If beacon is considered to be close to the core this will be ok. If it is considered just a logger to be loaded it is not. Designing something that makes beacon replacable will most likely exceed the code base beacon is. It is kept small for that reason.

Regarding Announcements. Are Announcements to be removed from the system? If not it is fine Beacon is using them. Btw. the global usage of beacon is just one use case. And a needed one because you want to have it usable from a playground, too. So it is a good fallback. The problems of Announcements should be solved in Announcements not in Beacon. Or Announcements should be deprecated.

So please define what is the core of pharo and we can talk about how Beacon is best integrated.

Norbert
Am 26.05.2018 um 11:26 schrieb Guillermo Polito <[hidden email]>:

Hi,

On Sat, May 26, 2018 at 10:57 AM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Stephan Eggermont-3

Re: Beacon for Pharo 7

In reply to this post by NorbertHartl

Norbert Hartl <[hidden email]> wrote:
> How can pillar kill pier?

They can not both be loaded. Pillar should have just forked: copy and
rename the parts needed.

Stephan

Henrik Sperre Johansen

Re: Beacon for Pharo 7

In reply to this post by Guillermo Polito

Guillermo Polito wrote
> 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?)

What? The new event is delivered, of course.
If the complaint is "When I write an infinite loop using announcements, it
is an infinite loop", I don't know what to tell you...

Guillermo Polito wrote
> , they block the caller until all announcements are processed (not so
> decoupled, huh :P),

Avoiding subscribers who take too long to process the subscription, *should*
be the responsibility of each subscriber. If you think announcement overhead
is bad now, imagine what happens if you fork of a process for every
delivery. Depending on priority, you'd still have a problem in that it
either in effect will still block the sender, or not be processed at all
until sender completes. Also, good luck debugging. Show me *one* other event
registration framework in a green-threaded system that hasn't made the same
tradeoff, and I'll buy you a beer.

Guillermo Polito wrote
> 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: ...).

The fact you can easily search for users of a given announcement in a
standard browser is one of its big advantages compared to the seaside
announcements, if you ask me.
However, the only hard requirement should be to implement
handlesAnnouncement: on whatever is passed to when: (though, there seems to
have been a late addition of #prepareForDelivery, which should be handled by
announcement initialization, not the delivery mechanism, at least for the
use indicated by its comment...).
Which still doesn't make it a good idea to implement on arbitrary objects
(though it's implemented on Symbol for backwards compatibility with the old
event registration mechanism).

Guillermo Polito wrote
> Not even mentioning the weak/ephemeron mess :).

This I can get behind though, the world would be a better place if everyone
unregistered their subscriptions properly. ;) (and/or we had a working
ephemeron implementation without the same self-referential pitfalls as the
weak one)

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

John Brant-2

memory leak

In reply to this post by Tudor Girba-2

On 05/26/2018 05:21 AM, Tudor Girba wrote:
> Yes, Glamour is stable since years. Yes, we did have some leak issues that appeared along the way. Last year, we discovered that a memory leak came from Rubric (specifically there was a global variable in it). People saw inspectors laying around, so naturally, the issue was seen as being due to GT. And now there is another one, which is still under investigation. For me, the main issue is not the memory leak, but the fact that we have no tool to reason about them.

I found a memory leak in GLMHintableActionButtonBrick. It has an
asyncTask class instance variable that holds a GLMAsyncTask. After
running for a while -- opening and closing inspectors and other tools, I
closed several windows, did a GC and expected to not have any AST nodes
hanging around. However, I found several, so I used my ReferenceFinder
tool to find a reference path. That path went through the
GLMHintableActionButtonBrick to a GLMAsyncTask to a block that holds a
reference to a GLMHintableActionButtonBrick instance. Following
references out of the GLMHintableActionButtonBrick instance eventually
leads to a NodeMorph which has a NodeModel that contained my AST node.

I'm running a Pharo 7 build from a few weeks ago
(Pharo-7.0+alpha.build.843.sha.edceb623c1a3ac3358f7e46ca1048d455657e10c)
so this may have been fixed.

John Brant

Marcus Denker-4

Re: memory leak

> On 2 Jun 2018, at 17:53, John Brant <[hidden email]> wrote:
>
> On 05/26/2018 05:21 AM, Tudor Girba wrote:
>> Yes, Glamour is stable since years. Yes, we did have some leak issues that appeared along the way. Last year, we discovered that a memory leak came from Rubric (specifically there was a global variable in it). People saw inspectors laying around, so naturally, the issue was seen as being due to GT. And now there is another one, which is still under investigation. For me, the main issue is not the memory leak, but the fact that we have no tool to reason about them.
>
> I found a memory leak in GLMHintableActionButtonBrick. It has an
> asyncTask class instance variable that holds a GLMAsyncTask. After
> running for a while -- opening and closing inspectors and other tools, I
> closed several windows, did a GC and expected to not have any AST nodes
> hanging around. However, I found several, so I used my ReferenceFinder
> tool to find a reference path. That path went through the
> GLMHintableActionButtonBrick to a GLMAsyncTask to a block that holds a
> reference to a GLMHintableActionButtonBrick instance. Following
> references out of the GLMHintableActionButtonBrick instance eventually
> leads to a NodeMorph which has a NodeModel that contained my AST node.
>

Thanks, I have added it to the issue tracker to not lose it:

https://pharo.fogbugz.com/f/cases/22163/Memory-Leak-GLMHintableActionButtonBrick