[Vm-dev] VM git commit hash (was: Image crashing on startup, apparently during GC)

Eliot Miranda eliot.miranda at gmail.com
Mon Apr 2 23:02:11 UTC 2018


Hi Alistair, Hi Ben,


> On Apr 2, 2018, at 9:28 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> 
> Hi Ben,
> 
> 
>> On 2 April 2018 at 15:42, Ben Coman <btc at openinworld.com> wrote:
>> 
>> 
>> 
>>> On 2 April 2018 at 20:26, Alistair Grant <akgrant0710 at gmail.com> wrote:
>>> 
>>> 
>>>> On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote:
>>>> Hi Alistair,
>>>> 
>>>> _,,,^..^,,,_ (phone)
>>>> 
>>>>> On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>>>>> 
>>>>> 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.
>>>> 
>>>> Yes please!!! The conventional alternative is to invoke git log from
>>>> the makefiles and lass in the commit hash as a compiler-line default
>>>> me.  But this is messy and slows down compilation (unless there is a
>>>> special rule for just one file, and that's fragile).  I much prefer
>>>> having the commit somewhere in source.
>>> 
>>> Done:
>>> 
>>> $ git log --oneline | head
>>> 5a5b1c7 vm version string: add commit short hash
>>> 4c4686e Skip SUnit testing in Sista builds
>>> 79c0809 Merge pull request #230 from smalltalking/Cog
>>> 804ed5c Fixed typo in the download URL
>>> 
>>> 
>>> $ products/cogspur64linuxht/pharo --version
>>> 5.0-201804012008-version_hash  Sun Apr  1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM]
>>> CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr  1 2018
>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr  1 2018
>>> VM: 201804012008-version_hash alistair at 4c0a4b2bdb79:vmmaker/opensmalltalk-vm $
>>> Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $
>> 
>> 
>> Maybe rather than just "Hash:" could it be more explicit as "GitHash:" or even "GitSHA1:"
>> One day the algorithm is likely to change... "Moving Git past SHA-1" (https://lwn.net/Articles/715716/)
>> and it may be useful later to be able to distinguish.
> 
> I like "GitHash" as it may not be obvious what the hash refers to for
> a newcomer.  Even if/when git moves away from sha1, from a cli/ui
> perspective presumably it will still just be "the hash".

Commit Hash?
Commit Hash (git)?
C Commit Hash?
Repository Commit Hash?

We've already moved from one sccs to another for the C code and may move again if anyone improves on git, which is not inconceivable.

>>> Plugins: 201804012008-version_hash alistair at 4c0a4b2bdb79:vmmaker/opensmalltalk-vm $
>>> Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>>> plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/]
>>> 
>>> 
>>> As expected, the hash is also included in:
>>> 
>>> - the VirtualMachine object (in Pharo, and the equivalent in squeak)
>> 
>> 
>> I presume this is what shows up under System > System Reporter ?
> 
> Yes.
> 
> 
>>> - crash.dmp
>>> - kill -USR1 output
>>> 
>>> 
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233
>>> if anyone wants to take a look.
>> 
>> 
>> 
>> An interesting insight for me into how the version info is generated. thx.
> 
> Glad it was useful. :-)
> 
> Thanks for your feedback.  I'll update the PR (probably tomorrow).
> 
> Cheers,
> Alistair


More information about the Vm-dev mailing list