Beacon for Pharo 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Beacon for Pharo 7

Denis Kudriashov
Hi.

I was looking at Beacon again to prepare integration. Some changes was needed in baseline for better granularity. So I send pull request because I have no permissions.

But now I remember that we had idea to integrate only core part of Beacon which requires MemoryLogger and TranscriptLogger. And we wanted to manage logger backends using separate baselines. So we need separate repos to have separate versioning.

What you think to create new org "pharo-logging" for this purpose? It looks like current approach to manage common projects (pharo-vcs, pharo-ide).

Another question is what we want: copy of BeaconCore into Pharo or load it separately like Iceberg and Calypso?
We can start with loading then we will decide.

Best regards,
Denis 
Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
Denis Kudriashov <[hidden email]>
wrote:

> Hi.
>
> I was looking at Beacon again to prepare integration. Some changes was
> needed in baseline for better granularity. So I send pull request because I
> have no permissions.
>
> But now I remember that we had idea to integrate only core part of Beacon
> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
> logger backends using separate baselines. So we need separate repos to have
> separate versioning.

Why would you want separate baselines for that? And on top of that separate
repos?

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Denis Kudriashov

2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>:
Denis Kudriashov <[hidden email]>
wrote:
> Hi.
>
> I was looking at Beacon again to prepare integration. Some changes was
> needed in baseline for better granularity. So I send pull request because I
> have no permissions.
>
> But now I remember that we had idea to integrate only core part of Beacon
> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
> logger backends using separate baselines. So we need separate repos to have
> separate versioning.

Why would you want separate baselines for that? And on top of that separate
repos?

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


Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
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?

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Tudor Girba-2
In reply to this post by Denis Kudriashov
Hi,

Yes, we want to have the concrete loggers managed with separate baselines. I would also put them in individual repositories.

Cheers,
Doru


> On May 25, 2018, at 5:58 PM, Denis Kudriashov <[hidden email]> wrote:
>
>
> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>:
> Denis Kudriashov <[hidden email]>
> wrote:
> > Hi.
> >
> > I was looking at Beacon again to prepare integration. Some changes was
> > needed in baseline for better granularity. So I send pull request because I
> > have no permissions.
> >
> > But now I remember that we had idea to integrate only core part of Beacon
> > which requires MemoryLogger and TranscriptLogger. And we wanted to manage
> > logger backends using separate baselines. So we need separate repos to have
> > separate versioning.
>
> Why would you want separate baselines for that? And on top of that separate
> repos?
>
> 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).
>
>
> Stephan

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

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."





Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

NorbertHartl
Really?? Don‘t you think the overhead is massive compared to the gain?

Norbert

> Am 25.05.2018 um 21:08 schrieb Tudor Girba <[hidden email]>:
>
> Hi,
>
> Yes, we want to have the concrete loggers managed with separate baselines. I would also put them in individual repositories.
>
> Cheers,
> Doru
>
>
>> On May 25, 2018, at 5:58 PM, Denis Kudriashov <[hidden email]> wrote:
>>
>>
>> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>:
>> Denis Kudriashov <[hidden email]>
>> wrote:
>>> Hi.
>>>
>>> I was looking at Beacon again to prepare integration. Some changes was
>>> needed in baseline for better granularity. So I send pull request because I
>>> have no permissions.
>>>
>>> But now I remember that we had idea to integrate only core part of Beacon
>>> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
>>> logger backends using separate baselines. So we need separate repos to have
>>> separate versioning.
>>
>> Why would you want separate baselines for that? And on top of that separate
>> repos?
>>
>> 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).
>>
>>
>> Stephan
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
Norbert Hartl <[hidden email]> wrote:
> Really?? Don‘t you think the overhead is massive compared to the gain?

As long as the baselines are nice trees, described only one level deep, it
should be ok-ish. That never seems to be the case though, and as soon as
you get diamond dependency issues the duplication of volatile information
creates a lot of commit ripple

I’d would like to see a description of how that is supposed to work with
all the duplicated baselines and repos.

Stephan





Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Denis Kudriashov
In reply to this post by Stephan Eggermont-3
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.
 

Stephan




Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Denis Kudriashov
In reply to this post by NorbertHartl
Hi Norbert 

2018-05-25 23:50 GMT+03:00 Norbert Hartl <[hidden email]>:
Really?? Don‘t you think the overhead is massive compared to the gain?

I am sure that you were agreed with this when we push Beacon two yeas ago. But look at my explanation in previous mail.
 

Norbert
> Am 25.05.2018 um 21:08 schrieb Tudor Girba <[hidden email]>:
>
> Hi,
>
> Yes, we want to have the concrete loggers managed with separate baselines. I would also put them in individual repositories.
>
> Cheers,
> Doru
>
>
>> On May 25, 2018, at 5:58 PM, Denis Kudriashov <[hidden email]> wrote:
>>
>>
>> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>:
>> Denis Kudriashov <[hidden email]>
>> wrote:
>>> Hi.
>>>
>>> I was looking at Beacon again to prepare integration. Some changes was
>>> needed in baseline for better granularity. So I send pull request because I
>>> have no permissions.
>>>
>>> But now I remember that we had idea to integrate only core part of Beacon
>>> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
>>> logger backends using separate baselines. So we need separate repos to have
>>> separate versioning.
>>
>> Why would you want separate baselines for that? And on top of that separate
>> repos?
>>
>> 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).
>>
>>
>> Stephan
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Tudor Girba-2
In reply to this post by NorbertHartl
Hi,

