<div dir="ltr">On Mon, Aug 1, 2016 at 11:59 AM, Patric Schmitz <span dir="ltr"><<a href="mailto:flavi0@openmailbox.org" target="_blank">flavi0@openmailbox.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi pd devs,<br>
<br>
I'm using pd 0.47.1 on archlinux which ships the latest lua-5.3<br>
by default. It seems that in 5.3 the internal representation of<br>
'number' types differentiates between floating and integer types<br>
now. Quoting the manual:<br>
> The type number uses two internal representations, or two subtypes, one called integer and the other called float. Lua has explicit rules about when each representation is used, but it also converts between them automatically as needed (see §3.4.3).<br>
<br></blockquote><div>and also from §3.4.3:<br>"The conversion from numbers to strings uses a
non-specified human-readable format.
For complete control over how numbers are converted to strings,
use the <code>format</code> function from the string library
(see <a href="http://www.lua.org/manual/5.3/manual.html#pdf-string.format" target="_blank"><code>string.format</code></a>). "





<br><br></div><div>In pd.lua,<br>function pd.Class:dispatch(inlet, sel, atoms)<br>  local m = self["in_" .. inlet .. "_" .. sel]<br></div><div>and<br>  m = self["in_" .. inlet]<br>...here we are looking for a function in the .pdlua script by building a string<br>using the inlet number, which is a lua_Number and will be printed however lua decides to print it.<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This led to the problem that the 'inlet' variable to string<br>
conversion resulted in the value 1.0 instead of 1, so the<br>
dispatching of the method failed since no method named e.g.<br>
in_1.0_float exists.<br>
<br>
I was able to fix it by making the inlet value integral with<br>
> inlet = math.floor(inlet)<br>
in pd.lua pd.Class:dispatch.<br>
\<br></blockquote><div>inlet = string.format("%d", inlet)<br></div><div>should also work. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
An integer-cast could be used as well, but that would not be<br>
compatible with older language versions. As found by Claude on<br>
IRC the floor version should be safe since "Rounding functions<br>
(math.ceil, math.floor, and math.modf) return an integer when the<br>
result fits in the range of an integer, or a float otherwise.".<br>
So as long as < 2^31 inlets are used, which one can reasonably<br>
assume, this should be fine.<br>
<br>
There are probably more places where this fix would need to be<br>
applied, such as the outlet dispatching, and the multi-receive<br>
example. It should also be commented to make obvious what is<br>
happening, like that no int-cast is used due to older language<br>
version compatibility.<br>
<br></blockquote><div>I think only two lines in pd.lua are affected by this. They could be changed to<br>  local m = self["in_" .. string.format("%d", inlet) .. "_" .. sel]<br>and<br>  m = self["in_" .. string.format("%d", inlet)]<br></div><div>or<br> local m = self["in_" .. math.floor(inlet) .. "_" .. sel]<br>and<br>  m = self["in_" .. math.floor(inlet)]<br><br></div><div>All the pd_lua scripts will usually pass through Class:dispatch so if the correct function names are generated therein, there will be no other effects.<br></div><div>pd_lua scripts may use integers internally of course but Pd itself uses only floats. (And lua numbers are either doubles or floats,  pdlua.c will convert them to float.)<br><br></div><div>Thanks for pointing this out,<br><br></div><div>Martin<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Patric<br>
</blockquote></div><br></div></div>