Beacon for Pharo 7
Locked
12
12
 
|
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 |
|
|
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 |
|
|
2018-05-25 17:21 GMT+03:00 Stephan Eggermont <[hidden email]>: Denis Kudriashov <[hidden email]> 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).
|
|
|
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 |
|
|
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." |
|
|
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." > > > > > |
|
|
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 |
|
|
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]> 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.
|
|
|
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.
|
|
|
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." |
|
|
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." |
|
|
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 |
|
|
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 |
|
|
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]> 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 |
|
|
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 |
|
|
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 |
|
|
2018-05-26 10:20 GMT+03:00 Stephan Eggermont <[hidden email]>: Denis Kudriashov <[hidden email]> Ok. I understand your point. But I don't agree with you.
|
|
|
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 > > > > > |
|
|
+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." |
|
|
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." |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |