Source Tree/Repository revision info for the VM [was Re: [Vm-dev] new Cog VMs available]

> Hi Bert,
>
> On Thu, Jul 14, 2011 at 12:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>
>>
>> On 13.07.2011, at 22:56, Eliot Miranda wrote:
>>
>> > Hi All,
>> >
>> >     find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/.  These have functional ALien callbacks.  Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32.
>>
>> Hi Eliot,
>>
>> do you keep a continuous changelog somewhere for your releases? It would be nice to include that in the VM.
>>
>> Also, your Mac VM bundles always have the same version number which is somewhat inconvenient. Would be nice to splice the release version into Info.plist.
>
> I think I've found what's required:
> http://stackoverflow.com/questions/206183/how-can-i-force-subversion-to-commit-an-unchanged-file
> In particular
>
> If you want the file contents to remain unchanged you can always
> change one of the properties on the file.
>
> eg.
>
> svn propset dummyproperty 1 yourfile
>
> hence "Use Case: A file (config, xml, etc.) is chosen as a canonical
> version beacon for other apps. It indicates that "the code queried
> represents version rXYZ in SVN". Using SVN's macros on commit ("$Rev:
> xxxxx $") would be ideal for these purposes, provided SVN would deign
> to update an unchanged file. – pcorcoran"
>
> So I can now force a change to each Info.plist file and embed the Rev
> property.  I can also embed the Rev property in relevant .c or .h
> files to cause the Rev property to show in the relevant VM version
> strings.
>
> And I can fire off the svn propset via a precommit hook.  What I can't
> do is make this corss-platform.  It'll work on unixes but fall flat on
> e.g. Windows wirth TortoiseSVN.  Unless anyone knows better.  If so,
> let me know.
>
>>
>> While I'm in nitpicking mode: CFBundleVersion is recommended to be a simple integer, incremented for each bundle release - your "2459" might serve fine. This is not shown in the UI. The Finder shows CFBundleShortVersionString and the Get Info dialog shows CFBundleGetInfoString. Both of these are free-form as far as OS X is concerned, you can put anything you want in there. "Smalltalk vmVersion" includes CFBundleShortVersionString so there may be users expecting a certain format.
>>
>> Your current CFBundleGetInfoString has a link to a "boutique web design" company. I'm almost certain that's not what you wanted to put in there.
>>
>> In other words: Thanks for the new release ;)
>>
>> - Bert -
>>
>
>
>
> --
> best,
> Eliot
>

>
> Hi All,
>
>    I juts committed a workable scheme for including version info in
> the VM and the Mac .app, checked in on
> http://www.squeakvm.org/svn/squeak/branches/Cog.
>
> - I've added a file platforms/Cross/vm/sqSCCSVersion.h which is
> included by the platform files that answer the Smalltalk
> getSystemAttribute: information (sqMacMain.c sqUnixMain.c &
> sqWin32Window.c).
>
> - I've modified the getSystemAttribute: code to answer the revision
> and repository URL in response to getSystemAttribute: 1009.
>
> - I've added a check-in script that makes sure sqSCCSVersion.h is
> updated (if the script is used) so sqSCCSVersion.h's revision number
> is up-to-date.
>
> So now e.g. Smalltalk getSystemAttribute: 1009 answers 'r2461
> http://www.squeakvm.org/svn/squeak/branches/Cog'
>
> The scheme in sqSCCSVersion.h is simple and I hope extensible to other
> repositories such that it is the only file that needs to fork between
> repositories, and then only by altering the following lines to choose
> the relevant repository:
>
> #define SCCS 0
> #define RCS 0
> #define CVS 0
> #define SUBVERSION 1
> #define BAZAAR 0
> #define MERCURIAL 0
> #define GIT 0
>
> e.g. choosing the repository on the command line via a Makefile means
> changing lots of makefiles.  So this approach, while not ideal, having
>  file different between different repositories does localise the fork
> to just one file.
>
> Here's sqSCCSVersion.h in its entirety.  It computes char
> *sourceVersionString(), which is that above.  If this approach makes
> sense to people we can a) standardise on an attribute number (I chose
> 1009 as the next unused number but am open to change if there's a good
> reason), and b) extend sqSCCSVersion.h with the relevant sccs-specific
> code to collect revision and url information for each specific
> repository.  Thoughts, comments?
>

