gordonb3 wrote: > > Yes, but that also requires compiling to the correct (ancient) support > libraries, although maybe you could get away with static linking on a > newer development platform. Of course once you do that you can also fix > jive_jiffies() to perform the roll-over itself at some `safe` time > within the 2^31 limit. >
Quite easily done with @ralphy's build of Squeezeplay, I think. Well, I know it is on macOS. gordonb3 wrote: > > Another option for testing in this case would be to upgrade LUA to 5.4+ > and replace all instances of `lua_Number` (signed) to `lua_Integer` > (unsigned), which should either shift the restart to after 49 days or > possibly continue indefinitely. Here I think you get to the nub of it. What might be convenient is a LUA numeric type that wraps around in the same way as the C integer/unsigned type. Then, given that timer setting is limited to 24 days in the future, and that expired timers are checked within 24 days of expiry, the semantics of timer checking can work fine. (One checks the _difference_ between timer value and current time. Just modular arithmetic.) I think both conditions are probably already met in the existing code. The LUA numeric type could probably be effectively implemented by defining a suitable LUA function or two, but it looked messy to me. Alternatively perhaps a LUA user defined type might be made to look and act cleaner. But, then what ? As far as I am aware, no Radio has ever run longer than 24 days. What else might be revealed ? ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
