- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Aliaksei Syrel

Hi, Bintray has 6 months upload limit for the same release. Uploading of a new binary to #development release becomes impossible after 6 month since creation of that release. I have to delete and re-create releases once in a while... Cheers, Alex On 1 April 2018 at 12:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > On 31 Mar 2018, at 22:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Pablo & Eliot, > > On 31 March 2018 at 20:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Pablo, > > On Sat, Mar 31, 2018 at 10:19 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> > wrote: > > > Hi, > I am taking the VM from the latest VM in > http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo > scripts, I believe is > http://files.pharo.org/get-files/70/pharo-mac-latest.zip) > The output of version in the VM is: > > 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler: > 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] > > CoInterpreter VMMaker.oscog-eem.2347 uuid: > 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 > > StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid: > 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 > > VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Mar 15 20:36:43 2018 +0100 $ > > Plugins: 201803151936 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > I don't know if this information helps you to know the specific commit, > but please feel free to tell me how I can get the exact commit from the VM. > Or where to get other VMs to check the error. > > > > The best one can do is either > - running the VM executable from the command line using --version > - via the System Reporter > > Alas git doesn't help here. Unlike many other scc systems git doesn't > provide a metalanguage to embed the current commit id into source. The > best > we have is the time stamp and as we can see the granularity isn't good > enough when things are changing quickly. > > > git doesn't provide a substitution mechanism like sccs, but the script > we have that embeds the date can just as easily embed the hash. In > .git_filters/RevDateURL.smudge there's a line that retrieves the > commit date from git: > > $date = `git log --format=%ad -1`; > > to get the (short) hash we can simply add: > > $shorthash = `git log --format=%h -1`; > > The string substitution can then proceed as for the date. > > I think it would be worthwhile having both the date and hash in the > --version info. > > I'm happy to add this in and update the --version output if there's > general agreement. > > > > As Alistair says, the issue is fixed in the VMMaker.oscog package commit > VMMaker.oscog-eem.2359, which is > > commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Thu Mar 15 18:09:12 2018 -0700 > > > > Which unfortunately is 1 commit after the version you have. > > There appears to be a separate problem that MacOS VMs aren't being > uploaded to files.pharo.org, so while running the VM through the Pharo > automated test suite and bootstrap process is a great idea, right now > we need to wait for an updated VM for MacOS. :-(. > > > I just figured out last green build of Cog was 16 days ago so is correct > (and not an error) that no mac build is being copied: there is no build > since linux build failed and then no mac build was ran. > Is not a problem about mac files copied to pharo file server but a general > one (but that does not explains the bintray problem, since last upload > there is from 8/03 and there was at least one successful build after) > > cheers, > Esteban > > > > Cheers, > Alistair > > > > CogVM source as per VMMaker.oscog-eem.2359 > > Cogits: > Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when > improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so > a > guard is needed. > > I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog > commit. I thought it did. I'll fix this. > > > Cheers, > Pablo > > On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > Hi Pablo, > > On 31 March 2018 at 18:36, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > > Hi Everyone, > I have created the PR in Pharo, so the CI runs the bootstrap with the > latest VM (March 15th). > Running the process fails during execution of the tests in 32bits OSX. > It crashes the VM with a segmentation fault. > I could reproduce the crash, running the tests from the command line, > and > also running OCBytecodeGeneratorTest test. > > > > There were several VMs built on / around the 15th. Would you mind > letting me know the commit hash as Eliot fixed this particular problem > about then. > > I tested 43a2f5c. > > Thanks, > Alistair > > > > > I am attaching the crash.dmp with both executions (from the commandLine > and > headful), both are in the same point. > > Cheers, > Pablo > > On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> > wrote: > > > I will try to promote then the one of 15 march. Weâll see next week. > but then, this is part of my observation: We cannot know which VMs > are > stable, and thatâs because the *process* to make them stable is very > âhuman > dependentâ: We consider a version stable when it builds on CI and > Eliot > says > is stable. But since Eliot does not use Pharo (not a critic, a > reality), > that may be not true for Pharo. And thatâs actually what happens, > Pharo > crashes. > > > Hi esteban > > What would be a way to fix the process and make your work easier? > > If you do not know what can be a release candidate then who can? > We should really improve this situation. > > Stef > > > I tried to avoid a bit this problem with our fork and nightly builds > that > runs the pharo tests (to knew about problems as early as possible). > But > to > be honest I didnât have the time (and the will) to work on it > recently, > then > pharo fork is in practice stalled. I will revive that eventuallyâ¦ > but > just > when I find the time and the spirit to do it. > > > to one more up to date than 2017 08 27 (in fact more up-to-date than > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, > Fri > Jan 19 > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can > result > in image corruption in large images, and can occur (as it has here) > at > start-up, causing one's work to be irretrievably lost. > > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that > are > triggered either by the automated test suite or the bootstrap > process. > > > The blocks I can see at the moment are: > > - Multiple builds have failed with an internal compiler error on the > sista builds. > -- The earliest occurrence I could find was commit 1f0a7da, but it > may > have been earlier. > - Even if the Mac builds show success in travis, they aren't making > it > on to files.pharo.org. > > > latest VM copied into files.pharo.org is 16/03. > we need to see whatâs happening there. > > -- I haven't ever worked with this code. > > Not directly related, but: > - Bintray hasn't been updated since 8 March 2018. > > > I think it could also be useful for files.pharo.org to have release > candidate links available, which would help people to focus testing > on > a particular VM. They would need to be manually maintained, but I > think the benefits would be worthwhile. > > > all VMs are available to test. > justâ¦ not available *directly* to general users. > nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know > which VM > is RC I find it pointless at this moment. > > cheers, > Esteban > > > > Cheers, > Alistair > > > > > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > > > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > >

April 1, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Esteban Lorenzano

hi, > On 31 Mar 2018, at 22:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Pablo & Eliot, > > On 31 March 2018 at 20:49, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> Hi Pablo, >> >> On Sat, Mar 31, 2018 at 10:19 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> >> wrote: >>> >>> Hi, >>> I am taking the VM from the latest VM in >>> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo >>> scripts, I believe is >>> http://files.pharo.org/get-files/70/pharo-mac-latest.zip) >>> The output of version in the VM is: >>> >>> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler: >>> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] >>> >>> CoInterpreter VMMaker.oscog-eem.2347 uuid: >>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 >>> >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid: >>> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 >>> >>> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> Date: Thu Mar 15 20:36:43 2018 +0100 $ >>> >>> Plugins: 201803151936 >>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> >>> >>> I don't know if this information helps you to know the specific commit, >>> but please feel free to tell me how I can get the exact commit from the VM. >>> Or where to get other VMs to check the error. >> >> >> The best one can do is either >> - running the VM executable from the command line using --version >> - via the System Reporter >> >> Alas git doesn't help here. Unlike many other scc systems git doesn't >> provide a metalanguage to embed the current commit id into source. The best >> we have is the time stamp and as we can see the granularity isn't good >> enough when things are changing quickly. > > git doesn't provide a substitution mechanism like sccs, but the script > we have that embeds the date can just as easily embed the hash. In > .git_filters/RevDateURL.smudge there's a line that retrieves the > commit date from git: > > $date = `git log --format=%ad -1`; > > to get the (short) hash we can simply add: > > $shorthash = `git log --format=%h -1`; > > The string substitution can then proceed as for the date. > > I think it would be worthwhile having both the date and hash in the > --version info. > > I'm happy to add this in and update the --version output if there's > general agreement. > > > >> As Alistair says, the issue is fixed in the VMMaker.oscog package commit >> VMMaker.oscog-eem.2359, which is >> >> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb >> Author: Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> >> Date: Thu Mar 15 18:09:12 2018 -0700 > > > Which unfortunately is 1 commit after the version you have. > > There appears to be a separate problem that MacOS VMs aren't being > uploaded to files.pharo.org <http://files.pharo.org/>, so while running the VM through the Pharo > automated test suite and bootstrap process is a great idea, right now > we need to wait for an updated VM for MacOS. :-(. I just figured out last green build of Cog was 16 days ago so is correct (and not an error) that no mac build is being copied: there is no build since linux build failed and then no mac build was ran. Is not a problem about mac files copied to pharo file server but a general one (but that does not explains the bintray problem, since last upload there is from 8/03 and there was at least one successful build after) cheers, Esteban > > > Cheers, > Alistair > > > >> CogVM source as per VMMaker.oscog-eem.2359 >> >> Cogits: >> Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when >> improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a >> guard is needed. >> >> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog >> commit. I thought it did. I'll fix this. >> >>> >>> Cheers, >>> Pablo >>> >>> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>>> >>>> Hi Pablo, >>>> >>>> On 31 March 2018 at 18:36, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >>>>> Hi Everyone, >>>>> I have created the PR in Pharo, so the CI runs the bootstrap with the >>>>> latest VM (March 15th). >>>>> Running the process fails during execution of the tests in 32bits OSX. >>>>> It crashes the VM with a segmentation fault. >>>>> I could reproduce the crash, running the tests from the command line, >>>>> and >>>>> also running OCBytecodeGeneratorTest test. >>>> >>>> >>>> There were several VMs built on / around the 15th. Would you mind >>>> letting me know the commit hash as Eliot fixed this particular problem >>>> about then. >>>> >>>> I tested 43a2f5c. >>>> >>>> Thanks, >>>> Alistair >>>> >>>> >>>> >>>>> >>>>> I am attaching the crash.dmp with both executions (from the commandLine >>>>> and >>>>> headful), both are in the same point. >>>>> >>>>> Cheers, >>>>> Pablo >>>>> >>>>> On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse >>>>> <stepharo.self(a)gmail.com> >>>>> wrote: >>>>>> >>>>>>> I will try to promote then the one of 15 march. Weâll see next week. >>>>>>> but then, this is part of my observation: We cannot know which VMs >>>>>>> are >>>>>>> stable, and thatâs because the *process* to make them stable is very >>>>>>> âhuman >>>>>>> dependentâ: We consider a version stable when it builds on CI and >>>>>>> Eliot >>>>>>> says >>>>>>> is stable. But since Eliot does not use Pharo (not a critic, a >>>>>>> reality), >>>>>>> that may be not true for Pharo. And thatâs actually what happens, >>>>>>> Pharo >>>>>>> crashes. >>>>>> >>>>>> Hi esteban >>>>>> >>>>>> What would be a way to fix the process and make your work easier? >>>>>> >>>>>> If you do not know what can be a release candidate then who can? >>>>>> We should really improve this situation. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>>> I tried to avoid a bit this problem with our fork and nightly builds >>>>>>> that >>>>>>> runs the pharo tests (to knew about problems as early as possible). >>>>>>> But >>>>>>> to >>>>>>> be honest I didnât have the time (and the will) to work on it >>>>>>> recently, >>>>>>> then >>>>>>> pharo fork is in practice stalled. I will revive that eventuallyâ¦ >>>>>>> but >>>>>>> just >>>>>>> when I find the time and the spirit to do it. >>>>>>> >>>>>>> >>>>>>> to one more up to date than 2017 08 27 (in fact more up-to-date than >>>>>>> opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, >>>>>>> Fri >>>>>>> Jan 19 >>>>>>> 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can >>>>>>> result >>>>>>> in image corruption in large images, and can occur (as it has here) >>>>>>> at >>>>>>> start-up, causing one's work to be irretrievably lost. >>>>>>> >>>>>>> >>>>>>> Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that >>>>>>> are >>>>>>> triggered either by the automated test suite or the bootstrap >>>>>>> process. >>>>>>> >>>>>>> >>>>>>> The blocks I can see at the moment are: >>>>>>> >>>>>>> - Multiple builds have failed with an internal compiler error on the >>>>>>> sista builds. >>>>>>> -- The earliest occurrence I could find was commit 1f0a7da, but it >>>>>>> may >>>>>>> have been earlier. >>>>>>> - Even if the Mac builds show success in travis, they aren't making >>>>>>> it >>>>>>> on to files.pharo.org. >>>>>>> >>>>>>> >>>>>>> latest VM copied into files.pharo.org is 16/03. >>>>>>> we need to see whatâs happening there. >>>>>>> >>>>>>> -- I haven't ever worked with this code. >>>>>>> >>>>>>> Not directly related, but: >>>>>>> - Bintray hasn't been updated since 8 March 2018. >>>>>>> >>>>>>> >>>>>>> I think it could also be useful for files.pharo.org to have release >>>>>>> candidate links available, which would help people to focus testing >>>>>>> on >>>>>>> a particular VM. They would need to be manually maintained, but I >>>>>>> think the benefits would be worthwhile. >>>>>>> >>>>>>> >>>>>>> all VMs are available to test. >>>>>>> justâ¦ not available *directly* to general users. >>>>>>> nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know >>>>>>> which VM >>>>>>> is RC I find it pointless at this moment. >>>>>>> >>>>>>> cheers, >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alistair >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pablo Tesone. >>>>> tesonep(a)gmail.com >>>> >>> >>> >>> >>> -- >>> Pablo Tesone. >>> tesonep(a)gmail.com >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot

April 1, 2018

Re: [Pharo-dev] Roadmap to Pharo 7 Release

by Stephane Ducasse

Hi Peter Now we do not want to rely on Glamour. You should pay attention since it is not maintained and producing memory leaks and we would like to avoid to have to fight to find them. I do not know what are the plans of feenk at this level. This is why we started to redesign Spec. Stef On Sat, Mar 31, 2018 at 8:58 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > On Sat, Mar 31, 2018 at 7:52 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> >> >> On 31 Mar 2018, at 17:17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> What does this means for end users? >> >> >> nothing. >> we are removing some *users* of glamour. >> Not glamour itself and certainly not the gttools that use glamour >> intensively (and they allow easy extension). > > > Aaah. My heart skipped originally, now I am at peace. :) > >> ps: but there are leaks around we would like to discover how and when they >> happen (because they are not so many and not evident). Any help there is >> welcome :) > > > I'll keep that in mind, although I don't usually check whether there are any > pointers dangling. > > Thanks! > Peter

April 1, 2018

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

by Stephane Ducasse

Hi Torsten Thanks for this question. Ephemerons do not work in Pharo sadly and we know it. We cannot then take advantage of them. What you see is in fact a degradation of the situation around the VM. :( We are concerned about this but the path for our future in this domain is unclear. What is clear is that we will reduce the number of Plugin (as pablo did for freetype) and use FFI. But FFI callbacks are not really good. And we need a threaded VM. Now nothing happens on this front. Let us face it there is a bad energy around. After years of discussion our engineers are still struggling and slowed down because of the dispersion of plugin code. In addition, from what I understood there is no development branch :) amazing is not it in 2020! On another scale, since 1 year, I was focusing on making that our institute offers a permanent position to Clement but I failed because the forces against where too strong (politics) and clement should reapply next year. Now to improve his CV, clement is doing a postdoc at VUB and will start working on Truffle (the VM of Oracle) and continue to work part time on Sista. This is not that bad, like that he will gain experience on other systems and in the future we will be in the position to see if there are real alternatives for us. May be writing a new VM on top of other existing infrastructure is the way to go. We will see in the future. To be fully transparent - we will have one phd working on IoT and how to reduce/clean the image and VM size and many other points she will probably work on a fork because I cannot suicide a student (by asking her to understand the messy plugin architecture) and she will need some space to experiment. Now if improvements she will perform take ages to be integrated in the main VM I will ask her not to do it and to focus on her future and science. I imagine that everybody paying attention to people can understand this. Stef On Tue, Nov 7, 2017 at 9:00 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > by accident I stumbled upon the following code in AnnouncementSubscription: > > makeWeak > action isBlock ifTrue: [ self error: 'Not currently available due to missing ephemerons support']. > ... > > My understanding is that we have Ephemeron support in Pharo now working. Right? > > Anyone with more insights who knows how to fix/complete this? Should we at least open an issue? > > Thx > T. > >