> HTH
> Eliot
>
> /*
>  * A set of definitions for C source code control systems, to provide accurate
>  * and definitive version information to the VM.
>  *
>  * Currently instantiated only for Subversion.  Please add definitions for
>  * other repositories as appropriate.
>  *
>  * I guess a good way to manage this is to edit the below define list to select
>  * appropriate the repository type, and then that's the extent of the fork.
>  *
>  * Eliot Miranda
>  * [hidden email]
>  * 15 July 2011
>  */
>
> #define SCCS 0
> #define RCS 0
> #define CVS 0
> #define SUBVERSION 1
> #define BAZAAR 0
> #define MERCURIAL 0
> #define GIT 0
>
>
> #if SUBVERSION
> static char SvnRawRevisionString[] = "$Rev: 2461 $";
> # define REV_START (SvnRawRevisionString + 6)
>
> static char SvnRawRepositoryURL[] = "$URL:
> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/sqSCCSVersion.h
> $";
> # define URL_START (SvnRawRepositoryURL + 6)
>
> static long
> revisionAsLong() { return atol(REV_START); }
>
> static char *
> revisionAsString()
> {
>        char *maybe_space = strchr(REV_START,' ');
>        if (maybe_space)
>                *maybe_space = 0;
>        return REV_START;
> }
>
> static char *
> repositoryURL()
> {
>        char *maybe_platforms = strstr(URL_START, "/platforms");
>        if (maybe_platforms)
>                *maybe_platforms = 0;
>        return URL_START;
> }
> # undef REV_START
> # undef URL_START
> #else /* SUBVERSION */
> static long
> revisionAsLong() { return -1; }
>
> static char *
> revisionAsString() { return "?"; }
>
> static char *
> repositoryURL() { return "unknown"; }
> #endif /* SUBVERSION */
>
> static char *sourceVersion = 0;
>
> static char *sourceVersionString()
> {
>        if (!sourceVersion) {
>                int len = strlen(revisionAsString()) + strlen(repositoryURL()) + 3;
>                sourceVersion = malloc(len);
>                sprintf(sourceVersion,"r%s %s",revisionAsString(),repositoryURL());
>        }
>        return sourceVersion;
> }
>
>
> On Fri, Jul 15, 2011 at 9:27 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Bert,
>>
>> On Thu, Jul 14, 2011 at 12:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>
>>> On 13.07.2011, at 22:56, Eliot Miranda wrote:
>>>
>>> > Hi All,
>>> >
>>> >     find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/.  These have functional ALien callbacks.  Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32.
>>>
>>> Hi Eliot,
>>>
>>> do you keep a continuous changelog somewhere for your releases? It would be nice to include that in the VM.
>>>
>>> Also, your Mac VM bundles always have the same version number which is somewhat inconvenient. Would be nice to splice the release version into Info.plist.
>>
>> I think I've found what's required:
>> http://stackoverflow.com/questions/206183/how-can-i-force-subversion-to-commit-an-unchanged-file
>> In particular
>>
>> If you want the file contents to remain unchanged you can always
>> change one of the properties on the file.
>>
>> eg.
>>
>> svn propset dummyproperty 1 yourfile
>>
>> hence "Use Case: A file (config, xml, etc.) is chosen as a canonical
>> version beacon for other apps. It indicates that "the code queried
>> represents version rXYZ in SVN". Using SVN's macros on commit ("$Rev:
>> xxxxx $") would be ideal for these purposes, provided SVN would deign
>> to update an unchanged file. – pcorcoran"
>>
>> So I can now force a change to each Info.plist file and embed the Rev
>> property.  I can also embed the Rev property in relevant .c or .h
>> files to cause the Rev property to show in the relevant VM version
>> strings.
>>
>> And I can fire off the svn propset via a precommit hook.  What I can't
>> do is make this corss-platform.  It'll work on unixes but fall flat on
>> e.g. Windows wirth TortoiseSVN.  Unless anyone knows better.  If so,
>> let me know.
>>
>>>
>>> While I'm in nitpicking mode: CFBundleVersion is recommended to be a simple integer, incremented for each bundle release - your "2459" might serve fine. This is not shown in the UI. The Finder shows CFBundleShortVersionString and the Get Info dialog shows CFBundleGetInfoString. Both of these are free-form as far as OS X is concerned, you can put anything you want in there. "Smalltalk vmVersion" includes CFBundleShortVersionString so there may be users expecting a certain format.
>>>
>>> Your current CFBundleGetInfoString has a link to a "boutique web design" company. I'm almost certain that's not what you wanted to put in there.
>>>
>>> In other words: Thanks for the new release ;)
>>>
>>> - Bert -
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> best,
> Eliot
>

