Quoting "David T. Lewis" lewis@mail.msen.com:
On Mon, May 26, 2014 at 02:17:47PM +0000, J. Vuletich (mail lists) wrote:
Hi David, Folks, ... The correct value would be -10800, as answered in Windows. I could not test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit :( ).
Any clue on what's wrong on Mac OS?
BTW, which would be the current non-Cog VMs to try?
Oops, I mistakenly said that the Cog VMs could be used. But it looks like there is a regression or code merge problem of some sort. I'm afraid that I was testing with my own locally compiled Cog VM and did not notice the problem.
A unix Mac VM from squeakvm.org/unix should demonstrate the correct behavior.
CC to vm-dev list:
Eliot, the fix for this was here (but it seems to have been overridden by a more recent change):
Name: VMMaker.oscog-dtl.286 Author: dtl Time: 4 May 2013, 11:29:25.237 am UUID: 8be237d9-7812-4792-9723-90f9cff0c2e9 Ancestors: VMMaker.oscog-eem.285
Replace broken primitiveUtcWithOffset with a version that works.
Dave
Thanks Dave,
I could run on 64 bits Ubuntu with the VM from squeakvm.org/unix. I'll try the Mac VM when I get the chance to borrow a Mac again.
One thing that seems to be missing is a Windows interpreter with the new primitives, although I don't know if there is a real need for that.
Additionally, besides getting rid of <primitive: 137> (primLocalSecondsClock that will overflow in 2037), it would be great to stop using <primitive: 135> (primLocalSecondsClock), that overflows every six days. But for this, we would need a new <primitive: 136> (primSignal:atMilliseconds:) as it uses on the same time base. This would enable a serious simplification of Delay.
Cheers, Juan Vuletich