Why not ChronologyTests?

2016-02-18 2:33 GMT+01:00 David T. Lewis <lewis at mail.msen.com>:

> I would like to move Chronology from 'Kernel-Chronology' to a new package
> called 'Chronology', and move 'KernelTests-Chronology' to a new package
> called 'Tests-Chronology'.
>
> Rationale:
>
> - Chronology is a large package that is functionally separable from the
> rest of the things in Kernel.
>
> - I have a UTC based variation of Chronology that addresses a number of
> issues that I think may be of long term benefit, and that prevent the kinds
> of issues that we are currently seeing in trunk. I would like to offer this
> for review in the inbox, but that is not practical with the current
> packaging.
>
> Would anyone object to this change to package structure?
>
> Thanks,
> Dave
>
>
> On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:
> > We can see the primitives involved with this do it -
> >  {SystemNavigation default browseMessageList: #(
> > 'Time class primMicrosecondClock 117'
> > 'Time class primMillisecondClock 135???
> > 'Time class eventMillisecondClock 135???
> > 'Time class primPosixMicrosecondClockWithOffset 117???
> > 'Time class primUTCMicrosecondClock 240???
> > 'Time class localMicrosecondClock 241???
> > 'Time class utcMicrosecondClock 240???
> > 'Time class primSecondsClock 137???
> > 'Time class primMillisecondClockMask 117???
> > 'Time class primLocalMicrosecondClock 241') name: 'time prims???}
> >
> > a) primMicrosecondClock is not sent in a 5.0 image and seems to only be
> implemented in a plain interpreter VM.
> > b) primMillisecondClock/135 is not sent in a 5.0 image
> > c) eventMillisecondClock/135 is used for the faked-up events required
> for double-click handling
> > d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> > e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec
> value in raw
> > f) localMicrosecondClock/241 is used in 5.0 in particular from Time now
> (as per the ClockMorph)
> > g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type
> cases
> > h) primSecondsClock/137 isn???t used in 5.0
> > i) primMillisecondClockMask isn???t used in 5.0
> > j) primLocalMicrosecondClock/241 isn???t used in 5.0
> >
> > So we have quite a collection of mixedup terminology and unused methods
> to clear up!
> >
> > Looking at it from the prims point of view -
> >
> > 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.
> >
> > 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.
> > Prim 241 is used by Time now etc and includes the TZ offset, which is
> why Time now returns correct wall-clock time.
> >
> > 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.
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > 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?
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160218/ddec1c09/attachment.htm