>
> Hi All,
>
>     I juts committed a workable scheme for including version info in
> the VM and the Mac .app, checked in on
> http://www.squeakvm.org/svn/squeak/branches/Cog.
>
> - I've added a file platforms/Cross/vm/sqSCCSVersion.h which is
> included by the platform files that answer the Smalltalk
> getSystemAttribute: information (sqMacMain.c sqUnixMain.c &
> sqWin32Window.c).
>
> - I've modified the getSystemAttribute: code to answer the revision
> and repository URL in response to getSystemAttribute: 1009.
>
> - I've added a check-in script that makes sure sqSCCSVersion.h is
> updated (if the script is used) so sqSCCSVersion.h's revision number
> is up-to-date.
>
> So now e.g. Smalltalk getSystemAttribute: 1009 answers 'r2461
> http://www.squeakvm.org/svn/squeak/branches/Cog'
>
> The scheme in sqSCCSVersion.h is simple and I hope extensible to other
> repositories such that it is the only file that needs to fork between
> repositories, and then only by altering the following lines to choose
> the relevant repository:
>
> #define SCCS 0
> #define RCS 0
> #define CVS 0
> #define SUBVERSION 1
> #define BAZAAR 0
> #define MERCURIAL 0
> #define GIT 0
>
> e.g. choosing the repository on the command line via a Makefile means
> changing lots of makefiles.  So this approach, while not ideal, having
>  file different between different repositories does localise the fork
> to just one file.
>
> Here's sqSCCSVersion.h in its entirety.  It computes char
> *sourceVersionString(), which is that above.  If this approach makes
> sense to people we can a) standardise on an attribute number (I chose
> 1009 as the next unused number but am open to change if there's a good
> reason), and b) extend sqSCCSVersion.h with the relevant sccs-specific
> code to collect revision and url information for each specific
> repository.  Thoughts, comments?

>
> On Fri, Jul 15, 2011 at 03:48:50PM -0700, Eliot Miranda wrote:
>>
>> Hi All,
>>
>>     I juts committed a workable scheme for including version info in
>> the VM and the Mac .app, checked in on
>> http://www.squeakvm.org/svn/squeak/branches/Cog.
>>
>> - I've added a file platforms/Cross/vm/sqSCCSVersion.h which is
>> included by the platform files that answer the Smalltalk
>> getSystemAttribute: information (sqMacMain.c sqUnixMain.c &
>> sqWin32Window.c).
>>
>> - I've modified the getSystemAttribute: code to answer the revision
>> and repository URL in response to getSystemAttribute: 1009.
>>
>> - I've added a check-in script that makes sure sqSCCSVersion.h is
>> updated (if the script is used) so sqSCCSVersion.h's revision number
>> is up-to-date.
>>
>> So now e.g. Smalltalk getSystemAttribute: 1009 answers 'r2461
>> http://www.squeakvm.org/svn/squeak/branches/Cog'
>>
>> The scheme in sqSCCSVersion.h is simple and I hope extensible to other
>> repositories such that it is the only file that needs to fork between
>> repositories, and then only by altering the following lines to choose
>> the relevant repository:
>>
>> #define SCCS 0
>> #define RCS 0
>> #define CVS 0
>> #define SUBVERSION 1
>> #define BAZAAR 0
>> #define MERCURIAL 0
>> #define GIT 0
>>
>> e.g. choosing the repository on the command line via a Makefile means
>> changing lots of makefiles.  So this approach, while not ideal, having
>>  file different between different repositories does localise the fork
>> to just one file.
>>
>> Here's sqSCCSVersion.h in its entirety.  It computes char
>> *sourceVersionString(), which is that above.  If this approach makes
>> sense to people we can a) standardise on an attribute number (I chose
>> 1009 as the next unused number but am open to change if there's a good
>> reason), and b) extend sqSCCSVersion.h with the relevant sccs-specific
>> code to collect revision and url information for each specific
>> repository.  Thoughts, comments?
>
> Hi Eliot,
>
> As an additional suggestion, if you could wire this version information
> into #primitiveInterpreterSourceVersion and #primitivePlatformSourceVersion,
> it would give a more consistent interface from the image side.

