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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von David T. Lewis lewis@mail.msen.com 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
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von David T. Lewis lewis@mail.msen.com 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
squeak-dev@lists.squeakfoundation.org