- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Crash on GC garbageCollect

by Esteban Lorenzano

> On 26 May 2018, at 02:27, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> > wrote: >> >> >>> On 25 May 2018, at 23:48, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>>> thatâs because 6.1 images still comes with an old VM. >>>> I think I will backport the newer, but next week (testing time has passed, I think). >>> >>> You probably want to include the TLS fix from this week for Win7 so github >>> repos eork >> >> no I do not want :) >> because in that case I will need to repeat the full cycle: 2 weeks as >> latest, one month as stable in 7.0, than backport. >> and probably in that moment there will be another fix to include. > > I understand that you donât want, but releasing a stable vm for Pharo 6 > where Iceberg (that is, github) doesnât work on Win7 is also not really a > solution. I didnât say I will not do it :) I just say first one, then the other :P Esteban > > Stephan

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by 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

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Denis Kudriashov

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