> Currently
> a Squeak image running on an up-to-date interpreter VM gives results
> such as:
>
>  Smalltalk vm interpreterSourceVersion ==> '4.7.0'
>  Smalltalk vm platformSourceVersion ==> '2438'
>
> This in turn is used by Help->About this System to report information about
> the VM, so it would be good if Cog and the interpreter VM could both provide
> these two primitives (or maybe just the #primitivePlatformSourceVersion?).
>
> It looks like #primitivePlatformSourceVersion would just need to answer
> the results of your new sourceVersionString(). I'm not sure how (or if)
> you would want to do #primitiveInterpreterSourceVersion, so maybe that's
> a different topic.
>
> Thanks,
> Dave
>
>

>
> On 16 July 2011 01:48, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi All,
>>
>>    I juts committed a workable scheme for including version info in
>> the VM and the Mac .app, checked in on
>> http://www.squeakvm.org/svn/squeak/branches/Cog.
>>
>> - I've added a file platforms/Cross/vm/sqSCCSVersion.h which is
>> included by the platform files that answer the Smalltalk
>> getSystemAttribute: information (sqMacMain.c sqUnixMain.c &
>> sqWin32Window.c).
>>
>> - I've modified the getSystemAttribute: code to answer the revision
>> and repository URL in response to getSystemAttribute: 1009.
>>
>> - I've added a check-in script that makes sure sqSCCSVersion.h is
>> updated (if the script is used) so sqSCCSVersion.h's revision number
>> is up-to-date.
>>
>> So now e.g. Smalltalk getSystemAttribute: 1009 answers 'r2461
>> http://www.squeakvm.org/svn/squeak/branches/Cog'
>>
>> The scheme in sqSCCSVersion.h is simple and I hope extensible to other
>> repositories such that it is the only file that needs to fork between
>> repositories, and then only by altering the following lines to choose
>> the relevant repository:
>>
>> #define SCCS 0
>> #define RCS 0
>> #define CVS 0
>> #define SUBVERSION 1
>> #define BAZAAR 0
>> #define MERCURIAL 0
>> #define GIT 0
>>
>> e.g. choosing the repository on the command line via a Makefile means
>> changing lots of makefiles.  So this approach, while not ideal, having
>>  file different between different repositories does localise the fork
>> to just one file.
>>
>> Here's sqSCCSVersion.h in its entirety.  It computes char
>> *sourceVersionString(), which is that above.  If this approach makes
>> sense to people we can a) standardise on an attribute number (I chose
>> 1009 as the next unused number but am open to change if there's a good
>> reason), and b) extend sqSCCSVersion.h with the relevant sccs-specific
>> code to collect revision and url information for each specific
>> repository.  Thoughts, comments?
>>
>
> I am a bit puzzled by the code.
> Why you need a function to evaluate the version string?

