<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> This trades the "posix" nomenclature in the API for #microsecondClockValue. "Posix" is a private matter to Chronology's implementation that should not be exposed in the API.<br>
<br>
"Posix" has been there since 2016: Time class >> posixMicrosecondClockWithOffset:.<br></blockquote><div><br></div><div>We should work to remove them for the reason stated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Everyone gets an idea what kind of timestamp a method with posix in its name will return.<br></blockquote><div><br></div><div>What are the possible "kinds"?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The same does not apply to #microsecondClockValue, does it?<br></blockquote><div><br></div><div>If "kind" refers to a timezone indication, then yes, it does (but "posix" doesn't). Again, I ask you to zoom out and look at the API as a whole, instead of only individual methods out-of-context of the broader "language" of the API.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In my opinion exposing "Posix" has benefits.<br></blockquote><div><br></div><div>It sounds like you confused epoch with with timezone indication. I explained why "posix" is negative, but you ignored it. Isn't encapsulation important? It seems you value a tight API with only as many concepts as necessary. Why do you feel the API to to support two different epochs?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> =============== Diff against Chronology-Core-ul.54 ===============<br>
><br>
> Item was added:<br>
> + ----- Method: DateAndTime class>>microsecondClockValue (in category 'smalltalk-80') -----<br>
> + microsecondClockValue<br>
> + ^ self clock microsecondClockValue!<br>
<br>
Why do we need this here? </blockquote><div><br></div><div><div>Because you said:</div><div> __________<br></div><div> It is unfortunate that<br> - #utcMicrosecondsClock is implemented as a class side method of Time,<br> because it's unrelated to Time (renaming it to #microsecondsClock would<br> not help with that)<br></div><div> ___________</div><div><br></div><div>To which I agree. The proper delegate of this responsibility is DateAndTime. But it can still delegate to private methods on Time, so we could keep these on DateAndTime and move the ones on Time out of the public-API to private.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Especially in that category. This is clearly <br>
not part of any smalltalk-80 protocol.<br></blockquote><div><br></div><div>The category doesn't really matter, may we focus on the UX question please?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
DateAndTime class >> ##millisecondClockValue has no senders, so we should <br>
remove that method instead of adding another unused one.<br></blockquote><div><br></div><div>That one's been there since 2006! :-p (sorry, couldn't resist...)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Item was added:<br>
> + ----- Method: DateAndTime class>>utcMicroseconds: (in category 'instance creation') -----<br>
> + utcMicroseconds: microsecondClockValue<br>
> + "Instantiate a DateAndTime in UTC from the value of my #microsecondClockValue."<br>
> + ^ super new<br>
> + utcMicroseconds: microsecondClockValue<br>
> + offset: 0!<br>
><br>
> Item was changed:<br>
> ----- Method: Time class>>estimateHighResClockTicksPerMillisecond (in category 'clock') -----<br>
> estimateHighResClockTicksPerMillisecond<br>
><br>
> | t0 t1 t2 t3 |<br>
><br>
> "Count the ticks ellapsed during a 10ms busy loop"<br>
> + t0 := Time microsecondClockValue + 200.<br>
> + [Time microsecondClockValue >= t0] whileFalse.<br>
> - t0 := Time utcMicrosecondClock + 200.<br>
> - [Time utcMicrosecondClock >= t0] whileFalse.<br>
> t1 := self highResClock.<br>
> + [Time microsecondClockValue >= (t0 + 10000)] whileFalse.<br>
> + t1 := self highResClock - t1 * 1000 // (Time microsecondClockValue - t0).<br>
> - [Time utcMicrosecondClock >= (t0 + 10000)] whileFalse.<br>
> - t1 := self highResClock - t1 * 1000 // (Time utcMicrosecondClock - t0).<br>
<br>
The method uses the primitive directly to make the measurements as <br>
accurate as possible. This change would make them less accurate.<br></blockquote><div><br></div><div>How does it know it's using the primitive directly? Is it depending on a known implementation and expecting it never to change?</div><div><br></div><div>If it wants / needs the efficiency of primitive, it should say so by calling "primSomethingSomething" then...</div><div><br></div><div>How many other primitive accessing methods are in the system without the "prim" prefix?</div><div><br></div><div>How cool it would be if Squeak users could simply type "prim" in a Message Names browser and instantly see just the methods that make up the "seam" between the image and the VM? This user would love that!</div><div><br></div><div>Instead, #utcMicrosecondClock conceals that's its a primitive accessor, while being incompatible and unusable with any other API in the image. It's actually quite horrible..</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> "Count the ticks ellapsed during a 20ms busy loop"<br>
> + t0 := Time microsecondClockValue + 200.<br>
> + [Time microsecondClockValue >= t0] whileFalse.<br>
> - t0 := Time utcMicrosecondClock + 200.<br>
> - [Time utcMicrosecondClock >= t0] whileFalse.<br>
> t2 := self highResClock.<br>
> + [Time microsecondClockValue >= (t0 + 20000)] whileFalse.<br>
> + t2 := self highResClock - t2 * 1000 // (Time microsecondClockValue - t0).<br>
> - [Time utcMicrosecondClock >= (t0 + 20000)] whileFalse.<br>
> - t2 := self highResClock - t2 * 1000 // (Time utcMicrosecondClock - t0).<br>
><br>
> "Count the ticks ellapsed during a 30ms busy loop"<br>
> + t0 := Time microsecondClockValue + 200.<br>
> + [Time microsecondClockValue >= t0] whileFalse.<br>
> - t0 := Time utcMicrosecondClock + 200.<br>
> - [Time utcMicrosecondClock >= t0] whileFalse.<br>
> t3 := self highResClock.<br>
> + [Time microsecondClockValue >= (t0 + 30000)] whileFalse.<br>
> + t3 := self highResClock - t3 * 1000 // (Time microsecondClockValue - t0).<br>
> - [Time utcMicrosecondClock >= (t0 + 30000)] whileFalse.<br>
> - t3 := self highResClock - t3 * 1000 // (Time utcMicrosecondClock - t0).<br>
><br>
> "Take the median of the 3 estimates as the best"<br>
> ^ t1 <= t2<br>
> ifTrue: [t2 <= t3<br>
> ifTrue: [t2]<br>
> ifFalse: [t1 <= t3<br>
> ifTrue: [t3]<br>
> ifFalse: [t1]]]<br>
> ifFalse: [t1 <= t3<br>
> ifTrue: [t1]<br>
> ifFalse: [t2 <= t3<br>
> ifTrue: [t3]<br>
> ifFalse: [t2]]]!<br>
><br>
> Item was added:<br>
> + ----- Method: Time class>>microsecondClockValue (in category 'general inquiries') -----<br>
> + microsecondClockValue<br>
> + "Answer the value of the microsecond clock, the number of microseconds elapsed since 1/1/1901 @ 00:00:00."<br>
<br>
Wrong date there.<br></blockquote><div><br></div><div>This is just a draft for discussion. I'm looking for basic consensus before investing a bunch of time...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> + ^ self utcMicrosecondClock - MicrosecondsBetweenPosixEpochAndSqueakEpoch!<br>
><br>
> Item was changed:<br>
> ----- Method: Time class>>microsecondsToRun: (in category 'general inquiries') -----<br>
> microsecondsToRun: timedBlock<br>
> "Answer the number of microseconds timedBlock takes to return its value."<br>
><br>
> | startUsecs |<br>
> (self useHighResClockForTiming and: [self highResClock ~= 0])<br>
> ifTrue: [ ^(self nanosecondsToRunHighRes: timedBlock) + 500 // 1000].<br>
> + startUsecs := self microsecondClockValue.<br>
> - startUsecs := self utcMicrosecondClock.<br>
> timedBlock value.<br>
> + ^self microsecondClockValue - startUsecs!<br>
> - ^self utcMicrosecondClock - startUsecs!<br>
<br>
Again, decreases the measurement's accuracy.<br></blockquote><div><br></div><div>Perhaps, but we can also acknowledge this is yet another place where the value itself didn't matter, just the delta. So, deprecation is not as disruptive as you thought.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Item was changed:<br>
> ----- Method: Time class>>millisecondClockValue (in category 'general inquiries') -----<br>
> millisecondClockValue<br>
> "Answer the value of the millisecond clock."<br>
> + ^self microsecondClockValue // 1000!<br>
> -<br>
> - ^self utcMicrosecondClock // 1000!<br>
<br>
After loading, this change would break code relying on previous results of <br>
this method.<br></blockquote><div><br></div><div></div><div>There is no such code and, if there was, it was already broken because this has never been a reliable value. It even used to roll over, remember?</div><div><br></div><div>That's why nothing broke when #utcMicrosecondClock went in and changed it...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Item was changed:<br>
> ----- Method: Time class>>nanosecondsToRun: (in category 'general inquiries') -----<br>
> nanosecondsToRun: timedBlock<br>
> "Answer the number of nanoseconds timedBlock takes to return its value.<br>
> Use high resolution clock if available and preferred."<br>
><br>
> | startUsecs |<br>
> (self useHighResClockForTiming and: [self highResClock ~= 0])<br>
> ifTrue: [ ^(self nanosecondsToRunHighRes: timedBlock)].<br>
> "Fallback to microseconds clock"<br>
> + startUsecs := self microsecondClockValue.<br>
> - startUsecs := self utcMicrosecondClock.<br>
> timedBlock value.<br>
> + ^self microsecondClockValue - startUsecs * 1000!<br>
> - ^self utcMicrosecondClock - startUsecs * 1000!<br>
<br>
Accuracy again.<br></blockquote><div><br></div><div>Really, this is bad code then to be relying on a method's implementation not named "prim" to remain a primitive, Intention-revealing code to achieve highest accuracy is achieved by writing "primUtcMicrosecondClock".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Item was removed:<br>
> - ----- Method: Time class>>posixUtcMicrosecondClock (in category 'clock') -----<br>
> - posixUtcMicrosecondClock<br>
> - "Answer the UTC microseconds since the POSIX epoch (January 1st 1970 00:00:00 UTC)."<br>
> -<br>
> - ^self utcMicrosecondClock - MicrosecondsBetweenPosixEpochAndSqueakEpoch!<br>
><br>
> Item was changed:<br>
> + ----- Method: Time class>>utcMicrosecondClock (in category 'private') -----<br>
> - ----- Method: Time class>>utcMicrosecondClock (in category 'clock') -----<br>
<br>
Does this mean that I have to reimplement the primitive in my external <br>
packages from now on?<br></blockquote><div><br></div><div>No.</div><div><br></div><div> - Chris </div></div></div>