Recent Monticello Timestamps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Recent Monticello Timestamps

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Recent Monticello Timestamps

Levente Uzonyi
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Recent Monticello Timestamps

David T. Lewis
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
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: Recent Monticello Timestamps

David T. Lewis
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
> > >
> > >
>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Recent Monticello Timestamps

Christoph Thiede

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!
Reply | Threaded
Open this post in threaded view
|

Re: Recent Monticello Timestamps

David T. Lewis
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
> > > >
> > > >
> >
> > >
> >
> >
>

>