Name: VMMaker.oscog-eem.2800 Author: eem Time: 6 September 2020, 4:58:47.598839 pm UUID: a6116113-df13-435d-968d-e9b111676754 Ancestors: VMMaker.oscog-eem.2799 Seriously ?!??! ;-) _,,,^..^,,,_ best, Eliot |
Hi Eliot,
The Monticello history of the Chronology package says that those microseconds were introduced by Kernel-eem.970: > Changes to Time and Delay prior to changing over to the utc microsecond clock and its use in delay scheduling. The "offending" change is probably the following: Item was changed: ----- Method: Time class>>now (in category 'ansi protocol') ----- now "Answer a Time representing the time right now - this is a 24 hour clock." + | localUsecs localUsecsToday | + localUsecs := self localMicrosecondClock. + localUsecsToday := localUsecs \\ MicrosecondsInDay. + ^ self + seconds: localUsecsToday // 1000000 + nanoSeconds: localUsecsToday \\ 1000000 * 1000! - - | ms | - - ms := self milliSecondsSinceMidnight. - - ^ self seconds: (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000 - - - ! And that happened more than four and a half years ago. Levente On Sun, 6 Sep 2020, Eliot Miranda wrote: > Name: VMMaker.oscog-eem.2800 > Author: eem > Time: 6 September 2020, 4:58:47.598839 pm > UUID: a6116113-df13-435d-968d-e9b111676754 > Ancestors: VMMaker.oscog-eem.2799 > > Seriously ?!??! ;-) > _,,,^..^,,,_ > best, Eliot > > |
A crude but effective fix is in the inbox in Monticello-dtl.727
Dave On Mon, Sep 07, 2020 at 03:56:19AM +0200, Levente Uzonyi wrote: > Hi Eliot, > > > The Monticello history of the Chronology package says that > those microseconds were introduced by Kernel-eem.970: > > >Changes to Time and Delay prior to changing over to the utc microsecond > >clock and its use in delay scheduling. > > The "offending" change is probably the following: > > Item was changed: > ----- Method: Time class>>now (in category 'ansi protocol') ----- > now > "Answer a Time representing the time right now - this is a 24 hour > clock." > + | localUsecs localUsecsToday | > + localUsecs := self localMicrosecondClock. > + localUsecsToday := localUsecs \\ MicrosecondsInDay. > + ^ self > + seconds: localUsecsToday // 1000000 > + nanoSeconds: localUsecsToday \\ 1000000 * 1000! > - > - | ms | > - > - ms := self milliSecondsSinceMidnight. > - > - ^ self seconds: (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000 > - > - > - ! > > And that happened more than four and a half years ago. > > > Levente > > On Sun, 6 Sep 2020, Eliot Miranda wrote: > > >Name: VMMaker.oscog-eem.2800 > >Author: eem > >Time: 6 September 2020, 4:58:47.598839 pm > >UUID: a6116113-df13-435d-968d-e9b111676754 > >Ancestors: VMMaker.oscog-eem.2799 > > > >Seriously ?!??! ;-) > >_,,,^..^,,,_ > >best,??Eliot > > > > > |
Well, maybe not so effective after all, given that the commit notice
for Monticello-dtl.727 on the mailing list still exhibits the same problem. Dave On Mon, Sep 07, 2020 at 07:52:02PM -0400, David T. Lewis wrote: > A crude but effective fix is in the inbox in Monticello-dtl.727 > > Dave > > On Mon, Sep 07, 2020 at 03:56:19AM +0200, Levente Uzonyi wrote: > > Hi Eliot, > > > > > > The Monticello history of the Chronology package says that > > those microseconds were introduced by Kernel-eem.970: > > > > >Changes to Time and Delay prior to changing over to the utc microsecond > > >clock and its use in delay scheduling. > > > > The "offending" change is probably the following: > > > > Item was changed: > > ----- Method: Time class>>now (in category 'ansi protocol') ----- > > now > > "Answer a Time representing the time right now - this is a 24 hour > > clock." > > + | localUsecs localUsecsToday | > > + localUsecs := self localMicrosecondClock. > > + localUsecsToday := localUsecs \\ MicrosecondsInDay. > > + ^ self > > + seconds: localUsecsToday // 1000000 > > + nanoSeconds: localUsecsToday \\ 1000000 * 1000! > > - > > - | ms | > > - > > - ms := self milliSecondsSinceMidnight. > > - > > - ^ self seconds: (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000 > > - > > - > > - ! > > > > And that happened more than four and a half years ago. > > > > > > Levente > > > > On Sun, 6 Sep 2020, Eliot Miranda wrote: > > > > >Name: VMMaker.oscog-eem.2800 > > >Author: eem > > >Time: 6 September 2020, 4:58:47.598839 pm > > >UUID: a6116113-df13-435d-968d-e9b111676754 > > >Ancestors: VMMaker.oscog-eem.2799 > > > > > >Seriously ?!??! ;-) > > >_,,,^..^,,,_ > > >best,??Eliot > > > > > > > > > > > |
> Well, maybe not so effective after all, given that the commit notice for Monticello-dtl.727 on the mailing list still exhibits the same problem. Isn't that notice generated by some servers that depend on a Trunk image rather than the uploaded inbox version itself?
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Dienstag, 8. September 2020 01:59:00 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Recent Monticello Timestamps Well, maybe not so effective after all, given that the commit notice
for Monticello-dtl.727 on the mailing list still exhibits the same problem. Dave On Mon, Sep 07, 2020 at 07:52:02PM -0400, David T. Lewis wrote: > A crude but effective fix is in the inbox in Monticello-dtl.727 > > Dave > > On Mon, Sep 07, 2020 at 03:56:19AM +0200, Levente Uzonyi wrote: > > Hi Eliot, > > > > > > The Monticello history of the Chronology package says that > > those microseconds were introduced by Kernel-eem.970: > > > > >Changes to Time and Delay prior to changing over to the utc microsecond > > >clock and its use in delay scheduling. > > > > The "offending" change is probably the following: > > > > Item was changed: > > ----- Method: Time class>>now (in category 'ansi protocol') ----- > > now > > "Answer a Time representing the time right now - this is a 24 hour > > clock." > > + | localUsecs localUsecsToday | > > + localUsecs := self localMicrosecondClock. > > + localUsecsToday := localUsecs \\ MicrosecondsInDay. > > + ^ self > > + seconds: localUsecsToday // 1000000 > > + nanoSeconds: localUsecsToday \\ 1000000 * 1000! > > - > > - | ms | > > - > > - ms := self milliSecondsSinceMidnight. > > - > > - ^ self seconds: (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000 > > - > > - > > - ! > > > > And that happened more than four and a half years ago. > > > > > > Levente > > > > On Sun, 6 Sep 2020, Eliot Miranda wrote: > > > > >Name: VMMaker.oscog-eem.2800 > > >Author: eem > > >Time: 6 September 2020, 4:58:47.598839 pm > > >UUID: a6116113-df13-435d-968d-e9b111676754 > > >Ancestors: VMMaker.oscog-eem.2799 > > > > > >Seriously ?!??! ;-) > > >_,,,^..^,,,_ > > >best,??Eliot > > > > > > > > > > >
Carpe Squeak!
|
On Tue, Sep 08, 2020 at 05:57:21AM +0000, Thiede, Christoph wrote:
> > Well, maybe not so effective after all, given that the commit notice for Monticello-dtl.727 on the mailing list still exhibits the same problem. > > Isn't that notice generated by some servers that depend on a Trunk image rather than the uploaded inbox version itself? > Yes, that is the reason. Dave > Best, > Christoph > > ________________________________ > Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]> > Gesendet: Dienstag, 8. September 2020 01:59:00 > An: The general-purpose Squeak developers list > Betreff: Re: [squeak-dev] Recent Monticello Timestamps > > Well, maybe not so effective after all, given that the commit notice > for Monticello-dtl.727 on the mailing list still exhibits the same problem. > > Dave > > On Mon, Sep 07, 2020 at 07:52:02PM -0400, David T. Lewis wrote: > > A crude but effective fix is in the inbox in Monticello-dtl.727 > > > > Dave > > > > On Mon, Sep 07, 2020 at 03:56:19AM +0200, Levente Uzonyi wrote: > > > Hi Eliot, > > > > > > > > > The Monticello history of the Chronology package says that > > > those microseconds were introduced by Kernel-eem.970: > > > > > > >Changes to Time and Delay prior to changing over to the utc microsecond > > > >clock and its use in delay scheduling. > > > > > > The "offending" change is probably the following: > > > > > > Item was changed: > > > ----- Method: Time class>>now (in category 'ansi protocol') ----- > > > now > > > "Answer a Time representing the time right now - this is a 24 hour > > > clock." > > > + | localUsecs localUsecsToday | > > > + localUsecs := self localMicrosecondClock. > > > + localUsecsToday := localUsecs \\ MicrosecondsInDay. > > > + ^ self > > > + seconds: localUsecsToday // 1000000 > > > + nanoSeconds: localUsecsToday \\ 1000000 * 1000! > > > - > > > - | ms | > > > - > > > - ms := self milliSecondsSinceMidnight. > > > - > > > - ^ self seconds: (ms // 1000) nanoSeconds: (ms \\ 1000) * 1000000 > > > - > > > - > > > - ! > > > > > > And that happened more than four and a half years ago. > > > > > > > > > Levente > > > > > > On Sun, 6 Sep 2020, Eliot Miranda wrote: > > > > > > >Name: VMMaker.oscog-eem.2800 > > > >Author: eem > > > >Time: 6 September 2020, 4:58:47.598839 pm > > > >UUID: a6116113-df13-435d-968d-e9b111676754 > > > >Ancestors: VMMaker.oscog-eem.2799 > > > > > > > >Seriously ?!??! ;-) > > > >_,,,^..^,,,_ > > > >best,??Eliot > > > > > > > > > > > > > > > > > > > |
Free forum by Nabble | Edit this page |