Spontaneous turning-on

[gordonb3]

Things seem to be very complicated regarding Lua's internal value representation of the number type, see LUA_NUMBER_TYPE definition in luaconf.h.
I just stumbled across this discussion between @mrw and @ralphy which I completely missed so far and I was not aware that they already struggled this much to find a solution for the wrapping problem. Wow!

Ah yes. There was talking about introducing an integer type to LUA for some time, but it produced weird results. I got confronted with that when another application I used to use (Domoticz) suddenly changed its code base to use this integer type and all my automation scripts started failing after I installed the update.

Either way, since the source of this issue lies in an apparent requirement for the C code and the LUA scripts to use the exact same value for some number at any given time the obvious solution is to make both environments use a compatible number format. As stated it will be dubious to store an integer value in a double, but then again it isn't actually an integer as it represents the sum of seconds and milliseconds which are itself of type time_t which is likely a floating point value as well (at least on 32 bit systems). The main problem with using a double is that you can not reliably keep adding 1 all the way to MAX_VAL, but if memory serves correct it will be accurate up to ~50 bit integer values on 32 bit systems and would therefore allow integer precision for jive_jiffies() for several years.

Note that this is not related to the pull request I made. That one is purely for keeping the conversion method from C unsigned integer to lua_Number to alter the number sign when pushing it onto the LUA stack.

[Steevee28]

(...) the obvious solution is to make both environments use a compatible number format (...)

Fully agree to this (and your whole post).
So for me now, encapsulating a native int32 or uint32 timer value in a Lua userdata type, as proposed by @mrw, seems to be the only solution that can certainly achieve this, giving us the additional opportunity of simply using built-in modular arithmetics for timer difference calculations, resulting in pretty clean code.
It also seems that we may have a good chance of not requiring any code changes on Lua side, but of course, the C/Lua interactions would all have to be looked through and adapted.

EDIT: I only disagree in one point: time_t is not a floating point on 32bit system, but I think I know what you meant

[ralphy]

Note that this is not related to the pull request I made. That one is purely for keeping the conversion method from C unsigned integer to lua_Number to alter the number sign when pushing it onto the LUA stack.

I've built a jive binary with the PR.

I only tested it in qemu as I'm in the middle of testing something else on my radio and ui works okay. I can't test playback in qemu as I haven't found a kernel audio driver that works so far.

[ralphy]

That is weird, because then you should be seeing the same error, unless of course the build you perform skips the parts where these errors occur.

I'm actually somewhat hazy on that point as well, as there does not appear to be any instruction how to build for any specific target machine even though there is a separate subdirectory for each of them.

There are many patch files included in the squeezeos poky build repository.

If you post details on your build failure, we should be able to figure out why I don't have a problem.

[gordonb3]

There are many patch files included in the squeezeos poky build repository.

If you post details on your build failure, we should be able to figure out why I don't have a problem.

Seems I was mostly chasing a red herring. There was an alignment error in audio decode and as a result it started spitting out various other messages including that of an unrecognized command line option. The main Make file also wants to build some LUA component `luartmp` that fails rather critically, but it appears you can build and install the components individually except for the hardware specific folders that appear to be incomplete and probably need to be combined with another folder but for which no documentation whatsoever exists.

Either way, the version of jive I created started with complaining about a missing png image and a bunch of font files. I found the image in the `squeezeplay_baby` folder of which I copied the entire `share` folder, but this resulted in jive complaining about another png image and completely stop (so not even complaints about the font files even though these are still missing). It's family time, so I stopped for now.

[gordonb3]

Oh, that's pretty hilarious. The sources result in a binary that uses dynamic linking to libraries that don't exist on the target and is statically linked to libraries that do exist on the target. How on earth did they manage to mess that up like that?

[Steevee28]

(...) encapsulating a native int32 or uint32 timer value in a Lua userdata type, as proposed by @mrw, seems to be the only solution that can certainly achieve this (...)

Wireshark has an UInt64/Int64 Lua userdata type implementation that could provide some inspiration: see here

[mrw]

Wireshark has an UInt64/Int64 Lua userdata type implementation that could provide some inspiration: see here

Excellent find !

[gordonb3]

Looking good so far

# uptime
 11:50:54 up 25 days, 16:03, load average: 0.12, 0.12, 0.10
#