November 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] BlueInk removal

by ducasse

Cyril We are crawling with too many things. Pharo should start to lose fat FOR REAL. I really hope that we will get rid of lot of old code in the future. If Enlumineur does not work when we integrate it - I just issue a PR then you will have a good case for reintegrating and having two formatter, two contexts classes, two packages full of nearly the same but not quite tests. S. > On 26 Nov 2019, at 14:16, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Nov 26, 2019 at 2:07 PM ducasse <stepharo(a)netcourrier.com> wrote: >> >> Cyril can you wait until this evening? >> We should remove old things and having the two side by side is a lot more painful >> to work. >> We are still in Pharo 80 alpha. >> >> Stef >> > > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything > will be stricked and people will know they should not use it and it > will help us migrate our settings without breaking everything. > > And deprecating it is just one method in the manifest. > >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 26, 2019

Re: [Pharo-dev] BlueInk removal

by ducasse

> On 26 Nov 2019, at 14:16, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Nov 26, 2019 at 2:07 PM ducasse <stepharo(a)netcourrier.com> wrote: >> >> Cyril can you wait until this evening? >> We should remove old things and having the two side by side is a lot more painful >> to work. >> We are still in Pharo 80 alpha. >> >> Stef >> > > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything > will be stricked and people will know they should not use it and it > will help us migrate our settings without breaking everything. ;((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( > > And deprecating it is just one method in the manifest. > >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 26, 2019

Re: [Pharo-dev] BlueInk removal

by Cyril Ferlicot

On Tue, Nov 26, 2019 at 2:07 PM ducasse <stepharo(a)netcourrier.com> wrote: > > Cyril can you wait until this evening? > We should remove old things and having the two side by side is a lot more painful > to work. > We are still in Pharo 80 alpha. > > Stef > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything will be stricked and people will know they should not use it and it will help us migrate our settings without breaking everything. And deprecating it is just one method in the manifest. > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 26, 2019

Re: [Pharo-dev] BlueInk removal

by ducasse

Cyril can you wait until this evening? We should remove old things and having the two side by side is a lot more painful to work. We are still in Pharo 80 alpha. Stef > On 26 Nov 2019, at 11:55, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > Can we revert the removal of blueink the time the new formatter is in > the image please? (And maybe deprecate it instead of removing it). > > I ask this because: > - If we work with Pharo 8 we need to format the code by hand because > the format option is currently messing the code > - The current formatter is removing all method comment > - Currently removing it without deprecation is breaking the setting > system (And since I push the setting system further than most people, > I cannot even open an image with settings now...) > > I remind that the formatter is called by the refactorings. Imagine my > surprise when I wanted to commit refactorings and I saw all the > formatting messed up and all my method comments missing. I really do > not appreciate to lose comments I spent time to write like this... > > -- > Cyril Ferlicot > https://ferlicot.fr >

Nov. 26, 2019

BlueInk removal

by Cyril Ferlicot

Hi, Can we revert the removal of blueink the time the new formatter is in the image please? (And maybe deprecate it instead of removing it). I ask this because: - If we work with Pharo 8 we need to format the code by hand because the format option is currently messing the code - The current formatter is removing all method comment - Currently removing it without deprecation is breaking the setting system (And since I push the setting system further than most people, I cannot even open an image with settings now...) I remind that the formatter is called by the refactorings. Imagine my surprise when I wanted to commit refactorings and I saw all the formatting messed up and all my method comments missing. I really do not appreciate to lose comments I spent time to write like this... -- Cyril Ferlicot https://ferlicot.fr

Nov. 26, 2019

Re: [Pharo-dev] VM crash investigations

by ducasse

> On 26 Nov 2019, at 10:06, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > On Mon, 25 Nov 2019 at 21:36, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Did you read that paper https://hal.inria.fr/hal-01152610 ? >> Because may be it can give you ideas of possible problems. > > That, and Eliot's blog posts, and class comments of SpurMemoryManager, > SpurPlanningCompactor, etc. (not that I understood it all) :-) Same here :) > > >> Pablo is on vacation until next monday. Guille working wednesday, thursday and friday afternoons > > OK, thanks. > > Cheers, > Alistair >

Nov. 26, 2019

Re: [Pharo-dev] VM crash investigations

by Alistair Grant

Hi Stef, On Mon, 25 Nov 2019 at 21:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Did you read that paper https://hal.inria.fr/hal-01152610 ? > Because may be it can give you ideas of possible problems. That, and Eliot's blog posts, and class comments of SpurMemoryManager, SpurPlanningCompactor, etc. (not that I understood it all) :-) > Pablo is on vacation until next monday. Guille working wednesday, thursday and friday afternoons OK, thanks. Cheers, Alistair

Nov. 26, 2019

[Pharo 8.0] Build #1010: 5212-Executable-comment-checker-problem

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

There is a new Pharo build available! The status of the build #1010 was: FAILURE. The Pull Request #5224 was integrated: "5212-Executable-comment-checker-problem" Pull request url: https://github.com/pharo-project/pharo/pull/5224 Issue Url: https://github.com/pharo-project/pharo/issues/5212 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 26, 2019

[Pharo 8.0] Build #1009: 5217-Remove-blueInk-to-introduce-Enlumineur

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

There is a new Pharo build available! The status of the build #1009 was: FAILURE. The Pull Request #5218 was integrated: "5217-Remove-blueInk-to-introduce-Enlumineur" Pull request url: https://github.com/pharo-project/pharo/pull/5218 Issue Url: https://github.com/pharo-project/pharo/issues/5217 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 25, 2019

Re: [Pharo-dev] VM crash investigations

by StÃ©phane Ducasse

Hi Alistair Did you read that paper https://hal.inria.fr/hal-01152610 <https://hal.inria.fr/hal-01152610> ? Because may be it can give you ideas of possible problems. Pablo is on vacation until next monday. Guille working wednesday, thursday and friday afternoons S > On 25 Nov 2019, at 10:18, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > At the moment I'm spending pretty much all of my working time tracking > down VM crashes. It sounds like there may be others working on the same > issue (Guille?, Pablo?), if so it would be good to be able to exchange > notes and hopefully reach a resolution a little earlier. > > So my status... > > I'm currently focusing on two corruptions that I've seen: > > 1. Frame Pointers aren't being updated when the receiver or rcvr/clsr > they point to is moved during scavenging / compaction. > 2. The current frame pointer (framePointer) contains an address that is > in a free stack page. > > > I'm doing all the investigation using a Pharo minimal image, so there's > no FreeType, and from what I've seen FFI isn't being used. > > The script I'm using to reproduce the crash is at: > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/444#issuecomment-5… > (the good part about this is that even the memory addresses are > consistent across runs, so it is highly reproducible). > > > For the Frame Pointers not being updated, what I'm seeing is that after > a scavenge has finished copying all the referenced objects, but before > the survivor spaces are exchanged, the call stack looks like: > > (gdb) call printCallStack() > 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: > a(n) SessionManager > 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: > a(n) SessionManager > 0x7ffffffe4020 I [] in INVALID RECEIVER>newProcess 0x118a728 > 0x118a728 is a forwarded object to 0x488fca0 of slot size 7 > hdr8 ..... > > Once the survivor spaces have been exchanged: > > (gdb) call printCallStack() > 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: > a(n) SessionManager > 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: > a(n) SessionManager > 0x7ffffffe4020 I [] in INVALID RECEIVER>newProcess 0x118a728 is in new space > > > For the framePointer containing an address in a free stack page: adding > a check during the scavenge shows that the framePointer is in a free > page. > > I'm assuming it is never valid for the framePointer to be in a free > stack page, and that the receiver and rcvr/clsr should never be in new > space. If my assumptions are wrong please let me know. > > If you'd like any more information, please let me know. > > Thanks, > Alistair > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Nov. 25, 2019