<div dir="ltr">Why not ChronologyTests?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-18 2:33 GMT+01:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to move Chronology from 'Kernel-Chronology' to a new package<br>
called 'Chronology', and move 'KernelTests-Chronology' to a new package<br>
called 'Tests-Chronology'.<br>
<br>
Rationale:<br>
<br>
- Chronology is a large package that is functionally separable from the<br>
rest of the things in Kernel.<br>
<br>
- I have a UTC based variation of Chronology that addresses a number of<br>
issues that I think may be of long term benefit, and that prevent the kinds<br>
of issues that we are currently seeing in trunk. I would like to offer this<br>
for review in the inbox, but that is not practical with the current<br>
packaging.<br>
<br>
Would anyone object to this change to package structure?<br>
<br>
Thanks,<br>
Dave<br>
<br>
<br>
On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:<br>
> We can see the primitives involved with this do it -<br>
> {SystemNavigation default browseMessageList: #(<br>
> 'Time class primMicrosecondClock 117'<br>
> 'Time class primMillisecondClock 135???<br>
> 'Time class eventMillisecondClock 135???<br>
> 'Time class primPosixMicrosecondClockWithOffset 117???<br>
> 'Time class primUTCMicrosecondClock 240???<br>
> 'Time class localMicrosecondClock 241???<br>
> 'Time class utcMicrosecondClock 240???<br>
> 'Time class primSecondsClock 137???<br>
> 'Time class primMillisecondClockMask 117???<br>
> 'Time class primLocalMicrosecondClock 241') name: 'time prims???}<br>
><br>
> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.<br>
> b) primMillisecondClock/135 is not sent in a 5.0 image<br>
> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling<br>
> d) primPosixMicrosecondClockWithOffset is not sent in 5.0<br>
> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw<br>
> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)<br>
> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases<br>
> h) primSecondsClock/137 isn???t used in 5.0<br>
> i) primMillisecondClockMask isn???t used in 5.0<br>
> j) primLocalMicrosecondClock/241 isn???t used in 5.0<br>
><br>
> So we have quite a collection of mixedup terminology and unused methods to clear up!<br>
><br>
> Looking at it from the prims point of view -<br>
><br>
> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.<br>
><br>
> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.<br>
> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.<br>
><br>
> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.<br>
><br>
> tim<br>
<span class="HOEnZb"><font color="#888888">> --<br>
> tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
> Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood?<br>
><br>
><br>
<br>
</font></span></blockquote></div><br></div>