Hi Guys -
Here is a short proposal for extending getSystemAttribute (see http://minnow.cc.gatech.edu/squeak/314):
* 1006 - build id; any string that uniquely identifies a VM build, preferredly in UUID format ('aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee')
Is this okay with everybody? (if so, I'll update the above page to include it)
Cheers, - Andreas
This is fine
Got source code...
On 21-Mar-06, at 2:14 PM, Andreas Raab wrote:
Hi Guys -
Here is a short proposal for extending getSystemAttribute (see http://minnow.cc.gatech.edu/squeak/314):
- 1006 - build id; any string that uniquely identifies a VM build,
preferredly in UUID format ('aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee')
Is this okay with everybody? (if so, I'll update the above page to include it)
Cheers,
- Andreas
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On 21-Mar-06, at 2:47 PM, John M McIntosh wrote:
This is fine
Got source code...
Well, and ideas on what exactly should be represented in this uuid?
How assuredly unique should it be? If 'moderately' is good enough then perhaps the compile-time would enough, though which of the many times involved in compiling should it be; compile time of a particular file, time the link finished...
What needs to be considered to make a VM unique and in need of a new uuid? If I generate a new set of stuff with VMMaker but nothing actually changed in the code, does that count? I recompile a file without regenerating it? I merely relink all the object files? What if the relink was needed because a new library had to be bound in?
Who wants to know the uuid and under what circumstances? On OSX it would be potentially nice to make it accessible to the 'getinfo' palette and probably M$ have copied much of that idea by now. It should probably appear in a help dialogue/string/window.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Paralyzed from the neck up.
Andreas is talking about using a UUID which for all purposes is unique. The hassle for the VM makers is that they need to remember to change the string in the callback when they build and publish a new VM, and also in OSx add it to the bundle info.
On 22-Mar-06, at 10:42 AM, tim Rowledge wrote:
On 21-Mar-06, at 2:47 PM, John M McIntosh wrote:
This is fine
Got source code...
Well, and ideas on what exactly should be represented in this uuid?
How assuredly unique should it be? If 'moderately' is good enough then perhaps the compile-time would enough, though which of the many times involved in compiling should it be; compile time of a particular file, time the link finished...
What needs to be considered to make a VM unique and in need of a new uuid? If I generate a new set of stuff with VMMaker but nothing actually changed in the code, does that count? I recompile a file without regenerating it? I merely relink all the object files? What if the relink was needed because a new library had to be bound in?
Who wants to know the uuid and under what circumstances? On OSX it would be potentially nice to make it accessible to the 'getinfo' palette and probably M$ have copied much of that idea by now. It should probably appear in a help dialogue/string/window.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Paralyzed from the neck up.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On 22-Mar-06, at 11:02 AM, John M McIntosh wrote:
Andreas is talking about using a UUID which for all purposes is unique. The hassle for the VM makers is that they need to remember to change the string in the callback when they build and publish a new VM, and also in OSx add it to the bundle info.
I think that's what I said. To avoid manual hassle - and hopefully cases where a uuid wasn't set or worse yet didn't get changed - you need to incorporate as much of it as possible into the automated system. It's not difficult to use makefile rules to always compile a tiny file with nothing more than the time in it - see platforms/ RiscOS/vm/sqRPCVersion.c for example- and that is a sort of uuid analogue that changes with every compile/link.
Another possibility is a 'Genuine Official VM' site where the act of publishing a vm onto the site creates a suitable uuid and incorporates it somehow. For RISC OS and OSX it would be trivial - write the uuid into a file inside the package bundle and the vm code reads that at need. For Windows it might be possible to run some program to comple the uuid file into the exe and for unix it would probably be simple since the server is likely to run some flavour of *nix. Development vms could include a default uuid file that declares them as unpublished and not to be trusted.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim when people are free to do as they please, they usually imitate each other
Am 22.03.2006 um 20:23 schrieb tim Rowledge:
On 22-Mar-06, at 11:02 AM, John M McIntosh wrote:
Andreas is talking about using a UUID which for all purposes is unique. The hassle for the VM makers is that they need to remember to change the string in the callback when they build and publish a new VM, and also in OSx add it to the bundle info.
I think that's what I said. To avoid manual hassle - and hopefully cases where a uuid wasn't set or worse yet didn't get changed - you need to incorporate as much of it as possible into the automated system. It's not difficult to use makefile rules to always compile a tiny file with nothing more than the time in it - see platforms/ RiscOS/vm/sqRPCVersion.c for example- and that is a sort of uuid analogue that changes with every compile/link.
Another possibility is a 'Genuine Official VM' site where the act of publishing a vm onto the site creates a suitable uuid and incorporates it somehow.
No, this should be unique without publishing to any official place, and needs to be different whenever you have a new binary. See here for the discussion:
http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=vm- dev&cmd=showmsg&msgnum=482
I think the compile time plus host name would make a fairly good id - the unix VM has this anyways:
"Linux squeak.hpl.hp.com 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux"
- Bert -
Bert Freudenberg wrote:
I think the compile time plus host name would make a fairly good id - the unix VM has this anyways:
"Linux squeak.hpl.hp.com 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004i686 GNU/Linux"
That would work just fine if the string is based on link (vs. compile) time.
Cheers, - Andreas
I've updated http://minnow.cc.gatech.edu/squeak/314 with this information and implemented a Windows version accordingly. I now actually think that type of identifier is more useful (if updated automatically) since it gives extra information about who and where a VM was built.
Can I ask you to support getSystemAttribute(1006) in your next versions?
Thanks, - Andreas
Andreas Raab wrote:
Bert Freudenberg wrote:
I think the compile time plus host name would make a fairly good id - the unix VM has this anyways:
"Linux squeak.hpl.hp.com 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC2004 i686 GNU/Linux"
That would work just fine if the string is based on link (vs. compile) time.
Cheers,
- Andreas
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
John M McIntosh -
tim Rowledge