<div dir="ltr">I stopped reading the Pharo list because there was *so* much traffic that I couldn't see my own email through it. And most of the traffic wasn't terribly interesting to me. Is there code we can (maybe modify and) use?<div>
<br></div><div style>I don't think there's anything wrong with forwarding an exigent discussion from that pharo list here, we just need an "exigency filter" who reads the Pharo list *nudge.* </div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 8:36 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Everyone here is aware of the enormous amount of traffic on the Pharo<br>
list about getting these kinds of Delay problems sorted out, right?<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 7 August 2013 16:14, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> Yes, making Delays work accurately wrt wall-clock time would be more work<br>
> now that I think about it. This seems to be better handled in a higher-level<br>
> object.<br>
><br>
> - Bert -<br>
><br>
> On 2013-08-07, at 16:16, Bob Arning <<a href="mailto:arning315@comcast.net">arning315@comcast.net</a>> wrote:<br>
><br>
> I was thinking about that, but I suspect there are use cases for both image<br>
> time and real-world time. Maybe something like<br>
><br>
> (Delay until: someRealTime) wait<br>
><br>
> would meet the need the current Delay does not.<br>
><br>
> Cheers,<br>
> Bob<br>
><br>
> On 8/7/13 9:54 AM, Bert Freudenberg wrote:<br>
><br>
> That has to be one of the oldest bugs! It's been there forever. I just<br>
> committed that to trunk.<br>
><br>
> There is still a problem though. Squeak's delays (with Bob's fix) are based<br>
> on image "running time". That is, if I have a 1 hour delay and snapshot the<br>
> image after 45 minutes, on the next day it will expire 15 minutes after<br>
> starting the image.<br>
><br>
> But arguably a delay should really expire by the same wall-clock time as<br>
> when it was scheduled, even across snapshots. This is how it was handled in<br>
> Smalltalk-80. Here's the ST80 code:<br>
><br>
> Delay>>preSnapshot<br>
> "convert from local millisecond clock to milliseconds since Jan. 1 1901"<br>
> pendingDelay _ resumptionTime - Time millisecondClockValue.<br>
> resumptionTime _ Time totalSeconds * 1000 + pendingDelay<br>
><br>
> Delay>>postSnapshot<br>
> "convert from milliseconds since Jan. 1 1901 to local millisecond clock"<br>
> pendingDelay _ resumptionTime - (Time totalSeconds * 1000).<br>
> pendingDelay _ pendingDelay max: 0.<br>
> resumptionTime _ Time millisecondClockValue + pendingDelay<br>
><br>
> Of course, we would have to use UTC nowadays but I still think<br>
> re-implementing this would be a good idea.<br>
><br>
> In any case, the fix makes the Delay snapshotting behavior at least<br>
> predictable :)<br>
><br>
> - Bert -<br>
><br>
> On 2013-08-06, at 21:57, Bob Arning <<a href="mailto:arning315@comcast.net">arning315@comcast.net</a>> wrote:<br>
><br>
> Well, this seems to fix it:<br>
><br>
> 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 6 August 2013 at<br>
> 3:39:29 pm'!<br>
><br>
> !Delay class methodsFor: 'snapshotting' stamp: 'raa 8/6/2013 15:22'!<br>
> restoreResumptionTimes<br>
> "Private!! Restore the resumption times of all scheduled Delays after a<br>
> snapshot or clock roll-over. This method should be called only while the<br>
> AccessProtect semaphore is held."<br>
><br>
> | newBaseTime |<br>
> newBaseTime := Time millisecondClockValue.<br>
> SuspendedDelays do: [:d | d adjustResumptionTimeOldBase: 0 newBase:<br>
> newBaseTime].<br>
> ActiveDelay == nil ifFalse: [<br>
> ActiveDelay adjustResumptionTimeOldBase: 0 newBase: newBaseTime.<br>
> ].<br>
> ActiveDelayStartTime _ newBaseTime "<-----this"! !<br>
><br>
> Cheers,<br>
> Bob<br>
><br>
> On 8/6/13 3:27 PM, tim Rowledge wrote:<br>
><br>
> Well the timer stuff has certainly been messed about with a lot since I last<br>
> had to dig into it, but it looks like it *ought* to work ok.<br>
><br>
> The only likely culprit I can spot is some issue with adjusting the<br>
> resumption times after the restart, but that would require some problem with<br>
> the millisecond time prim.<br>
><br>
><br>
> tim<br>
> --<br>
> tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
> Strange OpCodes: YVR: Branch to Vancouver<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>