Good to know.
On Sun, Apr 1, 2018 at 12:52 PM, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
> 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 <esteba...@gmail.com> wrote:
>>
>> hi,
>>
>> On 31 Mar 2018, at 22:42, Alistair Grant <akgrant0...@gmail.com> wrote:
>>
>> 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. :-(.
>>
>>
>> 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 <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
>>
>>
>
