[squeak-dev] Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

David T. Lewis lewis at mail.msen.com
Thu Feb 18 13:34:46 UTC 2016


On Thu, Feb 18, 2016 at 12:18:18PM +0100, Nicolas Cellier wrote:
> Why not ChronologyTests?

Agreed, that would be better.

Dave

> 
> 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?
> > >
> > >
> >
> >

> 



More information about the Squeak-dev mailing list