I do not have a strong opinion about repositories, but I do think that the concrete loggers will be inevitably created by different people with different interests, and this setup will naturally be more suitable for different repositories.

I do have a strong opinion about baselines: The baseline problem exists already at a significant scale and is not a local one. they are too costly to maintain now, and we need to build tools anyway to handle them cheaply. Without those tools we are confined to manual work, and optimizing design around manual work is not a good direction. So, trying to optimize one project is not particularly useful.

About Metacello groups: I think that in most cases using them for dependency purposes is less productive than a separate  baseline because they are not reified completely, and they are also not polymorphic with baselines which makes it hard to build tools to handle them.

Cheers,
Doru


> On May 25, 2018, at 10:50 PM, Norbert Hartl <[hidden email]> wrote:
>
> Really?? Don‘t you think the overhead is massive compared to the gain?
>
> Norbert
>> Am 25.05.2018 um 21:08 schrieb Tudor Girba <[hidden email]>:
>>
>> Hi,
>>
>> Yes, we want to have the concrete loggers managed with separate baselines. I would also put them in individual repositories.
>>
>> Cheers,
>> Doru
>>
>>
>>> On May 25, 2018, at 5:58 PM, Denis Kudriashov <[hidden email]> wrote:
>>>
>>>
>>> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>:
>>> Denis Kudriashov <[hidden email]>
>>> wrote:
>>>> Hi.
>>>>
>>>> I was looking at Beacon again to prepare integration. Some changes was
>>>> needed in baseline for better granularity. So I send pull request because I
>>>> have no permissions.
>>>>
>>>> But now I remember that we had idea to integrate only core part of Beacon
>>>> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
>>>> logger backends using separate baselines. So we need separate repos to have
>>>> separate versioning.
>>>
>>> Why would you want separate baselines for that? And on top of that separate
>>> repos?
>>>
>>> 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).
>>>
>>>
>>> Stephan
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "In a world where everything is moving ever faster,
>> one might have better chances to win by moving slower."
>>
>>
>>
>>
>>
>
>

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

"We are all great at making mistakes."









Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Tudor Girba-2
In reply to this post by Denis Kudriashov
+1

Doru


> On May 26, 2018, at 7:44 AM, 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.
>  
>
> Stephan
>
>
>
>

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

"Not knowing how to do something is not an argument for how it cannot be done."


Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
In reply to this post by Denis Kudriashov
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. 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




Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
In reply to this post by Tudor Girba-2
Tudor Girba <[hidden email]> wrote:
> I do have a strong opinion about baselines: The baseline problem exists
> already at a significant scale and is not a local one. they are too
> costly to maintain now, and we need to build tools anyway to handle them
> cheaply. Without those tools we are confined to manual work, and
> optimizing design around manual work is not a good direction. So, trying
> to optimize one project is not particularly useful.

We can only start from where we are. I’m sure that better tools will help,
and pushing for things to be structured in a way that gives us more work
now makes it take longer to get those tools.

Groups are at the moment essential to minimize manual work.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Denis Kudriashov
In reply to this post by Stephan Eggermont-3

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





Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Guillermo Polito
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
Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Stephan Eggermont-3
In reply to this post by Denis Kudriashov
Denis Kudriashov <[hidden email]>
wrote:
> If two entities needs separate versioning they should be in
separate
> repositories. Do you agree with this?

They don’t, and shouldn’t.
That is the way Pillar killed Pier. No separate maintaining of core
constantly breaking users.

Stephan





Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Denis Kudriashov

2018-05-26 10:20 GMT+03:00 Stephan Eggermont <[hidden email]>:
Denis Kudriashov <[hidden email]>
wrote:
> If two entities needs separate versioning they should be in
separate
> repositories. Do you agree with this?

They don’t, and shouldn’t.
That is the way Pillar killed Pier. No separate maintaining of core
constantly breaking users.

Ok. I understand your point. But I don't agree with you.
 

Stephan






Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

EstebanLM
In reply to this post by Stephan Eggermont-3


> On 26 May 2018, at 09:20, Stephan Eggermont <[hidden email]> wrote:
>
> Denis Kudriashov <[hidden email]>
> wrote:
>> If two entities needs separate versioning they should be in
> separate
>> repositories. Do you agree with this?
>
> They don’t, and shouldn’t.
> That is the way Pillar killed Pier. No separate maintaining of core
> constantly breaking users.

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…

Anyway, we can spell it differently: at least, with Pillar, a part of Pier remains in use, and not just in our hearts :)

Esteban

>
> Stephan
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Tudor Girba-2
+1

Doru

> On May 26, 2018, at 10:13 AM, Esteban Lorenzano <[hidden email]> wrote:
>
>
>
>> On 26 May 2018, at 09:20, Stephan Eggermont <[hidden email]> wrote:
>>
>> Denis Kudriashov <[hidden email]>
>> wrote:
>>> If two entities needs separate versioning they should be in
>> separate
>>> repositories. Do you agree with this?
>>
>> They don’t, and shouldn’t.
>> That is the way Pillar killed Pier. No separate maintaining of core
>> constantly breaking users.
>
> 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…
>
> Anyway, we can spell it differently: at least, with Pillar, a part of Pier remains in use, and not just in our hearts :)
>
> Esteban
>
>>
>> Stephan
>>
>>
>>
>>
>>
>
>

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

"We cannot reach the flow of things unless we let go."





Reply | Threaded
Open this post in threaded view
|

Re: Beacon for Pharo 7

Tudor Girba-2
In reply to this post by Guillermo Polito
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."





12