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

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

Re: [Pharo-dev] Beacon for Pharo 7

by Stephan Eggermont

Tudor Girba <tudor(a)tudorgirba.com> 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

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Stephan Eggermont

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

+1 Doru > On May 26, 2018, at 7:44 AM, 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. > > > Stephan > > > > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Tudor Girba

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 <norbert(a)hartl.name> 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 <tudor(a)tudorgirba.com>: >> >> 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 <dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <stephan(a)stack.nl>: >>> Denis Kudriashov <dionisiydk(a)gmail.com> >>> 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."

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Denis Kudriashov

Hi Norbert 2018-05-25 23:50 GMT+03:00 Norbert Hartl <norbert(a)hartl.name>: > 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 <tudor(a)tudorgirba.com>: > > > > 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 <dionisiydk(a)gmail.com> > wrote: > >> > >> > >> 2018-05-25 17:21 GMT+03:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Denis Kudriashov <dionisiydk(a)gmail.com> > >> 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." > > > > > > > > > > > > >

May 26, 2018

Re: [Pharo-dev] Beacon for Pharo 7

by Denis Kudriashov

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

May 26, 2018

Re: [Pharo-dev] Crash on GC garbageCollect

by Stephan Eggermont

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

May 26, 2018