April 1, 2018

[Pharo 7.0-dev] Build #748: SUCCESS

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

There is a new Pharo build available! The status of the build #748 was: SUCCESS. Could not extract further issue information from commit message: https://github.com/pharo-project/pharo/pull/1175 https://pharo.manuscript.com/f/cases/10181 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 1, 2018

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

by Sean P. DeNigris

Torsten Bergmann wrote > This raises the question about the current status of Ephemerons? Bump. What is the status of Ephemerons in Pharo 6.1 and 7? There was an announcement with several asterisks about full support [1] and there are these related issues that were closed with "stale (timeout)": - "Make usage of Ephemerons instead of WeakRegistry" https://pharo.manuscript.com/f/cases/19152 - https://pharo.fogbugz.com/f/cases/10787/Make-Announcements-Weak-By-Default 1. http://forum.world.st/ANN-Ephemeron-Support-is-Ready-td4899584.html ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 1, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Alistair Grant

Hi Pablo & Eliot, On 31 March 2018 at 20:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Pablo, > > On Sat, Mar 31, 2018 at 10:19 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> > wrote: >> >> Hi, >> I am taking the VM from the latest VM in >> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo >> scripts, I believe is >> http://files.pharo.org/get-files/70/pharo-mac-latest.zip) >> The output of version in the VM is: >> >> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler: >> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] >> >> CoInterpreter VMMaker.oscog-eem.2347 uuid: >> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 >> >> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid: >> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 >> >> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Thu Mar 15 20:36:43 2018 +0100 $ >> >> Plugins: 201803151936 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> I don't know if this information helps you to know the specific commit, >> but please feel free to tell me how I can get the exact commit from the VM. >> Or where to get other VMs to check the error. > > > The best one can do is either > - running the VM executable from the command line using --version > - via the System Reporter > > Alas git doesn't help here. Unlike many other scc systems git doesn't > provide a metalanguage to embed the current commit id into source. The best > we have is the time stamp and as we can see the granularity isn't good > enough when things are changing quickly. git doesn't provide a substitution mechanism like sccs, but the script we have that embeds the date can just as easily embed the hash. In .git_filters/RevDateURL.smudge there's a line that retrieves the commit date from git: $date = `git log --format=%ad -1`; to get the (short) hash we can simply add: $shorthash = `git log --format=%h -1`; The string substitution can then proceed as for the date. I think it would be worthwhile having both the date and hash in the --version info. I'm happy to add this in and update the --version output if there's general agreement. > As Alistair says, the issue is fixed in the VMMaker.oscog package commit > VMMaker.oscog-eem.2359, which is > > commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Thu Mar 15 18:09:12 2018 -0700 Which unfortunately is 1 commit after the version you have. There appears to be a separate problem that MacOS VMs aren't being uploaded to files.pharo.org, so while running the VM through the Pharo automated test suite and bootstrap process is a great idea, right now we need to wait for an updated VM for MacOS. :-(. Cheers, Alistair > CogVM source as per VMMaker.oscog-eem.2359 > > Cogits: > Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when > improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a > guard is needed. > > I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog > commit. I thought it did. I'll fix this. > >> >> Cheers, >> Pablo >> >> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >>> >>> Hi Pablo, >>> >>> On 31 March 2018 at 18:36, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >>> > Hi Everyone, >>> > I have created the PR in Pharo, so the CI runs the bootstrap with the >>> > latest VM (March 15th). >>> > Running the process fails during execution of the tests in 32bits OSX. >>> > It crashes the VM with a segmentation fault. >>> > I could reproduce the crash, running the tests from the command line, >>> > and >>> > also running OCBytecodeGeneratorTest test. >>> >>> >>> There were several VMs built on / around the 15th. Would you mind >>> letting me know the commit hash as Eliot fixed this particular problem >>> about then. >>> >>> I tested 43a2f5c. >>> >>> Thanks, >>> Alistair >>> >>> >>> >>> > >>> > I am attaching the crash.dmp with both executions (from the commandLine >>> > and >>> > headful), both are in the same point. >>> > >>> > Cheers, >>> > Pablo >>> > >>> > On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse >>> > <stepharo.self(a)gmail.com> >>> > wrote: >>> >> >>> >> > I will try to promote then the one of 15 march. Weâll see next week. >>> >> > but then, this is part of my observation: We cannot know which VMs >>> >> > are >>> >> > stable, and thatâs because the *process* to make them stable is very >>> >> > âhuman >>> >> > dependentâ: We consider a version stable when it builds on CI and >>> >> > Eliot >>> >> > says >>> >> > is stable. But since Eliot does not use Pharo (not a critic, a >>> >> > reality), >>> >> > that may be not true for Pharo. And thatâs actually what happens, >>> >> > Pharo >>> >> > crashes. >>> >> >>> >> Hi esteban >>> >> >>> >> What would be a way to fix the process and make your work easier? >>> >> >>> >> If you do not know what can be a release candidate then who can? >>> >> We should really improve this situation. >>> >> >>> >> Stef >>> >> >>> >> >>> >> > I tried to avoid a bit this problem with our fork and nightly builds >>> >> > that >>> >> > runs the pharo tests (to knew about problems as early as possible). >>> >> > But >>> >> > to >>> >> > be honest I didnât have the time (and the will) to work on it >>> >> > recently, >>> >> > then >>> >> > pharo fork is in practice stalled. I will revive that eventuallyâ¦ >>> >> > but >>> >> > just >>> >> > when I find the time and the spirit to do it. >>> >> > >>> >> > >>> >> > to one more up to date than 2017 08 27 (in fact more up-to-date than >>> >> > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, >>> >> > Fri >>> >> > Jan 19 >>> >> > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can >>> >> > result >>> >> > in image corruption in large images, and can occur (as it has here) >>> >> > at >>> >> > start-up, causing one's work to be irretrievably lost. >>> >> > >>> >> > >>> >> > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that >>> >> > are >>> >> > triggered either by the automated test suite or the bootstrap >>> >> > process. >>> >> > >>> >> > >>> >> > The blocks I can see at the moment are: >>> >> > >>> >> > - Multiple builds have failed with an internal compiler error on the >>> >> > sista builds. >>> >> > -- The earliest occurrence I could find was commit 1f0a7da, but it >>> >> > may >>> >> > have been earlier. >>> >> > - Even if the Mac builds show success in travis, they aren't making >>> >> > it >>> >> > on to files.pharo.org. >>> >> > >>> >> > >>> >> > latest VM copied into files.pharo.org is 16/03. >>> >> > we need to see whatâs happening there. >>> >> > >>> >> > -- I haven't ever worked with this code. >>> >> > >>> >> > Not directly related, but: >>> >> > - Bintray hasn't been updated since 8 March 2018. >>> >> > >>> >> > >>> >> > I think it could also be useful for files.pharo.org to have release >>> >> > candidate links available, which would help people to focus testing >>> >> > on >>> >> > a particular VM. They would need to be manually maintained, but I >>> >> > think the benefits would be worthwhile. >>> >> > >>> >> > >>> >> > all VMs are available to test. >>> >> > justâ¦ not available *directly* to general users. >>> >> > nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know >>> >> > which VM >>> >> > is RC I find it pointless at this moment. >>> >> > >>> >> > cheers, >>> >> > Esteban >>> >> > >>> >> > >>> >> > >>> >> > Cheers, >>> >> > Alistair >>> >> > >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > Pablo Tesone. >>> > tesonep(a)gmail.com >>> >> >> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com > > > > > -- > _,,,^..^,,,_ > best, Eliot

