hi, > On 31 Mar 2018, at 22:42, Alistair Grant <[email protected]> wrote: > > Hi Pablo & Eliot, > > On 31 March 2018 at 20:49, Eliot Miranda <[email protected] > <mailto:[email protected]>> wrote: >> Hi Pablo, >> >> On Sat, Mar 31, 2018 at 10:19 AM, [email protected] <[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> >> 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 <[email protected]> >>> wrote: >>>> >>>> Hi Pablo, >>>> >>>> On 31 March 2018 at 18:36, [email protected] <[email protected]> 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 >>>>> <[email protected]> >>>>> 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. >>>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Pablo Tesone. >>> [email protected] >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot
