September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

by Esteban Lorenzano

> On 10 Sep 2017, at 11:34, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > >> 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] > > Which I believe is the threaded heartbeat. > > Is that the information you're after? no :) please re-try using latest VM threaded: get -O- get.pharo.org/64/vmLatest70 <http://get.pharo.org/64/vmLatest70> | bash (and letâs hope this is fixedâ¦ and yes, I need to promote new stables) cheers! Esteban > > > Cheers, > Alistair > > > On 10 September 2017 at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> which VM are you using? >> >> Esteban >> >>> On 10 Sep 2017, at 11:23, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Everyone, >>> >>> I thought I'd have another go at moving to 64 bits after Esteban >>> commented that he's regularly using it now. >>> >>> However the following sequence reliably crashses the 64 bit VM (Ubuntu >>> 16.04): >>> >>> 1. Execute: >>> >>> Iceberg enableMetacelloIntegration: true. >>> Metacello new >>> repository: 'github://akgrant43/FileAttributes/src'; >>> baseline: 'FileAttributes'; >>> load. >>> >>> 2. Open Iceberg >>> 3. Select the FileAttributes repository >>> 4. Show History... >>> 5. Select master >>> 6. Click on the top commit >>> >>> $ ../vm64/pharo-ui Pharo7.0-64bit-f65af60.image >>> pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. >>> ../vm64/pharo-ui: line 11: 13199 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" >>> >>> >>> I also get crashes from other operations, e.g. iceRepository pull. >>> The result is that for me 64 bits isn't usable yet. >>> >>> If this isn't already known I'll open a fogbugz issue. >>> >>> Build info: >>> >>> Pharo 7.0 >>> Build information: alpha.build.109.sha.f65af6011ac4ff31af37c8d8567bf8a5fdad8dca >>> >>> but has happened with other builds as well. >>> >>> >>> $ ../vm64/pharo --version >>> 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] >>> CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >>> VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ >>> Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> Linux testing-gce-7a972a8a-3d5e-4b8d-94e0-6252bfe9a477 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >>> plugin path: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/] >>> >>> >>> >>> Thanks very much, >>> Alistair >>> >> >> >

Sept. 10, 2017

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

by Alistair Grant

Hi Esteban, > 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] Which I believe is the threaded heartbeat. Is that the information you're after? Cheers, Alistair On 10 September 2017 at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > which VM are you using? > > Esteban > >> On 10 Sep 2017, at 11:23, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Everyone, >> >> I thought I'd have another go at moving to 64 bits after Esteban >> commented that he's regularly using it now. >> >> However the following sequence reliably crashses the 64 bit VM (Ubuntu >> 16.04): >> >> 1. Execute: >> >> Iceberg enableMetacelloIntegration: true. >> Metacello new >> repository: 'github://akgrant43/FileAttributes/src'; >> baseline: 'FileAttributes'; >> load. >> >> 2. Open Iceberg >> 3. Select the FileAttributes repository >> 4. Show History... >> 5. Select master >> 6. Click on the top commit >> >> $ ../vm64/pharo-ui Pharo7.0-64bit-f65af60.image >> pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. >> ../vm64/pharo-ui: line 11: 13199 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" >> >> >> I also get crashes from other operations, e.g. iceRepository pull. >> The result is that for me 64 bits isn't usable yet. >> >> If this isn't already known I'll open a fogbugz issue. >> >> Build info: >> >> Pharo 7.0 >> Build information: alpha.build.109.sha.f65af6011ac4ff31af37c8d8567bf8a5fdad8dca >> >> but has happened with other builds as well. >> >> >> $ ../vm64/pharo --version >> 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] >> CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >> VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ >> Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Linux testing-gce-7a972a8a-3d5e-4b8d-94e0-6252bfe9a477 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >> plugin path: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/] >> >> >> >> Thanks very much, >> Alistair >> > >

Sept. 10, 2017

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

by Esteban Lorenzano

which VM are you using? Esteban > On 10 Sep 2017, at 11:23, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Everyone, > > I thought I'd have another go at moving to 64 bits after Esteban > commented that he's regularly using it now. > > However the following sequence reliably crashses the 64 bit VM (Ubuntu > 16.04): > > 1. Execute: > > Iceberg enableMetacelloIntegration: true. > Metacello new > repository: 'github://akgrant43/FileAttributes/src'; > baseline: 'FileAttributes'; > load. > > 2. Open Iceberg > 3. Select the FileAttributes repository > 4. Show History... > 5. Select master > 6. Click on the top commit > > $ ../vm64/pharo-ui Pharo7.0-64bit-f65af60.image > pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. > ../vm64/pharo-ui: line 11: 13199 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" > > > I also get crashes from other operations, e.g. iceRepository pull. > The result is that for me 64 bits isn't usable yet. > > If this isn't already known I'll open a fogbugz issue. > > Build info: > > Pharo 7.0 > Build information: alpha.build.109.sha.f65af6011ac4ff31af37c8d8567bf8a5fdad8dca > > but has happened with other builds as well. > > > $ ../vm64/pharo --version > 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ > Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-7a972a8a-3d5e-4b8d-94e0-6252bfe9a477 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > plugin path: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/] > > > > Thanks very much, > Alistair >

Sept. 10, 2017

Iceberg causes 64 bit VM core dump on Ubuntu

by Alistair Grant

