Hi all,


aside from the current senders of #eventMillisecondClock in the Trunk image, I wonder whether we would like to keep this possibility open in general. For instance, you could use this value to compare the time of events from different VM- and other image-based sources such as incoming network requests ... This is just a vague guess, what do you think?


With regard to existing dependencies, if we don't really need this selector, we could surely deprecate it and write a fallback to use primitive 240 instead, couldn't we?


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Chris Muller <asqueaker at gmail.com>
Gesendet: Samstag, 12. September 2020 02:35:44
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Time>>eventMillisecondClock and event timestamps

I don't know the answer to those questions, but in checking its
senders in my image, I did notice a couple by RFB-Server, which is a
pretty important external package.  Whatever answer is arrived at
would be nice if it involves keeping RFB in a functioning state for
the community (and hopefully eventually included in the base image).

Best,
  Chris

On Fri, Sep 11, 2020 at 4:54 PM David T. Lewis <lewis at mail.msen.com> wrote:
>
> Christoph has fixed a bug in event timestamps on the Windows VM. Background
> is at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/518.
>
> This led us to a question about Time>>eventMillisecondClock. To summarize:
>
> Events are delivered to the image by the VM, and processed in the image
> as e.g. MorphicEvent. Each event has a timeStamp that is an integer number
> of milliseconds since some arbitrary starting point. The actual time basis
> (starting point) of those timestamps is not important, just as long as they
> are consistent.
>
> In the Windows VM, the event timeStamps are derived from the Windows event
> system, and are in milliseconds relative to the time that the Windows system
> was started. Other VMs obtain their event time stamps differently, but
> normally through ioMSecs() in the VM.
>
> Thus, for any VM, the events must have internally consistent time stamps,
> but the timestamps may or may not be aligned with ioMSecs() in the VM.
>
> All good so far, but then Christoph pointed out this in the image:
>
> Time>>eventMillisecondClock
>         "In order to make certain event handling code work (cf MouseEvent>asMouseMove) we need access
>         to the tick kept by ioMSecs() "
>         "Time eventMillisecondClock"
>         <primitive: 135>
>         ^0
>
> This is being used in multiple places in the image, and it explicitly
> assumes that event timestamps are relative to ioMSecs() in the VM which
> is not the case on Windows.
>
> This leads me to ask three questions:
>
> 1) Does #eventMillisecondClock need to exist? It looks like it might be
> a kludge, if so could we make it go away?
>
> 2) If the eventMillisecondClock method does need to exist, should it be changed
> to retrieve a millisecond value that is aligned with that of the events?
>
> 3) If not 2) then do we need to change the Windows VM to somehow use event
> timestamps that match eventMillisecondClock?
>
> Dave
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200912/3bb291c9/attachment.html>