[Vm-dev] Reed Solomon plugins & performance slow down

Robert Withers robert.withers at pm.me
Fri Jun 4 03:16:25 UTC 2021


Thanks very much, Levente. I'll dig into your suggestions tomorrow. I
made my first contact over ham radio tonight after another generous soul
totally hooked me up with cables and power supplies and programmed my
radio. I am so excited! Now on the air, KO4PYS.

---
Kindly,
Robert


On 6/3/21 8:43 PM, Levente Uzonyi wrote:
> Hi Robert,
>
> I see the following potential causes:
>
> In #findErrorLocationsDegree:coefficients:count:fieldSize:result: the
> return value in ambiguous. You make the primitive fail if not enough
> errors are found. But after the send, you don't check for failure
> but simply send #methodReturnReceiver.
> Instead, you should either check for primitive failure after the send
> or make #findErrorLocationsDegree:coefficients:count:fieldSize:result:
> return boolean value: the method was successful or not.
> E.g. when numErrors = 1, return true, in the other branch, return e =
> numErrors. (If slang doesn't support boolean types, just use 0 and 1).
> In the actual primitive method, check for the value returned by that
> method and fail the primitive when needed. Once the primitive has failed,
> you ought to return from it.
> I see the above pattern in other methods too (marking the primitive as
> failed in a not-top-level method without checking for failure outside).
> Those need to be fixed as well.
>
> Another potential issue I see is that the validation of the arguments is
> not complete.
> E.g.: #stackIntegerValue: may have already set the primitive to failed if
> the argument was not an integer. So, before continuing, that has to be
> checked.
>
> Another possible but unlikely problem is that you assume that both result
> and coefficients have at least one field. But that may not be true which
> can result in segfaults.
>
>
> Levente



More information about the Vm-dev mailing list