> If you taking stings from defines, like:
>
> #define URL "abc"
> #define VERSION "123"
>
> then you can just do
>
> #define VERSIONSTRING URL VERSION
>
> static char* versionstring = VERSIONSTRING;
>
> or not?
>
>> HTH
>> Eliot
>>
>> /*
>>  * A set of definitions for C source code control systems, to provide accurate
>>  * and definitive version information to the VM.
>>  *
>>  * Currently instantiated only for Subversion.  Please add definitions for
>>  * other repositories as appropriate.
>>  *
>>  * I guess a good way to manage this is to edit the below define list to select
>>  * appropriate the repository type, and then that's the extent of the fork.
>>  *
>>  * Eliot Miranda
>>  * [hidden email]
>>  * 15 July 2011
>>  */
>>
>> #define SCCS 0
>> #define RCS 0
>> #define CVS 0
>> #define SUBVERSION 1
>> #define BAZAAR 0
>> #define MERCURIAL 0
>> #define GIT 0
>>
>>
>> #if SUBVERSION
>> static char SvnRawRevisionString[] = "$Rev: 2461 $";
>> # define REV_START (SvnRawRevisionString + 6)
>>
>> static char SvnRawRepositoryURL[] = "$URL:
>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/sqSCCSVersion.h
>> $";
>> # define URL_START (SvnRawRepositoryURL + 6)
>>
>> static long
>> revisionAsLong() { return atol(REV_START); }
>>
>> static char *
>> revisionAsString()
>> {
>>        char *maybe_space = strchr(REV_START,' ');
>>        if (maybe_space)
>>                *maybe_space = 0;
>>        return REV_START;
>> }
>>
>> static char *
>> repositoryURL()
>> {
>>        char *maybe_platforms = strstr(URL_START, "/platforms");
>>        if (maybe_platforms)
>>                *maybe_platforms = 0;
>>        return URL_START;
>> }
>> # undef REV_START
>> # undef URL_START
>> #else /* SUBVERSION */
>> static long
>> revisionAsLong() { return -1; }
>>
>> static char *
>> revisionAsString() { return "?"; }
>>
>> static char *
>> repositoryURL() { return "unknown"; }
>> #endif /* SUBVERSION */
>>
>> static char *sourceVersion = 0;
>>
>> static char *sourceVersionString()
>> {
>>        if (!sourceVersion) {
>>                int len = strlen(revisionAsString()) + strlen(repositoryURL()) + 3;
>>                sourceVersion = malloc(len);
>>                sprintf(sourceVersion,"r%s %s",revisionAsString(),repositoryURL());
>>        }
>>        return sourceVersion;
>> }
>>
>>
>> On Fri, Jul 15, 2011 at 9:27 AM, Eliot Miranda <[hidden email]> wrote:
>>> Hi Bert,
>>>
>>> On Thu, Jul 14, 2011 at 12:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>>
>>>> On 13.07.2011, at 22:56, Eliot Miranda wrote:
>>>>
>>>> > Hi All,
>>>> >
>>>> >     find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/.  These have functional ALien callbacks.  Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32.
>>>>
>>>> Hi Eliot,
>>>>
>>>> do you keep a continuous changelog somewhere for your releases? It would be nice to include that in the VM.
>>>>
>>>> Also, your Mac VM bundles always have the same version number which is somewhat inconvenient. Would be nice to splice the release version into Info.plist.
>>>
>>> I think I've found what's required:
>>> http://stackoverflow.com/questions/206183/how-can-i-force-subversion-to-commit-an-unchanged-file
>>> In particular
>>>
>>> If you want the file contents to remain unchanged you can always
>>> change one of the properties on the file.
>>>
>>> eg.
>>>
>>> svn propset dummyproperty 1 yourfile
>>>
>>> hence "Use Case: A file (config, xml, etc.) is chosen as a canonical
>>> version beacon for other apps. It indicates that "the code queried
>>> represents version rXYZ in SVN". Using SVN's macros on commit ("$Rev:
>>> xxxxx $") would be ideal for these purposes, provided SVN would deign
>>> to update an unchanged file. – pcorcoran"
>>>
>>> So I can now force a change to each Info.plist file and embed the Rev
>>> property.  I can also embed the Rev property in relevant .c or .h
>>> files to cause the Rev property to show in the relevant VM version
>>> strings.
>>>
>>> And I can fire off the svn propset via a precommit hook.  What I can't
>>> do is make this corss-platform.  It'll work on unixes but fall flat on
>>> e.g. Windows wirth TortoiseSVN.  Unless anyone knows better.  If so,
>>> let me know.
>>>
>>>>
>>>> While I'm in nitpicking mode: CFBundleVersion is recommended to be a simple integer, incremented for each bundle release - your "2459" might serve fine. This is not shown in the UI. The Finder shows CFBundleShortVersionString and the Get Info dialog shows CFBundleGetInfoString. Both of these are free-form as far as OS X is concerned, you can put anything you want in there. "Smalltalk vmVersion" includes CFBundleShortVersionString so there may be users expecting a certain format.
>>>>
>>>> Your current CFBundleGetInfoString has a link to a "boutique web design" company. I'm almost certain that's not what you wanted to put in there.
>>>>
>>>> In other words: Thanks for the new release ;)
>>>>
>>>> - Bert -
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>