May 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Beacon for Pharo 7

by Norbert Hartl

> Am 26.05.2018 um 08:41 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2018-05-26 9:30 GMT+03:00 Stephan Eggermont <stephan(a)stack.nl>: >> Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > 2018-05-25 20:03 GMT+03:00 Stephan Eggermont >> <stephan(a)stack.nl>: >> > >> >> Denis Kudriashov <dionisiydk(a)gmail.com> >> >> 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 >> >> >> >> >

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Norbert Hartl

+1 Norbert > Am 26.05.2018 um 10:57 schrieb Tudor Girba <tudor(a)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 <guillermopolito(a)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." > > > > >

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> 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

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Tudor Girba

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 <guillermopolito(a)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."

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Tudor Girba

+1 Doru > On May 26, 2018, at 10:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 26 May 2018, at 09:20, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Denis Kudriashov <dionisiydk(a)gmail.com> >> 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."

May 26, 2018

[Pharo 7.0-dev] Build #956: 21988-OSWindowcreateWindow-test-is-failing

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #956 was: FAILURE. The Pull Request #1434 was integrated: "21988-OSWindowcreateWindow-test-is-failing" Pull request url: https://github.com/pharo-project/pharo/pull/1434 Issue Url: https://pharo.fogbugz.com/f/cases/21988 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Esteban Lorenzano

> On 26 May 2018, at 09:20, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Denis Kudriashov <dionisiydk(a)gmail.com> > 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 > > > > >

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Denis Kudriashov

2018-05-26 10:20 GMT+03:00 Stephan Eggermont <stephan(a)stack.nl>: > Denis Kudriashov <dionisiydk(a)gmail.com> > 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 > > > > > >

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> 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

May 26, 2018

[Pharo 7.0-dev] Build #955: 21960-Move-DangerousClassNotifier-to-ClassBuilder-package

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #955 was: FAILURE. The Pull Request #1426 was integrated: "21960-Move-DangerousClassNotifier-to-ClassBuilder-package" Pull request url: https://github.com/pharo-project/pharo/pull/1426 Issue Url: https://pharo.fogbugz.com/f/cases/21960 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 26, 2018