Hi Everyone, I thought I'd have another go at moving to 64 bits after Esteban commented that he's regularly using it now. However the following sequence reliably crashses the 64 bit VM (Ubuntu 16.04): 1. Execute: Iceberg enableMetacelloIntegration: true. Metacello new repository: 'github://akgrant43/FileAttributes/src'; baseline: 'FileAttributes'; load. 2. Open Iceberg 3. Select the FileAttributes repository 4. Show History... 5. Select master 6. Click on the top commit $ ../vm64/pharo-ui Pharo7.0-64bit-f65af60.image pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. ../vm64/pharo-ui: line 11: 13199 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" I also get crashes from other operations, e.g. iceRepository pull. The result is that for me 64 bits isn't usable yet. If this isn't already known I'll open a fogbugz issue. Build info: Pharo 7.0 Build information: alpha.build.109.sha.f65af6011ac4ff31af37c8d8567bf8a5fdad8dca but has happened with other builds as well. $ ../vm64/pharo --version 5.0-201708271955 Sun Aug 27 20:00:58 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-7a972a8a-3d5e-4b8d-94e0-6252bfe9a477 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955 [default: /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/] Thanks very much, Alistair

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Esteban Lorenzano

> On 10 Sep 2017, at 10:56, Henrik-Nergaard <draagren(a)outlook.com> wrote: > >>> Everyone who used filetree with metadata can tell it is super annoying and > destroys the complete experience. > There has been a fix for this on the issue tracker for some time: > https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order <https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order> thatâs not related. Timestamp conflicts are related two different users touching exactly same part of source: conflict guaranteed, no matter the order. btw, Tonel export order is deterministic and it will always output same data in same way. Esteban > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Henrik-Nergaard

>>Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Esteban Lorenzano

> On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Point class >> x: anInt1 y: anInt2 > [ > ^ self new setX: anInt1 Y: anInt2] > > because trailing white space will only accumulate, something I see in Pharo and Squeak code. > > Alternatively have the output add white space if required and the input remove any and all trailing white space. in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was methodDeclaration [ methodBody ] but now Iâm digging also into methodDeclaration [ methodBody ] (always keeping the identity of sources idea) cheers! Esteban

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Esteban Lorenzano

Hi! > On 9 Sep 2017, at 19:43, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > > On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> >>> On 9 Sep 2017, at 12:28, Henrik Nergaard <draagren(a)outlook.com <mailto:draagren@outlook.com>> wrote: >>> >>> >> but this is still WIP: for example timestamp needs to go to avoid conflicts. >>> why/how would this cause conflicts versus other changes? >> >> two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :) > > I think this is a serious mistake. Time stamps and author marks are important (even more important if the unit of commit is a single file for the whole class). I'm always irritated when Monticello commits carelessly edit a method back instead of reverting, hence lost my the original time stamp. I want to know who edited a method when so I can ask them for help. I don't want to see spurious changes. So making if a conflict and preserving time stamps remains important to me. thing is: we need to obtain that information in a different way than just put it there as text, because of conflicts. But I do not want to lose that information eitherâ¦ just get it in a different way. Esteban > >> >> Esteban >> >>> >>> >>> Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>> pÃ¥ vegne av Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> >>> Sendt: 9. september 2017 11:39:12 >>> Til: Pharo Development List >>> Emne: Re: [Pharo-dev] About Git support for windows >>> >>> >>> > On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> > >>> > Hi All, >>> > >>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >>> >> >>> >> Hi all >>> >> >>> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>> >> others :), esteban designed a nice class file format. So that we will >>> >> not have 2Gb of space on harddisc, problems with long method names and >>> >> sluggish commits. >>> > >>> > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>> > >>> > Can someone post the grammar or a description of the syntax asap? >>> >>> I will commit it with a spec next week. >>> and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. >>> >>> Esteban >>> >>> > >>> >> >>> >> He is waiting at Wien and is probably checking everything right now. >>> >> >>> >> It is a nice format because we will be able to use it to communicate >>> >> by emails using it. So readable, compact and I like it :) >>> > >>> > Lovely! Details please :-) >>> > >>> >> >>> >> Stef >>> >> >>> > >>

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Esteban Lorenzano

> On 10 Sep 2017, at 09:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > Hi! > >> Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: >> >> Hi! >> >> I live very very much this idea! >> >> I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? >> > the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. thatâs the real problem. Thatâs why we need to find ways to have the correct timestamp using git tooling (like using git blame or something like that) > > Norbert >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Hi All, >>>> >>>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Hi all >>>>> >>>>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>>>> others :), esteban designed a nice class file format. So that we will >>>>> not have 2Gb of space on harddisc, problems with long method names and >>>>> sluggish commits. >>>> >>>> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>>> >>>> Can someone post the grammar or a description of the syntax asap? >>> >>> I will commit it with a spec next week. >>> and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. >>> >>> Esteban >>> >>>> >>>>> >>>>> He is waiting at Wien and is probably checking everything right now. >>>>> >>>>> It is a nice format because we will be able to use it to communicate >>>>> by emails using it. So readable, compact and I like it :) >>>> >>>> Lovely! Details please :-) >>>> >>>>> >>>>> Stef >>>>> >>>> >>> >>> >

Sept. 10, 2017

argh, tests are failing!

by Guillermo Polito

Hi all, Since a couple of builds we have consistently failing the following tests: - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> - ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> Green builds are the only hard metric to say if the build is healthy or not. - We should not integrate anything until the build is green again... Also, we spent with Pablo a lot of time to have a green build in all platforms... I'd like to spend my time in other fun stuff than the CI :/ -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 10, 2017