OTOH, don't borrow trouble.

Cheers,
Bob

On 8/7/13 12:28 PM, Frank Shearar wrote:
> At any rate my point is that Delays across image saves have caused
> Pharo people a reasonable amount of pain. If someone experiences pain,
> it can be worthwhile learning from the lessons of others.
>
> That is all.
>
> frank
>
> On 7 August 2013 17:13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> ... which is not what Igor was proposing there, and I agree with Eliot's objection to simply firing all delays at image startup time.
>>
>> Switching to wall-clock for all delays would have pretty much the same effect, since the typical time between image snapshot and startup is larger than the typical delay time.
>>
>> Delays being ultimately low-level objects I don't think wall-clock makes sense for them. You would need a calendar object for that, IMHO.
>>
>> - Bert -
>>
>> On 2013-08-07, at 17:52, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>>> Well, it's at least partially here:
>>> http://forum.world.st/A-matter-with-Delays-td4671239.html People there
>>> seem to be proposing what's in this thread: sometimes what you mean is
>>> "15 minutes from now, wall clock time, do this", and other times you
>>> want "15 minutes from now, 'logical time', do this". "Logical time"
>>> means image running time.
>>>
>>> Personally, I'm in the wall-clock-is-all-there-is camp, for what it's worth.
>>>
>>> frank
>>>
>>> On 7 August 2013 16:40, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> Err, no? I don't have time to follow all mailing lists, rather relying on kind people forwarding relevant discussions here :)
>>>>
>>>> - Bert -
>>>>
>>>> On 2013-08-07, at 17:36, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>
>>>>> Everyone here is aware of the enormous amount of traffic on the Pharo
>>>>> list about getting these kinds of Delay problems sorted out, right?
>>>>>
>>>>> frank
>>>>>
>>>>> On 7 August 2013 16:14, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>>> Yes, making Delays work accurately wrt wall-clock time would be more work
>>>>>> now that I think about it. This seems to be better handled in a higher-level
>>>>>> object.
>>>>>>
>>>>>> - Bert -
>>>>>>
>>>>>> On 2013-08-07, at 16:16, Bob Arning <arning315 at comcast.net> wrote:
>>>>>>
>>>>>> I was thinking about that, but I suspect there are use cases for both image
>>>>>> time and real-world time. Maybe something like
>>>>>>
>>>>>> (Delay until: someRealTime) wait
>>>>>>
>>>>>> would meet the need the current Delay does not.
>>>>>>
>>>>>> Cheers,
>>>>>> Bob
>>>>>>
>>>>>> On 8/7/13 9:54 AM, Bert Freudenberg wrote:
>>>>>>
>>>>>> That has to be one of the oldest bugs! It's been there forever. I just
>>>>>> committed that to trunk.
>>>>>>
>>>>>> There is still a problem though. Squeak's delays (with Bob's fix) are based
>>>>>> on image "running time". That is, if I have a 1 hour delay and snapshot the
>>>>>> image after 45 minutes, on the next day it will expire 15 minutes after
>>>>>> starting the image.
>>>>>>
>>>>>> But arguably a delay should really expire by the same wall-clock time as
>>>>>> when it was scheduled, even across snapshots. This is how it was handled in
>>>>>> Smalltalk-80. Here's the ST80 code:
>>>>>>
>>>>>> Delay>>preSnapshot
>>>>>> "convert from local millisecond clock to milliseconds since Jan. 1 1901"
>>>>>> pendingDelay _ resumptionTime - Time millisecondClockValue.
>>>>>> resumptionTime _ Time totalSeconds * 1000 + pendingDelay
>>>>>>
>>>>>> Delay>>postSnapshot
>>>>>> "convert from milliseconds since Jan. 1 1901 to local millisecond clock"
>>>>>> pendingDelay _ resumptionTime - (Time totalSeconds * 1000).
>>>>>> pendingDelay _ pendingDelay max: 0.
>>>>>> resumptionTime _ Time millisecondClockValue + pendingDelay
>>>>>>
>>>>>> Of course, we would have to use UTC nowadays but I still think
>>>>>> re-implementing this would be a good idea.
>>>>>>
>>>>>> In any case, the fix makes the Delay snapshotting behavior at least
>>>>>> predictable :)
>>>>>>
>>>>>> - Bert -
>>>>>>
>>>>>> On 2013-08-06, at 21:57, Bob Arning <arning315 at comcast.net> wrote:
>>>>>>
>>>>>> Well, this seems to fix it:
>>>>>>
>>>>>> 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 6 August 2013 at
>>>>>> 3:39:29 pm'!
>>>>>>
>>>>>> !Delay class methodsFor: 'snapshotting' stamp: 'raa 8/6/2013 15:22'!
>>>>>> restoreResumptionTimes
>>>>>>    "Private!! Restore the resumption times of all scheduled Delays after a
>>>>>> snapshot or clock roll-over. This method should be called only while the
>>>>>> AccessProtect semaphore is held."
>>>>>>
>>>>>>    | newBaseTime |
>>>>>>    newBaseTime := Time millisecondClockValue.
>>>>>>    SuspendedDelays do: [:d | d adjustResumptionTimeOldBase: 0 newBase:
>>>>>> newBaseTime].
>>>>>>    ActiveDelay == nil ifFalse: [
>>>>>>        ActiveDelay adjustResumptionTimeOldBase: 0 newBase: newBaseTime.
>>>>>>    ].
>>>>>>    ActiveDelayStartTime _ newBaseTime "<-----this"! !
>>>>>>
>>>>>> Cheers,
>>>>>> Bob
>>>>>>
>>>>>> On 8/6/13 3:27 PM, tim Rowledge wrote:
>>>>>>
>>>>>> Well the timer stuff has certainly been messed about with a lot since I last
>>>>>> had to dig into it, but it looks like it *ought* to work ok.
>>>>>>
>>>>>> The only likely culprit I can spot is some issue with adjusting the
>>>>>> resumption times after the restart, but that would require some problem with
>>>>>> the millisecond time prim.
>>>>>>
>>>>>>
>>>>>> tim
>>>>>> --
>>>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>>>> Strange OpCodes: YVR: Branch to Vancouver
>>>>
>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130807/c0569172/attachment.htm