March 31, 2018

Re: [Pharo-dev] Roadmap to Pharo 7 Release

by Peter UhnÃ¡k

On Sat, Mar 31, 2018 at 7:52 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 31 Mar 2018, at 17:17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > What does this means for end users? > > > nothing. > we are removing some *users* of glamour. > Not glamour itself and certainly not the gttools that use glamour > intensively (and they allow easy extension). > Aaah. My heart skipped originally, now I am at peace. :) ps: but there are leaks around we would like to discover how and when they > happen (because they are not so many and not evident). Any help there is > welcome :) I'll keep that in mind, although I don't usually check whether there are any pointers dangling. Thanks! Peter

March 31, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Eliot Miranda

Hi Pablo, On Sat, Mar 31, 2018 at 10:19 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, > I am taking the VM from the latest VM in http://files.pharo.org/get- > files/70/ (the one downloaded by the get pharo scripts, I believe is > http://files.pharo.org/get-files/70/pharo-mac-latest.zip) > The output of version in the VM is: > > 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler: > 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM] > > CoInterpreter VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 > Mar 15 2018 > > StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid: > 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018 > > VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Mar 15 20:36:43 2018 +0100 $ > > Plugins: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > > I don't know if this information helps you to know the specific commit, > but please feel free to tell me how I can get the exact commit from the VM. > Or where to get other VMs to check the error. > The best one can do is either - running the VM executable from the command line using --version - via the System Reporter Alas git doesn't help here. Unlike many other scc systems git doesn't provide a metalanguage to embed the current commit id into source. The best we have is the time stamp and as we can see the granularity isn't good enough when things are changing quickly. As Alistair says, the issue is fixed in the VMMaker.oscog package commit VMMaker.oscog-eem.2359, which is commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: Thu Mar 15 18:09:12 2018 -0700 CogVM source as per VMMaker.oscog-eem.2359 Cogits: Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when improving comoilation breakpoint. maybeSelectorOfMethod can answer nil so a guard is needed. I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog commit. I thought it did. I'll fix this. > Cheers, > Pablo > > On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> Hi Pablo, >> >> On 31 March 2018 at 18:36, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: >> > Hi Everyone, >> > I have created the PR in Pharo, so the CI runs the bootstrap with the >> > latest VM (March 15th). >> > Running the process fails during execution of the tests in 32bits OSX. >> > It crashes the VM with a segmentation fault. >> > I could reproduce the crash, running the tests from the command line, >> and >> > also running OCBytecodeGeneratorTest test. >> >> >> There were several VMs built on / around the 15th. Would you mind >> letting me know the commit hash as Eliot fixed this particular problem >> about then. >> >> I tested 43a2f5c. >> >> Thanks, >> Alistair >> >> >> >> > >> > I am attaching the crash.dmp with both executions (from the commandLine >> and >> > headful), both are in the same point. >> > >> > Cheers, >> > Pablo >> > >> > On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> >> > wrote: >> >> >> >> > I will try to promote then the one of 15 march. Weâll see next week. >> >> > but then, this is part of my observation: We cannot know which VMs >> are >> >> > stable, and thatâs because the *process* to make them stable is very >> >> > âhuman >> >> > dependentâ: We consider a version stable when it builds on CI and >> Eliot >> >> > says >> >> > is stable. But since Eliot does not use Pharo (not a critic, a >> reality), >> >> > that may be not true for Pharo. And thatâs actually what happens, >> Pharo >> >> > crashes. >> >> >> >> Hi esteban >> >> >> >> What would be a way to fix the process and make your work easier? >> >> >> >> If you do not know what can be a release candidate then who can? >> >> We should really improve this situation. >> >> >> >> Stef >> >> >> >> >> >> > I tried to avoid a bit this problem with our fork and nightly builds >> >> > that >> >> > runs the pharo tests (to knew about problems as early as possible). >> But >> >> > to >> >> > be honest I didnât have the time (and the will) to work on it >> recently, >> >> > then >> >> > pharo fork is in practice stalled. I will revive that eventuallyâ¦ but >> >> > just >> >> > when I find the time and the spirit to do it. >> >> > >> >> > >> >> > to one more up to date than 2017 08 27 (in fact more up-to-date than >> >> > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, >> Fri >> >> > Jan 19 >> >> > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can >> >> > result >> >> > in image corruption in large images, and can occur (as it has here) >> at >> >> > start-up, causing one's work to be irretrievably lost. >> >> > >> >> > >> >> > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are >> >> > triggered either by the automated test suite or the bootstrap >> process. >> >> > >> >> > >> >> > The blocks I can see at the moment are: >> >> > >> >> > - Multiple builds have failed with an internal compiler error on the >> >> > sista builds. >> >> > -- The earliest occurrence I could find was commit 1f0a7da, but it >> may >> >> > have been earlier. >> >> > - Even if the Mac builds show success in travis, they aren't making >> it >> >> > on to files.pharo.org. >> >> > >> >> > >> >> > latest VM copied into files.pharo.org is 16/03. >> >> > we need to see whatâs happening there. >> >> > >> >> > -- I haven't ever worked with this code. >> >> > >> >> > Not directly related, but: >> >> > - Bintray hasn't been updated since 8 March 2018. >> >> > >> >> > >> >> > I think it could also be useful for files.pharo.org to have release >> >> > candidate links available, which would help people to focus testing >> on >> >> > a particular VM. They would need to be manually maintained, but I >> >> > think the benefits would be worthwhile. >> >> > >> >> > >> >> > all VMs are available to test. >> >> > justâ¦ not available *directly* to general users. >> >> > nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know >> >> > which VM >> >> > is RC I find it pointless at this moment. >> >> > >> >> > cheers, >> >> > Esteban >> >> > >> >> > >> >> > >> >> > Cheers, >> >> > Alistair >> >> > >> >> > >> >> >> > >> > >> > >> > -- >> > Pablo Tesone. >> > tesonep(a)gmail.com >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- _,,,^..^,,,_ best, Eliot

March 31, 2018

Re: [Pharo-dev] Roadmap to Pharo 7 Release

by Esteban Lorenzano

> On 31 Mar 2018, at 17:17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > What does this means for end users? nothing. we are removing some *users* of glamour. Not glamour itself and certainly not the gttools that use glamour intensively (and they allow easy extension). > > I use Glamour extensively... does it mean that I will have to abandon all that code, or just that I need to load Glamour explicitly? Glamour is not leaving the image! cheers, Esteban ps: but there are leaks around we would like to discover how and when they happen (because they are not so many and not evident). Any help there is welcome :) > > Thanks, > Peter > > On Sat, Mar 31, 2018 at 4:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Iceberg :) > And all the user of Glamour that are not GT. > > Stef > > On Tue, Mar 27, 2018 at 9:28 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > >> Since Glamour is not really maintained anymore and source of some > >> leaks and problems, we want to remove any users > >> except GTTools. > > > > > > Can you please provide more info on this? What exactly is going to be > > removed? > > > > Thanks, > > Peter > >

March 31, 2018