- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Crash on GC garbageCollect

by Eliot Miranda

Hi Andreas, On Fri, May 25, 2018 at 1:24 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Hi all > > I have a 6.0 image which crashes on garbage collect. If I run "Smalltalk > garbageCollect" it crashes. The crash log is attached. But I don't really > understand that crash log. I run it with a 6.0 VM, tried it also with > newest 6.1 VM and 7.0 VM, but always the same error. > > I read here in the list about crash problems with GC, memory leaks and > similar, but I really don't see what I could do. > Note that if you build an Assert VM you will be able to manually patch the image in lldb so that you can rescue it. It looks like this: $ *lldb PharoAssert.app/Contents/MacOS/Pharo* (lldb) target create "/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/ PharoAssert.app/Contents/MacOS/Pharo" Current executable set to '/Users/eliot/oscogvm/build. macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64). (lldb) settings set -- target.run-args "clap_broken.d9e5daa.image" (lldb) *b warning* Breakpoint 1: 3 locations. (lldb) *run --leakcheck 31 clap_broken.d9e5daa.image* Process 31569 launched: '/Users/eliot/oscogvm/build. macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) object leak in *0x10f919658* @ 0 = 0x122216538 object leak in *0x10fbb3448* @ 0 = 0x122216760 object leak in *0x10fbb3480* @ 0 = 0x1222166a8 object leak in *0x10ff384f0* @ 0 = 0x122d480b0 object leak in *0x10ff38518* @ 0 = 0x122d480b0 object leak in *0x10ff385d0* @ 0 = 0x122d480b0 Process 31569 stopped * thread #1: tid = 0x5b6d56, 0x0000000100001a83 Pharo`warning(s=" checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001a83 Pharo`warning(s=" checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44 41 sqInt warnpid, erroronwarn; 42 void 43 warning(char *s) { /* Print an error message but don't necessarily exit. */ -> 44 if (erroronwarn) error(s); 45 if (warnpid) 46 printf("\n%s pid %ld\n", s, (long)warnpid); 47 else (lldb) *call freeObject(0,0x10f919658)* (sqInt) $0 = 4478138592 (lldb) *call **freeObject**(0,0x10fbb3448)* (sqInt) $1 = 4478138592 (lldb) *call **freeObject**(0,0x10fbb3480)* (sqInt) $2 = 4478138592 (lldb) *call **freeObject**(0,0x10ff384f0)* (sqInt) $3 = 4478138592 (lldb) *call **freeObject**(0,0x10ff38518)* (sqInt) $4 = 4478138592 (lldb) *call **freeObject**(0,0x10ff385d0)* (sqInt) $5 = 4478138592 (lldb) *expr checkForLeaks = 0* (sqInt) $0 = 0 (lldb) *continue* and then save the image. > > Any pointers in which direction I could investigate? > > Thanks and cheers, > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > -- _,,,^..^,,,_ best, Eliot

May 25, 2018

[Pharo 7.0-dev] Build #954: 21916-OSWindow-SDL2-leaks-because-there-are-strong-references-on-OSSDL2WindowHandle

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

There is a new Pharo build available! The status of the build #954 was: FAILURE. The Pull Request #1369 was integrated: "21916-OSWindow-SDL2-leaks-because-there-are-strong-references-on-OSSDL2WindowHandle" Pull request url: https://github.com/pharo-project/pharo/pull/1369 Issue Url: https://pharo.fogbugz.com/f/cases/21916 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 25, 2018

Re: [Pharo-dev] Crash on GC garbageCollect

by Esteban Lorenzano

> 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. So, I will promote this one, and then we can start the next cycle :) Esteban > > Stephan > > > >

May 25, 2018