I presume that the appropriate fix at this point is to publish the TimeStamp class, which is currently in the SqueakMap code, to the 3.4b update stream. Any objections?
Cheers,
-- Scott
At 8:07 PM +0100 12/20/02, Andreas Raab wrote:
BTW, I just noticed that the standard UUIDGenerator>>makeSeed now uses "TimeStamp" - a class which is not present in 3.4.
Cheers,
- Andreas
In message <p05100303ba2925931ccd@[10.0.1.7]> Scott Wallace scott.wallace@squeakland.org wrote:
I presume that the appropriate fix at this point is to publish the TimeStamp class, which is currently in the SqueakMap code, to the 3.4b update stream. Any objections?
Weel we could use the alternative approach and remove the dependency on said class; what effect would that have on the usefulness of the uuid value?
tim
Cees, Doug, Tim, and all,
Gentlemen, how do you wish to proceed on this?
Thanks,
-- Scott
At 9:50 AM -0800 12/24/02, Tim Rowledge wrote:
In message <p05100303ba2925931ccd@[10.0.1.7]> Scott Wallace scott.wallace@squeakland.org wrote:
I presume that the appropriate fix at this point is to publish the TimeStamp class, which is currently in the SqueakMap code, to the 3.4b update stream. Any objections?
Weel we could use the alternative approach and remove the dependency on said class; what effect would that have on the usefulness of the uuid value?
tim
I fear I have lost the context of this discussion; but if the issue can be cleanly fixed by publishing a class from SqueakMap, which is quite likely going to land in the distribution image anyway, and that fix is cleaner/better than mine (which is quite possible, because my fix squarely sits in the 'quick hack' category), I'm all for it.
Scott Wallace wrote:
Cees, Doug, Tim, and all,
Gentlemen, how do you wish to proceed on this?
Thanks,
-- Scott
At 9:50 AM -0800 12/24/02, Tim Rowledge wrote:
In message <p05100303ba2925931ccd@[10.0.1.7]> Scott Wallace scott.wallace@squeakland.org wrote:
I presume that the appropriate fix at this point is to publish the TimeStamp class, which is currently in the SqueakMap code, to the 3.4b update stream. Any objections?
Weel we could use the alternative approach and remove the dependency on said class; what effect would that have on the usefulness of the uuid value?
tim tim
(Sorry about not responding recently on this (or on the other recent fixes), but I am now back from xmas break. I will post this afternoon with a quick summary of the few other remaining issues/fixes for 3.4beta before it goes gamma.)
Cees de Groot wrote:
I fear I have lost the context of this discussion; but if the issue can be cleanly fixed by publishing a class from SqueakMap, which is quite likely going to land in the distribution image anyway, and that fix is cleaner/better than mine (which is quite possible, because my fix squarely sits in the 'quick hack' category), I'm all for it.
Actually, the class from SqueakMap (the TimeStamp class) is not currently in the image and is required by your fix, it doesn't replace or otherwise improve your fix. :-)
Okay, after poking around with 5150UUID-fix and Time and TimeStamp, it looks like we can remove the dependency on TimeStamp (as Tim suggested) and keep the same behavior by simply replacing "TimeStamp current asSeconds" with "Time totalSeconds" in UUIDGenerator>>makeSeed. So, we should probably just do that.
I guess there was also the problem with #makeUnixSeed trying to access /dev/urandom on non-Unix machines, which Andreas pointed out. But Tim's fix to this (posted 12/20) looks reasonable, and it works for me on Windows.
Also, I'm a little suspicious of #makeSeedFromSound. Are we sure that this will always generate a random number for all platforms, even if the machine has no sound input/microphone? I tried unplugging my microphone on my Windows machine and it did seem to generate a different number each time, so that's good. Still, using a Date/Time/millisecond-based seed seems more reliable to me.
Göran, I was wondering if you were seeing a problem with the millisecond-based seed and you wanted this fix for that reason, or if you just wanted this fix because it flushes the default generator on startup (which I agree is a good thing). If the latter, maybe we should get rid of #makeSeedFromSound just to be safe?
(For purposes of this discussion, remember that we are talking about a very short-term/simple fix for the upcoming 3.4 release, not a more general UUID solution for 3.5alpha and beyond.)
- Doug
Scott Wallace wrote:
Cees, Doug, Tim, and all,
Gentlemen, how do you wish to proceed on this?
Thanks,
-- Scott
At 9:50 AM -0800 12/24/02, Tim Rowledge wrote:
In message <p05100303ba2925931ccd@[10.0.1.7]> Scott Wallace scott.wallace@squeakland.org wrote:
I presume that the appropriate fix at this point is to publish the TimeStamp class, which is currently in the SqueakMap code, to the 3.4b update stream. Any objections?
Weel we could use the alternative approach and remove the dependency on said class; what effect would that have on the usefulness of the uuid value?
tim tim
On Thursday, January 2, 2003, at 12:13 PM, Tim Rowledge wrote:
It doesn't seem to me that this is an issue worth spending huge cycles on _right now_ so I'll suggest going with the inclusion of TimeStamp which appears to be a reasonably small and innocuous class.
Six minutes later, Doug Way wrote a contrasting view:
Okay, after poking around with 5150UUID-fix and Time and TimeStamp, it looks like we can remove the dependency on TimeStamp (as Tim suggested) and keep the same behavior by simply replacing "TimeStamp current asSeconds" with "Time totalSeconds" in UUIDGenerator>>makeSeed. So, we should probably just do that.
I'd have to agree with Doug here, for two reasons:
1) Let's not forget the principle that the image should get smaller, not larger. Sure, this is a small and innocuous class, but we're just going to have to rip it out again later. And we definitely shouldn't be adding dependencies on it to other parts of the image.
2) Adding TimeStamp isn't quite as innocuous as it seems. Having this functionality widely available is probably a good idea, but there are some issues that ought to be thrashed out. What about ANSI compatibility? Should we use DateAndTime instead? What about Todd's version of TimeStamp that works with the TimeZone stuff that Dave Lewis wrote? Should that be added instead? Should it be part of some kind of Time package? Will including this class in the base image break the Comanche package?
Cheers,
Colin
Colin Putney wrote:
I'd have to agree with Doug here, for two reasons:
- Let's not forget the principle that the image should get smaller,
not larger. Sure, this is a small and innocuous class, but we're just going to have to rip it out again later. And we definitely shouldn't be adding dependencies on it to other parts of the image.
Yes, the base image should get smaller over time, but we should be careful not to use that goal as the sole deciding factor in whether or not to add dependencies. Dependencies should be based on what makes sense for the code in question. If things hang together better by having UUID depend on TimeStamp, then add the dependency and remove UUID from the base image (along with anything else that depends on UUID).
However, in this case, I do agree that the code should be changed to "Time totalSeconds" and the dependency on TimeStamp dropped.
- Stephen
Mm not to loose track of this issue too
Who ever is correcting the UUIDGenerator>>makeUnixSeed code might want to revisit that to understand why this walkback occurs.
Error: Improper store into indexable object 21 December 2002 3:38:14 pm
VM: unix - Squeak3.4beta of '1 December 2002' [latest update: #5138] Image: Squeak3.4beta [latest update: #5156]
LargePositiveInteger(Object)>>error: Receiver: 713706752 Arguments and temporary variables: aString: 'Improper store into indexable object' Receiver's instance variables: 713706752 LargePositiveInteger(Object)>>errorImproperStore Receiver: 713706752 Arguments and temporary variables:
Receiver's instance variables: 713706752 LargePositiveInteger(Object)>>at:put: Receiver: 713706752 Arguments and temporary variables: index: 1 value: nil Receiver's instance variables: 713706752 LargePositiveInteger>>digitAt:put: Receiver: 713706752 Arguments and temporary variables: index: 1 value: nil Receiver's instance variables: 713706752
--- The full stack --- LargePositiveInteger(Object)>>error: LargePositiveInteger(Object)>>errorImproperStore LargePositiveInteger(Object)>>at:put: LargePositiveInteger>>digitAt:put: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Integer class>>byte1:byte2:byte3:byte4: [] in UUIDGenerator>>makeUnixSeed BlockContext>>ifCurtailed: UUIDGenerator>>makeUnixSeed UUIDGenerator>>makeSeed UUIDGenerator>>setupRandom
On Saturday, December 21, 2002, at 12:44 PM, Phil Hargett wrote:
Okay, strangely, when I repeat just the TestUUIDPrimitives test suite but itself, I achieve different results on different runs. After a few repetitions (where I did see all succeed), I did see TestUUIDPrimitives>>testDuplicationsKinda fail 2 out of 3 times. I'm attaching the stack trace that I filed out from a debugger showing the error.
Hope this helps!
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com is claimed by the authorities to have written:
Mm not to loose track of this issue too
Who ever is correcting the UUIDGenerator>>makeUnixSeed code might want to revisit that to understand why this walkback occurs.
Error: Improper store into indexable object 21 December 2002 3:38:14 pm
I'm _fairly_ sure that this is the problem fixed by my patch that make the makeUnixSeed method use an Exception instread of ifCurtailed:
tim
Colin Putney cputney@whistler.com is claimed by the authorities to have written:
On Thursday, January 2, 2003, at 12:13 PM, Tim Rowledge wrote:
It doesn't seem to me that this is an issue worth spending huge cycles on _right now_ so I'll suggest going with the inclusion of TimeStamp which appears to be a reasonably small and innocuous class.
Six minutes later, Doug Way wrote a contrasting view:
Okay, after poking around with 5150UUID-fix and Time and TimeStamp, it looks like we can remove the dependency on TimeStamp (as Tim suggested) and keep the same behavior by simply replacing "TimeStamp current asSeconds" with "Time totalSeconds" in UUIDGenerator>>makeSeed. So, we should probably just do that.
I'd have to agree with Doug here, for two reasons:
If Time totalSeconds is considered to be an adequate value for this purpose then most definitely let's do it that way.
tim
Like Cees, I've completely lost track of this issue over the holiday. I've just spent far too long trying to track down relevant emails from the various email archives and got nowhere. The only bit I could find was my suggested change to the method refering to /dev/urandom so that it used an exception correctly.
It doesn't seem to me that this is an issue worth spending huge cycles on _right now_ so I'll suggest going with the inclusion of TimeStamp which appears to be a reasonably small and innocuous class.
tim
squeakfoundation@lists.squeakfoundation.org
-
Cees de Groot -
Colin Putney -
Doug Way -
John M McIntosh -
Scott Wallace -
Stephen Pair -
Tim Rowledge