Magic Lantern Forum

Developing Magic Lantern => Scripting Corner => Scripting API suggestions => Topic started by: garry23 on May 05, 2017, 09:33:11 AM

Title: Lua string.format
Post by: garry23 on May 05, 2017, 09:33:11 AM
I hope some kind soul can put me out of my misery, as I've not used string.format before.

I've read up on line and I think I'm doing things correctly.

'All' I'm trying to do is format a string to print: here is the demo code:

Code: [Select]
b_diff = 45.6577
info_message = string.format("Blur_Diff = %f", b_diff )

But all I get back when I print is

Code: [Select]
Blur_Diff = f
I've tried %0.2f and still get the same as above.

Where am I going wrong?
Title: Re: Lua string.format
Post by: chris_overseas on May 05, 2017, 01:50:40 PM
What happens if you use %%f instead of just %f? This is just a guess and I don't know Lua, but based on your output it seems like there's an escape issue of some sort.
Title: Re: Lua string.format
Post by: dmilligan on May 05, 2017, 03:04:10 PM
Canon's printf() implementation is not standards compliant and does not support %f (amongst various other things). I suppose you are using the main nightly builds, and I suppose they are still using Canon's printf (it was fixed to use our own standards compliant libc implementation, but that was so long ago, I don't remember if it has made it into unified).
Title: Re: Lua string.format
Post by: garry23 on May 05, 2017, 03:13:28 PM


Through trail and error I worked out that it wasn't implemented, so have solved my needs through another approach.

I'll publish my script soon, which is an infinity focus helper.


Title: Re: Lua string.format
Post by: a1ex on May 05, 2017, 04:03:12 PM
I had a half-successful experiment about 64-bit integers in Lua (, but don't remember doing anything about floating-point. At least, there's no %f in api_test.lua from the lua_fix branch...

The branch about replacing Canon's printf with a standards-compliant implementation ( didn't progress because I hoped for some sort of help from the other developers (as there are *lots* of strings to be updated in that branch, and it's fairly easy to do so - just follow compiler messages - but it takes a lot of time).

For floating-point, the dietlibc library probably has to be recompiled (didn't try, but that would be the first thing).

There's also the possibility of formatting errors (very easy to get unnoticed, as every single formatted string has the chance to give different output after the update -- for a proof, just see the hdparm example from the PR page), so I'm tempted to implement this ( before converting to standards-compliant printf (because it would highlight such errors).