Hi Pablo & Eliot, On 31 March 2018 at 20:49, Eliot Miranda <eliot.mira...@gmail.com> wrote: > Hi Pablo, > > On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com <teso...@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.mira...@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 <akgrant0...@gmail.com> >> wrote: >>> >>> Hi Pablo, >>> >>> On 31 March 2018 at 18:36, teso...@gmail.com <teso...@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.s...@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. >>> > teso...@gmail.com >>> >> >> >> >> -- >> Pablo Tesone. >> teso...@gmail.com > > > > > -- > _,,,^..^,,,_ > best, Eliot
